AI 编码代理为什么会消耗大量 Token，费用能否提前预测？

AI 编码代理消耗大量 Token，主要不是因为最终生成的代码很长，而是它会在多轮执行中反复携带对话历史、读取仓库文件、接收工具结果、运行测试并修正方案。费用可以在执行前做区间预测和风险分级，但当前模型还不能可靠给出精确点估计；更有效的做法是先估范围，再在运行时设置预算、坚控增长速度和无进展循环。

一项基于 OpenHands 与 SWE-bench Verified 的研究发现，代理编码任务平均消耗的 Token 比单轮代码推理高约 3500 倍、比多轮代码聊天高约 1200 倍，差异主要由输入 Token 增长造成。同一模型解决同一问题的不同运行也可能出现很大波动，极端个例可达到约 30 倍，因此“任务描述看起来简单”并不能保证低成本。

研究如何测量代理成本

研究使用 500 个 SWE-bench Verified 真实软件问题，选择 Claude Sonnet 3.7、Sonnet 4、Sonnet 4.5、GPT-5、GPT-5.2、Qwen3-Coder、Kimi-K2 和 Gemini 3 Pro Preview 八个模型。每个问题对每个模型独立运行四次，代理框架统一为 OpenHands。

每轮流程是模型读取当前提示与完整历史，生成响应，调用工具并取得执行结果。研究从结构化轨迹中提取输入、输出、缓存和成本，以及文件查看、修改等动作。由于每轮都把已有上下文继续带入，后面的请求会重复处理越来越长的历史。

这些结果描述的是该框架、模型版本、提示、工具和基准下的行为，不是对任意产品的固定成本承诺。实际工具可能使用不同的上下文裁剪、缓存、压缩和停止策略。但实验揭示的增长机制对长轨迹代理具有普遍排障价值。

为什么输入 Token 会成为主角

普通代码问答通常只发送问题和少量代码，得到一次回答。代理则要读取项目说明、目录、源文件、测试、错误日志和此前所有工具结果。每增加一轮，新内容不仅在当轮计费，之后还可能继续作为历史输入。

即使缓存输入单价较低，累计数量仍可能非常大。研究对 Sonnet 4.5 的阶段分析显示，缓存读取在各阶段都占据最大的 Token 量，并成为主要美元成本贡献者。便宜的单个缓存 Token 乘上反复复用的巨大上下文，仍能超过价格更高但数量较少的输出。

因此，只限制回答长度通常无法控制代理总成本。更关键的是减少代理读取的文件、工具输出、无关历史和重复动作，并在上下文持续增长前结束或压缩会话。

五个阶段如何消耗 Token

研究把轨迹分为 Setup、Explore、Fix、Validate 和 Closeout。Setup 包含计划、环境准备与初始复现；Explore 是搜索代码、读取文件与定位根因；Fix 包括编辑、调试与补丁迭代；Validate 运行测试与回归检查；Closeout 完成清理和总结。

在 Sonnet 4.5 数据中，Explore 占约 30.37% 的轮次，Fix 占约 33.53%，两者合计接近三分之二。Validate 约 16.59%，Setup 约 9.98%，Closeout 约 9.53%。最值得优化的是探索和修复循环，而不是删掉最后几十行总结。

Setup 中规划输出相对突出；进入 Explore 后，读取仓库让输入迅速增长；Fix 和 Validate 会不断加入代码、脚本和测试结果。单轮成本峰值常由读取新文件、执行测试、创建脚本和最终总结等离散动作触发。

为什么同一任务费用差异很大

代理的路径具有随机性。同一问题的一次运行可能很快找到关键文件，另一次可能搜索错误目录、读取更多候选、做无效修改再回退。研究中跨全部模型和问题，最贵运行平均约为最便宜运行的两倍；少数同题极端个例可相差约 30 倍。

任务之间也呈重尾分布。500 个问题中，最昂贵问题平均比最便宜问题多消耗约 700 万 Token，而且高成本问题的不同运行波动更大。这意味着平均值不足以设置安全预算，还需要观察九十分位数、九十五分位数和最大值。

估算时应给出区间，例如常态、较高与硬上限，而不是承诺“这次会用 20 万 Token”。运行时若提前触发高成本信号，就请求用户确认、缩小范围或停止，而不是等到结算后才发现异常。

更多 Token 不等于更高成功率

在同一问题的四次运行中，准确率从最低成本组到次低成本组略有提升，随后在更高成本区间趋于饱和。最高成本运行并没有稳定获得更高成功率，部分场景反而更差。

高成本失败经常伴随重复查看和重复修改同一文件。代理没有获得新证据，却在旧假设上来回尝试，导致历史变长、缓存读取增加、测试重复运行。增加计算量在这里放大的是低效探索，不是有效推理。

因此，预算上限不只是财务控制，也可以提高工程质量。达到若干轮仍没有新测试结果、根因证据或补丁进展时，系统应停止并总结阻塞，而不是自动购买更多 Token。

人类判断的难度为何不够可靠

SWE-bench Verified 提供专家估计的人工解决时间，但它与代理 Token 消耗只有较弱关联。研究报告 Kendall 相关系数约为 0.32，不同难度组的消耗分布大量重叠。

约 6.7% 被标为人工 15 分钟以内的问题，Token 消耗高于人工一小时以上问题的平均值；约 11.1% 的人工一小时以上问题，消耗反而低于 15 分钟以内问题的平均值。人类熟悉的修复模式，模型可能需要大量搜索；人类认为复杂的问题，模型也可能凭已有模式快速定位。

项目经理估算的工时可以作为一个特征，但不能单独决定代理预算。还应加入仓库大小、相关文件数量、测试成本、框架熟悉度、错误可复现性和历史同类任务的真实轨迹。

模型之间的 Token 效率不同

研究发现，同一批任务中各模型的准确率与 Token 效率差异明显。GPT-5 与 GPT-5.2 在较低成本区域取得较强准确率，而部分模型处于更高消耗区。Kimi-K2 和 Sonnet 4.5 平均比 GPT-5 多消耗超过 150 万 Token。

这个结果不能直接替代今天的模型选型，因为模型版本、价格和代理实现会变化。真正重要的是：同一任务的成本差异不仅由难度决定，也与模型的探索行为有关。即使只看所有模型都成功的简单子集，相对效率差异仍然存在。

效率较低的运行通常查看和修改更多文件，且约一半动作重复发生在同一文件。选模型时应同时测试成功率、总 Token、重复动作和停止能力，而不是只比较每百万 Token 标价。

执行前能否准确预测

当前只能做粗粒度预测，不能稳定做到精确预算。研究让同一个代理在执行前检查仓库、分解阶段，并分别预测输入、输出与总成本；每个模型对 500 个问题做三次预测，再与真实运行比较。

各模型预测与实际用量只有弱到中等相关。Sonnet 4.5 的输出 Token 预测相关性最高约 0.39，Kimi-K2 的输入预测相关性约 0.38；输入通常比输出更难预测，因为检索、工具调用和上下文扩张取决于执行中才出现的路径。

所有受测模型都系统性低估真实 Token，特别是实际输入进入百万级时，预测值仍被压在较窄范围。预测结果适合判断“低、中、高风险”，不适合当作最终报价或无需运行时保护的保证。

预测本身也会花钱

要让代理检查仓库并估算步骤，预测本身也是一次代理任务。多数模型的预测成本低于实际执行的一半，但并非越花钱预测越准确。Sonnet 3.7 和 Sonnet 4 的预测开销超过任务成本两倍，却没有得到最强相关性。

Sonnet 4.5 在约任务成本 0.32 倍的预测开销下取得最高相关性之一，GPT-5.2 将预测开销降到 6% 以下仍得到中等相关。对短小任务，先做昂贵预测可能得不偿失；对大规模迁移或无人值守任务，粗估和风险扫描更有价值。

可以设置预测触发条件：小任务直接在低预算中执行，中型任务做静态范围估计，大任务才允许代理预检。预检只读关键目录、依赖和测试入口，不应完整执行修复，否则预测与执行的成本边界会消失。

一套实际可用的预测模型

第一步用历史数据建立任务类别：单文件修复、跨文件功能、依赖升级、测试故障、性能问题和大型迁移。每类记录输入、缓存输入、输出、轮次、工具动作、总费用和成功状态。

第二步提取执行前可见特征，包括候选目录数量、代码语言、仓库规模、错误是否可复现、测试时长、涉及依赖、预计文件数和模型。不要只让模型凭标题猜数字。

第三步输出分位数区间。中位数代表常态，九十分位数用于预算，九十九分位数或历史最大值用于硬上限。新任务数据持续回填，让估计适应模型与工具更新。

预算建议 = 历史同类任务 P90 成本 × 风险系数
硬上限 = min（组织单任务上限，历史同类任务 P99）

风险系数可根据仓库陌生度、测试不可复现、跨服务依赖和生产权限提高。模型自预测只作为其中一个特征，不能覆盖历史统计。

预测结果如何校准

每次任务结束后保存预测区间与实际值，并检查实际值落在区间中的比例。若系统声称九成任务应低于 P90，但实际只有七成，就说明基线、任务分类或风险系数需要调整。不能因为平均误差不大就认为模型可靠，少数昂贵离群任务才是预算风险的来源。

还应分别校准输入、缓存输入与输出。论文显示输入比输出更难预测，如果只校准总 Token，可能掩盖上下文增长带来的系统性低估。不同模型和代理版本使用独立基线，升级后先进入观察期。

预测区间必须附带条件，例如允许读取的目录、最大轮次、测试范围和模型。如果执行中用户扩大任务或代理发现跨服务依赖，旧预测立即失效，应重新估算剩余成本。

失败任务为何需要独立预算

失败任务往往比成功任务更容易持续探索。研究的共同失败子集中，多数模型比共同成功子集消耗更多 Token，说明代理不总能及时识别不可解状态。把成功任务平均成本作为所有任务上限，会低估失败尾部。

为失败路径设置较短的阶段预算：复现失败后不能继续猜测，定位阶段必须形成候选文件与证据，修改阶段必须让至少一个目标测试发生可解释变化。任一阶段没有进展就暂停，而不是自动进入下一轮。

失败记录也应进入历史数据，包括停止原因、最后证据和人工接管结果。若人工发现缺少凭据、环境不可用或需求矛盾，未来相同信号应在执行前被识别，直接避免高成本尝试。

缓存能降低单价但不能消除风险

缓存让重复上下文以更低费率处理，是长会话得以运行的重要机制，但它不会减少逻辑上的上下文体积。只要代理继续积累历史，缓存读取量仍会随轮次增长；缓存失效时还要重新写入。

不要用高缓存命中率证明工作流高效。一个代理反复读取同一错误历史可能有很高命中率，却没有进展。应同时查看缓存量、重复动作率、测试变化和单位成功成本。

频繁改变工具定义、项目指令或模型可能破坏可复用前缀。稳定配置集中放在前部，动态日志保持短小，能提高缓存价值。无关任务应开启新会话，避免为复用缓存而保留大量无效历史。

生产预算的三道保护

第一道是执行前风险门：低风险直接运行，中风险要求区间预测，高风险需要用户确认。第二道是运行时软限额：达到一定 Token、费用或轮次时，代理必须报告进度并申请继续。第三道是服务端硬限额，确保客户端或代理失控时仍不能突破组织预算。

软限额应早于硬限额触发，留出总结和保存补丁的空间。直接在硬限额处中断可能丢失有价值的中间结果。停止时保存当前分支、修改文件、测试输出和恢复指令，后续可以换模型或由人工继续。

预算按任务、用户、项目和月度四个层级聚合。单任务限制防止离群值，用户限制发现异常习惯，项目限制控制业务成本，月度上限保护总。只有一个全局上限会让某个失控任务影响整个团队。

哪些任务最需要预检

大型仓库迁移、跨语言修改、测试不可复现、依赖环境复杂和无人值守运行最需要预检。它们容易触发广泛搜索、长测试与多轮回退。预检应确认环境可用、目标清楚、测试入口存在，并估计候选文件范围。

单文件格式修复、明确报错和快速单元测试通常不值得做昂贵的代理自预测。可以直接用较小硬预算执行，触顶再升级。预测成本也属于总成本，治理方案必须与任务规模相称。

上线前检查清单

确认计费字段能区分普通输入、缓存与输出；为每次执行生成稳定任务 ID；记录模型与代理版本；保存阶段、工具动作和测试状态；配置软硬预算；定义无进展条件；验证停止后能保留补丁；确保指标不包含源代码和凭据。

先在非关键仓库运行一个完整周期，检查预测覆盖率、告警误报和人工接管体验。正式上线后定期抽样高成本成功、高成本失败和低成本失败任务，避免只分析平均成功案例。

运行时应坚控哪些信号

坚控累计输入、缓存读取、输出、轮次和美元成本，还要坚控进展：是否发现新证据、是否减少失败测试、是否产生有效补丁、是否重复查看或修改同一文件。只有费用没有进展指标，无法判断高消耗是在解决难题还是原地循环。

每隔固定轮次计算成本增长率和重复动作率。若成本持续加速、重复文件动作增加而测试状态不变，触发暂停。代理应输出已确认事实、失败尝试、剩余假设和恢复入口，由用户决定继续、换模型或缩小范围。

长测试和大日志要单独控制。先运行最小相关测试，失败后只返回必要上下文；通过后再扩大回归范围。把数万行日志原样送回模型会同时增加当轮输入和后续历史。

如何从工作流上减少消耗

给代理清晰的文件范围、禁止修改区、成功标准和测试命令。先用代码索引或精确搜索定位符号，再读取小片段；不要默认遍历整个仓库。无关任务使用新会话，已确认结论压缩成短摘要。

工具返回采用结构化摘要，保留退出码、错误位置和关键上下文。生成目录、依赖缓存、锁文件大段内容和二进制输出应排除。多代理只用于可独立并行的任务，并在完成后及时关闭。

为每次任务设置最大轮次、最大文件读取量、最大测试次数和费用上限。第一次触顶可以请求确认，第二次仍无新证据则停止。让代理知道何时放弃，往往比单纯选择低价模型更有效。

如何判断优化是否有效

用同类任务的成功成本分布比较优化前后，而不是只看平均 Token。至少观察成功率、中位成本、P90 成本、重复动作率、人工接管率和完成时间。降低 Token 但使失败率上升，不是真正的优化。

模型或代理版本变化后重新建立基线。价格降低不代表 Token 效率提高，Token 减少也不一定意味着美元成本下降，因为输出、缓存和输入的单价不同。财务指标与行为指标应同时保留。

结论

AI 编码代理的大量 Token 来自长轨迹中的上下文累积和工具交互，尤其是反复读取历史、文件与测试结果。高成本常与重复探索相伴，并不保证更高成功率；人类感知的任务难度也只能提供有限线索。

费用可以提前预测为风险等级和区间，但当前模型自预测相关性不足且普遍低估，不能作为精确报价。可靠方案是结合历史分位数、执行前特征和模型粗估，运行时再用预算、进展与重复动作共同触发停止。这样才能在不牺牲成功率的前提下控制代理成本。