本文来自微信公众号： AIGC从0到1 ，作者：王零壹
这一轮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 | 某项任务的再次触发 | 未必 |
| 常驻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的一部分。
| 软件对象 | 它拥有的能力 | 它缺少的能力 |
|---|---|---|
| Actor | 身份、状态、消息 | 开放式判断与持续职责 |
| Daemon | 持续运行 | 身份、语义理解与有限裁量 |
| Workflow | 恢复、重试、流程编排 | 任务结束后仍作为主体存在 |
| Controller | 持续校正状态 | 对模糊业务目标的理解 |
| Service Account | 身份与权限 | 自主判断和行动规划 |
常驻Agent的新意，不在于它发明了其中哪一个组件。
它的真正新意在于：第一次把这些组件组合成了一个可长期委托的“软件角色”。
它既有身份，又有状态；既能接收事件，又能等待；既有权限，又不能无限授权；
既会判断，又必须接受约束；既能完成一次任务，又能保留跨任务的责任。
如果用两个维度看，会更清楚：
| 低裁量权 | 高裁量权 | |
|---|---|---|
| 低连续性 | Function/Job | 一次性Agent |
| 高连续性 | Daemon/Controller | 常驻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在人不在场时，仍以一个被授权、被限制、也可被追责的主体存在。