本文来自微信公众号： AIGC从0到1 ，作者：王零壹，原文标题：《Agent 时代，最重要的新对象，可能不是 Agent》
当模型、工具和执行者都可以被替换，系统里真正该被长期管理的，到底是什么？
--
上一篇文章讨论过一件事：当AI开始替人行动，未来的界面就不该只剩一个聊天框。目标、权限、状态、例外、证据，都要有地方被看见。参见前文当AI开始替你行动，界面开始不再像界面
但这次往下挖，问题变了。
它不再是“未来UI应该有哪些组件”，而是：当一个Agent长期替人行动时，系统究竟在管理什么？
想象这样一个委托：
未来五年，保证这个网站持续可用。
小问题你自己修；涉及数据风险时停止并上报；超过一万元的支出，需要我批准；每一次重大变更，都留下可追溯的记录。
五年里，模型会升级，工具会更换，某个Agent可能下线，任务会在人类和不同Agent之间交接。
那么，到底是谁还在“负责”？
显然不是某个具体Agent。它只是此刻的执行者。
也不是某个Task。它只是一个阶段性的任务单元。
真正持续存在的，是那份尚未完成的委托：它规定了目标、权限、预算、边界、升级路径、证据要求，以及最后谁该为结果负责。
这可能是理解Agent时代最关键的一次视角转换：
Agent不是未来系统里最稳定的对象。
真正稳定的，是一份可以被执行、交接、验证、暂停、撤销和追责的委托。
暂且把它叫作：Mandate。
一、八个界面原语，不在同一层级
上一轮讨论Agent界面时，我们列出过一组关键要素：目标、责任、权限、状态、触发、例外、验证、恢复。
它们方向是对的，但这次研究给出了一个更精确的修正：
这些东西不在同一个层级。
有些是系统里长期存在的对象；有些是发生在运行过程中的事件；还有一些只是系统应该具备的操作能力。把它们一股脑称为“原语”，会让产品设计很快变成名词堆砌。
更合理的划分是：
| 层次 | 它回答的问题 | 典型内容 |
|---|---|---|
| 对象 | 系统里长期存在什么 | Identity、Goal、Mandate、State、Evidence |
| 关系 | 谁与谁构成了什么关系 | 拥有、委托、授权、依赖、担责 |
| 事件 | 控制权什么时候变化 | 触发、异常、交接、验证失败 |
| 操作 | 系统如何行动与恢复 | 授权、升级、暂停、撤销、回滚、补偿 |
这张表虽抽象，但它其实解决了一个很实际的问题。
今天我们总是在问：“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的最终回复是：“任务已完成。”
问题是，完成到底是什么意思？
在一个真实系统里，至少有五种不同的“完成”：
动作已经执行；
外部世界的状态确实发生变化；
原本设定的目标条件已经满足；
系统已经找到足够证据验证它；
人类接受了这个结果。
这五件事经常并不同时发生。
一封邮件已经发出，不代表客户已经理解。
代码已经部署，不代表服务已经恢复。
报表已经生成，不代表结论正确。
支付已经提交，也不代表款项已最终结算。
所以，未来Agent的输出不该只是一个“Done”。
它应该交付一张Receipt收据。
| 一张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智能体内核 | 身份、目标、委托、权限、状态、证据、事件日志、恢复能力 |
| Agent Runtime智能体运行时 | 任务、计划、工具、子Agent、沙箱、调度和执行 |
| Agency Layer智能体层 | 承诺、变化、边界、收据、策略与决策 |
| Presentation Layer表示层 | 对话、卡片、画布、语音、Dashboard、生成式UI |
这里最底层、也最容易被忽略的，是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头像。
它更可能只剩四个区域：
| 首页区域 | 它显示什么 |
|---|---|
| Commitments | 系统正在替我承担哪些长期承诺 |
| Changes | 它已经让外部世界发生了什么变化 |
| Needs You | 哪些边界需要我重新行使判断 |
| Receipts | 每一项行动留下了怎样的证据与记录 |
这会改变人和软件的关系。
过去，我们通过UI操作功能。
今天，我们通过Chat输入指令。
再往后，人可能主要做四件事：
定义目标；
创建或修改委托；
设定行动边界；
在关键时刻接受、拒绝或重新接管结果。
人的操作会变少，但权力不会变弱。
恰恰相反，人类会从“不断点击、填写、切换、确认”的过程控制里退出，把精力集中到更高杠杆的判断上。
十、即使AGI到来，这套结构也不会消失
有人会说：如果未来模型足够强、足够可靠，何必搞这么复杂？
答案是，这套结构并不是为了弥补模型不聪明。
即使一个Agent拥有远强于人的能力，依然会有几个问题无法被能力本身消除：
不同的人有不同的目标；
权限和责任仍要被分配；
行动仍会影响金钱、数据、身份和他人；
委托人仍然要决定哪些风险可以接受；
系统仍需要证明，它没有偏离受托的边界。
模型越强，这些问题反而越重要。
因为它不再只是回答问题，而开始真实地改变世界。
从这个角度看，Agent Computing更接近两个老领域的结合。
它一半像控制理论：目标是参考值，状态需要被观察，Agent是控制器，工具是执行器，证据是反馈，异常和恢复是纠偏机制。
另一半像委托代理理论：委托人和执行者之间天然存在信息不对称、目标偏差、监督成本和不完备契约。
Agent的出现，只是让这种原本存在于组织里的关系，第一次被写进了软件。
可计算的，不再只是任务。
还有委托本身。
最后再回到开头那份“五年网站可用性”的委托。
五年后，只要系统仍在替人行动，它就必须始终回答五个问题：
它代表谁？
它为什么行动？
它可以行动到什么程度？
出了问题，控制权交给谁？
最后凭什么证明，它值得被托付？
GUI让功能变得可操作。
而Agent时代真正要建立的，是让委托变得可计算。