来源

• 原始链接：https://www.youtube.com/watch?v=uiP88SpCi1Q
• 来源类型：视频逐字稿
• 来源标题：你的 Agent 正在浪费 Token，而你还不知道

Agent Token 成本控制高亮

这篇短讲来自 AWS 的 Eric Hanchett，价值不在于提出复杂新架构，而是把 agent token 成本拆成五个可操作的控制点：prompt 缓存、模型路由、工具结果外置、循环上限和历史裁剪。它适合作为任何 agent 产品上线前的成本检查清单。

一、缓存不是优化细节，而是 agent 成本基线

背景

Agent 往往会在每次 loop 中重复发送系统提示、工具说明和历史消息。演讲先从 system prompt 缓存讲起，因为这是最稳定、最不影响质量的节省方式。

第一种方法是缓存你的 system prompt。agent 第一次调用时会发送完整的 system prompt，之后每一次调用都会发送大幅缩减后的 system prompt。

你也可以缓存 tool prompt 和 messages。这听起来可能很显然，但你需要认真考虑根据任务难度来路由不同的消息。

兴趣匹配判断：这对长期运行的 Hermes / OpenClaw 式 agent 很关键。系统提示、工具说明和工作记忆如果每轮全量进入上下文，成本会随调用次数线性放大；缓存应被视为默认基础设施，而不是事后省钱技巧。

二、不要把最贵模型当默认执行器

背景

第二个策略是模型路由。演讲的反常识点是：并不是每个 agent 步骤都值得交给 frontier model，甚至可以用一个便宜模型先做路由判断。

如果任务更简单，就应该使用更便宜的模型。在这个例子里，也许我们用 Claude Haiku 来处理便宜一些、简单一些的任务，再用 Claude Sonnet 来处理更难一点的任务。

你甚至可以让另一个非常便宜的模型来决定该使用哪个模型。这里有很多可以尝试的空间，但我强烈建议，不要把最贵的模型用于你做的每一件事。

兴趣匹配判断：这正好对应多模型 agent 的调度问题。真正的 agent 产品不会只有一个“聪明大脑”，而是要把分类、改写、摘要、执行、审查等子任务拆开，用不同价格和能力的模型承接。

三、大型工具结果应该离开上下文窗口

背景

Agent 调工具后，工具结果常常被直接塞回对话。演讲提醒：如果结果很大，又在循环中反复携带，就会变成隐形 token 黑洞。

如果你拿到的是一个很大的 tool result，可以把它存到本地或云端，然后使用某种 summarization 来节省 token。

这样，tool result 就不会在每一次 tool loop 或每一次 agent loop 时都被加入 context。如果你能找到任何办法，让这个 tool result 不必在每一次调用时都发回给 large language model，那就能节省大量 token。

兴趣匹配判断：这条尤其适合“文件系统式记忆”和“引用式上下文”。工具返回全文、日志、检索结果时，应该保存到可寻址存储，只把摘要、句柄和必要片段放回上下文。

四、工具循环必须有上限，也必须可观测

背景

Agent 成本失控不只来自上下文太长，也来自 tool loop 自我重复。演讲把最大迭代次数和 observability 放在一起讲，是很实用的工程提醒。

当你处理 agent loop，而 agent 决定发起 tool call 时，我经常遇到这种情况：它会一遍又一遍地调用同一个工具。

如果你不限制这个 tool call，它可能会跑 10 次、20 次，甚至进入无限循环。对 token 使用量来说，这会非常糟糕。所以一定要设置 max iterations。

在部署 agent 之前，一个好的做法是运行一些 observability tools，查看每一个工具的 tool call 使用情况，看看每个调用运行了多长时间，以及循环了多少次。

兴趣匹配判断：这不是单纯成本问题，也是可靠性问题。任何生产 agent 都应能回答：哪些工具最常被调用、哪些调用最慢、哪里出现重复循环、哪些任务被 max iterations 截断。

五、多轮历史要裁剪，但要保留早期语义

背景

最后一个策略是历史裁剪。演讲没有简单主张“只留最近消息”，而是明确指出 sliding window 会丢失早期上下文，需要摘要来弥补。

多轮 agent 每次调用模型时会带上对话历史，长对话会消耗大量 token。可以使用 sliding window conversation manager 只保留最近若干条消息。

这种方式的 trade-off，是你会丢失开头部分的 message history。处理这个问题的方法是，你可以对历史记录做某种 summarization，然后把摘要放进 context window。

当触发 sliding window 之后，你发送的不是全部历史，而是一小部分摘要。

兴趣匹配判断：这对长会话协作非常贴近。核心不是“少放历史”，而是把历史压缩成可恢复的工作状态：当前目标、已做决定、关键约束、未解决问题和引用位置。

整体判断

这篇是小而实用的 agent 成本治理清单。它的价值在于把 token 优化从“少说一点”转成系统设计：缓存稳定提示、按难度路由模型、外置大型工具结果、限制并观测工具循环、用滑动窗口加摘要管理历史。对任何要长期运行、频繁调用工具、需要控制成本的 agent 系统，都值得直接转成上线检查项。