9月25日，菜鸟应邀在云栖大会做了主题分享。已晨分享了菜鸟在SRE Agent领域的实践

发表于 更新于

9月25日，菜鸟应邀在云栖大会做了主题分享。菜鸟平台团队围绕开发者的各个环节积极探索AI，希望可以用AI让菜鸟的开发者有十倍的效率提升。作为质量效能与基础架构团队的负责人，已晨在云栖大会分享了菜鸟SRE Agent在上下文工程上的实践。此次分享围绕四个核心问题展开：

● 第一，菜鸟的SRE Agent解决了什么问题

● 第二，我们如何实现SRE Agent

● 第三，如何度量SRE Agent的效果

● 第四，如何提升SRE Agent的表现

通过这次分享，你能看到一款Agent产品从0到1的过程，希望我们的实践经验，让你能了解sre agent的产品与技术的实践细节，理解企业级agent的实践方法论，并加深对于上下文工程的理解。

第一部分：SRE Agent 解决了什么问题

▐ SRE背景介绍

SRE的全称是站点可用性工程（Site Reliability Engineering），由Google提出的概念。在菜鸟，我们融入了菜鸟产业互联网特色，并做了体系化的设计和实践，称之为菜鸟的安全生产体系。

菜鸟的安全生产体系通过多维度的过程指标和结果指标进行牵引，覆盖研发的全生命周期。在平台层面，我们重点建设四个核心能力：

  1. 工程化的管理能力

  2. 预警观测诊断能力

  3. 资损安全的保障能力

  4. 大促等关键场景的应对能力

希望用这些能力让开发者做安全生产更简单。

▐ SRE AI演进历程：从AIOps到SRE Agent

介绍完SRE，再来看一看AI Agent的发展历程。早在2016年Gartner提出了AIOps这个概念，当时的定义是从海量的运维数据中进行学习，用算法来增强IT运维的能力，主要实践方向是对时序数据做异常检测、告警合并降噪、故障的根因分析等。但当时的实现成本非常高，它要求有很强大的算法团队支撑。比如，

  • 数据工程师，负责数据采集、清洗、存储运维数据，设计数据模型，支持算法模型训练和分析
  • 算法工程师，负责构建和优化AIOps核心算法模型，比如设计时序数据的异常检测算法，调整模型参数，对模型进行部署监控等
  • 开发工程师，负责开发AIOps平台的后端系统功能，集成算法模块到运维平台等

一个异常检测项目往往需要3-6个月的开发周期，还要持续的模型维护和调优。这对一般公司来说是一件非常奢侈的事，所以AIOps主要集中在学术界或很大型的公司。

大模型技术让AI能力真正普及到了各个领域，大模型可以直接理解告警、日志、时序数据，内置了通用的推理能力，可以用Prompt来约束推理方式，只需要开发工程师设计Prompt，调用大模型API，集成到现有运维系统中，开发周期从几个月缩短到几周，维护成本也大幅降低。

▐ 识别SRE Agent的黄金场景

平时SRE同学有大量的任务需要完成，比如处理告警、识别风险、排查工单、容量规划等。那么菜鸟SRE Agent应该优先解决哪个问题呢？

为了让SRE Agent的MVP版本发挥出最大的效果，我们建立了一个评估框架，从用户规模、使用频率、效果感知这三个维度进行分析。用户规模大、使用频率高、用户感知程度强的场景是AI实践的黄金场景。对菜鸟而言，这个黄金场景就是预警任务处理。

菜鸟的预警任务跟普通的告警消息不同，具体来说，我们会订阅所有监控平台的告警消息，在SRE工作台进行合并降噪，形成预警处理任务，然后下发给相应的开发者进行处理。如果开发者不处理，任务会有超时升级的机制，层层升级，确保每个预警任务都会有闭环处置。

从从业界实践来看，各家公司在SRE Agent方面的探索大同小异。比如Azure的SRE Agent主要做监控状况和性能表现分析，提供基础设施最佳实践和自动化响应能力；FuzzyLab的SRE Agent主要做告警的诊断

第二部分：如何实现SRE Agent

▐ 产品形态选择：用户在哪儿，Agent就应该在哪儿

当我们准备要做出来SRE Agent的时候，我们面临的第一个问题是选择agent的产品形态，是要做一个钉钉聊天机器人，还是嵌入在工作台右侧的智能对话框，还是像Cursor一样，做一个智能的IDE呢？

这里我们受Cursor的启发，Cursor没有改变用户的习惯，而是托管掉用户复杂的编码过程，只需要用户决策是accept还是reject。我们的sre agent，也选择尊重用户习惯，而只托管掉复杂的排查过程，只需要用户决策是否采纳AI的判断。

用户在哪儿，Agent就应该在哪儿

当预警任务创建后，会自动触发SRE Agent进行定位分析，它会调用我们预制的一些MCP工具获取更多的数据，比如根据TraceID分析下游的错慢调用节点、查询应用的错误日志，查询应用最近的变更事件等。

中间的分析过程会收起来，会描述调用MCP的入参和返回结果，分析结果显示在右边栏，最下方提供”采纳”或”拒绝”按钮。通过这种方式，Agent有效屏蔽了复杂的排查过程，用户只需做最后的决策判断。

并且在实践过程中，我们有一个重要认知是：Agent的产品形态不一定非得是对话形式，它可以是任意事件触发的。我们在设计的时候也没有对话框，只在点击“拒绝”之后，会有一个对话框让你输入原因，后续会根据这个原因来进行关单，或者做快恢的动作

▐ 技术选型决策

Agent架构模式选择：用ReAct模式构建菜鸟SRE Agent

我们观察到业界对Agent的认知也在逐渐提升。从最开始RAG + System Prompt的聊天机器人，到用低码搭建的各种智能工作流，再到用源码框架开发的的更自主的智能体。参考Anthropic对Agent的定义：Agent是一个大模型的循环，每次根据环境的反馈，决策下一步执行动作，直到大模型认为目标达成或无法再继续下去，停止循环。

在这个过程中，大模型一步一步达成最终的目标，而不需要提前编排好的、固定的流程。这种设计实现非常适合复杂的、开发性的场景，跟固定的流程编排相比，它的泛化性会更好，可以处理自己之前没有见过的场景。

预警任务的根因分析是复杂的、开放的场景，既没有办法枚举所有可能的场景，也无法固定根因定位的步骤，非常适合用这种ReAct的agent模式

开发框架选择：选择适合自己的企业级开源框架

在具体开发框架的选型方面，我们也遇到了一些纠结，我知道很多公司跟我们一样，业务系统都是用JAVA写的，而JAVA的AI生态相比于Python要落后一些。

但是，公司里python人才又相对缺乏，Python跟JAVA之间的相互调用，以及python对已有的中间件体系的兼容又不太好，这些都是使用Python框架的硬伤，很难被解决。在这里我也建议大家，尽量选择一个跟你们公司主流语言一致的开发框架，这样后续的维护成本会更低一点。

我们调研了几款流行的Java Agent开发框架，Spring AI，LangChain4J，Spring AI Alibaba，从模型接入、RAG、会话管理、MCP等多个方面对比，Spring AI Alibaba都处于领先地位。

SRE agent选择了基于Spring AI Alibaba的JManus模块进行开发，JManus是一个通用的AI agent框架，可以对多个agent去做编排，完成一些复杂的通用的任务。我们虽然不是通用的任务，但我们更看重它支持UI界面配置agent和工具，并且原生支持plan to act模式，让agent具备复杂的推理，分解，执行和调度的能力

▐ 菜鸟的改造实践

在实践过程中，我们复用了Jmanus的Plan-Act的运行框架，但每次只选择一个Agent执行，避免多个Agent上下文一致性的问题。当预警任务出现，Planner会组装初始的Prompt，并选择根因分析Agent执行。根因分析Agent是一个循环，每次会调用一个MCP工具，比如根据TraceID查询下游的错慢节点、异常日志等。

如果要扩展到预警的快速恢复领域，可以再增加一个做快速恢复的Agent，同样由Planner选择调度。在这个过程中，如果超过了上下文窗口的限制，我们会调用大模型对历史上下文做一下压缩。

我们还把Jmanus的Web模块改成了SDK，嵌入到了我们的内部应用里边，因为我们用不上Web端的能力，而只看中了它的Agent控制台和Plan-Act的模式，同时，我们还对Jmanus的Planner做了扩展，支持组装更丰富的上下文。

我们使用的部分MCP工具包括了，历史预警任务处理结论、根据traceId查询异常日志、根据traceId查询错慢调用节点、应用的基础监控异常指标、应用在告警之前的变更事件等。

同时我们对于Spring AI Alibaba也做了一些优化改造，比如H2内存DB改成支持MySQL、支持Agent的命名空间隔离，支持预发环境等等，目前已经回馈到了社区

第三部分：如何度量SRE Agent效果

▐ 采纳率的口径问题

为了度量SRE Agent的效果，我们最开始我们设计了 采纳/拒绝 按钮，以及 点赞/点踩 的反馈，期待通过用户反馈来度量效果。

但发现反馈的用户非常少，并且发现这是一个相当普遍的问题。除非在流程强要求，否则用户不会主动反馈的，核心原因大概有两个，

  1. 用户不知道点了之后会有什么后果，或者认为点击 采纳/拒绝，是否意味着承诺或确认了什么，有比较大的心理压力

  2. “根因”本身没有一个绝对正确的黄金标准，导致告警的原因有多个，或者受限于根因颗粒度的问题，用户对AI生成的结论并非100%采纳

考虑到现阶段AI的能力还有局限性，我们目前重点考察的不是传统根因分析的召回率和精确率，而是希望看AI有没有帮助我们的开发者，因此后来我们自己设计了一个「有效率」的口径，有效率 = 覆盖率 * 采纳率。其中，

覆盖率：Agent成功输出了分析结论的告警事件数 / 总告警事件数 * 100%

采纳率：如果Agent定位出来的根因分类，跟最后用户打标的根因分类一致，就认为是采纳。SRE Agent可能还不能做到完全正确，但我们现阶段更关注“有没有用”

如果Agent推荐的分类与用户最终打标的分类一致，我们就认为是有效的。

▐ 采纳率低的核心原因分析：缺失关键上下文数据

目前我们通用类SRE Agent的采纳率在30%~40%之间，这个采纳率不能算高。我们分析发现SRE Agent推荐不准确有两种原因

  1. LLM幻觉或推理能力不足

  2. LLM推理所依赖的数据缺失或质量不足

一般来说，Agent出现问题主要是因为缺少必要的数据。我们现在能获取到的数据包括

  1. 历史预警任务处理结论

  2. 根据traceId查询异常日志

  3. 根据traceId查询错慢调用节点

  4. 应用的基础监控异常指标

  5. 应用在告警之前的变更事件

  6. …

但还有一些数据获取不到，比如业务同学新配置了某条线路、或者新接入了某个大商家，这些事件并没有跟我们的SRE系统打通，我们也没法在根因定位中使用到它们。

换言之，如果要提升Agent的采纳率，就一定要提升提供给Agent的上下文质量。

第四部分：如何提升SRE Agent表现

▐ Context Engineering：提升Agent表现的关键理念

当上下文工程刚流行起来的时候，我们发现这个理念跟我们的实践经验不谋而合。上下文工程是构建一个动态系统，以合适的格式提供准确的信息和工具，让大模型更有效地完成任务。它有几个关键特征：

1. 系统工程：上下文可以来自多个数据源（历史文档、工具返回、用户输入），整合这些数据是复杂的系统工作

2. 动态特性：不同于静态的Prompt Engineering，上下文工程聚焦于与外部交互，动态组装提示词

3. 准确信息：确保提供的信息准确可靠

4. 合适工具：提供恰当的工具支持

5. 适当格式：用合适的格式组织信息

提示词工程、RAG、MCP都包含在上下文工程内，只有给模型高质量的上下文输入，大模型才可能得到高质量的输出。在这里我重点介绍一下Memory

▐ 构建Memory体系，持续提升Agent的采纳率

很多人会把memory误认为就是rag，但这两个是完全不同的技术。rag是把知识库或者文档做向量化，这样大模型就可以用语义的方式搜索到相关的信息，做生成内容的增强。而Memory则是为了维持对话或任务的上下文连贯性。

用一个可能不太精确的类比，RAG像是给大模型一个图书馆，当模型不知道答案时，去图书馆查资料再回答。Memory则是给了大模型一个记事本，记录和用户说过什么、做过什么，避免重复问或忘记。

我们希望为每一个预警任务创建一个memory，记录这一个预警任务的处理经验。成千上万个告警任务，写成千上万个文档肯定不合适。我们用大模型可以自动把用户的历史操作记录，做成这个预警任务的初始的memory，Memory可以由用户自行修改。

当预警任务创建的时候，Planner会查询这个预警任务的Memory，用以指导具体的排查过程，以及操作建议。比如，某一个预警信息里边有错误码，我们把错误码以及对应的文案、SOP也放进去，这样就可以推出来一个非常准确的信息，更容易被采纳

举例，很多告警会把错误码打印出来，我们把错误码和错误码对应的处理方案作为Memory，当预警任务告警时，可以自动推荐出来准确的处理SOP

结语：实践踩坑总结

以上就是我们在菜鸟SRE Agent方面的完整实践经验，当前我们也仍在实践当中，希望我们的踩坑经验能给大家带来一些帮助：

1. 构建开箱即用的Agent：不要做需要用户配置的Agent，因为用户往往不会进行任何配置

2. Memory > RAG：将历史处理记录、应急文档生成更轻量级的Memory，直接放入上下文中

3. 轻量级反馈机制：用户可能不会详细反馈，简单的”有帮助”/“没帮助”按钮更实用

4. 设定合理预期：不要设定过于激进的目标，对核心业务要有容错空间

5. 上下文工程是核心：上下文工程是构建高效Agent的最佳指导思想

6. 选择合适技术栈：企业级应用推荐使用与主流开发语言一致的技术栈

END

阅读更多好文