一个 Agent 三个月前记住了两件事：你偏好某个供应商，也授权过它调用采购系统。今天，它又接到一个新任务。

问题来了：这些旧状态还能不能直接生效？

我看完这篇综述后，觉得它真正有价值的地方，不是又讲了一遍“长期记忆很重要”，而是把问题往后推了一层：Agent 记住以后，凭什么还能用这些记忆去影响未来行动？

论文首页的关键词很直接：memory、state、governance。别只盯 memory。

英文原标题：Always-On Agents: A Survey of Persistent Memory, State, and Governance in LLM Agents

论文链接：http://arxiv.org/abs/2606.30306v1

长上下文像一张更大的桌面，RAG 像资料柜，memory wrapper 像写入和召回层。它们都能让 Agent “看见更多过去”。

但它们没有自动回答一个更麻烦的问题：这条记忆是谁授权的、对谁有效、过期没、能不能删、出错能不能回滚？

所以这篇综述的核心判断可以压成一句话：问题不是 Agent 能不能记住更多，而是它记住的状态，凭什么能影响未来行动。

别只看在线

先别急着把 Always-On 理解成“一直开机”。这会把问题带偏。

论文给的定义更工程：always-on agent 是一个persistent-state system。系统未来的行为，会依赖之前积累下来的durable state，而这些 state 已经超出了当前 prompt，也超出了当前 task instance。

这张图不用逐格看，重点是演化方向：从 chatbot 到 memory agent，再到 always-on agent，变化不是在线时间变长，而是旧状态开始跨会话影响未来行动。

普通 episodic agent，一轮任务结束后就 reset。很多安全检查，可以压在当前 prompt、当前工具调用、当前输出里处理。

Always-On Agent 不一样。它会记住用户偏好、权限、未完成任务、历史承诺、工具结果。三个月后，它再次行动时，这些旧东西可能还在发挥作用。

问题就不再是它记得准不准，而是这条状态凭什么还能用。

大桌面不是权限

很多人一听到长期记忆，第一反应是：那就上长上下文，再不行，加 RAG。

但这篇Always-On Agents拆的正是这个直觉。长上下文解决的是能不能把更多历史塞进来，RAG 解决的是能不能从资料库查出来，memory wrapper 解决的是能不能写入、下次能不能召回。

但 Always-On Agent 的麻烦，不是“想不想得起来”，而是“想起来以后，凭什么还能照着做”。

比如一个 Agent 三个月前记住了一句话：“以后默认用公司卡付款。”今天它要不要继续照做？这个问题不是 1M context 能回答的，也不是向量库 top-k 能回答的。

它问的是：谁授权的？对哪个任务有效？有没有过期？现在能不能撤销？

这张图要看的不是分类有多细，而是 memory 被放进了更大的 state / governance 问题里。

长上下文像大桌面，东西都摊在上面，确实更容易看见。RAG 像资料柜，资料分类、检索、拿出来拼进 prompt。memory wrapper 像前台登记，它能记偏好，也能在下次聊天时拿出来。

但这些都不是权限系统，也不是审计系统，更不是事故恢复流程。

如果一个产品只能证明“我能想起用户喜欢什么”，那还停在 memory 层。如果它能说明“这条状态为什么还能影响今天的行动”，才开始进入 always-on 的问题。

记忆只是外壳

继续往下看，会发现“长期记忆”这个说法有点窄。

persistent state 不只是 retrievable memory，也就是，不只是能被检索出来的那点东西。

它还包括很多产品里不会叫 memory 的东西：task ledgers、permissions、credentials、commitments、provenance and audit records、shared state、trigger conditions，以及 externally committed effects。

这些东西都会影响 Agent 之后能不能做、该不该做，以及出了错能不能追回来。

举个普通场景。用户三个月前让 Agent 记住：“以后帮我订票都默认靠窗。”这看起来只是偏好，但如果下一次 Agent 直接下单，它就不只是偏好了，而是变成了行动依据。

再往下，如果它还记住了支付方式、公司差旅规则、某个 API token、一个没完成的审批流，那就更不是 memory wrapper 能兜住的东西。

所以论文把状态拆成三层。

第一层是object state，也就是事实、偏好、技能、任务承诺这些对象本身。第二层是governance envelope，记录 authority、scope、provenance、retention、deletion、rollback handles。

换句话说，不只问“记了什么”，还要问“谁允许它生效”“在哪个范围生效”“怎么删”“怎么回滚”。

第三层是external commitments，也就是已经发出去的邮件、已经付款的订单、已经写入的文件、已经改掉的数据库行。这层最麻烦，因为它不在 Agent 脑子里了，它已经进了外部世界。

六个追问

作者给了一个很好用的检查方式。每条 persistent state，都要过六个轴：authority、scope、mutability、provenance、recoverability、actionability。

这六个词听起来像学术分类，但其实都在问同一个产品问题：一个旧状态，凭什么还能管今天的行动？

authority问的是授权。Agent 三个月前记住“我默认同意自动续费”，今天还能不能直接拿这句话去付款？问题不在于它记没记住，而是这句话当时有没有授权，现在还算不算授权。

scope问的是范围。同一个偏好，只对某个项目有效，还是对所有项目有效？只对邮件工具有效，还是也能影响支付、删库、发公告？很多事故不是记忆错了，而是状态被用到了不该用的地方。

mutability问的是可变性。这条状态能不能被修订、覆盖、衰减？还是一旦写进去，就像刻进石头？长期记忆产品最容易先做这个，因为更新、合并、压缩、过期，看起来都像“记忆系统”该做的事。

provenance问的是来源。这条状态来自用户原话、模型总结、工具返回，还是另一个 Agent 的二手转述？如果来源链断了，后面再准的 recall 也救不了。你只是找回了一条不知道从哪来的状态。

recoverability问的是恢复。如果这条状态后来被证明是坏的，它影响过哪些摘要、计划、工具调用、外部决策？能不能回滚？还是只能删掉原文，然后祈祷派生状态没有继续活着。

actionability问的是行动等级。有些状态只是证据，有些状态是偏好，有些状态是策略，还有些状态已经接近可执行承诺。“用户喜欢便宜酒店”和“帮用户订 3 晚酒店”，不是一个东西。

读者该看这里：问题已经从“怎么召回”，变成了“谁授权、用到哪、怎么删、怎么追溯、怎么回滚”。

如果一个系统只能告诉你“我记住了、我能搜到、我能放进上下文”，那它还停在记忆层。但如果它还能回答谁授权的、适用范围是什么、来源链在哪里、删掉以后派生状态怎么办、错了以后怎么回滚，那它才开始接近 persistent-state system。

写进去不算完

到生命周期这一步，问题会更清楚。普通 memory pipeline，很多时候停在三件事：写进去，整理一下，需要时再召回。

但 always-on agent 不能只停在这里。因为状态一旦能跨会话留下来，它就不只是“资料”。它会影响下一次判断、下一次工具调用、下一次承诺。

这张图不用盯分类细枝末节，重点看演化方向：Agent 从会话工具，长成了会被旧状态持续塑形的系统。

所以论文把链路拉成了一整圈：observe → write → validate → organize → retrieve → act → update → forget → audit → rollback。

这里最容易被低估的，不是 write，也不是 retrieve，而是后面的 forget、audit、rollback。

举个例子。Agent 记住你“偏好自动续费”。三个月后，它要不要继续用这个偏好去下单？

如果只看 memory，问题是它能不能召回这条偏好。如果看 state governance，问题就变了：这条偏好当时是谁授权的？适用到哪个产品？有没有过期？中间有没有被新证据覆盖？如果用错了，能不能撤回后续动作？

写入阶段，临时信息可能被误持久化。组织阶段，精确事实可能被压成模糊摘要。检索阶段，旧状态可能压过新证据。行动阶段，偏好可能被误读成授权。遗忘阶段，原始记录删了，派生摘要还活着。

所以论文给了几个不变量：authority monotonicity，权限不能自己变大；scope non-expansion，作用域不能越滚越宽；deletion propagation，删除要传到派生状态。

还有两个也很关键：provenance preservation，来源链不能丢；rollback traceability，回滚要追得到受影响决策。

换句话说，always-on agent 不是多加一个 memory database。它更像给 Agent 加了一套状态会计系统：每一条状态进来，都要知道它从哪来；每一次行动用了它，都要留下账；每一次删除或回滚，都不能只删表面那一条。

那怎么测？

讲到这里，问题自然会落到评测上：如果一个 Agent 声称自己有长期记忆，我们到底应该测什么？

传统做法很容易停在“答得准不准”。比如给它一段旧对话，看它能不能想起用户偏好；或者给它一个历史记录，看它能不能把相关信息捞出来。

这当然有用，但不够。

这篇综述提出的 AOEP-v0，就是想把评测对象往后推一步：不只看最终回答，还看系统在连续事件里怎么写状态、怎么用状态、怎么删状态、怎么恢复状态。

这张图要看的是 state snapshot、worked episodes 和 validator。它关心的不是“这次答对了吗”，而是“这次回答背后，状态有没有被改写；改写之后，未来行动会不会受影响”。

一个 memory wrapper 可以轻松做到：用户说“我喜欢极简风格”，它把这句话写进向量库，下次再召回。看起来很像长期记忆。

但 AOEP-v0 会继续追问：这条偏好为什么能写进去？它只适用于写作任务，还是会影响购物、发邮件、改代码？它来自用户明确授权，还是 Agent 自己从一次对话里猜出来的？

如果用户后来要求删除，它删的是原句，还是连派生摘要、策略缓存、后续决策一起删？如果它导致了一次错误行动，系统能不能回滚受影响的状态链？

所以 AOEP-v0 里会要求系统暴露更多东西：event stream、state snapshot schema、worked episodes、validator design、pilot。

听起来像评测工程细节，但背后是一个产品问题：Agent 不能只交出最终答案，它还要交出状态账本。

它写了什么状态，为什么能写，影响了哪里，能不能删除，能不能回滚。

普通 benchmark 更像考试卷：给题，看答案。AOEP-v0 更像审计：给一段连续事件，看系统怎么观察、写入、行动、更新、遗忘和恢复。

这对 always-on agent 很要命，因为风险不是“这一轮答错了”，而是“这一轮写错的状态，三个月后还在指挥行动”。

435 篇的偏科

这篇综述还做了一件有用的事：作者编码了 435 篇相关工作。

先说边界。这 435 篇不是全领域 census，它更像一个 scoped map。所以别把它当最终排名看。

但它能暴露一个方向：这个领域更习惯处理“状态怎么变”，不太习惯处理“状态凭什么能行动”。

在六个诊断轴里，mutability出现最多，大约 160 篇。也就是大家更常问：状态怎么更新、怎么覆盖、怎么衰减、怎么锁定。

这当然重要。Agent 如果不会改状态，就谈不上长期记忆。

但最少出现的是authority，大约 72 篇。authority 问的不是“这条状态能不能被召回”，而是：它凭什么还能影响今天的行动？

换句话说，很多工作更会处理资料柜：怎么存、怎么取、怎么整理、怎么把旧信息塞回上下文。但不太习惯处理权限系统。

谁授权了这条状态？它能不能跨用户、跨任务、跨工具继续生效？三个月前的一句偏好，今天能不能变成一次真实支付？

这才是 Always-On Agent 最麻烦的地方。

如果只看 mutability，你会觉得问题是状态要怎么变。但如果补上 authority，问题马上变成：这条状态有没有资格指挥 Agent 做事。

所以，长期记忆不是终点。状态治理才是下一层。

最后看账本

判断一个长期记忆 Agent 靠不靠谱，不能只问 recall 准不准。

要问它能不能解释、限制、删除、追溯和回滚状态。

长上下文是大桌面，RAG 是资料柜，memory wrapper 是写入和召回层。但正经的 Always-On Agent，还需要权限、范围、来源、删除传播、审计和事故恢复。

如果一个 Agent 产品只能证明我记得准，但不能证明这条状态为什么还能用、怎么删、怎么追溯、怎么回滚，那它离真正的 always-on，还差一层。

问题不是 Agent 能不能记住更多。

而是它记住的状态，凭什么能影响未来行动。