Skill绝不是写一段更长的Prompt，而是把可复用的经验、操作流程和质量标准，沉淀成Agent可调用的能力模块。 Prompt解决的是‘这次怎么做’，而Skill解决的是‘这类任务以后都怎么做’。

• 流程流向：

  1. 起点（Skill 库）：​ 系统拥有一个 Skill 库作为能力来源。

  2. 检索（Metadata 检索）：​ 当需要执行任务时，系统首先通过元数据检索，只查看技能的摘要和标签来初步筛选。

  3. 优先级判断（作用域/优先级）：​ 这是一个关键的决策环节，规定了规则的优先级顺序：安全规则 > 项目规则 > Skill > 用户偏好。这意味着越底层的、越基础的规则权重越高，Skill 不能覆盖安全底线。

  4. 核心策略（最小必要上下文）：​ 经过上述筛选后，系统最终只注入当前任务真正需要的“完整指令（full instruction）”。这就是所谓的“最小必要上下文”原则。

• 对比分析（正确 vs 错误）：

  • 错误做法（左下角）：​ 将所有 Skill 全部塞进去。图中用虚线箭头表示了这种错误的倾向，认为这会导致信息过载和噪声。

  • 正确做法（右下角）：​ 采取 “按需加载 + 冲突检测 + 版本治理”​ 的策略，确保加载进来的上下文是最精简且安全的。

【第一步：结构化构建Skill（写什么）】

“具体落笔写的时候，我不会上来就堆规则，而是按三个层次、九个要素来结构化地写：

第一层，先圈定能力的边界。 必须写清楚三个点：适用场景、不适用场景、输入要求。很多人写Skill只写能干什么，不写不能干什么，这非常危险。比如写简历优化的Skill，必须明确标出‘不能用于编造虚假经历’，不适用场景和适用场景一样重要。同时，输入信息不足时，要明确要求Agent先追问，而不是硬编。

第二层，固化执行流程与标准。 这里包含四个点：操作步骤、工具使用、输出格式、质量标准。操作步骤要把专家的隐性SOP显性化，比如排查问题，必须是‘先看影响范围，再看日志，再验证假设’。工具使用要写清‘优先用哪个、失败了怎么办’。输出格式要定死结构，而质量标准要告诉Agent‘什么叫做好’，不能让它只生成一个‘看起来像完成了’的结果。

第三层，强制写明兜底与红线。 也就是失败处理和安全边界。真实任务经常出错，信息不足怎么办？工具报错怎么办？权限不够怎么办？必须有降级、拒答或转人工的策略。而安全边界，比如‘不输出敏感信息’、‘不把不确定的当确定的讲’，这些不仅要写在Skill里，更要在工程层做拦截。因为Skill只是软约束，Tool Registry和Harness才是硬约束。”

【第二步：Skill的来源与迭代（怎么写出来）】

“当然，好的Skill不是坐在工位上拍脑袋写出来的，我遵循的路径是：从重复任务里提炼，从失败案例里补规则，从专家流程里抽SOP，从工具使用里沉淀最佳实践。

其中最有效的是‘从失败案例里长出来’。比如Agent做RAG经常不看证据来源就回答，那我就得在Skill里补上‘必须检查结论是否被检索文档支持’。Skill写完也不是结束，必须进入评测闭环，看它是不是真的提升了任务成功率，如果只是Token暴涨、误召回增加，那它就是在污染上下文。”

【第三步：工程化治理（高级认知展现）】

“最后，我认为写Skill不能只看‘写’本身，还要考虑它在生产环境里的治理。

当Skill变多，最怕的就是上下文污染和规则冲突。所以我会做几件事：

1. 按需加载：绝不把所有Skill全塞进去，而是通过Metadata检索和任务匹配，只注入当前任务的最小集合。
2. 分层摘要：检索时只看摘要和标签，真正执行时再加载Full Instruction

   1. 核心目标（Agent 执行任务）：​ 位于图顶部的中心节点，所有的底层能力最终都是为了支撑 Agent 完成具体任务。

   2. 四大核心组件（围绕 Agent 的四个方框）：

      1. Prompt（单次任务指令）：​ 针对这一次特定任务的指令。

      2. Skill（跨任务复用流程）：​ 重点强调 Skill 是用来解决“这类任务以后都怎么做”的，实现了能力的跨任务复用，避免了重复造轮子。

      3. Tool / MCP（真实执行能力）：​ 提供与外部世界交互的真实执行工具。

      4. Memory（经验和事实存储）：​ 存储历史经验、事实知识等，为决策提供依据。

   3. 底层支撑（Harness）：

      • 在底部有一个粉色的方框 Harness，它通过虚线箭头向上连接到其他组件，代表它是全局的基础设施。

      • 功能：​ 提供全局治理，包括 权限控制、成本管理、链路追踪（Trace）、评估（Eval）。

   4. 设定优先级：当规则冲突时，遵循‘系统安全规则 > 项目级规则 > 任务级Skill > 用户偏好’的作用域。

3. A/B测试验证：Skill有没有用不靠感觉，而是对比‘加载前后’的任务成功率、工具调用成功率、人工修正率和Token成本。”

【收尾总结】

“总而言之，写Skill表面上是写一段说明文，底层考的是工程意识。我是带着‘可复用、可治理、可评估’的思路去写Skill的，既要让Agent在局部任务上做得更稳，又要防止它变成上下文里的噪声，这就是我的理解和做法。”