给AIAgent加记忆,先决定哪些不该记
设想你每周都让 AI Agent 更新同一份业务看板：达标率超过多少显示绿色，百分比留几位小数，订单和客户怎样关联。上周已经说明的要求，这周换一个会话又得讲一遍。给它加记忆，很自然。
但准备保存时，问题来了：上次临时试过的配色要不要留？模型猜过、后来被推翻的字段含义要不要留？一次超时后的重试过程，能不能变成下一次的操作规则？聊天记录里同时装着已确认的要求、临时探索和错误，它们不能拥有相同的地位。
Apple 研究者的一篇论文专门处理这个问题。我读的是 9 月 15 日修订的《Agent 系统的共享选择性持久记忆》。它把跨会话保留的信息收束到几类可复用配置，给了一个值得试的工程方向；新版同时补充了小样本、实验混杂和失败案例的限制。
如果你正在做一个会反复处理相似任务的 Agent，这篇研究最有用的地方，是帮助你决定：下次启动时，哪些信息应该自动进场，哪些只适合留在日志里。
先分清：保存下来，还是交给下次的模型
我们通常把两件事都叫“记忆”。一件是保存完整会话，方便回放、排错和审计；另一件是挑出少量信息，让下一个任务直接使用。前者追求可追踪，后者要对当前任务负责。
一条“订单金额可能已经扣掉退款”的猜测，可以留在历史记录里。但把它默认放进下周的系统上下文，模型就可能把尚未验证的猜测当成业务规则。把会话压成一段摘要，也不能自动解决这个问题：摘要可能更短，猜测的身份却仍然含糊。
这篇论文保留四类内容：任务要求、数据结构、工具配置和输出约束。对应到每周看板，可以这样理解。
| 保留什么 | 下次直接用在哪里 |
|---|---|
| 已确认的任务要求 | 达标率 ≥95% 显示绿色 |
| 数据结构与关系 | 字段含义、类型和关联键 |
| 工具配置 | 使用哪个连接、怎样调用 |
| 输出约束 | 从运行时读取数据，避免写死数值 |
论文的架构图把四类记忆放在最上方：它们随工作区进入 Agent 的执行流程，再连接工具和数据源。这张图展示的是系统怎样组织配置，能否提升完成率，还要看后面的实验。
原论文 Figure 1：上方是四类记忆，中间是共享工作区和执行引擎，下方连接工具与数据。来源：Pedada、Dhavala、Patil，Shared Selective Persistent Memory for Agentic LLM Systems，v2。这里最容易忽略的是“已确认”。用户试过一个深色主题，然后撤回，长期配置就应继续使用此前确认的主题。对一个结果不满意时的探索过程，也不应获得正式要求的身份。
工具配置还要守住权限边界。记住“这个任务使用受控的只读 SQL 连接”有用；把密钥塞进模型上下文没有必要。连接凭据交给运行环境管理，记忆里只留下可用连接和调用约束。这是落地时需要补上的工程约束。
“不该记”在这里指不该自动进入下一次任务的规则层。日志、版本和失败记录仍可单独归档，需要排错时再查。
12 次都完成了，但实验到底在考什么
论文在四个公开数据集上做了一个两阶段实验，每个数据集、每种条件运行三次。第一阶段生成看板，同时给出格式要求；第二阶段换一份结构兼容的数据，只要求更新看板，不再重述此前的格式要求。
三种条件分别携带空上下文、此前的完整会话，以及选择性记忆工作区。每种条件共 12 次试验，结果是：无记忆完成 0 次，完整历史完成 8 次，选择性记忆完成 12 次。平均输入量分别为 3.8K、7.7K、3.9K token。
原论文 Table 2：完整历史的输入量约为选择性记忆的两倍；选择性记忆的耗时和工具调用数并未更低。来源：Pedada、Dhavala、Patil，Shared Selective Persistent Memory for Agentic LLM Systems，v2。看到 0/12，容易得出一个很重的结论：“没有记忆，Agent 就不会干活。”但作者检查后发现，无记忆条件下的产物通过了结构检查，失败都发生在格式要求上。那项要求第二阶段没有再给它，它自然难以复现。这个实验说明了跨会话传递要求的价值，不能拿来代表 Agent 的一般工作能力。
还有两处限制需要一起读。12/12 和 8/12 是观察到的差距，选择性记忆与完整历史之间的完成率差异未达到统计显著，报告的 p 值为 0.125。选择性条件还恢复了此前的产物，论文没有单独拆开“规则记忆”和“已有产物”各贡献多少。
因此，能带回自己项目里的结论应当窄一点：在这组重复看板任务中，携带可复用要求的工作区，比完整历史用了更少的输入 token。至于你的 Agent 会不会更准确，需要用自己的任务验证。表里选择性条件的耗时中位数是 140 秒，完整历史是 99 秒；平均工具调用数也更高。省输入量与更快完成，是两个指标。
“省了多少”要先看有没有调用模型
Apple 的研究介绍页还列出了企业任务上的 96%、79%、71% 完成率。看整数百分比很醒目，看分母就更容易判断：对应的是 24 个任务中完成 23、19、17 个。新版指出，在这个样本量和多重比较校正下，完成率差异尚未达到统计显著。
企业实验的选择性条件也混合了两条执行路径：24 个任务中，18 个通过数据刷新完成，没有调用模型；另外 6 个才使用记忆重新生成。把这两条路径合在一起计算成本和时间，不能解释成“每次模型推理都便宜了这么多”。
不调用模型的数据刷新，本身是一个实用设计。假如看板代码已经能从运行时读取订单表，换一批数据、重新聚合和渲染，就可以由普通程序完成。只有新增分析、调整结构或修改展示要求时，才需要再次生成代码。
但这个省钱入口有自己的边界。列名没有变，金额单位仍可能从元变成分；同一个 customer_id，也可能换了统计范围。检查列是否存在，只能挡住一部分变更。对实际项目，我会把类型、单位、关联关系和业务口径纳入刷新检查，检查失败就停下来处理，避免拿旧代码继续生成一张看似正常的报表。
判断自己的系统是否需要重新生成，可以先问：这次改的是数据值，还是解释数据的规则？前者可能适合刷新；后者需要重新核验配置和代码。这比一看到数据更新就重跑整个 Agent 更值得先检查。
我做了一个小例子：9 条候选留下 4 条
为了把“筛选”落到具体行为，我写了一个不调用大模型的本地规则脚本，人工构造九条候选记录。它不负责从对话中自动提取知识，只检查已经标好类别和状态的记录，是否有资格进入下一次任务的配置。
九条里有四条当前有效的配置：任务要求、数据关联、只读连接、输出约束。另五条分别是未验证的推理、被新版本替代的阈值、尚未确认的主题、一次重试过程和其他工作区的规则。
脚本先检查工作区和确认状态，再检查类别、数据结构版本，以及同一规则是否已有更新的确认版本。实际运行留下四条。一个细节是，其他工作区虽然有更高的配色版本号，也不能覆盖当前工作区的要求；“更新”必须先在同一个范围内比较。
这个小例子把一个容易说空的要求变成了可检查的结果：临时意见不能自动升级为偏好，旧版本不能压过已确认的新版本，别的工作区不能参与当前规则的覆盖。接上模型后，提取器可能把猜测误标成事实，所以类别和“已确认”状态的来源，还需要另外验证。
我建议先给记忆记录补齐几项信息：它从哪里来，谁确认过，适用于哪个工作区，依赖什么数据版本，何时应重新核验。短期内不必追求复杂的记忆系统。十条能追到来源、能撤回的规则，通常更容易调试；这个取舍是否提升最终表现，再通过任务记录判断。
旧规则失效时，系统要有一个停下来的动作
同一个脚本里，我把当前数据结构版本从 v2 改成 v3。旧的关联规则仍然能在历史里找到，但它依赖 v2，不能直接进入新配置。此时筛选后只剩三类有效规则，脚本报告缺少数据规则，并停止组装。
“停下来”有具体含义：不带着旧关联键继续生成，先检查新表的字段和关系，再写入新的确认记录。线上系统也可以把部分记忆降级为待核验，而不是把整个存储清空。关键是让变化触发动作，不能只有写入流程，没有失效流程。
这与另一篇 9 月发布的研究 Grounding Agent Memory关注的问题相邻。它让任务结束后的记忆整理者使用只读环境工具，在写入前检查候选知识的内容、范围和时效。只回看会话，能够总结模型上次看见了什么；要确认今天还成立，可能需要再查当前环境。
Apple 这篇论文也有一个很具体的失败：选择性记忆条件中，某个任务需要连接两份文件，但数据摘要只分别描述各自的结构，没有写明跨文件的关联关系。字段列表都在，关系缺了一条，任务仍然失败。压缩配置时，删掉了噪声，也可能删掉下一次必须知道的信息。
所以筛选标准要同时回答两个问题：这条信息有没有依据，以及去掉它之后，下一次还能不能正确完成任务。只按字数长短判断，容易把必要的关系说明一并压掉。
如果现在动手，先验证三个结果
第一次检查，选一个有重复需求的真实任务，在新会话中不再重述已确认的规则，看 Agent 能否继续遵守。不要只问“你记不记得”，要检查产物里的单位、阈值、格式和关联结果。
第二次检查，明确改掉一条旧规则，再执行同类任务，看新规则是否生效、旧版本是否退出。撤回临时偏好也值得单独试一次。能记住是入口，能正确改掉才开始接近长期可用。
第三次检查，改变它依赖的环境：删除一个字段，调整单位，或者换一条关联键。观察系统是否重新核验或停止执行。这个检查能区分“有版本号的记录”和“会响应版本变化的流程”。
三次检查都留下当前要求、携带的记忆、最终产物和调用成本，就能定位问题究竟出在提取、筛选、失效处理，还是模型执行上。完成率、输入量和耗时分别记录，避免用其中一个代替其他结果。
给 AI Agent 加记忆，值得从一份小而明确的配置开始：让下一次任务继承已经确认、仍然有效的要求，让旧猜测和临时探索保留在它们该在的地方。你需要的每一条长期规则，都应该能回答一句话：为什么今天还可以继续用它？