Agent 如何积累经验与自我学习：从反思、长期记忆到后台整理

2026-10-110 评论0 阅读3.9k 字

Agent 要在下一次任务中少犯同样的错误，需要把执行结果转化为可复用的经验，再在合适的时候读回来。对采用固定模型 API 的应用来说，这通常通过外部记忆、检索和工作流程更新来实现，不需要每次交互都修改模型参数。[1][2]

例如，一个编程 Agent 在第一次修改配置时找错了工作目录。它随后修复了问题，并记录：在这个项目中，配置文件位于 server/config/；修改前先确认仓库根目录、读取原文件，完成后运行配置校验。下次处理同类任务时，这条经验进入上下文，Agent 就有机会绕过上次的错误。

这里积累的是系统能够利用的经验。基础模型是否变强，是另一个需要单独训练与评估的问题。

一、先分清三种“学习”

方式	改变什么	能保留多久	常见用途
当前会话中的适应	本轮上下文、计划和执行策略	取决于会话保留与压缩方式	根据报错调整操作，理解临时要求
跨会话经验积累	外部记忆、规则、技能和检索索引	持久保存，直到更新或删除	复用项目约定、用户偏好、有效流程
参数学习	模型权重或适配器参数	随模型版本保存	训练较稳定的领域能力或输出行为

Reflexion 论文给出了不更新权重的实现：Agent 根据任务反馈形成文字反思，保存在情节记忆中，供后续尝试使用。ACE 研究则把上下文作为可以持续维护的策略手册，通过生成、反思和整理积累经验。它们说明，调整后续输入也能改变 Agent 的任务表现，但效果仍取决于具体任务和评估条件。[2][3]

工程上可以把参数训练放在独立的、可评估的版本迭代里；把日常纠错和项目经验放在可编辑、可撤销的记忆系统里。两者可以配合。

二、为什么不把每次纠错都变成一次微调

参数更新需要训练数据、训练任务和验证流程。OpenAI 的模型优化指南把评估、提示词改进和微调放在一个迭代流程中，而不是把每次对话中的纠正直接视为训练数据。[4]

一次失败可能来自错误的工作目录、过期文档、临时网络故障，或者缺少权限。即便模型推理没有问题，也可能执行失败。把这些事件直接训练进权重，容易学到错误的对应关系。

持续微调还需要检查旧能力是否退化。关于大模型持续指令微调的实证研究观察到了灾难性遗忘，涉及领域知识、推理和阅读理解；研究同时指出，训练安排可以缓解这种现象。因此，遗忘是一项需要控制的风险，不是每次微调都必然发生的结果。[5]

训练耗时也没有统一数字。模型规模、训练参数量、数据量和硬件都会影响成本，不适合用“从几百毫秒变成几十分钟”概括所有情况。对日常经验，外部记忆更便于定向修改：更换一个失效命令、撤销一条错误推断，都不必重新训练模型。

三、经验积累需要一条完整的闭环

下面是一种可实施的记忆系统设计。流程中增加验证和筛选，避免把所有复盘文字都直接写成长期规则。

flowchart TD
    A[执行任务] --> B[收集结果与反馈]
    B --> C[生成候选经验]
    C --> D{验证与筛选}
    D -->|通过| E[持久化记忆]
    D -->|不通过| F[保留日志或丢弃]
    E --> G[后台合并与更新]
    G --> H[按新任务检索]
    H --> I[注入有限上下文]
    I --> A

1. 反思必须从执行结果出发

有用的反馈包括编译器报错、测试结果、接口返回、用户明确纠正，以及执行后的回读检查。模型生成的失败解释只能作为候选原因，不能替代这些结果。

例如，调用工具返回“找不到文件”，可能是路径错了，也可能是文件尚未生成、挂载不可见或执行环境不同。直接记下“以后都改用绝对路径”会把一次故障扩大成通用规则。

更合适的记录应限定范围：

在项目 A 的容器环境中，命令默认工作目录不是仓库根目录。执行配置校验前先切换到已确认的仓库目录。该流程已通过一次成功校验，容器入口调整后需要复核。

成功任务也值得提炼：有效的排查顺序、可重复运行的构建流程、可靠的结果验收方法，都可以形成候选经验。Reflexion 支持使用不同类型、不同来源的反馈，而不只限于错误消息。[2]

2. 筛选决定哪些经验能够留下

建议把新经验分成三种状态：待验证、已验证、已失效。用户明确表达的长期偏好可以直接记录；模型推断出的技术原因应保留为待验证，直到有工具结果或后续任务支持。

记录之前可以检查：

未来是否会在其他任务中复用？
是否能从现有代码或文档直接获取，是否值得重复保存？
是否包含适用项目、环境或版本？
是否有可追溯的依据？
是否与已有记录冲突，或者包含不应保存的敏感内容？

“今天某次下载超时”通常留在日志里即可。“这个内网环境需要通过指定代理下载依赖”才可能成为环境经验，而且需要验证。

3. 归档要保存适用范围和来源

聊天记录适合回溯，但不应直接等同于经验库。建议把可复用经验保存为独立记录，每条表达一个事实或一个行动规则。

一份示意记录可以写成：

id: memory-0042
kind: procedure
scope: project-a/container
trigger: 修改配置文件或执行配置校验
lesson: 先确认仓库根目录并读取原配置，再修改目标文件
evidence: task-018 的路径错误与 task-019 的成功校验
status: validated
last_verified_at: 2026-10-11
recheck_when: 容器入口或仓库目录结构变化
supersedes: memory-0017

这些字段是设计示例，不是某个产品的固定格式。实际存储可以使用 Markdown、关系数据库或两者结合。文本保存内容，数据库管理状态与版本，搜索索引负责召回，不必把所有职责塞进一种存储里。

4. 检索之前，先限定范围

检索可以按“权限与范围过滤 → 候选召回 → 排序去重 → 上下文裁剪”的顺序实现。

先确定用户、项目、设备和环境，再查关键词与语义相似的记录。文件路径、错误码和命令名适合关键词匹配；描述方式不同但含义相近的经验适合语义匹配。OpenClaw 的记忆搜索就是一个混合检索案例。[8][9]

把项目 A 的部署经验检索给项目 B，可能比没有记忆更糟。多用户系统更不能只靠提示词隔离，应在检索查询和存储访问层限制可见范围。

5. 注入的是少量相关经验

Anthropic 的上下文工程文章强调，上下文是有限资源，需要挑选高信号的信息。文中介绍了压缩、结构化笔记和多 Agent 等长期任务策略。[1]

一种实用的注入方式是只给当前任务需要的条件与行动：

相关经验：
- 适用范围：项目 A，容器环境。
- 修改配置前，先确认仓库根目录并读取原文件。
- 修改后运行项目配置校验；容器入口变化时重新确认此流程。
- 来源：task-018、task-019；状态：已验证。

完整日志保留在外部，必要时再读取。注入内容还应区分用户明确约定、已验证的技术经验和未验证的模型推断，避免它们获得相同的可信度。

四、Claude Code、Codex 和 OpenClaw 怎么做

三者都是具体产品或工具实现，不代表所有 Agent 都采用相同机制。

系统	持久化与整理	读取方式
Claude Code	人工维护的 `CLAUDE.md`，以及自动记忆目录中的 `MEMORY.md` 与主题文件	会话启动加载规则和有限长度的自动记忆索引，主题文件按需读取
Codex	后台提取会话经验，写入状态数据库；再由整理 Agent 更新本地 Markdown 记忆与可选技能	摘要引导检索，按需查找手册条目、会话摘要及相关文件
OpenClaw	Markdown 保存用户信息、长期记忆与每日笔记；记忆后端建立检索索引	启动加载部分记忆，通过搜索工具召回其他相关内容

Claude Code：短索引与主题文件

Claude Code 官方文档区分了人工规则与自动记忆。CLAUDE.md 用于编码约定、工作流程等指令；自动记忆用于偏好、纠正和无法从代码直接推导的项目背景。[6]

自动记忆的 MEMORY.md 是索引。会话启动时加载前 200 行或前 25KB，以先达到的限制为准；主题文件不会全部在启动时加载，而是按需读取。这个限制针对自动记忆索引，不应套用到所有规则文件。[6]

Codex：数据库处理候选，文件承载整理结果

OpenAI 的 Codex 仓库公开了两阶段记忆流水线：第一阶段从符合条件的历史会话中提取结构化记忆，把结果写入状态数据库；第二阶段选择候选、同步文件，再运行专门的整理子 Agent。[7]

整理输出包括 MEMORY.md、memory_summary.md 和可选的 skills/。整理提示词要求支持渐进式读取，并复用已经验证的流程和检查清单。因此，数据库只是流水线的一部分，最终可用记忆也包含本地文件。[7][10]

这些描述对应公开仓库中的记忆实现。流水线需要记忆功能启用等条件，不能据此认为所有 Codex 会话都会执行后台学习。

OpenClaw：可读的文本与混合搜索

OpenClaw 官方文档把工作区中的 Markdown 作为记忆载体，区分用户信息、长期记忆与每日笔记。搜索层支持语义召回和关键词匹配，Agent 可以先搜索，再读取具体片段。[8][9]

这种分工让记忆内容可以人工检查，而索引负责提高查找效率。文档也提醒，记忆可以记录操作边界，却不能替代审批和沙箱等硬性控制。[8]

五、“做梦”机制实际整理什么

记忆不断追加后，会出现重复、冲突和过时记录。后台整理的工作是重新组织这些内容，而不是无限扩写摘要。

Anthropic 在 Claude Managed Agents 中公开了 Dreams 机制：读取已有记忆库和历史会话，生成新的、经过整理的记忆库，合并重复项，替换过时或被新信息推翻的记录，并提炼新的发现。输入记忆库不会被直接修改，输出可以审阅或丢弃；官方文档将其标为研究预览功能。[11]

“AutoDream”式整理可以作为这一类后台任务的描述，但具体产品的触发条件和能力需要分别确认。做梦也是功能比喻，不能据此认为系统复现了人类睡眠时的记忆机制。

对于自行实现的 Agent，建议后台整理输出增删改提案，而不是直接覆盖整个库：

操作	示例	应保留的信息
合并重复	多次记录了同一个构建命令	各次来源与适用范围
替换过时	新入口替代旧入口	新旧版本关系、失效原因
处理冲突	两个环境使用不同部署流程	环境条件，不能强行选一个
提炼流程	多次成功任务遵循相同检查顺序	验收标准与已知例外

整理时还应使用一致的输入快照，避免新记忆与清理操作互相覆盖；高影响的规则变化先审阅，再发布到活动记忆版本。这样才能在整理出错时回滚。

六、一套可以从小规模起步的实现

下面是工程设计建议，不是上述产品共有的默认配置。

初版可以只包含任务日志、候选经验表、活动记忆表和检索接口。不必一开始就引入复杂的向量库，先让关键词搜索和范围过滤工作可靠，再根据漏召回情况加入语义检索。

在线任务只读取已发布的记忆版本。任务结束后，后台提取候选；验证通过后才加入活动记忆。整理过程构建新版本，检查通过后原子切换，避免执行中的 Agent 读到半份旧规则、半份新规则。

任务开始：
  确定用户、项目、环境和记忆版本
  检索允许访问的活动记忆
  排序、去重，按上下文预算注入

任务结束：
  保存执行结果和明确反馈
  提取候选经验，检查来源与敏感信息
  验证可复用性，合并或替换相关记录

后台整理：
  读取一致快照，生成变更提案
  执行冲突检查与回归评估
  发布新记忆版本，保留回滚记录

用户要求“忘掉某条信息”时，需要同步处理活动记录、索引和缓存；如果历史日志仍然保留，也要避免下一轮整理再次把它提取回来。

七、怎么判断 Agent 真的学到了

经验条数增加，只说明写入成功。要判断系统是否改善，可以设置三组对照：不使用长期记忆、只使用人工规则、使用经过筛选的经验记忆。保持模型、工具和任务预算一致，在相似但不完全重复的任务上比较。[4]

建议关注任务成功率、同类错误复发率、工具调用次数、执行成本和人工纠正次数。同时检查注入的记忆是否相关、是否过时，以及是否让原本能完成的任务失败。

评估要防止“记住答案”被当成能力提升。用于测试的任务不应提前进入记忆库；否则系统可能只是检索到了测试结果。

错误反思也可能损害后续表现。2026 年的 VRL-Bench 在有限尝试预算下比较了多种文字记忆方法，观察到某些设置中表现改善、另一些设置中表现下降。这提示记忆系统需要回归测试，不能默认每条反思都有帮助。[12]

对于资金操作、生产部署和数据删除等高影响行为，经验只能辅助规划。授权、审批和执行限制仍应由工具与应用层控制。[8]

结语

Agent 的跨会话经验积累，可以通过固定模型与外部记忆协作来实现。需要维护的不只是记忆内容，还包括来源、适用范围、有效状态、召回方式和版本。

一个有用的闭环是：从真实结果提取候选，验证后归档，新任务中按需读取，再用执行表现检验它是否仍然有效。后台整理负责压缩重复项、更新失效经验；评估负责发现那些看起来合理、实际却有害的规则。[1][2][11][12]

参考资料

Agent AI 编程