Agent 系统里上下文缓存有什么价值，如何用它处理频繁复用的系统指令并降低冗余上下文成本？｜蚂蚁集团算法面经解析

60 秒回答模板

我会先把 Agent prompt 拆成稳定段和动态段。稳定段包括 system instructions、工具协议、行为规范、安全策略和固定格式要求，这些内容 token 多、重复率高，适合做 provider prefix prompt caching 或应用侧模板缓存；动态段包括用户当前问题、会话短期记忆、检索结果、工具返回和权限上下文，不应盲目跨请求缓存。缓存 key 要包含模型版本、系统指令版本、工具 schema 版本、策略版本、租户或权限作用域，避免旧指令被错误复用。需要注意：多数 provider prefix caching 仍然让稳定前缀在语义上参与本次输入，只是降低重复前缀的计费或延迟；只有少数运行时支持真正的上下文句柄或 delta 提交。因此工程表述应是“稳定前缀可被缓存复用并减少重复处理成本”，而不是默认不再提交系统指令。这样既降低重复系统指令成本，又不会牺牲安全和语义一致性。

考点 稳定前缀

难度 真实面经题

回答目标 体现你理解 prompt caching 不只是性能优化，而是 Agent 上下文工程、版本治理和安全隔离问题。

深入解析

拆分稳定和动态上下文

Agent 上下文里有大量重复内容，如角色设定、输出格式、工具协议、安全边界、公司规范和 MCP 工具说明。这些跨请求基本不变，适合缓存。用户当前问题、实时检索材料、工具返回、短期对话状态和权限令牌高度动态，不能简单混入长期缓存。

设计缓存 key 和版本

prompt cache 的 key 不能只按文本哈希，因为系统指令语义依赖模型版本、工具 schema、策略版本和租户配置。稳妥 key 应包含 modelId、systemPromptVersion、toolSchemaVersion、policyVersion、locale、tenantId 或权限域。

复用重复系统指令

执行时可以把 system instructions 和工具说明放在 prompt 前缀作为可缓存 prefix。Provider prompt cache 通常仍要求前缀出现在请求语义里，只是复用已处理前缀来降低计费或延迟；应用侧模板缓存则减少服务端拼装和版本管理成本。只有具备上下文句柄的运行时才可能真正只提交动态增量。长工具说明还可以模块化，只加载当前 allowlist 内工具 schema，提高缓存命中率并减少上下文噪声。

防止缓存污染

任何包含用户数据、检索内容、工具返回、访问 token、临时授权和个性化偏好的片段，都必须明确作用域，不能进入全局缓存。缓存写入也应只允许可信模板和服务端配置，防止 prompt injection 把用户内容伪装成系统指令进入缓存。

评估收益和一致性

缓存效果要看命中率、首 token 延迟、总推理成本、上下文长度、答案质量和策略一致性。不能只看成本下降，因为过度缓存可能导致工具说明过期、系统指令不一致或动态上下文被错误省略。

易错点

把整段会话上下文都缓存，导致用户数据或权限信息跨会话泄漏。
缓存 key 只用文本哈希，忽略模型版本、工具版本和策略版本。
为了缓存命中率把所有工具说明都放进前缀，导致上下文过长和工具选择混乱。
没有记录缓存版本，线上行为异常后无法回溯 Agent 遵循了哪版系统指令。

面试官追问

哪些内容绝对不能进入全局 prompt cache？

用户私有输入、检索结果、工具返回、权限令牌、临时授权、个人偏好和模型生成内容都不应进入全局缓存。它们最多只能进入有明确会话或租户作用域的短期缓存。

工具 schema 很多时如何提高命中率？

把工具说明模块化，按任务和 allowlist 加载当前可用工具，而不是把所有工具塞进固定前缀。也可以把通用协议和具体工具 schema 分层缓存。

系统指令更新后如何避免命中旧缓存？

把 systemPromptVersion 和 policyVersion 放入缓存 key，发布新策略时主动失效旧 key，并在日志中记录每次请求使用的版本，便于回溯。

如何检测缓存引入的行为不一致？

做灰度对照：完整 prompt 和缓存前缀分别跑同一评测集，对比工具调用准确率、答案一致性、安全违规率、延迟和成本，同时采样线上 badcase。