Agent 记忆写入机制深度解读：Claude Code 的工程化实践

🧠 核心问题

Agent 的记忆应该由谁来写？这是一个看似简单却决定 Agent 长期可用性的架构问题。如果完全依赖用户手动触发记忆写入，大部分有价值的信息会被遗漏 —— 因为用户对话时注意力在当前任务上，不会停下来想"这条该不该记"。Claude Code 给出的答案是：让后台子 Agent 自动提取记忆，整个过程用户无感知。

这个设计的核心矛盾在于：自动化带来便利，也带来失控风险。记忆写错、写重、写出幻觉，都比没记忆更糟糕。Claude Code 通过四个工程化机制，在"自动化"和"可控性"之间找到了平衡点。

⚙️ 整体流程

每次对话结束（主模型给出最终回答），后台悄悄启动一个独立子 Agent，它回顾对话内容，判断是否有值得长期保存的信息，若有则写入记忆文件。整个过程用户完全无感知。

• 触发时机：主模型回答完成 → 后台子 Agent 启动
• 执行方式：独立子 Agent，与主会话隔离
• 用户感知：零。用户继续对话，记忆提取在后台静默完成

🔑 四大关键设计机制

1. 权限锁死

后台子 Agent 的权限被严格限制，仅能执行以下操作：读取文件、搜索文件、用只读命令查看目录和文件内容、在记忆目录里写入和编辑文件。不能执行任何有副作用的命令（修改代码、启动其他 Agent、调用外部服务等）。

2. 两轮对话策略

子 Agent 最多在五轮对话内完成任务，设计意图是两轮搞定：

• 第一轮：并行读取所有需要的文件 —— 现有记忆文件列表（了解已有内容，避免重复）+ 最近对话内容（找出值得保存的信息）
• 第二轮：并行写入所有记忆文件，将提炼的记忆一次性写完

3. 互斥机制

若主模型在对话过程中已自行写入记忆文件，后台的记忆提取会直接跳过。

4. 游标和合并

游标机制和合并机制协同工作，解决成本和并发两个问题：

• 游标机制：子 Agent 维护一个游标，记录上次处理到的消息位置，每次只看游标后的新消息，大幅降低每次提取的输入量和成本。若提取失败，游标不推进，下次会重新处理这些消息，确保不丢失有价值信息。
• 合并机制：若上一次提取还在运行，新的对话上下文会被暂存，等当前提取完成后，再用最新上下文跑一次，避免多个子 Agent 同时运行产生冲突。还可配置触发间隔（如每两轮或三轮触发一次），降低高频对话场景下的后台计算开销。

🏗️ 对自建 Agent 记忆系统的启发

如果要给自家 Agent（如基于 OpenClaw 框架）加上类似的自动记忆提取能力，需要做到三件事：

1. 限制提取过程的权限：只允许读对话和写记忆文件，不能执行有副作用的操作。OpenClaw 的 subagent 天然支持 isolated session，可以做权限收窄。
2. 记录上次处理位置：下次只看新内容，避免重复处理整段历史。这是降低 token 成本的关键，也是当前 OpenClaw 记忆系统缺失的核心能力。
3. 处理主模型自行写记忆的互斥场景：若主模型已自行写记忆，就跳过自动提取，避免重复。

📊 机制对比：Claude Code vs 当前实践

维度 Claude Code 当前手动模式 记忆写入主体 后台子 Agent 自动提取 用户手动触发 / 主模型顺手写 权限隔离 严格限制，只读+写记忆目录 无隔离，主模型全权操作 增量处理 游标机制，只处理新消息 每次全量上下文，成本高 并发控制 合并机制，避免多 Agent 冲突 不存在并发问题（手动串行） 成本控制 共享缓存 + 五轮上限 无显式控制 互斥机制 主模型写了就跳过 不适用

逍遥云初 | 2026.04.17