这个选题要兼顾工程细节和面试表达，我先找 agent memory 与语义缓存的最新实践和评测。
这套架构真正要解决的问题只有一个：这一轮调用，到底该让模型看见什么。全量历史塞进 Prompt 的做法在 demo 里很爽，在生产里很快会撞上三堵墙 —— 成本、延迟、注意力衰减。公开评测里，全上下文方案在 LoCoMo 上只能拿到约 35% 的准确率，单次检索要烧掉 25000 多个 token；而做了选择性记忆提取的方案能把单次检索压到 7000 token 以内，同时把准确率拉到 90% 以上。语义缓存则是另一道闸门，但它的真实命中率远没有厂商宣传的那么高：生产环境通常只有 20% 到 45% 的流量能被语义命中，而且阈值调到 0.85 依然会把 “今天天气” 答成 “明天天气”，因为这两句话的余弦相似度有 0.909。所以一套能过面试、也能上生产的方案，必须同时回答四个问题：工作记忆留多少、长期记忆写什么、检索靠什么信号、缓存凭什么敢直接返回。
面试官真正想听的那句话
多数人一上来就讲 “用 Milvus 存向量、用 Redis 做缓存”，这属于选型，不是架构。能被追问三层还不崩的回答，通常是这个结构：
我会把上下文拆成三层记忆和两道闸门。三层是工作记忆、任务状态、长期记忆，分别解决 “这一轮看什么”“这个任务进行到哪”“这个人是谁”；两道闸门是精确缓存和语义缓存，前者拦完全重复，后者拦换个说法的重复。写入侧比检索侧更难，因为要处理冲突、过期和权限；缓存侧比命中率更难的是防止错误命中，所以必须加实体校验和边界复核。
这句话之所以站得住，是因为它先定义了边界，再谈组件。下面按这个顺序拆。
第一层：工作记忆，控的是这一轮
工作记忆就是你准备塞进 context window 的那部分，它必须小、必须准、必须有预算。
| 组成 | 放什么 | 预算建议 | 淘汰方式 |
|---|---|---|---|
| 静态前缀 | system prompt、工具 schema、输出格式约束 | 20%—30% | 不淘汰，按版本号缓存 |
| 近期对话 | 最近 8—12 轮原始消息 | 30%—40% | 滑动窗口，先进先出 |
| 任务状态 | 当前目标、约束、已完成步骤、待确认问题 | 10%—15% | 结构化覆盖写 |
| 工具结果 | 最近调用的返回，超长截断或摘要 | 15%—20% | 只留最近 N 条 + 摘要 |
| 检索片段 | 长期记忆召回的内容 | 10%—15% | 按相关性排序截断 |
| 输出预留 | 留给模型生成 | 10% | 固定预留 |
这套比例不是标准答案，但它能防住一个常见事故：工具返回了一大坨 JSON，把最近几轮对话挤出了窗口，模型于是 “忘了” 用户刚说的约束。工程上的做法是给每个区块设硬上限，超了就摘要，不要指望模型自己忽略噪音。
静态前缀还有个隐藏收益：它天然适合做前缀缓存（prompt caching）。system prompt 和工具 schema 只要不变，这部分 KV 可以复用，TTFT 会明显下降。所以别把动态内容拼到最前面，那等于每次都让缓存失效。
第二层：任务状态，控的是一个任务
这一层最容易被忽略，却最能提升稳定性。多轮 Agent 翻车，很多时候不是记不住历史，而是没有一份 “当前任务到底进行到哪” 的结构化状态。
| 字段 | 例子 | 为什么不能只靠向量 |
|---|---|---|
| goal | 给订单服务加幂等校验 | 目标是判断相关性的锚点 |
| constraints | 不改动对外 API 签名、必须兼容旧数据 | 约束丢了就会给出违规方案 |
| decisions | 已选定用 Redis 分布式锁 | 决策需要精确复述，不能被语义近似 |
| artifacts | 已修改的文件、已生成的 SQL | 路径和标识符必须逐字匹配 |
| open_questions | 等待用户确认超时时间 | 待办不丢，才不会重复提问 |
这层建议放 Redis 或关系库，用 KV 精确读写，不要走向量。原因很直白：order_id=123 和 order_id=124 在向量空间里几乎是同一个点，但业务上是两件事。语义检索适合 “找相关内容”，不适合 “取准确状态”。
生命周期也跟着任务走：任务结束打快照，24 小时后归档；跨天未完成的任务保留状态、丢弃过程。
第三层：长期记忆，控的是跨会话
长期记忆不是一个向量库，至少要分四类，因为它们的写入方式、检索方式、过期策略完全不同。
| 类型 | 存什么 | 存储形态 | 读法 |
|---|---|---|---|
| 情节记忆 | 历史会话、执行轨迹、工具调用记录 | 向量库 + 时间戳 | 语义召回 + 时间衰减 |
| 语义记忆 | 稳定偏好、身份事实、长期约定 | KV / 文档 + 实体索引 | 精确读 + 实体匹配 |
| 时序事实 | 带有效期的状态，如 “住在杭州” 到 “搬到成都” | 时序图或带 valid_from/valid_to 的表 | 按时间窗口过滤 |
| 程序性记忆 | 规则、技能、SOP、AGENTS.md | 文件或版本化知识库 | 直接注入，不参与相似度检索 |
时序这一类的价值，用一个例子就能说清：用户先说住在杭州，三个月后说搬到成都。纯向量库会把两条一起召回，模型拿到互相冲突的事实，只能瞎猜。时序图给每条边打两个时间戳 —— 事实在世界里成立的时间、系统获知的时间 —— 查询时按 “当前有效” 过滤，冲突自然消失。
大厂的真实做法也能印证这个方向。LinkedIn 的招聘助手把长期记忆做成了一棵按业务结构对齐的层级树，每个节点存三视图：facet 键值对、可回答的问答对、摘要；检索时先按身份限定子树，再做混合检索，这样权限隔离和隐私约束是靠拓扑保证的，不是靠后置过滤。公开数据是答案正确率提升 5% 以上、检索 F1 提升 10% 以上，记忆模块在 40% 以上的会话里被主 Agent 主动调用。
腾讯开源的 TencentDB Agent Memory 则是另一种分层：L0 原始对话全量留底，L1 抽原子记忆（事实、偏好、约束、阶段结论），L2 按任务聚成场景块，L3 蒸馏用户画像。评测里 WideSearch 成功率从 33% 到 50%，token 消耗降 61.38%；SWE-bench 从 58.4% 到 64.2%，token 降 33.09%；PersonaMem 从 48% 到 76%。这组数字说明分层不是为了好看，省 token 和提准确率可以同时发生。
写回比检索更难：四个必须回答的工程问题
写什么。 只写四类：事实、偏好、约束、决策。寒暄、临时情绪、一次性查询结果不写。写入门槛可以用一个便宜模型做分类，别让主模型兼职做记忆管理，那会把延迟拖垮。
冲突怎么处理。 两种主流路线：一种是 ADD-only，新事实只追加不覆盖，旧的保留，检索时按时间加权；另一种是提取时合并，冲突就更新。ADD-only 的好处是可追溯、不会静默丢历史，代价是库会变大，需要衰减机制。Mem0 现在的做法是 ADD-only 加 0.3 到 1.5 倍的近因加权，做软排序而不是硬删除 —— 过期记忆不会消失，只是排后面，万一它真的是最佳匹配还能被召回。
过期怎么判。 三类时间语义要分清：事实有效期（什么时候成立）、记录时间（什么时候写入）、访问时间（最后一次用到）。只用一个 updated_at 是不够的，会把 “很久没提但依然有效” 的偏好误判成过期。
权限怎么隔离。 记忆必须按 tenant、user、project 分作用域，检索前限定范围，而不是召回后再过滤。后者一旦漏了，就是跨租户数据泄露。写入侧还要做注入扫描 —— 用户可以让 Agent “记住” 一段恶意指令，这条记忆会在未来所有会话里生效，这是记忆系统独有的攻击面。
检索：别只走向量
单一向量检索在记忆场景里表现一般，因为记忆查询经常带实体、带时间、带精确标识符。
| 信号 | 解决什么 | 典型用法 |
|---|---|---|
| 稠密向量 | 换了说法的相似内容 | 初次召回，取 top 50 |
| BM25 / 关键词 | 专有名词、代码符号、错误码 | 与向量结果融合 |
| 实体匹配 | 同一个人、账号、项目 | 实体索引加权 |
| 时间新近性 | 近期事实优先 | 乘一个衰减系数 |
| 图关系 | 多跳关联，A 的项目关联到 B | 时序图扩展一跳 |
融合之后再 rerank，最后按 token 预算截断。这里有个容易被忽略的指标：检索的价值不看召回条数，看 “塞进去的 token 有多少真正被用到”。LinkedIn 那套方案把记忆节点做成摘要 + 问答对 + 键值三种视图，本质上就是在提高单位 token 的信息密度。
语义缓存：省钱的第二道闸门
缓存要分两级，别一上来就做语义匹配。
| 层级 | 匹配方式 | 延迟 | 适用 |
|---|---|---|---|
| L1 精确缓存 | 规范化后的 key 完全一致 | 亚毫秒 | 高频完全重复，如状态查询、固定 FAQ |
| L2 语义缓存 | 向量相似度 + 实体校验 + 边界复核 | 20ms 左右 | 换说法的同一意图 |
公开数字可以作参照，但要看清口径：GPTCache 论文报告命中率 61.6% 到 68.8%、正向命中率超过 97%；AWS 用 ElastiCache 给 Bedrock 做语义缓存，阈值 0.75 时成本降 86%、准确率 91%、单条延迟从 6.51 秒降到 0.11 秒；但第三方研究给出的生产真实命中率只有 20% 到 45%，而且冷启动前 4 到 6 周基本没有收益 —— 查询模式还没攒够。这些数字并不矛盾，差别在负载类型：FAQ、客服、文档问答重复度高，个性化 Agent 重复度低。
阈值是整套方案里最难的旋钮：
| 阈值 | 效果 | 风险 |
|---|---|---|
| 0.75 以下 | 命中率高 | 假阳性显著抬头，容易答错 |
| 0.80 | GPTCache 论文的经验最优 | 对时间敏感、实体敏感的查询仍然不够 |
| 0.85 | 行业常见起点 | “今天 / 明天” 这类仍会被误判 |
| 0.88—0.92 | 多数业务的安全区间 | 命中率明显下降 |
| 0.95 以上 | 接近精确匹配 | 缓存形同虚设 |
真正的问题不在阈值，而在 “有些请求根本不该进缓存”。判据是：同一句话，换一个用户、换一天、换一个订单号，答案会不会变。会变，就别缓存。
五类绝对不能缓存的请求
- 写操作。 删除、退款、转账、改配置。这类请求一旦误命中，就是把上一个请求的动作重放一遍。
- 时间敏感。 今天天气、股价、库存、汇率、剩余额度。相似度再高也不能复用。
- 强个性化。 同一句 “推荐个方案”，不同用户、不同套餐，答案不同。
- 带实体 ID。 订单号、工单号、会话 ID、文件路径。向量分不清 123 和 124。
- 未改写的多轮追问。 “那它呢”“再便宜点的” 这类指代，脱离上下文后语义完全漂移。
- 没有复核能力的安全场景。 涉及权限、金额、合规判断的，宁可不缓存。
另外两条硬规则：错误响应永远不缓存；缓存 key 必须带命名空间，至少包含 tenant、模型版本、system prompt 版本、工具 schema 版本。生产上最常见的事故不是阈值调错，而是有人改了 system prompt 没清缓存，旧答案继续被返回。
命中之后还要过三道校验
| 校验 | 做什么 | 拦什么 |
|---|---|---|
| 实体比对 | 抽取查询里的 ID、时间、金额、人名，与缓存条目逐项比 | 订单 123 命中订单 124 |
| 作用域比对 | 校验 tenant、user、权限等级、地域 | 跨用户、跨租户串答案 |
| 边界复核 | 相似度落在 0.85—0.92 区间时，用小模型或规则判一次 | 语义相近但意图相反的请求 |
这三道都过了才返回，任何一道不过就降级到真实推理。多花的是一次轻量判断的几毫秒，省下的是一次误执行的代价。
还有一类更隐蔽的失败：Agent 任务里的缓存不是 “问答对”，而是 “计划模板”。有研究专门测过，直接拿 GPTCache 那套余弦阈值去做 Agent 任务缓存，合成任务上命中率只有 3.3%，真实基准上准确率 37.9%，因为 “查邮件” 和 “发邮件” 在向量空间里几乎一样，但工具调用序列完全不同。这类场景要把意图结构化成 “动作 + 对象 + 参数”，用少样本分类做 key 规范化，而不是拿原始句子算相似度。
失效与观测：没有这套指标，缓存就是黑盒
| 指标 | 健康区间 | 说明 |
|---|---|---|
| 缓存命中率 | 客服 / FAQ 60%—80%，通用对话 25%—55% | 低于 20% 说明负载重复度不够 |
| 正向命中率 | 97% 以上 | 命中里答案正确的人为抽检比例 |
| 假阳性率 | 越低越好，按业务定阈值 | 必须单独监控，不能只看命中率 |
| p99 延迟（命中） | 100ms 以内 | 超过说明向量检索或校验成了瓶颈 |
| 绝对省下的 token | 按业务算 | 1 万 token 的命中比 500 token 的命中值钱得多 |
| 命中率突变 | 30 分钟内跌 15 个百分点即告警 | 大概率是命名空间没跟着发版更新 |
失效策略四件套：TTL 到期自动过期、LRU/LFU 控容量、版本变更整批 purge、防中毒（错误响应和低质响应永不入缓存）。冷启动阶段别急着看收益，先用历史流量做预热，把高频意图灌进去。
一套可以直接照着落地的参数表
| 层 | 存储 | 容量 | 生命周期 | 目标 |
|---|---|---|---|---|
| 工作记忆 | 进程内 | 8—12 轮 + 摘要 | 单次会话 | 信噪比优先 |
| 任务状态 | Redis / PG | 单任务 1 条 | 任务结束 +24h | 精确、可恢复 |
| 情节记忆 | 向量库 | 按租户分片 | 90—180 天 | 召回率优先 |
| 语义记忆 | KV + 实体索引 | 每用户几百条 | 长期，带复核 | 准确率优先 |
| 时序事实 | 图库 / 宽表 | 按实体 | 带有效期 | 冲突可解 |
| 程序性记忆 | 文件 / 知识库 | 版本化 | 随版本 | 直接注入 |
| 精确缓存 | Redis | 按 QPS 估 | 1—24h | 亚毫秒 |
| 语义缓存 | 向量库 | 按意图数估 | 7—30 天 | 命中 25%—55% |
面试追问怎么接
| 追问 | 答法 |
|---|---|
| 记忆和 RAG 什么区别 | RAG 检索静态文档，记忆管理 Agent 自己产生的状态，要处理写入、冲突、过期、遗忘 |
| 多租户怎么隔离 | 作用域前置，检索限定子树或分区；不靠召回后过滤 |
| 记忆冲突怎么办 | 优先 ADD-only + 时间有效性；确需合并时保留来源和审计 |
| 缓存一致性怎么保证 | key 带 prompt / 模型 / 工具版本；发版即 purge；TTL 兜底 |
| 怎么证明有效 | 离线看 LoCoMo/LongMemEval，线上看任务完成率、token / 请求、p95 延迟、正向命中率 |
| 成本怎么降 | 先砍上下文（选择性检索），再砍重复调用（缓存），最后才是换小模型 |
各家记忆方案的分数还会继续打架：Mem0 一侧公布 LoCoMo 92.5、LongMemEval 94.4，并称对 Zep 是 93.4 对 71.2；Zep 一侧的直接对比又给出 63.8 对 49.0，两家在 LoCoMo 的方法学上还有争议；ByteRover 在 LoCoMo 上报到 96.1，但带 15% 到 25% 的 token 开销，到 BEAM 1M 又回落到 62%。这些数字的正确用法是看趋势和口径，不是拿去当选型依据 —— 你的业务没有 LoCoMo 那么干净，重复度、实体密度、多轮比例都不一样。真正该背下来的不是榜单，而是那套判断：这一轮该给模型看什么，这条信息该不该写回去，这个请求凭什么可以不走模型。
【常见问题】
问题 1：Agent 多级记忆一般分几层，每层放什么？
回答 1：通常分三层：工作记忆放最近 8—12 轮对话和工具结果，任务状态放目标、约束、决策、待办，长期记忆再细分为情节、语义、时序事实和程序性记忆。Agent 多级记忆的核心不是层数多，而是每层只回答一个问题，别让向量库同时承担状态存储和内容召回。
问题 2：Agent 语义缓存为什么容易答错，阈值调到多少合适？
回答 2：因为向量只认语义相似，不认实体和时间。“删除订单 123” 和 “删除订单 124” 相似度超过 0.98，“今天天气” 和 “明天天气” 也有 0.909。Agent 语义缓存的阈值建议从 0.85 起步，安全区间 0.88—0.92，并且必须加实体比对和边界复核，写操作、时间敏感、带 ID 的请求直接不进缓存。
问题 3：Agent 多级记忆的长期记忆，用向量库够不够？
回答 3：不够。Agent 多级记忆里的偏好和身份事实适合 KV 精确读，带有效期的状态需要时序结构，规则和 SOP 适合版本化文件。纯向量库会把 “住在杭州” 和 “搬到成都” 同时召回，模型无法判断哪个有效，所以要么加时间有效性字段，要么用时序图。
问题 4：Agent 语义缓存命中率多少算正常，怎么评估效果？
回答 4：客服和 FAQ 场景 60%—80%，通用对话 25%—55%，生产环境真实语义命中率通常只有 20%—45%，冷启动前 4—6 周基本没收益。评估 Agent 语义缓存不能只看命中率，要同时看正向命中率、假阳性率、p99 延迟和绝对省下的 token，命中率 30 分钟内跌 15 个百分点就要告警。
【参考资料】
[2026-11-13]（大厂 AI 架构面实战：别再无脑塞 Prompt，手把手教你设计 Agent 多级记忆与语义缓存）51CTO
[2026-10-17]（语义缓存：命中率上去了，却把问「今天天气」的人答成了「明天天气」）掘金 AI 编程
[2026-09-18]（AI Memory Management: 4 Layers & Production Benchmarks）Mem0
[2026-09-03]（Zep vs Mem0: Which AI Memory Layer Should You Choose?）Mem0
[2026-07-21]（OpenAI Memory vs. LangMem vs. Letta (MemGPT) vs. Mem0: Which Performs Best?）Mem0
[2026-07-05]（Agent Memory in 2026: A Research Survey Breakdown for Practitioners）NiteAgent
[2026-06-10]（Context window in AI: why every token is a budget decision）Redis
[2026-05-25]（2026 年 5 月份 AI Agent 产品中的记忆设计与工程实践）DataLearner AI
[2026-05-24]（Agent Memory 2026: Mem0, Letta and Zep Compared）innobu
[2026-05-13]（TencentDB Agent Memory 正式开源：让 Agent 沉淀经验，让人专注创造）腾讯云开发者社区
[2026-04]（Hierarchical Long-Term Semantic Memory for LinkedIn's Hiring Agent）arXiv
[2026-02-24]（Why Agent Caching Fails and How to Fix It: Structured Intent Canonicalization with Few-Shot Learning）arXiv
[2026-01-23]（LLMOps Guide 2026: Build Fast, Cost-Effective LLM Apps）Redis
免责声明： 本文依据公开论文、厂商技术博客与工程实践文章整理，文中命中率、准确率、延迟和 token 数据均为各自来源的测试口径，不同负载、阈值和模型版本下差异很大，不可直接作为容量规划依据；架构分层与参数建议为通用工程参考，落地前请用自有流量做 A/B 与压测验证，本文不构成任何具体产品的选型或采购建议。