三个Agent各司其职：我折腾两个月多Agent协作的分工、交接与质检手册

一、先说说为什么单Agent干不动了

今年8月开始，我手头的AI编程需求突然变多：主业是给两三个客户做内部工具，副业还有自己的一个小产品。一开始的玩法很朴素——一个Claude Code会话从头聊到尾，需求澄清、写代码、改bug、写测试，全在一个窗口里。

前两周还行，第三周开始明显不对劲。第一，上下文膨胀。一个中等需求聊下来，输入token轻松冲到8万以上，越到后面模型越"健忘"，前面定好的接口约定它能给你改回去。第二，角色串台。你让它既当架构师又当码农还当评审，结果就是它自己写的东西自己夸，bug reviewing 形同虚设。第三，成本失控。那个月光Claude Opus的账单就到了920刀，其中一大半是反复重读整个会话历史烧掉的。

我当时的判断：问题不在模型不够聪明，在于我把一个工程流程硬塞进了一个对话框。真实团队里没人会要求一个程序员同时是产品经理、开发和QA，那我凭什么要求一个Agent？

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

二、分工方案：三个Agent，一条流水线

我最后定下来的结构很简单，Planner、Executor、Reviewer三个角色，串行流水线：

Planner：用Claude Opus 4.5（现在叫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按验收条件打回，一来一回浪费2小时。后来我强制所有交接物结构化——任务卡YAML + Executor完成后必须回填"实现说明.md"，说明自己做了什么、偏离了什么、为什么。光是这一个改动，返工率从35%降到了12%。

坑二：Reviewer也被带偏。 有一阵子Reviewer通过率虚高，98%，我心里发毛。抽查发现Executor的实现说明写得花言巧语，Reviewer被带节奏，重点审"说明写得对不对"而不是"代码对不对"。修复方式粗暴但有效：Reviewer的prompt里加了一句硬性指令——"忽略实现说明，只对照diff和验收条件逐条核验"。通过率掉到78%，但抓出来的都是真bug。评审不能信口供，只看证据，这个道理对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年秋天还没到能托付生产的程度，确定性流水线才是当下最优解。

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