Agent 的缓存机制不能只理解成“把大模型回答存起来”，更准确地说，要按 Agent 的执行链路分层缓存：输入理解、上下文构造、工具调用、RAG 检索、模型推理结果、长期记忆都可能有缓存点。

最基础的是 确定性缓存。如果一次 Agent 请求的 user input + system prompt + tool schema + model version + temperature + memory snapshot 完全一致，就可以生成一个稳定的 cache key，把最终响应或中间结果缓存起来。这个适合 FAQ、固定流程、低温度模型输出、重复工具调用等场景。cache key 里一定要包含模型版本、提示词版本、租户 ID、权限范围等信息，否则很容易出现串租户、旧提示词污染新结果的问题。

但 Agent 场景中，用户表达经常不完全一致，所以还需要 语义缓存。做法是把用户问题向量化，存入向量库或 Redis Vector 之类的存储中；新请求进来后先做相似度检索，如果命中相似问题，并且上下文、权限、数据版本都一致，就复用之前的答案或执行轨迹。这里不能只看向量相似度，还要加业务约束，比如用户身份、数据时间范围、工具结果版本，否则“看起来类似”的问题可能实际答案完全不同。

更实用的缓存点通常在 工具调用层。Agent 调数据库、搜索、HTTP API、代码执行器、浏览器环境时，很多结果比 LLM 输出更稳定，也更值得缓存。例如天气、商品详情、文档片段、接口列表、用户配置，都可以按参数做缓存，并设置 TTL、ETag、版本号或数据更新时间。这样即使最终回答不缓存，也能减少工具延迟和外部依赖压力。

对于 RAG 型 Agent，还要缓存 embedding、检索结果和重排结果。文档切片生成 embedding 成本较高，应按文档版本缓存；用户 query 的 embedding 也可以短期缓存；检索出的候选 chunk 和 rerank 结果也可以缓存。但如果知识库更新，需要通过文档版本、索引版本或 namespace 隔离，避免旧内容继续参与回答。

模型侧还可以利用 Prompt Cache / KV Cache。如果 system prompt、工具说明、长文档上下文这类前缀内容经常重复，可以让模型服务缓存前缀 token，减少推理成本。这个更多依赖模型供应商能力，但工程上要保证 prompt 前缀稳定，不要把随机时间戳、请求 ID 放在前缀里破坏命中率。

Agent 缓存还要处理一个关键问题：缓存的是结果，还是过程。只缓存最终答案实现简单，但可控性弱；缓存工具结果、检索结果、规划步骤、反思结果，可以让 Agent 在后续执行中复用中间状态，也更容易调试。复杂 Agent 通常会把一次运行抽象成 trace：每一步的输入、输出、工具调用、token 消耗、耗时和错误都记录下来，其中可复用的节点进入缓存。

失效策略非常重要。Agent 缓存通常不能只靠永久缓存，应该结合 TTL、数据版本、主动失效和权限变更失效。比如用户权限变化后，相关缓存必须清掉；知识库重建索引后，旧检索缓存必须失效；工具 schema 变更后，历史 tool call 缓存也不能直接复用。

最后是安全和观测。缓存要做租户隔离、权限隔离、敏感信息脱敏，不能把一个用户的上下文复用给另一个用户。同时要监控命中率、节省 token、平均延迟、错误复用率和缓存污染率。Agent 缓存不是命中率越高越好，而是要在成本、延迟、准确性和安全性之间取平衡。