解释定义skills,如何构建agent的skills,多agent该如何协调

提问

解释定义skills,如何构建agent的skills,多agent该如何协调

回答

这三个问题由浅到深，我逐个说明。

一、Skill 是什么

一句话：把「遇到某类事该怎么一步步做」从提示词里提取出来，保存成文件。通常是一个 SKILL.md 加脚本、模板、参考资料，放在固定目录里，agent 需要时才读取进来。

它的本质是经验资产化。提示词里的流程是隐性的，改一次要全文重写、没法版本管理、没法被多个 agent 共用；写成 skill 之后，它就是仓库里的一个文件，可以 review、可以 diff、可以回滚,也能被不同的 agent 加载同一份。

几个关键性质，别看错：

skill 没有自己的上下文和自主权，它是被 agent 加载进来的，是「手艺」，不是「人」。
skill 是可组合的，一个 agent 可以带好几个 skill，按当前任务挑。
skill 会过期。模型升级后，一部分 skill 会被模型本身吸收掉（以前要手写「先读文件再改」的流程，现在模型自己就会），剩下的一部分会和别的 skill 重复、冲突。所以要定期做清理，不是越多越好。

二、怎么构建一个 agent 的 skill

按这个顺序做，别跳：

第一步，从真实失败中提取,不要从「我觉得应该有这么一章」开始。你手上有一次具体的跑歪记录，才有资格写 skill。

第二步，只写一个完整任务。切分标准是「这件事能被做完并被验收」，而不是「一个概念」。比如「取数 → 对齐时间轴 → 处理停牌 → 输出统一结构」是一件事；拆成「取数 skill」「清洗 skill」就是按概念切，用起来会互相调用、反而更乱。

第三步，固定输入输出的结构。这是 skill 里最值钱的部分。写清楚：进来的是什么（哪个周期的数据、账户状态是什么）、出去的是什么（做不做、做多少、依据是什么）。靠对话传递结果是最容易返工的做法。

第四步，把验收条件写进 skill 里。什么叫「做对了」要能机械判断——产出格式对不对、关键字段有没有、异常有没有记录。不然 agent 自己觉得干完了就干完了。

第五步，先只被一个 agent 用。等它稳定了、被第二个场景需要了，再考虑通用化。过早抽象是所有 skill 库腐坏的开头。

反例也要知道：一个 SKILL.md 写了两千行、内部全是「如果 A 走这套，如果 B 走那套」，这时它不是 skill 写得好，是应该拆了。拆分信号只有一个——加条件分支时两边需要的输入输出结构不一样。

三、多 agent 怎么协调

协调的方式只有两种：共享状态，或传递消息。落到工程上，99% 做对的多 agent 系统用的都是「主从 + 文件契约」，而不是 libre 聊天。

具体机制四层：

第一层，编排者只做调度。主 agent 接指令，拆成子任务，定依赖顺序，派给 subagent，收结果，判断这轮算不算完成。它不碰数据和细节，上下文保持干净——这是它能跑长任务的原因。

第二层，subagent 带独立上下文干活。每个 subagent 有自己全新的上下文窗口、自己的工作目录，干完只回传摘要和产物的路径，不回传中间过程。这是 multi agent 唯一真实的收益来源：主上下文不被污染。

第三层，协调靠契约文件，不靠对话。上游写一份固定字段的结果文件，下游只读这份文件。字段定错了会反复返工，字段定对了 skill 内部怎么改、agent 换成几个都接得上。这层比 agent 有几个重要得多。

第四层，审查者必须独立上下文。写的人和批的人不能是同一个上下文，否则就是自己给自己打分。审查者只看结果文件和原始数据，不看生成过程的对话。

协调时最容易踩的三个坑：

一是按角色拆。产品经理 agent、架构师 agent、程序员 agent，这是想象中的组织架构；实际是在一个上下文里自问自答，收益很小还会互相强化幻觉。按「谁必须有不同的上下文」拆才对。

二是层数堆太多。两层（编排加干活）通常够，最多三层。层数越多，信息损耗越大，某个子任务跑偏你定位不到。

三是以为多 agent 自带正确性。它不带。准确率全靠机制兜住：生成和审查分角色、每轮自动跑测试和 lint，失败就打回、以契约文件为准而不是以某次对话为准、给结论必须附证据。

还有一点要提醒：判断某个东西该做成 skill 还是 agent，只问三条——需不需要独立审查、是不是耗时长且能并行、上下文装不装得下。三条都不满足，写 skill。

要不要我按你手上那套 pa 系统，把这三层各落一版具体文件结构出来？