多 Agent 协作的正确姿势

能力路由 + 单写入者 + 独立验收,顺便省一半 token

标题

《多 Agent 协作的正确姿势:能力路由 + 单写入者 + 独立验收,顺便省一半 token》

摘要

多个 AI agent 并行协作时,最常见的三个事故是:角色靠名字猜、文件互相覆盖、验收靠自说自话。本文分享一套已在生产环境稳定运行的编排协议——能力优先路由、单资源主写入锁、重要任务四级流水线、外部动作人工批准,以及一整套 token 成本控制策略。已开源,MIT 协议。

一、问题:三个 agent 一起干活,为什么总是翻车?

如果你同时把任务交给三个 AI agent,大概率会踩到这三个坑:

坑 1:角色靠名字猜。 叫 "coder" 的 agent 去做架构,叫 "reviewer" 的从不碰代码,谁也没在分配工作前验证过能力。名字是标签,能力是事实,两者经常对不上。

坑 2:文件互相覆盖。 两个 agent 同时编辑同一个文件,后写者静默胜出,diff 看不懂,改完的代码谁也不知道是哪一版。

坑 3:验收自说自话。 实现的 agent 自己测自己、自己宣布"做完了"。没有独立复核,等于考试自己给自己打分。

这三点我全踩过。踩完之后我把流程重写了一遍,开源成一套可配置的协作协议。

二、解法:四层设计

#### 1. 能力发现,不靠名字猜

任务开始前,每个 agent 提交一份紧凑的能力清单:模型、工具、读写权限、专长、成本等级、可用状态。角色分配(协调者、实现者、验证者、环境专家、领域评审)按证据打分,而不是按品牌名。

选最高分,再偏好低成本、低争用的 agent;平分时按可用性和历史证据,绝不按名单顺序。

#### 2. 单写入者:一个文件,一个主人

同一文件或资源在同一任务里只允许一个主写入者。评审者只能写隔离的产物——测试、报告、补丁——永远不覆盖主人的文件。不再有"静默的最后写入者胜出"。

需要换主人?走正式交接:旧主人、新主人、原因、基线、下一步检查,全部记录在案。

#### 3. 风险分级:routine / important / critical

"这是重要任务"这句话就足以把任务升级。你也可以在配置里定义你自己的触发规则。

#### 4. 验收门禁:没证据,就不许说"完成"

不允许在没有证据的情况下宣称 done / verified / deployed。验收必须覆盖:

门禁失败就把任务退回对应阶段,而不是悄悄"差不多得了"。

三、token 成本控制:省钱不省正确性

这一层很多人忽略,但对 API 账单影响巨大:

1. 一个规范任务包,而不是把完整聊天记录贴进每个 agent 的 prompt。

2. 有界输出:要求 agent 返回 JSON 或带必填字段的短报告。

3. 并行只读、串行写入:独立的只读检查并行跑,写操作和依赖工作保持串行。

4. 模型分层:便宜模型干发现、提取、格式化、机械检查;强模型只留给歧义、架构、对抗性复核和最终验收。

5. 缓存稳定结果:按 revision/hash 缓存发现与测试结果。

6. 停止阈值:所有验收标准都有新鲜证据后,停止探索性工作。

7. 绝不压缩:需求、权限、精确报错、代码、路径、URL、哈希、验收证据——这些一个字都不能省。

省钱的前提是永远不省正确性。

四、诚实的边界

这不是"保证不出错"的银弹。它是一套让错误可见、可回滚、可追责的控制:停止条件、可恢复基线、批准记录、残余风险报告。这已经是编排层能做到的极限——而且通常足以挡住前面那三个经典事故。

五、获取方式