Datawhale AI 学习中心 · GOAI 世界人工智能开源大赛 Agent Infra 赛道 学习笔记

---

一、前言：为什么做这个项目

作为智能科学与技术专业的学生，我一直关注 AI Agent 在实际工程场景中的落地。参加本次 GOAI Agent Infra 赛道后，我们团队选择了运维自动化这个方向——这是一个典型的"高噪音、强时效、多系统协同"场景，天然适合多 Agent 协作。

传统运维中，一次 P1 级别故障的平均处理时间（MTTR）在 30-60 分钟，且高度依赖运维专家的个人经验。我们的目标很明确：设计一套基于多 Agent 协同的运维自愈系统，将 MTTR 从小时级压缩到分钟级，并最大程度减少人工介入。

---

二、项目总览：OpsPilot Zero 是什么

OpsPilot Zero 是一套基于 GOAI AgentTeams 框架构建的多 Agent 智能运维系统，目标是在云原生环境下实现告警接入 → 根因分析 → 修复执行 → 恢复验证的全闭环自动化。

核心指标

维度	目标
MTTR	≤12 分钟（当前人工 30-60 分钟）
自动化率	≥80% 的 L1/L2 故障无需人工介入
Agent 数量	4 个专用 Agent + 1 个人机协同节点
Skill 数量	7 个（含 1 个 Guardrail）
故障场景覆盖	2 个真实运维场景已跑通 Demo

---

三、痛点分析：为什么现有方案不够用

当前企业运维团队面临的三大核心痛点：

3.1 告警噪音淹没真实根因

Prometheus/Grafana 等监控平台每天可能产生上千条告警，其中 80% 以上是重复或关联告警。运维人员需要在海量噪音中人工筛选和关联，效率极低。

3.2 跨系统排查耗时长

一次典型故障排查需要在日志系统、指标平台、Trace 链路、配置变更记录之间来回切换。人工操作的话，单是"找对地方"就可能花掉 10-15 分钟。

3.3 修复方案设计容错率低

修复脚本不仅要解决当前问题，还要考虑依赖服务的影响面。在压力下做出的决策，往往缺乏充分验证，容易引入二次故障。

3.4 恢复验证覆盖不全

"看起来好了"不等于真的好了。缺乏自动化的多维度验证，很多隐性故障会在几小时后再次爆发。

---

四、方案设计：4+1 Agent 闭环架构

4.1 整体架构

┌─────────────────────────────────────────────────────┐
│                    运维自愈闭环                       │
│                                                      │
│  ┌──────────┐   ┌──────────┐   ┌──────────────┐    │
│  │AlertIntake│ → │RCAAnalyst │ → │Remediation   │    │
│  │ 告警接入   │   │ 根因分析   │   │Planner 修复   │    │
│  └──────────┘   └──────────┘   └──────┬───────┘    │
│                                        ↓             │
│              ┌──────────────┐   ┌────────────────┐  │
│              │RecoveryVerifier│ ← │  Human-in-the- │  │
│              │  恢复验证       │   │  Loop 审批节点  │  │
│              └──────────────┘   └────────────────┘  │
└─────────────────────────────────────────────────────┘

4.2 四个 Agent 的职责分工

Agent	核心职责	输入	输出
AlertIntake	告警聚合降噪 + 事件创建	原始告警流	结构化故障事件
RCAAnalyst	多源证据关联 + 根因定位	事件 + 日志/指标/Trace	根因分析报告
RemediationPlanner	生成修复方案 + 影响面评估	根因报告	可执行修复计划
RecoveryVerifier	多维度恢复验证	修复结果	验证报告 + 事件关闭

4.3 协作模式

采用 串行流水线 + 状态共享上下文 模式：

• AlertIntake 输出结构化事件（JSON Schema）
• RCAAnalyst 附加根因分析（引用 ≥2 条独立证据来源）
• RemediationPlanner 生成修复方案（含回滚策略和影响面评分）
• RecoveryVerifier 执行验证并回写状态
• L2/L3 级操作经人工审批节点介入

4.4 安全边界设计（L0-L3）

等级	描述	处理方式
L0	已知故障，确定性修复	全自动执行，无需审批
L1	已知故障，需参数调整	自动执行，事后通知
L2	不确定根因，中等影响	生成方案，人工审批后执行
L3	未知故障，高风险操作	仅建议，必须人工执行

---

五、Skill 工程体系

我们围绕运维场景设计了 7 个专用 Skill，每个 Skill 都遵循统一的 SKILL.md 规范：

Skill	功能	类型
alert-fusion	多源告警去重合并，生成统一事件	感知
impact-mapping	故障影响面分析（服务/用户/业务）	分析
log-trace-rca	日志 + Trace 联合根因分析	分析
data-advisor	指标异常检测与趋势预测	分析
remediation-plan	基于根因生成分级修复方案	决策
recovery-verify	多维度恢复验证（指标/日志/接口）	验证
risk-guard	风险评估与人工审批触发（Guardrail）	安全

Skill 设计原则

1. 单一职责：每个 Skill 只做一件事，做好一件事
2. 证据驱动：任何结论必须引用可追溯的数据来源
3. 可复用：Skill 不绑定特定 Agent，可跨 Agent 调用
4. 可测试：每个 Skill 有明确的输入/输出契约

---

六、工程落地

6.1 技术栈

层级	选型
Agent 框架	GOAI AgentTeams
LLM	可插拔（支持 OpenAI/Azure/本地模型）
工具网关	Python FastAPI（Mock Tool Server）
工具协议	MCP (Model Context Protocol)
配置管理	YAML + JSON Schema
场景描述	JSON 结构化剧本

6.2 Mock Tool Server

在接入真实运维环境之前，我们搭建了 Mock Tool Server 用于验证 Agent 的决策链路：

# tools/mock_tool_server.py 核心架构
from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()

# 9 个运维工具的统一网关
@app.post("/api/v1/tools/{tool_name}")
async def execute_tool(tool_name: str, params: dict):
    """统一的工具调用入口，支持日志查询、指标获取等"""
    ...

支持的工具包括：日志查询、指标查询、Trace 查询、配置变更查询、服务重启、流量切换、健康检查等。

6.3 场景剧本

设计了两个真实运维场景的 JSON 剧本：

场景一：数据库连接池耗尽

{
  "scenario": "db_pool_exhausted",
  "trigger": {
    "alert": "MySQL connection pool exhausted",
    "metrics": {"active_connections": 100, "max_connections": 100}
  },
  "expected_root_cause": "慢查询堆积导致连接未释放",
  "expected_remediation": "KILL 慢查询 + 临时扩容连接池 + 优化索引"
}

场景二：慢 SQL 级联降级

{
  "scenario": "slow_sql_degradation",
  "trigger": {
    "alert": "API latency > 3s",
    "metrics": {"p99_latency_ms": 5000}
  },
  "expected_root_cause": "未使用索引的全文扫描",
  "expected_remediation": "添加复合索引 + 查询语句重写"
}

---

七、当前进展与后续规划

已完成

• ✅ 4 个 Agent 的角色定义与运行手册（Agent.md + RUNBOOK）
• ✅ 7 个 Skill 的完整定义（SKILL.md + 依赖清单）
• ✅ 2 个真实运维场景 JSON 剧本
• ✅ Mock Tool Server（9 个工具统一网关 + MCP 映射）
• ✅ 初赛方案 PPT（19 页完整内容）

进行中

• 🔄 接入真实 LLM 进行端到端测试
• 🔄 补充更多故障场景剧本（目标 5+ 场景）

待启动

• ⏳ RecoveryVerifier 自动化验证逻辑完善
• ⏳ 可观测性仪表板设计
• ⏳ 性能基准测试

---

八、学习心得与收获

8.1 多 Agent 协同的核心挑战

这次实践让我深刻体会到，多 Agent 系统的难点不在单个 Agent 的能力，而在协同。具体挑战包括：

1. 上下文传递的语义保真：Agent A 的根因分析报告如何被 Agent C 完整理解？我们采用了结构化 JSON Schema 作为中间表示，避免自由文本带来的歧义。
2. 安全边界的粒度把控：L0-L3 的分级看似简单，实际在"自动执行"与"人工审批"之间画线需要大量领域知识。risk-guard Skill 的阈值调整是一个持续迭代的过程。

8.2 Skill 工程的价值

将运维知识固化为标准化的 Skill，而非直接写入 Agent Prompt，带来了三点收益：

• 可复用：同一个 Skill 可被多个 Agent 调用
• 可测试：每个 Skill 独立验证输入输出
• 可演进：Skill 可以独立升级而不影响其他组件

8.3 从 Demo 到生产还有多远

坦诚地说，当前方案还处于 Demo 阶段。以下是我们识别出的关键差距：

• Mock 环境与真实运维环境的差异（工具可用性、数据延迟等）
• 多 Agent 并发协作的死锁风险
• LLM 输出的不确定性对修复方案可靠性的影响
• 缺少持续学习的反馈闭环

---

九、资源链接

• 赛事官网：GOAI Agent Infra 赛道
• 初赛方案 PPT：已提交至 Datawhale 学习小组任务
• 项目相关工作空间结构：

opspilot-zero-demo/
├── agents/          # 4 个 Agent 定义
├── skills/          # 7 个 Skill 定义
├── scenarios/       # 故障场景剧本
├── tools/           # Mock Tool Server + MCP 映射
├── at/              # AgentTeams 运行手册
└── README.md

---

十、写在最后

Agent Infra 赛道让我从"如何使用 AI"上升到"如何让 AI 自己协作"的层面。运维自动化只是 Agent Infra 的一个切入点，这套多 Agent 协同的架构设计可以迁移到更多场景——DevOps、安全响应、数据处理等。

如果你也在参加 GOAI 或对多 Agent 系统感兴趣，欢迎在评论区交流讨论！也欢迎关注我的后续更新，我会持续记录项目进展和技术细节。

---

本文为 Datawhale AI 学习中心 · GOAI Agent Infra 赛道学习笔记，如需转载请联系作者。

标签：#GOAI #AgentInfra #多智能体 #运维自动化 #AI #Datawhale