时间过的好快，一眨眼距离上一次发文章，已经过去一个月了，说好的，要把看完的Claude的设计哲学都总结一下的，总结新东西是很痛苦的，但是晚上竟然会做梦，觉得总有一个事没有完成，所以今天必须推动自己继续干。 虽然现在市场上充斥着Skill的概念，但是它依然无法逃出提示词这个概念，在看Claude源码解析之前，我对提示词的认知，确实单纯停留在那几个范式上，什么Few-Shot，思维链，自我一致性等等，但是他们都是从大模型输入角度，以及如何保证大模型输出的稳定性角度来说的。 但是如果你要做一个AI Agent系统，就会变得不一样，它总结下面三个挑战，也是为什么要做提示词架构的核心 体积与成本：完整的系统提示词包含身份介绍、行为规范、工具使用指南、环境信息、内存文件、MCP 指令等十余个段落，总量达数万 token。每次 API 调用都重传这些内容，意味着巨额的 prompt 缓存（prompt caching）成本。
变化频率不一：身份介绍和编码规范在所有用户、所有会话中完全相同，而环境信息（工作目录、操作系统版本）因会话而异，MCP 服务器指令甚至可能在对话中途变化。
多来源覆盖：用户可以通过 --system-prompt 自定义提示词，Agent 模式有专属提示词，协调器模式（coordinator mode）有独立提示词，Loop 模式可以完全覆盖 -- 这些来源之间的优先级必须明确。
对我来说最震撼的是工程师通过精打细算的设计来平衡成本和智能体的稳定性 分段记忆化（Sectioned Memoization） 将提示词拆分为独立段落，每个段落有明确的缓存策略（记忆化 vs. 易变）。通过工厂函数区分两种类型，并为易变类型增加 API 摩擦（DANGEROUS_ 前缀 + 必填reason ）。解决的问题：大型提示词中部分内容是静态的、部分是动态的，全量重算浪费资源。 MCP 工具触发全局缓存降级 当存在 MCP 工具时， splitSysPromptPrefix 自动降级到 org 级别缓存。这个决策基于一个工程判断：MCP 工具的 schema 是用户级别的动态内容，即便系统提示词中的静态区可以全局缓存，工具 schema 块的存在意味着 API 请求中已经有了无法全局缓存的大块内容，系统提示词的全局缓存带来的边际收益不足以证明额外的复杂性。
写在最后，之前我参与了一个Agent系统的研发，当时我们也做了一个CodeAgent，当时想当然就利用智能体框架，将工具，提示词，上下文，还有模型全部给到了大模型，也没考虑太多Token，但是带来的问题就是运行速度，缓存，以及稳定性问题，读完它的设计后，发现原来分层架构设计可以如此优雅，不仅考虑IO加载的速度，同时考虑多场景缓存命中率，和执行效率的问题，同时最震撼的是记忆优化，让我知道了一个好的Agent会有如此多的工程化思考.
夜雨聆风