[控场AI]
· 4 分钟阅读· 2,198 字

轮次而非观测:编码Agent的成本真相与缓存优化

轮次而非观测:编码Agent的成本真相与缓存优化

600条轨迹分析显示,Agent循环成本主要由轮次数量决定,而非观测体积或模型选择。

一项覆盖两个Agent脚手架、两种语言模型、共600条公开轨迹的分析,重新排列了编码Agent成本优化的优先级。数据显示中位数观测仅118到286个token,常被引用的巨型构建日志其实处于第99百分位;98.6%的输入token由前缀缓存提供,按平铺输入定价估算循环成本平均高估约7倍。归因分析表明,轮次数量解释了成本方差的84%,平均观测大小仅解释4%,且最贵的轨迹恰恰观测最小、轮次最多。研究还推导并验证了模型委派的闭式盈亏平衡条件,发现一半评估设置中委派反而增加成本。作者强调这是相关性证据,并未证明可移除轮次而保持任务成功率不变。

TurnCost: Turns, Not Observations: Cache-Aware Loop Engineering for Coding Agents

编码Agent的工作方式是一个反复循环:改代码、跑工具、看结果、再决定下一步。研究者把这个过程的设计称为「循环工程」(loop engineering),涵盖上下文管理、模型选择、压缩策略和终止条件。围绕效率的既有工作大多集中在压缩工具返回的观测内容,或把部分轮次路由给更便宜的模型。但一项针对600条公开轨迹的分析给出了不同的答案:真正决定成本的是轮次数量,而不是观测体积。

600条轨迹揭示的成本结构

研究覆盖了两个Agent脚手架和两种语言模型,共600条公开的编码Agent轨迹。数据给出的第一个反直觉结论是:观测内容远比想象中小。中位数观测只有118到286个token。那些常被拿来论证「必须压缩」的大型构建日志,实际分布在接近第99百分位的位置——它们是极端案例,而非日常常态。

更关键的发现来自缓存。分析显示,98.6%的输入token由前缀缓存(prefix cache)提供。这意味着按平铺输入价格估算循环成本,在接近理想缓存的条件下平均高估了约7倍。换句话说,很多关于「观测太贵」的担忧,建立在一个已经被缓存大幅稀释的计费模型上。

前缀缓存(prefix cache) 是大模型推理服务中的一种提示缓存机制。在多轮对话或Agent循环中,每一轮请求都包含大量与上一轮完全相同的前缀内容(系统提示、历史对话、已读取的文件等)。推理服务端把这些前缀对应的键值缓存(KV cache)保留下来,下一轮只需计算新增的少量token,命中部分按远低于标准输入的价格计费,通常仅为后者的十分之一量级甚至更低。这也是为什么文章强调「98.6%的输入token由前缀缓存提供」:循环的真实边际成本主要落在未命中缓存的增量token上,而非累积的上下文总量。理解这一点,才能明白为什么用无缓存的平铺输入定价去估算循环成本会系统性失真。

轮次解释了84%的成本方差

研究对成本驱动因素做了归因分析,结果相当清晰:

  • 轮次数量(turn count)解释了日志轨迹成本方差的84%
  • 平均观测大小(mean observation size)只解释了4%

最能说明问题的是最贵的那些轨迹:它们恰恰拥有最小的观测,但轮次最多。这个关联指向一个判断:以观测为焦点的压缩方法,瞄准的是次要成本因子;真正更大、却几乎没有被系统研究的机会,是「不必要的轮次」。

作者也保持了克制:他们并未证明在保持任务成功率不变的前提下,轮次可以被移除。这是一条相关性证据,而非因果结论。

成本方差归因(variance decomposition) 是一种统计方法,用来衡量多个候选变量各自能解释结果变化的多大比例。这里把每条轨迹的总成本作为因变量,把轮次数量、平均观测大小等作为自变量,估算出「轮次数解释84%、观测大小解释4%」这样的份额。要点在于,它给出的是相关性而非因果性——高解释力只说明该变量与成本高度同向变化,并不证明干预它就能降低成本。这也正是作者反复强调「未证明移除轮次可保持成功率不变」的原因:在编码Agent中,轮次往往由任务本身的复杂度、代码库规模和失败重试共同决定,直接削减轮次可能只是把成本转移到成功率上。

模型委派有一个可验证的盈亏平衡点

基于上述成本结构,研究推导并实证验证了一个模型委派的闭式盈亏平衡条件。结论是:在一半的评估设置中,委派反而增加了成本——而且这些增加恰好出现在预测边界的附近。这为「把简单轮次路由给便宜模型一定省钱」的直觉提供了反面证据。

配套发布的工具TurnCost允许在替代的缓存、定价、压缩和路由策略下重新为轨迹语料打分。它把「如果换个策略,这批轨迹会花多少钱」变成一个可以批量计算的问题。

闭式盈亏平衡条件(closed-form break-even condition) 指用解析公式直接给出「什么情况下委派更省钱」的判据,而不必逐条轨迹试算。直觉上,把简单轮次交给便宜模型似乎总是划算,但委派本身会带来额外开销:一次委派调用的提示与输出、可能的重试、以及被委派模型因能力不足而增加后续轮次的概率。当便宜模型节省的单价差额,不足以覆盖这些新增成本时,委派就会亏本。文章所说的「在一半评估设置中委派反而增加成本,且集中在预测边界附近」,正是对这一阈值的实证检验——边界附近的结果最容易因缓存命中率、任务分布等条件的微小变化而翻转。

对Agent工程的启示

这项工作的价值不在于给出一个确定的优化方案,而在于重新排列了优化目标的优先级:

  1. 先看缓存,再看价格:在讨论循环成本前,确认前缀缓存的命中情况,否则定价模型会失真数倍
  2. 先数轮次,再看观测:把注意力从「观测太大」转向「为什么需要这么多轮」
  3. 委派不是默认省钱:路由到便宜模型存在明确的盈亏边界,需要按场景计算而非凭直觉

循环工程仍是一个年轻的领域,但这项分析至少说明:在优化Agent成本时,最显眼的那个变量,往往不是最重要的那个。

#编码Agent#循环工程#前缀缓存#模型委派#Agent成本优化#轨迹分析#TurnCost#上下文压缩
分享:

相关推荐