跳到主要内容
版本：2.0.x

设计稳定可复用的 Skill

高质量 Skill 的标准不是内容越多越好，而是让 Agent 在正确场景下稳定使用。它应该边界清楚、易于选择、便于维护，并能和平台里的 Skill 创建、编辑、附件和安装流程自然衔接。

如果你还没有创建 Skill，可以先阅读创建标准 Skill。如果 Skill 中有复杂规则、模板或示例，建议结合管理 Skill 附件。创建完成后，再通过为 Agent 安装 Skill接入 Agent。

Skill 是什么​

Skill 是面向 AI Agent 的可复用能力包。它不是最终用户手册，也不是把知识库内容复制一份，而是把某个领域、流程或任务的处理方法沉淀下来，让 Agent 知道“遇到这类问题应该怎么做”。

一个有效的 Skill 通常提供四类能力：

  • 专用工作流：处理某类任务时应按什么步骤行动。
  • 工具或文件约定：如何使用特定接口、命令、文件格式、模板或项目结构。
  • 领域规则：业务概念、判断规则、口径、限制条件和常见陷阱。
  • 可复用资源：附件中的规则、模板、示例、检查清单或参考资料。

Skill 的目标不是让 Agent “知道更多背景”，而是让 Agent 在特定任务上更稳定、更少犯错、更少重复推导。

从一个可复用任务开始​

不要一开始就把 Skill 做成“全能助手”。先选择一个高频、稳定、边界清楚的任务，把它沉淀成可复用能力，再逐步补充规则、模板和附件。

设计时先回答几个问题：

  1. 这个 Skill 解决哪一类问题？
  2. 它适合哪些 Agent 使用？
  3. Agent 什么时候应该使用它？
  4. 执行时需要遵守哪些步骤？
  5. 输出结果应该长什么样？
  6. 哪些场景不应该使用它？

当你能列出几个典型用户请求，并能说明 Agent 应如何处理它们时，再进入平台的 Skill 创建流程。

一个 Skill 只解决一类问题​

不要把多个不相关能力塞进同一个 Skill。一个 Skill 最好只围绕一类业务问题展开，这样 Agent 更容易判断是否适用，也更容易长期维护。

推荐拆分为：

  • 客户跟进 Skill
  • 客户流失风险分析 Skill
  • 销售周报生成 Skill

不推荐合并为：

  • 销售全能 Skill

如果一个主题下还有明显不同的子流程，优先拆成独立 Skill，再由 Agent 按任务组合使用。

描述要让 Agent 能判断是否适用​

Skill 描述不只是给人看的，也会影响 Agent 是否正确使用它。描述要同时写清适用场景、主要能力和边界。

较弱描述：

用于客户管理。

较好描述：

用于销售和客服 Agent 分析客户跟进状态，判断客户优先级并生成下一步沟通建议。不负责直接修改客户数据或承诺成交结果。

一个清晰的描述通常包含三类信息：

  • 适用对象
  • 主要能力
  • 边界说明

如果计划使用 Agent 的智能模式选择 Skill，描述尤其重要。命名和描述的填写入口见创建标准 Skill。

用能力范围限定边界​

能力范围用于告诉 Agent 这个 Skill 能做什么，也告诉它不要越界。

建议同时写明：

  • 能做什么
  • 不能做什么
  • 适用哪些对象
  • 不适用哪些场景
  • 信息缺失时应该追问、默认处理还是停止

边界越清楚，Agent 越不容易把 Skill 用到错误任务里。

用执行步骤沉淀流程​

执行步骤是 Skill 的核心。它把团队经验变成 Agent 可以遵循的流程。

建议使用顺序步骤，而不是大段自然语言：

## 执行步骤

1. 先确认用户要处理的对象。
2. 检查完成任务所需的信息是否齐全。
3. 按固定规则判断或处理。
4. 输出结果，并说明依据和限制。

如果某一步需要工具或数据支持，可以只写业务动作，不需要在 Skill 中展开工具配置。工具暴露属于 Agent 的能力配置，见按需向大模型暴露工具函数。

用输出格式稳定结果​

输出格式能减少 Agent 每次回答风格不一致的问题。尤其是报表、审核意见、分析结论等场景，建议明确输出结构。

推荐使用：

  • 固定标题
  • 表格字段
  • 分条清单
  • 明确的结论、依据、建议

示例：

### 判断结论

### 关键依据

### 建议动作

### 需要人工复核的信息

如果下游流程依赖结构化结果，可以结合输入输出配置设计。

用约束条件减少误用​

约束条件用于告诉 Agent 哪些行为不应该发生。

常见约束包括：

  • 不要编造不存在的数据。
  • 数据不足时先说明缺失信息。
  • 不直接承诺价格、合同条款或法律结论。
  • 不绕过角色权限执行高风险操作。
  • 不输出与业务无关的解释。

高风险 Skill 还需要结合工具暴露和角色权限配置。工具暴露用于影响模型选择，角色权限才负责阻止越权调用。

复杂知识拆成附件​

主提示词不宜过长。复杂规则、术语表、模板和示例建议拆成附件，并在主提示词中说明每个附件的用途。

这样做有两个好处：

  • 主流程更清晰，Agent 更容易抓住重点。
  • 业务规则可以独立维护，不影响 Skill 主结构。

如果某条规则每次执行都必须遵守，应在主提示词中出现；如果只是补充判断或作为参考，可以放进附件。附件管理方法见管理 Skill 附件。

不要把知识库内容搬进 Skill​

Skill 适合写“怎么做”，知识库适合放“事实资料”。不要把大量产品手册、制度文件、FAQ 或历史记录复制进 Skill。

建议分工：

  • Skill：如何判断、如何处理、如何输出。
  • 知识库：产品文档、制度条款、FAQ、历史资料。
  • 工具：查询、写入、调用接口、操作页面。

如果 Agent 需要基于文档回答问题或检索资料，应使用让 Agent 查阅知识库。

不要和 Agent 主提示词重复职责​

Agent 主提示词负责定义当前 Agent 的角色、任务目标和整体行为；Skill 负责提供可复用的专业能力和执行规范。两者不要重复写同一件事。

不建议在 Skill 中写：

你是销售主管助手，负责所有销售管理工作。

更适合写：

当需要分析客户跟进状态时，按本 Skill 的分级规则和输出格式生成跟进建议。

如果某段内容只适用于一个 Agent，放在 Agent 的 System Prompts 中更合适。相关配置见编写 System Prompts。

先验证再复用​

Skill 一旦被多个 Agent 使用，影响范围会变大。建议先在一个测试 Agent 中验证，再推广到更多 Agent。

验证时重点看：

  • 使用场景是否准确。
  • 输出格式是否稳定。
  • 是否和 Agent 主提示词冲突。
  • 是否需要额外工具或知识库支持。
  • 是否存在高风险操作，需要角色权限或业务复核流程。

验证时尽量使用真实或拟真的用户任务，不要只问“这个 Skill 写得好不好”。真实任务更容易暴露触发不准、流程不清、输出不稳和边界缺失的问题。

迭代时优先修具体问题​

Skill 不需要一次写完。每次真实使用后，记录 Agent 的失败点，再判断应该改哪里。

常见迭代方向：

  • 触发不准：改写名称和描述。
  • 流程混乱：把正文改成编号步骤。
  • 输出漂移：补充固定输出结构。
  • 重复犯错：把隐性规则写成显性约束。
  • 内容太长：把详细规则、模板和示例拆到附件。
  • 缺少事实依据：接入知识库或工具，而不是把大量资料塞进 Skill。

每次迭代都应针对一个明确问题，而不是泛泛地“补充更多内容”。