转载提示：本文转载自 bbruceyuan 原文。原作者：bbruceyuan。原文发布日期：2026-02-22。本文已按站点规范移除原文中的推广/导流内容，仅保留技术分析与示例。0. 阅读收获 (takeaway) 读完本文，你将了解：从 Prompt Engineering 到 Context Engineering 的范式转变为什么 Agent 比普通 Chatbot 更需要 Prompt Caching什么操作会破坏 Cache（比你想象的多）Prompt 布局与动态信息管理的最佳实践工具管理的三种 Cache-aware 方案对比 前置知识：本文假设你已经理解 KV Cache、Prefill/Decode 两阶段、以及 Prompt Cache 的前缀匹配机制。如果不熟悉这些概念，建议先阅读 理解 KV Cache 与 Prompt Caching：LLM 推理加速的核心机制。1. 先说结论：Cache Rules Everything 在深入细节之前，我想先分享我对这个话题的理解： Prompt Cache 不只是一个省钱技巧，它是 Agent 系统架构设计的核心约束。 就像数据库的 schema 设计会影响整个应用架构一样，Prompt Cache 的前缀匹配约束深刻地影响了 Agent 的每一个设计决策：prompt 怎么组织？→ 稳定内容放前面，变化内容放后面工具怎么管理？→ 工具列表固定，通过其他机制限制可用范围状态怎么切换？→ 不切换工具，用工具模拟状态转换（Claude Code Plan Mode 就是最好的例子）context 怎么压缩？→ 压缩操作本身必须 cache-safe模型怎么选？→ 不在同一会话中切换，用子代理隔离1.1 从 Prompt Engineering 到 Context Engineering 我们已经越来越多地听到 "Context Engineering" 这个术语。区别在哪？Prompt Engineering 关注 "怎么写指令让模型表现更好"——内容层面的优化。Context Engineering 关注 "怎么组织整个上下文——指令、工具、历史、外部信息——让 Agent 系统整体高效运转"——系统架构层面的设计。 Manus 在 25 年底最新总结中提出了三个维度：Reduce（缩减）、Isolate（隔离）、Offload（卸载）。 后面的内容你会看到，各家的设计都在围绕这三个维度展开。1.2 三家方案的共同规律 不同公司、不同架构，但核心规律惊人地一致：前缀不变：system prompt、tools、早期历史永远不修改追加不修改：Append-only，永远不编辑历史消息工具定义稳定：tools 数组不变，通过其他机制控制可用范围动态信息后置：时间戳、环境状态等放在后面的 user message 中压缩必须 cache-safe：压缩操作复用父对话的 cache prefix 带着这些规律，我们来看具体的实践。2. 为什么 Agent 比 Chatbot 更需要 Prompt Cache？2.1 Agent 的 I/O 比例严重失衡 Agent 每一步都需要发送完整的对话历史给模型，模型只输出一小段。Manus 披露过一个数据：input:output ≈ 100:1。 如果没有 Prompt Cache → 每一步重新 Prefill 所有历史 token → 成本二次方增长。2.2 经济账 | 场景 | 不缓存 | 缓存后 | 节约 | |------|--------|--------|------| | Claude（正常 vs cached）| $3/MTok | $0.30/MTok | 90% | | OpenAI GPT-5（正常 vs cached）| $10/MTok | $2.50/MTok | 75% | | Claude Code 单任务（约 2M tokens）| ~$6.00 | ~$1.15 | 81% | Thariq（Claude Code 团队）： "Coding agents would be cost prohibitive without prompt caching." OpenAI Codex：cache 命中后，采样开销从二次降为线性。2.3 延迟：TTFT 的大幅改善Manus：KV cache hit rate 是 "the single most important metric"Claude Code 团队：cache 命中率下降 → 当作线上事故（SEV）处理OpenAI：150K+ tokens 时，cached 请求 TTFT 快 67%3. 什么操作会破坏 Cache？ 前缀匹配是一切…