你也可以这样落地 AI Agent - 案例篇

1. 处理确定故障

对于有具体处理方式的故障，直接使用 Agent 处理，发通知周知即可。

类似的自动处理，我们有应用层的异常负载删除、节点层的磁盘清理、GPU 掉卡屏蔽卡、屏蔽节点等。先找出团队中遇到得最多、需要最多人力的事情，对其进行自动化处理。你可以认为，此时 Agent 就是 LLM + SOP，模型帮你选择合适的标准流程处理标准的故障得到标准结果。

完成上一步之后，我停顿了很久，一直在补齐团队的一些观测能力，同时将指标、日志、事件、链路、标准运维五个维度的能力通过 ops-mcp-server 项目导出为统一的标准协议。

保障十几个集群和几百个节点的稳定运行，快速发现和定位、修复故障是我的工作基本盘。数量达到一定级别时，以前有概率出现的事情，逐渐变得必然。每天需要排查的故障很多，GPU 的异构场景、训推一体的 AI 构架又显著增加了根因分析的难度。

在故障发生期间，会频繁在很多页面来回切换，寻找根因。巡检 Agent 就是解决这个问题的。此时的 Agent 并不是 AI 驱动的。写 AI Agent 过早使用太多 AI 能力只能得到局部最优解，之后可能无法继续演进。

但并不意味着不能植入 AI。你可以先写很多巡检 Agent，让 AI 根据场景选择哪些巡检 Agent 需要启用。

对于一些开放式的根因分析，才是 AI Agent 的主战场。已经有前面的铺垫，你已经建立了若干故障标准的处理流程，还能进行各种集群、节点、中间件、网络的巡检，剩下的交给 AI 去分析。

热故障的分析无疑是有巨大价值的，能在团队中第一时间发现故障、定位修复，是很有成就感的事情。

自动故障分析的关键点是进行资源的关联。非常可惜的是，你可能和我们一样，没有这样的数据库，全靠口口相传，全靠分析时实时查看。花大力气去补齐这个数据库，后期维护一致性也是一个问题。怎么办？交给大模型。

在前面我们做了很多巡检 Agent 查询资源，将查询到的信息给 AI 就能提取到关联的信息。不停查询，不停分析，一直找到达到要求的根因为止。

上面这张图就是我根据最原始的 Prometheus、Elasticsearch，不借助 Trace 埋点，无任何入侵，告警之后，自动分析得到的根因分析结果。