以下内容涉及生产级 Agent 的架构细节，初次阅读可以跳过，在实际开发 Agent 时回来参考。
在生产级的 Agent 系统中，缓存不仅仅是性能优化手段——它是一个**架构约束**，决定了系统中许多看似无关的设计决策。
Claude Code 的实践揭示了一个深层的模式：当 Prompt Cache 的经济效益足够显著时，缓存一致性会反过来主导系统的架构选择。以下是几个体现这种约束的设计决策：
**提示词的结构由缓存边界决定**。系统提示词在物理上被一个缓存边界标记一分为二——标记之前的内容可以跨用户、跨会话进行全局缓存，标记之后的内容则包含用户和会话的特定信息。这意味着提示词的排列顺序首先由缓存的经济性决定，其次才是语义逻辑。每个运行时条件（操作系统类型、当前模式、用户偏好等）如果被放在缓存边界之前，就会把缓存键的变体数量翻一倍（若每个条件都是二值的，N 个条件就会产生 2^N 种组合），因此所有的动态元素都被严格归类到边界之后。例如，如果有 3 个条件（macOS/Linux、普通/调试模式、中文/英文），就会产生 2×2×2 = 8 种不同的缓存键。提示词片段在类型层面被区分为“可缓存”和“会破坏缓存”两类，后者的命名中包含显式的警告标记。
**子 Agent 必须与父 Agent 字节级对齐**。当主 Agent 派生子 Agent 或进行旁路查询时，子 Agent 的提示词、工具定义、模型配置、消息前缀和思考配置必须与父 Agent 的缓存键逐字节匹配。这样做的原因是：子 Agent 发起的 API 请求如果前缀与父 Agent 的请求一致，就能命中 API 服务商的 Prompt Cache，从而减少计费和延迟。这个约束从缓存层向上传导，影响了 Agent 的生成方式和参数传递机制。
**工具结果的替换字符串在首次出现时就被冻结**。当大型工具输出被替换为摘要预览时，替换后的字符串会被持久化保存。即使后续会话重启，系统也会使用完全相同的替换字符串——以保证恢复后的消息序列与缓存中的字节流一致，避免缓存失效。
这些设计选择的核心启示是：**在设计 Agent 架构时，缓存经济性不是事后优化，而是前置约束**。如果你的 Agent 系统使用了 Prompt Caching，那么缓存键的一致性要求会渗透到提示词设计、多 Agent 协调、会话恢复等各个层面。越早将这个约束纳入架构设计，后续的工程代价越小。
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/lj1109053360/article/details/169245116
