在大规模、低成本运行 agent 时，一个很有力的杠杆是提示词缓存（Prompt Caching）。这是模型提供商提供的一项功能，可以把推理的 token 成本降低 41–80%。正如 Manus AI 所说：
“如果只能选一个指标，我会说 KV-cache 命中率是生产阶段 AI agent 最重要的单一指标。”
不过，不同模型提供商支持的缓存控制策略各不相同，所以要做出一套不绑定具体提供商的缓存方案，会更棘手一些。
Deep Agents 是我们通用的、模型无关的 agent 运行框架，支持所有主要提供商的提示词缓存功能。我们接下来会深入看看 Deep Agents 如何用提示词缓存来降低 API 成本；但在此之前，先看看提示词缓存如何降低聊天模型对话里的 token 成本。
TL;DR：提示词缓存
聊天模型对话的 token 成本增长得很快。每出现一条新消息，模型都必须重新处理对话中此前的所有 token，包括：
- 系统提示词
- 工具描述
- 已加载的技能
- 消息历史
- 新消息
当我们选择启用提示词缓存时，提供商会在处理完一段提示词后，把模型状态保存成一个快照：
下一次请求时，模型会从这个快照继续，只处理新文本。
不过，加载新的技能或工具，可能会修改对话中更靠前位置的提示词，从而让缓存失效。有些模型提供商允许我们在提示词的较早位置显式添加缓存断点，这样即使不能命中完整提示词，也能命中其中一部分，而不是整个缓存都失效。不过，并不是所有模型提供商都支持显式缓存断点：
| Anthropic | OpenAI | Gemini | Fireworks | Baseten | |
|---|---|---|---|---|---|
| 显式断点 | ✅ | ❌ | ✅ | ❌ | ❌ |
显式缓存也只是提示词缓存功能中的一种，而且不同提供商的支持情况差异很大：
| Anthropic | OpenAI | Gemini | Baseten | Fireworks | |
|---|---|---|---|---|---|
| 显式断点 | ✅ | ❌ | ✅ | ❌ | ❌ |
| 可配置 TTL | ✅ | 取决于模型 | ✅ | ❌ | ❌ |
| 缓存预热 | ✅ | ❌ | ❌ | ❌ | ❌ |
| 路由键 | ❌ | ✅ | ❌ | ❌ | ✅ |
提示词缓存功能的支持情况变化很快。关于功能支持，请务必查看模型提供商的文档。
由于各家提供商的提示词缓存实现和功能支持不同，要在多个提供商之间实现最大的成本节省，并不容易。
我们在 Deep Agents 里是怎么解决的
Deep Agents 运行框架会尽力利用提示词缓存功能，自动完成以下几件事：
- 在提供商支持时设置显式缓存断点
- 在不支持显式断点时，选择启用提供商侧的隐式缓存
- 组织你的提示词，让缓存读取最大化
这些策略支持所有主要提供商，所以你可以随时切换提供商，同时仍然尽可能多地节省 token。为了利用特定提供商的功能，这个框架会检测当前模型提供商，并把缓存交给提供商专用中间件处理。你也可以在自己的 createAgent() 中使用这些中间件，获得提示词缓存带来的节省：
// In Deep Agents you get prompt caching for free!
const agent = createDeepAgent({
model: "gpt-5.5",
});
// In LangChain, opt in via our middleware:
const agent = createAgent({
model: "claude-haiku-4-5-20251001",
middleware: [anthropicPromptCachingMiddleware()],
});
Deep Agents 运行框架也会组织你的提示词和显式缓存点，尽量减少缓存退化。理想情况下，一次模型调用里的静态前缀（你的工具描述、技能、系统提示词）应保持不变。但在更新记忆或压缩对话等情况下，它确实可能发生变化，导致缓存失效。Deep Agents 会通过组织提示词和显式缓存点来缩小影响范围：例如，当一段记忆被更新时，你仍然可以命中提示词中某个子集的缓存。
提示词缓存真正能省多少
功能表告诉我们哪些事情是可能的。为了看看提示词缓存到底能省多少，我们让 Deep Agents 的 eval suite 分别跑在三家提供商的一款中档模型上：claude-haiku-4-5、gpt-5.4-mini 和 gemini-3.5-flash。结果见下图。在真实 agent 轨迹上，提示词缓存把 token 成本降低了 49–80%。
- claude-haiku-4-5：-77%。借助 Anthropic 的显式断点，我们可以让提示词中的很大一部分保持缓存状态。这显著降低了每次请求的 token 成本。
- gpt-5.4-mini：-80%。OpenAI 的自动最长前缀缓存带来了可观的 80% 成本下降。
- gemini-3.5-flash：-49%。Gemini 的隐式缓存不对节省幅度做显式保证，但我们仍然看到了相当大的节省。
还有一点值得注意：对话越长，缓存的收益越高。缓存前缀会在每一轮中复用，所以长周期任务受益最大。
用 LangSmith 做可观测性
提示词缓存带来的成本节省，只有在你能衡量它时才真正有意义。LangSmith 可以在单次调用和整条轨迹两个层级上，让你看到 API 成本、缓存读取和 token 用量：
对每次调用，你都能看到首 token 时间、总输入 token、缓存读取 token 和总输出 token，并汇总到每条轨迹上。因为缓存读取会单独列项，所以你可以准确看到每段提示词里有多少内容是从缓存返回的，而不是重新处理出来的。
这也是我们在这篇文章里得到这些数字的方法：
- 针对每个 agent 配置运行 Deep Agents eval suite
- 在 LangSmith 仪表盘里检查 trace 数据，验证运行结果
- 通过 LangSmith Client SDK 拉取运行数据
- 把数据放进 Jupyter notebook 里计算各提供商的成本差异（或者让 agent 使用 LangSmith Skills 来帮忙）
LangSmith 让我们能够拆分缓存、轨迹长度和更便宜的轮次分别带来的节省，这可以指导我们如何优化自己的 agent。关于如何在 LangSmith 中读取并使用这些数据，这里有更多说明。
提示词缓存的下一步
模型提供商还没有在提示词缓存上收敛到一套共同的功能集。上面的结果里，显式断点带来了一些节省，但这只是开始。还有少数其他功能——缓存预热、路由键、可配置 TTL——有望进一步释放成本节省和延迟收益。
你现在就可以通过使用 createDeepAgent 来利用目前已支持的功能，不需要额外配置。随着模型提供商增加更多功能支持，我们会继续把它们整合进现有框架里。