多 Agent 系统上线前逐条核对的 3 张清单：触发词别超 4 个、共享约定而不是共享状态、给失败留兜底。Agent Skills 入门篇的进阶实操。
先说结论
Agent Skills 是 9 月 23 日那篇文章讲的概念（文末有链接），这篇是它的进阶篇：往前走一步，把一套 Multi-Agent 的准备工作拆成 3 个清单，照着做就行。
清单一：把重复动作翻译成「触发词 + 步骤」
多 Agent 协作最容易出事的地方，是每个 Agent 都按自己的理解干活。你让 A 写稿、让 B 审稿，A 写出来的东西 B 不认识，来回三轮也没对齐。
解法是把协作约定写成「触发词 + 步骤」的形态。触发词是固定的短语，步骤是一行一条、可核对的动作。举例：
触发词：开始审稿
步骤：
1. 找出事实性陈述，逐条标注来源
2. 标点、错别字单独列一行清单
3. 判断是否有三段式节奏或万能结论，有就标注
4. 结尾「待确认」空行留给作者，不自行改写
这套格式跟 Agent Skills 的 SKILL.md 是同一个思路：一样的入口结构、一样的分步动作，只是你把它用在多个 Agent 之间，而不是一个助手身上。不存在标准答案就写「不存在」，可以核对的动作就写「可核对」，一视同仁。
一个实战提醒：触发词别超过 4 个。我一开始配了 8 个，一周后连我自己都记不清哪个是什么，全废了。稳定下来之后，常用的其实就 3 个：配置、审稿、发布。
清单二：准备好「共享约定」，而不是「共享内存」
第二个清单针对数据。多个 Agent 共享状态，最常见的坑是人人都去读改同一份「记忆」，改坏了没人知道谁改的。
更稳的形态是共享约定文件而不是共享现场状态。约定文件的内容是「我们怎么做这类事」：每个 Agent 的动作边界、产物放哪里、命名规则。现场状态（今天跑到第几步）反而应该各自保存，不要让 A 读 B 的进度。
说个上图没写的重要原因：状态沿途共享看起来省事，但一出错就查不出来源头。约定文件共享，进度各自保存，错误归因就变成了读文件，五分钟闭眼可查。
这里有个顺手的副产品：约定文件写好了，即使最近换模型、换工具，约定不用重写。这也是 Agent Skills 思路的另一重价值：流程和工具解耦。
清单三：留一个「失败兜底」角色
第三个清单最容易被跳过，但真实运行中最重要：设计流程时假设每个 Agent 都可能不回话、干错活、或干了没人知道。
兜底角色要回答三个问题：
- 超时多久算失败？（哪怕说不清楚也要有个默认值）
- 失败后谁来接手？（可以就是你自己，写明即可）
- 完成的产物最后由谁确认？（没有确认方的流程等于没有完成态）
这一步的隐含价值：一个故障有兜底的多 Agent 系统，反过来也让单 Agent 工作流变得更可靠。因为兜底的设计过程会强迫你梳理「什么算完成」「什么算失败」，这两个问题在单 Agent 场景下同样成立。
做与不做
最后是一张快速自查表：
| 做 | 不做 |
|---|---|
| 触发词控制到 4 个以内 | 起步就上 8 个触发词试图覆盖所有场景 |
| 共享约定，各自保存进度 | 所有 Agent 共改一份「全局记忆」 |
| 每个流程有兜底和确认方 | 默认「都跑通」然后排障靠聊天记录考古 |
| 写「不确定」比编一个答案好 | 要求 Agent 100% 确定所有事实 |
这篇比概念篇更偏实操。但说实话，我自己也还是入门阶段。等哪天把三个清单都真跑过一轮，我才知道哪一条在真实场景里最重要。如果你也在搭多 Agent 流程，欢迎留言说说卡在哪一步。