一家电商把客服 Agent 的主模型换成了单价更低的新版本。
财务测算很直观：输入和输出 token 都更便宜，按月请求量估算，模型账单应该下降三成。灰度两周后，总支出不仅没有下降，反而上涨了 46%。
问题不在价格表，而在运行轨迹。
新模型第一次选择工具的准确率略低，于是更多请求进入重试；检索结果不够确定时，编排器同时启动三个子 Agent；其中两个又各自展开网页、做摘要、请求裁判。用户等待变长后会重复点击，网关把第二次点击当成新任务。单次调用便宜了，完成一件事需要的调用却成倍增加。
普通聊天产品常按一次请求估算成本，Agent 更接近一个动态工作流。一次用户任务会生成多少模型步骤、工具调用、候选分支和重试，事先并不固定。任何一处失败都可能触发新的路径。
因此，最有用的成本单位不是“每百万 token”，而是“每个成功业务结果”。
任务的直接支出包括模型、检索、沙箱、浏览器、数据库、第三方 API、持久化和评测，还要算上失败重做与保留容量。把这些成本相加之后，分母不是请求数，而是真正完成且无需人工返工的业务结果数。
这个账本先把优化目标从“每次调用便宜多少”改成“交付一个可验收结果要消耗多少资源”。如果成功率下降、人工接管增加，分母变小，即使价格表不变，单位结果成本也会升高。
公式里最危险的还不是加号，而是乘数。
平均步骤数与每步分支数形成基础扇出；工具失败、格式错误和超时扩大尝试树；并发会提前消费尚未证明必要的路径；上下文又让后面的调用越来越贵。这四种放大并不相同，识别信号和断路方式也不能混用。
第一个乘数来自循环。
如果系统没有明确完成条件，模型可能在“搜索—总结—发现不足—再次搜索”之间往返。每一轮都合法，错误率甚至保持为零，任务却没有前进。只监控 5xx 看不到这种故障；更有效的信号是相同工具与相近参数重复出现、状态摘要不变、token 持续增长而业务里程碑没有增加。
循环控制不能只写在提示里。运行时需要最大步骤、同工具重复阈值、无进展计数器和总预算硬上限。达到阈值后可以切换策略、降低模型、请求澄清或终止，不能让一句“继续努力”拥有无限信用额度。
第二个乘数来自重试。
一次工具超时可能先触发工具层重试，Agent 看到失败后再试，网关或客户端还可能重放整次请求。三个层级各自认为只多试了少数几次，合起来却形成一棵不断扩张的 attempt tree；若动作有副作用，还会增加补偿、核验和人工处理。
重试必须有唯一所有者。下层已经具备退避和熔断时，上层只接收结构化终态；未知终态先查询，不立即重发；错误按可重试、不可重试和需要人工三类返回。全链路共享同一棵尝试树，才能看见一次用户任务扩张成了多少次实际执行。
第三个乘数来自并发。
并行可以缩短墙钟时间，却不等于提高资源效率。监督 Agent 同时派出五个研究分支，第一个已经找到足够证据，其他四个若不能取消，成本仍然全部发生。多个分支再把长报告带回汇总模型，最后一次调用还可能成为整个轨迹里最贵的一步。
并发应该由预期价值控制。只有分支成功概率乘以时间收益，高于额外模型和工具成本时才启动；一旦某个分支满足终止条件，取消信号要传播到队列、沙箱和下游 API。不可取消或按整次计费的工具，更应推迟到确定需要时调用。
第四个乘数来自上下文膨胀。
Agent 每轮重新发送全部历史、完整工具结果和所有子 Agent 报告，输入 token 会随步骤累积。十步任务不是十次相同成本，而是十次逐步变贵的调用。提示缓存能降低部分稳定前缀的费用或延迟，却不能修复不断增长的动态尾部。
更有效的做法是把状态、证据和原始材料分离。模型只接收当前步骤需要的工作集；确认事实写入紧凑账本；大工具结果只保留句柄；重复前缀保持稳定以提高缓存命中。成本优化与上下文工程在这里是同一个问题。
四个乘数还会彼此喂养。并发分支越多，汇总上下文越长；上下文越长，超时和格式错误越容易出现；新的失败又会触发重试和更多步骤。逐项调低某个参数，不一定降低整条轨迹的成本。运行时需要观察它们如何共同改变每个成功结果，而不是给四张独立仪表分别设一个漂亮目标。
把乘数截断以后，还要回答每一分钱应归到哪里。
调用、步骤、尝试、任务与租户必须通过父子 ID 串成一棵因果树。没有这种关系，月度总账只能解释“花了多少”，无法回答“哪种运行结构把它放大”。同样，只有 token 也不够：浏览器分钟、代码沙箱、向量查询、第三方数据、评测模型和人工复核，都可能成为主成本。
共享资源还要求两种口径。边际成本记录这次任务直接新增的 token、API 和执行时间，适合优化模型路由；分摊成本按峰值占用、缓存份额或租户配额分配预留实例与平台费用，适合产品定价和容量规划。混用两个口径，常会出现工程团队声称已降本，财务账单却没有变化。
质量失败也应该带成本标签。一个答案生成成功但导致用户再次联系，不应以 completed 结束；人工接管、补偿优惠和二次处理要回挂到原任务。只有把延迟发生的业务后果重新归因，系统才不会通过快速输出低质量结果“优化”眼前成本。
成本异常检测同样要看轨迹形状。总额突然升高可能只是流量增长；真正危险的是每成功任务成本、无进展步骤占比、重试深度或取消后继续消耗开始漂移。告警应指向具体 Agent 版本、工具版本和任务切片，才能在预算耗尽前止损。
离线评测也不是免费的附属品。每个版本候选如果都在全部历史轨迹上使用最强模型重跑，评测账单会随发布频率增长。可以先用确定性检查和小模型筛掉明显退化，再把高价值、边界和分歧样本交给昂贵裁判；用于最终上线的关键切片不能因为省钱被跳过。
成本还会通过延迟形成第二条反馈环。
系统越慢，用户越容易重试或离开；未完成请求堆积后，队列尾延迟继续上升；团队为了追赶时延扩大并发和预留容量，峰值过去后，闲置资源仍然计费。资源争用又可能反过来拖慢服务。
因此，均值和尾部必须同时观察。平均每任务 0.2 元，没有说明最慢的 1% 是否会跑到 20 元。系统应记录 cost p50、p95、p99，按任务类型和终态分桶，并分别限制单任务、单租户、单工具和全局预算。异常长尾要在达到上限前终止，而不是月底才从账单里发现。
预算也不只是一个拒绝数字。
每个任务可以先获得小额探索预算；出现新证据或不确定性下降时再分配下一段。高价值业务可以申请更高额度，低价值批处理在拥塞时降级。模型路由、候选数量、上下文长度和并发度都应由剩余预算共同决定。
简单、低风险、可验证的任务适合小模型和单路径；高价值但可延迟的任务可以串行增加证据；高价值且强时效的任务才值得有限并发；低价值且难验证的开放任务应设置更低上限，因为继续投入最难证明回报。
降本也不能伤害成功率。把模型换小、减少工具或压缩上下文，如果导致返工和人工接管增加，表面推理费用会下降，单位成功结果成本却可能更高。所有成本实验都要与质量、延迟和风险一起观察。
最小对照可以从一百条真实轨迹回放开始，用同一任务分布比较当前编排、只换便宜模型和结构性限流。
统一记录任务成功率、无需返工率、每成功任务总成本、模型与非模型成本占比、步骤数、扇出、重试深度、取消浪费、输入增长斜率、延迟 p95 和人工接管。若 B 组单价下降但步骤与接管上升，就能看见“便宜模型为何更贵”；若 C 组调用单价不变却单位成功成本下降，说明结构优化才是主收益。
上线前可以设置明确门槛：每个调用能归属到 step、attempt、task 和 tenant；价格版本随调用保存；重试只有一个所有者；同类动作重复会触发无进展检查；并发分支可取消；动态上下文增长有斜率告警；预算能控制模型、步数和工具；高成本尾部有硬停止；非模型费用进入同一账本；任何降本版本都通过成功率与风险回归。
那家电商最后没有撤回新模型。
团队先把三层重试合并为一个运行时策略，再把默认三路子 Agent 改成按不确定性逐步展开。工具返回只保留结构化字段，用户重复点击通过任务键合并。模型单价优势这才真正反映到账单上。
Agent 的成本不会从价格表直接流向财务报表。
它要穿过循环、分支、失败、等待、上下文和容量，途中每一层都可能放大，也可能被提前截断。
真正值得优化的不是一次调用有多便宜。
而是系统用多少不可追回的资源，换来一个可以验收的结果。
作者｜随机比特
