多Agent零人工运维系统设计复盘：4个Agent、7个Skill与9条工程判断

过去半年里，关于多Agent的优质文章确实不少——有讲框架架构的，有讲协作范式的，也有讲评估方法论的。读下来能明显感觉到这个领域在快速沉淀，几位老师的输出都很扎实，从中获益不少。

但读多了之后，有一个小小的感受：大家把“应该长什么样”讲得越来越清楚，但“实际做起来会撞到什么”讲得还不够多。真正把一个多Agent系统从想法推到能演示、再往可信闭环上推的过程里，那些不太性感的工程判断——分工到几个Agent合适？Skill的边界怎么定？Mock数据和真实数据的契约怎么对齐？动作的风险等级怎么切？——反而是最容易被跳过、也最容易在后面反噬的部分。

正好GOAI世界人工智能开源大赛·新智基座Agent Infra赛道立了一个非常清晰的命题：让多Agent从Demo走到Production。借这个机会自己先动手做了一个刻意做小的多Agent Demo，叫OpsPilot Zero，算是抛砖引玉——把“最小可信闭环长什么样”这一步做透明，不藏方案、不藏权衡、也不藏Demo承认自己做不到的地方，让准备参赛或者正在做类似系统、但又没有这块经验的同学，能快速上手，也有一个具体的参照物去校准自己的方案。

场景选的是运维自愈：从客诉进来到生成事故报告并执行低风险修复，全程不需要人工介入。这个场景的好处是风险光谱够宽、证据来源够多、成功信号够明确，容易把多Agent协作的几个关键工程问题都暴露出来。

这篇文章不贴代码。它讲的是在做这个Demo的过程中想通的9条工程判断，以及为什么这9条判断决定了一个多Agent系统能不能扛真实业务。

这个Demo到底做什么

场景是我们熟悉的：杭州某电商公司在10:15收到客诉，用户反馈下单失败率升高、支付页面一直转圈。运维同学接到告警时，往往要在网关、应用、日志、Trace、配置变更、数据库慢SQL这几个数据源之间来回跳，手工把时间线拼出来、定位根因、想清楚该怎么改、然后小心翼翼地执行——即便有Runbook，从告警到恢复通常也要30-60分钟。

OpsPilot Zero想把这段流程压到5-10分钟以内，并且在低风险动作上做到零人工值守、高风险动作生成可审批方案。它的核心是四个职责清晰的Agent顺序协作：

• Alert Intake Agent负责把散落在客诉、告警、监控指标里的信号归并成一个可追踪的事故对象；
• RCA Analyst Agent关联日志、Trace、配置变更、慢SQL和Runbook，排序根因候选并给出证据链；
• Remediation Planner Agent生成修复计划、验证方案、回滚点，并给动作打上风险等级；
• Recovery Verifier Agent执行被允许自动化的动作，用探针验证恢复效果，产出事故报告。

Demo里两个mock场景一次跑完：一个是db.pool.maxSize被从50改成8导致的连接池打满，一个是慢SQL扫描过多行拖慢系统。两次事故都能在几分钟内跑出根因、置信度、回滚计划和恢复报告。

[配图 1：事故时间线图，标出10:15客诉到10:27恢复中间4个Agent的介入节点]

4个Agent是怎么分工的

先讲一个可能反直觉的事：Agent数量不是越多越好。最初的版本尝试过7个Agent，把归并、影响面分析、根因、数据缺口诊断、修复计划、执行、验证各拆一个。跑了几次之后压回到4个——原因是“Agent数量”和“任务粒度”是两回事，多出来的3个Agent只是把同一件事切成了更小的片段，没有真正带来协作意义上的价值。

判断分工的标准是“这一步产出的是不是一个可被下游Agent独立消费的语义对象”。

• Alert Intake输出的是“事故对象”（时间线、影响面、初始事实清单）——这是一个可以独立存在的东西；
• RCA Analyst输出的是“根因候选+证据链+置信度+缺失证据”——一个诊断结论；
• Remediation Planner输出的是“分级动作列表+回滚点+审批要求”——一个可执行方案；
• Recovery Verifier输出的是“执行结果+验证证据+恢复报告”——一个可回放的终态。

四个输出物之间是接力式的语义交付，每一个下游Agent都可以只看上游给的对象、不需要回读原始数据。这样的分工让每个Agent的边界都清晰，评审时也容易判断“这一步做没做到位”。

Skill层面同样做了收敛。7个Skill——alert-fusion、impact-mapping、log-trace-rca、data-advisor、remediation-plan、risk-guard、recovery-verify——每一个都对应一个具体的、可以独立评测的能力，而不是一段可有可无的Prompt。

[配图 2：4个Agent的协作关系图，标注每一步的输入/输出契约]

9条工程判断

下面是在这个Demo里想通的9条判断。它们不是通用真理，是从这个具体场景里长出来的、愿意为之辩护的选择。

判断1：Skill必须有Guardrail段，而不只是Prompt

Skill的价值在于“稳定”，稳定的关键不是提示词写得多好，而是它有明确的边界和拒绝条件。RCA Analyst用的log-trace-rcaSkill里有一条硬约束：不允许在只有一条独立证据的情况下给出根因结论，除非报告里明确标注“结论较弱”。这条约束让Agent在证据不足时会选择“承认缺口+建议采集”而不是“编一个听起来合理的原因”。

对赛道评审来说，这类Guardrail直接决定“系统工程水平”和“安全可信”维度的分数——评委看的不是Agent有多聪明，而是它做不对时会不会硬编答案。

判断2：至少两条独立证据才能给结论，比让LLM自由发挥更值

这条是判断1的具体化，但它值得单独列出来。多Agent系统最容易踩的坑就是“看起来什么都答得上来”——LLM不擅长承认不知道。在Demo里强制要求：任何根因结论必须至少引用两条独立来源的证据（比如日志+配置变更、Trace+数据库慢查询），并把每条证据的引用路径写进报告。

这个约束的代价是有时候Agent会返回“证据不足，需要补充采集”这样看起来不够利落的结论。但从工程视角，“我不知道”比“我猜是A”贵得多——后者会让运维同学基于错误结论去操作，损失远大于多花几分钟补数据。

判断3：风险分级不能只做二档，必须做L0-L3四档

第一版做过“可自动/不可自动”的二档划分，很快就发现不够用。真实运维动作的风险光谱远比这两档细：

• L0：只读诊断（查日志、拉指标、看配置），完全无副作用；
• L1：可回滚的低风险动作（配置回滚到已知良好值、重启无状态服务实例）；
• L2：需要灰度+人审的中等风险动作（扩容、切流量、修改生产配置）；
• L3：只生成方案不执行的高风险动作（建索引、变更数据库表结构、跨服务大规模改动）。

自动执行的边界画在L0和L1，L2/L3一律生成审批工单。这不是保守，是让“自动化率”和“可回滚性”这两个指标都能给出数字。评审Agent Infra类作品时，评委会问：“你说你能自愈，那你自愈的是哪个风险等级的动作？”——没有分级的作品答不上这个问题。

判断4：Mock工具和真实工具必须共用一套Schema

Demo里所有数据源都是mock的：mock监控、mock日志、mock Trace、mock配置、mock数据库慢SQL。但在设计的时候有一条硬要求——mock工具和后续替换成MCP Server或真实数据源接入时，输入输出Schema必须完全一致。

这条判断带来的直接好处是：Demo阶段用mock数据快速迭代Agent逻辑，到复赛阶段接入真实系统时不需要改Agent一行——只需要换掉工具层的实现。Demo与Production共用一套契约，这是多Agent系统能从赛场走到生产的核心工程判断。

判断5：Prompt / Skill / AgentSpec的内联版是过渡态，必须走Registry

Demo里所有Agent的Prompt、Skill定义、AgentSpec都是内联在文件里的。这在初赛阶段没问题，但它有两个致命限制：没法多版本共存、没法灰度发布、没法审计谁在什么时候改了什么。

真正到复赛/决赛阶段，这些东西必须进Registry——比如Nacos的AI资源治理控制面。Prompt Registry、Skill Registry、AgentSpec Registry、AgentTeams Spec Registry四层各自管理生命周期，才能支撑发布、灰度、回滚、审计的完整链路。内联版是给“能跑起来”用的；Registry版是给“能扛业务”用的。

判断6：报告里必须有“缺失证据”这一段

在incident_report.md的模板里强制加了两段：Evidence Chain（列出所有支持结论的证据）和Telemetry Recommendations（列出因为数据缺失而没能验证的假设、以及建议采集的指标）。

后者比前者更重要。它承认了这次诊断有哪些盲区、下次需要补什么数据。一个不会承认自己盲区的Agent系统，用得越久错得越离谱——因为运维同学会越来越相信它的结论，而它的置信度其实是被“用户不追问”惯出来的。

判断7：“跑一次”和“跑一万次”是两个完全不同的工程问题

Demo现在能跑通2个mock场景。这在赛道初赛是够的，但离生产还差得远。差在哪？差在评估集、稳定性、幂等性这三件事上：

• 评估集：需要Golden Case和Badcase数据集，每次改Prompt或换模型前跑一遍对比，防止越迭代越差；
• 稳定性：同一份输入跑十次，结论应该是一致的，而不是有时候说A有时候说B；
• 幂等性：Agent执行动作要有幂等键，网络抖动导致重复调用不能造成二次执行。

这三件事在Demo里都是空白，但它们是从“能演示”到“能上生产”必须补的三件套。赛道复赛/决赛的区分度大概率在这里。

判断8：Agent系统的可回滚性比自动化率更重要

如果一定要给“多Agent生产系统”选一个最重要的指标，会选可回滚性，而不是自动化率。理由是：自动化率决定运维效率的上限，可回滚性决定运维事故的下限。

一个90%自动化但没有回滚点的系统，一次误操作就能把线上打瘫；一个60%自动化但每一步都可回滚的系统，即便出错也能在几秒内恢复。Demo里给每个L1动作都强制附带回滚点，L2/L3动作直接不执行——这不是保守，是承认“多Agent系统还处在‘我们信任但需要证据’的阶段”。

判断9：这个Demo敢开放，因为它承认自己的局限

这条不是技术判断，是做这个Demo时想清楚的一件事。多Agent领域最缺的不是漂亮的架构图，是敢把不完美的方案摆出来的实践者。

OpsPilot Zero有一堆局限——数据是mock的、Skill是内联的、评估集是空的、只在单一云环境跑过、没有真实业务流量验证。这些都写在文档里。因为相信：一个承认自己边界的Demo，比一个假装什么都能做的Demo，工程价值大得多。

一份Agent生成的报告长什么样

上面讲了这么多设计判断，最直观的验证是看它到底产出什么。下面是Demo跑连接池耗尽场景时RCA Analyst和Recovery Verifier联合生成的事故报告（节选）：

[配图 3：incident_report.md截图，圈出以下几个关键段落]

从报告结构可以看到几件事：

• Incident Summary段给了完整的事故时间线，每条事件都有具体时间和来源服务；
• Root Cause段给出根因db_pool_exhausted、置信度0.91、以及三条独立证据（日志、指标、配置变更），符合“至少两条独立证据”的硬约束；
• Remediation Plan段列出动作rollback_config，标注风险等级L1、自动执行yes、并给出回滚点，符合“每个L1动作都必须有回滚点”的判断；
• Execution And Verification段贴出探针验证结果和恢复后的关键指标；
• Telemetry Recommendations段主动列出“这次诊断因为缺什么数据而没能验证什么假设”——这是判断6的直接体现。

这份报告的信息密度、证据链完整度、以及主动承认盲区的姿态，代表了一个多Agent系统在“最小可信闭环”这个标准上应该达到的水平。

Demo承认自己不足的地方

按照判断9的原则，把OpsPilot Zero目前的局限也写在这里：

• 数据全是mock——真实的日志/Trace/慢SQL数据形态更复杂，噪声更大，Agent面对真实数据的表现需要重新评估；
• Spec全是内联——没有Nacos Registry，无法支撑多版本、灰度、审计；
• 没有评估集——目前只有2个场景跑通，Golden/Badcase集合是空的，版本对比无从谈起；
• 没有Trace看板——每一次Agent、Skill、LLM调用都记录了trace，但没有可视化，排查Agent行为异常还得看jsonl；
• 只在单一云环境跑过——公有云、私有云、自建IDC之间的差异化排障场景没有覆盖到。

这五条局限，恰好对应赛道复赛和决赛要打磨的方向——从“能跑通最小闭环”到“能承接真实生产流量”，工程上要补齐的就是这些。

跑通闭环本身就是一个效率锚点

有同学可能会问：数据还是mock的，能谈什么业务价值？确实不能下定论。但有一个数字可以记下来做参考：

运维行业有Runbook的团队，MTTR（平均恢复时间）基线大约在30-60分钟。OpsPilot Zero在mock场景里跑出的是12分钟全流程闭环、人工介入0次。这不是生产实测，是mock环境下的理想路径——真实环境的数据形态更复杂、噪声更大、工具链更碎，实际能压到多少，是参赛者在接入真实数据后需要进行验证和不停优化的内容和目标。

把这个数字放在这里，不是为了宣称“我们很快”，是为了说明：跑通闭环本身就能给出一个可对比的效率锚点——后续每一次改进，都有基线可以衡量。

写在最后

OpsPilot Zero是为GOAI世界人工智能开源大赛·新智基座Agent Infra赛道做的最小参考实现。因为同时也是这个赛道的导师，看得到评委视角上什么样的作品会拿高分，就想把“最小可信闭环长什么样”这一步的判断标准做透明——让准备参赛的开发者，能对着一个真实存在的、承认自己局限的Demo，去思考自己方案的边界在哪。

Demo完整代码目前还没正式开源，计划在赛道决赛结束后一起放出来。大赛详细介绍在下面补充了，面向复杂任务下的多Agent基础设施与协同系统，¥190万总奖池，1-3人组队，8.16初赛截止。

如果这篇文章对你正在做的事有一点帮助，评论区聊一下你在多Agent工程化上踩到的坑——比看到“来报名”更让人期待的，是看到有人拿着这些判断继续往前走。

附：大赛介绍

www.goaihz.com/tracks?trac…

赛道定位：聚焦多智能体协同基础设施

新智基座赛道要求参赛团队从真实业务场景出发，设计由不少于3个不同职能Agent组成的完整任务闭环，展现任务拆解、上下文传递、工具调用、结果验证、执行证据沉淀以及安全审计等能力，并将关键能力封装为可复用的Skill。

赛道从“团队协同、可验证可回滚、持续进化”三个维度考察系统工程能力，分别对应AgentTeams多Agent协同底座与AgentLoop观测评估飞轮两大开源基础设施。其中AgentTeams作为必选协同设计基点，通过Manager–Team Leader–Worker分层架构实现任务编排与混合框架调度；AgentLoop提供全栈观测、效果评估与自进化调优能力，让Agent系统在真实业务反馈中持续进化。

换言之，这条赛道考察的不是“谁的Agent更聪明”，而是“谁能把多个Agent组织成一个可治理、可观测、可进化的生产级系统”。

核心要求：Skill工程化与可复用性

赛道的核心导向，是“可复用”而非“一次性”。参赛作品应将关键能力沉淀为可复用的Skill，而不是一段只能运行一次的脚本或一场单次演示。具体而言，参赛作品应重点体现：

• 多Agent协同完成复杂任务；
• Skill可复用与工程化封装；
• 工具、系统或云产品的稳定接入；
• 上下文管理与执行证据沉淀；
• 安全边界、审批、回滚与审计机制；
• 作品的开放/开源计划与长期成长价值。

参赛条件：真实场景与闭环能力

赛道提供零人工运维、智能客服自主闭环、软件研发全流程协同、金融风控与理赔自动化等参考方向，但不限制行业，鼓励团队从自身最熟悉的真实业务出发。适合参赛的项目通常具备三个特点：

第一，问题来自真实场景，且需要多个角色协作完成；第二，任务能够形成闭环——系统不仅能提出建议，还能调用工具推动执行并验证结果；第三，关键能力可以复用——项目能沉淀出Skill、工具接口或协同流程，迁移到相似场景中去。

赛道特别提示：相比功能庞杂却无法真正运行的“大平台”，一个场景真实、结构清晰、证据完整的“小闭环”，往往更具竞争力。

评审标准：场景、协同与工程并重

赛道设置五项评审维度：场景价值与行业可复制性（25%）、多Agent协同与自主闭环能力（25%）、Skill工程体系与生态复用（25%）、工程落地与运行验证及安全审计（20%）、开放与开源贡献（5%）。

从权重分布可以看出，赛道并不单独奖励“炫技”，而是将真实场景价值、系统协同能力与工程落地水平放在同等重要的位置，引导团队做出既有行业意义、又经得起运行检验的作品。

赛程与奖项

赛道设计了从初赛到决赛的清晰进阶路径。初赛阶段不强制提交代码，团队可通过作品简介和方案PPT说明设计思路；复赛需提交可执行的AgentTeams代码包和可运行Demo；决赛则需完成现场展示与答辩。

赛程安排：初赛提交截止8月16日；8月24日公布复赛入围名单（Top 30）；9月3日复赛提交截止；9月10日公布决赛入围名单（Top 15）；9月22日线下决赛答辩；9月23日GOAI DAY颁奖及生态对接。

奖项方面，赛道冠军50万元、亚军30万元、季军10万元；表现优异的项目还有机会角逐100万元GOAI全场大奖。参赛团队1-3人，组队规则和报名详情请访问大赛官网。

欢迎大家报名参赛（注：本赛道承办方阿里云所有员工，以及有机会接触赛题背景业务、产品、数据的所有人员，自动退出本次比赛，放弃参赛资格。）：

www.goaihz.com/tracks?trac…