用 OpenClaw 跑多 Agent 有一阵子了，踩了不少坑，也慢慢摸出了一些门道。今天不聊概念，聊活法——四种协作模式，每种什么时候用、怎么用、容易栽在哪里。都是真实场景里磕出来的。先说一个前提
很多人觉得多 Agent 是为了解决上下文窗口不够用的问题。不是的。单个 Agent 的上下文窗口现在已经很大了，200K token 够干很多事。多 Agent 真正要解决的是两个更本质的问题：注意力稀释和角色污染。注意力稀释：你让一个 Agent 同时关注架构设计、代码实现、测试用例、文档编写，它每一项都做得马马虎虎。不是能力不行，是注意力分散了。角色污染：你让同一个 Agent 先写代码再审代码，它会对自己写的东西手下留情。这不是 bug，这是人性——或者说，是 LLM 模拟人性的副产品。模式一：主从协作 Leader → Workers
这是最直觉的模式，也是大多数人上手多 Agent 的第一站。一个 Leader 负责拆解任务、分配工作、收集结果。多个 Worker 各领一块活，干完交回来。Leader 做最终整合。什么时候用？
任务天然可分的时候。比如一个全栈项目，前端、后端、数据库迁移脚本，三块活互相之间依赖不强，各自干各自的。我之前做一个数据采集网关系统的原型，就是这个模式。Leader 拿到整体需求后拆成三个子任务：协议解析模块、数据清洗管道、上报接口。三个 Worker 各写各的，最后 Leader 把接口对齐，整合联调。实际怎么跑？
在 OpenClaw 里，Leader 本质上就是你的主 Agent 实例。它通过 claude -p 或者 tmux + PTY 的方式拉起 Worker。每个 Worker 拿到的是一个高度聚焦的 prompt——只包含它需要知道的上下文，不多不少。这里有个关键细节：给 Worker 的 prompt 要做减法，不要做加法。很多人恨不得把整个项目的 README、架构图、设计文档全塞进去。不要。Worker 只需要知道：我要干什么、接口契约是什么、输出格式是什么。多余的信息只会稀释注意力。容易栽的坑：
Leader 的整合能力往往是瓶颈。三个 Worker 各自写得挺好，但拼到一起发现接口对不上、命名风格不统一、错误处理逻辑矛盾。解法是 Leader 在分发任务之前，先生成一份「接口契约」——不是完整的设计文档，就是一个简洁的约定：函数签名、数据结构定义、错误码规范。Worker 必须遵守这个契约。这一步省不了，省了后面返工成本翻倍。模式二：链式协作 A → B → C
前一个 Agent 的输出是后一个 Agent 的输入，像流水线一样串起来。什么时候用？
任务有天然的先后依赖关系的时候。最典型的场景是「需求 → 设计 → 实现 → 测试」这条线。我在做翻译 App 的时候用过这个模式。Agent A 负责解析 PRD，输出结构化的功能点列表。Agent B 拿到功能点，输出 SwiftUI 的组件拆分方案和数据模型设计。Agent C 拿到设计方案，逐个组件实现代码。Agent D 拿到代码，写单元测试。链条上每个 Agent 都只看上一步的输出，不看原始需求。这不是偷懒，这是刻意为之——每个环节只处理自己该处理的抽象层级。实际怎么跑？
链式协作的关键在于中间产物的格式设计。每个 Agent 之间传递的不是自然语言的大段描述，而是结构化的、可解析的中间产物。我通常用 JSON 或者 Markdown 的固定模板。比如 Agent A 输出的功能点列表长这样：{ "features": [ { "id": "F001", "name": "热键触发悬浮窗", "priority": "P0", "inputs": ["全局快捷键事件"], "outputs": ["翻译悬浮窗实例"], "constraints": ["需要辅助功能权限"] } ]}
Agent B 看到这个结构，就知道该怎么接。如果你传的是一段散文式的描述，下游 Agent 要花大量注意力去「理解」上游在说什么，信息损耗非常大。容易栽的坑：
链条越长，误差累积越大。A 理解需求偏了一点点，B 在偏的基础上又偏一点，到 D 的时候已经面目全非了。实话说，链条超过 4 步我就不太敢用了。如果业务逻辑确实需要更长的链条，我会在中间插入一个「校验节点」——一个轻量 Agent，不干活，只负责对比当前输出和原始需求是否还在轨道上。偏了就打回去重来。还有一个务实的建议：链条的第一个 Agent 最重要。它的输出质量决定了整条链的上限。在这个环节多花时间打磨 prompt，比优化后面三个环节都有效。模式三：并行协作 A → {B,C,D} → A
Leader 把任务并行分发给多个 Worker，等所有 Worker 都完成后，Leader 收集结果做汇总。这看起来跟模式一很像，但有一个关键区别：模式一的 Leader 是做整合，模式三的 Leader 是做决策。什么时候用？
同一个问题需要多个视角的时候。比如技术选型——让三个 Agent 分别从性能、可维护性、团队学习成本三个角度去评估一个方案，最后 Leader 综合三个维度做决策。我做电池换电平台的月度调账系统时用过这个模式。同一套业务逻辑，让三个 Agent 分别生成三个实现方案：一个偏重数据一致性（悲观锁 + 事务），一个偏重性能（Redis 分布式锁 + 最终一致性），一个偏重可运维（异步队列 + 人工审批兜底）。Leader 拿到三个方案后对比取舍，最终选了 Redis 方案但加上了人工审批兜底。这个模式的精髓在于：让不同 Agent 带着不同的「偏见」去工作。这个偏见不是贬义词，是有意注入的视角约束。如果三个 Agent 都不带任何倾向，它们大概率会给出高度相似的方案，那并行就没意义了。实际怎么跑？
每个并行 Worker 的 system prompt 里要明确它的「角色立场」。不是简单说"你是一个注重性能的工程师"，而是要给具体的决策倾向：Worker B：你在做技术选型时，响应时间低于 50ms 是硬约束，其他都可以妥协Worker C：你在做技术选型时，新人上手成本是第一优先级，技术栈越主流越好Worker D：你在做技术选型时，线上出问题后的回滚和排查效率是核心关注点容易栽的坑：
Leader 在汇总阶段容易「和稀泥」——把三个方案的优点各取一点，拼出一个四不像。解法是在 Leader 的 prompt 里明确要求：你必须选择一个主方案，其他方案的优点只能作为补丁叠加，不能搞成三合一。决策要有取舍，取舍要有理由。模式四：对抗 / 评审协作 Builder ↔ Reviewer
一个造，一个拆。Builder 负责生成代码或方案，Reviewer 负责找问题、提改进意见，然后 Builder 根据意见修改，如此往复。什么时候用？
任何对质量有要求的场景。代码审查、方案评审、文档校对、甚至写文章。前面提到的角色污染问题，在这个模式下被彻底解决了。写代码的 Agent 和审代码的 Agent 是两个独立实例，上下文完全隔离。Reviewer 看 Builder 的代码时是「冷眼旁观」的状态，不会因为"这是我写的"而放水。实际怎么跑？
- Reviewer 审查，输出结构化的反馈（问题列表 + 严重程度 + 修改建议）
- 重复，直到 Reviewer 的反馈里没有 P0/P1 级别的问题
关键是给 Reviewer 设计好反馈格式。我通常用这个模板：[P0-阻塞] 并发场景下 Redis 锁没有设置过期时间，可能导致死锁→ 建议：加 30s 过期时间 + 看门狗续期机制[P1-重要] 错误处理只有 log，没有向上层抛异常，调用方无法感知失败→ 建议：定义业务异常类，关键路径必须向上传播[P2-建议] 变量命名 `data` 太笼统，建议改为 `rawMeterReading`→ 可选优化
Builder 只需要处理 P0 和 P1，P2 是可选项。这个分级很重要，不然 Builder 会陷入无限修改的循环——Reviewer 总能找到可以改进的地方，如果没有收敛条件，这个循环永远不会停。进阶玩法：多 Reviewer
一个 Builder 配两个 Reviewer，一个看功能正确性，一个看安全性和边界情况。两个 Reviewer 的反馈合并后发给 Builder。这比一个全能 Reviewer 效果好得多，原因还是注意力稀释——一个 Reviewer 同时关注正确性和安全性，两边都顾不好。拆成两个，各自深挖各自的维度。容易栽的坑：
循环次数。我的经验是上限设 3 轮。超过 3 轮如果还有 P0 问题，说明任务拆解有问题，或者 Builder 的基础 prompt 需要调整。死磕下去只会越改越乱。另一个坑是 Reviewer 的标准漂移。第一轮它说"命名不规范"，Builder 改了，第二轮它又觉得改后的命名也不好，换了个标准来挑。解法是在 Reviewer 的 prompt 里固定评审标准——写死一个 checklist，Reviewer 只能按 checklist 打分，不能自由发挥。混合使用才是常态
外层是主从协作：Leader 拆出协议解析、数据清洗、上报接口三个模块。每个模块内部是对抗协作：一个 Builder 写代码，一个 Reviewer 审代码，跑 2-3 轮收敛。模块整合阶段是链式协作：先跑集成测试 Agent（检查接口对接），再跑性能测试 Agent（检查吞吐量），最后跑文档 Agent（生成 API 文档）。三种模式套在一起，每个 Agent 的职责清晰，注意力聚焦，角色不会互相污染。几个实操层面的碎碎念
1. 日志和可观测性比什么都重要
多 Agent 一旦出了问题，排查难度是指数级上升的。每个 Agent 的输入输出都要落盘。我会让每个 Agent 在工作目录下生成一个 agent-log.md，记录它收到了什么、想了什么、输出了什么。出问题的时候顺着日志链条查，效率高很多。2. 先单 Agent 跑通，再拆多 Agent
不要一上来就设计复杂的多 Agent 编排。先用单 Agent 把整个任务跑通一遍，跑通之后你才知道哪里是真正的瓶颈、哪里值得拆分。过早拆分 = 过早优化，一样的道理。3. Agent 数量不是越多越好
每多一个 Agent，就多一层通信开销和一致性风险。能用 2 个 Agent 解决的问题别用 5 个。我目前单个任务很少超过 5 个 Agent 同时工作。4. 失败要有兜底
Worker 可能会跑飞、死循环、输出格式不对。Leader 必须有超时机制和降级策略。我一般设 Worker 的执行时间上限，超时直接 kill 掉重来。重试 2 次还不行就 Leader 自己上，降级为单 Agent 模式，总比卡死强。最后
多 Agent 不是银弹。它解决的是注意力稀释和角色污染，代价是引入了协调复杂性。这笔账要算清楚——如果单 Agent 能在 30 秒内搞定的事，就别折腾多 Agent 了。但对于那些真正复杂的、需要多视角、多阶段、多轮迭代的任务，多 Agent 的投入产出比是实实在在的。关键是想清楚：你的任务属于哪种模式，或者哪几种模式的组合。模式选对了，事半功倍。选错了，你只是在用更贵的方式写出同样质量的代码。
夜雨聆风
