AI 代理怎样积累可以复核的记忆

一个长期运行的代理可以保存每次对话、每次命令和每份输出，却仍然在下一次任务中反复犯错。保存回答的是发生过什么，记忆还要回答哪些经历值得带到下一次、它们何时仍然成立，以及新的证据出现后应修改哪条旧结论。对工程团队来说，这些都是可以拆开设计的能力。把上下文窗口扩大，能够延后内容装不下的时点，但不能决定一段记录的可信度，也不能告诉代理该去哪里查证。

公开原文：The components of agent memory

原文给出的证据与边界

这篇公开工程文章讨论跨会话保留的经验。模型参数在这些案例中没有因为单次任务而变化，经验通过文件和检索工具交给下一轮。作者把记忆分成不同层次：会话记录保留原始经历，笔记摘出可能会重用的观察，类似维基的资料结构组织彼此相关的笔记，而少量最重要的内容可以在新会话开始时主动提供。原文还展示一种离线整理方式，让模型在没有新请求时重新检查记录、纠正笔记和调整知识结构。

实验提供了几种不同强度的证据。在持续学习基准的一个数据库任务中，模型能在不同问题之间读写同一记忆目录，答题后获得正确答案。部分模型会验证自己的猜想再留下规则，部分模型则保存许多未验证的解释。公开图表给出的两个数字可以说明这种差别并非只是文件写法：在该数据库任务里，Opus 5.5 的平均奖励由约零点六六升至零点八四，Sonnet 4.6 由约零点三三升至零点三六。这些是指定任务和配置下的结果，不能换算成生产代理的成功率。

另一项探索让代理在游戏里保留跨会话笔记。作者举出一个路线记错的案例，离线检查根据早期行动记录纠正了方向，随后代理走到了下一座城市。这个案例表明，一条关键笔记确实可能改变后续行动。游戏案例中的对比不能把进度差异全部归因于记忆组织方式，参与比较的模型能力也不同。作者还在一个文档语料上考查维基和搜索的组合，给定问答集上，随着整理会话增加，维基单独使用时的评分有所上升。该问答集规模有限，不能说明离线整理总能带来同样收益。

下面的工程分析沿用这些区分，重点讨论怎样把经验变成可以审查和撤销的资产。文中的工作场景是明确标出的假设，不是原文的实验结果。

先区分记录、推断与可执行规则

一条会话记录通常包含不同性质的内容。工具返回的状态码是一次观察，代理对失败原因的解释是推断，人工批准可以建立一项当时有效的决定。把这些写在同一段自然语言里很方便，却会让下一轮读取者难以区分证据与猜想。最简单的做法是分别记录观察、结论及其支持关系，并在结论边上写清适用范围。如果代理只观察到一次失败，就应该保留可复现线索，暂时不把原因写成普遍规律。

记录在未来的用途也各不相同。某个节点当前处于等待状态，应该从任务系统重新读取；确认过的字段含义可以从版本化的规范中取出；一个不容易找到的排障路径，才适合放进记忆帮助定位。把易变状态写成长期笔记，会为同一事实增加第二个来源。两个来源产生冲突时，代理如果总先读更短的笔记，反而容易失去对实际状态的判断。可把记忆理解为快速找到问题和证据的索引，最终事实仍由能负责的来源确定。

有些经验可以提升为规则，但提升应有门槛。可以要求至少给出适用版本、验证方式和一个反例，并指出规则何时需要重新检查。比如某个测试环境需要先启动依赖，只有能稳定复现顺序相关的故障，且能在隔离环境确认正确顺序后，才值得记录为运行指引。若后续启动脚本已经自动解决依赖，旧规则可以降级为历史说明。规则升级越容易，过时知识传播越快；门槛过高又会把有用经验困在原始日志里。不同影响程度的规则可以采用不同的验证要求。

记录结构不必复杂。对于一条经验证的事实，读者应当能看见结论、证据、范围、更新时间和负责维护的人或系统。对于未完成的尝试，可以只保留任务、下一步和已排除的解释。把所有笔记都设计成完整报告会增加写入成本，产生大量无人阅读的材料。对会影响权限、数据一致性或正式发布的结论，则要留有更具体的证据和复核入口。这样可以在低成本记录和关键决策可追溯之间取得平衡。

离线整理需要一条证据链

离线作业有条件重读更多材料，并把不适合在在线请求中处理的任务放到后台。它可以找出互相冲突的条目，也可以合并反复出现的解释。风险在于，作业可能对错误形成更流畅的叙述。把四份内容相同的笔记合成一份，只增加了语言的一致性；如果四份都源于同一次错误判断，它们并不构成独立证据。整理流程应追踪笔记指向哪些原始观察，允许对照并保留冲突。

一个可行的发布方式是先生成候选差异。对于每条拟修改的笔记，列出变更原因、支持材料、可能受影响的后续任务和替代旧记录的方式。可用程序检查引用能否读取、时间范围是否矛盾，以及条目是否重复。对高影响的策略和操作步骤，再由具备权限的人审核。低风险的索引标题可以自动更新，涉及事实和规则变更时则需要明确把结果留在候选区还是提升到可用区。这样的分层使系统既能进行维护，也不会把审稿权限隐含地交给整理模型。

纠错应该留下可查询的轨迹。若某条笔记曾经被多人读取，覆盖正文可能会使后来者找不到当初为什么作出某个决定。保留旧结论、纠正原因和替代位置，可以帮助判断哪些历史任务受过影响。对于应当删除的敏感数据，则要遵守保留和删除要求，通过必要的审计事件记录曾经发生的动作。两种需求需要在设计时区分，不能用无限保存代替审计，也不能把不可追踪的覆盖当作所有纠错的默认动作。

离线整理也需要停止条件。如果每轮都把上一轮的摘要再摘要一次，重要的限定条件会逐渐丢失。可以先针对真实检索失败整理，例如某个常见问题找不到可靠入口，或已有两条规则互相冲突。若一次整理没有改变这些问题，就应该核对是任务定义不清、证据缺失，还是索引策略不合适。持续增大整理预算之前，应该看到具体失败减少，并确认新规则没有让罕见但重要的情况更难找到。

假设案例：构建代理遇到一次缓存故障

设想一个代理负责维护开源文档工具的持续集成。某次打包任务在缓存命中后失败，重新运行却成功。代理记录了失败时间、提交版本、所用运行器、缓存键和构建日志。它先写下一个猜想，缓存内容可能来自不兼容的编译器版本。这个猜想如果进入公共规则，会让后续代理遇到相似报错就清空缓存，增加耗时，也可能掩盖真正的缺陷。

离线整理时，代理把同一版本的失败记录与几次成功记录放在一起。假设它发现缓存使用同一个键，但只有依赖解析后的文件顺序不同才出现错误。下一步是在隔离环境重建这两种输入，再改变单个条件观察结果。如果仍不能复现，就保留待验证解释，并写出能缩小范围的下一步。若测试能稳定表明关键差异在依赖锁文件，经过审阅后才可以将笔记提升为一条具体规则，例如某个构建步骤的缓存键应当包含该文件的摘要。

后来构建工具升级，旧错误不再出现。系统仍应知道当时为什么修改缓存键，也应提示维护者重新评估规则。可将历史笔记链接到原始故障记录，将当前运行说明链接到新测试结果。这样，新任务不用读完整事故历史，却能在条件变化时追查。若代理对同一类报错再次建议清缓存，维护者也能判断它读到了过时条目，还是出现了一个与旧故障不同的新问题。

案例中的结果都是假设。它检验的是系统设计能否保留猜想、证据、审批和版本之间的差别，不为任何真实产品声称性能收益。这个思路也适用于其他工作，只要环境中存在可以核对的记录。例如在文档检索任务里，可以把经过核实的术语和未查证的解读分开；在排期任务里，可以将最终决定与早期草案区分开来。适用条件是读取方确实能查到正确范围的材料，且更新过程能通知依赖这些材料的人。

把跨会话读取变成一种预算

每次启动都加载全部笔记，能够提高某些事实被看见的机会，同时带来更长的上下文、更慢的响应和更高的误读风险。适合主动加载的内容，应当对多数会话都适用，而且在任务开始时有决定性作用。其余内容可以按当前任务检索。一个索引入口可以说明如何找到有关发布、测试或回退的文档，不必把这些文档的全部内容都预先放进上下文。

检索同样需要预算。若只能返回相似度最高的几条，热门术语容易盖过具体环境约束。可以把任务里的版本、组件和数据范围用于过滤，再将搜索结果按证据种类排序。例如，正在核对兼容性时优先看对应版本的发行说明和验证记录，过往问答仅提供导航。如果候选结果互相矛盾，代理应报告冲突并寻找原始记录。要求它必须给出一个答案，容易让它挑中措辞最明确的那条，而不是证据最充分的那条。

还有一种成本来自记忆本身的维护。标注太多字段会让记录者绕开流程，标注太少又无法判断适用范围。可以先跟踪几类真正反复出现的失误，比较一段时间内代理寻找证据花费的时间，以及作出错误行动后需要的返工。这样度量的是面向任务的结果，而不是索引页数量。对基本不会重复的工作，一条能找到原始记录的链接往往已经足够。对频繁交接、成本较高的工作，才更值得维护经过验证的条目。

记忆是一种长期输入权限

允许外部文档参与整理，意味着其中的内容可能从一次检索变成后续多次会话的输入。网页中伪装成规则的句子、工具输出里的恶意文字，或者一条看似合理却越权的操作建议，都可能被提升为高优先级笔记。系统应保留每段内容来自哪里以及允许用来做什么。外部材料可以帮助理解和检索事实，不能凭自己的文字授予权限。权限应由会话的实际授权或受管规则提供。

分区也应与任务本身一致。能读取某个项目日志的代理，未必可以把其中事实汇总进共享记忆。将私人内容复制到另一个长期索引，会创造一条原本不存在的传播路径。对不同范围的会话，应分别限定读取、写入、发布和删除权限。整理任务读取某份原材料时，要使用与它处理的范围相符的身份，并把输出限制到获准的位置。如果系统只在界面显示分区，而后台搜索或整理能够跨区读取，边界依然形同虚设。

记忆中的敏感信息应尽量通过引用访问受保护的来源，避免被重复复制。搜索条目和摘要也可能泄露信息，例如把受限内容写进索引标题，即使正文另有访问控制，标题本身仍然可见。检索、导出、缓存和回放都需要使用同一套约束。删除或撤销访问后，还应检查派生索引何时失效，并有办法防止旧缓存再次把已经撤销的材料交给代理。

怎样验证记忆是否值得保留

评估可以从同一组任务出发，分别比较无记忆、原始记录检索、人工编写指引和带离线整理的记忆。应尽量固定模型、工具、任务顺序及可用预算，同时记录延迟、检索次数、错误类型和人工返工。若较晚的问题直接复用较早题目的答案，可以测出基本保留能力。若新问题换了版本、改了条件或加入冲突资料，才更能检验模型是否理解规则的范围。把两类情况合在一起算平均值，容易高估系统处理变化的能力。

还应加入需要忘记或拒绝采用旧资料的任务。例如，让系统先看到一个在旧环境有效的操作说明，再明确标注新环境的变更；或者让它看见一条没有来源的流畅笔记，要求回答时给出证据。正确的结果可能是暂缓行动、返回待确认状态或向相应维护者请求核对。这类结果不能一律当作失败。测试应该同时评价找到有用知识的能力，以及知道何时不能依赖一条记忆的能力。

对使用人群不同的系统，最好分别查看首次接入、常规任务和异常恢复的结果。新成员可能受益于入口清晰，熟练维护者可能更在意历史变更和例外。若只有规则熟悉的人参与测试，就会低估入口缺失的影响。还可以观察整理后的记忆如何影响人工决策：是否提供了足够材料，使审阅者不用翻完整会话；是否将不同结论混成一个建议；以及拒绝后能否快速定位需要修正的条目。单纯让模型判定摘要质量，很难覆盖这些真实使用条件。

还可以做一次针对回滚的演练。先让整理作业发布一条经审阅的规则，再模拟后来发现审阅依赖的样本不完整。值班人员应当能够撤下规则，并找出由它派生的索引条目和待执行的动作。正在运行的任务如果已读取旧版本，需要有明确的处理口径，例如继续只读调查，等新规则确认后再执行会产生副作用的步骤。测试时记录撤回多久能传递到缓存和工作进程，并区分已发生的动作与仍可取消的动作。如果只能在管理界面修改原文，却不能证明新会话已经停止读取旧版本，撤回机制就还没有闭环。这个检查也能帮助决定索引的刷新节奏和发布规则所需的验证强度。它要求系统能在并发读取时标识所用版本，出了问题才能判断影响范围。

什么时候简单方案更好

如果可靠文档已经覆盖大部分问题，直接检索往往比维护第二套知识更稳定。再复制一层笔记可能增加同步负担，并让使用者误以为两处一致。对于执行条件可直接从工具获取的任务，保留状态的地方应该是权威任务系统。记忆更适合记录为什么作出某项决定、哪些前提容易遗漏、以及怎么找到正确的资料。这些内容很难从运行状态重新推导，也比较容易判断是否有继续保留的必要。

另一种反例是工作变化太快。一个快速探索的流程在多个版本间频繁改动，离线整理的周期可能追不上实际变化。可以先保存少量有时间标记的观察，在规则变得稳定之后再形成共享指引。也可以为临时笔记设置复核时间，过期后只用于查找旧记录。这样能保留探索过程，又不会在正式任务开始时被旧习惯牵着走。相反，对于有审计要求且变化较慢的流程，维护结构化记录和独立复核可能更划算。

最后，原文中的不同模型在相同任务上表现不同，也说明记忆功能不能单独采购或验证。较弱模型可能需要明确提示去读取记录和检验猜想，较强模型则可能在过细的写入限制下丢掉有用信息。系统还要考虑工具能否找回记录、错误能否回滚、谁在运行期间作出最后决定。实际选型应看模型、任务、权限与工具组合后的表现。

结论

代理能把经验带到下一次任务，只是记忆系统的起点。更难的是让它能够查证一条结论、识别适用范围，并在事实变化时撤回旧规则。原文的层次划分和离线整理实验提供了设计线索，生产系统还需要把证据、权限、更新与评测接在同一条流程上。可以从一种反复出现的错误开始，保存必要记录，先建立能被人工复核的修订路径，再观察它是否减少下一次的返工。一个可靠的记忆系统，应让好的经验更容易找到，也让错的经验更容易纠正。