假设一个客服 Agent 正在处理投诉。
它先查订单。
判断用户符合退款条件后，调了支付接口。退款完成。
接着，它给用户发了一封道歉邮件。
然后，它修改 CRM，把用户标为“高风险流失”。
做到第四步时，Agent 从后续上下文里发现：自己一开始理解错了。用户只是询问退款规则，并没有真的要求退款。
这时怎么办？
邮件已经发出去了。
钱已经退了。
CRM 已经被改了。
这不是一个“重试一次”就能解决的问题。
过去我们讨论 Agent 基础设施，最常见的词是持久执行（Durable Execution）：任务跑到第五步挂了，能不能从第五步继续；容器崩了，状态会不会丢；人类审批隔了两天才回来，工作流能不能恢复。
Temporal 的走红，正是因为它解决了这件事。
但 Agent 一旦开始退款、发邮件、下单、改数据库、merge PR、修改生产配置，真正的问题就变了。
不再只是：
这个步骤有没有跑完？
而是：
这个动作，是否应该被允许变成现实？
这可能才是 Temporal 之后，Agent 基础设施最重要的一层。
一、Temporal 证明的，不只是 Workflow 值钱
Temporal 的高估值很容易被解读成：Workflow Engine 是一个大市场。
它更像是在验证一件更基础的事：
Agent 正在从一次性的模型调用，变成一种长期运行的软件进程。
早期 LLM 的结构很简单：
请求 → 模型 → 回复后来变成 Agent Loop：
思考 → 调工具 → 观察结果 → 再思考再往前一步，Agent 会变成一个真正的进程（Process）。
它可能运行几十分钟、几小时，甚至几天。它有工作区，要读文件、写代码、启动环境、等待审批、调用其他 Agent、保存中间产物、恢复失败任务，还会对真实世界产生副作用。
于是，过去分布式系统里那些被认为很“底层”的问题，一下子全回来了：
- 状态如何保存；
- 任务中断如何恢复；
- 重复执行如何避免；
- 一个动作到底执行过没有；
- 多个动作怎样形成一个整体；
- 谁授权它行动；
- 出事后怎么审计；
- 外部世界已经改变时，如何补偿。
Durable Execution 是其中最先爆出来的刚需。
今天，Temporal 之外，DBOS、Restate、Inngest、Cloudflare、Vercel、LangGraph 等系统，也都在把 checkpoint、retry、resume、sleep、wait-for-human、failure recovery 变成 Agent 的默认原语。
OpenAI 新版 Agents SDK 的变化也很说明问题。它把 Harness 与 Compute Sandbox 分开：Harness 管理 Agent 如何调用工具、组织上下文、保留记忆；Sandbox 提供文件、命令、依赖和隔离执行环境。状态被外置后，容器失效不再意味着任务消失，系统可以在新环境里恢复执行。
这已经不是“给大模型加个工作流”了。
这是在给一种新的软件进程补齐生存能力。
问题也随之出现：当 Durable Execution 逐渐成为每个 Agent Runtime 的标配，下一层壁垒会在哪里？
二、Agent 跑得下去，和 Agent 能动真格，是两回事
Temporal 很擅长回答一个问题：
Did the step run?
某个任务是不是跑过？跑到哪里？有没有失败？能否恢复？
但 Agent 还需要回答另一个问题：
Should this effect become real?
它应该真的把钱退掉吗？
应该真的发这封邮件吗？
应该真的合并这个 PR 吗？
应该真的把采购单送出去吗？
应该真的修改这个客户的权限吗？
传统数据库事务能解决一部分问题。
你可以对数据库里的余额、库存、订单状态做 commit 或 rollback。可 Agent 的世界比数据库大得多。
邮件发出去，无法真正撤回。
支付完成，无法假装没发生。
GitHub PR merge 后，可能已经触发部署。
CRM 改错标签，销售团队已经看见了。
调用第三方 API 后，外部系统不一定给你 rollback 接口。
现实世界没有 Ctrl+Z。
这也是为什么 Cordon 这篇论文值得注意。
它提出的不是又一种 Agent Guardrail，而是一个更底层的抽象：Semantic Transaction，语义事务。
Cordon 的判断很直接：今天大多数 Agent Runtime 把工具看成孤立的 RPC。
模型决定调用工具 A；工具 A 返回结果；再调用工具 B；然后调用工具 C。
这种接口很方便，但它缺少一个任务级的边界。
一个真实任务里，工具调用之间不是彼此独立的。
它们共享目标、上下文、授权范围、状态变更和最终后果。
Cordon 想做的是把下面这些东西放进同一份任务级事务里：
工具意图
↓
授权范围
↓
状态修改
↓
结果血缘
↓
外部副作用
↓
恢复信息
↓
审计记录然后把 Agent 的行动过程改写成：
Intent
↓
Plan
↓
Proposed Effects
↓
Policy / Authority Check
↓
Stage
↓
Validate
↓
Commit
↓
Audit
↓
Compensate if necessary这里最重要的词是 stage。
Agent 可以先提出“我要退款”“我要发邮件”“我要修改 CRM”这些效果，但先不让它们立即发生。
系统把可逆的状态变化放进 shadow state，把不可逆的外部动作放进 effect outbox，检查整个任务链路是否越权、是否相互矛盾、是否触发风险策略。通过后再 commit。
这和传统审批不一样。
传统审批通常盯着某一个动作：退款前弹一个确认框。
语义事务盯的是整个任务：退款、邮件、CRM 更新放在一起后，这条行动链是否仍然符合用户的原始意图、授权范围和企业策略。
这就是 Agent Runtime 将来一定会遇到的分界线。
Durable Execution 解决“任务别死”。
Semantic Transaction 解决“任务做错时，别把错误直接变成现实”。
三、Agent 需要的不是 API Key，而是被委托的权力
很多企业今天给 Agent 权限，方式仍然很粗糙。
发一个 API Key。
给一个 service account。
授予几个 OAuth scope。
这对传统程序通常够用。传统程序是稳定的、长期存在的、功能预先写死的。它大致知道自己要干什么。
Agent 不一样。
它可能由用户临时创建，几分钟后销毁；也可能代表某个员工长期工作；还可能由另一个 Agent 委托，继续调用更多 Agent 和工具。
想象一个采购 Agent。
它真正需要的授权不是“可以调用采购 API”。
更接近这样：
王零壹授权采购 Agent，在 24 小时内，代表自己向指定供应商采购服务器。预算不超过 2 万美元。不得修改付款账户。任何单笔超过 5000 美元的采购，必须重新确认。
这份授权至少包含：
谁授权
↓
授权给谁
↓
代表谁行动
↓
可做什么
↓
不可做什么
↓
预算多少
↓
多久失效
↓
何时需要再次确认这就是 Delegated Authority，委托式授权。
它比“有没有权限”复杂得多。
权限是静态的。
委托是有上下文的。
Agent 也不是单纯的应用身份。它既可能拥有自己的权限，也可能代表某个用户行动；它的生命周期短，数量大，行为动态，甚至会在一次任务中临时生成和销毁。
Microsoft 已经把 Agent Identity 做成 Entra 中独立的一等身份类型。其公开文档专门区分了 Agent Identity、User Identity 和 Application Identity，并强调 Agent 的高动态生命周期、最小权限、可追踪活动和代理用户的授权关系。
这意味着 Agent IAM 已经不是远期概念。
只是它会比传统 IAM 多出一层难题：
这个 Agent 是谁，和它能代表谁做事，是两件不同的事。
未来企业里的 Agent 权限模型，很可能要把身份、委托、预算、时间、动作边界和后果归属一起表达。
否则，所谓“让 Agent 帮我干活”，最后会变成“给一个概率模型一把万能钥匙”。
四、Memory 会变成 State
Agent Memory 现在很热。
很多产品把它理解成：让 Agent 记住用户偏好、历史对话和过去经验。
不过，长期运行的 Agent 需要保存的东西，远比“记忆”复杂。
Temporal 记录的是 Execution State。
程序执行到了第几步，完成了什么 Activity，下一次从哪恢复。
Agent 还需要维护至少六种状态。
第一种是 Working State。
它现在在做什么？已经检索到哪些资料？中间结论是什么？哪个子任务正在等待人类批准？
第二种是 World State。
外部世界已经发生了什么？这笔退款是否已经到账？库存是否已被占用？PR 是否已经 merge？客户是否收到通知？
第三种是 Context State。
Agent 当前为什么这么判断？它依据哪些合同、日志、数据库记录、政策文件和用户指令？
第四种是 Episodic Memory。
过去做过什么？遇到过什么异常？某次失败是怎么处理的？
第五种是 Semantic Memory。
过去学到了什么可以复用的知识、策略、Skill 和业务规则？
第六种是 Artifact State 与 Causal Lineage。
生成过哪些文件、代码、报告和中间产物？这条结论来自什么输入？这个动作又影响了哪些后续结果？
这几层加在一起，才更接近一个长期 Agent 的有效状态。
Cloudflare 在推出 Agent Memory 时提到，即使上下文窗口达到百万 token，context rot 仍然是问题。把所有信息都塞进模型上下文，会让信息质量下降；过度裁剪，又可能丢掉未来需要的内容。
这正说明了一个常见误区。
长上下文不等于长期状态。
Memory 解决“Agent 记得什么”。
State 解决“Agent 此刻处于怎样的真实世界”。
后者会成为比向量检索更大的基础设施问题。
因为只要 Agent 要跨天运行、跨系统行动、跨人协作，它就不能只有一段被压缩过的聊天历史。
它得拥有一个连续、可信、可追溯的世界模型。
五、当企业有一万个 Agent，必然会长出 Control Plane
过去一年，企业对 Agent 的想象经历了一个很快的变化。
一开始，大家关心的是：
“我能不能做一个客服 Agent？”
后来，问题变成：
“我能不能让客服、销售、采购、财务、研发都各有一个 Agent？”
再往后，CIO 会面对另一种景象：
公司里到底有多少 Agent？
谁创建的？
谁负责？
它们调用了哪些模型和工具？
谁有数据库写权限？
谁在花钱？
谁的错误率突然上升？
哪一个需要被立刻 kill？
这和 Kubernetes 早期的路径很像。
最初，人们只想把一个容器跑起来。
后来，容器数量变成几千、几万。调度、观测、配额、网络、权限、策略、生命周期，全部需要集中治理。
于是 Control Plane 出现了。
Agent 也会经历同样的过程。
Salesforce 最近发布 Enterprise AI Harness 时，把 AI Control Plane 放在非常靠前的位置。其描述包括发现与注册 Agent、身份与策略、生命周期管理、性能评估、行为与结果监控、成本控制，并覆盖 Salesforce 和第三方 AI 系统。
这不是某家公司的独特包装。
它反映出一个现实：当 Agent 从单点功能变成企业里的机器劳动力，管理层需要一个统一的地方，知道这些“非人类员工”在干什么。
Control Plane 不是让 Agent 更聪明。
它负责让组织不被一群 Agent 拖进不可见的混乱。
未来它大概会横跨整个系统：
- 注册与发现；
- 身份与委托；
- 策略和预算；
- 生命周期与版本；
- 审批和 kill switch；
- 成本与资源配额；
- 评测与行为监控；
- 合规、审计和责任追踪。
这层的价值很容易被低估。
因为它平时看上去什么都没做。
可一旦 Agent 误操作、越权、泄露数据、成本失控或调用链无限循环，企业首先找的就是它。
六、Agent Gateway 和 Sandbox，分别管理“出门”和“落地”
Agent 不会只在模型上下文里思考。
它需要走出去。
它要连接模型、工具、MCP Server、数据库、企业 API、其他 Agent 和外部服务。
因此，传统 API Gateway 的边界会被重新定义。
过去它管理的是：
Application → API未来它需要管理：
Agent → Model
Agent → Tool
Agent → MCP
Agent → Agent
Agent → API这不仅是流量问题。
它还要处理模型路由、协议转换、认证、授权、速率限制、预算、trace、内容策略和风险控制。
Gateway 管的是 Agent 怎么出门。
Sandbox 管的是 Agent 到哪里干活。
越来越多 Agent 的工作不只是调 API。它们要 clone 仓库、安装依赖、运行脚本、打开文件、浏览网页、编译代码、生成产物，有时还要开多个隔离环境并行探索。
这就是为什么 E2B、Daytona、Modal、Cloudflare、Vercel 以及模型公司，都在布局 Agent Computer 和 Sandbox。
OpenAI 对 Harness 与 Compute 的分离，实际上说得很清楚：
Harness 负责 Agent 如何思考和行动。
Sandbox 提供 Agent 真正行动的计算环境。
前者可以不断迭代，后者必须可隔离、可快照、可恢复、可限制权限。
Agent 的“脑”和“手”最好不要放在同一个不受控的地方。
七、Observability 最后会变成 Verification
今天的 Agent Observability，常常盯着这些指标：
- 调用了多少次模型；
- 花了多少 token；
- 延迟多长；
- 调了哪些工具；
- 有没有报错；
- Trace 是否完整。
但企业最终真正想知道的不是：
这个 Agent 调了 18 次工具。
而是：
它完成任务了吗？
它完成得对吗？
它是不是按授权在做？
它造成了什么现实后果？
出问题后，我们能不能解释、追溯和补偿？
这就是 Observability 之后的下一步。
Observability
↓
Evaluation
↓
Verification最后可能会形成一个新的类别：Agent Assurance 智能体保障
它不只记录 Agent 做过什么。
它试图证明：这个 Agent 做了它应该做的事。
这件事会把 tracing、evaluation、policy enforcement、transaction log、audit、outcome monitoring 慢慢拉到一起。
传统软件里，一个 API 返回 200，往往就算成功。
Agent 世界里，任务完成不等于业务正确。
一个 Agent 可以成功调用十个 API，却让客户收到一封不该收到的邮件，导致一笔不该退的钱退了出去。
对 Agent 而言，“成功”必须包含语义。
八、未来的 Agent Runtime，大概会长成三个 Plane
把上面的东西拼起来，未来的 Agent Application Platform 可能不再是：
Model
↓
Agent Framework
↓
Tools更像三个彼此协作的 Plane。
Runtime Plane：它怎么跑
这一层负责执行。
包括 durable execution、workflow、checkpoint、retry、scheduler、concurrency、sandbox、tool execution、agent-to-agent execution 与 gateway。
Temporal 的核心价值，主要就在这里。
State Plane：它现在知道什么，世界发生了什么
这一层负责长期状态。
包括工作状态、上下文、Memory、artifact、world state、execution history、provenance 和 lineage。
它要解决的，不只是“Agent 记住了什么”，还包括“真实世界已经被 Agent 改成什么样”。
Control Plane：它能不能这样做
这一层负责约束和治理。
包括 identity、delegated authority、permissions、policy、budget、approval、transaction、evaluation、audit、lifecycle 和 kill switch。
Control Plane 并不只是 Runtime Plane 的下一层。
它实际横跨整个系统。
它要在 Agent 读取数据前、调用工具前、产生副作用前、提交结果后，都能介入和留下证据。
Harness 则在这三层之上。
它负责 Prompt、Skill、planning、tool selection、context assembly、memory policy、routing 和 model selection。
Harness 决定 Agent 如何思考。
三个 Plane 决定它能否可靠地存在于现实世界。
九、真正值得沉淀的，可能是一种新的任务对象
Temporal 最重要的数据对象之一，是 Workflow Execution History。
它记录程序发生了什么。
未来 Agent Runtime 最重要的对象，可能不再只是执行历史。
它更像一份 Semantic Execution Ledger，或者 Agent Execution Contract。
一个长期运行的 Agent Task，至少应该包含七个字段：
Identity：谁在执行
Mandate：谁授权、为何授权
Goal：它要达成什么结果
State：当前任务和世界处于什么状态
Capabilities：它可以调用什么能力
Effects：它准备改变什么
Evidence：为什么认为这些行动合理接下来，执行过程就不再只是：
Tool Call A
↓
Tool Call B
↓
Tool Call C而是：
Task
↓
Identity / Mandate / Goal
↓
Plan
↓
Proposed Effects
↓
Policy Check
↓
Transaction Boundary
↓
Commit
↓
Evidence + Audit
↓
New World State这已经超出传统 Workflow 的范畴。
Workflow 关心流程走向。
Agent Execution Contract 关心一个有自主性的系统，是否有资格以某种方式改变世界。
它的任务不是让 Agent 永远不犯错。
这不现实。
它要做的是，让错误不至于在无人知晓的情况下被放大；让每一次关键行动都有授权边界、状态记录、提交规则、证据链和补偿路径。
十、Durable Execution 之后，创业机会在哪里
Durable Execution 会是大市场。
但它正在迅速基础设施化。
当越来越多云厂商、Agent Framework 和工作流系统都默认支持 retry、checkpoint、resume 和 human-in-the-loop，单独卖“更耐跑的工作流”会越来越难。
新的机会更可能集中在三处。
第一，Semantic Transaction 或 Agent Effects Layer。
它解决的是：Agent 的现实世界动作怎样被暂存、校验、提交、审计和补偿。
这层很新，技术难度高，也很接近金融、采购、CRM、代码部署等高价值场景的真实需求。
第二，State + Context Plane。
它解决的是：一个运行几小时、几天甚至几个月的 Agent，怎样拥有连续、可信、可验证的世界状态。
这不会只是一个向量数据库，也不会只是长上下文。
第三，Agent Control Plane。
它解决的是：当一个组织拥有成千上万个 Agent 实例时，如何管理它们的身份、权限、预算、行为、结果和风险。
其中，Identity、Gateway、Sandbox 都会是大市场。
但它们也很容易被云厂商、企业软件公司和既有安全平台吸收。独立创业者更可能从窄切口进入，例如 Delegated Authority Engine、Agent Transaction Manager、跨系统 State Lineage，或者面向特定行业的 Agent Assurance。
Temporal 的机会在 Execution。
后面的机会，可能在如何把 Execution 变成可靠、被授权、可验证的 Action。
十一、Agent 不是一个模型功能
Temporal 这波热度最容易引发一个误读：
AI Agent 需要 Workflow。
更准确的说法是：
Agent 正在成为一种新的软件运行单位。
它有身份。
有状态。
长期存在。
消耗资源。
与人、系统和其他 Agent 通信。
它会对外部世界产生副作用。
历史上，每出现一种新的计算主体，周围都会长出一整套基础设施：Runtime、Identity、State、Networking、Security、Transaction、Observability、Governance。
Agent 也不会例外。
Temporal 让大家看见了第一块刚需：长期任务必须跑得下去。
下一阶段的难题更棘手：
一个由概率模型驱动的系统，如何安全地退款、采购、部署、修改数据、调用支付系统、代表人类签署承诺，并在出错后留下可解释、可审计、可补偿的后果？
这件事还没有标准答案。
但方向已经浮出来了。
从 Reliable Agent Execution，走向 Governed Agent Action。
这才是 Agent 的下一层基础设施。
>/作者：王零壹，920.org.cn（AI Research Institute）创始人，港大AIBT研究生，前上市公司 CMO。长期研究 AI 产品、Agent 架构与商业增长，并持续观察技术变迁如何重塑人的工作、判断与生活。
*著有《AIGC从0到1》系列丛书、及东方寓言小说《飞将军》；
*善于洞察先机，中文互联网第1个意识到OpenClaw范式价值的人（1月26日）；
关注我，一起AIGC从0到1~
