AI智能体浪费令牌的7种方式（以及应对之策）
内容提要
文章讨论生产环境AI智能体的令牌浪费问题，总结七种常见模式：上下文无限累积、工具结果未压缩、检索粗放、工具模式臃肿、思维链循环失控、忽视KV缓存前缀、简单任务用大模型。对应修复包括滑动窗口与摘要、中间件过滤、AST检索、状态机裁剪工具、熔断器、静态前缀排序和级联路由。核心观点是令牌优化关乎系统稳定，需依真实追踪权衡取舍。
延伸解读
上下文与状态混淆是浪费的根源
文章指出，许多工程师把上下文窗口当作系统记录，导致每轮请求都重复发送全部历史，令牌成本线性增长、延迟呈二次方上升。关键区分是：上下文是每次请求临时传输的令牌负载，状态是持久化的进度表示。将状态存入SQLite或Redis，而非塞回提示，才能避免为数据库读取反复付费。这一架构选择在项目早期就应确立。
修复措施之间存在真实张力
文章明确点出两个修复方向相互冲突：动态裁剪工具模式可节省令牌，但会改变提示前缀，破坏KV缓存命中率；而静态前缀排序最大化缓存命中，却让无关工具模式持续占用上下文。如何取舍取决于工具注册表大小、请求量和提供商的缓存实现。文章强调，只有真实生产追踪才能找到平衡点，不能凭猜测调参。
每项修复都有需要警惕的副作用
语义摘要本质有损，可能幻觉出早期会话中的精确UUID或代码片段，需搭配严格键值查询工具。工具结果过滤若误删分页游标，会静默破坏检索循环。熔断器可能对真正复杂的任务误报，在最终合成前终止任务。级联路由若分类层误判，会把垃圾参数送给前沿模型，反而使该次调用令牌花费翻倍。这些限制说明优化需结合场景权衡。
令牌优化最终是稳定性问题
文章结论强调，令牌优化不是省钱，而是系统稳定性。臃肿的上下文直接推高推理延迟，扩大检索失败和幻觉的暴露面。将上下文限制到任务所需的最小值，能迫使行为更确定、减少编排器超时、收紧故障域。到生产第100天，令牌浪费会从账单问题演变为数据质量问题，第一周的架构决策会双向复利。
Q&A
AI智能体在生产环境中常见的令牌浪费模式有哪些？
文章总结了七种常见模式：1. 上下文窗口无限累积（追加式陷阱）；2. 未压缩的工具结果直接注入；3. 检索粗放（grep-and-dump）；4. 静态工具模式臃肿；5. 无限制的思维链循环；6. 忽视KV缓存和提示前缀；7. 简单任务使用前沿大模型（单体路由）。此外还提到输出令牌浪费和冗余上下文注入两个额外模式。
如何解决上下文窗口无限累积导致的令牌浪费？
采用滑动窗口加语义滚动摘要：只保留最近N轮对话原文，将较早的对话压缩成密集的背景摘要，并将智能体的结构化状态卸载到SQLite或Redis等确定性存储中，而不是注入回提示。注意摘要是有损的，对于需要精确UUID、哈希或代码片段的场景，应配合严格的键值查找工具。
工具返回的JSON数据太大，如何减少令牌消耗？
在工具执行和上下文注入之间加入中间件转换层：剥离空值、过滤非必要键、将深层JSON重新格式化为紧凑的YAML或结构化Markdown。对于日志，可以预处理去除时间戳、线程ID等样板内容。但要小心不要过滤掉分页游标等必要元数据，否则可能破坏检索循环。
代码智能体检索时如何避免把整个文件塞进上下文？
采用基于AST（抽象语法树）的分块检索。在索引阶段将代码解析为调用图，当智能体搜索函数时，只返回精确的函数签名、文档字符串和直接结构依赖，而不是整个文件。这样可以将令牌从数千减少到约300。可以使用Tree-sitter等库构建语言感知的解析器。注意需要持续异步索引，避免索引滞后导致智能体基于过时代码推理。
工具模式（schema）太多导致每次调用都消耗大量令牌，怎么办？
实现上下文感知的工具裁剪，由有限状态机控制：根据智能体当前状态只注入相关工具。例如在“发现”状态只注入搜索和读取工具，在“执行”状态只注入写入和变更工具。但要注意动态工具模式会干扰提示缓存，因为每次工具子集变化都会导致KV缓存重新计算，需要与缓存优化权衡。
如何防止智能体陷入无限重试循环而浪费大量输出令牌？
在编排器层面实现熔断器：对工具失败设置严格的最大重试次数，并限制每个动作的输出令牌预算。当达到阈值时，编排器应拦截循环，调用确定性回退或升级到人工处理。LangChain和LlamaIndex等框架提供重试和回调钩子可作为基础。注意熔断器可能对真正复杂的任务误报，需要根据真实追踪调整阈值。
如何利用KV缓存和提示前缀来降低令牌成本？
将请求结构设计为严格的静态到动态梯度：把大量静态内容（系统提示、组织风格指南、持久模式定义）放在请求最顶部，绝不在静态负载之上注入动态变量（时间戳、用户ID等）。缓存边界应落在最长静态前缀的末尾。注意不同提供商的缓存TTL通常为5到15分钟，低流量或慢思考周期可能导致缓存过期。
简单任务应该用大模型还是小模型？如何路由？
实现级联LLM路由器：使用快速小模型（如Haiku级或Gemini Flash级）处理意图分类、结构化数据提取和日志摘要等简单任务；仅当分类意图明确需要复杂多步推理时，才路由到前沿大模型。可以使用LiteLLM等开源路由库。注意小模型在面对复杂或重叠工具模式时可能脆弱，误路由会导致双倍令牌消耗，因此路由边界应设在任务复杂度真正分离的地方。
除了输入令牌，输出令牌浪费如何避免？
当需要提取结构化数据（如姓名和邮箱）时，使用提供商原生的结构化输出模式或工具使用模式，而不是让模型自由生成对话性前言。约束输出格式可以完全消除这类浪费。此外，审计并消除冗余上下文注入（同一信息在多个地方重复注入）通常可以减少10-20%的输入令牌。
令牌优化为什么关乎系统稳定性而非仅仅省钱？
臃肿的上下文负载直接导致更高的推理延迟，并扩大检索失败和幻觉的表面区域。将上下文窗口限制到任务所需的最小值，可以强制更确定的行为，减少编排器超时，并收紧系统的故障域。到生产第100天，令牌浪费会从账单问题变成数据质量问题， stale事实积累、记忆过时、智能体陷入推理循环。第一周的架构决策会双向复合。
