OpenClaw 多 Agent 协同：把“靠感觉”变成可验收的协作流水线

你有没有遇到这种崩溃场景：

• 让多个 Agent 一起干活，最终结果“看起来挺像那么回事”。
• 真拿去用，Bug、漏项、边界条件一堆。
• 追责时全靠猜：到底是需求没讲清，还是实现偷懒，还是审查走过场？
• 聊天断了、工具重启了，大家又开始“重新解释一遍需求”。

OpenClaw 的多 Agent 协同原则，核心就一句话：把聪明变成可控的流程。不靠感觉，不靠运气，靠“材料包 + 闸门”。

0. 你要搭的不是“群聊”，是流水线

把多 Agent 当成一条生产线更合适：

• 每个节点只交付自己的“可检查产物”。
• 上一节点的产物不过闸门，下一节点不准开工。
• 任何一步都能抽检、回滚、重跑。

下面这套分工很实用（字母只是代号，你也可以改名）：

• A：验收标准（什么叫做成了）
• B：事实/约束/边界用例清单（什么必须满足，什么会踩雷）
• D：实现 + 最小测试（能跑起来的东西 + 最基本的验证）
• E：红队挑错 + 最小修复建议（专门找茬，不负责写新功能）
• F：最终交付 + 验证步骤（交付包怎么验收，一步步可复现）

1) 步骤级可验证：每个节点都要“材料包”📦

多 Agent 失败的常见原因：大家都在输出“看起来对”的文字。

OpenClaw 直接反过来：每一步都产出可检查的材料包。你想验哪一步，就抽查哪一步。

A 节点材料包（验收标准）

A 不写“我觉得差不多”，要写能勾选的清单：

• 目标是什么（1 句话）
• 必须交付的内容列表（文件/接口/文档/截图）
• 验收口径（输入是什么、输出长啥样、允许误差是多少）
• 范围边界（明确“不做什么”）

典型检查方式：字段齐不齐？有没有可执行的验收动作？有没有把“不做什么”写死？

B 节点材料包（事实/约束/边界用例）

B 的任务是把“坑”提前摆到台面上：

• 事实清单（已知信息，带来源/引用）
• 约束清单（时间、权限、成本、性能、合规、依赖）
• 风险清单（可能失败的方式）
• 边界用例（最容易翻车的输入/场景）

典型检查方式：边界用例够不够狠？有没有把“最坏情况”列出来？引用有没有对上？

D 节点材料包（实现 + 最小测试）

D 只关心一件事：能不能跑。

• 实现方案（结构图/模块说明/关键算法）
• 最小可用实现（能跑通主流程）
• 最小测试（至少覆盖：正常输入 + 1 个边界用例）
• 失败模式说明（失败时怎么报错、怎么降级）

典型检查方式：测试有没有？边界有没有覆盖？失败时是不是“沉默失败”？

E 节点材料包（红队挑错 + 最小修复）🧨

E 的定位是“找茬专员”，不是“帮你润色的好同事”。

• 挑错清单（按严重程度排序）
• 复现路径（怎么触发这个问题）
• 影响范围（会坏到什么程度）
• minimal_fix（最小修复动作：改哪一行、补哪个字段、加哪个测试）

典型检查方式：问题有没有复现步骤？修复是不是最小闭环？有没有把锅甩给“建议优化”？

F 节点材料包（最终交付 + 验证步骤）

F 负责让交付变成“拿来就能验”：

• 交付清单（文件/链接/版本/配置）
• 验证步骤（复制粘贴就能跑的命令/操作）
• 验收对照表（对应 A 的验收标准逐条打勾）

典型检查方式：能不能在一台新机器上照做复现？有没有把 A 的每条验收逐个对齐？

2) 排查可定位：结果翻车时，能一秒钟问对问题

传统玩法是“结果不对 → 从头猜一遍”。

OpenClaw 是“结果不对 → 定位到节点”。你只需要问：

是定义错？证据不全？推理跳步？可行性没覆盖？红队漏检？

常见翻车 → 直接定位

• 做出来的东西不符合预期

  • 高概率：A 的验收标准写错/缺失，或范围边界没写清

• 方案听着很对，一落地全是坑

  • 高概率：B 的约束/风险没列全，或 D 没写失败模式/可靠性策略

• 明明有明显问题，红队没指出来

  • 高概率：E 的输入没隔离（被上下文带偏）
  • 或闸门太松（缺字段也放行）

这套定位方式很爽。因为你不用“重写提示词求好运”，你只改出问题的那一段。

3) 可复盘可进化：失败要落到 FailureCode + minimal_fix

你要的不是“这次修好了”，而是“下次更不容易坏”。

建议你每次失败都写两行：

• FailureCode：失败类别
• minimal_fix：最小修复动作

FailureCode 参考表（直接拿去用）

• A-CRITERIA-MISSING：验收标准缺字段
• A-SCOPE-UNCLEAR：范围边界不清
• B-CONSTRAINT-MISSING：约束/依赖漏列
• B-EDGECASES-THIN：边界用例太少/太软
• D-NO-TEST：没有最小测试
• D-FAILMODE-MISSING：失败模式没写
• E-REDTEAM-LEAK：红队被上下文污染
• E-GATE-TOO-SOFT：闸门要求太松
• F-VERIFY-NOT-REPRODUCIBLE：验证步骤不可复现

minimal_fix 要“单变量”

一次只改一个点，才叫迭代。

• 补一个字段
• 加一条边界用例
• 强化一个闸门规则
• 把红队隔离成独立代理
• 增加一个最小测试用例

别每次都全量重写。那不是进化，是抽奖。

4) 可恢复：对话断了也能接着干（靠任务卡/真相源）

多 Agent 最怕的不是慢，是“断线”。

解决办法很简单：把任务状态写进任务卡（真相源）。

可以从一个本地文件开始，比如 task_card.md 或 task_state.json。

任务卡建议字段

• 任务目标（一句话）
• 当前节点（A/B/D/E/F）
• 每个节点的产物链接/粘贴区
• 闸门状态（通过/未通过）
• 缺失项列表（缺哪个字段、缺哪个引用、缺哪个测试）
• 最近一次 FailureCode + minimal_fix

对话断了、工具重启了，打开任务卡就知道：

• 现在卡在哪一步
• 上次闸门过没过
• 是重试还是回滚
• 还缺哪些信息

你就不会陷入“再讲一遍需求”的地狱循环。

5) 防抄近路：把聪明关进笼子里

Agent 越聪明，越会走捷径。

OpenClaw 的做法是：每个角色只交自己那份材料包。

闸门一收紧，捷径自然走不通：

• 缺验收标准 → A 不过闸
• 缺边界用例 → B 不过闸
• 缺测试 → D 不过闸
• 缺引用/事实来源 → B 不过闸
• 红队没复现路径 → E 不过闸

你不是在“求它认真点”，你是在用流程逼它认真。

一套能直接落地的闸门规则（复制就能用）✅

你可以把下面这段当成每轮的“通关条件”。

A 闸门（验收标准）

• [ ] 有交付清单
• [ ] 每条验收可执行（能操作、能判断）
• [ ] 写清楚“不做什么”

B 闸门（事实/约束/边界）

• [ ] 事实有来源/引用
• [ ] 约束清单覆盖：资源/权限/依赖/性能（按你的任务删减）
• [ ] 至少 5 条边界用例（越高风险越多）

D 闸门（实现/最小测试）

• [ ] 主流程跑通
• [ ] 至少 2 个测试：正常 + 1 个边界
• [ ] 写了失败模式（失败时返回什么/怎么告警）

E 闸门（红队）

• [ ] 每个问题都有复现步骤
• [ ] 每个问题都有 minimal_fix
• [ ] 红队输入隔离（不看 D 的“解释”，只看交付与需求）

F 闸门（交付/验证）

• [ ] 验证步骤能在干净环境复现
• [ ] A 的验收标准逐条对齐打勾

示例：你在做一个“自动生成周报”的多 Agent 流程

• A 写：周报必须包含「本周完成」「风险」「下周计划」，输出 Markdown；给 2 个示例输入输出；明确“不做排版美化”。
• B 列：数据来源（Jira/飞书/手填）、权限限制、字段缺失怎么办；边界用例放狠一点：空数据、重复任务、超长文本、时区混乱。
• D 做：脚本跑通；最小测试用一条正常数据 + “空任务列表”。
• E 找茬：空数据时是不是输出乱码？重复任务有没有去重？时区是不是把周一算成上周？给 minimal_fix：加一个空数据分支 + 加一个测试。
• F 打包：仓库结构、安装命令、运行命令、验收对照表。

跑完这一轮，你会明显感觉：每个 Agent 都“被迫交作业”，而不是“被鼓励发挥”。

避坑清单（踩过的人都懂）

• 闸门写得太文学：比如“输出要清晰、要专业”。这种等于没写。
• 红队和实现共享上下文：红队看了实现者的解释，很容易被带节奏。
• 只测正常路径：边界不测，等于把爆炸留给用户。
• 没有任务卡：断一次就回到原始社会。
• 每次失败都全量重写：你以为在迭代，其实在买彩票。

你可以怎么开始（成本最低的版本）

• 今天就用一个 task_card.md 开工。
• 严格要求 A/B/D/E/F 每个节点交材料包。
• 把闸门规则贴在任务卡顶部。
• 每次失败记录一条 FailureCode + minimal_fix。

跑个 3 轮，你会发现协作稳定性上来得离谱：你不需要更“会写提示词”，你需要的是一套能卡住捷径的流程。😄