项目名称OpsPilot Zero——基于 AgentTeams 的多智能体自主运维与故障恢复平台一、使用场景面向 Kubernetes、Nacos、Higress、MySQL 等云原生系统解决传统运维中告警分散、根因定位慢、修复依赖人工、恢复结果难验证的问题。当系统发生订单接口超时、网关 5xx 激增、数据库连接池耗尽、慢 SQL 等故障时用户只需在 Team 房间提交事故描述和scenario_idAgentTeams 自动调度多个专业 Agent完成事故接收 → 告警归并 → 多源证据采集 → 根因分析 → 修复方案生成 → 风险审批 → 自动处置 → 恢复验证 → 事故报告你已经跑通的db_pool_exhausted场景就是完整案例系统通过日志、指标、Trace 和配置变更定位到 Nacos 将连接池上限从 50 错误下调到 8随后回滚配置并验证业务恢复。二、AgentTeams 能力应用项目必须以 AgentTeams 作为多 Agent 协同基础而不是简单调用多个独立大模型。系统架构建议设计为用户 ↓ Matrix Team 房间 ↓ opspilot-zero-demo-leader ↓ AgentTeams 任务拆解与消息协同 ├─ alert-intake ├─ rca-analyst ├─ remediation-planner └─ recovery-verifier ↓ HTTP Mock Tool Gateway ↓ 指标、日志、Trace、配置、数据库、探针其中 TeamLeader 负责解析事故任务、安排执行顺序、传递 Worker 输出、处理冲突并汇总最终报告。四个业务 Agent 只承担专业职责不直接充当 TeamLeader。你当前方案也明确要求独立创建opspilot-zero-demo-leader并由它调度四个业务 Worker。三、不同职能 Agent 设计比赛至少要求 3 个不同职能 Agent你现在设计了4 个业务 Agent和1个独立 TeamLeader。1. Alert Intake Agent名称alert-intake职责是聚合客户投诉、监控告警和故障前指标确定事故等级、影响范围、时间线和证据索引。主要调用mock_ticket.get_customer_complaint mock_monitoring.list_alerts mock_monitoring.query_metrics输出包括{ incident_id: INC-1001, severity: P1, affected_services: [], timeline: [], symptoms: [], evidence_refs: [] }其目标是把零散的客诉与告警转化为结构化事故摘要。2. RCA Analyst Agent名称rca-analyst负责关联日志、Trace、配置变更、慢 SQL、指标和 Runbook形成根因候选排序及证据链。主要调用mock_logs.search_logs mock_traces.query_traces mock_config.list_changes mock_database.list_slow_queries mock_runbook.search它不能只根据经验猜测而必须输出根因置信度、支持证据和缺失证据。3. Remediation Planner Agent名称remediation-planner负责将 RCA 结论转化为可执行修复步骤、验证步骤、回滚点和审批计划。核心能力是风险分级L0/L1允许进入自动执行流程 L2/L3只能生成审批任务不得直接执行例如连接池配置回滚可以作为低风险动作执行而创建数据库索引等高风险操作只生成审批方案。4. Recovery Verifier Agent名称recovery-verifier负责执行被允许的低风险修复语义并查询修复后指标及合成探针结果判断业务是否真正恢复。主要调用mock_config.rollback_config mock_monitoring.query_metrics mock_probe.check_endpoint最终输出{ recovered: true, executed_actions: [], approval_actions: [], verification: [], postmortem_notes: [], telemetry_advice: [] }5. TeamLeader Agent名称opspilot-zero-demo-leaderTeamLeader 不代替专业 Agent 执行具体分析而是负责理解用户事故任务按顺序调度专业 Agent将前一 Agent 的输出传给后一 Agent发现证据不足时要求相关 Agent 补充查询处理多个根因候选之间的冲突汇总生成最终事故报告。四、可复用 Skill 设计比赛要求 Skill 能够复用因此不能把所有能力都硬编码在某一个事故场景中。建议设计以下 6 个 Skill。Skill 1alert-fusion功能将不同来源、不同时间和不同服务的告警进行关联归并。输入{ complaints: [], alerts: [], metrics: {} }输出{ severity: P1, affected_services: [], timeline: [], evidence_refs: [] }可复用于连接池耗尽、慢 SQL、配置异常、网关故障等场景。Skill 2impact-mapping功能根据告警和接口信息推断受影响服务、用户操作和业务影响。例如order-service异常 → /api/order/create延迟 → 用户提交订单失败 → 支付页面持续加载Skill 3log-trace-rca功能统一关联错误日志、调用链、指标突变和配置变更输出根因候选排序。输出格式{ top_candidate: { root_cause: , confidence: 0.95, evidence: [] }, candidates: [], missing_evidence: [] }Skill 4remediation-plan功能根据根因和 Runbook 自动生成修复步骤、验证步骤和回滚点。它不依赖某一个具体服务可用于配置回滚服务重启缓存启用流量切换扩容建议索引优化计划。Skill 5risk-guard功能对处置动作进行风险分级和执行控制。建议规则风险等级示例执行策略L0只读查询、探针检查自动执行L1已知配置回滚自动执行并记录L2服务重启、流量切换需要审批L3数据库结构变更、删除数据只生成审批计划Skill 6recovery-verify功能比较修复前后指标并调用接口探针判断是否恢复。例如网关5xx18.4% → 0.3% 订单P996800ms → 420ms 连接池活跃率0.99 → 0.46 探针状态failed → ok只有满足预设恢复阈值才能输出{ recovered: true }五、可复用性体现这些 Skill 不绑定db_pool_exhausted只依赖标准输入输出和工具契约因此能够迁移到数据库连接池耗尽慢 SQL 导致接口退化Nacos 配置误变更Higress 网关 5xx 异常Kubernetes Pod 异常服务依赖超时缓存失效或击穿数据库负载突增。工具调用统一采用POST http://172.18.0.1:18089/tools/{scenario_id}/{tool_name}.{function_name}因此增加新事故场景时只需新增场景数据与工具实现不需要重新设计 Agent 协作结构。项目材料也明确规定所有工具数据经统一 HTTP Mock Tool Gateway 获取。六、比赛要求对应关系比赛要求项目实现必须以 AgentTeams 为基础使用 Team、TeamLeader、Worker 和 Matrix 房间完成协作至少3个不同职能 Agent设计4个业务 Agent和1个 TeamLeader必须设计可复用 Skill设计告警融合、影响分析、根因分析、修复规划、风险控制、恢复验证等 Skill多 Agent 协同TeamLeader 按事故处理流程串联各 Worker能力可落地已跑通连接池耗尽的诊断、回滚和验证闭环可扩展性通过统一工具契约扩展更多事故场景
项目名称OpsPilot Zero——基于 AgentTeams 的多智能体自主运维与故障恢复平台一、使用场景面向 Kubernetes、Nacos、Higress、MySQL 等云原生系统解决传统运维中告警分散、根因定位慢、修复依赖人工、恢复结果难验证的问题。当系统发生订单接口超时、网关 5xx 激增、数据库连接池耗尽、慢 SQL 等故障时用户只需在 Team 房间提交事故描述和scenario_idAgentTeams 自动调度多个专业 Agent完成事故接收 → 告警归并 → 多源证据采集 → 根因分析 → 修复方案生成 → 风险审批 → 自动处置 → 恢复验证 → 事故报告你已经跑通的db_pool_exhausted场景就是完整案例系统通过日志、指标、Trace 和配置变更定位到 Nacos 将连接池上限从 50 错误下调到 8随后回滚配置并验证业务恢复。二、AgentTeams 能力应用项目必须以 AgentTeams 作为多 Agent 协同基础而不是简单调用多个独立大模型。系统架构建议设计为用户 ↓ Matrix Team 房间 ↓ opspilot-zero-demo-leader ↓ AgentTeams 任务拆解与消息协同 ├─ alert-intake ├─ rca-analyst ├─ remediation-planner └─ recovery-verifier ↓ HTTP Mock Tool Gateway ↓ 指标、日志、Trace、配置、数据库、探针其中 TeamLeader 负责解析事故任务、安排执行顺序、传递 Worker 输出、处理冲突并汇总最终报告。四个业务 Agent 只承担专业职责不直接充当 TeamLeader。你当前方案也明确要求独立创建opspilot-zero-demo-leader并由它调度四个业务 Worker。三、不同职能 Agent 设计比赛至少要求 3 个不同职能 Agent你现在设计了4 个业务 Agent和1个独立 TeamLeader。1. Alert Intake Agent名称alert-intake职责是聚合客户投诉、监控告警和故障前指标确定事故等级、影响范围、时间线和证据索引。主要调用mock_ticket.get_customer_complaint mock_monitoring.list_alerts mock_monitoring.query_metrics输出包括{ incident_id: INC-1001, severity: P1, affected_services: [], timeline: [], symptoms: [], evidence_refs: [] }其目标是把零散的客诉与告警转化为结构化事故摘要。2. RCA Analyst Agent名称rca-analyst负责关联日志、Trace、配置变更、慢 SQL、指标和 Runbook形成根因候选排序及证据链。主要调用mock_logs.search_logs mock_traces.query_traces mock_config.list_changes mock_database.list_slow_queries mock_runbook.search它不能只根据经验猜测而必须输出根因置信度、支持证据和缺失证据。3. Remediation Planner Agent名称remediation-planner负责将 RCA 结论转化为可执行修复步骤、验证步骤、回滚点和审批计划。核心能力是风险分级L0/L1允许进入自动执行流程 L2/L3只能生成审批任务不得直接执行例如连接池配置回滚可以作为低风险动作执行而创建数据库索引等高风险操作只生成审批方案。4. Recovery Verifier Agent名称recovery-verifier负责执行被允许的低风险修复语义并查询修复后指标及合成探针结果判断业务是否真正恢复。主要调用mock_config.rollback_config mock_monitoring.query_metrics mock_probe.check_endpoint最终输出{ recovered: true, executed_actions: [], approval_actions: [], verification: [], postmortem_notes: [], telemetry_advice: [] }5. TeamLeader Agent名称opspilot-zero-demo-leaderTeamLeader 不代替专业 Agent 执行具体分析而是负责理解用户事故任务按顺序调度专业 Agent将前一 Agent 的输出传给后一 Agent发现证据不足时要求相关 Agent 补充查询处理多个根因候选之间的冲突汇总生成最终事故报告。四、可复用 Skill 设计比赛要求 Skill 能够复用因此不能把所有能力都硬编码在某一个事故场景中。建议设计以下 6 个 Skill。Skill 1alert-fusion功能将不同来源、不同时间和不同服务的告警进行关联归并。输入{ complaints: [], alerts: [], metrics: {} }输出{ severity: P1, affected_services: [], timeline: [], evidence_refs: [] }可复用于连接池耗尽、慢 SQL、配置异常、网关故障等场景。Skill 2impact-mapping功能根据告警和接口信息推断受影响服务、用户操作和业务影响。例如order-service异常 → /api/order/create延迟 → 用户提交订单失败 → 支付页面持续加载Skill 3log-trace-rca功能统一关联错误日志、调用链、指标突变和配置变更输出根因候选排序。输出格式{ top_candidate: { root_cause: , confidence: 0.95, evidence: [] }, candidates: [], missing_evidence: [] }Skill 4remediation-plan功能根据根因和 Runbook 自动生成修复步骤、验证步骤和回滚点。它不依赖某一个具体服务可用于配置回滚服务重启缓存启用流量切换扩容建议索引优化计划。Skill 5risk-guard功能对处置动作进行风险分级和执行控制。建议规则风险等级示例执行策略L0只读查询、探针检查自动执行L1已知配置回滚自动执行并记录L2服务重启、流量切换需要审批L3数据库结构变更、删除数据只生成审批计划Skill 6recovery-verify功能比较修复前后指标并调用接口探针判断是否恢复。例如网关5xx18.4% → 0.3% 订单P996800ms → 420ms 连接池活跃率0.99 → 0.46 探针状态failed → ok只有满足预设恢复阈值才能输出{ recovered: true }五、可复用性体现这些 Skill 不绑定db_pool_exhausted只依赖标准输入输出和工具契约因此能够迁移到数据库连接池耗尽慢 SQL 导致接口退化Nacos 配置误变更Higress 网关 5xx 异常Kubernetes Pod 异常服务依赖超时缓存失效或击穿数据库负载突增。工具调用统一采用POST http://172.18.0.1:18089/tools/{scenario_id}/{tool_name}.{function_name}因此增加新事故场景时只需新增场景数据与工具实现不需要重新设计 Agent 协作结构。项目材料也明确规定所有工具数据经统一 HTTP Mock Tool Gateway 获取。六、比赛要求对应关系比赛要求项目实现必须以 AgentTeams 为基础使用 Team、TeamLeader、Worker 和 Matrix 房间完成协作至少3个不同职能 Agent设计4个业务 Agent和1个 TeamLeader必须设计可复用 Skill设计告警融合、影响分析、根因分析、修复规划、风险控制、恢复验证等 Skill多 Agent 协同TeamLeader 按事故处理流程串联各 Worker能力可落地已跑通连接池耗尽的诊断、回滚和验证闭环可扩展性通过统一工具契约扩展更多事故场景
