【AI原生】用AI-Native的方式编写SRE告警诊断Agent和Skill

在SRE和稳定性工程领域，告警诊断Agent大概是当下AI落地最热门的场景之一了。对于告警应急场景，有一个迅速可靠的Agent做根因分析，通过透出问题链路关键的信息点，可以省掉很多前期的排查精力，帮助线上问题更迅速被解决。

从实现难度上看，写一个能跑的告警诊断Agent或者Skill，门槛其实不高。接几个Tool（查日志、查监控、查变更记录），写一段System Prompt描述诊断流程，大模型就能按照套路给出一个看似合理的分析结论。但如果要把它做到真正好用、能让大家都信赖程度，那难度就完全不一样了。

所以今天这篇文章就聊一下，如何用AI-Native的方式去研发一个高质量的告警诊断Agent。

首先是为什么需要用AI-Native的方式写，因为本质上Oncall排查也是经验工程，所以很多知识的整理、梳理和表达，都是自然语言驱动的。在这个情境下，用AI-Native的方式而非手搓，肯定是相对更加合理的方案。具体而言，Agent跟Skill本体Prompt的编写，reference的蒸馏，都是可以通过LLM来做的。当然这里的前提是，你了解的整套排查流程，要排查什么信息，得到结论的话涉及哪些知识跟资料，把这些东西整合起来就肯定需要AI的协助。

然后一点是，明确Agent/Skill跟运行时环境的关系。本质上写一个告警诊断Agent是在写一个数字人，从数字人的视角来看，一是知道告警的基本信息，二是手头有一些工具，要做的事情就是根据这些信息，快速推断根因，给予值班同学解决方案。在这个基础上，笔者的建议是根据专家经验，先入为主先预设一套工具集及其用途，从这个角度出发再去根据runtime提供的tool，寻找合适的工具做调用，甚至也可以考虑跟runtime做适当的耦合。这样的话一是能够明显减少工具的误调用，二是整体排查效率也会变高。

之后是Agent跟Skill之间的关系。这里的关键点是，对于不同的告警场景，Agent下面需要拆出多个垂直领域的Skill按需编排，比如可以拆成"变更关联诊断"、“容量水位诊断”、“依赖链路诊断”、"数据库慢查询诊断"等独立Skill，每个Skill有明确的输入输出契约和诊断逻辑。每一个Skill可能引用相同的知识源跟工具，但是做的事情各自又不一样，术业有专攻，这样就能尽可能把不同场景的排查结论做到更加精确。此外，Agent自己接收到一个Skill的输出结论，自身也需要做一层精炼和表达，先是对结论和抽样案例做详细说明，然后得出关键结论，之后一个重点是要指导线上值班同学做什么事情，这样组织起来结论的可靠度会变得更高。

最后是需要做好Agent的评测，通过数据去支撑Agent的执行效果。这里面包括一些用户反馈机制的建设，Agent执行性能/时间/ToolCall成功率的统计，大规模历史数据自动化评测等内容。这一部分也是最复杂最需要持续迭代的环节，建议是在AIOps底座工程层面，去研发更多的Sidecar Agents完善这个事情。因为Agent执行效果的判断，本质上需要与每个业务自身场景做深度绑定，所以并不能说有一个非常普世通用的机制去描述这个事情，而最终也是更多基于业务内的共识，怎么去把这个共识给量化，是要解决这个问题。

总体而言，做一个告警诊断Agent很容易，但要做好，做的系统化，是有难度的。对于有足够技术力，足够技术驱动的组织，并且对于SRE稳定性非常重视，那么把这个事情做到深度投入，是非常有价值的；如果组织更加偏向业务驱动，技术力方面也不能做深的情况下，那么把这个Agent做浅一些，适当包装，尝试从运营推广角度让Agent给更多人用，采取由面到点的战术，有更多合作方背书，这样整个Agent的业务价值也是很好说明的。