面试官问你「会写Agent Skill吗」，别只说「写提示词」——这才是正确答案

最近面试AI Agent岗，有个问题出现频率特别高：「如果让你给Agent写Skill，你会怎么写？」 很多人一听Skill，直接说：「不就是写一段提示词吗？」——面试官听完直接皱眉头。 别小看这个问题，它考察的不是你会不会写Prompt，而是你有没有把重复经验沉淀成可复用能力的工程意识。 这篇文章系统讲一下：Skill到底是什么？和Prompt、Tool、MCP、Memory、Harness有什么区别？一个高质量Skill应该包含什么？怎么写？怎么管理？面试怎么答？

一、👔 面试官：先给结论——Skill到底是不是更长的Prompt？

🙋‍♂️候选人：Skill就是给Agent写的一段更详细的提示词……

👔面试官：那Prompt和Skill有什么区别？

🙋‍♂️候选人：呃……Skill更长更详细？

👔面试官：那什么任务适合沉淀成Skill？什么不适合？Skill和Tool、MCP、Memory、Harness又有什么边界？

💡 简要回答

Skill不是更长的Prompt，而是把可复用经验、操作流程、工具使用方法和质量标准沉淀成Agent可调用的能力模块。Prompt解决单次任务表达，Skill解决跨任务复用。

📝 详细解析

Skill到底是什么

可以这样定义：Skill是面向某一类任务的可复用能力说明，它告诉Agent什么时候用、怎么做、用什么工具、按什么标准输出、遇到异常怎么处理。

注意，它不是简单写一句：

你是一个专业的简历优化专家。

这太空了。一个真正有用的Skill，应该能回答这些问题：

• 什么场景该用它？
• 什么场景不该用它？
• 输入需要哪些信息？
• 操作步骤是什么？
• 优先使用哪些工具？
• 输出格式是什么？
• 怎么判断结果合格？
• 信息不足怎么办？
• 工具失败怎么办？
• 有哪些安全边界？

举个例子，如果你写一个"简历项目点评Skill"，它不应该只说"帮用户优化简历项目"，而应该写清楚：

• 先判断项目描述是否有业务场景
• 再检查个人工作是否突出技术贡献
• 再看项目难点是否有挑战和解决方案
• 再给出优化版本
• 输出必须包含反面问题和正面示例
• 不要凭空编造用户没写过的经历

这才是Skill。Skill的价值不是让模型"知道一个名词"，而是让模型在某类任务上更稳定地遵循流程和边界。

Skill和其他概念的区别

面试官很喜欢问边界，因为很多人把这些概念混在一起。你要能讲清楚它们分别解决什么问题：

一句话总结：Prompt适合一次性任务，Skill适合高频重复任务。Tool是执行器，Skill是使用指南。MCP是接入协议，Skill是使用策略。Memory是知识库，Skill是方法论。Harness是全局治理，Skill是局部能力。

二、👔 面试官：一个高质量Skill应该包含什么？

🙋‍♂️候选人：就是把提示词写得详细一点……

👔面试官：详细到什么程度？要不要写安全边界？要不要写失败处理？要不要写质量标准？

💡 简要回答

写Skill不能只写"你要专业"这类没工程价值的话。一个高质量Skill至少应该包含：适用场景、不适用场景、输入要求、操作步骤、工具使用、输出格式、质量标准、失败处理、安全边界。

📝 详细解析

高质量Skill的九个组成部分

逐个拆解：

1. 适用场景：什么时候该用这个Skill？

• 比如："当用户要求分析简历项目、优化项目经历、点评个人工作时使用"。适用场景越清楚，Agent越不容易误用。

2. 不适用场景：什么时候不该用？

• 这点很重要！很多Skill只写能做什么，不写不能做什么，结果Agent一遇到相似任务就乱套。比如简历点评Skill不应该用于：生成虚假实习经历、伪造项目成果、编造公司背景、替用户写不真实的技术细节。Skill要写边界，不只是写能力。

3. 输入要求：Skill要说明需要哪些输入

• 比如：原始简历内容、目标岗位、项目背景、技术栈、用户想优化哪一部分。如果输入不足，Skill应该要求Agent先追问，而不是硬编。

4. 操作步骤：Skill最重要的是流程

• 比如：先识别任务类型→再检查信息完整性→再按框架分析→再输出优化建议→最后给出可直接替换的版本。步骤要明确，但不要写死到无法适配。

5. 工具使用：如果任务需要工具，要写清楚

• 优先用哪个工具？什么情况下不用工具？工具失败怎么办？工具结果如何验证？注意，Skill不能绕过Tool Registry，它只能指导工具使用方式，不能替代权限治理。

6. 输出格式：Agent最容易不稳定的地方就是输出格式

• Skill里应该写清楚：最终输出分几部分？要不要表格？要不要代码？要不要引用来源？要不要风险提示？

7. 质量标准：Skill要告诉Agent什么叫做好

• 比如：是否解决用户目标？是否有事实依据？是否结构清晰？是否可执行？是否避免无关展开？没有质量标准，Agent只会生成"看起来像完成了"的结果。

8. 失败处理：真实任务里经常失败

• Skill要写：信息不足怎么办？工具失败怎么办？证据不足怎么办？权限不足怎么办？结果冲突怎么办？高质量Skill一定要有兜底策略。

9. 安全边界：比如不要编造事实、不要绕过权限、不要执行高风险动作、不要输出敏感信息、不要把不确定内容说成确定事实。这里要强调：安全边界不能只写在Skill里，工程层也要有拦截——Skill是提醒，Harness和Tool Registry才是强制执行。

三、👔 面试官：怎么写出高质量Skill？

🙋‍♂️候选人：就是想清楚流程，然后写出来……

👔面试官：那流程是从哪来的？凭经验拍脑袋？还是有方法论？

💡 简要回答

好的Skill不是坐在工位上拍脑袋写出来的，而是从真实任务里抽出来的。推荐路径：重复任务→失败案例→专家流程→工具经验→Eval反馈→Skill迭代。

📝 详细解析

写出高质量Skill的五个步骤

1. 从重复任务里提炼

不是所有任务都值得写Skill。Skill适合高频、重复、流程相对稳定的任务，比如：

• 简历点评
• 日志排查
• RAG评估
• SQL优化
• 文档生成
• PR Review
• 数据分析报告

如果任务只出现一次，写Skill成本可能不划算。

2. 从失败案例里补规则

Skill最有价值的来源，是Agent犯过的错。

• 比如Agent做RAG评估时，经常只看最终答案，不看证据来源→Skill里就要补"必须检查答案关键结论是否被检索文档支持"
• 比如Agent写代码时经常忘记跑测试→Skill里就要补"修改代码后优先运行相关最小测试"

好的Skill，是从错误里长出来的。记住：Skill是软约束，工程拦截才是硬约束——Skill可以提醒，但真正的安全控制要在Harness和Tool Registry层实现。

3. 从专家流程里抽SOP

很多专家做事有隐性流程。

• 比如一个资深工程师排查线上问题，不会一上来就改代码→他会先看影响范围，再看日志，再看最近变更，再验证假设

这种流程就适合沉淀成Skill。Skill的价值，就是把专家隐性经验显性化。

4. 从工具使用经验里沉淀最佳实践

有些工具很强，但用不好。

• 比如浏览器自动化、数据库查询、RAG检索、日志平台、代码搜索

Skill可以写清楚：

• 查询前先缩小范围
• 不要一次取太多结果
• 先读schema再写SQL
• 搜不到时换关键词
• 工具结果要二次校验

这会显著提升Agent的稳定性。

5. 从Eval结果里迭代

Skill写完不是结束，要看效果。

• 如果某个Skill加载后，任务成功率上升、工具失败率下降、格式错误率降低→说明它有效
• 如果Skill加载后Token暴涨，误召回增加→说明它可能污染上下文

Skill要进入评测闭环，不是写完就放在那里。

四、👔 面试官：Skill多了之后，Agent怎么选择和调用？

🙋‍♂️候选人：就是让Agent自己选……

👔面试官：那选错了怎么办？Skill冲突了怎么办？怎么控制Token消耗？

💡 简要回答

Skill选择不是单一方案，而是组合使用：显式指定（最稳定）、任务描述匹配（最灵活）、Metadata检索（最可控）、Harness控制注入（最安全）。最重要的是——Skill要按需加载，不要全塞进去污染上下文。

📝 详细解析

Skill选择的四种方式

Skill多了之后，最大的问题不是怎么写，而是怎么选。面试官很可能会问："如果系统里有几十个Skill，Agent怎么知道该用哪个？"

可以分四种方式：

推荐做法：生产系统里，不应该让Agent自己随便加载所有Skill。Agent可以建议用Skill，但Harness应该控制Skill注入。

Skill选择失败怎么办

Skill召回错了，会误导Agent。比如用户只是问"怎么写简历"，系统却加载了"简历造假美化Skill"——这就危险了。

所以要有：

• Skill命中置信度：置信度低时不自动加载，而是询问用户
• 多Skill冲突检测：如果多个Skill规则冲突，按优先级处理
• 低置信度时追问用户："我不确定该用哪个Skill，你能告诉我吗？"
• 高风险Skill需要显式确认：涉及删除、修改等操作的Skill，必须用户确认
• Skill使用记录进入Trace：方便排查问题和迭代Skill

五、👔 面试官：Skill的上下文怎么治理？会不会污染？

🙋‍♂️候选人：就是把所有Skill都塞进去……

👔面试官：那Token会不会爆炸？上下文会不会被污染？Agent会不会被误导？

💡 简要回答

Skill本来是能力资产，但管理不好会变成上下文噪声。核心策略：按需加载、分层摘要、优先级和作用域、版本管理、过期Skill淘汰。Skill不是越多越好，是越准越好。

📝 详细解析

Skill上下文治理的五个策略

Skill多了之后，会出现一个新问题：Skill本来是能力资产，但管理不好会变成上下文噪声。很多团队一开始很兴奋，写了几十个Skill，然后每次任务都塞一堆进去，结果模型看了一大堆不相关规则，反而更容易跑偏。

这就是Skill污染上下文。怎么治理？

1. 按需加载：不要把所有Skill都放进上下文，只加载当前任务需要的最小集合。Skill应该像工具一样按需调用，而不是像背景音乐一样一直播放。

2. 分层摘要：Skill可以分层：

• metadata：用于检索和路由
• summary：用于快速判断是否适用
• full instruction：真正执行时再加载

这样可以减少上下文浪费。

3. 优先级和作用域：不同Skill可能冲突，比如一个Skill要求"回答尽量简洁"，另一个Skill要求"详细解释每一步"。这时要有优先级，通常可以按：系统安全规则 > 项目级规则 > 任务级Skill > 用户喜好。作用域也要清楚，不要让一个局部Skill影响全局任务。

4. 版本管理：Skill会迭代，每次修改都应该有版本，至少要记录：修改原因、影响场景、评测结果、回滚方式。否则Skill越改越乱。

5. 过期Skill淘汰：业务会变，工具会变，模型能力也会变，旧Skill可能不再适用。所以要定期检查：是否还被命中？是否提升指标？是否产生误导？是否和新工具冲突？无效Skill要下线。

一句话总结：Skill不是越多越好，是越准越好。

六、👔 面试官：Skill怎么评估效果？

🙋‍♂️候选人：就是看效果好不好……

👔面试官：怎么定义"好"？有没有量化指标？有没有A/B测试？

💡 简要回答

不要只说写了Skill，要说怎么证明它有用。核心指标：任务成功率、工具调用成功率、输出稳定性、人工修正率、Token消耗、Skill命中准确率和误召回率。还要做A/B测试对比。

📝 详细解析

Skill效果评估的七个指标

面试中说Skill，有一个很重要的加分点：不要只说写了Skill，要说怎么证明它有用。如果你说"我加了Skill后感觉效果更好了"，这不算工程结论。要看指标。

A/B测试怎么做

可以做对比：

• 不加载Skill vs 加载Skill
• 旧Skill vs 新Skill
• 单Skill vs Skill组合
• 全量Skill vs 最小必要Skill

有对比，才能知道Skill是真的有效，还是只是心理安慰。

七、👔 面试官：Skill常见的误区有哪些？

🙋‍♂️候选人：好像没什么误区……

👔面试官：那你有没有把Skill写得特别长？有没有只写步骤不写边界？有没有Skill冲突不管？

💡 简要回答

常见误区：把Skill写成长Prompt、只写步骤不写边界、Skill互相冲突不管、工具细节写太死、Skill不更新、所有任务都强制加载、没有Eval只靠感觉迭代、把安全约束只写在Skill里。

📝 详细解析

八个常见误区

这里面试也很容易问，因为很多团队引入Skill后，确实会踩坑：

1. 把Skill写成长Prompt：Skill不是越长越好，太长会挤占上下文，还会让模型抓不住重点。好的Skill应该结构清楚、边界明确、只包含必要信息。

2. 只写步骤，不写边界：只写"怎么做"，不写"什么时候不该做"，很容易误用。Skill必须写不适用场景和风险边界。

3. Skill互相冲突：多个Skill同时加载时，规则可能冲突。所以要有优先级、作用域和冲突检测。

4. 工具细节写太死：如果Skill把某个工具的参数写死，工具一升级就坏。Skill应该描述工具使用原则，具体schema以Tool Registry为准。

5. Skill不更新：业务会变，工具会变，模型能力也会变，Skill也要变。过期Skill会误导Agent。

6. 所有任务都强制加载Skill：这会造成上下文污染。Skill应该按需加载，不是越多越专业。

7. 没有Eval，只靠感觉迭代：没有指标，就不知道Skill有没有价值。最后会变成一堆没人敢删的历史规则。

8. 把安全约束只写在Skill里：这是很危险的误区。Skill可以提醒模型不要越权，但真正的权限、审批、审计，必须在Harness和Tool Registry层实现。

🎯 总结：面试怎么答Skill相关问题

回顾这篇文章，当面试官问你Skill相关问题时，你可以按这个逻辑链回答：

面试回答框架：

1. 先给结论：Skill不是更长的Prompt，而是把可复用经验沉淀成Agent可调用的能力模块。Prompt解决单次任务，Skill解决跨任务复用。
2. 再讲边界：Skill和Prompt、Tool、MCP、Memory、Harness的区别——面试官很喜欢问这个，能讲清楚说明你理解透彻。
3. 再说结构：一个高质量Skill应该包含九个部分——适用场景、不适用场景、输入要求、操作步骤、工具使用、输出格式、质量标准、失败处理、安全边界。
4. 接着讲方法：怎么写出高质量Skill？从重复任务里提炼、从失败案例里补规则、从专家流程里抽SOP、从工具使用经验里沉淀最佳实践、从Eval结果里迭代。
5. 然后讲管理：Skill多了怎么选？显式指定、任务描述匹配、Metadata检索、Harness控制注入。上下文怎么治理？按需加载、分层摘要、优先级和作用域、版本管理、过期淘汰。
6. 再讲评估：怎么证明Skill有用？七个指标+A/B测试。
7. 最后讲避坑：八个常见误区——能说出这些，说明你有实战经验。

最后一句话：Skill真正考的，不是你会不会写一段说明，而是你有没有把重复经验沉淀成可复用能力的工程意识。