Skill 与 Prompt 的核心区别
先给结论：Skill 不是更长的 Prompt，而是把可复用经验、操作流程、工具使用方法和质量标准沉淀成 Agent 可调用的能力模块。
这句话要抓住两个关键词：1. 可复用 2. 能力模块。
Prompt 更偏单次任务。比如用户这次让模型写一份简历点评，你在 Prompt 里告诉它："先指出问题，再给出优化版本。"这当然有用。但如果你每次做简历点评，都要重新告诉模型一遍四要素框架、点评顺序、输出格式、常见问题、不要犯哪些错，那就说明这些经验应该沉淀成 Skill。
Skill 解决的是：同一类任务反复出现时，Agent 不应该每次都从零推理。它应该复用已经沉淀好的流程。
所以面试里不要把 Skill 说成"一段 Prompt"。更好的说法是：Prompt 解决单次任务表达，Skill 解决跨任务复用。这也是 Skill 的核心价值。
Skill 到底是什么
可以这样定义：> Skill 是面向某一类任务的可复用能力说明，它告诉 Agent 什么时候用、怎么做、用什么工具、按什么标准输出、遇到异常怎么处理。
注意，它不是简单写一句"你是一个专业的简历优化专家"，这太空了。一个真正有用的 Skill，应该能回答这些问题：
- 什么场景该用它？什么场景不要用它？
- 输入需要哪些信息？
- 操作步骤是什么？
- 优先使用哪些工具？
- 输出格式是什么？
- 怎么判断结果合格？
- 信息不足怎么办？工具失败怎么办？
- 有哪些安全边界？
举个例子：如果你写一个"简历项目点评 Skill"，它不应该只写"帮用户优化简历项目"，而应该写清楚：
- 先判断项目描述是否有业务场景
- 再检查个人工作是否突出技术贡献
- 再看项目难点是否有挑战和解决方案
- 再给出优化版本
- 输出必须包含反面问题和正面示例
- 不要凭空编造用户没写过的经历
这才是 Skill。Skill 的价值不是让模型"知道一个名词"，而是让模型在某类任务上更稳定地遵循流程和边界。
Skill 与其他组件的区别
面试官很喜欢问边界，因为很多人把这些概念混在一起。你要能讲清楚它们分别解决什么问题。
Skill 和 Prompt 的区别
- Prompt 是单次指令：更像你临场告诉模型"这次请按 A、B、C 做"。
- Skill 是可复用能力：更像你提前沉淀好一套 SOP，"以后遇到这类任务，都按这个方法做"。
- 结论：Prompt 适合一次性任务，Skill 适合高频重复任务。
Skill 和 Tool 的区别
- Tool 是执行动作的能力：比如
search_docs负责检索文档。 - Skill 是使用能力的方法：比如"什么时候检索、检索几轮、如何判断检索结果够不够、没证据时怎么拒答"。
- 结论：Tool 解决能不能做，Skill 解决怎么做得更稳。
Skill 和 MCP 的区别
- MCP 是工具接入协议：解决工具怎么标准化暴露给模型或 Agent 应用，提供的是工具生态。
- Skill 是任务方法论：告诉 Agent 当前任务该不该用这个 MCP 工具、用之前要检查什么、调用结果怎么解释、高风险动作怎么处理。
- 结论：MCP 提供工具生态，Skill 提供任务方法论。
Skill 和 Memory 的区别
- Memory 是经验和事实的存储：比如"用户喜欢简洁回答"、"某个项目曾经因为缓存击穿出过事故"。
- Skill 是可执行的任务方法：比如"做项目点评时，先看业务场景，再看技术贡献，再看难点，再看收获"。
- 结论：Memory 更像材料库，Skill 更像操作手册。
Skill 和 Harness 的区别
- Harness 是全局运行时治理：负责编排、工具权限、状态管理、成本预算、轨迹评估、安全边界。
- Skill 是局部任务能力：比如"写文档 Skill"、"分析日志 Skill"、"做 RAG 评估 Skill"。
- 结论：Skill 让局部任务做得更稳，Harness 让整个 Agent 系统跑得更稳。
一个高质量 Skill 应该包含什么
写 Skill 不能只写"你要专业"，这类话没什么工程价值。一个高质量 Skill，至少应该包含以下九个部分：
- 适用场景：什么时候应该用这个 Skill？（例如："当用户要求分析简历项目、优化项目经历、点评个人工作时使用。"）适用场景越清楚，Agent 越不容易误用。
- 不适用场景：什么时候不要用？（例如：简历点评 Skill 不应该用于生成虚假实习经历、伪造项目成果、编造公司背景等。）Skill 要写边界，不只是写能力。
- 输入要求：需要哪些输入？（例如：原始简历内容、目标岗位、项目背景等。）如果输入不足，Skill 应该要求 Agent 先追问，而不是硬编。
- 操作步骤：流程是什么？（例如：先识别任务类型 -> 再检查信息完整性 -> 再按框架分析 -> 再输出优化建议。）步骤要明确，但不要写死到无法适配。
- 工具使用：优先用哪个工具？什么情况下不用？工具失败怎么办？结果如何验证？注意，Skill 不能绕过 Tool Registry，只能指导工具使用方式。
- 输出格式：最终输出分几部分？是否需要表格、代码、引用来源或风险提示？
- 质量标准：什么叫做好？（例如：是否解决用户目标、是否有事实依据、是否结构清晰、是否可执行。）没有质量标准，Agent 只会生成"看起来像完成了"的结果。
- 失败处理：信息不足、工具失败、证据不足、权限不足、结果冲突时怎么办？高质量 Skill 一定要有兜底策略。
- 安全边界：不要编造事实、不要绕过权限、不要执行高风险动作、不要输出敏感信息。注意：安全边界不能只写在 Skill 里，工程层（Harness 和 Tool Registry）也要有拦截。Skill 是提醒，Harness 和 Tool Registry 才是强制执行。
如何写出高质量 Skill
好的 Skill 不是坐在工位上拍脑袋写出来的，它是从真实任务里抽出来的。建议遵循以下路径：
重复任务 → 失败案例 → 专家流程 → 工具经验 → Eval 反馈 → Skill 迭代
- 从重复任务里提炼：Skill 适合高频、重复、流程相对稳定的任务（如简历点评、日志排查、RAG 评估、SQL 优化、文档生成、PR Review、数据分析报告）。如果任务只出现一次，写 Skill 成本可能不划算。
- 从失败案例里补规则：Skill 最有价值的来源是 Agent 犯过的错。比如 Agent 做 RAG 评估时经常只看最终答案不看证据来源，Skill 里就要补"必须检查答案关键结论是否被检索文档支持"。好的 Skill 是从错误里长出来的。
- 从专家流程里抽 SOP：很多专家做事有隐性流程（如资深工程师排查线上问题的步骤），Skill 的价值就是把专家隐性经验显性化。
- 从工具使用经验里沉淀最佳实践：Skill 可以写清楚查询前先缩小范围、不要一次取太多结果、先读 schema 再写 SQL、搜不到时换关键词、工具结果要二次校验等，显著提升 Agent 稳定性。
- 从 Eval 结果里迭代：Skill 写完不是结束。如果加载后任务成功率上升、工具失败率下降、格式错误率降低，说明有效；如果 Token 暴涨、误召回增加，说明可能污染上下文。Skill 要进入评测闭环。
Skill 如何被 Agent 选择和调用
如果系统里有几十个 Skill，Agent 怎么知道该用哪个？可以分以下几种方式：
- 显式指定：用户或系统直接指定（例如："这次用简历点评 Skill"）。这种最稳定，适合后台任务、固定流程、自动化工作流。
- 任务描述匹配：系统根据用户输入和 Skill 描述做匹配（例如：用户说"帮我优化一下项目经历"，匹配到简历项目优化 Skill）。这种方式灵活，但依赖 Skill 描述质量。
- Metadata 检索：每个 Skill 都应该有 metadata（name, description, domain, task_type, input_requirements, tools, risk_level, version）。系统可以根据 metadata 做检索和路由，比全文塞上下文更可控。
- Harness 控制注入：生产系统里，不应该让 Agent 自己随便加载所有 Skill。Harness 应该根据任务类型、用户权限、上下文预算、风险等级决定注入哪些 Skill。Agent 可以建议用 Skill，但 Harness 应该控制 Skill 注入。
- Skill 选择失败怎么办：Skill 召回错了会误导 Agent（如用户问"怎么写简历"却加载了"简历造假美化 Skill"）。所以要有 Skill 命中置信度、多 Skill 冲突检测、低置信度时追问用户、高风险 Skill 需要显式确认、Skill 使用记录进入 Trace。
Skill 的上下文治理
Skill 本来是能力资产，但管理不好会变成上下文噪声。如果每次任务都塞一堆 Skill 进去，模型看了一大堆不相关规则，反而更容易跑偏。这就是 Skill 污染上下文。
- 按需加载：不要把所有 Skill 都放进上下文，只加载当前任务需要的最小集合。Skill 应该像工具一样按需调用，而不是像背景音乐一样一直播放。
- 分层摘要：Skill 可以分层：metadata（用于检索和路由）、summary（用于快速判断是否适用）、full instruction（真正执行时再加载）。这样可以减少上下文浪费。
- 优先级和作用域：不同 Skill 可能冲突（如一个要求"回答尽量简洁"，另一个要求"详细解释每一步"）。通常按 系统安全规则 > 项目级规则 > 任务级 Skill > 用户偏好 排序。作用域也要清楚，不要让一个局部 Skill 影响全局任务。
- 版本管理：Skill 会迭代，每次修改都应该有版本，记录修改原因、影响场景、评测结果、回滚方式。否则 Skill 越改越乱。
- 过期 Skill 淘汰：业务、工具、模型能力都会变，旧 Skill 可能不再适用。要定期检查是否还被命中、是否提升指标、是否产生误导、是否和新工具冲突。无效 Skill 要下线。Skill 不是越多越好，是越准越好。
Skill 和生产级 Agent 的关系
Skill 不是孤立存在的，它要放在 Agent 工程体系里看。可以这样理解：
- Prompt：单次任务指令
- Skill：局部可复用能力
- Tool：真实执行动作
- MCP：工具接入协议
- Memory：经验和事实存储
- Harness：全局运行时治理
如果没有 Skill，Agent 每次处理复杂任务都要从零推理；如果没有 Tool，Skill 只是纸上流程；如果没有 Memory，Skill 无法利用历史经验；如果没有 Harness，Skill 可能被乱加载、乱组合、乱执行。所以生产级 Agent 不是只靠某一层，而是这些层一起工作。
尤其要注意：Skill 不能替代 Harness，也不能替代 Tool Registry。比如 Skill 里写"删除文件前必须确认"，这有帮助，但真正的删除权限、确认流程、审计日志，必须在工具治理层强制执行。只把安全写在 Skill 里，不做工程拦截，生产上是不够的。
Skill 怎么评估效果
面试里说 Skill，有一个很重要的加分点：不要只说写了 Skill，要说怎么证明它有用。如果你说"我加了 Skill 后感觉效果更好了"，这不算工程结论。要看指标：
- 任务成功率：加载 Skill 后，任务是否更容易完成？（如简历点评是否覆盖四要素、日志排查是否定位到根因、代码修改是否通过测试、RAG 回答是否有证据支持）
- 工具调用成功率：是否减少了错误工具调用？（如工具选错率下降、参数非法率下降、无意义重复调用减少、高风险工具误调用减少）
- 输出稳定性：看输出是否更稳定。（如格式错误率、字段缺失率、引用缺失率、不按流程输出的比例）
- 人工修正率：如果 Skill 有效，人工修正应该减少。特别是面向内容生成、代码修改、数据分析的任务，人工返工率比"看起来不错"更有说服力。
- Token 消耗：Skill 不是免费的。加载 Skill 会占上下文。要看 Skill Token 占比、总 Token 是否上升、重试次数是否下降、单任务成本是否下降。
- Skill 命中准确率和误召回率：这是 Skill 系统特有指标。命中准确率指该用的时候有没有用；误召回率指不该用的时候有没有乱用。误召回很危险，因为错误 Skill 会给 Agent 带来错误方向。
- A/B 测试：可以做对比（不加载 Skill vs 加载 Skill、旧 Skill vs 新 Skill、单 Skill vs Skill 组合、全量 Skill vs 最小必要 Skill）。有对比，才能知道 Skill 是真的有效，还是只是心理安慰。
Skill 常见误区
很多团队引入 Skill 后，确实会踩坑：
- 把 Skill 写成超长 Prompt：Skill 不是越长越好。太长会挤占上下文，还会让模型抓不住重点。好的 Skill 应该结构清楚、边界明确、只包含必要信息。
- 只写步骤，不写边界：只写"怎么做"，不写"什么时候不要做"，很容易误用。Skill 必须写不适用场景和风险边界。
- Skill 互相冲突：多个 Skill 同时加载时，规则可能冲突。所以要有优先级、作用域和冲突检测。
- 工具细节写得太死：如果 Skill 把某个工具的参数写死，工具一升级就坏。Skill 应该描述工具使用原则，具体 schema 以 Tool Registry 为准。
- Skill 不更新：业务变了，工具变了，模型能力变了，Skill 也要变。过期 Skill 会误导 Agent。
- 所有任务都强制加载 Skill：这会造成上下文污染。Skill 应该按需加载，不是越多越专业。
- 没有 eval，只靠感觉迭代：没有指标，就不知道 Skill 有没有价值。最后会变成一堆没人敢删的历史规则。
- 把安全约束只写在 Skill 里：这是很危险的误区。Skill 可以提醒模型不要越权，但真正的权限、审批、审计，必须在 Harness 和 Tool Registry 层实现。