阿里云最新实践：三重Reward驱动的运维智能体如何突破AI-SRE技术瓶颈？

从ChatGPT发布到现在，各行各业都在忙着把AI技术落地，技术风险领域当然也不例外。不过说实话，在推理模型O1/R1这类东西出来之前，受限于模型本身的能力和技术架构上的约束，真正在风险深度诊断和深度挖掘上取得实质性进展的案子并不多。O1/R1以及DeepResearch这类产品的出现，让一个方向变得清晰起来：把领域知识、推理引擎、平台工具资产这三样东西结合起来，构建深度智能的风险诊断和洞察产品，这条路行得通。

背景

AIOps这个词大家早就熟了，2016年Gartner就提出来过，开创了用人工智能辅助运维决策的先河。到今天，已经快十年了。在这十年里，围绕机器学习和深度神经网络的AIOps技术在智能可观测、智能诊断、智能容量等领域，成果确实不少。但说句实在话，运维领域面临的挑战依然是实打实的，主要表现在三个方面。

第一，系统的规模在过去十年里爆炸式增长，带来的就是架构复杂、调用链路长、依赖复杂、变更频繁，整个系统的复杂性已经远远超出了任何一个专家可以全面掌握的范畴。第二，SRE专家资源依然是稀缺品。除了核心系统和基础设施，绝大多数系统根本没有专职的SRE去深挖风险、做系统性的分析。人员一变动，有些系统的风险就变成了“盲区”。尤其是一些还没关停的老系统，基础保障的资源投入更是越来越少。第三，风险和告警事件的数量依然庞大。虽然稳定性工作一直在牵引，应急类事件也在持续分析和治理，但每天生产环境里还有大量告警信息处于“无人问津”的状态，更别说那些没有触发事件的隐藏风险了——人力投入ROI太低，风险持续挖掘这件事，在业界始终很难持续下去。

业界进展

运维智能体具体是啥时候冒出来的，确实不好给出一个精确的时间点。但这个领域的探索，其实已经有好几年了。直到2024年底，业界才逐渐对运维智能体的探索方向有了相对一致的共识，AI-SRE、SRE-Agent这些概念也被越来越多的人接受。与此同时，一系列产品和创业公司陆续浮出水面。比如微软发布了SRE-Agent产品，能做故障分析定位；Cleric-AI推出了AI-SRE产品，据说可以像一个高级SRE一样处理生产问题；ResolveAI作为运维智能体领域的代表，获得了李飞飞等数千万美元的投资。除此之外，主流的云厂商和业界大公司，基本也都发布了自己的运维智能体，在一个或几个运维场景里尝试处理生产问题。

不过，上面提到的这些产品，主要还是聚焦在通过智能体解决运维过程中的某一个或某几个点上的问题。到目前为止，业界还没有一个完整的、长远的关于运维智能体系统架构和产品演进方向的系统性阐述。

技术判断

这两年做AI应用，最大的挑战不是基础模型的能力不行，也不是场景效果调不好，更不是短暂的同质化抄袭和竞争，而是如何在技术日新月异的大背景下，找一个既面向当下又符合未来的发展方向。找到这条路，我们花了两年。

首先，有一个基本判断：任何领域的智能体，本质上都是一个包含了领域知识、技能和推理思考范式的多智能体系统。拿技术风险领域来说，这个系统主要会经历三个发展阶段。

• 阶段一、基础智能：结合LLM和技术风险，解决领域知识理解、数据使用和工具使用这些痛点，让它具备基础的风险分析、洞察和处理能力。

• 阶段二、中级智能：通过强化学习和推荐系统等技术，不断提升系统智能的能力和场景匹配的精确度，技术上实现智能演进的闭环，业务上能自主完成风险定位、分析和诊断。

• 阶段三、高阶智能：构建基于场景自适应学习的闭环，从被动响应转向主动探测、学习、防御、总结和进化，走向真正的高阶智能。

在技术演进上，核心观点是：所有AI原生的多智能体系统，本质上都是一个找最优策略的奖励优化问题。具体来说，一个AI原生的智能系统，其技术核心的演进方向主要是找三类奖励：

1. 多智能体协同奖励：不断优化并寻找领域内多个智能体之间最佳的协同范式。
2. 上下文工程的奖励：通过各种不同的策略，找到基础模型最偏好的上下文。
3. 强化学习的奖励：通过构建基于场景的在线强化学习系统，找到领域模型最佳的权重。

基础概念介绍

在详细阐述这三个奖励之前，有必要把多智能体、上下文工程和强化学习这几个基础概念稍微梳理一下。

什么是多智能体？

目前关于智能体的概念非常多，有宏观的、微观的、笼统的、具体的。这里说的智能体，是从技术层面展开的相对具体的概念。在研究了几个智能体框架和理论之后，可以总结出Agent核心的几个特性。

• Profile模块：做Agent的角色认定，回答的核心问题就是“我是谁？我在哪？我该干什么？”。不管是在人与人之间、人与智能体之间，还是智能体与智能体之间的协同，角色认定都是基础。

• Memory模块：记忆模块，主要用来存储、获取和检索信息，包含感知记忆、短期记忆、长期记忆和混合记忆。

• Planning模块：计划制定模块，支持单步指令遵循、多步CoT推理，以及基于ReACT的动态推理规划等多种形式。

• Action模块：执行模块，负责执行智能体的具体规划和决策，完成实际任务。

基于以上信息，可以给智能体下一个定义：智能体是一种具备角色信息和记忆功能，能够进行自主规划并决策，从而推动任务完成的智能系统。

那什么是多智能体呢？顾名思义，多智能体是由多个智能体组成的、多角色之间相互协作的复杂智能系统。目前业界主流的协作模式主要有两种。

1. 基于Group的群组协作模式
2. 基于组织架构的团队管理模式

基于Group的群组协作模式

图-1.1

这种模式里，多个智能体在同一个群组里对话，每个智能体都能看到所有消息。Manager Agent通过@方式来分派任务，智能体之间通过Message进行通信。

基于组织架构的团队管理模式

在这种模式下，除了Manager Agent之外，每个智能体只能看到当前本轮次的消息，直接接收Manager的指令并汇报自己的任务执行情况。

多智能体相比单智能体，优势在于可以通过多个角色分工协作完成更复杂的任务。核心在于结合实际业务场景，找到最佳协作方式。这也是为什么我们说多智能体技术的核心是不断优化协作的奖励——不断寻找领域内多个智能体之间最佳的协同范式。

什么是上下文工程？

上下文工程这个概念最早可以追溯到2020年，但直到今年才被大范围重视。原因主要有两点。第一，在推理模型和长上下文模型出现之前，只能靠简单的Prompt来激发模型能力，更长的、更复杂的上下文模型根本理解不了，所以也谈不上上下文工程。第二，各领域花了两年时间精心准备数据做SFT，结果发现基础模型迭代之后，尤其是R1这类模型出现后，SFT的效果还不如优化好上下文，投入的资源和人力的差距就更不用说了。

上下文工程顺理成章地引起了重视。今天开发一个好的智能体或智能系统，最核心的手段就是上下文的处理。大模型的性能，从根本上取决于推理过程中提供的上下文信息。

上下文是提供给模型做推理任务的。要理解上下文工程，先要理解大语言模型的原理。生成式大语言模型的本质是，给定一个上下文输入，通过最大化条件概率生成输出序列。

在基于Prompt的范式里，上下文是静态的。但在Context工程中，上下文被重新定义为一个动态的信息结构，由多个组件组成。这些组件经过一系列函数分类、过滤和格式化，最终通过一个高级函数装配起来。组件构成如下：

1. 系统指令与规则（Context Retrieval and Generation）
2. 可用工具（MCP & Tool-Integrated Reasoning等）
3. 拓展知识（通过RAG、GraphRAG、上下文处理获取）
4. 持久化信息（Memory System, Context Management）
5. 动态状态（用户、世界、多智能体系统）
6. 用户即时的请求

大语言模型的上下文，就是由系统指令与规则、可用工具、可用知识、记忆、当前状态、用户请求等一系列输入构成的一个信息集合。

上下文工程，就是找到一组理想的上下文生成函数，以最大化语言模型输出的质量。所以它本质上是一个正式的优化问题，公式化表示为：给定一个特殊任务实例，通过函数F生成任务上下文，目标是达到真实值或理想输出。优化受到模型上下文长度的严格约束。

既然上下文工程是一个优化问题，我们将其系统化演进划分为三个阶段。

1. 阶段一：具备上下文处理能力，提供统一的初级策略。
2. 阶段二：提供上下文优化策略引擎，支持各种动态优化配置。
3. 阶段三：基于模型架构与业务场景，系统自动智能调整上下文。

所以上下文工程的核心是不断优化上下文组装的奖励，通过各种不同的策略，找到基础模型最偏好的上下文，最大化模型输出的质量。

什么是强化学习？

强化学习是机器学习的重要分支，研究的是智能体如何在与环境的交互中，通过试错和反馈来学习最优策略，以最大化某种累积奖励。与其他机器学习方法不同，强化学习的核心在于它基于“奖励信号”进行决策优化，而不是依赖标注数据。

从强化学习的概念可以看出，它是结合智能体与环境，通过不断交互来找到最优解的过程。如果把多智能体架构和上下文工程分别看作面向局部的协作优化和模型输入优化，那么强化学习就是围绕智能体与环境的系统性优化，也是任何智能体系统演进的终极目标。

DeRisk——AI原生的风险智能系统

介绍完基础概念和技术判断，接下来聊一聊我们在AIOps领域的系统架构设计和产品发展理念。在开始技术架构介绍之前，先明确一下我们构想的AI原生风险智能系统到底要做什么。

什么是DeRisk？

核心特性：

技术架构：

在前面已经明确了一个AI原生系统的核心是三个优化问题。因此在目标架构设计上，第一天就应该面向终态，思考系统架构的演进与进化逻辑。这三个进化分别是：多智能体协同的进化、上下文工程的进化、强化学习基于实际环境的在线学习进化。基于这些需求，我们调研并探讨了市面上主流的技术路径，发现围绕Multi-Agents架构和上下文工程，可以满足系统架构演进的目的，同时Context工程与多智能体架构可以很好地与Agentic RL训练范式打通，为未来端到端的技术架构演进打好平台基础。

同时，我们也观察到，目前主流的业务落地产品还是以Workflow的技术架构为主。但Workflow的范式仅仅是之前工程架构的延伸，无法达到智能演进的目的。虽然Workflow可以满足短期业务落地的效果，但同时也锁死了智能演进的路线。

下图是我们AI原生风险智能系统的总体架构方案。总体分为三个层次：基础平台层、智能迭代层、应用场景层。基础平台层主要负责领域知识处理、领域工具资产构建、多智能体与Context工程研发等基本能力，通过这些基础能力可以快速搭建一个技术风险领域的场景智能体。

在基础平台层，围绕多智能体架构主要有三个核心模块：知识引擎、MCP/工具资产模块、推理引擎。在这些基础模块之上，我们提供了统一的记忆层，以及常见的领域通用Agent，比如Trace智能体、监控智能体、日志智能体、代码智能体、搜索智能体、报告生成智能体等。

推理引擎

推理引擎是基础平台层的重要模块。每个智能体都有一套推理引擎，不同的智能体可以根据自己的角色与任务选择不同的推理范式，如SOP推理范式、ReACT推理范式等。推理引擎是决定一个任务如何被智能体处理的核心模块，实现上强依赖于基座模型，在系统中起决策、推理、计划、执行分发的核心作用，可以说是智能体的大脑。在实际运作中，推理引擎感知到外界变化或输入后，根据输入动态分析决策，最终完成任务。过程中人可以通过Human in Loop的能力与推理引擎交互，干预整个决策和执行过程。

知识引擎

知识引擎同样非常重要。它的作用除了不断收集和丰富技术风险领域知识外，更重要的功能是如何智能化地处理和理解这些知识与文档。知识引擎设计中的核心能力包括：

1. 智能文档处理：处理各种格式的文档，如PDF、语雀文档、图表、业务架构图等。
2. DeepDoc：文档处理只是第一步，如何理解文档中的内容并做好分类保存，也是一个很大的挑战。
3. 统一存储：提供统一的多模存储结构，支持对象、KV、向量、图等各种存储扩展。
4. 丰富的RAG检索策略：支持各种RAG检索，可以满足按场景调优的诉求。

工具资产

MCP协议出现之后，给工具资产的构建提供了标准参考，很大程度上提速了工具资产的构建。当然，在实际场景中还需要结合LocalTool、API等各种形式组合使用，以达到最高效的场景构建目的。

产品思考

从产品角度出发，DeRisk的产品架构也分为三层，从上到下依次为产品层、框架层、调度层。产品层是基于知识、Agent和技能构建多智能体场景，针对不同场景实现不同的交互与可视化逻辑。框架层方面，DeRisk提供了基于Python的开源、开放的开发框架，其中DeRiskCore围绕多Agent架构提供了基础开发模块，DeRisk-Ext支持各个模块及业务场景的自定义扩展，DeRisk-Serve是服务层，处理各种服务端的交互与通信。最下面是调度层，主要解决系统内部多智能体之间高效协作和执行的问题。多智能体之间通过消息协议，可以实现不同Agent任务分布式运行在不同计算节点上，最大化执行效率。

关于AI原生的产品，我们认为主要有三个核心能力模块，依次为构建态、运行态、使用态。同时，AI原生产品的演进也分为三个阶段。

• 阶段一、基础能力建设：构建基于Context工程的多智能体构建、运行、使用的全链路完整产品形态，并形成产品架构标准。
  
• 阶段二、初级智能：集合知识、工具、智能体以及场景订阅使用，构建初级智能化能力，如搜索、生成、AI-Native流程等。
  
• 阶段三、高级智能：结合RL与推荐系统，构建持续进化的智能系统能力，包括模型能力提升、Context自动优化等，并通过推荐系统解决能力与场景匹配的问题，不断提升系统的好用程度。

实践案例

接下来，以AIOps领域两个典型的案例来说明如何基于上述技术方案构建领域深度分析智能体。

DeepRCA

智能体架构设计

第一个场景，构建一个领域深度报警诊断智能体。对于一个告警分析场景，需要分析的信息包括：监控指标、日志报错、业务链路、变更信息、代码，以及最终的告警分析报告生成。因此，在Agent协作关系设计上，每一类任务的Agent天然可以被划分为一个子Agent，每个子Agent可以通过深度分析推理得到此领域的最终结论。在协作模式上，我们选择了TeamMode。原因有两个：一是运维场景下，日志和监控的数据都非常庞大，如果全局信息共享，对上下文处理的挑战极大；二是分析是否有变更与日志报错之间不存在本质的逻辑关系，通过TL进行最终汇总分析，即可达到综合分析的效果。

智能体构建

设计好智能体架构后，下一步就是构建智能体。一个多智能体由多个单智能体按照一定协作模式组成，所以构建多智能体时，首先要分别构建各个子智能体，再通过协作模式组织起来。下图是具体的构建流程。

运行调试

在运行调试环节，通过一个简单的深度告警分析案例，展示了DeRisk中多智能体构建的操作流程。目前，Trace分析、根因定位相关的智能体已经在蚂蚁生产环境规模化应用，相关能力也已经部分集成到蚂蚁的现有产品中，比如云图、监控等。

智能SQL诊断分析

第二个案例是SQL风险分析的多智能体。构建流程与DeepRCA基本一致，这里主要介绍其多智能体架构设计。对一个SQL诊断专家来说，主要功能由DB监控、DB元数据、SQL索引分析、TopSQL分析、报告生成几部分组成。与DeepRCA不同，SQL索引分析的流程相对明确，所以在规划上采用了一个基于SOP的规划范式——领域专家先根据经验写好分析思路知识库，单独编写一个规划专家，严格按照专家编写的分析思路进行分析。

总结展望

时代的浪潮滚滚向前，一代SRE有一代SRE的使命。十年前，随着互联网和大数据等技术的兴起，SRE的工作职责从OPS转向了Site Reliability。如今，随着AI技术的日新月异，Vibe Coding逐渐成为主流的研发范式，SRE这个与研发共生的岗位，也正在面临巨大的挑战。一方面，大量低质量AI代码的出现，使得将大模型技术运用在运维领域、解决超大规模代码运维的诉求在爆发。另一方面，AI原生的应用产品对运维架构体系与范式提出了新的要求。对于技术风险来说，通过AI解决问题，早已不是一道可做可不做的选择题，而是一道如何做好的攻坚题。经过持续不断的探索，我们对AI的理解和认识越来越深刻，对未来的路径也更加清晰，信心也比以前更足。同时我们也关注到，大量的领域和场景对构建AI原生产品与技术架构有强烈的需求。本文中提到的技术和产品，会在接下来的两周内逐步进行开源。