一个没有人能回答的问题
问一个运行长期 AI agent 的团队一个简单的问题：它记住了你公司的哪些事情？这些记忆是什么时候改变的？
大多数团队回答不上来。在当前的技术栈中，agent 记忆是”写入为主、读取不透明”的。事实从各个会话中不断累积，由 agent 自己进行摘要，然后悄悄影响 agent 之后做出的每一个决定。当 agent 在第三个月开始表现异常时，没有任何记录能告诉你是哪一条被记住的”事实”变了、什么时候变的、又是什么改变了它。
对个人助理来说，这只是个小毛病。但对一个负责起草客户消息、安排工作或向审批队列供稿的 agent 而言，这是一个治理缺口：agent 的记忆是每一个受治理输出背后未经审计的输入。
记忆整理已成原生能力，治理却还没有
Agent 平台在这方面进展迅速。计划式记忆整理——一个后台进程，读取记忆存储和近期会话历史，然后重写记忆以合并重复项、删除过期条目、归纳模式——如今已是前沿技术栈的原生能力。它确实有用：未经整理的记忆会退化，一个要在六个月互相矛盾的笔记上推理的 agent，表现必然不如拥有干净存储的 agent。
但原生的整理功能是一个黑盒。整理器读取所有内容，重写它认定过期的部分，却不留下任何可审阅的编辑记录。从治理角度看，这是一个无人值守、却拥有写入权限的进程，而它写入的正是你所有其他控制机制的输入层。
受治理的记忆整理是什么样子
我们本周为 JieGou 托管 agent 上线了计划式记忆整理——构建在原生能力之上，并包裹了原生功能所欠缺的治理层：
- 受保护的命名空间。 记忆存储的部分区域对整理器完全禁止访问。运营状态、跨 agent 共享上下文、以及会话线程级别的记录，都不能被整理过程重写——无论模型多么确信它们已经”过期”。
- 每个周期的硬性上限。 每次整理都有边界：总操作次数有固定上限，删除次数的上限更低。不存在任何一种场景，会让一次失控的周期在一夜之间改写 agent 的整个世界观。大规模变更需要许多个周期，也就意味着许多次审阅的机会。
- 试运行预览。 整理周期可以在预览模式下执行，产出完整的变更提案，但不实际应用任何一项。新部署会一直以试运行模式运行，直到运维人员看过几个周期的判断质量为止。
- 可审计的差异记录。 每一项实际应用的变更都会被记录为可审阅的差异：合并了什么、替换了什么、删除了什么，以及哪些会话促成了这次变更。本文开头的那个问题——它记住了什么？什么时候改变的？——在任何时间点都有具体的答案。
同一个版本还加入了双通道结果评分：在 agent 会话内产出的工作，由原生评分器在会话内评分；在会话外产出的草稿，则走我们的评审通道。每一份 agent 的工作成果都会得到结果评分；记忆整理与结果证据落在同一套审计体系之中。
为什么这件事的意义超越功能本身
这里有一个值得点明的模式。随着 agent 平台日趋成熟，过去属于集成方工作范围的能力——记忆、评分、调度——正在变成原生基础组件。这是好事。模型层及其基础组件正在成为大宗商品化的基础设施。
不会大宗商品化的，是治理外壳：范围限定、上限、审批关卡、可回放的记录。原生记忆整理只会让一个不受治理的 agent 更擅长不受治理。对任何让 agent 接触真实客户数据的团队来说，真正的运营问题不是该不该使用原生基础组件——该用，就用——而是每一个会写入 agent 状态的基础组件，是否都留下了审计员、保险核保人、或未来的你自己能够审阅的证据。
只通过有上限、有差异记录、可回放的操作来改变的记忆，就是我们的答案。如果你当前的 agent 技术栈无法给你一份”上个月记住的内容 vs. 今天记住的内容”的差异报告，那么最好在这些记忆变得举足轻重之前，先把这件事解决掉。