- 引言
- 为什么 Agent 应用里缓存格外重要
- OpenAI 与 Anthropic 有什么不同
- 提示词该如何结构化
- 简单的应用示例
- ROI 在什么情况下表现好
- 常见错误
- 迁移清单
- 可以直接分享给团队的结论
- References
引言
Agent 应用比想象中更频繁地重复使用同一个提示词。系统指令、工具说明、政策文档、few-shot 示例、团队共用的工作流文案，在多次请求之间往往不会有太大变化。反而是用户的实际问题或任务数据，通常只是小幅变动。
这时候，提示词缓存就不只是一个细枝末节的优化，而会变成改变产品结构的手段。只要不重新计算相同的前缀提示词，延迟和成本就能同时降低。在多步骤 Agent、系统提示词很长的 copilot、共用工具说明很长的工作流里，效果尤其明显。
本文以 OpenAI 与 Anthropic 的官方文档为准，从实务角度整理 Agent 应用该如何理解并应用提示词缓存。
为什么 Agent 应用里缓存格外重要
比起普通聊天机器人，Agent 应用能从缓存中获得更大收益，原因有三点。
- 系统提示词很长。
- 工具说明和政策文档会反复出现。
- 同一个 Agent 会以相似结构处理多个用户请求。
举例来说，假设一个内部运维 Agent 每次都会发送如下结构。
- 角色与行为规则
- 安全与审批政策
- 可用工具清单与说明
- 响应格式示例
- 实际的用户请求
在这个结构里，前半部分几乎是固定的，只有最后的用户请求会变化。缓存命中良好时，就不需要在每次请求中重新计算这段昂贵的前缀，平均响应时间会缩短，流量增加时单价也更容易控制。
OpenAI 与 Anthropic 有什么不同
两者都致力于降低重复提示词的成本和处理时间，但设计侧重点不同。
OpenAI 的核心要点
根据 OpenAI 官方文档，提示词缓存在近期的大多数模型上自动启用，可用于 gpt-4o 及之后的系列。而且，缓存命中只能发生在完全一致的前缀上。因此把静态的指令和示例放在提示词前部、把用户相关变量放在后部的结构就很重要。
OpenAI 文档还强调了以下两个实务要点。
- 提示词长度达到 1024 token 以上时会自动启用缓存。
- 使用
prompt_cache_key有助于改进路由与缓存命中率。
也就是说，在 OpenAI 这边，"能把前缀维持得多稳定"是最大的设计变量。
Anthropic 的核心要点
根据 Anthropic 官方文档，提示词缓存有助于在重复性任务中降低处理时间和成本。Anthropic 不仅提供自动缓存，还提供显式的缓存断点（cache breakpoint）概念。默认缓存有效期为 5 分钟，额外付费后也可以使用 1 小时缓存。
另一个重要差异在于缓存范围的表达方式。Anthropic 文档说明，缓存对象是按 tools、system、messages 顺序排列的前缀，并且包含到缓存断点为止的部分。
整理如下。
| 项目 | OpenAI | Anthropic |
|---|---|---|
| 基本方式 | 自动缓存 | 自动缓存 + 显式断点 |
| 核心设计要点 | 前缀完全一致 | 缓存断点设计 |
| 关于最小长度的信息 | 1024 token 以上自动缓存 | 官方文档以复用重复前缀为核心说明 |
| 关于缓存有效期的信息 | 官方文档说明了自动维持策略 | 默认 5 分钟，额外付费可延长到 1 小时 |
| 提示词构成的视角 | 静态在前，动态在后 | 断点之前排列可复用资产 |
提示词该如何结构化
实务中，比起"写好提示词"，更重要的往往是"做出可缓存的前缀"。以下模式尤其适合 Agent 应用。
模式 1：把固定资产放在最前面
以下要素应尽量移到前面。
- 系统指令
- 政策文案
- 工具说明
- 共用示例
- 固定的输出规则
相反，以下要素应移到后面。
- 用户问题
- 会话级状态
- 请求级参数
- 会变化的文档片段
[固定系统指令]
[固定政策]
[固定工具说明]
[固定 few-shot 示例]
[每次请求变化的用户输入]
模式 2：按团队标准化前缀
对缓存来说重要的不是"大致相似"，而是"完全相同的前缀"。因此如果各团队使用的指令文案略有差异，缓存命中率很快就会被打破。
比较好的做法如下。
- 把每个 Agent 系列的系统提示词模板统一管理。
- 固定工具说明的排列顺序。
- 不频繁改变 few-shot 示例的数量。
- 如果同时运行多个实验组，需要一并设计缓存 key 策略。
模式 3：把频繁变化的上下文放到后面
RAG 文档、用户画像、工单正文这类经常变化的数据一旦混进前面部分，可缓存的前缀就会变短。这种情况下，最好先放固定的运营规则和工具说明，再把检索结果或用户相关上下文放到后面。
模式 4：在 Anthropic 中把断点看作资产边界
在 Anthropic 中，以"可以在多次请求中复用的资产边界"（例如长篇知识文档、共用政策、工具定义）为基准来设置缓存断点是很有用的思路。先想清楚"要反复复用什么"，再决定断点位置。
简单的应用示例
OpenAI 风格示例
下面的示例展示了把固定前缀放在前面、最后只追加用户输入的结构。
{
"model": "gpt-4o",
"prompt_cache_key": "support-agent-v1",
"messages": [
{
"role": "system",
"content": "You are the support operations agent. Follow the policy, use the available tools carefully, and produce a concise action summary."
},
{
"role": "system",
"content": "Policy: verify account scope, avoid irreversible actions without approval, and log the final decision."
},
{
"role": "system",
"content": "Tool guide: ticket_lookup, refund_policy_check, escalation_create."
},
{
"role": "user",
"content": "Customer asks whether order 48291 can be refunded after partial shipment."
}
]
}
关键在于前三个区块是长期保持不变的固定前缀。这种结构在多次请求中维持得越久，缓存命中的可能性就越高。
Anthropic 风格示例
在 Anthropic 中，把缓存断点之前的前缀看作可复用资产，会更容易理解。
{
"model": "claude-sonnet",
"system": [
{
"type": "text",
"text": "You are the finance operations agent. Apply policy strictly and explain risk before action."
},
{
"type": "text",
"text": "Shared policy and workflow documentation goes here.",
"cache_control": {
"type": "ephemeral"
}
}
],
"messages": [
{
"role": "user",
"content": "Review this reimbursement request and tell me whether it should be approved."
}
]
}
在这个示例中，想要反复复用的共用政策文档被放在了缓存对象边界上。之后即使只改变用户消息，也能构建出复用同一前段的结构。
ROI 在什么情况下表现好
并不是所有服务都能获得同等收益。可以按下面的方式来做现实的判断。
ROI 较高的情况
- 每次都要发送很长系统提示词的 Agent
- 工具说明很多的工作流
- 反复调用同一团队提示词的内部 copilot
- 大量用户共享同一前缀的 B2B SaaS
- 持续引用长文档或政策的业务自动化
ROI 较低的情况
- 每次请求从前半部分开始内容就有很大差异的应用
- 以极短提示词为主的服务
- 前缀每次发布都频繁变化的实验环境
- 用户个性化上下文先于固定内容出现的结构
简单来说，"固定资产越长、重复调用越多、前缀能维持得越稳定"，ROI 就越好。
常见错误
1. 把变量数据混进前面部分
如果用户名、工单编号、最近的事件日志排在系统指令之前，前缀一致性就会被打破。从缓存的角度看，应该最先把固定资产排列好。
2. 滥用相似但不完全相同的提示词
哪怕只是一个标点符号、一个示例、一个工具顺序不一样，命中率也可能下降。团队越多，提示词标准化就越重要。
3. 不区分可缓存资产和实验资产
如果经常做产品实验，系统提示词就会持续变化。这种情况下最好把实验区段和稳定区段分开，至少把共用政策和工具说明固定下来。
4. 在 Anthropic 中把断点放得太靠后
应该让缓存断点之前尽量聚集可复用的资产，如果把断点放在变动性很大的用户数据之后，复用价值就会变小。
5. 在 OpenAI 中不制定 prompt_cache_key 策略、只依赖路由
正如 OpenAI 文档所说，prompt_cache_key 有助于改进路由与缓存命中率。按团队、Agent、版本单位一致地设计 key，运维会更轻松。
迁移清单
引入提示词缓存时，按以下顺序推进在实务上比较稳妥。
- 把当前提示词拆分为固定资产和可变资产。
- 把系统指令、工具说明、示例重新排列到前缀部分。
- 把用户相关数据和请求相关上下文移到后面。
- 制定每个 Agent 系列的标准模板。
- 如果使用 OpenAI，确认实际是否存在 1024 token 以上的重复前缀。
- 如果使用 OpenAI，按团队或 Agent 版本单位确定
prompt_cache_key标准。 - 如果使用 Anthropic，确定要在哪个资产边界设置缓存断点。
- 判断默认的 5 分钟复用是否够用，还是需要 1 小时缓存。
- 上线后一并观察缓存命中率、平均延迟、单次请求成本的变化。
- 让提示词实验与缓存稳定区段分开，避免互相干扰。
可以直接分享给团队的结论
提示词缓存不是单纯削减模型成本的选项，更接近一种让 Agent 提示词设计更有体系的运营原则。在 OpenAI 中，前缀完全一致和前缀排列是核心；在 Anthropic 中，可复用资产和缓存断点设计是核心。
如果 Agent 应用大量使用又长又重复的系统资产，最先该做的不是换模型，而是把提示词重新排列成"可缓存的结构"。仅凭这一点，成本、延迟、运营一致性就有很大概率一起变好。
References
현재 단락 (1/134)
Agent 应用比想象中更频繁地重复使用同一个提示词。系统指令、工具说明、政策文档、few-shot 示例、团队共用的工作流文案，在多次请求之间往往不会有太大变化。反而是用户的实际问题或任务数据，通常...