第 29 章 GOAI Agent Infra 赛道：多 Agent 协同的前沿实践探索¶
第25-28章记录的是企业在生产环境中已经跑通的实践。本章记录的是，当一批开发者被放在同一道命题下、面向企业内部真实的高风险流程去设计多 Agent 系统时，他们会做出什么选择。
2026 年 GOAI 世界人工智能开源大赛 Agent Infra 新智基座赛道给出的命题是「企业级复杂任务下的多 Agent 基础设施与协同系统，推动 Agent 从 Demo 走向 Production」。赛道对参赛作品提出了明确的工程要求：系统中至少包含三个职能不同的 Agent，以 AgentTeams 作为多 Agent 协同的设计基点，并将 Skill 作为能力封装的必选项；作品需要覆盖从任务输入、任务拆解、上下文传递、工具调用、结果验证、执行证据沉淀、审批与回滚，直到经验沉淀的完整链路。评审从五个维度展开：场景价值与行业可复制性、多 Agent 协同与自主闭环、Skill 工程体系与生态复用、工程落地运行验证与安全可审计、开放开源贡献。
赛道采用开放式选题，自 2026 年 7 月启动，共吸引7802支队伍、8346名选手报名参赛，提交作品847个，覆盖全球 38 个国家/地区。历经初赛与复赛层层选拔，于 9 月产生 15 项决赛晋级作品。本章呈现的就是这 15 项作品：它们各自选择了什么场景、如何组织多个 Agent 的分工与权限、在赛道要求之外又做出了哪些值得记录的工程判断。
29.1 参赛结构：产业、高校与独立开发者同台¶
15 支决赛队伍由 30 位选手组成，覆盖 11 所高校与 7 家企业及科研机构。按参赛主体划分，高校队 7 支、企业与科研机构队 5 支、个人开发者队 3 支，比例约为 5:3:2。
两个结构特征值得记录。
一是成绩不由机构背景决定。 三类参赛主体的平均成绩相当接近，前五名中高校、企业、个人开发者各占其位。三支个人开发者队伍全部进入决赛，其作品分别面向 IT 运维、金融数据治理与跨平台故障恢复——都是需要相当行业经验才能提出的命题。
二是跨单位组队成为常态。 15 支队伍中有 6 支为跨单位组合，占四成。其中「逐光」队由浙江吉利控股、OPPO 两家企业的工程师组成，「星河引擎」队来自昆山杜克大学、深圳大学与上海大学，「helloworld」队则由高校、科研机构与独立开发者共同构成。产业侧的 8 位选手分散在 7 家单位，除浙江移动创新研究院为两人外均为单人报名，是工程师带着本岗位的实际痛点参赛。
29.2 场景版图：11 个互不重合的领域¶
15 项作品涉及 11 个互不重合的行业或技术领域，没有出现集中于同一场景的扎堆现象。
| 分类 | 行业或技术领域 | 作品数 | 对应作品 |
|---|---|---|---|
| 垂直行业（5 项） | 能源电力 | 1 | EnergyMesh-Agents |
| 金融 | 1 | FinFlux | |
| 建筑工程设计 | 1 | 总工之眼 | |
| 零售连锁 | 1 | 店巡Agent | |
| 数字内容（游戏 / XR / 电商） | 1 | SceneGuard | |
| 企业职能（2 项） | 企业运营与组织治理 | 1 | OrgRebase 知变 |
| 财务与渠道佣金结算 | 1 | RevGuard | |
| 研发与 IT（8 项） | 软件工程与交付 | 4 | CodeNotary、MergePilot、RepoMesh、DevOrbit |
| IT 运维与故障恢复 | 2 | OpsKeeper、OpenXnet | |
| 网络安全运营 | 1 | CyberGuard | |
| 数据工程 | 1 | DataFlow-Agent | |
| 合计 | 11 个领域 | 15 | — |
其中 5 项（33.3%）进入垂直行业的专业流程，8 项（53.3%）服务研发与 IT 自身，另有 2 项属于可跨行业平移的企业职能场景。
一个共同点贯穿全部 15 项：它们选择的都是企业内部的高风险流程——安全处置、生产变更、资金结算、食品安全、工程出图、数据准入。这类流程的共同特征是，一次错误动作的代价远高于一次响应延迟，因此对 Agent 的要求不止于「能完成任务」，还包括权限是否受控、结果是否可验证、出错后能否退回。这也解释了为什么 15 项作品在架构上都把「谁来执行」与「谁来确认」分给了不同的角色。
29.3 九项作品的设计与价值¶
以下九项作品覆盖了全部 5 个垂直行业领域，以及财务结算、数据工程、网络安全、IT 运维四类横向场景，是这批探索中场景纵深与工程设计都较为完整的一组。
29.3.1 EnergyMesh-Agents：让能源调度从“自动优化”走向“可信自治”¶
团队 超境创新｜李如枫（深圳维境拟生）、夏超 领域 能源电力
作品使用真实公开数据完成验证，以原有能源管理系统的策略作为对照基线，并提供了独立复算入口。运行链路可将负荷、光伏出力、储能状态与分时电价收敛为一份覆盖全天的调度计划，人工批准、模拟执行、结果回读与回退均有完整记录。
工业园区与算力中心需要协调用电、光伏、储能和生产负荷。现有 EMS 已具备监测、控制和部分优化能力，但生产计划、设备状态和运行约束持续变化时，系统还需要完成状态确认、计划更新、独立复核和授权执行。
EnergyMesh 在现有 EMS 与确定性优化器之上增加 Multi-Agent 治理层。感知角色确认现场状态，规划角色调用优化器生成计划，审计角色独立检查关键约束并可拒绝失效计划，执行角色只执行已授权版本。实际功率曲线和成本计算由确定性优化器完成，BMS、PCS 及现场保护系统继续承担设备级控制与安全保护。
项目已跑通状态快照、计划版本、独立审计、人工审批、模拟执行、结果回读与回退。作品基于公开园区运行数据、数字孪生和模拟设备完成验证，并通过 Baseline 与 Optimization 对照调度结果。EnergyMesh 形成从状态变化、计划生成、复核授权到执行回读的完整闭环，为工业能源系统中的受控自主执行提供治理层。
29.3.2 FinFlux：金融数据变更的语义准入闸门¶
团队 dovic_cn｜李瑞（独立开发者） 领域 金融
交易与行情数据的字段定义与统计口径频繁变更。最危险的情形不是接口报错，而是接口正常返回、数据结构校验通过，业务含义却已经改变——这类漂移会沿着数据血缘一路传导进计算、风控与分析环节，直到结果出错才被发现，而此时影响范围已经难以界定。
作品把数据变更的准入做成一条责任链：三类 Agent 分别负责证据采集、影响评估与结论签署，五个核心 Skill 承担资产画像、血缘追溯与口径比对等可复用能力，全过程沉淀不可篡改的证据。准入结论不是简单的通过或不通过，而是放行、暂缓、拦截三条路径，每条路径都要说清依据：为什么可以放行、在等什么条件、因为哪一处漂移而拦截。一次完整运行会把三个角色的产物、模型调用记录与人工决定关联在一起，事后可以逐步回放。
作品以期货行情资产完成了完整链路验证，三条准入路径均有可复现的运行记录，人工签署环节与证据链均可回溯。
29.3.3 总工之眼：工程设计企业的多专业智能会审¶
团队 晨之初晞｜李博（北京伯禹规划设计）、王娜（独立开发者） 领域 工程设计
设计企业在出图前需要组织多专业会审。真正的难点往往不在某一个专业能否独立发现问题，而在于多个专业条件放在同一个工程对象上后，能否同时成立。各专业分别审查合规，并不意味着项目整体不存在冲突；跨专业条件遗漏、审查依据不完整，最终往往会转化为返工、沟通成本和工期风险。
“总工之眼”基于 AgentTeams 构建设计企业的多专业智能会审流程。系统由协调角色组织任务，将可追溯的工程事实与审查依据分派给多个专业审查角色处理，再汇总跨专业关系，由独立的证据核验角色对关键结论进行复核。
其中有一项重要设计：跨专业分歧不做平均处理。 当不同专业对同一工程对象形成不一致意见，或现有证据不足以支持结论时，系统不会强行折中或替代专业人员作最终判断，而是保留不同专业意见及其依据，提交真人总工程师复核、裁决并留痕。
项目已经形成真实 AgentTeams 运行记录，可追溯多专业审查、跨专业关系识别、证据核验、异常恢复和人工技术裁决等过程；专业结论、运行事件与人工决定能够关联在同一条证据链上，为后续复核和责任追溯提供依据。
29.3.4 店巡 Agent：设备修好不等于商品安全，独立验证每一次关键处置¶
团队 逐光｜夏志强（浙江吉利控股）、马荣（OPPO） 领域 零售连锁 / Agent Infra
门店冷柜异常的处理不只是“告警后报修”。从停售遏制、故障诊断、维修处置，到商品批次判断和恢复销售，往往涉及多个系统与角色。最容易出现的问题是：维修工单已经完成、设备温度恢复正常，但柜内商品是否仍然安全，并不能因此直接得出结论。
店巡 Agent 将这一过程设计为多智能体执行闭环：异常发生后先停售遏制，再进入诊断与处置；设备恢复与商品安全是两条独立确认路径。系统的核心约束是执行者不能自行确认自己的处置成功，独立 Auditor 必须重新查询设备状态、商品批次、维修工单与审批记录，只有两条路径都通过，才允许恢复销售并关闭事件。
作品覆盖六类正常与异常场景，包括设备故障、传感器误报、审批超时和维修查询异常等。对于证据不足、处置未完成或商品仍存在风险的情况，系统继续保持停售并阻止事件关闭，是设计中的正确结果，而不是流程失败。
29.3.5 SceneGuard：三维资产的质量门禁与受控修复¶
团队 星河引擎｜顾梓洋（昆山杜克大学）、刘志豪（深圳大学）、王峥睿（上海大学） 领域 数字内容
游戏、XR 与电商团队需要批量发布三维资产。格式、材质、网格与贴图缺陷往往在导入或上线后才暴露，造成导入失败、渲染异常与性能退化；而修复过程依赖技术美术在设计工具中手工处理，难以追溯与复现。
作品由一个协调角色拆分任务，四类执行角色分别负责审计、制定修复计划、执行修复与回归验证，各自持有独立的权限边界。资产处理遵循三条约束：原始文件只读，修复动作限定在白名单范围内，每一步留存检查点。高风险操作先行暂停、经批准后续跑；回归验证未通过则自动回滚，并保持零发布状态——宁可不发布，也不发布未验证通过的资产。
作品在代码层面已经打通从缺陷检出、受控修复到回归复验的完整主链，具备内容寻址的证据记录与发布结论，一份存在缺陷的资产可以走完修复、复验与可追溯发布的全过程。
29.3.6 RevGuard：渠道佣金异常的自动核算与治理¶
团队 helloworld｜任宇帆（西安工业大学）、宋传承（中国科学院信息工程研究所）、乐达（独立开发者） 领域 财务与渠道佣金结算
渠道佣金结算涉及订单、合同、回款、激励政策、渠道等级与结算台账，分散在多个系统中依靠人工核对。最常见的差错不是算错公式，而是取用了错误的政策版本、弄错了等级生效的时间点，或者漏算了某个激励组件。少付会引发渠道争议，多付会产生追偿成本，而手工改账往往还会丢失审计依据。
作品由一名 Leader 与九类 Worker 分工完成受理、取证、政策匹配、金额计算、台账写入与结果验证。最值得记录的判断是金额不由模型产生：计算交给专用的十进制规则引擎按政策条款精算，模型只负责组织流程、匹配政策版本与解释差异，不直接触碰数字。涉及台账写入的高风险动作须持有审批令牌方可执行，写入失败则走反向冲销，最终由独立的验证角色复核账目。
作品以八个标准用例完成验证，覆盖政策版本错配、等级时点冲突、激励组件漏算等典型佣金异议，人工审批环节、台账写入、回滚与运行轨迹均有完整记录。
29.3.7 DataFlow-Agent：让需求直接变成数据流水线¶
团队 PKU-DCAI｜强美伊、梁昊、徐畅（北京大学） 领域 数据工程
AI 数据工程与算法团队需要持续生产训练数据。AI 虽然可以按需求生成处理脚本，但脚本难以沉淀、难以修改、难以稳定复跑，依赖关系也不透明；一旦运行失败，往往说不清是哪一个处理环节失效。
作品把需求解析、算子检索与实际执行分派给不同的 Agent，并确立了一条明确的优先级：先在平台已有算子中检索复用，确实缺少能力时才生成新算子，避免每次从零编写完整脚本。Agent、可视化界面与后端围绕同一份流水线状态协作，任何修改前后都要经过校验。最终交付的不是一段对话答案，而是一条可编辑的流水线、完整的运行记录与明确的数据出口。
作品已展示可视化编辑界面、算子与流水线管理、保存运行与结果追踪等能力，一条流水线可以经历生成、人工修改、执行与再次运行的完整过程——让非平台专家也能搭起一条能保存、能修改、能复跑的数据流水线。
29.3.8 CyberGuard：让每一步安全处置都可授权、可回滚¶
团队 逆律成调｜吴林斌、陈培琛（杭州电子科技大学） 领域 网络安全运营
安全运营团队每日面对海量入侵告警，而能够支撑处置决策的证据相当有限。安全动作本身又很「重」：未经充分授权的封禁、隔离或账号禁用，可能造成业务中断与证据污染，影响的是正在运行的生产系统。
作品设置七类职能角色，分别承担分诊、情报、取证、遏制、验证、恢复与审计。两处设计值得记录：一是高风险动作与人工授权严格绑定——每次授权对应一个具体的处置提案与明确的目标对象，执行角色不能自行扩大权限范围；二是独立复测有权推翻上一轮结论，若发现处置目标有误，流程会退回规划阶段，重新走一遍授权。
作品提交了完整的运行记录，一次运行串起七个职能角色与四次人工审批，并完整演示了模型服务异常后的恢复、处置目标的修正、已执行动作的回滚以及两轮独立复测——一条高危告警可以收敛为有证据、有授权、有恢复状态确认的结案记录。
29.3.9 OpsKeeper：让生产操作留在授权范围内¶
团队 奔悦智维｜蒋幸（独立开发者） 领域 IT 运维与故障恢复
生产故障发生时，告警、定位、审批、修复与复盘往往散落在不同的人、群聊与控制台中。谁定位、谁批准、谁动手、谁确认恢复，通常不在同一条证据链上。修错目标、扩大影响范围，或者以「命令执行成功」冒充「业务已恢复」，都会把一次小故障拖成生产事故。
作品通过插件方式接入 AgentTeams，并把控制层与执行层分离：调查角色只做只读定位，修复角色须取得精确授权后才能执行，验证角色独立判断业务是否真正恢复。授权的精确性由一组标识共同保证——故障工单、处置提案、目标对象与具体指令必须全部匹配，任何一项不符即拒绝执行。
作品完整演示了一类数据库连接池耗尽故障的处置过程：先对错误的目标对象拒绝执行，再经人工批准后对正确目标重新派发，连接数归零、新的健康探针成功，全过程进入审计记录与故障时间线——错误目标不会被误操作，是这次演示重点验证的结论。
29.4 赛道要求之外的一致选择¶
赛道对参赛作品提出了明确的工程要求：至少三个职能不同的 Agent、审批与回滚机制、执行证据沉淀。因此角色分工与审批留痕在 15 项作品中普遍存在，这是命题设定的结果。更值得记录的是在赛道未作规定的地方，多支队伍给出了方向一致的答案。
一是执行者不为自己的结果签字。 赛道要求「结果验证」这一环存在，但没有规定验证由谁执行。多支队伍不约而同地把验证权从执行角色手中拿走：MergePilot 的修复角色不能为自己的修复签字，店巡Agent 的执行角色不能确认自己的处置，CodeNotary 让作者看不到盲测、测试者不接触实现，OpsKeeper 与 RevGuard 都设置了独立的验证角色。这些团队的场景差异极大，却都判断出同一件事——自证的验证结论没有价值。
二是授权精确到具体动作与目标。 通用做法是「高风险操作需要审批」，而多支队伍进一步把授权与动作本身绑定：CyberGuard 的每次审批对应一个具体提案与明确目标，OpsKeeper 要求工单、提案、目标与指令四项标识全部匹配，RevGuard 的台账写入须持有对应的审批令牌。这一步的意义在于，授权不再是一张可以复用的通行证，而是一次一用的具体许可。
三是关键计算不交给模型。 在结果必须精确的场景中，多支队伍主动缩小了模型的职责范围：EnergyMesh-Agents 把调度计算与安全边界交给确定性优化器，RevGuard 的金额由专用规则引擎精算，模型在两处都只负责组织流程与解释过程。这是一处清醒的判断——模型擅长处理语义与流程，不擅长承担必须精确的数值责任。
四是「拒绝」被设计成正确结果。 多支队伍明确地把不放行作为合法终态：店巡Agent 在处置未达标时保持遏制状态，SceneGuard 在验证未通过时回滚并保持零发布，MergePilot 对严重风险变更永久阻断，FinFlux 的拦截路径与放行路径同等完整。这些团队没有把「必须给出结论」当作系统的成功标准，而是承认在证据不足时停住本身就是正确输出。
五是一次运行留下可回放的完整证据。 多支作品都把「同一次运行内的角色协作、能力调用、人工决定与最终状态可关联、可回放」作为交付标准的一部分，而不是事后补写的日志。这让作品的验证方式从「演示一遍」变成了「可以复查」。
29.5 15 项决赛作品一览¶
| 序号 | 团队 | 作品 | 领域 | 定位 |
|---|---|---|---|---|
| 1 | PKU-DCAI | DataFlow-Agent | 数据工程 | 让需求直接变成数据流水线 |
| 2 | 超境创新 | EnergyMesh-Agents | 能源电力 | 让园区用电随电价与负荷自动重算 |
| 3 | 逆律成调 | CyberGuard | 网络安全运营 | 让每一步安全处置都可授权、可回滚 |
| 4 | helloworld | RevGuard | 财务与渠道结算 | 渠道佣金异常的自动核算与治理 |
| 5 | 奔悦智维 | OpsKeeper | IT 运维与故障恢复 | 让生产操作留在授权范围内 |
| 6 | 晨之初晞 | 总工之眼 | 建筑工程设计 | 多专业工程图纸的智能会审 |
| 7 | 逐光 | 店巡Agent | 零售连锁 | 门店设备与食品安全的双重闭环 |
| 8 | ARA | CodeNotary | 软件工程与交付 | 为 AI 生成的代码做发布公证 |
| 9 | dovic_cn | FinFlux | 金融 | 金融数据变更的语义准入闸门 |
| 10 | 分子 | MergePilot | 软件工程与交付 | 代码合并请求的风险分流与把关 |
| 11 | OriNodes | OrgRebase 知变 | 企业运营与组织治理 | 让组织规则变更安全落地 |
| 12 | 疯狂猫咪队 | RepoMesh | 软件工程与交付 | 跨多仓库交付的多 Agent 团队 |
| 13 | SynapXnet | OpenXnet | IT 运维与故障恢复 | 跨平台线上事故的统一恢复空间 |
| 14 | 星河引擎 | SceneGuard | 数字内容 | 三维资产的质量门禁与受控修复 |
| 15 | 钱塘舞士 | DevOrbit | 软件工程与交付 | 从线上缺陷到受控发布的研发闭环 |
29.6 这批探索留下了什么¶
这 15 项作品不是产品，多数还没有进入企业的日常生产。它们的价值在别处。
它们把多 Agent 协同的讨论推进到了具体场景。 关于多 Agent 架构的讨论长期停留在通用层面——如何拆解任务、如何传递上下文、如何让 Agent 互相通信。这批作品把同样的问题放进了 11 个互不重合的具体领域，得到的答案立刻变得具体：园区调度的难点是计算精度与安全边界，佣金结算的难点是政策版本与时间点，门店食品安全的难点是两条独立的确认路径必须都通过。多 Agent 系统的设计难点不在协同机制本身，而在场景对「正确」的定义。
它们验证了高风险流程可以交给 Agent，前提是权限设计到位。 15 项作品全部选择了企业内部的高风险流程，这在一年前还是被普遍规避的方向。它们给出的共同答案不是提升模型能力，而是重新组织权限：执行与验证分离、授权绑定到具体动作、关键计算交给确定性引擎、拒绝作为合法终态。这四条都不需要更强的模型，需要的是更清楚的工程设计。
它们展示了一批可迁移的工程模式。 OpenXnet 用同一套控制面覆盖三个不同平台的故障场景，只替换平台工具、阈值与场景能力；SceneGuard 的原件只读加白名单修复，同样适用于任何「不能损坏原始数据的受控修改」场景；FinFlux 的三路径准入结论，适用于所有需要在变更进入生产前做判断的环节。这些模式的适用范围明显超出了作品各自的原始场景。
从 2026 年 7 月的报名到 9 月的决赛，这批开发者用两个月时间完成了一轮密集的探索。他们中有企业工程师带着本岗位的痛点参赛，有高校团队从零搭起完整工程链路，也有独立开发者独自完成了面向企业级场景的系统设计。这批探索的意义，不在于其中某一项作品最终走得多远，而在于它们共同证明了一件事：把 Agent 放进企业真正重要的流程里，这条路是走得通的，而且已经有人走出了具体的方法。