Agent 记忆、压缩与生命周期治理
本页由 [[wiki/concepts/Agent 原理、记忆与上下文工程]] 拆分而来（2026-07-05），承接 Agent 记忆、上下文压缩与运行生命周期治理。原页保留总览和路由入口。
记忆不是多存点东西
- 新资料提到的 ChatGPT 四层记忆、OpenClaw 混合检索、紧凑指令与上下文压缩，都在说明：记忆系统的关键不是越多越好，而是能不能在正确时机把正确信息拿回来。 [[raw/2026-04-28/侑夕/你不知道的 Agent：原理、架构与工程实践.md|来源: 你不知道的 Agent：原理、架构与工程实践.md]]
- 如果检索和压缩做不好，上下文会越堆越脏，模型反而更容易跑偏。 [[raw/2026-04-29/李泽宇的AI实验室/300 亿 Token，30 万行代码，30万字烧出来的Harness实践，我开源了.md|来源: 300 亿 Token，30 万行代码，30万字烧出来的Harness实践，我开源了.md]]
AutoDream：Agent 的”做梦”式记忆巩固
- Anthropic 上线 AutoDream 功能——在 agent 空闲时后台自动进行记忆巩固。设计灵感直接来自认知科学：人类在 REM 睡眠中重放白天经历，将短期记忆转化为长期记忆。四阶段流程：Orient → Gather → Consolidate → Prune & Index。三重门控机制确保不干扰正常运行：24 小时间隔 + 至少 5 个 session + 文件锁防并发。 [[raw/2026-05-07/金色传说大聪明/Anthropic 上线「做梦」功能，让 Agent 越睡越聪明.md|来源: Anthropic AutoDream]] [[raw/2026-05-07/三元同学/一文讲清楚 AutoDream：Claude Code 是如何-做梦-，更新记忆的？.md|来源: 三元 AutoDream详解]]
知识巩固的两条路线
- AutoDream（Anthropic 生态）：全自动后台巩固，侧重清洗与压缩，不需要人工介入。
- Hermes Curator（OpenClaw 生态）：知识自动复利，侧重结构化沉淀与跨 agent 共享。 [[raw/2026-05-08/朗朗晴空/构建智能知识基地：Hermes 用户如何让知识自动复利.md|来源: Hermes知识复利]]
- 两条路线目标一致但实现哲学不同：AutoDream 偏”自动清理”，Hermes 偏”结构化积累”。
Hermes 四层记忆系统（来自 jilolo）
- 四层：提示词记忆(MEMORY.md/USER.md) + SQLite会话搜索 + 技能即过程记忆 + Honcho深度用户建模
- 核心设计：提示词缓存优先——热记忆压到~1300tokens，冷记忆存SQLite+FTS5，按需检索后先总结再交模型
- “压缩前记忆刷新”：长对话压缩前先注入合成指令让模型主动写入MEMORY.md
- Hermes vs OpenClaw：Hermes热+冷分层(缓存意识优先) vs OpenClaw追加式日志(存储优先)
- 记忆是复数：语义记忆+情景记忆+过程记忆+用户建模
- 来源：[[raw/2026-05-16/jilolo/Hermes，补上了 Agent 记忆系统最关键的一块.md|来源: Hermes记忆]]
矛盾：与OpenClaw的”Markdown优先存储”存在架构张力——已在[[wiki/syntheses/矛盾与视角差异]]中
Claude Code 的四层记忆模型
- 借用认知科学框架，Claude Code 将 agent 记忆分为四层：工作记忆（上下文窗口，极易失）→ 程序性记忆（Skills，可复用行为模板）→ 情景记忆（JSONL session 历史，带时间戳的完整轨迹）→ 语义记忆（MEMORY.md / Auto Memory，提炼后的长期知识）。设计原则很明确：尽量少装在工作记忆里，尽量多落盘到文件系统。 [[raw/2026-05-08/晋小辰/Harness Engineering：从 Prompt 工程到系统工程.md|来源: 晋小辰 记忆模型]]
上下文工程三大Agent横向对比（来自 歪斯Wise）
- Claude Code：五层渐进预算调度
- OpenClaw：开放自定义Context Engine
- Hermers：窗口到50%就开始压缩，压缩产物是结构化交接文档(当前目标+完成进度+核心决策+涉及文件+下一步)，而非简单摘要
- 来源：[[raw/2026-05-17/歪斯Wise/上下文工程ClaudeCode、Hermers、Openclaw.md|来源: 上下文工程对比]]
ContextBucket：Agent 记忆与工作区统一底座（2026-06 新增）
火山引擎的 ContextBucket 托管服务在 OpenClaw 上的实测结果验证了统一的记忆/工作区底座对 Agent 能力的巨大提升。核心解决三类断层：记忆随会话消失、工作文件无法跨实例持久化、多 Agent 共用存储的权限审计混乱。[[raw/2026-06-04/火山引擎存储/ContextBucket：Agent 的-无限-记忆与工作区底座.md|来源: ContextBucket]]
技术要点：
- 向量 + BM25 + Rerank 多路检索，三路召回合并重排
- 智能事实提取：只沉淀关键事实（需求决策、技术结论、用户偏好），过程噪声不保存
- 时间表达归一化：对”昨天""上周”做特殊处理避免时间歧义
- FUSE 挂载工作区，文件远端持久化，Agent 侧无需感知底层差异
- ContextSet 千万级原生多租隔离
Locomo 评测数据：正确率 16.45% → 64.14%（↑48pp），输出 Token 减少 80%，计费 Token 减少 43.2%。
（参见 [[上下文管理与 Harness Engineering#ContextBucket：Agent 记忆与工作区统一底座]] 获取完整架构分析。）
TencentDB Agent Memory：四层渐进式记忆架构（2026-06 新增）
腾讯云数据库团队开源的 Agent Memory 项目（4600+ Star），提供了一个不同的记忆方案——符号化短期记忆 + 分层长期记忆。[[raw/2026-06-04/逛逛/腾讯开源了 Agent Memory，让 AI 真正记住你。.md|来源: TencentDB Agent Memory]]
四层记忆架构：
| 层级 | 内容 | 特点 |
|---|---|---|
| L0 原始对话 | 全量保留，一字不落 | 兜底用，随时可回查 |
| L1 原子事实 | 自动提取独立事实节点 | ”我爱吃火锅”、“我用 NextJS” |
| L2 场景聚类 | 相关原子事实按场景聚合 | Markdown 格式，人可直接读 |
| L3 用户画像 | 稳定的用户画像 | 技术偏好、代码风格、工具链 |
核心设计：系统保证从顶层到原始证据有完整的回溯路径。L3 说用户偏好 TypeScript，这个结论可追溯到 L2 场景块 → L1 原子事实 → L0 原始对话。整条证据链不断裂。
短期记忆创新：用 Mermaid 语法画任务状态图（少量 token 编码拓扑结构），替代传统的线性日志摘要。细节通过节点 ID 按需检索——Token 消耗直降超 50%，任务完成率反升 23%。
评测数据（PersonaMem）：总准确率 47.85% → 76.10%（+59%），用户事实召回 29.63% → 79.07%（+167%），SWE-bench 通过率 58.4% → 64.2%，token 省 33%。
与 ContextBucket 的关系：TencentDB Agent Memory 偏开源插拔和本地优先（SQLite + sqlite-vec 零配置开箱即用），ContextBucket 偏云端托管和企业级底座（Serverless 多租过滤，适合规模化部署）。两者解决的共同问题——Agent 记忆无法跨会话/跨设备持久化。
Anthropic 递归自我改进数据：证明回忆能力的重要性正在上升（2026-06 新增）
Anthropic 研究院发布的《When AI builds itself》报告披露了 AI 自我加速的关键数据：Anthropic 工程师平均每季度代码交付量是 2021-2025 年期间的 8 倍。模型能独立完成任务时长每 4 个月翻一番（此前为 7 个月）。这意味着 Agent 的工作持续时间从分钟级向小时级跃迁——记忆系统的战略重要性随之提升，因为数个 Agent 需要跨会话持续积累上下文。[[raw/2026-06-05/AI兴观点/半年52 倍优化，颠覆认知。Anthropic 报告里更值得深挖的信息是：AI 迭代飞轮已启动，甚至参与研究决策了。.md|来源: 递归自我改进]] [[raw/2026-06-05/数字生命卡兹克/Anthropic万字长文：当AI开始构建自己，人类该何去何从？.md|来源: 当AI构建自己]]
工业级四层记忆架构：从”短期+长期”到分层治理（2026-06 新增）
尼恩 AI 架构团队基于 Hermes、OpenClaw、DeerFlow 三大开源项目对比，系统梳理了 Agent 记忆系统从传统两层（短期+长期）到工业级四层的完整技术演进。核心判断：90% 的人对记忆系统的认知还停留在两三年前的”短期+长期”两层架构，但真实线上环境里纯两层架构早就不够用了——本质问题是粒度太粗、边界模糊、缺少治理。 [[raw/2026-06-14/尼恩AI架构团队/字节面试官：Agent记忆系统如何设计？工业级 四层 memory infra 记忆底座架构 与实战.md|来源: 四层记忆架构]]
四层记忆核心参数对照表
| 记忆层级 | 定位 | 存储介质 | 典型容量 | 访问延迟 |
|---|---|---|---|---|
| 第 0 层 上下文窗口记忆 | 热记忆/当前交互 | LLM 原生上下文 | 4k～128k tokens | 最低 |
| 第 1 层 工作记忆 | 任务认知黑板/长任务必备 | 内存/文件/任务状态 | 无硬限制 | 低 |
| 第 2 层 会话记忆 | 单会话完整历史 | SQLite/本地文件 | 单会话无限 | 中 |
| 第 3 层 长期记忆 | 跨会话知识沉淀 | 文件/DB/向量索引 | 理论无限 | 较高 |
第 1 层工作记忆：传统两层架构的致命死穴
传统短期记忆是”对话流水账”，按时间排序存原始对话；工作记忆是结构化的任务认知——存的是任务目标、实体关系、中间产出，和对话顺序无关。没有工作记忆层，长任务跑着跑着就忘了最初的目标。典型案例：用户要求”写一份 10 个章节的行业报告”，跑了 3 小时后 Agent 忘了要写 10 章只输出 3 章。工作记忆的四个核心能力：① 任务目标锚定（永久记住最终目标防跑偏）；② 实体关系图谱（记录人事物关联）；③ 中间结果持久化（不用反复重算）；④ 断点续传（从上一状态继续）。 [[raw/2026-06-14/尼恩AI架构团队/字节面试官：Agent记忆系统如何设计？工业级 四层 memory infra 记忆底座架构 与实战.md|来源: 工作记忆]]
为什么不把所有记忆都塞上下文
三个现实问题：① 成本——上下文是 O(n²) 的 Token 开销，1M 窗口成本几十倍上涨；② 注意力——长上下文存在”中间遗忘效应”，模型注意力集中在开头和结尾；③ 延迟——窗口越大推理越慢，C 端产品扛不住。窗口再大，分层记忆依旧是工程最优解。
记忆熵增定律：只存不治的必然结局
真实线上事故：某团队智能客服上线半年，用户说”我要退款”Agent 还在发优惠券——三个月前该用户咨询过优惠券，过时记忆没清理，检索权重高把最新请求盖过去了。记忆熵增定律：只要不加治理，记忆系统一定会自发从有序走向混乱。只存不治必然出现三个问题：重复记忆（同一事实存 N 遍）、过时记忆（信息过期还在用）、冲突记忆（新旧事实矛盾 Agent 不知道信哪个）。
五大治理机制
- 记忆准入：写入前做”资格审查”——重要性打分（低于阈值不存）+ 语义去重校验 + 事实校验
- 合并与归一化：语义去重合并（相似度超阈值自动合并）+ 实体归一化（“张三”/“张总”/“张工”统一成一个 ID）+ 冲突解决（新旧覆盖）
- 过期与主动遗忘：时间衰减曲线（90 天过期）+ 访问频率衰减 + 定期清理。核心记忆永久保存，普通记忆 90 天过期，临时记忆会话结束就删
- 记忆升降级：对话溢出→第 0 层写入第 2 层；会话结束→精华提炼写入第 3 层；检索命中→第 3 层注入第 0 层
- 安全与可解释性：用户可控（查看/编辑/删除）+ 审计日志（全链路追溯）+ 防注入防护（记忆写入前做恶意指令检测）
三大黄金原则
- 分层原则：冷热分层，按需加载——热记忆放缓存求速度，温记忆放本地数据库求连贯，冷记忆放向量库求容量
- 治理原则：对抗熵增，动态治理——“宁可少存也别乱存”，上线前只做存取不做治理，半年后只能全量清库重来
- 务实原则：场景驱动，拒绝炫技——“技术没有高低，只有适合不适合场景”
[[raw/2026-06-14/尼恩AI架构团队/字节面试官：Agent记忆系统如何设计？工业级 四层 memory infra 记忆底座架构 与实战.md|来源: 三大黄金原则]]
2026-07 更新：记忆、压缩与运行生命周期
新增资料把 Agent 记忆从”把历史存起来”纠正为生命周期治理问题：工作记忆、长期记忆、压缩摘要、checkpoint、事件流和事实层各有职责，不能把它们都塞进一个向量库或一个聊天记录里。[[raw/2026-06-29/算法狗/字节二面被问：-工作记忆在 Agent 执行任务时，究竟承担什么角色？-，我说：-临时储存信息的地方-,他说：-这么说没错，但是不全面…-.md|来源: 工作记忆]] [[raw/2026-06-30/45岁老架构师尼恩/阿里面试：为什么 长期记忆分成 静态长期记忆 和 动态长期记忆 ？长期记忆爆炸了，怎么解决？.md|来源: 长期记忆分层]] [[raw/2026-06-25/Jameszyh/上下文压缩的反直觉设计：压缩不等于截断，结构化摘要怎么保住缓存命中率.md|来源: 压缩不等于截断]]
工作记忆不是短期缓存：它是当前任务的主动加工空间，负责保存中间假设、未决问题、当前计划、工具结果和下一步决策依据。短期缓存只是数据暂存；工作记忆要能支持推理连续性和任务恢复。[[raw/2026-06-29/算法狗/字节二面被问：-工作记忆在 Agent 执行任务时，究竟承担什么角色？-，我说：-临时储存信息的地方-,他说：-这么说没错，但是不全面…-.md|来源: 工作记忆]]
长期记忆应拆成动态 History 与静态 Facts：History 记录发生过什么，Facts 记录稳定事实和偏好。长期记忆爆炸的根因是只追加、不筛选、无生命周期；解决方向是去重、过期、晋升、降级和冲突标记，而不是一味扩大上下文。[[raw/2026-06-30/45岁老架构师尼恩/阿里面试：为什么 长期记忆分成 静态长期记忆 和 动态长期记忆 ？长期记忆爆炸了，怎么解决？.md|来源: 长期记忆分层]]
压缩不是截断：结构化压缩应保护开头任务契约和尾部最新状态，处理中部历史，并保留 tool_call/tool_result 配对。把历史压成一段”大概做过什么”会破坏缓存命中、证据链和恢复能力。[[raw/2026-06-25/Jameszyh/上下文压缩的反直觉设计：压缩不等于截断，结构化摘要怎么保住缓存命中率.md|来源: 压缩不等于截断]] [[raw/2026-06-30/孔某人/主流Agent Harness实现对比——Context压缩.md|来源: Context 压缩对比]]
协议视角补上运行生命周期：Thread/Run/Step/Event/Artifact/Checkpoint 让 Agent 从黑盒对话变成可中断、可恢复、可审计的执行体。这一层比具体框架更稳定，应该作为理解 Agent Runtime 的底层对象模型。[[raw/2026-07-02/晓灰/相比层出不穷的 Agent 框架，不变的 Agent Protocol 是什么.md|来源: Agent Protocol]]
/compact 不是普通摘要：07-05 的工程拆解把它描述成“结构化重写 + 客户端补偿”的组合。压缩触发后，模型按固定 9 章模板生成结构化摘要；客户端丢弃中间分析，只保留摘要，再附加最后 assistant 衔接、文件自动附录、hook context、planAttachment、skillAttachment 等状态材料。它暴露的核心矛盾是：摘要能省 token，但会丢位置信息和过程细节，所以真实恢复还要靠文件重读、计划附件和技能附件补偿。[[raw/2026-07-05/算法狗/蚂蚁面试官：claude code的-compact到底做了啥- 我说-自动总结-，他说我理解的太肤浅了.md|来源: compact工程拆解]]
相关页面
- [[wiki/concepts/Agent 原理、记忆与上下文工程]]
- [[wiki/concepts/上下文管理与 Harness Engineering]]
- [[wiki/entities/Claude Code]]
- [[wiki/syntheses/矛盾与视角差异]]