Agent时代更该被长期管理的核心对象

本文来自微信公众号： AIGC从0到1 ，作者：王零壹，原文标题：《Agent 时代，最重要的新对象，可能不是 Agent》

当模型、工具和执行者都可以被替换，系统里真正该被长期管理的，到底是什么？

--

上一篇文章讨论过一件事：当AI开始替人行动，未来的界面就不该只剩一个聊天框。目标、权限、状态、例外、证据，都要有地方被看见。参见前文当AI开始替你行动，界面开始不再像界面

但这次往下挖，问题变了。

它不再是“未来UI应该有哪些组件”，而是：当一个Agent长期替人行动时，系统究竟在管理什么？

想象这样一个委托：

未来五年，保证这个网站持续可用。

小问题你自己修；涉及数据风险时停止并上报；超过一万元的支出，需要我批准；每一次重大变更，都留下可追溯的记录。

五年里，模型会升级，工具会更换，某个Agent可能下线，任务会在人类和不同Agent之间交接。

那么，到底是谁还在“负责”？

显然不是某个具体Agent。它只是此刻的执行者。

也不是某个Task。它只是一个阶段性的任务单元。

真正持续存在的，是那份尚未完成的委托：它规定了目标、权限、预算、边界、升级路径、证据要求，以及最后谁该为结果负责。

这可能是理解Agent时代最关键的一次视角转换：

Agent不是未来系统里最稳定的对象。

真正稳定的，是一份可以被执行、交接、验证、暂停、撤销和追责的委托。

暂且把它叫作：Mandate。

一、八个界面原语，不在同一层级

上一轮讨论Agent界面时，我们列出过一组关键要素：目标、责任、权限、状态、触发、例外、验证、恢复。

它们方向是对的，但这次研究给出了一个更精确的修正：

这些东西不在同一个层级。

有些是系统里长期存在的对象；有些是发生在运行过程中的事件；还有一些只是系统应该具备的操作能力。把它们一股脑称为“原语”，会让产品设计很快变成名词堆砌。

更合理的划分是：

这张表虽抽象，但它其实解决了一个很实际的问题。

今天我们总是在问：“Agent该做什么？”“它什么时候完成？”“它犯错怎么办？”

可如果没有先分清对象、关系、事件和操作，这些问题会混在一起。

比如，Verification验证不是一个静态对象。它更像一个动作：

用证据去校验目标与当前状态，判断系统是否真的完成了它受托的事。

Recovery恢复也不是一个页面按钮，更不是“失败时再补一下”的功能。它是一组运行能力：暂停、撤销、回滚、恢复、补偿、分叉。

屏幕上的卡片、对话框、进度条，只是这些关系在某一时刻的投影。

未来Agent产品真正要运行的，是一套行动关系。

二、Prompt、Task、Agent，都不是那份真正的承诺

要理解Mandate授权，先要把几个今天经常混用的词拆开。

Prompt是一次表达。它告诉模型“现在请做什么”。

Task是一次有起点、有过程、有终点的工作单元。

Agent是执行者。它可以是一个模型、一个工作流、一组工具、一个子Agent，也可以在必要时切回人类。

Goal是希望达成的结果。

Mandate则是一份持续的委托关系。

它更像：

在接下来三个月内，持续监测这项业务的异常；在风险可控范围内自行处理；超过授权范围时上报；每周提供一次有证据的结论。

这两种关系的差别很大。

一次Task可以完成。一个Agent可以被替换。一个Prompt可以被遗忘。

但一份委托不会因为执行者换了，就自动消失。

所以未来更合理的关系，应该是：

Mandate（委托）→Task（阶段任务）→Executor（Agent/人/工具/子系统）

而不是今天更常见的：

Agent→Task

这会带来一个很大的变化。

未来企业不会只配置“我们有几个Agent”。真正重要的是：系统里有多少仍在生效的委托，分别由谁发起、谁拥有、谁被授权、谁在执行、谁能接管、谁对结果负责。

一个负责网站可用性的Agent可以被替换十次，但“保证网站可用”这件事不能跟着消失。

一个负责客户续约的Agent可以把部分工作交给子Agent，但它不能把责任也一起丢掉。

这才是委托关系真正的含义。

三、为什么任何Agent委托，都是一份不完备契约

人类给人的工作委托，本来就不可能写得毫无遗漏。

“把这个客户维护好”“保证系统稳定”“把预算控制住”，每一句话背后都有大量没有被写下的判断：什么叫维护好？多大风险必须报告？什么情况可以先斩后奏？发生损失时谁来补救？

Agent也一样。

我们不可能写一份无限长的提示词，把未来所有例外情况提前列完。越真实的工作，越不能靠一张完美任务说明书解决。

这意味着：

Exception不只是“Agent出错了”。

Exception是委托关系本来就必须留下的出口。

一个成熟的Mandate至少需要写清楚：

• 谁是委托人；

• 谁被允许代表他行动；

• 目标到底是什么；

• 可使用哪些工具、数据、账户和预算；

• 何时开始、何时结束；

• 哪些状态应该被持续保存；

• 哪些情况必须停止、升级或交接；

• 用什么证据证明结果；

• 如果发生错误，如何撤销、回滚或补偿。

这也解释了为什么Agent时代的很多产品难题，不是“模型再聪明一点”就能解决。

模型可以非常聪明，仍然会遇到一个无法绕开的问题：

当它碰到一个没有被写进规则、却又必须做决定的情况时，它到底有没有资格替你决定？

四、能力、权限与权力，是三件不同的事

今天讨论Agent时，最常混淆的三个词是：能力、权限、权力。

它们并不一样。

Capability：它会不会做。

比如，一个Agent具备写邮件、修改代码、分析财务报表的能力。

Permission：系统是否给了它技术上的访问范围。

它能不能登录CRM，能不能调用支付接口，能不能读取某个数据库。

Authority：它是否被允许在这一刻、以这种方式、代表某个人或组织行动。

一个Agent可以会发邮件，也能访问CRM，但它未必有权代表公司向客户承诺折扣；它可以调用支付接口，也未必有权把一笔钱转出去。

能力回答“做不做得到”。

权限回答“门开不开”。

权力回答“你该不该走进去”。

这层差别，决定了Agent产品能否从“工具”进入真正的工作系统。

身份和权限，构成的是安全控制面。微软近来为Agent单独引入身份、赞助人和生命周期治理，本身就说明企业已经开始把Agent当作需要被管理的行动主体，而不只是一个API调用。

但仅有身份和权限还不够。

身份加权限，只能说明“这个Agent用哪个账号，能碰哪些资源”。

身份、权限再加Mandate，才开始回答：

它为什么能代表你做这件事？

它究竟承担了哪一部分责任？

它越界时，谁该把它拉回来？

这才是一种可以被信任的行动关系。

五、例外不是失败，它是控制权转移

如果Mandate是一段持续的委托关系，那么Trigger、Exception和Handoff就不该被看成三套零散功能。

它们本质上是一件事：

控制权的转移

触发器，是人把行动权交给机器。

异常，是机器把行动权交还给人或上级系统。

交接，则是一个执行者把未完成的责任、状态、权限和问题，移交给另一个执行者。

未来的系统里，最关键的是控制权是否在正确的时刻、交给了正确的人。

一个不成熟的Agent产品，通常会把所有异常都扔给最终用户。

于是用户会被一堆看不懂的报错、审批和日志淹没。最后，所谓自动化，只是把一部分机械劳动换成了另一种更烦的“盯着AI工作”。

成熟系统的升级路径应该更像这样：

自修复→专项Agent→主管Agent→运营人员→最终委托人

只有那些涉及重大判断、不可逆风险、权限扩张或目标冲突的问题，才应该真正来到委托人面前。

这也让“注意力”有了一个新定义。

注意力，更像CPU时间、内存和预算一样，是一种稀缺资源。

未来的Agent Inbox，是一个人的注意力调度器。

里面主要出现四类事情：

• 系统希望扩大行动权限；

• 一个变化具有不可逆风险；

• 验证没有通过；

• 原来的委托关系已经不适用，需要人重新判断。

人不会从工作循环中彻底退出。

只是人不再负责逐步操作，而会越来越集中地出现在那些真正决定方向、边界和责任的时刻。

六、“Done”会慢慢失效，Receipt收据会成为新的结束语

今天很多Agent的最终回复是：“任务已完成。”

问题是，完成到底是什么意思？

在一个真实系统里，至少有五种不同的“完成”：

1. 动作已经执行；

2. 外部世界的状态确实发生变化；

3. 原本设定的目标条件已经满足；

4. 系统已经找到足够证据验证它；

5. 人类接受了这个结果。

这五件事经常并不同时发生。

一封邮件已经发出，不代表客户已经理解。

代码已经部署，不代表服务已经恢复。

报表已经生成，不代表结论正确。

支付已经提交，也不代表款项已最终结算。

所以，未来Agent的输出不该只是一个“Done”。

它应该交付一张Receipt收据。

Receipt是让信任可以被追溯。

而且，Agent的状态也不能只理解成“它记住了多少聊天记录”。

至少有四类状态值得被区分：

• 世界状态：外部环境究竟发生了什么；

• 工作状态：任务跑到了哪里；

• 产物状态：生成了哪些文件、代码、方案和记录；

• Agent状态：模型上下文、记忆、工具调用和运行信息。

这会让未来软件的重心从Screen，慢慢迁移到State。

屏幕不再是工作的中心。

屏幕只是在某一刻，把系统状态投影给人看的一个窗口。

七、现有Agent技术栈，恰好缺了一层东西

今天的Agent技术栈已经长得很快。

身份系统在解决“它是谁”。

沙箱和Runtime在解决“它能在哪里运行”。

Durable Execution在解决“任务中断后怎么办”。

MCP在解决“模型如何接入工具、资源和上下文”。

A2A在解决“Agent如何交换任务、消息与产物”。A2A当前的核心对象之一就是有生命周期的Task。

MCP也正在通过Tasks扩展，尝试处理异步、长时间运行和人类介入的任务。

AG-UI、A2UI等协议，则开始讨论Agent的运行状态和界面如何呈现。

这些方向都重要。

但把它们放在一起，会出现一个很明显的空洞：

系统越来越知道任务怎么跑，却还没有统一回答：它为什么能代表某人行动，何时该交还控制权，又如何证明自己完成了委托。

企业内部会用IAM、审批流、预算系统、审计日志、工单和流程引擎，把这些问题拆散处理。问题在于，Agent让这些原本分散的系统第一次需要共同面对一个主体：一个能主动规划、调用工具、跨系统行动、还能把任务交给其他Agent的执行者。

于是，技术栈里浮现出一层尚未被清晰命名的东西：

Delegation Semantics，委托语义层

它管理的不是一次模型调用，而是：

• 谁委托了什么；

• 谁被授权在什么范围内行动；

• 谁对什么结果负责；

• 哪些状态必须被保存；

• 哪些边界必须发生升级；

• 结果该用什么证据证明；

• 出错后怎么恢复。

这也是为什么“Agent OS”这个说法，总让人觉得哪里不对。

它过于站在机器的视角。

八、Agent OS的上面，可能还有一个Delegation OS

如果把未来Agent系统重新分层，大致会是这样：

这里最底层、也最容易被忽略的，是Agency Kernel。

它里面至少要有七个长期概念：

• Identity：谁在行动，谁被代表；

• Goal：最终希望出现什么状态；

• Mandate：哪一份持续委托正在生效；

• Authority：它可以代表谁做到什么程度；

• State：系统、世界和产物目前处于什么状态；

• Boundary：何时应该触发、停止、升级或交接；

• Evidence：凭什么相信它真的完成了工作。

Plan、Prompt、Task、Progress Log，更像Runtime里的过程性对象。

一个计划可以改，任务可以重试，Prompt可以重写，日志可以压缩。

真正不能丢的是：系统现在替谁承担了什么，它有多大权限，它做过什么，最后拿什么对结果负责。

这就是为什么，未来有一类系统或许不该叫Agent OS，而更接近：

Delegation OS

它不是负责“运行更多Agent”，它负责让越来越多的委托关系，可以被安全地交给Agent执行。

九、未来的首页，可能不再是App，也不是Agent

如果沿着这个逻辑继续走，未来个人和企业的Agent首页，可能不会是一排App图标，也不会是一堆Agent头像。

它更可能只剩四个区域：

这会改变人和软件的关系。

过去，我们通过UI操作功能。

今天，我们通过Chat输入指令。

再往后，人可能主要做四件事：

• 定义目标；

• 创建或修改委托；

• 设定行动边界；

• 在关键时刻接受、拒绝或重新接管结果。

人的操作会变少，但权力不会变弱。

恰恰相反，人类会从“不断点击、填写、切换、确认”的过程控制里退出，把精力集中到更高杠杆的判断上。

十、即使AGI到来，这套结构也不会消失

有人会说：如果未来模型足够强、足够可靠，何必搞这么复杂？

答案是，这套结构并不是为了弥补模型不聪明。

即使一个Agent拥有远强于人的能力，依然会有几个问题无法被能力本身消除：

• 不同的人有不同的目标；

• 权限和责任仍要被分配；

• 行动仍会影响金钱、数据、身份和他人；

• 委托人仍然要决定哪些风险可以接受；

• 系统仍需要证明，它没有偏离受托的边界。

模型越强，这些问题反而越重要。

因为它不再只是回答问题，而开始真实地改变世界。

从这个角度看，Agent Computing更接近两个老领域的结合。

它一半像控制理论：目标是参考值，状态需要被观察，Agent是控制器，工具是执行器，证据是反馈，异常和恢复是纠偏机制。

另一半像委托代理理论：委托人和执行者之间天然存在信息不对称、目标偏差、监督成本和不完备契约。

Agent的出现，只是让这种原本存在于组织里的关系，第一次被写进了软件。

可计算的，不再只是任务。

还有委托本身。

最后再回到开头那份“五年网站可用性”的委托。

五年后，只要系统仍在替人行动，它就必须始终回答五个问题：

它代表谁？

它为什么行动？

它可以行动到什么程度？

出了问题，控制权交给谁？

最后凭什么证明，它值得被托付？

GUI让功能变得可操作。

而Agent时代真正要建立的，是让委托变得可计算。