三人分工的Agent流水线：两个月多Agent协作的踩坑、联调与验收全记录

一、单Agent为什么撑不住了

今年八月起，我手上的AI编程活儿一下多了起来：一边是给两三个客户做内部工具，一边还要顾着自己的小产品。最初的做法特别简单粗暴——开一个Claude Code会话，从头聊到尾，需求梳理、编码、修bug、补测试，全挤在同一个窗口里完成。

头两周还凑合，到第三周就开始出问题了。首先是上下文越滚越大。一个中等规模的需求聊下来，输入token轻轻松松突破8万，而且越往后模型越容易"断片"，早先敲定的接口约定它转头就给你改掉。其次是角色混在一起。你让同一个它既做架构设计又写代码又当审核，最后就是自己写的东西自己叫好，代码评审完全成了走过场。第三是成本压不住。那个月Claude Opus的账单直接飙到920美元，其中相当一部分是反复重读整个对话历史白白烧掉的。

我当时的结论是：毛病不出在模型智商上，而是我把一整套工程流程硬生生塞进了一个聊天框。现实中哪个团队会让一个程序员同时干产品、开发和测试的活？那我凭什么要求一个Agent全包？

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

二、角色划分：三个Agent串成一条线

我最终敲定的架构不复杂，Planner、Executor、Reviewer三个角色，串行排列：

Planner：跑Claude Opus 4.5（十月初的模型阵容里，它依然属于推理能力最强的那一档），任务只有一个——把含糊的需求拆解成带验收标准的任务卡。输出我强制用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%，但抓出来的全是真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年秋天还没到能托付生产的程度，确定性流水线才是当下的最优解。

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