过去两年，Agent 最容易被感知的能力，是对话、调用工具、生成代码。但当 Agent 真正进入企业生产系统，问题很快从“它能不能做”变成“它能不能可靠地做”。
一次任务可能涉及多个角色、多个系统和不同权限：谁负责判断，谁可以执行，谁来验证？如果工具调用失败、执行对象错误、系统状态改变，又该如何恢复？
当 Agent 开始接触代码发布、金融数据、安全运维、能源调度等高责任场景，仅仅让模型“更聪明”已经不够。从世界人工智能开源大赛（GOAI）「新智基座 Agent Infra」15 个决赛项目看，Agent 基础设施正在出现一个明显转向： 竞争重点正从模型能力，走向系统能力 。
多 Agent 协作、权限隔离、证据链、Human Gate、独立验证、状态回读、重规划与回滚，正在成为越来越多项目共同面对的工程问题。透过这些项目，可以进一步看到 Agent Infra 正在形成四条相对清晰的技术演进主线。
趋势一：从“生成答案”走向“交付结果” Agent 工程化的第一个变化，是系统不再把“模型已经输出”视作任务结束。 DataFlow-Agent 面向数据工程，把自然语言需求转化为可编辑、可执行、可追溯的数据流水线。
系统优先复用已有处理算子，在能力不足时再生成补充能力，最终交付的不是一段一次性代码，而是包含 DAG、运行记录和数据出口的可维护流程。 CodeNotary 则把这一问题推进到 AI 编程场景：代码生成之后，是否足以进入正式交付？
项目用十四状态组织分析、创作、盲测、争议、门禁与发布等环节，并将代码作者与独立测试职责分离。最终不是让模型宣布“代码可用”，而是由交付链给出 RELEASED 或 REJECTED 判定。
两类项目指向同一个变化： 模型输出正在由“最终结果”退回到“流程中间产物”。真正进入生产系统之后，Agent 不仅要生成内容，还要把内容转化为能够执行、检查、复用和继续流转的工程对象。
衡量 Agent 的标准，也由“回答得对不对”，进一步变成“任务有没有真正完成”。趋势二：多 Agent 正在从“角色扮演”走向职责协作 多 Agent 并不等于多开几个模型窗口。
CyberGuard 把安全事件处理拆成分诊、情报、取证、遏制、验证、恢复和审计七类角色。不同角色承担不同责任，高风险操作需要绑定具体人工审批，独立复测如果发现问题，还可以推翻此前结论并重新规划。
“总工之眼”把工程设计企业的专业协作引入 Agent 系统：不同专业智能体分别审查，独立角色核验证据，跨专业冲突则进入 Human Gate 交由人工判断。 RepoMesh 则通过组织 Leader、仓库 Leader 与 Worker 以及跨仓 DAG 组织任务依赖；OrgRebase 进一步关注组织规则本身的安全变更，让职责、权限和规则调整也进入受控流程。
这些设计说明，多 Agent 系统的关键已经不是“几个 Agent 能不能互相讨论”，而是能否建立 清晰的任务关系、责任关系和权限关系。谁规划、谁执行、谁验证；上下文如何传递；冲突如何仲裁；失败之后由谁接手——这些问题开始决定多 Agent 系统能否真正运行。
Agent 由此越来越像一个“数字化组织”，而不仅是一组模型调用。趋势三：从“能执行”走向“受控执行” 当 Agent 获得越来越多工具调用能力之后，新的问题随之出现： 有能力执行，并不等于有权执行；动作执行了，也不等于结果成立。
OpsKeeper 将运维事故中的调查、修复、验证明确分权：调查者保持只读，修复者取得精确授权后才能执行，恢复状态再由独立验证者确认；FinFlux 则把类似的控制机制用于金融数据变更，对存在风险或证据不足的任务进行暂停或阻断。 MergePilot 同样把审查者、修复者和验证者分离，并根据普通、高危、严重变更设置自动完成、人工放行和直接阻断等不同路径。
店巡 Agent 则将“设备状态”和“商品状态”分开管理，由独立审计角色重新检查设备、批次、工单和审批；OpenXnet 进一步把白名单、审批、独立验证等机制扩展到跨平台运维操作。三个场景虽然完全不同，却形成了同一条原则： 提出方案的人不一定拥有执行权，执行任务的人也不能成为自己唯一的验证者。
当 Agent 进入安全、研发、财务和实体运营场景，权限控制和独立验证正在由外围功能变成基础设施的一部分。趋势四：失败恢复开始成为 Agent 的核心能力 Demo 最容易展示的是成功路径，生产环境真正考验的却是失败之后怎么办。
EnergyMesh-Agents 把智能体与确定性优化器结合：Agent 负责识别变化和协同，优化器负责具体调度与安全边界，执行出现偏差就重新规划或回退；RevGuard 则在财务结算任务中引入失败后的反向冲销和独立验证，让错误执行具备恢复路径。 SceneGuard 为三维资产建立受控修复和发布门禁：原件只读，修复范围受白名单约束，独立复验失败后必须回滚，并保持零发布。
DevOrbit 则把线上缺陷取证、定位、补丁生成、验证、灰度发布和复盘串成状态化流程。证据不足时继续补证，补丁失败时根据反馈重新修复，灰度阶段指标退化则按规则回滚。
这些项目开始把过去 Demo 中容易被忽略的问题放到中心位置：工具失败怎么办？状态改变怎么办？
验证失败怎么办？执行了一半怎么办？
因此，一个真正可用的 Agent 系统，必须具备的不只是“做事能力”，还包括 补证、重试、重规划、阻断、补偿和回滚能力。 Agent Infra 正在成为模型与真实系统之间的中间层 从 15 个决赛项目整体来看，新智基座呈现出的并不是某一种单一技术路线，而是一套逐渐成形的 Agent 工程化逻辑：从任务交付，到角色协作；从权限控制，到失败恢复，开发者正在尝试把模型能力真正嵌入可持续运行的生产系统。
一端是模型负责理解、推理与规划，另一端是数据库、代码仓库、业务系统和执行工具；真正决定 Agent 能否落地的，是二者之间的任务编排、Skill、权限、状态、证据、验证和恢复机制。这并不意味着所有 Agent 都需要复杂架构，而是任务风险越高、流程越长，对系统工程的要求就越高。
未来 Agent Infra 真正要解决的，是如何把模型的概率性能力，转化为 可执行、可控制、可验证、可恢复的系统行为。这也是世界人工智能开源大赛（GOAI）希望推动的变化：不只展示一个 Agent“能做什么”，更要验证它在真实流程、真实权限和真实失败面前还能不能把事情做完。
从“会聊”到“会干活”，AI 正在迈出从 Demo 走向真实世界的重要一步。 9 月 22 日至 23 日，世界人工智能开源大赛（GOAI）总决赛及 GOAI DAY 将在杭州举行。
「新智基座」15 支决赛团队将进入最终比拼。谁能真正把模型能力变成系统能力，值得继续观察。
（新智基座 赛道 15 支决赛入围团队，排名不分先后）