来源
- 原始链接：https://www.youtube.com/watch?v=uiP88SpCi1Q
- 来源类型：视频逐字稿
- 来源标题：你的 Agent 正在浪费 Token，而你还不知道
文本来源是 AI Engineer 频道视频《你的 Agent 正在浪费 Token，而你还不知道》的修复版中文稿。下面按汉松兴趣画像优先保留机制解释、反常识判断和可复用工作流，而不是做普通摘要。
开头可以先抓住一句：AWS 开发者布道师 Eric Hanchett 介绍了降低 Agent token 成本的五种做法：缓存系统提示词，按任务难度路由到不同模型，把大型工具结果移出上下文，限制工具循环次数，以及裁剪多轮对话历史。
一、缓存系统提示词
背景
Eric Hanchett 开场说明主题：在使用和创建 Agent 时降低 token 成本。第一种方法是缓存系统提示词，让第一次调用发送完整提示词，后续调用复用缓存，减少重复发送的提示词内容。
假设你有一个非常困难的任务，你可能会想使用较新的前沿模型。不过，如果任务更简单，就应该使用更便宜的模型。在这个例子里，也许我们用 Claude Haiku 来处理成本更低、也更简单的任务，再用 Claude Sonnet 来处理更难一点的任务。然后你可以用一个 if 判断来决定。你甚至可以让另一个非常便宜的模型来决定该使用哪个模型。这里有很多可以尝试的空间，但我强烈建议，不要把最贵的模型用于你做的每一件事。你应该根据使用场景使用多个不同模型，然后在 Agent 内部尝试把任务路由过去。
Eric Hanchett 开场说明主题：在使用和创建 Agent 时降低 token 成本。第一种方法是缓存系统提示词，让第一次调用发送完整提示词，后续调用复用缓存，减少重复发送的提示词内容。
兴趣匹配度很高。它对应的是 Agent 工程化的核心问题：如何把不稳定的模型行为放进清晰的状态、动作、工具和反馈闭环里。
二、将大型工具结果移出上下文
背景
当工具结果很大时，可以把结果存到本地或云端，再把摘要放回上下文。这样 Agent 循环每次调用模型时不必反复携带完整工具结果，从而节省大量 token。
另一个有用的技巧是把工具结果移出去。这里我再给大家看一段代码。同样，我使用的是 Strands Agent。这是一种手动做法。Strands Agent 也提供了一些额外 API 来完成这件事。如果你拿到的是一个很大的工具结果，可以把它存到本地或云端，然后用某种摘要来节省 token。这样，当它被反复调用时，工具结果就不会在每一次工具循环或每一次 Agent 循环时都被加入上下文。如果你能找到任何办法，让这个工具结果不必在每一次调用时都发回给 LLM，那就能节省大量 token。就像我刚才说的，有一些 API 可以做这件事，但本质上你也可以使用摘要技术来实现。
当工具结果很大时，可以把结果存到本地或云端，再把摘要放回上下文。这样 Agent 循环每次调用模型时不必反复携带完整工具结果，从而节省大量 token。
兴趣匹配度很高。它对应的是 Agent 工程化的核心问题：如何把不稳定的模型行为放进清晰的状态、动作、工具和反馈闭环里。
三、限制工具循环次数并观察工具调用
背景
Agent 调用工具时可能反复循环，甚至进入无限循环。应该设置最大迭代次数，并在部署前用可观测性工具检查每个工具调用运行多久、循环多少次，以评估工具调用效率。
你还可以限制工具循环的次数。当你处理 Agent 循环，而 Agent 决定发起工具调用时，我经常遇到这种情况：它会一遍又一遍地调用同一个工具。如果你不限制这个工具调用，它可能会跑 10 次、20 次，甚至进入无限循环。对 token 使用量来说，这会非常糟糕。所以一定要设置最大迭代次数，限制它最多循环多少次。在部署 Agent 之前，一个好的做法是运行一些可观测性工具，查看每一个工具的调用情况，看看每个调用运行了多长时间，以及循环了多少次。这样你就能了解工具调用的效率。
Agent 调用工具时可能反复循环，甚至进入无限循环。应该设置最大迭代次数，并在部署前用可观测性工具检查每个工具调用运行多久、循环多少次，以评估工具调用效率。
兴趣匹配度很高。它对应的是 Agent 工程化的核心问题：如何把不稳定的模型行为放进清晰的状态、动作、工具和反馈闭环里。
四、裁剪多轮对话历史
背景
多轮 Agent 每次调用模型时会带上对话历史，长对话会消耗大量 token。可以使用滑动窗口对话管理器，只保留最近若干条消息，并用历史摘要弥补早期上下文的缺失。
这会帮你节省很多 token。总结一下，我们有五件事。缓存系统提示词。如果可以，也缓存工具提示词和消息。按难度路由。不要把同一个昂贵模型用于你做的所有事情、所有任务。把这些大型工具结果移出去。如果你有一个很大的工具结果，可以对它做摘要，不要让它在 Agent 循环中反复发送，也不要让它撑爆你的上下文。你可以限制那些工具循环。一定要使用可观测性工具来查看工具调用花了多长时间、循环了多少次，然后继续迭代优化。当然，如果你的 Agent 使用多轮对话，也要裁剪历史记录，这样在很长的对话中，整段对话就不会被一遍又一遍地发送。
多轮 Agent 每次调用模型时会带上对话历史，长对话会消耗大量 token。可以使用滑动窗口对话管理器，只保留最近若干条消息，并用历史摘要弥补早期上下文的缺失。
兴趣匹配度很高。它对应的是 Agent 工程化的核心问题：如何把不稳定的模型行为放进清晰的状态、动作、工具和反馈闭环里。
五、五种节省 token 的方法回顾
背景
演讲者总结五个方法：缓存系统提示词，按难度路由模型，移出大型工具结果，限制工具循环，并裁剪多轮对话历史。
这会帮你节省很多 token。总结一下，我们有五件事。缓存系统提示词。如果可以，也缓存工具提示词和消息。按难度路由。不要把同一个昂贵模型用于你做的所有事情、所有任务。把这些大型工具结果移出去。如果你有一个很大的工具结果，可以对它做摘要，不要让它在 Agent 循环中反复发送，也不要让它撑爆你的上下文。你可以限制那些工具循环。一定要使用可观测性工具来查看工具调用花了多长时间、循环了多少次，然后继续迭代优化。当然，如果你的 Agent 使用多轮对话，也要裁剪历史记录，这样在很长的对话中，整段对话就不会被一遍又一遍地发送。
演讲者总结五个方法：缓存系统提示词，按难度路由模型，移出大型工具结果，限制工具循环，并裁剪多轮对话历史。
兴趣匹配度很高。它对应的是 Agent 工程化的核心问题：如何把不稳定的模型行为放进清晰的状态、动作、工具和反馈闭环里。
整体判断
这篇最值得保留的不是某个单点技巧，而是它把「你的 Agent 正在浪费 Token，而你还不知道」放进了更完整的工程框架里：缓存系统提示词、将大型工具结果移出上下文、限制工具循环次数并观察工具调用。这些内容可以作为汉松后续写 AI 工程、Agent 系统和团队工作流时的素材。
更重要的是，它提供了一种判断 AI 系统的方式：先看问题如何被拆成状态、动作、工具、评估和人的边界，再看模型能力如何嵌进去。只有这样，视频里的做法才会从一次演示变成可迁移的方法。