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