一个 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 能不能记住更多。而是它记住的状态凭什么能影响未来行动。