Agent 为什么必须有 Token Budget?
上一篇我们给 Agent Loop 加了 maxSteps。
很多人做到这里,会松一口气:至少 Agent 不会无限跑了。
但只靠 maxSteps,控不住成本,也控不住上下文质量。
原因很简单:
同样是 8 步,
每一步 2K token 和每一步 60K token,
不是同一个系统。
一个 Agent 可以在 5 步里烧掉几十万 token。也可以在 20 步里保持很轻。真正决定成本的,不只是跑了几步,而是每一步带了多少上下文、输出了多少内容、工具结果有没有被降级、工具 schema 有没有全量暴露、失败后有没有重复把大日志塞回模型。
所以 Agent Runtime 不能只有 step budget。
还必须有 token budget。
Token Budget 不是省钱按钮
很多团队一听 token budget,第一反应是'降成本'。
这当然对,但不完整。
Token budget 同时影响三件事:
成本
延迟
判断质量
上下文太少,模型会失忆。上下文太多,模型会变慢、变贵,还可能被噪声干扰。旧日志、过期计划、全量搜索结果、无关文件片段,都可能把模型带到错误路径上。
这也是为什么长上下文不是万能解法。
更大的 context window 解决'放不放得下',不解决'该不该放进去'。OpenAI 和 Anthropic 都提供 prompt caching,说明重复前缀值得优化。但缓存只能帮你处理稳定前缀,不能替你判断动态工具结果该摘要、截断还是引用。
Runtime 要做的是预算分配,不是盲目压缩。
先把预算拆成四类
一个可用的 Agent Budget 不该只有 maxTokens。
我会先拆成四类:
type RunBudget = {
maxSteps: number;
maxModelCalls: number;
maxToolCalls: number;
maxRunTokens: number;
maxInputTokensPerStep: number;
maxOutputTokensPerStep: number;
maxWallClockMs: number;
};
这里每一项都解决不同问题。
maxSteps 防止 loop 无限跑。
maxModelCalls 防止某些实现里一次 step 内多次模型请求。
maxToolCalls 防止模型一轮里并行扔出一堆工具调用。
maxRunTokens 控制整个 run 的总预算。
maxInputTokensPerStep 控制每一步上下文大小。
maxOutputTokensPerStep 控制模型输出。
maxWallClockMs 控制任务耗时。

