三Agent协同实战：两个月摸索出的多Agent分工、交接与质检全记录

一、单Agent为什么撑不住了

今年8月起，我手上的AI编程活儿一下子多了起来：正职是帮两三家客户搭建内部系统，业余还维护着一款自己的产品。最初的做法很直接——开一个Claude Code会话，从头聊到尾，需求梳理、编码、修bug、写测试全部塞进同一个窗口。

头两周还凑合，到第三周就撑不住了。问题主要有三：其一，上下文越滚越大。一个中等规模的需求聊完，输入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年秋天还没到能托付生产的程度，确定性流水线才是当下的最优解。

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