从工具调用到领域 Skill：让智能体能力可复用、可治理
发布时间：
在智能体项目中，最容易出现的误区之一，是把“能调用工具”理解为“具备领域能力”。工具通常只是查询、保存或调用接口等原子动作；真实业务任务还包含前置条件、执行顺序、异常分支、人工确认与交付标准，这些知识需要由更高层次的 Skill 承载。
Tool 与 Skill 的边界
Tool 应尽量小而确定：输入明确、输出稳定、副作用可描述。Skill 更像一份领域操作手册，它需要说明：
- 什么情况下使用这项能力；
- 执行前需要收集哪些事实；
- 多个工具应以什么顺序调用；
- 哪些步骤必须由用户确认；
- 成功、失败与等待输入如何判定；
- 最终必须交付哪些产物。
因此，Skill 不只是提示词。一个可维护的 Skill 通常包含说明文件、执行脚本、按需加载的参考资料和关键分支测试。说明文件负责工作流与边界，脚本承担确定性操作。
将澄清与执行分开
复杂需求往往不完整。如果模型一边追问一边执行，很容易在信息不足时产生副作用。实用的设计是拆成两个阶段：
- 澄清阶段： 只收集事实，不调用有副作用的工具；
- 执行阶段： 用户确认后，按冻结的计划执行。
澄清结果最好是结构化字段，每项标记“已确认、待补充、可选”。进入执行阶段时，将用户明确跳过的字段传递给下游，避免不同 Agent 重复追问。
用显式状态替代隐式记忆
长流程不能只依赖模型上下文。可以为任务维护计划、进度、产物、问题和已确认事实。状态由确定性代码读写并带版本号。即使上下文被裁剪、任务跨轮恢复或执行 Agent 被替换，流程也能从可靠状态继续。
为流程设置确定性终点
如果完成条件完全由模型判断，系统容易提前结束。例如活动创建只有在保存成功、体验环境可访问、说明书已生成后才能完成。
职责应明确分开：
- LLM 负责理解意图、生成内容和处理模糊信息；
- 规则负责权限、状态转换、交付完整性与副作用边界。
版本化与治理
Skill 应像代码一样治理：使用 Git 评审规则变化、锁定运行版本、限制脚本权限、校验关键输入输出，并用回归样本记录失败案例。还应把“文档存在、配置启用、测试通过、生产验证”分开描述。
领域 Skill 的价值，不是让模型看起来更聪明，而是把散落在人脑和文档中的流程知识，转化为可版本化、可测试、可审计的工程资产。