三个Agent分工协作：两个月实战总结出的交接与质检经验

一、单Agent为什么撑不住了

今年8月起，我手里的AI编程活儿一下子多了起来：主业是帮两三个客户搭建内部工具，副业还运营着自己的一个小产品。最初的做法很直接——开一个Claude Code会话，从需求梳理到编码、调试、写测试，全都在这一个窗口里完成。

头两周还凑合，到第三周就明显扛不住了。首先是上下文越来越臃肿。一个中等规模的需求聊完，输入token轻松突破8万，模型越往后越容易"丢三落四"，之前约定好的接口它能给你改回去。其次是角色混淆。让它同时扮演架构师、程序员和评审，最终就是自己写的东西自己叫好，代码审查完全成了走过场。最后是成本飙升。那个月光Claude Opus就花了920美元，其中大部分都耗在反复重读整个会话历史上。

我当时就想明白了：症结不在于模型能力不够，而在于我把一整套工程流程硬塞进了一个对话框。现实中没有任何团队会让一个程序员同时兼任产品、开发和测试，那我凭什么要求一个Agent做到？

单Agent与多Agent方案的成本与耗时对比

二、角色划分：三Agent串行流水线

最终敲定的架构很简洁，Planner、Executor、Reviewer三个角色，串行推进：

Planner：采用Claude Opus 4.5（10月的模型矩阵中它依然是最强推理档位），职责只有一个——将模糊需求拆解为附带验收标准的任务卡。输出格式强制为YAML，含目标、约束、验收条件、涉及文件四个字段。
Executor：走Claude Sonnet 4.5 + DeepSeek V3.2 双轨。普通CRUD任务交给DeepSeek，它的API便宜得夸张，百万输入token才一块多人民币；复杂逻辑和跨文件重构则留给Sonnet。路由规则是写死在配置里的，靠关键词加文件数判断，谈不上什么智能调度。
Reviewer：通过Codex CLI运行GPT-5.2（OpenAI秋季发布的版本），关键在于它看不到Executor的推理过程，只能看diff和验收条件。这是刻意设计的——评审必须是个"局外人"，否则就是做样子。

任务卡的格式如下，可以直接拿去用：

task: 订单导出增加CSV格式
goal: 用户可将订单列表导出为CSV
acceptance:
  - 导出文件带BOM头，Excel打开不乱码
  - 字段顺序与页面一致
  - 单测覆盖率不低于80%
files: [src/exporter.py, tests/test_exporter.py]

三、交接与质检：最容易翻车的两个环节

分工方案谁都能画出来，真正棘手的是交接。我踩了三个坑，每一个都在烧钱。

坑一：口头交接，信息全丢。 最初版本里，Planner输出自然语言任务描述，Executor直接读取。结果"页面一致"这种模糊表述，Executor理解成按字母顺序排列字段，Reviewer依据验收条件打回，一来一回白白浪费两小时。后来我要求所有交接物必须结构化——任务卡YAML加上Executor完成后强制填写的"实现说明.md"，写明做了什么、哪里偏离了、原因是什么。仅这一项改动，返工率就从35%降到了12%。

坑二：Reviewer被带节奏。 有段时间Reviewer通过率异常偏高，达到98%，我心里直发毛。抽查后发现Executor的实现说明写得天花乱坠，Reviewer被牵着走，重点去审"说明写得对不对"而非"代码对不对"。解决办法简单粗暴但管用：在Reviewer的prompt里加了一条硬指令——"忽略实现说明，只对照diff和验收条件逐条核验"。通过率随即跌到78%，但抓出来的全是真问题。评审不能听口供，只看证据，这个原则对Agent同样成立。

坑三：三个Agent三套格式。 Executor交Python，Planner交YAML，Reviewer输出Markdown评审报告，起初我还得手动把它们拼成一条记录。后来统一了一层轻量契约：所有交接物放入约定目录，文件名用任务ID，评审报告必须引用验收条件编号（如"AC-2 不通过"），这样grep一下就能追溯。听着像废话，但缺了这层约定，多Agent就是三个各说各话的哑巴。

三Agent流水线的交接流程

四、量化效果：钱花在哪儿，省在哪儿

完整跑了两个月（9月到10月上旬，共42个需求），数据如下：

成本：月账单从920美元降至380美元。具体拆解，Executor将约六成流量切给了DeepSeek，这部分月成本仅约90块人民币；Opus只负责规划，token消耗下降了八成。Kimi K2我也试过放进Executor，中文注释生成质量确实更好，但工具调用稳定性稍差，最终保留了DeepSeek，Kimi只在写文档时出场——说句得罪人的话：给国产模型排座次没意义，按任务路由才是真省钱。
耗时：单个需求平均交付从4.5小时压缩到1.6小时，接近2.8倍。提升的关键不在"写得更快"，而在"返工更少"。
质量：Reviewer在合并前拦截了90%以上的缺陷，上线后回滚次数从每月5次降到1次。
Token：单次任务平均输入从约85k降到22k，因为每个Agent只读自己该读的内容，不必反复咀嚼整个会话历史。

质量控制的闭环机制

值不值得这么折腾？我的判断是：如果你每月AI编程账单超过300美元，或者每周需求超过5个，这套分工两周内就能回本，值得投入。反之，如果你只是写写脚本、改改文案，单Agent配合好的prompt就足够了——多Agent是有管理成本的，任务卡维护、交接契约、评审规则，这些本身就是工作量。网上鼓吹的"Agent swarm自动协作"我试过两个框架，一半是智商税：演示视频里无所不能，真上生产全是幻觉接力。先用确定性流水线把基本功打扎实，比追swarm热点实在得多。

结尾：一份可直接照搬的清单

先拆分再谈多Agent：一个会话超过5万token还频繁"健忘"，才是拆分的信号，别为拆而拆。
角色物理隔离：评审Agent绝不能看到执行Agent的思维链，只看diff和验收条件。
交接物必须结构化：YAML任务卡 + 实现说明 + 带编号引用的评审报告，缺一不可。
按任务路由模型：重规划给Opus，复杂执行给Sonnet，批量执行给DeepSeek/Kimi，评审换一家厂商的模型以防"一家人护短"。
通过率虚高要警惕：Reviewer通过率超过95%大概率已失效，宁可它严格到烦人。
别碰花架子：swarm、自主协商那一套，2026年秋天还没到能托付生产的程度，确定性流水线才是当下最优解。

说明：本文数据来源为公开行业报告综合整理，部分成本与耗时数值为估算仅供参考。