Agent多步任务Token预算

本地处理

Agent 的成本陷阱是历史累积：每一步都要把前面所有步骤的对话再送一遍。10 步任务的输入量不是 1 步的 10 倍，而是接近 5.5 倍的单步累积。

模型

步骤数

静态前缀 token/步（系统提示+工具定义）

每步新增对话 token

每步输出 token

提示词缓存

静态部分 token

动态累积 token

总输入 token

总输出 token

无缓存($)

有缓存($)

当前成本($)

静态部分 = 步骤数 × 静态前缀；动态累积 = (每步新增对话 + 每步输出) × 步骤数 × (步骤数 − 1) ÷ 2；有缓存时静态部分按首次写入 1.25× + 其余命中 0.1× 折算。

Agent 成本为什么会爆炸

单轮对话很便宜，但 Agent 是多步循环：调用工具 → 看结果 → 再调用 → 再看结果……每一步都要把"系统提示词 + 工具定义 + 之前所有步骤的对话与工具返回"完整重发一次。

这意味着：第 10 步的输入里，包含前 9 步的全部内容。总输入随步骤数呈平方级增长，而不是线性。

总输入 = 步骤数 × 静态前缀 + (新增对话 + 输出) × 步骤数 × (步骤数 − 1) ÷ 2

以 10 步为例：静态 5000 × 10 = 5 万，动态累积 800 × 45 = 3.6 万，合计 8.6 万 token——而"单步 5800 token × 10"的直觉算法只会得出 5.8 万，低估了三分之一。

步骤数翻倍，成本涨 2.6 倍以上。这解释了一个常见现象：演示时跑 3 步的任务很便宜，上线后遇到真实复杂任务连跑 30 步，账单直接失控。

提示词缓存（收益最大）：静态前缀每步都重复，命中读只要 0.1×。上例中成本从 $0.26 降到 $0.16，降幅近 40%。Agent 是缓存收益最显著的场景。
设最大步数上限：硬性截断在 15–20 步，超限则要求模型总结当前进展并给出部分结论。避免一个跑偏的任务无限烧钱。
工具结果截断：把超长的工具返回（如整个网页、大段日志）截断或摘要后再入历史。这是动态部分膨胀的主要来源。
历史压缩/滚动窗口：只保留最近 N 步的完整内容，更早的步骤替换成一句摘要。
分层调用模型：简单步骤（判断、路由、抽取）走便宜的小模型，只在关键推理步骤用旗舰模型。

除了正常累积，还有一种成本黑洞：模型陷入循环——反复调用同一个工具、反复读取同一个文件、在错误的思路上绕圈。这类任务会一直跑到步数上限，把预算一次性消耗殆尽。

防御手段是监控"重复动作"：如果连续 3 步的工具有相同的参数，就强制中断并交还控制权。成熟 Agent 框架都有这类重复检测。

每步都要重复携带历史上下文，步数越多累计输入越大，呈近似平方级增长；不加限制时简单任务的成本会远超预期。

按任务复杂度分档设定，并在达到上限时优雅终止并给出中间结果；上限过高浪费资源，过低则任务完不成。

截断或摘要历史、只保留必要工具返回、对中间结果做压缩；把长文档处理拆成独立子任务也能显著降本。