夜雨聆风
一份关于减少 AI Agent token 消耗的实践指南（缓存、懒加载工具、模型路由和精简上下文），以及无人提及的安全权衡。
为什么你的 Agent 开销会暴涨
一个聊天机器人发送一条消息，得到一条回复。而一个 Agent 会循环：它调用工具、读取结果、重试、并对所见的一切进行推理，每一步都会重新发送整个对话。因此成本不在于一次性的巨大提示词，而在于 相同 的 token 被反复处理。
在一个 40 步的任务中，一个 20,000 token 的系统提示词会被发送 40 次，而第 30 步会重新发送之前的所有内容。有团队报告，在优化前，单个任务消耗了 6000 万 token。换算成真实费用，一个未经优化的 Agent 每天运行 100 条消息，每月成本可能达到 约 1000–2500 美元；而下面这些技术可以将其降低到接近 50–100 美元。
事先坦诚地说：每一项节省都有代价：工程时间、质量或安全性。我会逐个指出。
1. 提示词缓存：停止反复读取从未改变的内容
在回答之前，模型必须 读取 你的提示词，这需要花钱。如果你的系统提示词、工具和示例每次调用都完全相同，那么你每次都在为重新读取它们付费。提示词缓存会存储那些不变部分的处理后的形式并重复使用，最高可节省 90% 的费用。
有一个规则决定成败：缓存的部分必须完全匹配并且放在开头。多一个空格或调整工具顺序都会导致缓存未命中。所以：稳定的内容放在顶部，变化的提问放在底部。
python
from anthropic import Anthropicclient = Anthropic()response = client.messages.create( model="claude-sonnet-4-6", max_tokens=1024, system=[{\ "type": "text",\ "text": LONG_STABLE_SYSTEM_PROMPT, # 规则、工具、示例\ "cache_control": {"type": "ephemeral"}, # 标记可缓存的前缀\ }], messages=[{"role": "user", "content": user_question}], # 变化的部分，放在最后)
OpenAI 在超过约 1024 token 时会自动执行此操作；只需确保稳定内容在前。注意： 缓存会在短暂的空闲窗口后过期（通常为 5–10 分钟），因此这对快速循环有利，而不适用于间隔数小时的请求。
最适合： 任何具有大型稳定系统提示词且被重复发送的 Agent。这几乎是唯一免费的午餐。
2. 语义缓存：复用含义相同的答案
提示词缓存需要 精确 匹配。语义缓存则基于 含义 匹配。“法国的首都是什么？”和“快，告诉我法国的首都”会返回相同的已存储答案，无需调用模型。它通过将每个问题转换为嵌入向量（表示其含义的数字）来实现，当新问题足够接近时，就提供已保存的答案。
这听起来简单，但其中暗藏陷阱。难点在于阈值（过于宽松时会自信地提供 错误 答案）、答案的有效期，以及防止一个用户的缓存泄露给另一个用户。一个干净的问答机器人可以将模型调用减少三分之二；而具有独特请求的编码 Agent 则节省甚微。建议： 只有在日志显示确实存在重复查询时才添加此功能，并配合每用户过滤器和合理的过期时间。
最适合： 高流量的通用问答机器人。当每个请求都是独一无二时，可以跳过。
3. 懒加载工具：不要传递 200 个你不会使用的定义
每个工具的名称、描述和模式都会在每次调用时随提示词一起传输，无论是否被使用。Anthropic 报告称，在优化前，工具定义占用了 55,000–134,000 个 token。解决办法：给 Agent 一个搜索工具，仅在真正需要时才加载特定工具的完整定义（Anthropic 的 defer_loading 标志可以实现）。代价是在调试时多了一个难以看见的额外搜索步骤，并且只有在拥有 10 个以上工具 时才值得。
除了成本之外还有一个好处：工具列表越小，模型选择 正确 工具的概率就越高。将数百个工具塞入上下文是已知的导致选错工具错误的原因。
最适合： 具有大型或不断增长工具集的 Agent。对于只有两个工具的 Agent，则不必费心。
4. 模型路由：廉价模型做廉价工作
大多数估算认为“简单”请求占比至少 60%，用顶级推理模型来回答这些请求无异于雇佣外科医生来贴创可贴。最安全的方法是 级联：先让廉价模型尝试，检查答案是否足够好，只在必要时才升级。在得到答案后再判断质量远比提前预测难度要容易得多。
python
def answer(query): draft = cheap_model(query) # 例如 claude-haiku-4-5 if is_confident(draft): # 检查 token 概率/不确定性 return draft # 完成，低成本 return strong_model(query) # 仅在需要时升级
只有大多数问题确实适合廉价模型时，这种计算才有效，因为升级的问题需要两次调用。经典失败案例：小型模型常常 自信地犯错：它们通过了你的检查但却是错误的。从保守的阈值开始，随着你测量真实质量再逐步放宽。
最适合： 真正混合了琐碎和困难请求的应用。注意那些直到用户抱怨才显现的质量下降问题。
5. 精简上下文：停止囤积垃圾
Agent 是囤积狂。工具输出、文件转储、测试日志、重试步骤以及死胡同的推理都会堆积到对话中，并在每一轮被重新发送。解决办法是只保留 Agent 所需的 提炼后 的状态，将原始垃圾归档到别处，并通过持续地摘要和剪枝来处理，而不是等到上下文膨胀。
与缓存或路由不同，这项技术 不会牺牲质量。更干净的上下文通常会让 Agent 变得更好，而不仅仅是更便宜。清除垃圾可以清理掉 30–70% 的上下文，也就意味着这些 token 节省了 30–70% 的费用。需要注意的是：在极小的模型上，运行摘要器的成本可能会超过节省的开销。
最适合： 长期运行的 Agent（编码、研究），它们会积累状态。
安全考虑：大多数教程跳过的那部分
缓存通过 共享 和 复用 来节省资金，而共享恰恰是风险的来源。将缓存看作一个地方，一个用户的数据可能悄然出现在另一个用户面前。
跨用户泄漏。 在共享缓存中，缓存的提示词返回速度比新的快，这个时间差是一个可测量的侧信道。有记录的漏洞攻击已逐 token 重建了 其他用户 的提示词，准确率高达 99%。缓解措施： 将敏感数据排除在可缓存前缀之外；在提示词开头加入唯一的用户或会话 ID，以避免缓存碰撞。 语义缓存投毒。 由于匹配基于相似性，攻击者可以构造一个在嵌入空间中接近合法查询的查询，从而拉取一个不属于他们的答案。缓解措施： 按用户和工作空间划定缓存范围，使用严格的元数据过滤器，并保持保守的阈值。 过时答案。 缓存的过时价格或政策不仅仅是 bug；在某些领域，这是一项责任。按主题设置过期时间，并且永远不要缓存任何必须保持最新的内容。 绝不缓存秘密。 API 密钥、个人数据和机密文档绝不应进入缓存。将哪些内容可缓存作为明确的策略。
简短规则：缓存是一个信任边界。按用户分区，激进地设置过期时间，验证输入，并监控异常的时间或重复的近似查询。
结论
AI Agent 中的 token 成本并非来自一次昂贵的提示词，而是来自那些在每次循环中被重新读取的相同 token，再乘以每次工具调用和重试的次数。这些修复方法可以整齐地叠加：提示词缓存是几乎每个人都应该开启的简单胜利；懒加载工具和精简上下文可以在不影响质量的情况下削减冗余；语义缓存和路由提供了最大的节省，但需要真正的谨慎。
从最适合你 Agent 的最廉价改动开始，在前后测量 token 用量，只有当你的日志显示复杂技术能带来回报时才去使用它们。优化你能衡量的东西，并让你的缓存保持短时有效。
原文链接： medium.com/@ancilartech/... 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～
登链社区始于 2017 年，通过构建高质量的技术内容平台，助力开发者在 AI 时代成为更好的 Web3 Builder。
登链社区网站 : learnblockchain.cn Twitter : @UpchainDAO B站 : space.bilibili.com/581611011 YouTube : www.youtube.com/@upchain
