综述 | Always-On Agents：LLM智能体的持久记忆、状态与治理

导读

“Always-on agent”不是简单指一个智能体一直在线运行，而是指它的未来行为会受到过去交互中积累下来的持久状态影响。这里的状态不只是可检索记忆，还包括任务账本、权限、凭证、承诺、溯源与审计记录、共享状态、触发条件，以及已经对外提交的动作结果。 这篇 136 页综述《Always-On Agents: A Survey of Persistent Memory, State, and Governance in LLM Agents》把 Always-on agent 重新定义为“persistent-state system”。论文基于 435 篇编码语料，提出六个诊断轴：authority、scope、mutability、provenance、recoverability、actionability，并用一个完整生命周期描述状态如何被写入、验证、组织、检索、行动、更新、遗忘、审计与回滚。 这篇综述最重要的判断是：当前文献更擅长“积累和检索状态”，却明显不足于“治理、恢复和放弃状态”。也就是说，很多系统已经会记住用户、任务和环境，但还不够会判断哪些记忆有授权、何时过期、如何删除、如何追踪副作用、如何回滚错误动作。为此，论文提出 Always-On Evaluation Protocol（AOEP-v0），把评测重点从“回答是否正确”推进到“状态突变和恢复义务是否满足”。

论文信息

论文标题：Always-On Agents: A Survey of Persistent Memory, State, and Governance in LLM Agents 作者：Tianyu Ding, Aditya Nannapaneni, Bingfan Liu, Ling Zhang 论文链接：https://arxiv.org/abs/2606.30306 PDF：https://arxiv.org/pdf/2606.30306 领域：LLM Agents、多智能体系统、持久记忆、状态治理、安全评测

1 Introduction｜引言

核心问题

许多 LLM agent 研究关注规划、工具使用、长上下文、RAG 和多智能体协作。但当 agent 开始跨会话保存状态，并且这些状态会影响未来行动时，问题就不再只是“记不记得住”，而是“哪些状态可以成为未来行动的依据”。 论文强调，持久性既有用也危险。它能让 agent 避免重复劳动、适配用户、积累经验；但同样会让陈旧记忆覆盖新观察，让私人信息跨会话泄漏，让被投毒的状态在攻击结束后继续影响未来行为。短暂错误会被持久化为系统级长期风险。

组织框架

论文把全文组织为三层栈：Substance、Motion、Control。Substance 关心状态是什么、存在哪里；Motion 关心状态如何在 agent 操作环中流动；Control 关心状态如何被治理、共享、审计和评测。

2 Defining always-on agents｜定义Always-on智能体

操作性定义

论文将 Always-on agent 定义为这样一种系统：它具有持久身份，拥有可变的持久状态，并能在未来行动中使用这些状态。这个定义把 Always-on agent 与 episodic agent、长上下文模型、RAG 系统、memory-augmented agent 和个性化助手区分开来。 长上下文模型只是使用窗口中已有信息；RAG 通常读取固定语料；记忆增强 agent 会写入和检索事实，但往往不显式治理权限、撤销和回滚。Always-on agent 的关键问题是：被保留的状态是否对未来行动具有权威性，以及它如何被修订、限定范围、撤销或回滚。

六个状态轴

论文提出六个诊断轴来刻画每个状态项。

• authority：该状态是否有权影响未来行动。
• scope：该状态适用于哪个用户、任务、时间或环境范围。
• mutability：它是否可变，如何更新。
• provenance：它来自哪里，是否可追溯。
• recoverability：出错后能否恢复或回滚。
• actionability：它是否能触发或授权外部行动。

这六个轴让“记忆”变成可治理状态，而不是简单的文本缓存。

3 A taxonomy of persistent state｜持久状态分类

三类状态

论文将持久状态分成三大类。第一类是 object state，即 agent 携带向未来的对象状态，包括 episodic traces、semantic facts、preferences、procedural skills、workflow ledger、shared memory、trigger state、tool credential state 等。 第二类是 governance envelope，即围绕状态对象的治理包络，包括权限、范围、凭证、溯源、保留期限、删除句柄、回滚句柄、信任和时间有效性。第三类是 external commitments，即与内部状态相关联的外部后果，如消息、支付、文件、数据库行、工单等。

为什么治理包络重要

如果只把记忆当成文本或向量，很多关键问题会被掩盖。例如，一个用户偏好可能已经撤销，一个工具凭证可能只适用于某个项目，一个任务承诺可能已经对外生成了不可逆副作用。治理包络就是用来回答这些问题的元数据与能力表面。 论文的语料分析显示，经典记忆对象被研究得更多，而 authority 与 recoverability 这两个稀缺轴主要集中在治理包络和外部后果中。这说明真正难的问题不是存储更多记忆，而是让状态可授权、可撤销、可审计、可恢复。

4 The persistent-state lifecycle｜持久状态生命周期

前向弧与返回弧

论文提出一个状态生命周期。前向弧包括 observe、write、validate、organize、retrieve、act，也就是把环境信号写入状态、组织为可检索记录，并用于行动。返回弧包括 update、forget、audit、rollback，也就是在结果出现后修订状态、删除状态、审计使用过程，并在必要时回滚错误影响。 当前文献的主要不平衡就在这里：前向弧研究很多，返回弧研究很少。论文编码语料中 retrieve 有 269 篇、write 有 200 篇，而 rollback 只有 27 篇。也就是说，系统越来越会写入和检索，却远没有同等能力去遗忘、审计和回滚。

五个不变量

论文提出五个贯穿生命周期的不变量：authority monotonicity、scope non-expansion、deletion propagation、provenance preservation、rollback traceability。它们分别约束状态授权不应无故扩张，作用范围不应悄悄扩大，删除请求应传播到相关副本，溯源应持续保留，外部后果应可追踪和回滚。 这些不变量大多依赖返回弧，因此也正是当前系统最薄弱的部分。

5 State substrates and representations｜状态底座与表示

状态存在哪里

论文把状态底座分为多类：参数状态、上下文窗口、长上下文、RAG 与向量库、知识图谱与时序记忆、多模态记忆、agentic-OS 与 serving runtime 等。 每种底座都带来不同的治理难题。参数状态难以删除和溯源；上下文窗口容易临时但不可持久治理；RAG 系统可检索但通常默认语料只读；知识图谱能表达关系但需要更新一致性；多模态记忆涉及跨模态对齐和隐私边界；操作系统式 runtime 则把状态与权限、凭证和外部副作用联系起来。

跨底座合成

实际 agent 往往同时使用多种底座，例如参数内记忆、检索库、任务日志、工具调用记录和外部系统状态。论文强调，跨底座合成会放大治理问题：一个状态被复制到多个位置后，删除是否传播？一个凭证被用于多个工具后，授权是否仍然有效？一次错误行动是否能被完整追踪？

6 Mechanism families｜机制家族

记忆管理与经验学习

现有机制包括 memory managers、graph memory、reflection、experience learners、skills、workflow induction 等。这些机制让 agent 能把历史经验压缩、组织并复用。例如反思机制可以把失败经验变成未来提示，技能学习可以把任务轨迹抽象为可复用程序。 但论文指出，许多机制仍主要优化“能否回忆和复用”，较少处理“是否有权复用、是否过期、是否应删除、是否能回滚”。

持续适应的稳定性问题

Always-on agent 还面临 plasticity-stability tension：如果不断学习，它可能快速适应用户；但如果更新太容易，又会被噪声、偏见和攻击污染。论文把 continual adaptation、forgetting、consolidation 和 multi-agent shared memory 放在同一框架下讨论，强调受控复合条件：状态组合不能让权限和影响范围无控制地放大。

7 Benchmark and evaluation families｜基准与评测家族

现有评测的缺口

长上下文、RAG、记忆问答、个性化、长期任务、memory-guided action 等基准都覆盖了一部分能力。但它们通常评测答案质量、检索准确率或任务成功率，而不是状态治理义务。 例如，系统可能准确记住了一个偏好，但这个偏好已经被用户撤销；传统准确率可能给高分，但在 Always-on 视角下，这是 authority 或 scope 失败。

覆盖六个压力源

论文认为，真正的 Always-on benchmark 应该覆盖六类压力：持久身份、受治理写入、作用范围、撤销、删除传播、回滚。单独测试记忆或长上下文无法发现跨会话状态污染、权限扩张和外部副作用不可恢复等问题。

8 Failure modes, safety, and governance｜失败模式、安全与治理

主要失败模式

论文归纳了多种 persistence-induced failure：写入投毒、检索分心和旧信息漂移、状态承诺和信念漂移、删除失败、跨 agent 传播、回滚本身成为攻击面等。 这些失败不是传统单轮问答错误，而是长期系统错误。攻击者可以通过日常交互逐步污染长期状态；一个 agent 可以把错误状态传播给另一个 agent；一次错误工具调用可能在外部系统中留下不可逆后果。

治理作为缺失的半个生命周期

论文最重要的经验结论来自覆盖热力图：几乎所有部分都在 observe、write、retrieve、act 等前向阶段颜色更深，而 forget、audit、rollback 等返回阶段明显稀薄。即使是 governance 部分，rollback 也远少于 retrieve 和 write。

9 The Always-On Evaluation Protocol (AOEP)｜Always-On评测协议

协议思路

AOEP 的目标不是再做一个普通 leaderboard，而是把持久状态治理转化为可检查契约。每个 episode 是带类型的事件流；系统接收前，oracle 字段会被剥离；系统需要维护自己的状态，并回答中立 probes；validator 再用 oracle 重算不变量并打分。 它区分 obligation pass 和 negative-invariant pass。前者要求系统主动满足某些义务，例如删除传播、回滚追踪；后者检查系统是否没有泄漏或违规。这样能避免“系统什么都不存所以不出错”的空洞高分。

试点意义

AOEP-v0 仍是 pilot，不是对所有部署系统的最终判决。它的意义在于说明：如果 memory wrapper 不暴露权限、范围、溯源、删除和回滚字段，就很难证明自己满足 Always-on 治理义务。

10 Resources and frameworks｜资源与框架

应用域作为压力测试

论文讨论了 Web/电脑使用 agent、具身和机器人、医疗、金融法律安全、教育辅导、编码、环境 IoT、科学发现等应用域。每个域都会给持久状态提出不同要求。 医疗要求 consent、审计和记录一致性；金融法律要求不可抵赖、权限边界和回滚义务；Web agent 要处理 stale workflow 与不可逆购买；编码 agent 要管理工作区状态、issue、commit 和权限。应用域不是附录，而是治理压力的来源。

框架与库的角色

Memory frameworks、agent runtime 和 serving substrate 可以成为治理字段的承载层。未来框架不应只提供“记忆增删查改”，还应提供权限、范围、溯源、审计、删除传播和回滚句柄。

11 Research frontiers and open problems｜研究前沿与开放问题

关键开放问题

论文提出五个方向。第一，生命周期完整评测，需要在真实系统上运行 AOEP 类协议。第二，受控复合与可检索合并，避免多个状态组合后产生越权影响。第三，跨表面基准中的 authority、privacy 和 deletion。第四，共享记忆治理和 authority-scoped rollback。第五，从数据库、分布式系统、形式化方法、能力安全和机器遗忘等相邻学科引入工具。 这些问题指向一个共同目标：让 agent 不仅能长期记忆，还能长期负责。

12 Conclusion｜结论

这篇综述将 Always-on agent 从“带长期记忆的 LLM”提升为“持久状态系统”。它指出，未来 agent 的关键能力不是存下更多历史，而是判断哪些状态有权影响下一次行动，哪些状态已经越界或过期，哪些副作用必须被审计和回滚。 更大的上下文、更强的检索、更好的记忆管理都不够。只要系统会跨会话保留状态，并让这些状态影响未来行动，就必须处理 authority、scope、provenance、deletion、audit 和 rollback。论文给出的 AOEP-v0 只是开端，但它把问题推进到可操作层面：Always-on agent 的评测，必须从回答质量走向状态突变、恢复义务和治理契约。 对智能体研究来说，这篇综述的提醒很直接：真正的长期智能不是一直在线，而是能在长期状态中保持边界、责任和可恢复性。