Agent的下一个阶段是什么

过去两年，行业讨论 Agent，最常见的问题是：模型够不够聪明？工具调用准不准？上下文窗口够不够长？多 Agent 能不能协作？这些问题当然重要，但它们越来越不像决定 Agent 能否进入真实业务的最后一道门槛。真正阻止 Agent 从演示走向生产的，往往不是它不会思考，而是它无法在几个小时、几天甚至几周的任务中持续保存状态，无法在故障后恢复，无法证明自己看过什么、做过什么，也无法回答一个企业最关心的问题：如果行动出了错，谁能阻止、追踪、修复并承担责任？因此，Agent 的下一个阶段，不只是模型能力继续提升，而是 Runtime 成为新的基础设施。模型负责产生决策，Runtime 负责让决策在真实世界中安全、可靠、可审计地发生。当行业的一级对象从 Conversation 转向 Task，Agent 才真正从“会说话的软件”变成“能够承担任务的执行单元”。 ## 一、Agent 正从模型时刻走向系统时刻 大模型第一次让软件具备了处理模糊意图的能力。传统软件要求用户把需求翻译成菜单、表单、查询条件和固定流程，大模型则允许用户直接表达目标：“分析这批客户为什么流失”“整理本周项目风险并通知负责人”“找到三个可行供应商，完成初步询价”。 这是一种根本性的变化。输入不再是精确指令，而是目标；输出也不再只是信息，而可能是一连串行动。 但从“理解目标”到“完成任务”之间，有一段经常被产品演示隐藏起来的距离。一个模型可以在几十秒内生成漂亮的分析报告，却未必知道数据是否过期；可以调用邮件工具，却未必知道收件人是否属于允许触达的范围；可以修改数据库，却未必能在网络超时后判断操作究竟成功还是失败；可以制订十步计划，却可能在执行到第七步时因为进程重启而忘记前六步发生过什么。 这说明，模型能力解决的是“有没有可能”，生产系统解决的是“能不能兑现”。 如果把 Agent 的业务价值写成一个简单公式，它更接近：  ```text Agent 业务价值 = 模型能力 × Runtime 兑现率 × 上下文质量 × 治理可信度 ``` 这不是加法，而是乘法。任何一项接近零，最终价值都会迅速坍缩。 早期 Agent 产品容易把全部注意力放在模型能力上，因为模型变化最显眼：推理更强、上下文更长、工具调用更准确、成本更低。这些进步会直接改善演示效果，却不会自动生成企业级可靠性。一个成功率从 80% 提升到 90% 的模型，依然意味着每十个任务可能有一个失败。对于生成文案，这也许可以接受；对于付款、发布、审批、客户承诺和生产数据修改，这远远不够。 因此，Agent 的发展正在经历四个阶段。 第一阶段是 Chat。模型围绕一次对话生成答案，人类是行动主体，AI 提供建议。 第二阶段是 Tool Use。模型能够选择工具、填写参数并完成短链路操作，AI 开始进入行动过程。 第三阶段是 Agent Loop。模型开始规划、反思并连续调用多个工具，但状态与责任仍主要依赖单次运行，循环一旦中断，系统往往缺少稳定的恢复依据。 第四阶段是 Runtime。任务可以跨越多轮、多个系统和较长时间运行，拥有稳定身份、状态、权限、预算、审批、审计和恢复机制，AI 才开始成为可管理的执行单元。 为了看清这次变化，可以把 Agent 的演进压缩为四个连续阶段。每前进一步，系统需要承担的状态与责任都会增加。  这个阶段变化的关键，不是 Agent 看起来更像人，而是它开始像一个真正的软件运行实体：它可以被创建、调度、暂停、观察、限制、恢复、终止和追责。 模型时刻关注“智能涌现”，系统时刻关注“责任落地”。前者决定能力上限，后者决定组织是否敢把关键任务交出去。 ## 二、Runtime 不是 Agent 框架，也不只是工作流引擎 “Agent Runtime”很容易成为一个模糊的大词。有人把调用模型的循环称为 Runtime，有人把可视化工作流称为 Runtime，也有人把部署 Agent 的服务器称为 Runtime。如果概念边界不清楚，我们就无法判断行业究竟在竞争什么。 一个最小的 Agent Loop 通常只有三件事：把上下文发送给模型，读取模型返回的工具调用，执行工具后把结果再次交给模型。只要模型没有给出最终答案，循环就继续。这已经足以完成许多令人惊艳的演示。 但生产级 Runtime 要回答的是另一组问题： - 进程在执行到一半时崩溃，任务从哪里恢复？ - 工具返回超时，但实际操作已经成功，是否会被重复执行？ - Agent 等待人类审批三天，期间状态保存在哪里？ - 同一个任务被两个 Worker 同时领取，如何避免重复行动？ - 模型、提示词或工具版本升级后，旧任务按照哪个版本继续？ - Agent 代表谁行动，它获得的权限能否随任务缩小？ - 任务完成是指程序停止，还是业务结果已经被验收？ - 出现错误时，系统能否撤销、补偿或转交人工？ 这些能力都不属于单纯的模型推理，也不是画一张 DAG 就能自然获得。 传统工作流引擎擅长运行确定性流程。开发者预先定义节点、顺序、分支和失败策略，系统按照规则执行。Agent 则把一部分控制流交给模型：下一步做什么、调用哪个工具、是否需要补充信息，可能在运行时才被决定。它既不像普通函数那样完全确定，也不能像自由对话那样没有边界。 因此，Agent Runtime 可以被定义为： > 一个把非确定性模型决策封装在确定性执行边界内，并持续管理任务状态、行动权限、资源消耗、风险控制与结果责任的系统。 这一定义里有两个关键词。 第一个是“非确定性”。同样的输入，模型可能产生不同计划；即使温度设为零，模型版本、上下文顺序和外部数据变化仍可能改变结果。Runtime 不能假设每次重放都会获得完全相同的推理。 第二个是“确定性边界”。模型可以提出行动，但是否允许执行、执行几次、使用什么凭证、消耗多少预算、何时需要审批、如何记录证据，不能由模型临时决定。否则，系统就把业务控制权交给了一个概率函数。 这也是 Agent 框架、Harness 和 Runtime 的区别。 Agent 框架提供模型、工具、消息、handoff 等开发抽象，让开发者更容易写出 Agent。 Harness 为模型准备工作环境，例如文件系统、终端、搜索、规划、子 Agent 和上下文管理，让模型能够处理更复杂的任务。 Runtime 则拥有任务生命周期。它负责把某次执行变成一个可持续存在、可查询、可恢复、可治理的业务对象。 三者可以属于同一个产品，也可以由不同基础设施组合完成。但在架构判断上，必须把它们分开。否则，团队很容易在拥有一个“能跑”的 Agent 后，误以为已经拥有一个“能上线”的 Agent 系统。 对架构师而言，判断一个产品属于哪一层，不能看它是否使用了“Agent”这个名字，而要看它实际拥有哪种生命周期责任。下面这张图把三者放在三个可组合的责任面中：Framework 管开发抽象，Harness 管工作环境，Runtime 管跨时间和组织边界的任务责任；它们可以组合，也可以由同一个产品同时提供。  开发工程师可以用 Framework 快速建立模型与工具循环，用 Harness 提升复杂任务中的上下文与工作能力；但只要任务需要跨进程恢复、长时间等待审批，或要求外部副作用具备授权、幂等、恢复与审计保证，就进入 Runtime 的责任范围。对技术管理者而言，这条边界也对应投入顺序：先在受控环境中验证模型能否完成任务，再建设让组织敢于托付任务的运行基础设施。 ## 三、一级对象正在从 Conversation 转向 Task 今天很多 Agent 应用仍然以 Conversation 为中心。数据库里保存的是 thread、message、role、content；一次用户输入触发一次模型运行，运行结束后返回一条消息。这种结构继承自聊天机器人，非常适合问答，却不适合承担任务。 对话没有天然的完成条件。一段对话可以包含多个目标，也可能在几个月后继续。消息能够表达进展，却不能可靠代表业务状态。用户说“继续”，究竟是继续哪个任务？Agent 回复“已经处理”，究竟是生成了结果，还是外部系统已经确认成功？这些问题无法只靠消息历史解决。 Task 不同。Task 是一个有边界的责任容器。它至少需要明确： - 目标是什么； - 谁发起、谁授权、谁验收； - 可以访问哪些上下文； - 可以使用哪些工具与权限； - 预算、时间和风险上限是什么； - 当前处于哪个状态； - 产生了哪些行动、证据与产物； - 失败后如何重试、补偿或转交； - 什么条件下才算真正完成。 工程上可以把这组责任压缩为一个最小 `TaskContract`：`task_id` 标识任务，`intent` 与 `desired_outcome` 描述目标；`requester_ref`、`authorizer_ref`、`accountable_owner_ref` 与 `acceptance_owner_ref` 分别记录发起者、授权者、责任归属和验收责任；`delegation_chain_ref` 与当前 `credential_ref` 记录执行身份如何逐级派生。`status`、`budget` 与 `deadline` 约束运行过程，`context_refs` 绑定上下文来源，`policy_snapshot_refs` 与 `risk_tier` 保存各次行动实际采用的策略和风险事实，`acceptance_criteria` 定义完成条件，`recovery_policy` 则规定失败后采用重试、补偿还是升级人工。它不是一段更长的 Prompt，而是 Runtime 可以校验、持久化和版本化的结构化契约。读图时，重点不是字段本身，而是 Task 如何把职责分离、委托链、上下文、策略、行动、产物和验收组织成一条可追溯的责任索引。  这张图给出的不是完整审计日志结构，而是一条可扩展的责任主索引。Task 直接记录发起、授权、责任归属和验收四类职责；`DelegatedPrincipal` 的每条记录代表一级派生凭证，串起完整委托链；`PolicySnapshot` 则按行动保留策略版本、风险事实哈希与评估时间，而不是让长任务只指向一份会变化的当前策略。 每个 Action 都绑定实际 `actor_ref`、所用 `credential_ref`、`permit_id`，以及 `action_hash`、`op_key`、`request_ref`、`request_hash`。其中 `request_ref` 指向不可变的规范化请求载荷，包含工具、目标和参数；恢复或重放前，执行网关必须重新计算哈希并与 `request_hash` 比对。Action 的 `policy_ref` 指向本次决策实际使用的快照，Acceptance 则用 `reviewer_ref` 记录实际验收人。模型、Agent 和对话可以更换，但这些记录必须持续绑定同一个 `task_id`，系统才能在 handoff 后仍重建谁发起、谁授权、谁以哪一级凭证和哪份策略执行了什么，又由谁完成验收。 Agent、模型与对话都可以在 Task 内变化。一个任务可能先由规划 Agent 拆解，再交给检索 Agent、执行 Agent 和审查 Agent；中途模型可能从低成本模型切换到强推理模型；人类也可能通过对话补充信息。但 Task 的身份、目标和责任边界不应随之漂移。 一个生产级任务状态机，通常不会只有 `running` 和 `completed`。 如果 Task 是一级对象，它就必须拥有独立于聊天消息的生命周期。下面的状态机展示了执行、等待、失败、补偿与验收之间的关系。  这里最重要的变化是：`Produced` 不等于 `Accepted`。`Paused`、`Reconciling (Unknown)` 和 `Compensating` 也都不能绕过控制直接回到执行；补充输入、编辑提案、安全重试、权威确认、补偿成功和验收退回，必须先进入 `Revalidating Action`，重新通过凭证、策略与风险检查。 很多 Agent 系统把模型输出最终答案当作任务完成。但企业真正关心的是结果是否达到验收标准。例如，生成一份供应商名单只是产物；供应商信息真实、满足资质要求、报价在预算内并由采购负责人确认，才是被接受的结果。 一旦 Task 成为一级对象，产品指标也会变化。团队不应只看对话满意度、调用次数或 Token 成本，而要关注任务成功率、验收通过率、人工介入率、回滚率、策略违规率、平均恢复时间，以及每个被接受任务的成本。 这可能是 Agent 产品从 Copilot 走向 Autopilot 时最关键的一次数据模型迁移。 ## 四、Agent Runtime 需要怎样的系统架构 一个完整的 Agent Runtime，可以理解为四个相互约束的平面：控制面、状态面、执行面和治理面。 控制面决定任务如何向前推进。它接收目标，选择 Agent 与模型，管理计划、路由、handoff、并发、超时和终止条件。控制面允许模型参与决策，但必须限制模型能够改变的范围。例如，模型可以选择下一项工具，却不能自行提高预算；可以提出需要更多权限，却不能直接获得权限。 状态面负责让任务跨越时间和故障持续存在。它保存任务状态、事件历史、上下文引用、模型调用、工具结果、审批决定与产物版本。理想的状态面不是不断覆盖一份巨大的 JSON，而是保留可追踪的事件序列，并在关键节点建立 Checkpoint。这样系统才能回答：任务为何走到今天这一步？如果从某个节点恢复，哪些动作需要跳过，哪些推理需要重新执行？ 执行面负责真正产生副作用。它连接 API、数据库、浏览器、代码沙箱、消息系统和企业应用，管理 Worker、队列、并发和资源隔离。执行面必须假设模型输出不可信、工具描述可能不完整、网络随时会失败。所有参数都需要结构化校验，敏感工具需要最小权限，代码执行需要隔离，外部操作需要超时、限流、幂等与补偿机制。 治理面负责建立行动的合法性和可解释性。它将组织政策转化为机器可执行规则：什么数据可以被读取，什么动作需要审批，哪些用户可以授权，什么风险等级必须由谁复核。治理面还要记录完整审计链路，并支持运行时评估，而不是等事故发生后再翻日志。 把这些要求落到系统中，可以得到控制面、状态面、执行面和治理面四个相互制约的部分。它们围绕同一个 Task 协同，而不是围绕一次模型调用临时拼接。  在这四个平面之上，还需要两个横向能力。 第一个是可观测性。传统 APM 关注请求延迟、错误率和资源使用，Agent 可观测性还要关注决策轨迹：模型为什么选择这个工具？它基于哪些上下文？在哪一步发生了计划偏移？一次任务可能包含几十次模型调用和工具调用，如果只能看到最终答案，就无法定位失败来自模型、数据、工具、策略还是编排。 第二个是评估。离线 Benchmark 只能告诉我们模型在测试集上的表现，Runtime 需要在真实任务中持续评估过程和结果。每个关键步骤都可以拥有局部契约：输入是否完整、输出是否符合 Schema、引用是否真实、行动是否命中风险规则。最终产物还要由业务验收标准判断，而不是由另一个模型给出一个笼统分数。 这套架构的核心并不是增加更多组件，而是建立清晰的所有权：模型拥有建议权，策略拥有授权权，Runtime 拥有执行控制权，业务负责人拥有验收权。 ## 五、真正困难的工程问题，不在 Agent Loop 里 写一个 Agent Loop 并不难。真正困难的是，当模型开始改变外部世界时，分布式系统里那些最棘手的问题会全部回来，而且多了一层非确定性。 第一个难题是副作用与重试。 假设 Agent 调用付款接口，网络在返回响应前中断。Runtime 无法确定付款失败，还是付款成功但响应丢失。如果直接重试，客户可能被扣款两次；如果不重试，任务可能永远停在未知状态。 解决办法不是要求模型“谨慎一点”，而是工程机制。工具调用需要稳定的幂等键；关键写操作要支持查询最终状态；跨系统流程需要 Outbox、事务日志或补偿动作；Runtime 还要区分可安全重试的读取、具有幂等保证的写入，以及只能人工确认的不可逆行动。 因此，“自动重试三次”不是可靠性策略。对无副作用调用，它可能有效；对有副作用调用，它可能制造三次事故。 下面用一次“请求超时但外部操作可能已成功”的典型场景说明 Runtime 的价值。关键点不是多重试几次，也不是把外部结果假装成确定事件，而是让每次行动都可唯一标识、可查询、可对账，并在获得权威结果前保持 Unknown。  对开发工程师，这意味着关键写操作只有在工具提供权威状态查询和明确的幂等契约，且查询确认 `NotAccepted`、无在途请求时，才可自动重放同一 Action；契约还应定义键作用域、请求指纹、保留期与重复请求行为。补偿本身也是新的副作用，需要独立的 `op_key` 和恢复协议。Action Ledger 的每条唯一记录映射 `action_id`、`permit_id`、`op_key`、`request_ref` 与 `request_hash`；`request_ref` 指向审批时固化的工具、目标和参数载荷，执行或重放前都要重新计算哈希并与 permit 比对。permit Claim 与 Pending 写入同一持久事务，崩溃恢复只能沿同一条 Action 记录和同一份不可变请求继续。对架构师，Action Ledger 与幂等执行器构成持久恢复、对账和审计边界，而不是跨系统事务边界；对技术管理者，是否能够安全处置 Unknown，决定系统能否进入付款、发布和生产变更等关键流程。 第二个难题是重放与版本。 传统持久化工作流要求控制逻辑具有确定性：系统通过事件历史重放程序，恢复到故障前状态。但 Agent 的控制逻辑可能由模型生成。同一个模型再次调用都可能给出不同答案，更不用说模型、提示词、工具描述和外部数据都可能已经升级。 Runtime 必须明确区分两种操作：恢复和重新计算。 恢复意味着沿用已经确认的历史结果，从最后一个安全 Checkpoint 继续；重新计算意味着接受新的模型决策，并创建一条新的任务分支。二者不能悄悄混在一起。否则，所谓“恢复”可能改变原计划，甚至重复已经发生的现实行动。 这要求 Runtime 为每次关键决策保存版本快照：模型标识、Prompt 版本、工具 Schema、策略版本、上下文来源和代码版本。对于高风险任务，还应保存模型提出行动时的证据，而不只是自然语言推理。 第三个难题是身份与权限。 Agent 调用企业系统时，究竟代表谁？如果直接使用一个高权限服务账号，所有用户通过 Agent 获得的能力都可能超出自身权限；如果完全继承用户权限，后台长任务又会遇到 Token 过期和人员离职问题。 更合理的做法是任务级委托。用户或组织授权一个明确任务，Runtime 为任务签发短期、限定范围的执行身份。这个身份只能访问完成任务所需的资源，只能调用批准的工具，并受到预算、时间与风险约束。子 Agent 接手任务时，权限只能保持或进一步收窄，不能因为 handoff 自动扩大。 这相当于把最小权限原则从“应用”推进到“每一个任务实例”。 这张图把任务级授权拆成四道边界：TaskCredential 定义任务身份与授权上限，策略引擎判断具体行动是否在范围内，审批人只处理达到阈值的风险责任，ActionPermit 将最终许可绑定到一次具体执行。沿着这四道边界阅读，就能看清“拥有任务权限”为什么不等于“可以立即执行某个动作”。  这条链路把 Human-in-the-loop 变成风险驱动的责任断点，而不是每一步都弹窗确认。TaskCredential 证明任务“可以在什么边界内行动”，ActionPermit 证明“这一次具体行动可以执行”，二者不能互换；handoff 只能衰减权限，不能扩大权限；责任人对参数做任何编辑都会改变规范化提案，因此必须重新经过凭证验证、策略授权与风险分级。 审批等待不会冻结授权事实。无论人工批准还是策略自动通过，Runtime 都必须在签发许可前基于最新凭证主体与有效期、策略规则、资源属性、角色、数据敏感度、风险事实和剩余预算重新评估，并确认 approval 仍绑定当前 `action_hash`；任一条件变化都必须重新提议，不能沿用旧 approval。每次评估生成独立 `PolicySnapshot`，供 Action 的 `policy_ref` 固定引用。 Runtime 在规范化阶段稳定生成 `action_id`、`action_hash`、`op_key` 和 `request_hash`，并将工具、目标、参数固化为不可变 `request_ref`；这些标识与 `credential_id` 一同签入 ActionPermit。执行网关 Claim 时只原子校验绑定、占用许可并写入 Action Ledger Pending，唯一 `permit_id` 只能 Claim 一条 Action 记录。Claim 与 Pending 提交后才允许 dispatch；崩溃恢复时读取同一 `request_ref`，重算哈希并沿前图协议恢复同一 Action。业务端仍以 `op_key` 和请求载荷保证幂等，Unknown 期间保持 Claimed，直到权威终态才收口为 Completed 或 Cancelled。 第四个难题是上下文治理。 许多团队把 Agent 记忆理解为“把更多历史塞进上下文窗口”。但生产系统真正需要的不是无限记忆，而是可治理的上下文。Runtime 必须知道每一段信息从哪里来、何时获取、是否过期、谁有权使用、能否被发送给外部模型，以及它影响了哪些决策。 上下文不应只是一串文本，而应是带来源与权限的对象。一次任务使用的上下文集合，需要形成 Context Ledger。事故发生后，团队才能判断问题来自模型推理，还是来自错误、过期或越权的数据。 第五个难题是 Human-in-the-loop。 很多产品把 Human-in-the-loop 做成“每一步弹窗确认”。这看似安全，实际上会让用户沦为 Agent 的点击操作员。审批过多会导致疲劳，用户最终不再认真判断；审批过少又会留下风险缺口。 更好的方式是风险闸门。Runtime 根据行动类型、数据敏感度、金额、影响范围、可逆性和模型置信度计算风险等级。低风险读取自动执行；可逆写入在策略允许下执行并保留回滚；高影响动作要求指定角色审批；不可逆或监管敏感动作则需要双人复核或直接转人工。 审批界面也不能只显示一句“是否允许”。它应展示行动主体、目标系统、关键参数、预期影响、使用证据、回滚方案和未执行的替代选项。人类需要做真正的风险判断，而不是为模型行为背书。 第六个难题是完成语义。 模型说“完成了”没有任何系统意义。工具返回 200，也不代表业务目标已经实现。Runtime 需要把技术完成和业务验收分开：工具调用成功、产物生成、规则校验通过、业务负责人接受，是不同阶段。 只有当验收标准被满足，任务才能进入 `Accepted`。否则，它可能需要修订、补充证据、回滚或升级给人类。这一步把 Agent 从内容生成器变成了责任系统。 ## 六、Runtime 会成为新的产业控制点 为什么 Runtime 可能比模型层形成更稳定的竞争位置？因为模型可以被替换，而 Runtime 会逐渐沉淀组织如何完成工作。 一个企业使用 Agent 半年后，真正有价值的资产不只是 Prompt，而是任务模板、工具契约、权限策略、审批规则、失败案例、补偿流程、验收标准、历史轨迹和评估数据。这些内容共同构成组织的执行知识。 谁拥有这些数据，谁就拥有 Agent 系统的控制面。 未来的竞争大致会出现三条路线。 第一条是模型厂商向上构建完整栈。优势是模型、工具调用、上下文和运行接口紧密集成，默认体验最好；风险是企业的任务状态、追踪和治理能力可能与单一模型生态绑定。 第二条是云平台与工作流基础设施向 Agent 延伸。它们擅长计算、队列、身份、网络、持久化和可观测性，更理解长任务与故障恢复；挑战是传统确定性工作流如何容纳模型动态决策，以及如何表达意图、证据和验收等语义。 第三条是独立 Agent Runtime。它强调模型中立、跨云部署、统一治理和可移植任务协议。它最有机会成为企业级控制层，但也最容易陷入“又一个 Agent 框架”的同质化竞争。真正的差异不会来自节点数量，而会来自执行语义是否可靠、治理模型是否完整、生产运维是否成熟。 协议也会改变竞争边界。MCP 正在标准化模型如何发现和调用工具，A2A 正在标准化 Agent 如何发现彼此、管理任务状态和传递产物。当连接协议逐渐开放，Runtime 的价值将进一步集中到协议没有替企业决定的部分：身份映射、权限收敛、状态持久化、策略执行、风险审批、结果验收和责任追踪。 因此，未来真正有价值的平台，不一定是“支持最多模型”的平台，而可能是最早成为企业 Agent 执行记录系统的平台。 它保存的不只是聊天记录，而是：谁授权了什么任务，Agent 基于什么证据，在什么权限下采取了哪些行动，产生了什么结果，谁最终接受了结果，失败后如何恢复。 模型记录智能，Runtime 记录责任。后者一旦进入企业核心流程，迁移成本和组织依赖都会更深。 ## 七、企业应该如何开始建设 Agent Runtime 企业不需要一开始就建设一个覆盖所有场景的通用平台。Agent Runtime 最容易失败的方式，就是在没有真实任务之前，先抽象出一个宏大的多 Agent 操作系统。 更有效的路径，是从一个价值明确、风险可控、结果可验收的任务开始。 第一步，选择真正的任务，而不是选择一个聊天入口。 合适的起点通常具备几个特点：任务频率较高；输入和结果可以被结构化；当前流程包含大量信息整理与跨系统搬运；错误可以被发现和补偿；存在明确的业务负责人。客户工单分流、销售线索研究、合同要素抽取、运营异常归因、内部知识维护，通常比自动付款或直接修改生产配置更适合作为第一批场景。 第二步，为任务建立 TaskContract。 TaskContract 不需要复杂，但至少应包含目标、发起人、授权人、责任归属、验收责任人、输入范围、允许工具、风险等级、预算、截止时间、验收标准和失败处理方式。自然语言可以表达目标，却不能独自承担系统契约。 第三步，把工具分级。 所有工具都应标注读取或写入、是否产生外部副作用、是否可逆、是否支持幂等、需要什么身份、数据敏感度和默认审批策略。工具越多并不代表 Agent 越强；未经治理的工具越多，意味着攻击面和事故半径越大。 第四步，先建立事件日志，再追求复杂自治。 团队必须能看到每个任务的状态变化、模型调用、工具请求、策略判断、人工决定和产物版本。没有可观测性时，增加规划、自我反思和多 Agent，只会让失败路径更长、更难定位。 第五步，把人工介入放在风险断点，而不是所有步骤。 先根据可逆性和影响范围定义简单风险矩阵，再逐步加入数据敏感度、金额、置信度和历史异常率。人工审批的目标不是证明系统“有人看着”，而是在关键责任转移发生前，让合适的人获得充分信息并作出决定。 第六步，用业务指标评估，而不是只看模型指标。 最值得持续跟踪的指标包括： - `task_success_rate`：任务达到技术完成状态的比例； - `accepted_output_rate`：产物通过业务验收的比例； - `human_intervention_rate`：任务需要人工介入的比例； - `rollback_rate`：已执行行动需要撤销或补偿的比例； - `policy_block_rate`：被策略阻断或升级审批的提议比例； - `confirmed_policy_violation_rate`：已执行行动经审计确认违规的比例； - `trace_completeness`：关键决策和行动具有完整证据链的比例； - `cost_per_accepted_task`：每个被接受任务的综合成本； - `time_to_accepted_result`：从任务创建到业务接受的时间。 其中，`cost_per_accepted_task` 比单次模型调用成本更接近真实经济性。便宜模型如果导致更多返工、审批和失败，未必更便宜；昂贵模型如果显著提高一次验收通过率，整体成本反而可能更低。 第七步，在扩大自治范围前验证恢复能力。 团队应该主动进行故障演练：在工具调用前后终止进程、让外部 API 超时、让凭证过期、让审批等待数天、升级模型版本、重复投递同一事件。只有当任务能够恢复且不会重复产生副作用，Runtime 才具备承接更关键流程的资格。 一条务实的成熟度路线是：先让 Agent 提议，人类执行；再让 Agent 执行可逆动作，人类验收；随后让低风险任务自动完成，高风险断点审批；最后才考虑跨系统、长周期和多 Agent 的自主执行。 自治不是一个开关，而是一组可以逐步扩大的权限边界。 ## 八、Agent 的下一个阶段，是成为可管理的执行单元 回到最初的问题：Agent 的下一个阶段是什么？ 不是单纯拥有更长上下文，不是把更多工具接进模型，也不是让十个 Agent 在群聊里互相讨论。这些能力都会继续进步，但它们仍然属于“更会做”的范畴。 真正的下一阶段，是 Agent 开始“能够承担”。 承担一个任务，意味着它拥有稳定的任务身份，知道目标和边界；能够在长时间运行中保存状态，在故障后恢复；能够以受限身份访问上下文和工具；能够在风险断点请求授权；能够为关键行动留下证据；能够区分产物生成与业务验收；也能够在失败时重试、补偿、回滚或把责任交还给人类。 这就是 Runtime 的意义。 它不是为了让 Agent 看起来更自主，而是为了让自主性变得可控。它不是替模型增加一点编排，而是为模型的非确定性建立一套确定的责任边界。 未来，我们可能会把 Agent Runtime 类比成 AI 时代的 Kubernetes、工作流引擎或者操作系统。但这些比喻都只说对了一部分。Kubernetes 管理计算单元，传统工作流管理预定义流程，而 Agent Runtime 管理的是带有意图、权限和责任的行动。 它的一级对象应该是 Task，而不是 Conversation，也不是某个固定 Agent。Agent 可以更换，模型可以升级，工具可以演化，对话可以继续，但任务的目标、授权、状态、证据和验收必须稳定存在。 当 Runtime 成熟以后，企业选择模型会更像选择一种可替换的计算能力。不同任务可以调用不同模型，同一个任务也可以在成本、速度与推理质量之间动态选择。但无论模型如何变化，任务都在同一套权限、状态、审计与责任系统中运行。 模型决定 Agent 能走多远，Runtime 决定组织敢让它走多远。 Agent 的下一个阶段，不是成为一个更像人的聊天机器人，而是成为一种新的、可被组织信任和管理的执行单元。而围绕这种执行单元建立的 Runtime，将很可能成为 AI 应用真正的基础设施，也是下一轮产业竞争最值得关注的战场。 ### 参考资料 - [OpenAI Agents SDK：Running agents](https://openai.github.io/openai-agents-python/running_agents/) - [LangGraph：Overview](https://docs.langchain.com/oss/python/langgraph/overview) - [Agent2Agent Protocol：Specification](https://a2a-protocol.org/latest/specification/) - [Model Context Protocol：Tools](https://modelcontextprotocol.io/specification/2025-11-25/server/tools) - [Dapr Workflow：Architecture](https://docs.dapr.io/developing-applications/building-blocks/workflow/workflow-architecture/)