多Agent成本失控实战——并发、上下文与Token预算如何系统治理 从“Agent越多越强”到“每一美元都能解释”

多Agent成本失控实战——并发、上下文与Token预算如何系统治理从“Agent越多越强”到“每一美元都能解释”#多Agent #Agent #LLM #Token #成本优化 #上下文工程 #Prompt Caching #并发控制 #模型路由 #可观测性多Agent系统真正昂贵的地方往往不是模型单价而是同一份上下文被多个Agent重复读取、并发分支做了大量重叠工作、子Agent输出过长、失败后集体重试以及主Agent不断把历史结果重新塞回上下文。本文从成本公式出发拆解并发扇出、上下文复制、缓存、模型路由、交接格式、重试预算和观测指标给出可执行的预算控制器与案例测算。目标不是让Token越少越好而是在质量SLO不下降的前提下让每个子Agent的创建都有理由、每次调用都有预算、每次失败都有止损线最终把“多Agent很贵”变成可测量、可治理、可持续优化的工程问题。图1 多Agent成本治理从无界扇出到可观测、可预算、可收敛的执行系统1. 先说结论多Agent最贵的不是Agent数量而是“重复工作 × 高价上下文 × 失败放大”很多团队第一次把单Agent升级为多Agent时会先做一件看起来非常合理的事把任务拆成5份同时启动5个子Agent。速度确实快了质量有时也更好但账单往往在几天后突然变得难以解释。原因并不是“5个Agent当然就贵5倍”这么简单。真实成本更像一个放大器每个子Agent会重新消费系统提示、工具定义、业务规范和历史上下文它们会产生自己的中间输出主Agent还要再次读取、比较和综合只要某个上游失败重试可能把整棵调用树重新跑一遍。Anthropic在公开复盘多Agent Research系统时给出过一个非常有参考价值的数据其普通Agent交互的Token消耗大约是聊天的4倍而多Agent系统大约可达到聊天的15倍。这个数字不是所有系统的固定倍率但它揭示了本质——多Agent是在主动购买更多“并行计算与独立上下文”只有当任务价值足够高、工作流确实可并行时这笔计算才值得。一个更准确的判断多Agent成本治理的目标不是“少用Agent”而是让每一次spawn都回答四个问题它能否并行它是否需要独立上下文它能否产出可验证的独立结果额外质量价值是否大于额外成本图2 多Agent成本的典型组成重复上下文常常比“Agent数量”更值得先优化2. 先把成本公式写出来否则所有优化都只能靠感觉生产系统里最危险的成本指标是“本月总Token”。它能告诉你钱花了多少却几乎不能告诉你为什么贵、贵在哪个Agent、哪种任务在浪费、哪次优化真的有效。要让成本可治理最少要把每个Agent调用拆成未缓存输入、缓存读取、缓存写入、输出、工具费用以及由重试和协调产生的额外开销。图3 建议使用的任务级成本分解公式其中 U、H、W、O 分别代表未缓存输入Token、缓存命中Token、缓存写入Token和输出TokenP代表对应单价。C_tool是搜索、代码执行、浏览器、向量检索等按调用或按资源计费的工具开销C_retry表示失败放大C_coord则是主Agent综合、Reviewer复核、交接转换带来的协调成本。指标为什么必须记录常见异常信号未缓存输入Token判断上下文是否重复、是否过度携带历史Agent数增加后几乎线性上升缓存命中Token衡量稳定前缀复用效果缓存功能已开但命中率很低输出Token输出通常比输入更贵且会进入下一轮输入子Agent都返回长篇叙述重试次数区分正常波动与失败放大429/超时后整棵任务树重跑工具返回TokenMCP/搜索结果可能吞掉上下文一次工具调用返回几十页原文Cost / Success把成本和任务价值绑定总成本下降但成功率也下降3. 第一大黑洞无界并发不是并行是重复探索并发是多Agent最显眼的优势也是最容易失控的地方。理想情况下4个子Agent分别探索4个独立方向端到端时间接近单个分支的最大耗时现实里更常见的是4个Agent都拿着相同背景、搜索相似关键词、访问相同文档最后返回内容高度重叠。此时你买到的不是“4倍搜索覆盖”而是“4份重复上下文 4份重复工具结果 4份重复输出”。图4 无界fan-out与有界并发并发槽位不是越多越好3.1 先限制最大分支数再谈动态扩容最实用的做法不是让主Agent自由spawn而是给它一个硬上限。例如普通任务最多2个子Agent复杂研究最多4个只有当不同分支之间的主题相似度低于阈值、预计收益高于成本时才允许继续扩容。OpenAI的多Agent文档也明确指出多Agent适合可分成具体、独立工作流的任务对于严格顺序推理、频繁写共享状态、或者瓶颈本身是一个慢外部操作的任务增加子Agent可能只会提高Token使用。3.2 并发控制至少要有三层· 全局层限制系统同时运行的Agent总数避免多个用户任务一起冲垮RPM/TPM。· 任务层限制单个任务的max_parallel和max_agents防止一个“难题”吃掉全部预算。· 资源层对搜索、浏览器、数据库、代码执行等昂贵工具单独设置Semaphore和速率限制。经验法则当新增一个子Agent不能明确回答“它将探索哪个与现有分支不同的假设/数据源/模块”时先不要spawn。让主Agent继续做通常更便宜也更稳定。4. 第二大黑洞把完整上下文复制给每个子Agent上下文窗口越大越容易产生一种错觉既然放得下就把所有内容都塞进去。但大上下文并不免费。它除了直接增加输入Token还会让模型在不相关信息里寻找重点导致上下文污染。更糟的是多Agent会把这份“过度上下文”复制N次。一个50K Token的项目背景如果复制给6个子Agent仅公共输入就已经是300K Token还没有计算各自的工具结果、推理和输出。图5 推荐的上下文分层公共规则、任务摘要、局部证据、工作草稿逐层收窄4.1 用“最小充分上下文”替代“全量上下文”每个子Agent真正需要的通常只有四类信息目标、验收标准、局部证据、必要约束。完整聊天历史、无关代码、其他分支的草稿和全部工具定义不应该默认继承。对于代码仓库先检索相关文件再把文件路径与关键片段交给子Agent对于研究任务先把公共问题定义和已知事实写成一页“任务摘要”不要把几十轮对话原样复制。4.2 子Agent返回“摘要 证据 产物引用”不要返回完整思考史Anthropic的上下文工程实践强调子Agent可以在自己的干净上下文里做深度工作但回到主Agent时只返回压缩后的结论通常是1K~2K Token量级并把详细结果写入外部产物。这个模式能同时减少信息损失和Token开销主Agent只需要知道“结论是什么、证据在哪里、产物怎么引用”而不是重读子Agent几十页搜索过程。图6 产物式交接比“对话转述”更省Token也更容易审计5. 第三大黑洞工具定义和工具结果悄悄占满上下文多Agent一旦接入MCP、搜索、数据库、工单、文件系统等大量工具工具定义本身就会变成一笔固定税。Anthropic在高级工具使用实践中展示过一个极端但很典型的现象几十个MCP工具的定义可以在用户问题进入前就吃掉数万Token工具结果如果原样回灌成本和上下文污染会进一步扩大。问题低成本改法不要这样做工具定义太多按需Tool Search / 动态加载3~5个相关工具每个Agent启动时加载全部MCP Schema工具结果太长分页、过滤、范围选择、服务器端聚合把整张表/整份日志塞回模型重复读相同资料产物缓存、共享检索结果ID每个子Agent重新下载同一文件结构化数据转文字让代码/SQL先聚合再给模型把十万行JSON直接交给LLM一个常被忽略的优化是“让代码处理数据让模型处理判断”。如果任务只是排序、去重、筛选、计数、Join、格式转换让代码执行环境先把原始数据压缩成几十行结构化结果通常比让LLM逐Token读取更便宜、更确定。6. 缓存最便宜的Token是第二次不用重新算的TokenPrompt Cache对多Agent非常重要因为系统提示、工具契约、项目规范往往会被多个分支重复使用。但“打开缓存”不等于“缓存命中”。缓存依赖稳定前缀如果你把用户动态输入、时间戳、随机ID插在公共规则中间同一份规范在每个请求里都会变成不同前缀。图7 缓存友好的上下文布局稳定内容在前动态内容在后以OpenAI当前API为例GPT-5.6及以后模型的缓存读取价格是未缓存输入的0.1倍缓存写入是1.25倍这意味着缓存适合“会被重复读”的稳定前缀而不是所有内容都强行写入。真正应该监控的是cache_write_tokens、cached_tokens以及后续复用次数而不是“是否启用了缓存”这个布尔值。缓存是否划算的直觉一段公共上下文如果只用一次缓存写入反而更贵如果会被多个子Agent或多轮请求重复读取缓存才开始形成净收益。把“预计复用次数”加入spawn预算比盲目缓存更可靠。7. 模型路由不要让所有Agent都坐商务舱多Agent系统常见的第二类结构性浪费是所有角色都默认使用同一个旗舰模型。实际上规划、深度推理、简单提取、格式化、验证的认知难度完全不同。成本治理的关键不是“永远用便宜模型”而是用最便宜、但能稳定满足该角色SLO的模型。图8 模型分层把最强模型留给最需要判断力的环节角色建议模型档位典型任务升级条件路由/分类低成本判断任务类型、选工具、提取字段置信度低或涉及高风险并行执行低~中档检索、局部编码、数据清洗、草稿复杂推理或多约束冲突主Agent中~高档规划、依赖管理、综合多个结果高价值任务或证据冲突Reviewer按风险触发高档安全、正确性、关键决策复核高金额/生产变更/不可逆操作截至2026年9月OpenAI API公开价格里GPT-5.6 Luna、Terra、Sol的标准短上下文输入价分别约为$0.20、$2、$4/百万Token输出价约为$1.20、$12、$20/百万TokenAnthropic Claude Sonnet 5约为$2/$10Opus 5.5约为$4/$20。具体价格会变化但数量级足以说明把批量低难度子任务从旗舰模型下沉到成本型模型往往比“删几句Prompt”更有杠杆。8. 长上下文不是无限优惠跨过价格阈值前要主动压缩大上下文还有一个容易被忽略的价格拐点。以GPT-5.6 Sol为例当前模型文档说明当输入超过272K Token时整次请求的输入按2倍、输出按1.5倍计价。也就是说很多“把所有分支结果都塞回主Agent再总结”的做法不仅让Token变多还可能让整次综合请求进入更高价区间。· 在主Agent上下文达到阈值前主动compaction只保留目标、决策、未解决问题和产物索引。· 把大文件和完整报告放到对象存储/文件系统只在上下文里放ID、路径、哈希和摘要。· 对子Agent结果设置硬输出上限例如摘要1K~2K Token完整结果写产物。· 长任务按里程碑切段每段结束写结构化checkpoint再用新上下文继续。9. 重试不是可靠性免费午餐先分类失败再消耗预算图9 三类失败对应三种完全不同的处理策略多Agent系统里最可怕的不是一次失败而是“失败触发扇出重试”。比如主Agent创建4个子Agent其中一个因429失败调度器选择重跑整组如果重试逻辑再遇到超时就会产生2×、3×的成本放大。正确做法是把重试预算绑定到最小失败单元只重跑失败分支并且失败类型必须可解释。9.1 建议的重试预算· 瞬时网络/429指数退避 随机抖动通常最多2~3次。· 输入/Schema错误不允许原样重试必须修改输入或降级路径。· 副作用状态未知先查询业务状态或幂等键禁止盲目重放。· 连续失败达到阈值熔断该工具或该模型路由切备用方案或转人工。10. 预算控制器让spawn变成一个“需要审批的资源决定”图10 生产级预算控制器创建子Agent之前先做价值与资源判断真正成熟的多Agent系统不会让“创建子Agent”只是一个普通工具调用。它更像申请数据库连接、申请GPU或启动容器必须经过配额、并发和预算检查。可以给每个任务设置max_cost_per_task、max_agents、max_parallel、max_retries、max_context_tokens和deadline主Agent每次准备spawn时先估算新增分支的Token和工具成本如果剩余预算不足就压缩上下文、切换更便宜模型、改为串行或者直接由主Agent处理。代码示例一个最小可用的预算 并发门禁from dataclasses import dataclassimport asynciodataclassclass Budget:max_usd: float 1.00spent_usd: float 0.0max_agents: int 4spawned: int 0def can_spawn(self, estimated_usd: float) - bool:return (self.spawned self.max_agentsand self.spent_usd estimated_usd self.max_usd)def reserve(self, estimated_usd: float):if not self.can_spawn(estimated_usd):raise RuntimeError(budget exceeded)self.spawned 1self.spent_usd estimated_usdsemaphore asyncio.Semaphore(3) #单任务最多3个并行分支async def run_subagent(task, budget, estimate):budget.reserve(estimate)async with semaphore:return await execute(task) # 记录真实Token后再结算差额生产环境还应把“预估成本”和“实际成本”同时记录。预估用于阻止明显超预算的调用实际用于校准估算器。随着日志积累可以按任务类型训练一个非常简单的回归模型预测输入Token、输出Token、工具调用次数和成功率让预算控制从静态阈值升级为数据驱动。11. 可观测性不要问“今天用了多少Token”要问“花的钱换来了什么”图11 多Agent成本看板应该同时显示成本、质量与延迟指标公式/定义为什么有用Cost / Success总成本 ÷ 成功任务数最核心的单位经济性指标Context Dup Ratio重复上下文Token ÷ 总输入Token定位“复制粘贴型”浪费Cache Hit Ratio缓存读取Token ÷ 可缓存Token判断缓存布局是否真的有效Retry Amplification实际调用数 ÷ 首轮调用数识别失败导致的成本放大Fan-out每个任务平均创建的子Agent数判断是否过度并行Token / Accepted Result总Token ÷ 被主Agent采用的结果数发现低价值分支P95 Latency95分位端到端时延避免省钱后用户体验崩溃这些指标必须按任务类型、模型、Agent角色和工具拆分。否则“平均值”会掩盖问题可能80%的任务非常便宜只有5%的复杂任务因为无限fan-out和长上下文把账单拉高。对多Agent系统来说P90/P95成本分布往往比平均成本更重要。12. 一个完整算例6个Agent如何把单任务成本从约$1.7降到约$0.5下面用一个“多源研究 报告”任务做示意。假设原方案由1个主Agent、4个研究Agent、1个Reviewer组成全部使用同一高档模型且每个研究Agent都复制完整背景。价格仅用2026年9月公开API单价做估算实际账单还取决于缓存、工具、地区和服务层级。这个例子的目的不是给出固定成本而是展示优化顺序。阶段原方案优化方案主要变化主Agent规划Sol40K in / 6K outTerra18K in / 3K out公共背景压缩为任务摘要4个研究分支每个Sol32K / 8K每个Terra12K / 4K限制输出按来源切分避免重叠ReviewerSol45K / 5KSol20K / 3K只读摘要证据索引不重读全部过程并发一次开4~6个max_parallel3降低限流与同步重试交接复制完整文本产物引用 结构化摘要减少主Agent二次输入按GPT-5.6 Sol约$4/M输入、$20/M输出Terra约$2/M输入、$12/M输出粗算原方案约$1.7/任务优化方案约$0.5/任务降幅约70%。如果稳定前缀还能获得较高缓存命中成本还会进一步下降。更重要的是这个优化没有依赖“把所有Agent换成最便宜模型”而是先减少重复再做模型分层。不要只看降本百分比任何模型降档、输出截断或并发收紧都必须配套离线Eval与线上质量SLO。便宜但错误的结果不是优化真正的优化是 Cost / Success 下降同时正确率、召回率、安全性和P95延迟仍在目标范围内。13. 异步任务别走实时通道Batch/Flex也是成本工具很多多Agent任务并不要求秒级返回例如离线评测、批量分类、夜间代码扫描、知识库重建、历史工单摘要。这些任务如果和在线请求使用同一高优先级通道既贵又会抢实时配额。OpenAI当前Batch API公开说明提供50%的成本折扣并使用独立的批处理配额Flex则用更慢、偶尔资源不可用换取更低价格。把“是否需要实时”作为调度维度往往比继续压Prompt更有效。· 在线用户请求Standard/Fast严格控制fan-out和deadline。· 夜间评测、批量处理Batch接受24小时内完成。· 低优先级后台任务Flex或同类低价服务层。· 周期性汇总先聚合数据再一次性让模型生成结论。14. 决策树什么时候值得多开一个Agent图12 创建子Agent前的四问决策树如果一个任务不能并行、必须频繁共享可变状态、没有独立验收标准或者额外质量价值很低多Agent通常不是正确答案。此时更好的选择可能是单Agent Workflow、单Agent 工具、或者先用代码把确定性步骤完成再让模型处理最后的判断。15. 上线前检查清单检查项通过标准任务边界每个子Agent有独立目标、输入、输出和验收标准最大扇出设置max_agents和max_parallel默认小于等于3~4上下文公共内容去重完整文件用引用而非复制工具按需加载结果有分页、过滤、截断输出预算每个角色有max_output_tokens或结构化Schema模型路由低难度分支使用成本型模型Reviewer按风险触发缓存稳定前缀在前记录cache_write/cached_tokens重试按失败类型处理禁止整树盲目重跑预算每任务有max_cost、deadline、token cap可观测性能按task/agent/model/tool查看Cost / SuccessEval任何降本策略都经过质量回归测试降级预算不足、限流、模型不可用时有串行/低档/人工路径16. 结语真正成熟的多Agent不是“会开更多Agent”而是“知道什么时候不该开”多Agent的能力提升本质上来自更多上下文窗口、更多工具调用和更多并行计算。它天然不会比单Agent便宜。工程上能做的不是幻想“多Agent零成本”而是让新增计算只发生在有边际价值的地方可并行的任务才并行需要隔离的上下文才隔离低难度任务下沉模型稳定前缀尽量缓存长结果写产物而不是反复塞回对话失败只重试最小单元。最终你需要管理的也不是“Token数量”而是单位成功成本。一个系统今天用了1000万Token并不可怕可怕的是没人知道其中多少是重复上下文、多少分支最后没有被采用、多少是盲目重试、多少是本可以交给代码或更便宜模型完成的工作。只要这些成本能被解释、预算能被约束、质量能被评测多Agent就不再是一个烧钱的黑盒而是一套可以持续优化的计算系统。参考资料OpenAI, Multi-agent guide: https://developers.openai.com/api/docs/guides/responses-multi-agentOpenAI, Pricing: https://developers.openai.com/api/docs/pricingOpenAI, Prompt caching: https://developers.openai.com/api/docs/guides/prompt-cachingOpenAI, Cost optimization: https://developers.openai.com/api/docs/guides/cost-optimizationOpenAI, Batch API: https://developers.openai.com/api/docs/guides/batchAnthropic, How we built our multi-agent research system: https://www.anthropic.com/engineering/multi-agent-research-systemAnthropic, Effective context engineering for AI agents: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agentsAnthropic, Code execution with MCP: building more efficient AI agents: https://www.anthropic.com/engineering/code-execution-with-mcpAnthropic, Introducing advanced tool use: https://www.anthropic.com/engineering/advanced-tool-useAnthropic, Claude Sonnet 5: https://www.anthropic.com/news/claude-sonnet-5