项目名称

OpsPilot Zero——基于 AgentTeams 的多智能体自主运维与故障恢复平台

一、使用场景

面向 Kubernetes、Nacos、Higress、MySQL 等云原生系统，解决传统运维中告警分散、根因定位慢、修复依赖人工、恢复结果难验证的问题。

当系统发生订单接口超时、网关 5xx 激增、数据库连接池耗尽、慢 SQL 等故障时，用户只需在 Team 房间提交事故描述和scenario_id，AgentTeams 自动调度多个专业 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-leader

TeamLeader 不代替专业 Agent 执行具体分析，而是负责：

• 理解用户事故任务；
• 按顺序调度专业 Agent；
• 将前一 Agent 的输出传给后一 Agent；
• 发现证据不足时要求相关 Agent 补充查询；
• 处理多个根因候选之间的冲突；
• 汇总生成最终事故报告。

四、可复用 Skill 设计

比赛要求 Skill 能够复用，因此不能把所有能力都硬编码在某一个事故场景中。建议设计以下 6 个 Skill。

Skill 1：alert-fusion

功能：将不同来源、不同时间和不同服务的告警进行关联归并。

输入：

{ "complaints": [], "alerts": [], "metrics": {} }

输出：

{ "severity": "P1", "affected_services": [], "timeline": [], "evidence_refs": [] }

可复用于连接池耗尽、慢 SQL、配置异常、网关故障等场景。

Skill 2：impact-mapping

功能：根据告警和接口信息推断受影响服务、用户操作和业务影响。

例如：

order-service异常 → /api/order/create延迟 → 用户提交订单失败 → 支付页面持续加载

Skill 3：log-trace-rca

功能：统一关联错误日志、调用链、指标突变和配置变更，输出根因候选排序。

输出格式：

{ "top_candidate": { "root_cause": "", "confidence": 0.95, "evidence": [] }, "candidates": [], "missing_evidence": [] }

Skill 4：remediation-plan

功能：根据根因和 Runbook 自动生成修复步骤、验证步骤和回滚点。

它不依赖某一个具体服务，可用于：

• 配置回滚；
• 服务重启；
• 缓存启用；
• 流量切换；
• 扩容建议；
• 索引优化计划。

Skill 5：risk-guard

功能：对处置动作进行风险分级和执行控制。

建议规则：

Skill 6：recovery-verify

功能：比较修复前后指标并调用接口探针，判断是否恢复。

例如：

网关5xx：18.4% → 0.3% 订单P99：6800ms → 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 获取。

六、比赛要求对应关系