什么是 Skill

第一次接触 Skill 时，可以先把 AI 模型想象成一个知识面很广、理解能力也不错的新同事。它能够回答许多问题，但面对一项具体任务时，未必知道团队希望它按照什么步骤处理，也不知道哪些资料可以读取、哪些操作不能执行。

Skill 就是交给这位新同事的一套可复用任务方法。它会告诉 AI：什么情况下应该使用这套方法，执行时要经过哪些步骤，可以读取哪些资料或调用哪些工具，最终应该得到什么结果，以及整个过程需要遵守哪些边界。

因此，Skill 不是一个新的 AI 模型，也不只是某一句 Prompt。简单的 Skill 可以是一组单轮处理指令，复杂的 Skill 还可以包含多轮状态、工作流、受控工具和后台任务。无论复杂程度如何，它解决的都是同一个问题：让 AI 在遇到某类任务时，不再临场随意发挥，而是按照已经定义好的方法稳定完成。

我们可以用一个具体场景来理解。用户对 Agent 说：

如果没有 Skill，模型可能直接给出建议，也可能随意罗列优缺点，每次回答的思路都不太一样。有了决策澄清 Skill以后，系统会先判断这句话是否属于选择困难，再按照固定方法了解用户看重的目标、现实约束和不可接受项，帮助比较两个选项的取舍，最后把决定权留给用户。

这套方法可以拆成几个容易理解的部分：

如果继续使用工作场景来类比，Agent Persona 更像这位同事的性格与表达方式，Memory 是它记住的用户资料，Tool 是它可以使用的工具，而 Skill 则是完成某类任务时遵循的工作方法。后文讨论的 Skill 系统，就是负责管理这些方法如何定义、选择、授权、运行、记录和升级。

为什么需要 Skill 系统

理解了 Skill 的基本含义以后，我们再来看 AI 电子伴侣为什么需要一套可扩展 Skill 系统。这里既要说明能力如何定义，也要考虑它怎样选择、运行、授权、记录和升级。我们先把面向完整产品生命周期的架构梳理清楚，确认 Skill 与现有聊天系统的边界，以及控制面和运行面分别承担什么职责。

从这个角度再看第一阶段就非常清晰了。它不是一套孤立的关键词功能，而是整个架构里风险最低、最适合先验证的一层。

通用聊天模型可以回答很多问题，但能回答不等于能够稳定地按照某种方法完成任务。AI 电子伴侣运行一段时间后，会不断遇到重复而又有明确处理方法的场景。用户倾诉时，我们希望它先接住情绪，而不是立即给解决方案；用户纠结时，它应该帮助梳理约束和取舍，而不是随意替用户做决定；用户有目标却无法开始时，它需要把目标拆成真正可以执行的步骤。

到了群聊场景，多个 Agent 还要提供互补观点，不能围着同一句话重复表达。再把时间拉长，复盘、习惯跟进、关系修复、活动策划和创意共创也会逐渐变成稳定需求。

如果把这些方法全部堆进一个越来越长的 System Prompt，每轮请求都会携带大量无关指令，上下文成本会持续增加。不同场景的规则也容易互相干扰，模型很难判断当前究竟应该优先采用哪一种方法。

更麻烦的是，能力无法单独版本化、启用、禁用、评测和回滚。Prompt、工具调用、多步工作流与后台任务混在一起以后，权限边界会变得模糊；每增加一种能力都要继续修改聊天流程，维护成本也会越来越高。

Skill 系统解决的正是这个问题。我们把可复用的领域方法整理成具有明确元数据、触发条件、权限和生命周期的能力单元，只在真正需要时加载和执行。

什么适合成为 Skill

一个能力适合提炼成 Skill，通常应满足以下条件中的大部分：

1. 在多个 Agent、用户或聊天场景中可以复用。
2. 有相对稳定的触发语义和使用边界。
3. 有明确的执行过程，而不只是几句人格描述。
4. 输出质量可以通过示例、规则或指标评测。
5. 能够独立版本化，不需要频繁修改聊天主流程。
6. 需要按需加载，而不是每轮对话都应该存在。

边界同样重要。Agent 的名字、性格、语气和故事背景属于角色定义；用户姓名、偏好、经历和关系事实属于记忆系统；当前用户很难过这类一次性判断属于对话理解结果。单个 HTTP 请求或数据库操作只是 Tool 或基础设施能力，它们可能被 Skill 使用，但本身还不是一套完整方法。所有回复都必须遵守的安全要求则属于全局 Policy，其优先级必须高于 Skill。

我们可以用一句话记住这个判断标准：

边界与原则

职责与原则

在讨论具体实现前，我们可以先把 Skill 与现有聊天模块的职责重新梳理一下。Skill 不应该吞掉其他模块已经承担的工作：

现有 LangGraph 仍然负责聊天理解、路由和 Agent 发言选择。Skill 只是图中可以按需接入的能力，不需要把整张聊天图复制到每个 Skill 中。

渐进加载

Skill 内容按三个层级加载：

1. 元数据层：ID、名称、描述、适用场景、触发摘要，始终保持很小。
2. 指令层：Skill 被选中后才加载具体执行步骤。
3. 资源层：只有执行到对应分支时，才读取参考资料、模板、脚本或工具定义。

经过这样的拆分，我们就不用在每轮聊天中塞入所有 Skill 的完整 Prompt 和资料。

定义与运行分离

Skill Definition 描述它是什么，Skill Runtime 决定这一轮能否运行、如何运行，以及运行结果如何记录。

静态定义不能直接获得数据库、网络或后台任务权限。所有执行都必须经过统一的权限策略和运行器。

安全与角色优先

我们可以把指令优先级固定为：

1
全局安全与合规
2
  > 用户和资源权限
3
  > Agent 角色边界
4
  > 用户当前明确要求
5
  > 本轮回复策略
6
  > Skill 过程指令
7
  > 表达偏好与格式建议

Skill 只能补充过程，不能覆盖更高层约束。

默认确定性，必要时才使用模型路由

明确命令、场景限制、绑定状态和高置信规则都应该先通过确定性逻辑处理。只有候选 Skill 较多、表达又比较复杂，规则已经无法区分时，才让 LLM 在一个较小的候选集中做语义判定。

LLM 不应该直接从全部 Skill 中自由选择，更不应该通过输出任意名称获得未授权能力。

所有运行都绑定版本

Skill ID 表示稳定身份，Skill Version 表示一次不可变实现。会话和运行记录应保存确切版本，确保问题可以复现、旧会话可以继续、升级可以灰度和回滚。

状态与聊天记录分离

聊天记录描述说了什么，Skill Session 描述任务进行到哪里。例如旅行计划已经收集了日期但还缺预算，这是一种任务状态，不应该依赖重新解析全部聊天历史来恢复。

控制面与运行面

把前面的职责放在一起看，Skill 系统自然会分成控制面和运行面。

控制面负责管理能力，而不直接生成回复：

• Skill Catalog：技能目录和可发现元数据。
• Version Manager：版本发布、停用、灰度和回滚。
• Binding Manager：决定用户、Agent、群聊或会话启用了哪些 Skill。
• Configuration：保存不同绑定范围下的参数。
• Permission Manager：管理 Tool、数据和后台任务权限。
• Evaluation：保存触发样本、质量评测和回归结果。
• Admin UI：查看、配置和审计 Skill。

运行面在每次聊天或后台任务中工作：

• Context Builder：构造当前用户、Agent、会话和安全上下文。
• Candidate Resolver：根据绑定、场景和权限得到可用候选集。
• Selector：根据显式请求、规则、意图和语义选择 Skill。
• Policy Gate：检查权限、安全、频率、成本和冲突。
• Resource Loader：按需加载指令、参考资料和工具。
• Executor：运行 Prompt、Workflow、Tool 或 Background Skill。
• Session Store：保存多轮任务状态。
• Run Recorder：记录版本、选择原因、耗时、成本和结果。

总结

重新梳理下来可以看到，Skill 系统解决的是可复用任务方法的管理和运行问题，它不能替代 Agent Persona、Memory、Intent、Reply Policy、Tool 或 Safety Policy。我们只有先把这些职责边界划分清楚，后面的选择、权限和状态设计才不会互相侵入。

控制面负责目录、版本、绑定、权限和评测，运行面负责候选解析、选择、策略检查、资源加载、执行与记录。有了这张架构图，下一篇再继续定义 Skill 类型、领域实体、Manifest 和选择器，彼此之间的关系就会更加清楚。