大模型Agent应用上线后，成本和效果之间如何取舍？来自Anthropic官方的成本和效果均衡优化建议
大模型Agent的应用已经在快速发生，但是很多人发现，demo阶段效果很好的系统一旦上线就会面临一个非常现实的问题：成本。每一次agent请求的背后是多次甚至几十次的大模型调用，每次调用都是实实在在花钱的。模型越好，Agent效果越好，但价格也越贵；即使是同一个模型，不同的推理力度（effort参数，如low、medium、high）也会极大影响成本和效果。demo阶段可能觉得开销不大，但是一旦真实用户涌进来，这就是绕不开的问题了。
那么，效果和成本之间如何找到一个合理的平衡点？Anthropic官方最近上线了一篇文档，描述的是他们内部怎么做这件事情。这篇文档的每一条建议都附了内部基准测试的实测数据、适用条件，甚至包括什么时候这条建议会失效，非常值得关注。
文档把所有可以调节的手段分成了两类。第一类是不需要牺牲效果就能省下来的钱，包括prompt缓存、精简输入token、批处理接口，以及针对当前模型重新审一遍prompt。第二类才是真正需要做取舍的，包括选哪个模型、effort设多少、预算和上限怎么定，以及要不要用多个模型配合。
如果整篇文档只记一个结论，那应该是这个：在Anthropic测过的所有配置里，prompt缓存都是最大的一根杠杆，而且领先幅度非常明显——在agent循环里把任务成本压到了原来的三分之一左右，在一个小型的issue分类agent上直接砍掉了83%的开销，配合输入精简后达到88%。相比之下，换模型、搭多模型架构这些看起来更"架构级"的手段，实际收益反而窄得多。
需要说明的是，文档里所有数字都来自Anthropic自己的内部测试（2026年7—8月，按当时的官方价格计算），文档本身也反复强调这些只是方向性参考，最终要在自己的业务流量上重新测。
原文地址：https://platform.claude.com/docs/en/about-claude/models/optimizing-for-cost-and-intelligence
一、保证大模型效果的情况下如何节省成本
这个其实是大家最为关注的一个话题。这一类手段的共同点是用了之后输出质量不会下降，属于先做了再说的部分。有两个例外需要提前说：批处理接口是拿延迟换折扣，结果可能24小时后才返回；另外context editing这一项在实测中花掉的钱比省下的还多，原因下面会讲。
1.1 prompt缓存：所有优化里应该最先做的一件事
要理解这根杠杆为什么这么大，得先看清楚agent循环的计费结构。agent执行任务的时候，每一轮都要把整个不断增长的对话重新发送一遍，包括system prompt、全部工具定义、以及之前所有轮次的内容。一个40轮的任务，第一轮的内容实际上被发送了40次，任务总成本因此大致按轮数的平方增长。
缓存不能阻止这种重复发送，但可以让每次重发只花大约十分之一的钱——命中缓存的前缀按cache read价格计费，是input价格的0.1倍，每轮只需要为新增内容支付1.25倍的cache write价格。在Anthropic测过的所有运行里，cache read一直是任务成本中最大的单项开销，这意味着把缓存配置对比大多数模型选型决策更值钱。
缓存默认生命周期是5分钟，agent循环相邻两轮只隔几秒，所以绝大部分token每轮都能吃到折扣。如果循环中间需要等人（比如人工审核），5分钟很可能过期，这时候应该换成1小时缓存，写入成本涨到input价格的2倍，但只要避免一次未命中就回本了。
配置上的工作量不大，自动缓存会帮你放置断点，也可以用Claude Code自带的Claude API skill一句话加上。
有一段特别容易被忽略的内容：三个设置会在任务中途打断缓存。 第一，请求之间修改effort会让缓存前缀失效，所以只在compaction边界这类本来就要重新缓存的位置改。第二，中途修改task budget同样会失效，所以只在第一个请求上设一次。第三，每一次context editing都会让清理点之后的前缀失效，下一个请求要为后面的全部内容重新付写入费用，因此要分少数几个大批次清理而不是频繁小批量清。改完之后确认cache read没有下降，掉了的话用cache diagnostics查看前缀从哪里开始分叉。
1.2 精简输入和上下文里的无效token
大部分agent请求里都携带了对最终答案毫无影响的token。输入侧可以用web fetch的动态过滤挡掉网页样板内容、用图像缩放控制视觉输入的大小、用tool search配合延迟加载只在需要时载入工具定义，其中programmatic tool calling值得单独一提，它让Claude从代码里发起多次工具调用、只把过滤后的结果送进上下文，官方报告输入token减少了24%，分数还更高。上下文生命周期方面，context editing清理陈旧的工具返回，自动compaction防止长循环一路背着全部历史。
这些手段和缓存之间存在相互影响，要按净效果判断。Anthropic用一个issue分类agent逐项开启测试：
需要单独强调的是，context editing是这一节里唯一不免费的一项。每次清理都会重写被缓存的对话内容，和prompt缓存机制直接冲突，在这次测试里它花的钱多于省的钱。它的正确用途是给上下文窗口腾空间，而不是省钱。
1.3 不着急的任务走批处理接口
Batch API对每一个token打五折（包括缓存token），代价是结果在24小时内的任意时刻返回。规则很简单：没有人在实时等待的请求全部走批处理。对于无人值守的agent工作（评估运行、数据回填、定时任务），这是仅次于缓存的第二大免费杠杆，可以和本文其他所有手段叠加，唯一例外是Claude Managed Agents的会话天生是交互式的、不支持批处理。
1.4 用现在这个模型重新审一遍prompt
这一节我个人认为是全文最容易被低估的部分。
每一代模型对prompt的反应方式不一样，而prompt会不断沉积下为旧模型写的补偿性文字："verify twice"、"be maximally thorough"、强制分步流程、手写的scratchpad。问题在于新模型会一字不差地照着执行，多跑好几轮工具调用、多写一堆内容，账单涨上去了，准确率一点没涨。
在一个客服工单评测集上的结果：为Claude Opus 4.8写的prompt拿到Opus 5上用，每张工单贵了36%，准确率不变；做完审计之后Opus 5比未审计版本便宜14%，同时准确率从92%升到97%，超出噪声范围。Sonnet 4.6到Sonnet 5的迁移上，审计在同等准确率下省了14%。
更有意思的是两类陈旧文本造成的损失方式完全不一样。新模型会过度服从的那类指令（"verify twice"、"be maximally thorough"），代价体现在钱上，删掉后每张工单成本降三分之一左右。而已经不适配新模型的那类文本（废弃的thinking设置、互相矛盾的规则、与模型自身思考机制冲突的手写scratchpad），代价体现在准确率上，删掉后各自恢复了7到11个百分点。
审计本身只是一条命令，Claude Code自带的Claude API skill有一个prompt-audit命令，读取项目里的prompt和请求代码，报告哪些内容是为另一个模型写的，输出是diff补丁而不是重写稿，并会明确列出它故意没有改动的部分。同样的陈旧模式也会出现在工具描述和skill里，建议一并清理。
二、需要在成本和效果之间做取舍的部分
上面四项做完之后，账单通常已经降到原来的一个零头。如果还是太高，接下来就必须开始做真正的取舍了。这一类手段决定的是单个模型在成本和智能之间停在哪个位置，包括模型选择、effort、失败重跑，以及预算和上限。目前Claude的模型从便宜到贵依次是Claude Haiku 4.5、Claude Sonnet 5、Claude Opus 5、Claude Fable 5（前沿模型）。
虽然下面先讲模型比较，但文档给出的第一个动作始终是先在当前模型上做一次effort扫描，因为那是最便宜的实验，大多数负载到这一步就该结束了。
2.1 比较模型要看每个完成任务的成本，不是每token价格
按token看前沿模型确实贵，Claude Fable 5的单token价格是Sonnet 5的好几倍。但你实际付钱买的是完成的任务：更强的模型完成同一个任务需要更少的轮次、搜索、重读和回溯，单token溢价经常被"每件事都少做一点"整体盖过去。
不过这个结论并不普适。在SWE-bench Pro子集上（两个模型基本刷满，分数与公开榜单不可比），Opus 5和Fable 5准确率在噪声范围内相当，而Opus只花了约60%的钱。文档的默认建议是大多数agent负载从Claude Opus 5起步；另一端，Haiku 4.5单题成本约为Opus的十分之一，准确率63%对92%，适合高吞吐可校验的活，不适合长agent循环。
这里还有一条方法论上的提醒非常重要：定价要看业务负载的尾部，不要看中位数。 典型任务上所有模型看起来差不多，但账单是被便宜模型跑失败的那些任务决定的。而且就算什么都没失败，钱也集中在尾部。一次20道题的WideSearch运行里，两道题吃掉了43%的总开销，最便宜的一半加起来只占10%。
后面要讲的多模型策略，存在的意义就是把前沿智能花在这条尾巴上，而不必为其余部分付前沿价格。
2.2 effort：把模型的思考深度调到任务真正需要的水平
effort参数控制模型思考、调用工具和自我验证的量，默认值high。成本随这些活动上涨，但准确率只随任务真正需要的那部分上涨——在模型能力上限以下，最高的几档等于是在为用不上的深度付钱。
在研究和知识工作类基准上（WideSearch、DeepWideSearch、BrowseComp、GDPval，全部用Fable 5），准确率对成本的曲线几乎是平的：low损失1到3个百分点，换来成本降到三分之一到二分之一；medium与默认档准确率持平，成本只有70%到85%；默认档在这四个基准上相对medium没有买到任何可测量的提升。在DeepWideSearch上，low档单模型甚至追平了orchestrator加Sonnet 5 worker的架构，成本还低20%——单纯调低effort打赢了一次架构改造。
长周期编码是完全不同的形态。SWE-bench Pro上Opus 5在medium损失约2个点换来成本减半，在low损失约8个点换来成本降到四分之一，这是实打实的取舍（下一节的失败重跑可以把它变回净节省）。
两个推论。第一，在加第二个模型之前先给自己的负载画出这条曲线，文档里有多模型配置看起来比默认档单模型便宜、实际上比同一模型降effort更贵的案例。第二，这条曲线就是任何多模型策略必须打败的单模型基线。
当然，在真正触到模型能力上限的负载上，降effort要付准确率代价。DeepResearch Bench II上每上一档effort稳定买到约2.4个rubric分，这条曲线上没有免费午餐。
光看任务描述判断不出自己属于哪种情况，要在自己流量的样本上扫两到三档。操作细节：每档用独立会话测，中途改effort会让缓存失效、扭曲对比。
2.3 结果可以校验时：低effort全跑，失败的高effort重跑
当任务结果可以自动检查时，effort曲线上最省钱的策略不是某个固定档位，而是一条动态策略。
Opus 5在low档有16%的任务失败，把这些用默认档重跑，总通过率约93%、每任务约0.70美元（已含失败尝试的费用）。全部用默认档跑则是91.7%、1.39美元。同样的通过率，一半的钱。从medium起步则是约94%、0.95美元。
文档补了一句：这里的小幅分数提升主要来自"第二次尝试"本身，所以这条策略应该当省钱手段用，不是提分手段。前提条件有两个：必须有可靠的失败信号（放过劣质结果的检查器等于没有），以及每个首次失败的任务要花两次运行的墙钟时间。
2.4 三种上限做的是三件不同的事
大多数agent任务运行不贵，但少数任务会在反复搜索和验证上花掉中位数的好多倍。task budget的机制是让模型看到一个实时的token倒计时然后自我调节。SWE-bench Pro上用Fable 5测的结果：宽松预算损失约2.7个百分点换来18%节省，最紧预算损失4.4个百分点换来47%。
三种控制手段完全不是一回事：
文档建议三个全设：一个task budget、一个比较高的max_tokens、一个session上限，再加workspace支出上限兜底。
task budget目前是beta功能，支持Opus 5、Fable 5、Opus 4.8、Opus 4.7，不支持Sonnet 5。起始值取循环token用量的90分位数，然后逐步收紧，低于20000 token的下限会被拒绝。它是建议性的，只引导不强制停止，只在第一个请求设一次（中途改会失效缓存）。
关于max_tokens有一条很反直觉的结论：它对模型不可见，所以调低并不会让模型变省。 那些需要更多空间的轮次只是被截断丢弃了，但照样计费。在一个内部基准上，16384的上限终止了Opus 5的15%的尝试和Fable 5的三分之一，这些被截断的尝试没有一个解出问题。折算到每个解出任务的成本上，和设成64000时完全一样，但64000下什么都没被截断，Fable从33.3%涨到54.6%。所以规则是：agent类工作max_tokens设成64000（xhigh或max effort下设128000），用流式返回，把stop_reason: max_tokens当作失败处理，省钱交给effort和task budget。
session budget是真正的硬停止，针对一次会话按官方价格的美元上限，到达时返回stop_reason: budget_reached，提高预算后可恢复。它是平台强制的，在所有有官方定价的模型上都能用（包括Sonnet 5），可以和task budget叠加。
三、多个模型配合使用：advisor与orchestrator
单模型上能调的都调完了之后，再往下走就是把不同步骤交给不同模型。这也是"多agent编排"最容易被过度设计的地方。文档对多模型的态度相当保守：前面那条effort曲线是任何多模型方案必须整体打败的基线，在实测里真正成立的形态只有两种，收益比前面的免费手段窄得多。
多模型适合的是任务复杂度分布足够分散的负载——常规部分交给小模型，难的步骤才用前沿能力。如果难度均匀或者本身是一条依赖链，单个调好的模型通常更好。
3.1 Advisor：把难的决策升级上去
低成本executor跑循环，遇到需要深判断的决策时调用高智能advisor拿建议，然后继续。大部分token按executor计价，只有咨询按advisor计价。用法上只需加advisor tool（beta），整个策略在一个/v1/messages请求里由服务端完成，不需要写编排代码。
收益由两件事决定。 第一是两个模型之间的能力差距，advisor只能交付executor缺少的能力：GPQA Diamond上Haiku做executor时从Opus advisor获益很大，Sonnet做executor获益几个百分点，前沿模型做executor时几乎没有获益。
第二是executor到底会不会开口问（咨询率），这条更脆弱。低effort的executor可能根本意识不到自己卡住了：某个配对在默认effort下大部分任务都咨询，effort调低后几乎不咨询，分数反而低于executor单跑。在DeepSWE上低effort的Sonnet 5 executor一直在问，涨了23个百分点；在SWE-bench Pro上同一个executor就不问了。
只要executor开口问，效果是好的——几组配对里advisor弥合了60%到90%的能力差距，而强模型只在咨询时才计费。
咨询率对prompt敏感，advisor tool文档给了一段system prompt要求每任务约两到三次咨询。实践建议是：为咨询率专门写prompt、持续测量、崩掉了就把executor的effort调回去。
什么时候能省钱。 能力差距大的时候。在Chartography（图表阅读基准）上，Opus 5 executor用low effort配Fable 5 advisor，得分67.5、每任务0.60美元，位于两个模型各自effort曲线之上，而这个executor在86%的任务上都咨询了。但在能力差距小的时候结论就不好看了：在一个内部编码基准上，Opus配Fable advisor是最准确的配置（85.7%、8.40美元/次），但只比Opus单跑默认档（84.4%、8.50美元）和Fable单跑medium（83.4%、8.20美元）高出一两个百分点，单次运行区分不出和噪声的差异。
无论哪种配对，都要先给advisor那个模型单独在低effort下定价，那才是需要打败的基线。每次有新模型发布都要重测。advisor策略适合编码agent、computer use、多步研究流水线这类大部分轮次机械性但好计划很重要的负载，不适合每轮都需要前沿能力、没有可规划内容（单轮问答）、或executor已经接近advisor能力的情况。
3.2 Orchestrator：把批量工作分派出去
前沿模型持有主循环，拆解任务、分派给低成本worker、合并结果。orchestrator自己的对话记录很短，token密集的探索被worker吸收掉了。worker可以并行时还能省大量墙钟时间。
但在省钱这件事上，它只在两种情况下成立。凡是单模型能独立完成的工作，同一模型调低effort每次都更便宜。
情况一：给常规工作的成本尾部买保险。 前沿模型偶尔会在一个本该轻松解决的常规问题上"转进去"，你事先判断不出是哪几个，而这几次运行足以主导账单。Coordinator把常规工作交给worker，等于按worker价格封顶了这条尾巴。在一个BrowseComp简单切片上，Fable coordinator配Sonnet worker平均成本约为Fable单跑的一半，90分位约为三分之一（12美元对33美元），而单模型最贵的一次花了84美元、答案还是错的。
注意这个结论和直觉是反的：分派在"常规的、本来就能解出的"工作上才划算，不是在难题上。 完整的更难集合上经济性直接反转。
情况二：工作量超过一个上下文窗口。 单模型面对这么大的输入只能串行处理，每遍都要为重读状态付钱，而worker各读各的分片、并行、按worker价格计费。Anthropic造了一个2160万token的语料基准，任何上下文窗口都装不下。这种情况下调effort完全没用，因为账单就是读语料本身（Fable单跑每个episode在每一档effort下都是720到764美元）。Coordinator配置比任何一档便宜55%，得分低3到7个百分点，同时完胜Sonnet单跑基线。
什么时候不要建orchestrator。 当工作是一条依赖链或者能装进单个上下文时，orchestrator是在为规划、交接、合并额外付钱，而这些单模型免费做掉。所有这类情况里coordinator那个模型自己降effort都更划算。BrowseComp在同一个基准内就展示了这条边界：分派在常规切片赢、在更难集合上输，后者前沿模型单跑准确率追平coordinator而成本还低22%到30%。
3.3 两种策略怎么选
归结为一个问题：工作能拆成独立片段还是一条依赖链？前者orchestrator，后者advisor。
如果拿不准，先什么都别建。第一步，在当前模型上扫effort，大多数负载到这步就结束了。第二步，如果有差距，给更强模型单独在低effort下定价，那是advisor配对必须打败的数字。真要加advisor时，它只是一个工具定义，不是架构重做。
四、如何在自己的业务上做测量
前面所有数字都来自特定基准和特定时间，你的升级率、任务拆分程度、对话记录长度都会挪位置。文档里那几处结论反转本身就是证据：同一个executor在两个编码基准上一个涨23个百分点、一个完全失效；分派在简单切片赢、在难切片输。方法可以直接搬，结论必须自己重测。
四步：第一步，从生产日志里按真实流量权重抽一批任务，为每个任务写结果检查（测试通过、工单关闭、行数正确），把每任务成本记在得分旁边（把响应usage里的四种token计数按各自费率计价，在全部请求上求和）。第二步，在各effort档给各模型打基线，画出得分对开销的曲线，多模型配置必须打败整条曲线。第三步，如果曲线有effort关不上的差距，加对应的多模型策略重跑。第四步，正式切换前在部分流量上影子运行，之后让评测持续跑。
两个容易踩的坑：agent循环里cache read那项通常是四项中最大的，如果不是就去检查缓存是否生效；启用advisor tool或compaction时有些token只体现在usage.iterations里而不进顶层合计，需要在iterations上求和并把advisor_message按advisor模型费率计价。
最后是文档给出的手段汇总表，排列顺序就是建议尝试的顺序：
五、几点总结
这篇文档最有价值的地方并不在于某个具体数字，而在于它给每一条手段都配了失效条件。context editing在实测中亏钱、多模型架构输给"同一模型降effort"、advisor在咨询率崩掉时分数低于executor单跑，这些反例完整写在正文里而不是脚注，这在厂商自己发布的材料里并不多见。
对工程实践的影响大概有三条。第一，优化的顺序被明确了：缓存、token精简、prompt审计、effort扫描，然后才轮到架构，而现实中大量团队一上来就设计多agent编排，缓存断点还没放对。第二，"每个完成任务的成本"必须替代"每token成本"成为决策口径，并且要按负载的困难十分位来算——20道题里两道题吃掉43%开销这个数字值得记住。第三，prompt是有折旧的，为老模型写的补偿性指令在新模型上会变成纯粹的成本甚至准确率损失，每次换模型都应该把prompt、工具描述和skill一起重审一遍，这是全文唯一一条既省钱又能提准确率的手段。
DataLearner 官方微信
欢迎关注 DataLearner 官方微信，获得最新 AI 技术推送
