三个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的双轨方案。常规增删改查任务交给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年秋天还没到能托付生产的程度，确定性流水线才是当前最优解。

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