項目名稱OpsPilot Zero——基于 AgentTeams 的多智能體自主運維與故障恢復平臺一、使用場景面向 Kubernetes、Nacos、Higress、MySQL 等云原生系統(tǒng)解決傳統(tǒng)運維中告警分散、根因定位慢、修復依賴人工、恢復結果難驗證的問題。當系統(tǒng)發(fā)生訂單接口超時、網關 5xx 激增、數據庫連接池耗盡、慢 SQL 等故障時用戶只需在 Team 房間提交事故描述和scenario_idAgentTeams 自動調度多個專業(yè) Agent完成事故接收 → 告警歸并 → 多源證據采集 → 根因分析 → 修復方案生成 → 風險審批 → 自動處置 → 恢復驗證 → 事故報告你已經跑通的db_pool_exhausted場景就是完整案例系統(tǒng)通過日志、指標、Trace 和配置變更定位到 Nacos 將連接池上限從 50 錯誤下調到 8隨后回滾配置并驗證業(yè)務恢復。二、AgentTeams 能力應用項目必須以 AgentTeams 作為多 Agent 協(xié)同基礎而不是簡單調用多個獨立大模型。系統(tǒng)架構建議設計為用戶 ↓ Matrix Team 房間 ↓ opspilot-zero-demo-leader ↓ AgentTeams 任務拆解與消息協(xié)同 ├─ alert-intake ├─ rca-analyst ├─ remediation-planner └─ recovery-verifier ↓ HTTP Mock Tool Gateway ↓ 指標、日志、Trace、配置、數據庫、探針其中 TeamLeader 負責解析事故任務、安排執(zhí)行順序、傳遞 Worker 輸出、處理沖突并匯總最終報告。四個業(yè)務 Agent 只承擔專業(yè)職責不直接充當 TeamLeader。你當前方案也明確要求獨立創(chuàng)建opspilot-zero-demo-leader并由它調度四個業(yè)務 Worker。三、不同職能 Agent 設計比賽至少要求 3 個不同職能 Agent你現在設計了4 個業(yè)務 Agent和1個獨立 TeamLeader。1. Alert Intake Agent名稱alert-intake職責是聚合客戶投訴、監(jiān)控告警和故障前指標確定事故等級、影響范圍、時間線和證據索引。主要調用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負責關聯(lián)日志、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 結論轉化為可執(zhí)行修復步驟、驗證步驟、回滾點和審批計劃。核心能力是風險分級L0/L1允許進入自動執(zhí)行流程 L2/L3只能生成審批任務不得直接執(zhí)行例如連接池配置回滾可以作為低風險動作執(zhí)行而創(chuàng)建數據庫索引等高風險操作只生成審批方案。4. Recovery Verifier Agent名稱recovery-verifier負責執(zhí)行被允許的低風險修復語義并查詢修復后指標及合成探針結果判斷業(yè)務是否真正恢復。主要調用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 不代替專業(yè) Agent 執(zhí)行具體分析而是負責理解用戶事故任務按順序調度專業(yè) Agent將前一 Agent 的輸出傳給后一 Agent發(fā)現證據不足時要求相關 Agent 補充查詢處理多個根因候選之間的沖突匯總生成最終事故報告。四、可復用 Skill 設計比賽要求 Skill 能夠復用因此不能把所有能力都硬編碼在某一個事故場景中。建議設計以下 6 個 Skill。Skill 1alert-fusion功能將不同來源、不同時間和不同服務的告警進行關聯(lián)歸并。輸入{ complaints: [], alerts: [], metrics: {} }輸出{ severity: P1, affected_services: [], timeline: [], evidence_refs: [] }可復用于連接池耗盡、慢 SQL、配置異常、網關故障等場景。Skill 2impact-mapping功能根據告警和接口信息推斷受影響服務、用戶操作和業(yè)務影響。例如order-service異常 → /api/order/create延遲 → 用戶提交訂單失敗 → 支付頁面持續(xù)加載Skill 3log-trace-rca功能統(tǒng)一關聯(lián)錯誤日志、調用鏈、指標突變和配置變更輸出根因候選排序。輸出格式{ top_candidate: { root_cause: , confidence: 0.95, evidence: [] }, candidates: [], missing_evidence: [] }Skill 4remediation-plan功能根據根因和 Runbook 自動生成修復步驟、驗證步驟和回滾點。它不依賴某一個具體服務可用于配置回滾服務重啟緩存啟用流量切換擴容建議索引優(yōu)化計劃。Skill 5risk-guard功能對處置動作進行風險分級和執(zhí)行控制。建議規(guī)則風險等級示例執(zhí)行策略L0只讀查詢、探針檢查自動執(zhí)行L1已知配置回滾自動執(zhí)行并記錄L2服務重啟、流量切換需要審批L3數據庫結構變更、刪除數據只生成審批計劃Skill 6recovery-verify功能比較修復前后指標并調用接口探針判斷是否恢復。例如網關5xx18.4% → 0.3% 訂單P996800ms → 420ms 連接池活躍率0.99 → 0.46 探針狀態(tài)failed → ok只有滿足預設恢復閾值才能輸出{ recovered: true }五、可復用性體現這些 Skill 不綁定db_pool_exhausted只依賴標準輸入輸出和工具契約因此能夠遷移到數據庫連接池耗盡慢 SQL 導致接口退化Nacos 配置誤變更Higress 網關 5xx 異常Kubernetes Pod 異常服務依賴超時緩存失效或擊穿數據庫負載突增。工具調用統(tǒng)一采用POST http://172.18.0.1:18089/tools/{scenario_id}/{tool_name}.{function_name}因此增加新事故場景時只需新增場景數據與工具實現不需要重新設計 Agent 協(xié)作結構。項目材料也明確規(guī)定所有工具數據經統(tǒng)一 HTTP Mock Tool Gateway 獲取。六、比賽要求對應關系比賽要求項目實現必須以 AgentTeams 為基礎使用 Team、TeamLeader、Worker 和 Matrix 房間完成協(xié)作至少3個不同職能 Agent設計4個業(yè)務 Agent和1個 TeamLeader必須設計可復用 Skill設計告警融合、影響分析、根因分析、修復規(guī)劃、風險控制、恢復驗證等 Skill多 Agent 協(xié)同TeamLeader 按事故處理流程串聯(lián)各 Worker能力可落地已跑通連接池耗盡的診斷、回滾和驗證閉環(huán)可擴展性通過統(tǒng)一工具契約擴展更多事故場景