长程Agent每多走一步，就要把系统提示和工具定义重新喂一遍模型。这件事本身有解——Prompt缓存：把稳定前缀缓存一次，之后每次只按原价1折（Anthropic）或5折（OpenAI）读取。问题在于，绝大多数Agent框架要么默认不开启，要么主动把缓存打散。一个真实团队把缓存命中率从7%提到74%，当月推理账单直接砍掉59%。本期实测六大主流Agent栈的"缓存断点税"：谁开箱即得折扣、谁需要手动埋断点、谁在每一轮循环里默默把token烧成灰。
Agent不是一次性问答，而是一个不断膨胀的循环：系统提示 + 工具定义 + 对话历史，每一轮都重新发送。假设稳定前缀（系统提示+工具Schema）为8000 token，一个30步任务：
比值约7.2倍。这就是Codex CLI强调"exact-prefix caching keeps the agent loop closer to linear"的底层逻辑——缓存把循环成本从近二次方压回线性。但前提是：前缀真的稳定、断点真的埋对、框架真的不捣乱。arXiv 2601.06007《Don't Break the Cache》在500–50000 token、3–50次工具调用的消融中证实：agentic工作流会系统性地破坏缓存，上下文越大、调用越多，浪费越夸张。
| 框架/栈 | 缓存默认状态 | 断点控制 | 理论最大折扣 | 典型生产命中率 | 未调优浪费 |
|---|---|---|---|---|---|
| OpenAI Agents SDK | ✅ 隐式自动 | ❌ 无（系统托管） | 50%读 | 20–40% | 中 |
| LangGraph + Anthropic | ⚠️ 中间件opt-in | ≤4 手动断点 | 90%读 | 30–75%（调优后） | 中 |
| CrewAI | ❌ 关（需手动） | 无原生，经LiteLLM | 90%可达但难 | <30% 常见 | 高 |
| Microsoft Agent Framework | ⚠️ 部分自动 | 有限，依后端 | 50–90% | 视模型而定 | 中 |
| Anthropic SDK 直连 | ⚠️ 显式（默认关） | ≤4 全控 | 90%读 | 70%+（懂行） | 低 |
| LiteLLM 代理/路由 | ⚠️ 部分透传 | 跨厂商有损 | 折扣被稀释 | 不稳定 | 高 |
注：折扣数据来自Anthropic/OpenAI官方文档；命中率区间综合agentmarketcap生产案例与社区基准，"未调优浪费"为基于成本模型的相对评估。
OpenAI的Prompt缓存是隐式且自动的：任何超过1024 token的前缀，系统自动尝试缓存，代码一行都不用改，usage.cached_tokens直接回报命中量。这对OpenAI Agents SDK用户意味着开箱即得约5折的缓存输入折扣，零配置心智负担。
代价是天花板很低且不可控。第一，折扣封顶50%，远低于Anthropic的90%；第二，缓存阈值1024 token意味着短任务根本进不了缓存；第三，OpenAI自动缓存对前缀稳定性极度敏感——SDK若在系统提示里注入时间戳、会话ID或随机few-shot，每次前缀都变，缓存形同虚设；第四，一旦你把SDK指向非OpenAI模型（如Claude），这套自动机制完全失效，cache_control不会自动迁移。
# OpenAI: 自动缓存，只需读取 usage 确认命中
resp = client.responses.create(model="gpt-4o", input=msgs)
cached = resp.usage.input_tokens_details.cached_tokens # 命中量
# ⚠️ cached 若长期为 0，说明前缀在漂移
变现评估：作为"零配置省钱"的卖点，适合做企业入门级Agent FinOps培训，但深度不足，难撑高价训练营。
LangChain生态对Anthropic缓存的支持藏在 AnthropicPromptCachingMiddleware 里——一个必须显式挂载的Agent中间件。它会自动给稳定的系统消息和工具定义打上cache_control标记，并通过model_settings透传，理论上能拿到90%读折扣。
问题是双重脆弱。其一，opt-in意味着不挂中间件就一分钱折扣都没有，新手几乎全军覆没；其二，该中间件有已知Bug（GitHub issue #33709）：与ModelFallbackMiddleware同用时，cache_control会破坏模型降级链路，迫使你在"要缓存"和"要容灾"之间二选一；其三，LangChain的对话记忆（memory）常在系统提示后插入动态摘要，把断点之后的稳定区也污染掉。
# LangGraph: 必须显式挂中间件才有缓存
from langchain_anthropic import AnthropicPromptCachingMiddleware
agent = create_react_agent(
model=ChatAnthropic(model="claude-sonnet-4-6"),
tools=tools,
middleware=[AnthropicPromptCachingMiddleware()], # 关键一行，漏掉=白烧
)
变现评估：这是最有料的培训题材——"LangGraph缓存调优+fallback兼容"能直接做成中高级工程师实战课，客单价可拉高。
CrewAI底层走LiteLLM，自身没有原生的cache_control抽象。社区要实现缓存，得手动拼装"CrewAI + mem0 + 手动Prompt Caching"的方案（见Medium实战文），等于把缓存责任完全甩给开发者。结果是：大多数CrewAI项目的缓存命中率长期低于30%，工具Schema和角色定义（role/goal/backstory）每一轮都全价重算。
CrewAI的设计哲学（角色化、丰富的系统提示）反而放大了缓存损失——它的系统提示本就冗长稳定，是最该被缓存的，却最容易被忽略。LiteLLM的content-cache透传对Anthropic支持尚可，但对OpenAI与Gemini的跨模型路由会触发缓存失效（缓存按model+org隔离）。
# CrewAI: 无原生开关，只能在 LiteLLM 层手工打标
# 必须确保 role/goal/backstory 位于稳定前缀，工具定义排序固定
crew = Crew(agents=[...], tasks=[...]) # 默认无 cache_control
变现评估：适合"低成本原型→生产成本审计"的诊断型咨询，给已经上线的CrewAI项目做缓存体检，按节省比例抽成。
直接用Anthropic SDK是控制力最强的路径：最多4个显式cache_control断点，支持5分钟（默认）和1小时（ttl:"1h"）两种TTL。1小时缓存对"会暂停等待人工反馈"的长程Agent是杀手锏——写入成本翻倍（2倍），但只要TTL内命中一次就回本，之后全是0.1倍读取。
代价是全部手工。断点位置、TTL选择、前缀稳定性维护全靠开发者把关。最大的陷阱是"断点放错"：把断点放在动态内容之后等于没放；超过4个断点会被API拒绝；最小可缓存前缀约1024 token以下不生效。
# Anthropic 直连: 手工埋断点，系统提示+工具放最前并标记缓存
client.messages.create(
model="claude-sonnet-4-6",
system=[{"type":"text","text":BIG_SYSTEM,
"cache_control":{"type":"ephemeral","ttl":"1h"}}], # 长程用1h
messages=msgs,
)
变现评估："Anthropic缓存架构设计"是高价值咨询，尤其对长程编码Agent（类Codex），可做1对1架构review。
BUILD 2026上微软把AutoGen正式升级为Microsoft Agent Framework（Agent Harness、Hosted Agents、CodeAct）。但就Prompt缓存而言，它继承的是多后端路由的通病：缓存能力完全取决于你接的后端模型，框架本身不做断点优化。接OpenAI得隐式5折，接Anthropic需要开发者自己在message层埋cache_control，框架不代劳。
对多Agent研究型场景（Agent Framework的强项），频繁的角色切换和消息广播天然不利于前缀稳定——每个Agent的系统提示不同，缓存复用率被稀释。
变现评估：偏研究/企业级，缓存不是它的卖点，更适合做"多Agent架构"主题课，缓存作为成本章节附带。
LiteLLM作为统一网关/代理，承诺一套API调所有模型。但在缓存这件事上，透传即有损：它对Anthropic的content-cache有一定支持，对OpenAI依赖后端自动，跨模型路由时缓存按model+org隔离直接失效。更隐蔽的是，LiteLLM的请求改写（重试、参数注入、fallback切换）可能微调前缀，导致看似命中实则miss。
对追求"成本最优"的团队，LiteLLM的统一性是双刃剑：便于做模型路由降本，但缓存优化必须下沉到具体后端，不能指望网关层统包。
# LiteLLM: 跨厂商路由会稀释缓存，需针对每个后端单独验证 cached_tokens
litellm_settings:
cache: true # 注意: 这是 LLM 响应缓存，不等于 prompt prefix cache
# content-level caching 需针对 anthropic 单独配置
变现评估：适合"统一网关成本治理"咨询，但要诚实告知客户缓存需按厂商拆分优化。
实测发现，框架"破坏缓存"的方式比"不开缓存"更阴险，因为开发者以为开了其实没生效：
当前思考...前缀 → 每轮前缀都变 → 全量miss；这6条每命中一条，账单就悄悄上一个台阶。agentmarketcap那个案例的本质就是修正了第1、3条，命中率才从7%跃到74%。
flowchart TD
U[用户请求] --> L[Agent Loop 第N轮]
L --> P{前缀是否稳定?}
P -->|动态内容在断点前| MISS[❌ 缓存失效<br/>全价重算 prefix]
P -->|稳定前缀 + 正确断点| HIT[✅ 缓存命中<br/>1折/5折读取]
MISS --> COST1[账单 ×7 浪费]
HIT --> COST2[成本回到线性]
HIT --> T{命中后}
T -->|5min内活跃| KEEP[续命]
T -->|等待人工>5min| DECAY[缓存过期<br/>需1h TTL续命]
style MISS fill:#f4cccc
style HIT fill:#d9ead3
style COST1 fill:#f4cccc
style COST2 fill:#d9ead3
把上面的逻辑落到一个可复用的成本模型。设稳定前缀S=8000 token，N=30步任务：
| 策略 | 前缀等效输入token | 相对最优 |
|---|---|---|
| 不开缓存 | 8000 × 30 = 240,000 | 7.3× |
| OpenAI隐式（5折，命中率30%） | 240000×0.7 + 240000×0.3×0.5 ≈ 204,000 | 6.2× |
| Anthropic显式（命中率74%） | 8000×1.25 + 8000×0.1×29 ≈ 33,200 | 1.0×（基准） |
| Anthropic显式（命中率30%） | 8000×1.25 + 8000×0.7 + 8000×0.1×29×0.3 ≈ 84,520 | 2.5× |
模型为简化估算（假设历史增量与工具结果对前缀缓存的影响近似），实际随任务结构浮动，但量级结论稳健：调优到位可省约七成，不调优等于白烧。
结论很直接：同样的模型、同样的任务，缓存调优与否，账单差5–7倍。这就是"断点税"——不是模型的税，是框架默认值和开发者认知的税。
cached_tokens，长期为0就说明前缀在漂移，立刻排查动态注入。ttl:"1h"断点，把循环压回线性。这是性价比最高的组合。AnthropicPromptCachingMiddleware，但别和ModelFallbackMiddleware同用（#33709），改用应用层重试。通用三条铁律：(1) 稳定内容永远在动态内容之前；(2) 工具列表固定排序；(3) 监控cached_tokens/缓存命中率，把它当一等公民指标——agentmarketcap的案例证明，这是从7%到74%、砍掉59%账单的唯一杠杆。
缓存不是"开了就省钱"的开关，而是一项需要持续维护的工程。Agent走得越长，这项工程的价值越大——断点埋对，七成token就能从灰烬里捡回来。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。