Agent 记忆管理：向量库的边界与两条生产级路线（ChatGPT/Codex 分层记忆 / Claude Code 文件系统）（口播版）
面试高频问题：Agent 的记忆管理怎么设计？是不是上向量数据库 + RAG 就够了？ 一句话答案：不够。向量库只解决「模糊语义召回」，不负责记忆的写入、更新、冲突、过期、审计和沉淀。生产级路线有两条：① ChatGPT/Codex 路线的分层记忆，核心是「原始会话证据 + 两阶段异步提炼 + 常驻摘要 + 可搜索索引 + 按需读取证据 + 技能固化」；② Claude Code 路线的文件系统记忆，核心是「磁盘为持久层、上下文为可重建缓存、压缩后从磁盘重注」。 回答边界：ChatGPT 服务端内部细节没有完整公开。本文把 ChatGPT 产品侧可观察的记忆行为，与 Codex 公开可观察的
rollout -> 提炼 -> 摘要/索引/证据/技能机制放在同一条 OpenAI 路线里讲；具体文件名、阈值和界面会随版本变化，面试时讲机制，不背内部参数。 适用轮次：二面深度 / 三面综合（Agent 记忆机制 + 生产架构细节） 本版定位：口语应答脚本。先给「开口就能说」的话术，再给分层架构、读写链路、治理与追问预案。
【30 秒极简版】（面试官随口一问时用）
如果只答「向量库 + RAG」，说明把一种检索手段当成了完整记忆系统。向量库能召回「语义相似」，但接不住订单号、文件路径这类精确定位，也解决不了新旧状态冲突、更新失效和记忆审计。 ChatGPT/Codex 这条线我会拆成四层：工作上下文、会话证据、跨会话提炼记忆、过程记忆/技能。写入走两阶段异步管道：先按单个会话提炼高信号信息，再做全局去重、归纳和淘汰；读取走「常驻摘要 -> 索引定位 -> 按需读取 1 至 2 份证据」；最后用状态管理、双时间和当前来源复核兜底。Claude Code 则证明另一条路线：磁盘是持久层，上下文只是缓存，压缩后从磁盘重注。
【2 分钟完整口播】（正式被问到时的主干回答）
这题我先说结论：向量库只是记忆系统里的一个检索组件，不是记忆系统本身。只答「向量数据库 + RAG」，说明你没有处理过写入、更新、过期和审计。
第一，先讲向量库的三个局限。 一是它擅长模糊语义匹配，遇到手机号、订单号、文件路径这种精确查找就弱；二是新旧状态可能同时被召回，比如用户换了地址，新旧两条都在库里，检索时分不清谁有效，产生时间盲区；三是它只管存和查，不管记忆的抽取、更新、冲突处理、过期和沉淀。
第二，给 ChatGPT/Codex 路线的四层记忆。 最底层是工作上下文，放最近几轮对话、当前任务状态和关键工具结果，按窗口滚动并压缩；第二层是会话证据，也就是完整 rollout 或对话日志，只追加，作为审计事实；第三层是跨会话提炼记忆，存稳定偏好、项目事实、决策和失败经验，采用「常驻小摘要 + 可搜索索引 + 按需证据」；第四层是过程记忆/技能，把验证成功的流程和检查清单固化成可复用能力。这里的关键不是「有四个库」，而是四层生命周期不同，读写策略也必须不同。另外，
AGENTS.md、项目规则和 skill 是版本化指令，不能和学习记忆混写；记忆只能提供线索，不能覆盖当前规则。第三，写入不是每轮直接写库，而是两阶段异步提炼。 第一阶段按单个会话处理：用户怎么纠正、什么方案真的被采用、哪些命令和错误值得复用、任务最终成功还是失败；只保留能改变未来行为的高信号信息，没有价值就允许 no-op。输出是会话摘要和紧凑的候选记忆。第二阶段做全局整合：跨会话去重、归纳、处理冲突、保留来源，再生成摘要、索引、证据文件和技能。这样当前对话不被记忆写入阻塞，也避免了「每句话都变成一条记忆」的噪声。
第四，读取也不是把全部记忆塞进上下文。 先加载体积受控的记忆摘要，用任务关键词在索引里定位，只打开最相关的 1 至 2 份证据；对于代码状态、价格、权限这类容易漂移的事实，再回到当前源文件或业务系统复核。记忆只能提供线索，不能天然当作当前真相。
第五，可靠性底座。 原始证据只追加，摘要和索引都是派生视图，控制策略决定何时写入、失效和淘汰；每条记录保留业务发生时间和写入时间，解决状态复写；用户明确说「记住、忘掉、纠正」时，先写 append-only 的变更备注，再由整合流程生效，避免模型直接改坏生成记忆。
第六，对照 Claude Code。 它走文件系统路线，项目规则、auto memory、计划文件都落盘；上下文压缩后，项目规则、记忆索引和计划从磁盘重注，子目录规则和记忆内容按需加载。它的共同原则不是「文件比数据库高级」，而是上下文是缓存，持久状态必须有可重建的来源。
所以收尾我会说：记忆系统真正难的是生命周期和治理，不是选 Pinecone 还是 FAISS。向量库可以用，但只能作为混合检索的一路。
【追加口播：Claude Code 的路线】（被追问「生产上你还见过什么方案」时用）
还有一个对照特别有说服力：Claude Code 公开的记忆文件机制不依赖向量数据库，走的是文件系统路线。设计哲学一句话概括：磁盘是持久层，上下文窗口只是可重建的缓存。凡是写到磁盘上的项目规则、auto memory、计划文件，压缩后还能重新注入；只存在于对话里的内容，压缩后就会丢。 它有两套机制：CLAUDE.md 是人写的指令，按组织 / 用户 / 项目 / 本地四层作用域加载，且分层触发：上级目录启动时加载，子目录文件按需加载，带
paths:的规则只在命中文件时进上下文；auto memory 是 Claude 自己写的学习笔记，按 git 仓库存，每次会话只加载索引，其余内容按需读取。这就是「索引常驻 + 内容懒加载」。 再叠加 subagent 的上下文隔离：大文件调研丢给子 agent，它在自己的上下文窗口里运行，只把摘要回传主会话。Anthropic 还把这套做法做成了 API 能力：memory tool 提供受限于/memories的文件增删改查，context editing 清理过期工具结果，并在清理前提示模型先把重要信息落盘。 所以我答这题会补一句：文件系统 + 压缩重注 + 上下文隔离，同样能构成成熟的记忆架构。真正的共性不是「不用向量」，而是持久状态有明确归属，上下文可以被重建。
一、速记要点
1. 面试红线
- ❌ 只答「向量数据库 + RAG」→ 面试官判定缺乏生产实操经验
- ✅ 答出「分层生命周期 + 读写链路 + 状态、时间、治理」→ 工程级信号
2. 向量库三大局限
| 局限 | 具体表现 | 后果 |
|---|---|---|
| 只会模糊匹配 | 手机号、订单号等精准查找接不住 | 场景失灵 |
| 新旧状态混存 | 检索分不清记录先后 | 时间盲区，决策出错 |
| 只管存查 | 不管更新、覆写、沉淀 | 记忆越积越脏 |
3. 四层记忆（ChatGPT/Codex 路线的工程抽象）
| 层 | 内容 | 生命周期 | 读写策略 |
|---|---|---|---|
| L0 工作上下文 | 最近对话、当前任务状态、关键工具结果 | 当前轮次或当前任务 | 滚动窗口、压缩、任务结束释放 |
| L1 会话证据 | 完整 rollout、对话日志、工具调用与结果 | 单会话，长期留存 | 只追加、不原地改写、可回放 |
| L2 提炼记忆 | 用户偏好、项目事实、决策、失败经验 | 跨会话 | 两阶段异步提炼、合并、失效、淘汰 |
| L3 过程记忆 | 已验证的流程、检查清单、技能 | 跨任务 | 成功轨迹固化，版本化复用 |
这四层是按生命周期和用途划分，不是要求部署四个数据库。落到实现上，可能是 SQLite + 日志 + Markdown 工作区 + 文件检索，也可能再加向量索引。
4. 状态管理三件套 + 双时间机制
- 原始账本：事实记录，只追加不改写；
- 派生视图：账本加工出的可查询状态；
- 控制策略：决定何时写入、何时更新；
- 双时间机制：每条记录带「业务发生时间 + 记录写入时间」两个时间轴，解决状态复写——改了不丢历史，新旧不混淆。
5. 技能固化
- 高频成功任务轨迹 → 固化为可复用技能；
- 同类任务直接复用，不从零推理；
- 记忆系统从「记住」升级到「会用」。
6. 一条判断标准
不要问「这个方案用了几个库」，要问：写什么、何时写、写错怎么撤、过时怎么判、读取时如何控制预算、删除是否彻底、效果如何评测。
二、ChatGPT/Codex 生产级记忆架构（托管分层 + 可审计工作记忆）
核心判断：这条路线不是「把全部历史向量化，然后每次 top-k 召回」。它把记忆当成一条数据流水线：原始证据负责可追溯，异步提炼负责降噪，摘要/索引负责低成本读取，按需证据负责核实，技能负责把经验变成能力。
1. 先区分 ChatGPT 和 Codex
两者共享「分层 + 提炼 + 按需读取」的工程思想，但不是同一套实现，目标和风险也不同。
| 维度 | ChatGPT 产品记忆 | Codex 工作记忆 |
|---|---|---|
| 主要单位 | 用户、对话、长期偏好与事实 | 仓库、线程、任务、工具调用 |
| 主要目标 | 减少重复说明，维持个人偏好和跨会话连续性 | 维持项目上下文、复用已验证流程、减少重复探索 |
| 典型内容 | 稳定偏好、长期事实、正在进行的主题 | 仓库约定、关键路径、命令、历史决策、失败经验 |
| 典型写入源 | 用户可管理、可开关的长期记忆与对话历史 | 会话 rollout、工具验证结果、用户纠正、显式记忆备注 |
| 主要读取方式 | 选择相关记忆注入当前对话 | 摘要常驻 + 索引检索 + 按需读取证据 + 当前仓库复核 |
| 最大风险 | 过期个人信息、隐私、错误泛化 | 过期仓库事实导致改错代码、把一次性方案当稳定约定 |
面试时不要说「我确定 ChatGPT 内部就是这样」。正确表述是：基于公开可见的产品行为和 Codex 机制，可以抽象出这条生产级路线；具体内部实现和参数没有完整公开。
2. 规则、任务状态、学习记忆要分开
| 类型 | 典型来源 | 权限与可信度 | 更新方式 |
|---|---|---|---|
| 规则 / 指令 | AGENTS.md、项目文档、skill | 在作用域内有明确约束力，受版本控制 | 人审阅、提交、评审后更新 |
| 任务状态 | plan、todo、检查点、已执行动作 | 当前任务内高时效，任务结束可释放 | 由确定性流程或结构化状态更新 |
| 学习记忆 | 从 rollout 异步提炼的偏好、事实、经验 | 是线索，不是当前真相；必须带来源 | 整合、失效、淘汰，不能反向覆盖规则 |
规则不是记忆。自动提炼不能因为「历史上经常这样」就悄悄覆盖
AGENTS.md、安全策略或用户当前指令；反过来，记忆也不该把所有项目规则重复抄一遍，否则规则更新后会产生两份互相矛盾的事实。
3. 数据面：四层记忆不是四个孤岛
当前消息 / 工具调用 / 文件变更
|
v
L1 会话证据（只追加，可回放）
|
+--> Phase 1：单会话异步提炼（允许 no-op）
|
v
会话摘要 + 候选长期记忆
|
v
Phase 2：全局去重、归纳、冲突处理、淘汰
|
+-------------------+-------------------+
v v v
常驻记忆摘要 可搜索记忆索引 按需证据摘要
| | |
+-------------------+-------------------+
|
v
技能 / 流程 / 检查清单四层的职责：
- L0 工作上下文：直接参与本轮推理。只装当前目标、最近对话、关键状态和必要工具结果，不能把历史全量塞进来。
- L1 会话证据：保留完整对话、工具调用和结果。它是审计与回放的事实源，不为了「好看」去改写原文。
- L2 提炼记忆：从多个会话中抽取稳定偏好、项目事实、已采用决策和失败经验。它是有损摘要，必须保留来源指针。
- L3 过程记忆：把多次验证成功的任务轨迹固化成 skill、workflow 或 checklist。它解决的是「下次怎么做」，不是「上次说了什么」。
4. 写入面：两阶段异步提炼
为什么不每轮直接写一条记忆？
单轮对话噪声太大，用户的试探、模型的猜测、临时状态都可能被误存成长期偏好。更稳妥的做法是先保留证据，再异步提炼；先单会话降噪，再跨会话合并。
| 阶段 | 作用域 | 输入 | 输出 | 关键判断 |
|---|---|---|---|---|
| Phase 1 单会话提炼 | 一个 rollout / 线程 | 用户消息、工具调用、验证结果、最终状态 | 会话摘要、紧凑候选记忆 | 这次任务有没有值得未来复用的信息？没有就 no-op |
| Phase 2 全局整合 | 多个高价值会话 | 候选记忆、近期/高频会话摘要、显式备注 | 常驻摘要、索引、证据、技能 | 哪些重复、冲突、过时？哪些能抽象成稳定规则或流程？ |
Phase 1 只保留高信号内容：
- 用户重复强调或纠正过的工作偏好；
- 实际验证过的仓库路径、命令、错误原因和修复方式；
- 已被用户接受并实施的决策；
- 下次遇到类似任务能帮助止损的 failure shield；
- 任务结果到底是 success、partial、fail 还是 uncertain。
不应该优先写入：
- 一次性状态、临时指标和随手寒暄；
- 大段工具输出；
- 助手自己的猜测、未采用的方案；
- 通用常识和空泛建议；
- token、密码、密钥等敏感信息。
两阶段设计带来的四个收益：
- 不阻塞主对话：记忆提炼可以后台执行，用户不需要等。
- 降噪：单会话先过滤，全局再合并，避免每句话都变成长期记忆。
- 可追溯：摘要指向原始 rollout，结论和证据分开存。
- 可回滚：整合产出的是派生工件，规则改坏后可以从原始证据重建。
5. 存储面：摘要、索引、证据、技能各司其职
| 资产 | 回答什么问题 | 是否常驻上下文 | 设计要点 |
|---|---|---|---|
| 记忆摘要 | 「这个用户/项目通常需要注意什么？」 | 常驻，但必须小 | 只放高价值、低漂移信息，控制 token 预算 |
| 可搜索索引 | 「哪条记忆可能和当前任务有关？」 | 不常驻，按需搜索 | 带项目、时间、主题、来源、任务结果等元数据 |
| 会话证据 | 「这个结论当时是怎么来的？」 | 不常驻，按需读取 | 保留原始 rollout、工具输出和验证证据 |
| 技能 / 流程 | 「这类任务下次应该怎么做？」 | 命中任务时加载 | 版本化、可测试、写清适用边界 |
| 显式变更备注 | 「用户明确要求记住/忘掉什么？」 | 不直接注入 | append-only，等待整合流程合并 |
这里最重要的一条是摘要和证据分离：
- 摘要负责回忆速度和 token 成本；
- 证据负责准确性和可审计性；
- 索引负责把两者连起来；
- 技能负责把稳定流程从「知道」升级成「会做」。
6. 读取面：渐进式披露，而不是一次全量召回
生产读取链路可以固定成五步：
- 看当前任务：当前指令、约束、工作目录和本轮目标优先。
- 加载小摘要：先获得用户偏好、项目约定和高风险提醒。
- 查索引：用实体、文件路径、任务类型、错误关键词定位候选。
- 只读 1 至 2 份最相关证据：需要细节、来源或原始错误时才回读，避免一次打开大量历史。
- 复核当前来源：代码、配置、数据库和权限这类可漂移事实，以当前源为准。
上下文预算建议按优先级分配：
| 优先级 | 内容 | 策略 |
|---|---|---|
| P0 | 系统安全规则、当前用户指令、任务验收标准 | 必须保留，不能被低层记忆覆盖 |
| P1 | 当前任务状态、已确认事实、待办与阻塞点 | 结构化保留，跨轮更新 |
| P2 | 当前仓库/业务系统的真实状态 | 按需读取最新源，优先于历史记忆 |
| P3 | 记忆摘要和命中的技能 | 小额常驻，按任务裁剪 |
| P4 | 历史证据和旧工具输出 | 摘要、引用或按需回读，不默认全量注入 |
关键规则：当前指令 > 当前来源 > 提炼记忆 > 旧会话原文。低优先级信息不能反向覆盖高优先级约束。
7. 压缩：先落盘，再摘要，再重注
上下文接近上限时，不能只做一次「聊天记录摘要」。更稳的顺序是：
- 先落盘：把当前目标、硬约束、已确认决策、产物路径、待办和阻塞点写进任务状态或持久文件；
- 再摘要：把旧对话压成结构化摘要，旧工具输出在产物已保存后只保留路径和结论；
- 再重注：压缩后重新加载当前指令、项目规则、记忆摘要和任务状态，而不是依赖被摘要掉的细节；
- 按需回读：需要代码、日志、文档原文时，按路径重新读取当前文件；
- 复核锚点：确认关键数字、ID、权限和验收条件没有在压缩中失真。
生产原则：先保证信息有持久归属，再允许它离开上下文。 如果一段信息只存在于对话里，就没有资格要求它在压缩后「不要忘」。
8. 更新与冲突：记忆必须有时间语义
一条记忆至少要回答三个时间问题：
- 事件何时发生：用户什么时候改的地址、项目什么时候切换的技术栈；
- 记录何时写入：系统是什么时候知道这件事的；
- 状态何时有效：从哪个时间点开始有效，到什么时候失效。
生产实现通常需要：
- 原始账本只追加，不原地覆盖；
- 摘要、索引、档案都是可重建的派生视图；
- 新事实与旧事实冲突时，保留旧记录的失效痕迹，而不是无痕删除；
- 用户明确纠正时，显式纠错优先于低置信度推断；
- 删除或「忘掉」请求要穿透原始存储、索引、缓存和后续派生工件；
- 对价格、权限、代码结构这类易漂移信息，回答前重新验证当前源。
一句话：记忆不是当前真相，它是对过去的压缩。 面试里能主动说这句，比背「四层记忆」更能体现生产意识。
9. 治理与安全：写入权比检索算法更关键
- 用户控制写入：Codex 的显式记忆变更只在用户明确要求「记住、忘掉、纠正」时写；ChatGPT 是否自动从历史提炼，由产品设置和用户授权决定。无论哪条路线，模型都不能把一次临时观察直接升级成稳定身份或长期偏好。
- 原文与指令分离：工具输出、网页、仓库文件都属于不可信数据，不能因为被写进记忆就获得指令权限。
- 作用域隔离：用户、租户、项目和线程要分开，检索前先做权限过滤，越权数据不能进入候选集。
- 敏感信息治理：写入前脱敏，禁止保存密钥、令牌、密码和完整访问链接。
- 生成与人工变更分离：生成记忆不要手改，用户变更通过 append-only 备注进入下一次整合，保证审计链完整。
- 可观测性：记录写入、检索、命中、使用、纠正、删除事件，才能定位「记错了」还是「召回错了」。
10. 为什么这条路线不把向量库当主力
Codex 的大量查询天然带精确定位信号：仓库根目录、文件路径、函数名、错误字符串、线程 ID、任务结果和时间。这些信息用日志、SQLite、全文检索和路径索引往往更直接，也更容易审计。
同时，代码和配置变化快。把过期历史做成语义近邻，模型可能「召回得很像」，却基于旧实现改代码。所以这条路线更强调：
- 先用结构化元数据缩小范围；
- 再用关键词/路径精确定位；
- 只有在需要证据时才读取原文；
- 关键结论回到当前源验证。
这不是说向量库没用。它更适合：
- 海量非结构化笔记和历史对话的模糊召回；
- 跨语言、同义表达、概念相似的任务探索；
- 作为混合检索的一路，与关键词、时间、项目、权限过滤融合排序。
正确答案不是「不用向量」，而是：向量库负责相关性探索，结构化存储负责事实、权限和版本，二者不是替代关系。
11. 怎么证明记忆系统真的有效
| 评测维度 | 指标示例 | 验证方式 |
|---|---|---|
| 召回质量 | recall@k、精确率、噪声率 | 人工标注「问题 -> 应召回记忆」测试集 |
| 时效与冲突 | 过期命中率、矛盾回答率 | 构造状态变更和旧事实干扰用例 |
| 写入质量 | 高信号保留率、低价值写入率、重复率 | 抽样审计 + 人工复核 |
| 任务收益 | 同类任务成功率提升、重复纠正次数下降 | 开关记忆做 A/B，或 shadow 对比 |
| 成本 | 上下文 token、首 token 延迟、后台整合成本 | 分读写链路埋点 |
| 治理 | 删除完整性、越权召回率、敏感信息泄漏率 | 权限测试和删除演练 |
评测必须按链路归因：没召回、召回了没用、用错旧记忆、压缩丢关键约束，是四个不同问题，不能只看一个总准确率。
三、Claude Code 生产级记忆架构（文件系统为持久层）
与 ChatGPT/Codex 的托管分层不同，Claude Code 公开的记忆文件机制走纯文件系统路线。它证明：只要持久状态可重建、加载范围可控，文件系统也能承担生产级 Agent 记忆。
1. 核心原则：磁盘是持久层，上下文窗口只是可重建的缓存
整套架构的设计哲学可以压成一句：凡落到磁盘的，压缩后能从磁盘重新注入；只存在于对话里的，压缩即丢失。 所以它不追求「把所有记忆塞进上下文」，而是追求「上下文随时可以被重建」。
2. 双机制：人写的指令 vs Agent 自写的学习
| CLAUDE.md 文件 | Auto memory | |
|---|---|---|
| 谁写 | 人 | Claude 自己 |
| 内容 | 指令、规则 | 学习、纠正、偏好 |
| 作用域 | 组织 / 用户 / 项目 / 本地 | 按 git 仓库（同仓库多 worktree 共享） |
| 加载 | 每次会话 | 每次会话，仅前 200 行或 25KB 索引 |
| 用途 | 编码规范、工作流、项目架构 | 用户偏好、反复纠正、代码里推不出的上下文 |
两者都只被当作上下文（context）而非强制配置——要真正拦截某个动作，得靠 PreToolUse hook，不能指望记忆文件。
3. 四层作用域 + 分层加载策略
CLAUDE.md 按作用域分四层，从宽到窄依次加载（越靠近工作目录越后读）：
| 作用域 | 位置 | 目的 |
|---|---|---|
| 组织级 | macOS /Library/Application Support/ClaudeCode/CLAUDE.md | 公司规范、安全合规 |
| 用户级 | ~/.claude/CLAUDE.md | 个人跨项目偏好 |
| 项目级 | ./CLAUDE.md 或 ./.claude/CLAUDE.md | 团队共享规范（入库） |
| 本地级 | ./CLAUDE.local.md | 个人项目偏好（gitignore） |
关键在于分层触发、不全量塞：
- 工作目录及上级目录的 CLAUDE.md 启动时加载，且是拼接而非覆盖，顺序从文件系统根往下；
- 子目录里的 CLAUDE.md 按需加载——只有当 Claude 读 / 写 / 编辑到该子目录的文件时才进上下文；
.claude/rules/支持paths:frontmatter 做路径作用域规则，只在命中匹配文件时才加载，省上下文；- 用
@path/to/file复用（最大 4 层嵌套）；项目级文件里的外部 import 首次会弹审批对话框，防止共享仓库里别人提交的文件偷带内容进来——这是记忆加载的安全边界。
4. 索引 + 懒加载（Auto memory 的关键设计）
Auto memory 从不把全部记忆注入上下文：每次会话只加载 MEMORY.md 索引的前 200 行或 25KB，其余由 Agent 按需读取。「索引常驻 + 内容懒加载」这套前端熟悉的思路，在记忆系统里同样成立。子 agent 也可以维护自己的持久记忆。
5. 压缩与重注：明确「什么必须活下来」
上下文逼近上限时自动压缩，机制是先清旧的 tool 输出，再摘要整段对话。真正见功力的是压缩后什么会被从磁盘重新注入：
| 机制 | 压缩后 |
|---|---|
| 系统提示 / 输出风格 | 仍然生效 |
| 项目根 CLAUDE.md、无作用域规则 | 从磁盘重新注入 |
| Auto memory | 从磁盘重新注入 |
| Git 状态快照 | 从仓库重新读取最新 |
| Plan 模式写下的计划 | 从磁盘重新注入 |
带 paths: 的规则、子目录 CLAUDE.md | 按需重新加载 |
| Claude 读过 / 改过的文件 | 重读最多 5 个，最近修改优先；超 5K token 只回路径引用，不回内容 |
| 被调用的 skill 正文 | 重新注入，单 skill 上限 5K token、总量 25K，超了先丢最旧的 |
| 后台命令 / 后台 subagent | 继续运行，并提醒 Claude 别重复启动 |
| Hook 早期注入的上下文 | 被摘要带走，不重注 |
把这张表反过来读就是生产经验：任何必须跨压缩存活的信息，要么写进项目根 CLAUDE.md / rules 文件，要么写进 memory 文件；只留在对话里的，一定会丢。 可控手段包括 /compact 聚焦某任务、/rewind 做局部摘要、/autocompact 500k 调阈值、/clear 切任务。
6. 上下文隔离：subagent 当「记忆防火墙」
把调研类的大文件读取丢给 subagent，它在自己独立的上下文窗口里运行，只有摘要和一小段元数据回传主会话——大批文件内容根本不进主上下文，也就不会挤占记忆预算。
7. API 层的对应物：memory tool + context editing
这套思路不只活在 Claude Code 里，Anthropic 把它做成了 API 能力：
- memory tool：客户端侧的
/memories目录，Claude 通过 view / create / str_replace / insert / delete / rename 增删改查，跨会话累积知识；服务端要求把所有操作限制在/memories内（防路径穿越），存储位置由你自控； - context editing：
clear_tool_uses_20250919清理过期的 tool 结果；与 memory tool 搭配时，上下文逼近清理阈值会给 Claude 发预警，让它先把重要信息写进 memory 文件再被清掉——即「先落盘、后清理」。
四、三条路线横向对照
| 维度 | 向量库 + RAG | ChatGPT/Codex 分层记忆 | Claude Code 文件系统 |
|---|---|---|---|
| 主要单位 | 文本块、向量 | 用户/对话，或仓库/线程/任务 | 项目、目录、规则文件、记忆文件 |
| 持久化对象 | 向量索引和原文块 | 原始 rollout + 提炼记忆 + 摘要/索引/证据 + AGENTS.md / skills | 文件系统 + git 仓库 |
| 写入方式 | 批量切块、嵌入、入库 | 单会话异步提炼 + 全局整合 + 显式变更备注 | 人写规则、Agent 写记忆、计划与文件落盘 |
| 读取方式 | 语义 top-k | 摘要常驻 + 索引检索 + 按需读证据 + 当前源复核 | 作用域加载 + 路径规则 + 索引懒加载 |
| 精准查找 | 弱，通常要叠加关键词/结构化过滤 | 强，路径、项目、时间、任务结果可做索引 | 强，路径和时间天然是索引 |
| 时效与版本 | 依赖额外元数据和治理 | 证据时间、整合时间、来源指针、淘汰策略 | 文件时间、git 历史和当前文件状态 |
| 可解释、可审计 | 中到弱 | 强，摘要可回到原始证据 | 强，明文文件可 diff、可 review |
| 成本结构 | 嵌入、索引维护和检索成本 | 后台提炼/整合成本 + 较低的按需读取成本 | 读取便宜，但依赖目录和文件治理 |
| 主要风险 | 语义相似但不正确、旧状态混入 | 摘要失真、整合滞后、错误泛化 | 文件膨胀、作用域污染、权限边界 |
| 适用场景 | 大规模非结构化知识的模糊召回 | 通用助手、编码 Agent、长期任务连续性 | 工程 Agent、本地优先、需要透明可审计的场景 |
共性：向量库只是组件；两条产品路线也需要完整的治理体系才能成立。真正决定效果的是写入质量、时间语义、读取预算、权限隔离和淘汰机制。
五、高频追问
Q1：为什么要两阶段提炼，不能一次完成？
一次处理要么范围太窄，只能看见单会话；要么输入太大，跨会话全部塞进去会丢细节、成本和延迟也失控。两阶段把职责拆开：Phase 1 保住单会话证据和细节，Phase 2 才做跨会话去重、冲突和抽象。它还支持并行和失败重试，不会阻塞主对话。
Q2：为什么不能每轮直接写长期记忆？
单轮内容里有很多试探、临时状态和模型猜测。直接写会把噪声固化成偏好，后面很难纠正。更稳的做法是先写不可变证据，再异步判断值不值得提炼。记忆写入应该像数据仓库的 ETL，而不是聊天消息的镜像。
Q3：既然有完整会话记录，为什么还要摘要和索引？
完整记录适合审计，不适合每次推理。摘要解决「快速知道大概」，索引解决「知道去哪里找」，原始证据解决「结论是否可信」。三者分别是 recall、routing、grounding，不能互相替代。
Q4：新旧记忆冲突怎么办？
先看来源和明确程度：用户显式纠正优先于模型推断，当前业务系统状态优先于历史摘要；再看时间：新事实通常覆盖旧事实，但保留旧记录失效痕迹。删除请求则要做真正的级联删除，不能只在摘要里改一句话。
Q5：怎么防止记忆被污染或提示注入？
核心是权限和信任分层。网页、工具输出、仓库文件只能作为数据，不能因为被写进记忆就变成指令；写入前做来源标记和敏感信息脱敏；读取前按用户、租户、项目过滤；高风险动作回到当前工具或业务系统做确定性鉴权。
Q6：那什么时候该用向量库？
当历史内容规模大、表达高度多样、用户自己也说不准关键词时，向量召回有价值。生产上通常不是纯向量，而是 metadata filter + keyword/BM25 + vector + recency/importance rerank。精确状态、权限和审计仍由结构化存储负责。
Q7：记忆系统怎么评测，不能只看回答像不像？
要分链路评测：写入是否高信号、召回是否命中、证据是否支撑结论、冲突和过期是否被处理、删除是否彻底，最后才看任务成功率和用户重复纠正次数。最好是标注集离线评测 + 线上开关 A/B；否则无法判断是记忆没用，还是模型本来就不会。
Q8：ChatGPT 和 Codex 的记忆是同一套吗？
不能说同一套。ChatGPT 更偏用户长期偏好和事实连续性，Codex 更偏仓库事实、任务恢复和可复用流程；Codex 的原始 rollout、分层摘要、按需证据和当前仓库复核机制更容易观察。面试时讲共享的工程原则，不要把内部实现说成确定事实。
六、露馅点 vs 加分点
- ❌ 张口就是「存向量库、做 RAG 检索」→ ✅ 先说向量库只负责相关性召回，再补写入、更新、过期和审计
- ❌ 把记忆等同于存聊天记录 → ✅ 区分工作上下文、会话证据、提炼记忆和过程记忆
- ❌ 每轮对话直接沉淀长期偏好 → ✅ 先存原始证据，再两阶段异步提炼，允许 no-op
- ❌ 摘要、索引、原文混成一个库 → ✅ 摘要负责快速回忆，索引负责路由，原始证据负责 grounding
- ❌ 不知道状态复写问题 → ✅ 主动提双时间机制和失效记录
- ❌ 把所有记忆都注入上下文 → ✅ 常驻小摘要 + 按需索引 + 只读 1 至 2 份证据
- ❌ 把过期记忆当当前事实 → ✅ 对易漂移信息重新读取当前源，并说明不确定性
- ❌ 认为生产级记忆必须依赖向量库 → ✅ 能举 Codex 的摘要/索引/证据路线和 Claude Code 的文件系统路线
- ❌ 只设计写入，不设计删除和评测 → ✅ 讲作用域隔离、级联删除、审计和分链路指标
七、一句话收尾
记忆管理不是「一个向量库」的事，而是证据保存、异步提炼、渐进读取、时间冲突、权限治理和效果评测的完整工程。ChatGPT/Codex 的核心是「原始证据可追溯，摘要索引控成本，按需证据保准确」；Claude Code 进一步印证了底层原则：上下文只是缓存，持久状态必须能够从磁盘重建。