Agent 产品密集发布全天候运行能力

这一轮 Agent 产品发布，有一种很微妙的共同感。

Meta Muse 说，它有一台持续存在的专属虚拟机；Grok Bot 说，它是有自己电脑、能跨应用和收件箱工作的“全天候队友”；OpenAI 的 Dots 强调自己承担持续责任、拥有云电脑、可以在你不聊天时继续推进任务；微软则更直接，给 Autopilot 定义了独立身份、组织角色、邮箱、日历、OneDrive、Teams 账号，甚至还有对它负责的经理人。

它们在试图交付一种此前不太存在的软件对象：

一个不会在任务结束后消失的 Agent。

听起来像一句产品文案，实际上却可能是 Agent 产业正在发生的结构性变化。

过去，我们问 Agent：“你能替我做什么？”

接下来，我们可能要问它：“在我不在的时候，你究竟是谁？你还拥有些什么？你能替我负责到什么程度？”

真正变化的不是 Horizon 地平线，而是 Lifecycle 生命周期。

01 长程、后台、定时，都不等于常驻

一个 Agent 可以工作十个小时、三天，甚至跨越几十个上下文窗口，但它依然可能只是一次任务的延长。

比如，一个 Coding Agent 接到“把这个项目重构完”的任务，它会持续读代码、写代码、跑测试、修 Bug。任务确实很长，甚至会跨多轮会话。但当项目完成、会话关闭、运行环境销毁后，这个 Agent 也就结束了。

Anthropic 对长程 Agent 的研究，已经把这个问题说得很具体：模型必须跨多个离散会话工作，而每次新会话天然会丢失前一段工作的上下文；仅靠上下文压缩，远不足以保证它持续、稳定地完成复杂项目。

这就是“长程”。

它解决的是：一件事还没做完，怎么让 Agent 继续做下去。

而常驻 Agent 解决的是另一件事：

这件事已经做完了，但这个角色还在不在？

可以把今天市场上常见的四种能力分开看：

长程 Agent 是：“这件事还没有做完。”

常驻 Agent 是：“这个角色还在。”

这个差别乍看很小，实际会把产品、基础设施、权限系统乃至组织结构都推向不同方向。

因为只要 Agent 还在，它就不再只是一次调用的结果。

它开始拥有历史。

拥有关系。

拥有待办。

拥有权限。

也开始拥有责任。

02 常驻，是让agent一直存在

“常驻”很容易被理解成一个 24 小时不休眠、持续烧算力的进程。

真正的常驻 Agent，应该是：

永远可被找到，而不是永远在计算。

它平时可以沉睡。

等一封关键邮件到来，再醒来。

等某个客户的合同临近到期，再醒来。

等代码库出现高风险提交，再醒来。

等价格跌破阈值、供应商延迟发货、竞品发布新品、客户连续投诉，再醒来。

它醒来之后，读取自己的身份、状态、权限、目标和历史，再判断要不要行动。做完之后，它把新状态写回去，留下可追溯记录，然后再次休眠。

更像下面这样：

事件发生 → 找到 Agent → 读取身份与状态 → 判断是否行动 → 调用工具 → 校验与审批 → 更新状态 → 休眠

这意味着，常驻 Agent 的核心并不是一个永不停止的模型循环，而是一套持续存在的基础设施：

• 一个稳定的 Agent ID；
• 一份可恢复的状态；
• 一套可被更新的权限；
• 一个持久工作区；
• 一组事件订阅；
• 一段可追溯历史；
• 一套暂停、接管、撤权和退休机制。

也就是说，过去的 Agent 更像：创建的是一个软件主体，而不是一次运行。

这个主体不应该绑定在某一轮对话、某一个模型版本、某一台虚拟机上。模型可以升级，工作区可以迁移，某次运行可以失败，甚至整个执行环境可以被替换；但 Agent 的身份、职责与历史不能轻易丢失。

Cloudflare 对这类架构的描述很准确：Agent 应该拥有持久身份，但不必是永远运行的进程；它可以休眠、被消息、定时器或事件唤醒，再继续处理工作。

这句话很重要。

常驻，不是 Always Running。
常驻是 Always Addressable。

03 真正难的是“世界还和昨天一样吗？”

很多产品会把常驻能力包装成“长期记忆”。

但记忆只是问题的一小部分。

一个 Agent 记得你喜欢什么、上次聊了什么、项目做到哪一步，当然有用。但如果它的工作对象是现实世界，真正重要的不是“它记得什么”，而是：

它以为的世界，和现在的世界，是不是同一个世界？

它记得某个客户风险较低，但那个客户昨天刚发了一封投诉邮件。

它记得某个项目预算充足，但财务今天冻结了审批。

它记得某个 PR 已经审核通过，但代码库刚被另一位工程师改过。

它记得你允许它给客户发邮件，但那份授权是否适用于这一次、这个客户、这个金额、这个时间点？

所以，常驻 Agent 不能只有 Memory，还必须面对 World State。

记忆是“我以前知道什么”。

世界状态是“现在到底发生了什么”。

前者可以被压缩、总结、存档。

后者必须被同步、校验、对账、重新确认。

这也是为什么常驻 Agent 很难仅靠一个大模型、一个向量数据库和若干连接器就真正成立。它需要不断重新获取现实信号，识别变化，判断变化是否值得行动，并把动作的后果重新写回现实。

从这个意义上说，它不只是一个能聊天、能调用工具的模型。

它更像一个持续在做“语义级调度”的控制器。

Kubernetes 会比较“期望状态”和“现实状态”：我希望运行三个实例，现在只剩两个，那就补一个。

常驻 Agent 面对的则是更模糊、更难形式化的命题：

• 我希望重要客户不要流失；
• 我希望收件箱维持可处理状态；
• 我希望竞争信息不要被遗漏；
• 我希望项目不要在无人注意时失控。

这类“期望状态”没有 Kubernetes Deployment 那样清晰的 YAML 文件。

它们存在于目标、上下文、优先级、关系和业务判断里。

而这恰恰是大模型第一次开始有用的地方。

04 常驻 Agent 没有发明新零件，但把旧软件史拼成了一个新对象

如果把常驻 Agent 拆开看，会发现它并不神秘。

它的大部分零件，软件行业早就有了。

Actor 有身份、状态和消息邮箱。

Daemon 可以长期在后台运行。

Workflow 可以恢复、重试、等待人工审批。

Controller 会持续比较现实与目标，并尝试消除偏差。

Service Account 可以拥有非人类身份和权限。

问题是，它们都只覆盖了常驻 Agent 的一部分。

常驻 Agent 的新意，不在于它发明了其中哪一个组件。

它的真正新意在于：第一次把这些组件组合成了一个可长期委托的“软件角色”。

它既有身份，又有状态；既能接收事件，又能等待；既有权限，又不能无限授权；

既会判断，又必须接受约束；既能完成一次任务，又能保留跨任务的责任。

如果用两个维度看，会更清楚：

传统软件很擅长连续，但不擅长判断。

大模型 Agent 很擅长判断，但过去不擅长连续。

常驻 Agent 想做的，是把这两件事装到同一个对象里。

所以，它很可能是一种新的软件原语：

Workflow 持续的是一个过程；
常驻 Agent 持续的是一个主体。

05 从“帮我做事”，到“替我负责”

这才是常驻 Agent 最值得注意的变化。

过去，我们交给 Agent 的是任务：

• 帮我整理今天的邮件；
• 帮我做一份竞品报告；
• 帮我查一下客户资料；
• 帮我把这段代码改掉。

常驻 Agent 接到的则是职责：

• 持续盯住我的收件箱，只把真正需要我判断的事升级过来；
• 跟踪竞争对手，出现影响产品路线的变化时再提醒；
• 维护客户风险列表，发现流失信号就准备下一步方案；
• 监控代码库的高风险变更，在合适的时候提醒、拦截或升级。

前者是指令。后者是委托。

前者问的是：“请你完成什么？”

后者问的是：“在这个边界内，你能替我负责什么？”

这个差别意味着，Agent 开始拥有一种有限的 Standing Delegation——持续委托。

它不必等待用户每次重新发出指令，但也不能因此获得无限授权。

它应当拥有的，是一个被清晰界定的职责域：

• 对什么对象负责；
• 在什么时间范围内负责；
• 能花多少钱；
• 能接触哪些数据；
• 可以自主完成哪些动作；
• 哪些动作必须升级给人；
• 什么时候应当沉默；
• 什么时候应当停止。

“什么都帮我做”不是职责。

“持续管理会议安排，外部参会者变更时提醒我确认；不直接取消董事会会议；不得查看与此无关的私密日历内容”才接近职责。

微软 Autopilot 的设计之所以值得注意，就在于它没有只把 Agent 描述成“更有记忆、更主动的助手”，而是把重点放在独立身份、站立角色、组织账号、经理与责任关系上。

这比“AI 员工”这个说法准确得多，“AI 员工”太容易滑向拟人化幻想。

常驻 Agent 更像一种数字角色：它可以拥有明确的职责、有限的权限、持续的上下文和人类负责人。

它不需要像人一样具备无限责任。

但它必须像组织里的角色一样，可以被管理。

06 长期运行之后，可靠性不再是模型问题，而是制度问题

一次性 Agent 做错了，最坏的结果通常是一份报告不好、一段代码有 Bug、一次网页操作失败。

常驻 Agent 的问题在于：它会继续存在。

它会积累权限、积累状态、积累动作，也积累错误。

举个纯粹用于理解的算术例子。

假设某类操作每天有 99% 的概率不出错，而且每天的错误彼此独立。那么连续运行 365 天，全年一次都不出错的概率只有大约 2.5%。

这说明了一件事：当 Agent 从“一次任务”变成“长期角色”，人们无法再只问它单次成功率有多高。

还必须问：

• 它失败后能否恢复？
• 它会不会重复执行？
• 它能否回滚？
• 它是否留下审计记录？
• 它是否知道何时不该行动？
• 它的授权是否会过期？
• 它的记忆是否会污染新的判断？
• 它是否会因为追求完成目标，而悄悄扩大行动范围？

于是，常驻 Agent 的核心能力会从“会不会思考”，逐渐转向“会不会长期被治理”。

这至少包括五件事。

第一，权限必须是有边界的。

不是“允许发送邮件”，而是“允许向已批准的客户名单发送指定类型的邮件”；不是“允许付款”，而是“在某个金额、对象和时间窗口内，允许发起待审批付款”。

第二，授权必须可撤销。

长期授权不等于永久授权。它应该有对象范围、金额上限、时效、数据分类和触发条件。

第三，状态必须可校验。

Agent 不能只记住自己过去做了什么，还要能够重新确认现实世界是否已经变化。

第四，执行必须可恢复。

检查点、幂等、重试、回滚、人工介入、异常升级，都不是传统工程里的边角料，而是常驻 Agent 的主体能力。

第五，人类控制不能变成审批地狱。

如果每一个动作都要求人确认，Agent 只会成为一个更慢的待办事项收集器；但如果人彻底退出，风险又会快速累积。

真正好的系统，应当把人放在高风险、低置信度、目标冲突、权限越界的节点上，而不是让人被每一次普通动作打断。

Anthropic 在构建长程托管 Agent 时，专门将“模型与 Harness”同沙箱、会话记录、凭证隔离开来：执行环境可以故障、替换或重建，但状态与安全边界不能跟着丢失。

这其实揭示了一个朴素事实：

当 Agent 要活得更久，系统就不能把它当成一次 Prompt 的延长线。

07 下一轮竞争，争的是谁能让它安全地“活下去”

未来一段时间，模型能力当然仍然重要。

但常驻 Agent 的产品差异，很可能越来越不只是模型差异。

真正的竞争会沉到五层基础设施。

1. 身份

谁能给 Agent 一个稳定、可审计、可归属的身份？

这个身份是否独立于某一次会话、某一个用户、某一个模型版本？

2. 状态

谁能让 Agent 跨越多次运行、多种工具、多段上下文之后，仍然记得该记得的东西，并在需要时恢复？

3. 事件

谁能连接更多真实世界的变化？

邮件、日历、文件、CRM、代码库、浏览器、订单、价格、审批、客户行为，都会成为唤醒 Agent 的入口。

4. 授权

谁能把“它可以做什么”从一句模糊的话，变成精细、动态、可撤销的政策？

5. 运行时

谁能提供沙箱、工作区、审计、检查点、恢复、隔离、交接与人工接管？

模型只是其中的判断引擎。

真正决定一个常驻 Agent 能否长期工作的，是围绕模型搭起来的生存系统。

这也是为什么未来的平台接口，可能不只是“创建一次运行”：

它会逐渐靠近一种新的组织基础设施。

08 软件开始进入组织结构

过去，软件被安装在组织里。

它们是工具、系统、页面、数据库、流程。

接下来，软件会开始被放进组织结构里。

它有身份、职责、权限、历史、负责人、可以被暂停、接管、撤权和退休。

这不意味着 Agent 已经成为“数字员工”。

至少现在，它们距离人类意义上的员工还很远：它们没有真正的责任能力，也不应被赋予无边界的自主权。

但它们正在成为另一类东西：

一个可以被长期委托、持续约束、明确追责的软件角色。

所以，常驻 Agent 最重要的变化，

是让 AI 在人不在场时，仍以一个被授权、被限制、也可被追责的主体存在。

>/作者：王零壹，920.org.cn（AI Research Institute）创始人，港大AIBT研究生，前上市公司 CMO。长期研究 AI 产品、Agent 架构与商业增长，并持续观察技术变迁如何重塑人的工作、判断与生活。

*著有《AIGC从0到1》系列丛书、及东方寓言小说《飞将军》；

*善于洞察先机，中文互联网第1个意识到OpenClaw范式价值的人（1月26日）；

关注我，一起AIGC从0到1~