上个月接了个项目,帮一位做跨境电商的朋友把商品详情页生成工具做一次彻底重构。原来的模板脚本要升级成一条完整链路:标题撰写、卖点提炼、FAQ生成、多语言翻译,再加上SEO检查和格式导出,五个环节彼此咬合。规模谈不上大,但麻烦——环节多、依赖多。
起初我想偷懒,直接开了一个Claude Code的Opus会话,丢过去一句"全部你来"。结局各位大概也能猜到:跑了47分钟,消耗约230万token,账单11.2美元,交付结果我人工抽检,五个环节错了两个——爬虫把变体商品的价格抓错了,FAQ生成干脆照抄了上一个商品的答案。返工又搭进去半小时。
那一瞬间我明白了一个道理:让单个强模型单线程干活,并不等于"雇了一个聪明人",而是"让一个聪明人同时兼任产品、开发、测试和翻译,还不给他任何交接文档"。 人扛不住,Agent也一样会犯糊涂。
于是我开始研究多Agent协作。下面这篇文章,记录了我一个月里试错、踩坑、推翻重来的全过程,包括最终跑通的方案、账面上的真实数字,还有一份可以直接照抄的作业。
我最初的想法很朴素:串行接力。一个Agent写需求,一个Agent写代码,一个Agent验收,像流水线一样往下传。
试了两轮,问题全部出在交接上。
第一轮,我让"规划Agent"(DeepSeek-V3.2,便宜,大概一块钱百万token的量级)输出一份自然语言需求文档,直接丢给编码Agent(Claude Code + Sonnet 4.5)。结果这份文档写了1200字,一半是"保证质量""注意兼容性"这类正确的废话,真正要紧的约束——比如"价格字段必须取 variant.price 而不是 product.price"——埋在第三段中间,Claude Code压根没看见。代码能跑,业务全错。
第二轮我换了策略,让规划Agent输出结构化JSON任务卡,字段包括goal、constraints、acceptance_criteria、forbidden。这次约束确实被执行了,但新问题冒出来:上下文丢失。编码Agent干活时图方便,把前面爬虫环节的数据结构改成了自己习惯的命名,检查Agent拿着原始需求来验收,两边对不上,互相甩锅——当然,账单还是我付,反复重跑。
两轮下来我算了笔账:单看每个Agent都便宜(DeepSeek一次几分钱,Sonnet一次两三毛),但因为交接不清导致的返工,整体耗时从预期的40分钟膨胀到2小时20分,总成本反而比单Agent方案高出12%。便宜模型 + 糟糕交接 = 最贵的方案,这是我踩的第一个坑。
第二个坑更隐蔽:我一开始让三个Agent共享同一个工作目录,以为这样"沟通更顺畅"。结果编码Agent写到一半,检查Agent的某个自动化lint脚本正好在跑,把半成品文件格式化了一遍,编码Agent回来发现自己代码"被改了",开始修一个根本不存在的问题,白白多烧40万token。后来我给每个Agent划了独立工作区,靠显式文件交接,才消停下来。
折腾两周后,我定下了最终架构,三句话概括:分工按"思考成本"切,不按"功能模块"切;交接只认物化的工件,不认聊天记录;验收设硬门槛,不过就回退,不商量。
具体拆成四步:
1. 规划环节——用最便宜的模型,干最贵的架构思考。 这里有个反直觉的点:规划恰恰可以用便宜模型,因为规划任务的输出是"给机器看的结构化任务卡",不需要文采,只需要完整和精确。我用DeepSeek-V3.2加一份精心调过的prompt模板(前后改了9版),输出固定字段的JSON任务卡:goal、input_schema、output_schema、constraints(数组,逐条编号)、acceptance_tests(至少3条可自动执行的断言)。单轮成本约0.03元,输出稳定在900token以内。这一步省下来的钱,全都补贴给后面贵模型的执行环节。
2. 编码环节——上最好的模型,但给它戴上镣铐。 编码用Claude Code + Sonnet 4.5,但启动时挂载一份我手写的HANDOFF.md,内容只有两块:任务卡原文,和"你可以改什么、不能改什么"。关键配置是我在.claude/settings.json里关掉了它的自动执行权限,只允许它写文件,跑测试必须由我(或脚本)触发。这样它就没法自己跑一半测试然后说"应该没问题"。这一步单轮成本约0.35美元。
3. 检查环节——换个"物种"来验收。 这是我认为整套方案里最值钱的决定:检查Agent不用Claude,改用GPT-5(当时也试过Codex CLI,效果接近,GPT-5的代码审查指令遵循更稳)。用同一个家族的模型自检,等于让学生自己批改自己的卷子——Claude生成的代码让Claude挑毛病,它总能找到理由原谅自己。换个异构模型,挑剔程度肉眼可见地上升。检查Agent拿到的是任务卡+产物,不拿到编码过程的任何上下文,避免"它都这么辛苦写了"的共情偏差。单轮成本约0.22美元。
4. 回退机制——一次不过,整体回退到编码环节,最多两次。 超过两次就升级到我的桌面,人工看一眼——实践里一个月触发过3次,全是需求本身有歧义,不是Agent的锅。
整个流程我用一个60行的Python脚本编排,脚本本身不调任何模型API,只负责传文件、记日志、算token。模型API全部走各家官方接口,没有用什么花里胡哨的编排框架——这个决定我也要单独说:市面上的多Agent框架我试了三个,全是智商税重灾区,封装一层"Agent社会"的概念,底层还是顺序调用API,但token消耗因为系统prompt膨胀涨了30%以上,调试还更痛苦。一个能看懂的循环脚本,比什么都强。
方案上线后我在真实业务上连续跑了一个月,处理详情页生成任务412次,账本如下:
折腾一个月,我的态度很明确,直接说:
值得折腾的:异构模型分工(便宜模型规划+贵模型执行+异构模型审查)这一条, alone 就值回所有试错成本;交接工件的结构化(任务卡、schema、验收断言),投入产出比极高,写一次模板受益半年;以及"上下文即成本"的预算意识。
智商税:重型多Agent编排框架(除非你做的是真正需要并行探索的研究型任务);让Agent之间用自然语言"自由讨论"——听起来很美,实测是token黑洞加错误放大器,三个Agent讨论十分钟得出的结论,不如一个清晰的JSON任务卡;以及一切"全自动无人值守"的宣传话术,我的实践是人退到验收和例外处理两个位置,剩下的交给流程,这个位置感比"全自动"靠谱得多。
多Agent协作这事,说到底不是技术问题,是组织设计问题——你本质上是在给一群没有记忆、没有责任心但执行力爆表的"实习生"设计管理制度。想清楚谁有权决定、谁有权执行、谁有权说"不",比换任何一个新模型都管用。
说明:本文数据来源为公开行业报告综合整理,文中涉及的token量、成本、耗时等数值基于作者个人实践记录,部分为估算值,仅供参考。