在Agentic AI中节省Token的5种实用方法：降低LLM成本

一份关于减少 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 Anthropic
client = 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 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～