AWS开发者直言：你的AI Agent每天都在白白烧Token

很多团队以为Token成本失控，是模型太贵。AWS高级开发者Eric Hanchett却指出：真正的元凶，是Agent设计本身。从系统提示词到工具调用循环，几乎每一步都在偷偷浪费钱。这是一篇能让你立刻省预算、又显得很懂行的实战文章。

最贵的不是模型，而是你每天重复发送的那段话

Eric一上来就点破一个很多人忽略的事实：Agent最浪费Token的地方，往往不是用户输入，而是系统Prompt。

在真实生产环境里，系统Prompt通常又长又复杂：角色设定、规则、工具说明、示例……问题是，大多数团队在每一次Agent调用时，都会把这一整段原封不动地再发一次。

他的解决方案很“工程”：缓存系统Prompt。第一次调用时发送完整Prompt，之后只发送一个缩减版引用。AWS Strands Agents里只需要加一句类似 cache_prompt = default 的配置，就能让系统Prompt不再反复进上下文窗口。

更狠的是，这个思路不仅适用于系统Prompt，工具Prompt、固定消息同样可以缓存。很多团队抱怨上下文窗口不够用，其实窗口里塞的，全是本可以缓存掉的“老熟人”。

别再用“最强模型”干所有活，这是最隐蔽的浪费

第二个常见误区：所有请求都丢给同一个最贵的模型。

Eric的建议非常直白：根据任务难度做路由。复杂推理、关键决策，交给前沿模型；简单分类、改写、摘要，交给便宜模型。

他举的例子很现实：简单任务用 Claude 3 Haiku，稍复杂一点再切到 Claude 3.5 Sonnet。甚至，你可以让一个“更便宜的小模型”先判断任务难度，再决定用哪个大模型。

这背后的逻辑不是省，而是资源分层。Agent不是一个模型，而是一个调度系统。真正成熟的Agent架构，一定是多模型共存，而不是“All in One”。

Eric几乎是用告诫的语气在说：“不要用最贵的模型做所有事情。”如果你现在还在这么干，Token账单迟早会教你做人。

工具结果和无限循环，正在悄悄吃掉你的预算

真正让很多团队“突然爆单”的，往往不是对话，而是工具调用。

第一个坑是：大工具结果反复塞进上下文。搜索结果、数据库返回、日志、文档片段……一旦Agent进入多轮工具循环，这些内容会被一遍遍地带回模型。

Eric给出的解法是“外包”：把工具结果存到本地或云端，只把摘要放进上下文。这样Agent还能理解结果，但不再为重复内容付费。

第二个坑更致命：没有上限的工具循环。Agent一旦判断失误，就可能连续调用同一个工具10次、20次，甚至陷入近似死循环。

他的建议很工程化：
- 明确设置 max iterations
- 在部署前用可观测性工具检查：每个工具被调用多少次、跑了多久

这不是优化，而是基本的生产安全措施。

上下文不是越多越好，历史对话要“滑动”而不是堆积

最后一个技巧，几乎是多轮Agent的必修课：裁剪历史对话。

在多轮对话中，每一次调用都会把完整聊天历史重新发送给模型，这很容易吃掉成百上千个Token。Strands Agents里的解决方案叫“滑动窗口对话管理器”：只回看最近N条消息，比如10条。

代价是什么？你会失去最早的对话上下文。

Eric给出的平衡方案是：对早期历史做一次摘要，然后放回上下文。这样Agent既“记得发生过什么”，又不需要为完整原文反复付费。

这是一个典型的Agent取舍问题：记忆完整性 vs 成本控制。成熟团队不会选极端，而是用摘要做中间层。

总结

这场“闪电演讲”真正想传达的不是技巧，而是一种Agent思维方式：Token不是自然灾害，而是工程结果。缓存能省、路由能省、摘要能省、上限能省。对AI从业者来说，这意味着两件事：第一，Agent设计已经进入精细化运营阶段；第二，谁先把成本打下来，谁就能更快规模化。下次你看到高昂账单时，别急着换模型，先看看：你的Agent，是不是在做无意义的重复劳动？

关键词： AI Agent， Token成本， 提示工程， 模型路由， 上下文窗口

事实核查备注： 需要核查：演讲者姓名 Eric Hanchett（AWS高级开发者倡导者）；AWS Strands Agents 是否提供 cache_prompt 与 sliding window conversation manager；示例模型 Claude 3 Haiku 与 Claude 3.5 Sonnet 的定位描述；视频发布时间 2026-06-28。