多 Agent 协同：从"一个人硬扛"到"一个团队作战"

昨天交付一份人格测评总表，因为漏了独立评审这一步，上线后才发现问题——如果交付前安排一个评审者按清单过一遍，这个问题根本不会漏出去。之前 dg 幻灯片项目用了"一人做、三人按不同维度审"的模式，揪出了 dev 自己完全没意识到的问题。这篇文章，就是这套多 Agent 协同方法论的完整沉淀：什么时候该用、怎么分工、怎么评审、怎么控制成本。

什么时候用多 Agent

先说结论：多 Agent 约为单 agent 的 3–10 倍 token 消耗（Anthropic 官方口径；以"聊天"为基准时约 15 倍）。本质是"花钱买覆盖面"，只值得用在高价值任务。

用：重要事项/项目——技术文章发布前评审、项目上线前测试验收、表单构件类交付物、任何"错了代价大"的事。

不用：日常小事、一次性简单任务；各 agent 必须共享同一上下文、任务间强依赖的场景（如大部分编码任务）。

按复杂度定投入：简单查证派 1 个 agent；中等对比派 2–4 个；复杂调研可以上 10+ 个。反模式：小问题派 50 个子 Agent，烧 token 还互相干扰。

三种协同模式

模式一：生成-评审（Generator-Critic）——通用默认

一个模型负责做（生成初版），另一个模型负责挑刺（按验收单评审），循环直到验收单全过。我们实测中这个模式揪出的问题最多。

模式二：测试-验收（Tester-Acceptor）——项目场景

测试者实测跑通全流程、记录问题；验收者按验收单逐项验收，给通过/不通过。关键要求：测试和验收必须由不同模型担任。

dg 幻灯片项目就是这个模式的完整实例：planner 做计划和基础设施 → dev 开发 → 三个 tester（布局/动画/美观）并行评审 → dev 修 → tester 重测 → 主 Agent 终验。

模式三：并行双评审——高风险事项

两个评审者用不同外部大模型独立评审同一交付物，取更严格的一方为准。有条件通过的问题必须修完再进入下一轮。

多评审者冲突仲裁：多个评审维度意见打架时，预先定好优先级，不让执行者自己猜。dg 项目里的仲裁规则是：布局 > 美观 > 动画。

六条铁律

1. 验收单先行：评审开始前，先有书面验收清单。没有验收单的评审等于瞎评审。
2. 模型隔离：评审者必须用不同外部大模型，避免同源偏见——同一家模型容易犯同一种错，互相看不出来。
3. 职责边界一句话：每个参与的模型都要能说清"它负责什么、别人不许碰什么"。说不清等于分工失败。
4. 评审与执行权限分离：评审者只读不写、只出报告；只有执行者能改产物。dg 项目里三个 tester 全是"代码只读"角色，这是职责边界最彻底的执行方式。
5. 最小权限：子 Agent 只给完成任务必需的权限——能读什么目录、能不能写文件、能不能联网、能不能调付费接口，派活时一次写清。默认不给凭证、不给删除权限。
6. 人在环：固定最后一关是用户亲自验收。模型审完，用户再看一轮。

标准流程（七步）

1. 想清楚：任务复杂度、派几个子 Agent、角色定义、用什么工具。先定再派，边派边想是分工失败的主因。
2. 定验收单：明确交付标准，每条必须能无歧义判定 PASS/FAIL。
3. 派角色：写清职责边界和投入预算。授权四要素缺一不可：目标、输出格式、工具/信息源、任务边界。
4. 试跑（推荐）：拿 1 个子任务试跑，拿到真实的 token 和时间数据，再决定全量投入。
5. 执行：各模型独立干活，评审类任务互相不可见，避免干扰。
6. 汇总：收结论，冲突处标出，取严格方。汇总的本质是压缩——子 Agent 是智能过滤器，只交精简结论，不回传全文。
7. 用户终验：用户看汇总加关键原文，拍板。评结果不评路径——看终点对不对，别纠结过程是不是预设的那条。

模型选用与成本控制

模型-角色匹配：贵模型用在"决策位"（生成、终审），便宜模型用在"执行位"（测试、批量跑）。评审链相邻两环必须模型隔离。实测：强 lead + 弱 subagent 组合效果超单个强模型 90.2%。

具体来说：生成者选该领域最强的（代码选代码强的，中文写作选中文语感好的）；评审者选推理强的，且必须和生成者不是同一家；测试者用便宜、快、听话的轻量模型，但验收单判定标准必须写死（轻量模型容易"差不多就过"）。

成本估算：总 token ≈ Σ(每个 agent 单轮输入 × 预计轮次) + 协调开销，再用 3–10 倍做合理性校验。省钱三招：强弱搭配、限制每跳上下文增量、结果压缩。

硬预算 + 熔断：每个 agent 设 token/轮次上限，超限转人工或降级。靠 prompt 让模型"自己省着点"不可靠（实测 91.5% 会超预算），必须用硬门。

失败恢复

先分类再处置：

• 超时/429/5xx（基础设施类）→ 可重试
• 输出格式错乱 → 带错误信息重新提示
• 认证失效/权限/政策拦截 → 重试无用，直接换路或转人工
• 写操作超时但结果不明 → 先核实外部状态再决定，绝不盲重试（防重复扣款/重复写入）

重试策略：服务商超时最多 3 次（指数退避 2s→4s→8s）；429 最多 4 次（遵守 retry-after）；格式错误最多 2 次（多了说明 prompt 本身有问题）；5xx 走熔断切换备用模型。

四级升级阶梯：重试耗尽 → 换策略 → 降级 → 转人工。循环检测：连续 5 次相似动作无进展直接升级。

十个常见坑

1. 评审者看到生成者的过程——评审必须独立，只给终稿和验收单，不给中间稿
2. 验收单模糊——"写好一点"不是验收单，"标题不超 20 字、无违禁词"才是
3. 模型串通——同一任务不要让有上下文关联的两个模型互相评审
4. 跳过用户终验——再急也要走完最后一关
5. 迭代没有逃逸机制——定个轮次上限（如 3 轮），超限升级人工裁决，别无限循环烧 token
6. 只验单元不验整体——分单元评审完，加一轮交付物整体终验
7. 评审缺"内容正确性"维度——别只评审形式，内容本身的对错要单独列一维
8. 任务状态没人更新——状态表谁建谁更新要写死
9. 重测漏掉新问题——重测验旧项时，加一次快速全量扫描
10. 无护栏的迭代会失控——子 Agent 数量、搜索轮次设硬上限

总结

多 Agent 协同的核心就三句话：

1. 花钱买覆盖面：3–10 倍 token 换的是"一个人想不到的盲区"，只用在错了代价大的事上
2. 评审必须独立：不同模型、只读不写、按验收单打勾，缺一不可
3. 人在环是底线：模型审完，用户再看一轮，不跳过

这套方法论已经在我的技术文章发布流程里落地：写完初稿后，会安排独立评审按检查清单逐项打勾，改完再发。

---

以上，全文完。

如果这篇文章对你有帮助，欢迎关注我的博客，更多实战笔记持续更新中。