多Agent真香还是烧钱？我给你一套可复用的成本评估公式
用多个AI Agent并行干活，听起来是在用钱买时间。但到底花多少钱、省多少时间、划不划算，大多数人是算不清的。我试着把这笔账理清楚，顺便给出一个可以直接套用的评估框架。
01 Anthropic自己说的数字
Anthropic在官方博客里明确提过一个数字：多Agent系统通常消耗单Agent方案的3到10倍token。
为什么会多这么多？三个原因。第一，上下文复制。每个Agent都需要加载项目上下文才能理解自己在做什么，10个Agent就是10份上下文，这些token是重复消耗的。第二，Agent之间的通信。Lead Agent分配任务要描述背景，Sub Agent汇报进展要附带结果，来回传递都在烧token。第三，失败重试。Agent做错了、合并冲突解决不了、测试没通过，每次重试都是一笔额外开支。
3到10倍是个很大的范围。具体落在哪个点，取决于任务的耦合程度。任务越独立、Agent之间通信越少，越接近3倍。任务越耦合、需要频繁协调，越接近甚至超过10倍。
02 一个真实案例的成本拆解
Nicholas Carlini用16个Claude实例花两周做了一个C编译器，花费大约20000美元，产出约10万行代码。
简单算一下：每行代码0.2美元。这个数字本身说明不了什么，需要有参照物。
换成人来做呢？一个高级C/C++开发者在美国的年薪中位数大概在15万到18万美元之间。两周的人力成本约5700到6900美元。但一个人两周能写多少行编译器代码？按高产估计，大概2000到5000行有效代码。这意味着人的每行成本在1.1到3.5美元之间。
所以从单价看，Agent的每行0.2美元比人的1.1到3.5美元便宜得多。但这里有个隐含假设：Agent产出的10万行代码质量和人写的一样。这个假设是否成立，需要看具体项目。Carlini的编译器通过了测试套件，质量是有保障的。换成别的场景，结论可能不同。
另一个角度：20000美元买到的是两周交付，人工可能需要几个月。如果时间有价值（比如抢先发布、赶项目deadline），这笔账就更划算了。
03 一个可复用的评估公式
我把多Agent的成本估算简化成一个公式：
多Agent总成本 ≈ 单Agent成本 × Agent数量 × 协调系数
协调系数怎么取？根据任务特性来定。
任务高度独立，Agent之间几乎不需要通信：协调系数1.5倍左右。每个Agent各干各的，额外开销主要来自上下文重复加载。
任务有一定耦合，需要偶尔协调：协调系数2到2.5倍。这是大多数实际项目的情况，Agent之间会有接口对接、偶尔的冲突解决。
任务紧密耦合，频繁通信：协调系数3倍甚至更高。如果到了这个级别，你应该认真考虑是不是不该用多Agent。
举个例子。假设一个任务，单Agent跑一遍大概消耗50美元的token。你想用5个Agent并行加速。
乐观场景（任务独立）：50 × 5 × 1.5 = 375美元 中等场景（有些耦合）：50 × 5 × 2.5 = 625美元 悲观场景（高度耦合）：50 × 5 × 3 = 750美元
对比单Agent串行的50美元，多Agent最少也要7.5倍的成本。你得问自己：省下来的时间值不值这个差价。
04 什么场景划算
几种明确划算的情况。
任务可以干净地切分成独立模块，每个Agent的工作上下文互不重叠。这种情况下协调系数最低，接近理论下限。比如给一个网站做十个独立页面，每个Agent做一个页面，互相不影响。
时间价值远大于token成本。如果一天的项目延迟意味着几万美元的损失，那花几千美元让多Agent两天做完比一个Agent跑两周要划算得多。
人力比token贵。这在很多场景下是成立的。尤其是需要高级开发者才能做的任务，人的时薪可能是200到500美元，多Agent哪怕烧了几百美元token，和人力成本比也不算什么。
05 什么场景不划算
任务高度耦合，改一个文件会影响其他五个文件。这种场景下Agent之间需要不停同步状态，协调开销可能比实际干活的开销还大。最后你花了10倍的token，速度可能只快了2倍。
项目本身不大。如果一个Agent花两小时就能做完的事，你开五个Agent并行，加上协调开销可能也就省了一个小时，但成本翻了好几倍。对于一天以内能完成的小任务，单Agent几乎总是更合算的。
你在做探索性工作。设计还没定、方向还在摸索的阶段，多Agent会放大不确定性。一个Agent走错方向，损失有限。五个Agent同时走错方向，损失是五倍的。
06 实际的省钱策略
减少不必要的上下文传递。不是每个Agent都需要加载完整的项目上下文。如果一个Agent只负责改前端样式，它不需要知道后端数据库的schema。精简每个Agent的输入上下文，可以显著降低token消耗。
用更便宜的模型做简单子任务。不是所有子任务都需要最强的模型。代码格式化、简单的文档生成、测试用例补充这些工作，用Haiku级别的模型就够了，token单价可能只有Sonnet的十分之一。把模型能力和任务难度匹配起来，是最直接的省钱方式。
控制Agent数量。不是Agent越多越好。Anthropic建议从最简单的架构开始，只在确实需要时才增加Agent。我的经验是，对大多数项目来说，两到四个Agent就是甜点区。超过这个数量，协调开销的增长速度会超过产出效率的增长速度。
设置花费上限。给每次多Agent运行设一个预算上限。到了上限就停下来，评估进度和投入产出比，再决定是否继续。这能避免失控的token消耗。有些CI/CD平台支持设置cost limit，如果你的工具不支持，至少手动监控一下消耗曲线。
07 最后的建议
多Agent不是银弹，是一个需要计算ROI的工具选择。
在做决定之前，先用上面的公式粗算一下成本。然后问自己两个问题：省下来的时间值多少钱？如果多Agent跑失败了（冲突太多、质量不行），回退到单Agent的代价是什么？
如果两个答案都指向"可以承受"，那就试。如果任何一个答案让你犹豫，先用单Agent跑一个子任务看看效果，再决定要不要扩展到多Agent。
稳妥比激进好。先证明小规模可行，再往上加Agent数量。这比一上来就开十几个实例然后发现钱烧完了效果还不好，要聪明得多。
参考链接： https://claude.com/blog/building-multi-agent-systems-when-and-how-to-use-them https://arstechnica.com/ai/2026/02/sixteen-claude-ai-agents-working-together-created-a-new-c-compiler https://venturebeat.com/orchestration/claude-codes-tasks-update-lets-agents-work-longer-and-coordinate-across