异常处置包含异常发现、问题定界和根因定位等环节，高效的异常处置流程对于保障平台的稳定性起到至关重要的作用，然而平台本身的复杂度以及海量的多元异构数据给异常处置带来了巨大的挑战。如今，大模型等 AI 技术的演进则为应对这些挑战提供了新的思路。在 2025 年 InfoQ 举办的 QCon 全球软件开发大会（ 北京站）上，来自阿里云的算法专家张颖莹发表了题为《AI 驱动的智能异常处置：从异常发现到根因定位》的演讲。她从阿里云计算平台的运维场景出发，分享了从异常发现到问题定界和根因定位各环节的算法选型和设计思路，包括通用的时间序列异常检测、高效的日志聚类和精准的多 Agent 根因定位框架。
预告：将于 2026 年 4 月 16 - 18 召开的 QCon 北京站策划了「Agent Ops：运维新生产力」专题，将深入讨论 Agent 如何与现有技术栈深度集成，并演进为具备长期记忆与自我进化能力的运维实践。如果你也有相关方向案例想要分享，欢迎提交至 https://jinshuju.com/f/Cu32l5。
以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。
阿里云大数据运维背景
我们阿里云计算平台整合了整个阿里的大数据和 AI 的能力，并以产品化、平台化的方式支撑了我们集团内部与云上各行各业客户的众多非常核心的业务场景。这里列举其中几个比较典型的平台。
比如 MaxCompute 大数据计算服务主要负责大规模数据的离线计算。大家日常在网购后经常会在手机上去追踪自己的包裹，这些菜鸟的物流数据产出就依赖 MaxCompute。
还有实时性要求相对较高的场景，比如自动驾驶场景，车机系统会对司机的危险驾驶行为发出实时警告。像这一类比较追求时效性的场景，往往就依赖 Flink 这样的实时计算引擎。下一个是 Hologres 实时数仓，大家在手机淘宝上检索商品关键词时，它会在底层进行实时的交互式分析，为大家呈现实时的检索推荐结果。
另外随着大模型越来越火爆，大家对机器学习模型相关的训练、微调、在线服务的需求都有了爆发式的增长。这一类的模型训练、微调、在线服务都可以一站式在我们的机器学习平台 PAI 上完成。
可以看出我们的这几个平台上层支撑的业务都非常重要，所以做好这些平台的运维也非常关键。但传统的运维模式很容易让运维人员变成背锅侠的角色。所以我们计算平台也专门设置了一支运维中台研发团队来负责所有大数据和 AI 产品的统一运维管控。我们也一直利用“AI+ 数据 + 工程”的手段来提升整体运维效率。
稳定性作为运维的基石，其重要性是毋庸置疑的。但对于系统来说，异常的发生很难避免，怎样在异常发生时能进行快速高效的处置，对于整个平台的稳定性是非常重要的。另一方面，随着我们的用户对云服务厂商服务水平的要求越来越高，精细化运维已成为行业趋势。另外像我们前面提到的这些大数据平台，它们的底层都是超大规模的计算集群，这些集群无时不刻都在产生海量的数据，这些海量数据对我们的异常处置也带来了更多的战。
我把整个异常处置层面我们面临的挑战总结成三个层面。首先是面对这样复杂的系统，我们怎样从这个系统运行的蛛丝马迹里全面发现各种异常，确保监控的覆盖率。第二个层面是面对这么多异常告警，我怎样从这些告警风暴里真正剥离出最关键的信息，从而减少误报对运维人员的干扰。第三个层面是当异常发生时，我怎样快速定位到问题的根本原因，并采取针对性的措施，对症下药来让异常快速恢复，减少对用户带来的损失。
异常发现和告警降噪
接下来我们会为大家分享我们是怎样逐一来攻克前面提到的三个挑战。
首先是异常发现的层面，我们团队构建了非常丰富的异常检测相关的算法，力求实现异常的全面覆盖及精准发现。
我们在这里梳理了 4 个典型场景，我们针对不同形态的数据和不同的场景都会选择它最适配的算法。
首先是单指标异常检测场景，比较典型的应用就是我们整个系统的可用性监控。比如这个平台整体的流量、性能、成功率，这些指标和用户自身的业务周期是非常紧密相关的，因此它经常会呈现出比较复杂的多重周期性。所以在这里我们自研了一套鲁棒的周期分解算法，来对这些曲线中的多重周期性进行精准的识别和分解，从而更好地做到异常的发现。
第二类是多指标异常检测场景。当我需要判断一台机器是不是存在异常时，可能单独去看其中的某一条指标是没有太大参考价值的，我需要综合去看这个机器所有维度的指标。在多指标异常检测这边，我们直接选用了开源的多指标异常检测模型。虽然它相比单指标异常检测可能会牺牲一定程度的可解释性及性能，但它可以更好地把握多指标之间的内部关联性，从而提升检测的精准度。
第三类是基于分布的异常检测。在大数据运维的场景里，我们经常会面临着这样的问题，就是当我的集群性能变慢时，我不单是要检测单个指标、单个作业是不是变慢了，而是希望去看整个集群或整个平台的作业运行的分布是不是有异常的变化。针对分布的异常检测，我们也自研了一套异常检测算法。
除了指标之外，日志也是非常重要的一种可观测的数据。日志数据最大的挑战是它的体量非常庞大，所以在这里我们先选用了业界性能比较高的日志模板提取算法，然后我们会基于提取出来的日志模式去判断它是不是新增的异常，或者它的模式是不是有暴增的变化。
接下来我们重点给大家展开介绍一下前面提到的两类自研算法。
首先是针对单指标的场景，我梳理了我们运维场景里最关心的几类典型异常，包括均值变化、方差变化，也就是抖动频率的变化，还有尖峰深谷的异常、断崖式跌落的异常，还有趋势型的异常。大家可以看到梳理出来的异常可能看起来还比较明确，但实际上这些异常融合到真实的业务数据里时，非常容易受到数据本身的其他周期性的干扰，使得检测变得非常困难。
所以在这里我们构建了 周期分解算法，它的核心思想是采用了分而治之的策略。首先从一条时间序列里把不同频率的周期逐一剥离出来，然后再针对剥离出来的每一重周期去精准计算它具体的周期长度，从而更好地把握整个数据的周期性特点。做完周期分解后，我们会进一步利用不同类型的统计检验方法，来分别对应检测前面提到的这几种典型异常，从而实现用一套算法框架就能够覆盖前面提到的多种类型的异常，使得这一套单指标的异常检测算法能够在运维领域具备更强的普适性。
第二类是基于分布的异常检测。大数据运维经常会面临的痛点，是当我需要做整个集群性能的异常检测时会面临两个挑战。首先是整个集群上运行的作业数量非常多，如果我对每个作业都去检测它有没有运行变慢，耗费的成本会非常高。而且即使我做到了对每个作业的检测，但实际上我并不会关心单一的某作业的波动，因为很多情况下可能用户购买的资源不足，他自己的资源组里面的作业之间也会进行资源的争抢，所以也会出现单作业变慢的情况。但我们真正需要关心的是整个集群作业性能异常、变慢的这种趋势。
所以我们把整个集群作业运行时长的分布图构建了出来，然后借鉴了优化领域非常经典的运输问题，结合基于重构的深度学习模型来进行异常检测。我们可以把整个集群的作业运行时长的分布图想象成土堆，然后当这个土堆向右边运输时，我们增加一定的惩罚项，从而更好地检测出整个作业运行时长分布图向右偏移，也就是整个集群性能变慢的这种场景。当然我们还在深度学习模型里选用特殊的门控机制，来更好地应对训练样本当中的噪音问题。
到这里我们已经通过多种类型的异常检测算法实现了异常的全面覆盖。随之而来的问题就是面对这么多的异常告警，运维人员怎么判断到底哪些异常才是需要第一时间响应的。所以我们需要对这些告警进行进一步的精细化分级。我们主要从两个方面来进行告警的精细化处理，分别是影响面拉取和问题定界。
影响面拉取指的是当我们的主指标异常触发了异常工单后，我可以根据整个拓扑关系拉取到主指标所关联的子指标。然后我通过时间序列的下钻算法，可以量化出来每个子指标对主指标的贡献程度，以及它自己相对于历史的异常度。综合这两个维度，我可以计算出来这一次的异常所波及到的影响面到底有多广。一般来说波及面越广的异常，运维人员自然要去更加高优地响应。
第二类是问题定界。在大数据的场景里有很多异常是因为用户自己的操作失误引起的，比如像一条 SQL 语句，如果它的语法就存在错误，自然会运行失败，但运行失败就会产生报错日志，甚至会影响到用户实例本身的成功率。但像这一类语法错误导致的异常，我们的运维人员并不需要第一时间介入处理。运维人员真正应该关心的是由平台问题导致的失败或者任务的异常，所以我们需要对用户作业的报错日志进行更加精细化的分析。
这里我们首先用前面提到的日志聚类算法对异常时段的所有日志先进行聚类，聚类完成后我们会提取出其中典型的日志异常模式，然后和我们日志知识库当中的标签去匹配，这个标签就可以标识出日志到底是用户问题还是平台问题。日志知识库的标签从哪来？一方面可以由我们的运维专家去人工标注，另一方面我们现在也在用大模型做这方面的提效。我们会利用大模型事先生成预标签结果，然后让专家审核。
基于影响面和问题定界的结果，我们就可以对告警分成不同的等级，包括需要立即响应的故障性异常，还有红灯、黄灯，还有可以稍微延迟处理的风险性异常。这种做法首先可以让我们不遗漏任何一种风险，同时又可以更好地分配运维专家的精力和关注度，确保他们能够更高效地处置那些真正紧急的异常。
多 Agent 根因定位框架
到这里我们已经解决了异常发现环节的问题。但实际上在异常处置流程里，最耗时也往往最困难的点在根因定位这个环节。因为这个环节涉及到的数据还有工具都非常繁杂，而且即使存在一套非常标准的运维排障流程，但真正具体到每一次故障时，依然需要结合当时的场景和数据的具体问题做具体分析。所以根因定位往往也只有那些经验非常丰富的运维专家才能够做到真正高效的处置。也正是因为根因定位存在着这样的难点，它近年来也一直是学术界、工业界都非常关注的热门话题。我们团队也一直在根因定位这个方向上不断升级策略和算法，现在也引入了多 Agent 的框架来解决这样的问题。
在具体介绍我们的策略之前，我们可以先简单回顾一下 Agent 的核心要素。这几个要素对构建高效的智能体来说非常关键，它也是我们后续设计我们整个多 Agent 根因定位的核心思路。首先是角色的设定部分，我们通常会在大模型的 prompt 里交代它的角色定位，包括它的业务背景，使得它能够在领域上具备更好的专业度，同时也能够更加明确它自己的任务产出到底是什么样的形式。第二类是长短期记忆，通常我们会通过 RAG 的方式引入外部私域知识，进一步提升大模型在私域的专业性，更好地让它了解上下文。第三类是好的工具模块，让大模型具备更强大的主观能动性，拓展它的能力边界。最后是自主编排，对大模型来说非常关键，因为它直接决定了大模型能不能很好地做到任务的拆解，以及具体执行步骤的编排，它很大程度上决定了大模型能不能够解决根因定位的问题。
接下来我们就分别介绍我们是怎样基于这几个核心要素来构建多 Agent 根因定位框架。首先是角色设定的部分。
我们可以回忆一下，当我们日常出现线上问题时，运维团队是怎样工作的？通常他们会成立故障应急小组，在这个小组中会有各个模块的负责人，他们会分别排查各自的模块目前的信息，并且判断自己到底是根因方还是受影响方。然后他们也会和自己的上下游模块做沟通，最终他们的结论会汇总到故障应急负责人这边，他会去对全局的信息做整体汇总，并给出最终结论。
我们希望基于大模型构建出来的诊断系统也能够具备故障应急团队这样的效果。在这个团队里面，人的分工是非常关键的，每个角色都应该具备自己的专业度和特长，所以单一的 Agent 通常不能满足这样复杂任务的需求，所以我们引入了多 Agent 的框架。我们是按照系统的模块来设定每个 Agent 的角色，比如会有专门的存储 Agent、调度 Agent、网络 Agent 等。在 prompt 里，我们会内置模块相关的背景信息，使得它们可以对照现实世界里每个模块的 owner 这样的角色。除了模块 Agent 外，在上层我们还会有系统 Agent 的角色，就相当于是故障应急负责人。它可以收集每个模块 Agent 的结论，并且给出最终的判断。
在完成了 Agent 的角色设定后，接下来很重要的就是要丰富每个 Agent 的装备库。我们构建了 4 大类工具，首先是算法服务类的工具，包括前面提到的时间序列异常检测、日志异常检测能力，还有因果推断能力。这些服务都会构建成在线服务的形式，可以非常方便地对接其他系统，或者作为 API 来让 Agent 调用。
第二类是 RAG 工具，它在私域的智能问答领域里是非常核心的技术，在根因定位环节里同样发挥着非常关键的作用。比如当我们需要对照历史的相似故障来参考它的排障经验时，或者当我遇到一些指标和日志，但可能不太清楚它的具体含义是什么时，都需要参考对应的文档，把对应的知识检索回来，从而给大模型提供更丰富的背景知识。
第三类是运维分析类工具。我们的运维人员构建了很多集成了他们专家经验的分析诊断流，比如针对单个作业的诊断，还有针对整个单机的诊断，还有网络层的诊断等。这一类诊断工具理论上都可以由大模型来自主编排完成，但实际上因为这些工具之前就已经沉淀好了，而且我们利用编排好的诊断流可以直接得到非常明确的结果，所以在很大程度上可以减少大模型的 token 消耗，来提升整体根因定位的效率。
第四类是外部插件。现在很多大模型应用平台都搭载了非常丰富的生态系统，有着插件市场这样的概念，在里面很多第三方的开发者都会贡献他们自己研发的分析工具，比较典型的包括在线检索类工具、代码编写类工具，还有 chatBI 类的工具。现在这些工具都可以直接拿来为我们自己所用。
通过这些工具集的构建，我们就让 Agent 同时具备了专业的运维分析能力、专业的算法分析能力，甚至还具备一定的通用基础开发能力，这样它就能有更好的武器应对更加复杂的根因定位场景。
第三部分是关于编排可靠性的提升。
关于编排，我们会面临这样的挑战，就是一方面我们希望能够尽可能释放大模型自主编排的灵活性，这样它在以前没有遇到过的故障场景也能发挥特定的效应，而不是只能针对历史重复出现的故障才知道该怎么做。但另一方面大模型编排结果是否可靠，可能直接决定了这个故障是不是能够及时恢复，在这个方面我们的容错性是非常低的。所以这里的最大难点就是怎样在释放大模型编排灵活性的同时，又能进一步提升编排结果的可靠性。
在这里我们采取的策略是固定工作流编排和自主编排相结合的混合策略。一方面我们会把运行性能相对较高，并且对根因诊断非常关键的工具，直接编排到前置的工作流里。这些工具直接执行完后，我会把它的结果输入到大模型里，再让大模型自主决策是不是还需要调用额外的工具来做进一步排查，才能够得到最终的根因推断结论。
然后在大模型自主编排这一部分，我们也采取了很多策略来提升它结果的可靠性。任务分解部分我们主要采用的是 react 框架，也是现在比较主流的框架。大家在实际应用里也可以直接把它作为 baseline 来作为后续提升的参照。另一部分是记忆增强，我们通过检索外部的 SOP 来让大模型进一步校准它生成的 SOP 的可信度。第三部分是加入了反思机制，我们会让大模型在整个决策过程动态反思中间过程可能会有哪些改动来保证灵活性。
除了任务分解、记忆增强和反思机制之外，还有一些策略可以进一步提升它的编排可靠性，包括多计划选择，还有引入外部规划器来辅助它生成这样的策略。我们也计划在后面再对这些策略做更详细的尝试。
最后一个问题涉及多 Agent 框架的协同。我们前面聊的都是怎样让 Agent 自己变得更好，接下来的问题是我有这么多个 Agent，怎么能够让它们更好地协同。
现在有非常多的 multi Agent 编排框架，他们在系统里都会内置编排好的多 Agent 协同工作流。但这些默认的工作流，在我们的场景里或多或少都会存在一定的弊端。比如像顺序执行的工作流，上游节点在做决策时是不知道下游节点信息的，所以会存在着一定的信息不对称，会导致它得到片面的结论，而它的结论可能又会进一步影响到下游节点的决策，会形成一定的误差累积效应。第二类是层次结构，虽然看起来有顶层节点来对大家的信息做汇总，但实际上下游节点之间依然是不存在任何信息交换的，同样会导致它们自己得到比较片面的结论。第三种圆桌讨论的模式，看起来大家的信息可以在桌子上进行非常充分的交换，但它最大的弊端在于缺少明确的领导者，所以大家的讨论可能会非常发散，聊着聊着可能就偏离了主题，很难在限定时间内得到非常明确的结论。
考虑到这些固定编排模式的弊端，我们自研了一套基于神经网络反馈机制的工作流。它的核心思想也非常简单，我首先会根据模块之间的拓扑结构设定单向传导的工作流，我们称之为前向反馈。在前向反馈的基础上，我额外增加了后向反馈的机制，实际上就是让前置 Agent 有机会修改自己之前可能得出的错误结论，然后最终大家的结论依然会汇总到系统 Agent 这边来。这样的好处是一方面我可以在一定程度上弥补信息不对称的问题，同时也能把整体的推理次数非常严格地限制在预设的范围内，减少盲目发散的讨论。
通用异常处置平台
前面介绍的更多都是算法层面的设计，而好的算法最终还是需要真正集成到我们的平台上，才能真正融合到运维人员的工作流里，发挥出真正的效用。所以工程平台的建设也非常关键。在这里我给大家分享一下我们怎样来构建通用的异常处置平台。现在我们各个产品的运维异常处置流程都可以在这个异常处置平台上来进行，很大程度上提升了我们计算平台整体异常处置的效率。
整体架构最底层是数据层，我们为运维场景里这些经典的数据模式都安排了最适合它们的存储方式，包括指标、日志、拓扑、文档、事件等，使得它可以在后续的分析环节里做到非常高效的数据抽取、根因分析。
数据层之上是我们非常核心的算法服务层及大模型服务层。算法服务层里搭载的是前面提到的时序、日志、根因定位、因果分析，还有检索这类非常基础通用的算法，这些算法会部署在 PAI-EAS 上变成在线服务，可以供其他系统直接调用，也可以作为工具集成到 Agent 里。
大模型相关的这一部分，除了前面提到的 prompt 工程，还有工具的调用，还有工作流编排。对于完整的大模型服务而言，如果你不是 demo，如果你想要真正上生产的话，还需要考虑很多因素，比如像可观测能力，还有资源的管理隔离能力等。所以想要搭建好大模型应用服务，还是需要搭配非常好的大模型应用构建的平台。幸运的是现在也有非常多的这样的平台，包括商业化的、开源的，都具备了非常强大的能力。但对我们来说，我们还是需要根据我们自己的业务场景去选择最好的、最适合自己的平台来进行构建，才能提升效率。
接下来也想和大家进一步分享一下我们在选择这样的大模型应用开发平台时会从哪几个角度来考虑。我们主要会从三个层面，第一个是应用构建本身的便捷度和产品应用性，第二个是 LLMOps 能力的完备度，最后是平台本身的开放度。
在应用构建方面，我们会重点考虑我在这个平台上是不是可以非常便捷地完成非常复杂的业务工作流的编排，最好就是拖拉拽的方式就可以完成复杂的编排任务。其次是这个平台上面是不是同时具备了微调能力，这样我就不需要在各个平台上频繁切换，能够在平台上一站式完成整个模型的微调和最终应用的部署搭建。第三个是像 RAG 的经典组件，我在这个平台上是不是能够直接复用，减少额外的开发工作量。最后是我在这个平台上面搭建的服务，是不是能够非常便捷地和最终的交互出口承接，不需要额外再构建中间的一层服务来进行引流。
第二个大的层面是 LLMOps 的能力，它直接决定了整个大模型应用服务的稳定性，以及后续性能优化的空间。所以我会重点关注平台是不是具备一定的模型加速能力，资源管理的能力也非常重要，就是在突发流量打进来的时候，你是不是能非常方便地帮我做资源扩容。还有我不同的大数据产品之间肯定是要做隔离的，你是不是具备完备的资源管理隔离的体系。可观测性也是非常关键的，当我大模型推理失败的时候，是不是能够非常便捷清晰地看到到底是哪个环节、哪个工具调用出现了问题，方便我进行问题的快速恢复和改进。最后是模型测评的能力，因为现在基础模型发展非常迅速，所以我希望能够在平台上非常便捷地做模型效果的测评，来方便我选择最适合这个场景的基模。
第三个层面是开放性，开放性直接决定了我在你这个平台上是不是能够更好地利用别人开发的能力，以及我是不是能够和开源的生态做更好的兼容。这里首先要考虑你的插件市场是不是足够丰富。第二个方面，像现在比较火的 MCP 协议，你是不是能够天然支持？还有同外部系统以及开源框架的对接，我现在迁移到你的平台，是不是能够更好地做到无缝的迁移，我后续是不是还能够持续用到开源生态的创新性成果，这些都非常关键。
基于这些考虑因素，我们现在选用的是阿里云的百炼来搭载大模型应用，当然大家也可以结合自己对这几个因素的优先级的排序，选择更适合自己的平台。我们选择百炼，一方面是它在我前面提到的几个维度上相对来说是比较完整的，同时它在应用类型上也非常丰富，既包括我前面提到的固定工作流式的编排，也提供了以 RAG 为核心的智能体应用，同时它还提供了智能体编排应用，可以把前面提到的多种不同类型的应用全部整合进来，做到混合编排。
另外它整个任务编排的产品界面是相对来说比较友好的，我在上面可以非常便捷地拖拉拽来完成复杂工作流的编排。最后在整个百炼的项目空间里，我可以观测到整个服务的调用情况，每一次调用都可以点开详情看每个工具的输入输出到底是什么，是不是符合预期，方便我进行问题的排查。
前面我们已经完成了大模型应用搭建的部分，接下来我们具体聊一下整个异常处置平台到底包含了哪些核心的模块。
首先这个平台的入口也就是告警源，除了前面提到的算法检测结果外，在我们实际的业务里它还会包含 SRE 自己在监控系统里设置的监控告警，当然还有用户来提的工单或者人工补录的情况。每一种告警来源，我们都会给它生成异常工单，这个工单里会包含 4 个非常核心的模块，首先是异常现场，然后是定界定级的结果，还有根因定位的结果以及快速恢复。
异常现场主要呈现出这一次开工单的原因到底是什么，触发的指标和日志到底是什么样的，来方便运维人员在接手工单时快速了解问题的背景。然后是定界定级的结果，会具体呈现出这一次异常的影响面，以及算法得到的分级过程。根因定位会展现出多 Agent 框架定位的结果，我们现在会得到根因模块的结论，同时大模型也会提供出得到这个结论的推理依据。同时对于每个模块 Agent，我都可以点开详情查看它的工具调用情况。最后快速恢复的部分，我们现在还在相对比较初步的阶段。目前主要是做的是检索历史的相似工单，这样运维人员可以在新的工单里直接点击跳转到历史工单里查看当时的处理策略，从而对这一次的异常处置提供一定的参考。
我们可以整体来看一下整个异常处置平台在我们线上应用的真实效果。首先当异常发生时，运维人员会在钉钉上收到卡片的通知，根据告警等级的不同，卡片也会呈现出不同的颜色，直观看出异常的严重程度。如果异常没有被及时处置，它的影响面可能会不断扩大，它可能会从黄灯变成红灯，这个卡片的颜色也会随之动态变化。
另外当工单被运维人员接手进行处置时，我们可以在工单上实时看到它的处置进度，方便整个群里的人都了解整个异常的处置情况。
运维人员收到这个卡片后，他可以点击对应的链接跳转到异常工单的页面上，可以看到异常的现场，包括具体的曲线以及曲线到底是从哪个时刻开始有这个异常点。
然后在异常影响面的分析部分，我们可以看到这次的异常到底影响了哪些客户，我们会在这里列出具体的客户信息。同时我们也能看到这个客户这次受影响的实例在我们这次异常里的占比。在最下方，我们会呈现多 Agent 的根因定位结论。首先会得到明确的定界和定位结果，以及这个结果的核心依据。下面我们可以看到每个模块 Agent 的独立结果，点击详情就可以进一步看这个模块到底调用了哪些工具，以及这些指标日志的检测的情。实际上我们经常会出现多个模块 Agent 都觉得自己出问题了，都可能觉得自己是根因这样的情况，但我们最终的系统 Agent 还是会根据各个模块之间的潜在拓扑关系得到更加明确的结论，最终它给出的结论只会是最终根因的那个模块。
总结和展望
这次分享，我们首先从大数据运维的业务背景出发，来给大家介绍了我们在异常处置环节到底都面临着哪些挑战，包括我们怎样全面检测出这些异常，以及怎么面对告警风暴，真正剥离出其中关键的信息，帮助运维人员更好地分配注意力，以及最后我们在异常发生时怎么快速定位到问题的根因。
然后我们具体介绍了我们怎样利用 AI 技术来逐一攻破这些挑战，包括建设多种类型的异常检测算法，以及通过影响面的分析还有问题的定界来帮助我做更加精细化的告警分级。最后我们还引入了多 Agent 的根因定位框架，来模拟现实当中的故障处置小组实现根因模块的定位，并且给出它的推理依据，让我们的大模型推理不再是黑盒。前面提到这些算法技术都是通过 PAI-EAS 部署成在线服务的方式来供其他的系统和大模型应用层来进行进一步的调用。
而我们大模型服务层本身则是依靠百炼这个平台来进行构建和部署的，最终这些算法服务层和大模型服务层共同支撑了最上层的异常处置平台，真正把 AI 能力集成到平台和产品里，整合到运维人员日常的工作流里，发挥出真正的提效作用。
最后我们来对下一步的规划做展望。首先我们会进行异常处置能力整体的补全，会从现在事中的异常发现，一步向前延展，做风险预防。我们整体的思路是希望纳入更多海量数据来做故障的提前预警，这方面带来的技术挑战会更大，可能会涉及告警本身时空相关性的挖掘等技术。
在根因定位之后，我们还会打造真正的预案推荐，因为只有真正推荐出了可能的预案，才有可能走到最终的自愈环节，做到处置的自动化闭环。预案推荐在某种程度上也依赖根因定位的精细度。目前我们的根因定位也只能做到一级的模块，后面我们会进一步做到二级模块，来让整个根因定位更加明确具体，让它最终的关联动作可以更加明确。
除了异常处置能力的补全外，我们还会进行 Agent 的能力增强，包括自主编排、可靠性的提升，我们还有很多的策略需要尝试，来进一步保证它的结果是靠谱，并且性能是足够优的。还有工具能力的拓展，我们现在主要是把现有的运维平台上面的工具还有作业去兼容 MCP 这样的协议，使得 Agent 具备更强的系统兼容性。
最后是交互体验的优化以及人工反馈的增强。要让大模型能够得到令人满意的效果，人的实时反馈是非常重要的，包括现在很多像 Manus 这样的组件，都会在生成 plan 之后允许用户有机会做调整，这对最终结果的准确性非常关键。所以我们整体的交互模式的变化，以及后续怎样利用人工的反馈来持续优化后面的迭代，让大模型真正做到越用越聪明，是非常关键的问题。
整体来说，我觉得大模型技术和 AI 技术的发展可以用日新月异来形容，它也给我们智能运维领域带来了很多技术上面的突破，我也非常期待我们能够有更多的成果来做进一步的分享，感谢大家。
阿里云计算平台正急招智能运维算法专家，岗位链接，也可直接投递简历至：congrong.zyy@alibaba-inc.com，欢迎加入我们。
嘉宾介绍
张颖莹，阿里云算法专家，阿里云计算平台智能运维算法团队负责人，在智能运维领域深耕 8 年。用产品和服务支撑计算平台 MaxCompute、Flink、Dataworks、PAI 等多个大数据 &AI 产品的智能化运维。多项研究成果被 ICLR，KDD，VLDB, SIGMOD, ICDE，WWW, CIKM，ICASSP 等国际顶会接收，并带领团队获得了 ICASSP 国际智能运维算法大赛冠军。曾受邀在 QCon，ArchSummit，DataFunCon，FlinkForward 等大会发表演讲，同时参与了阿里巴巴开源大数据运维平台 SREWorks 开发和信通院《智能运维能力成熟度模型》行业标准编写。
活动推荐
2026，AI 正在以更工程化的方式深度融入软件生产，Agentic AI 的探索也将从局部试点迈向体系化工程建设！
QCon 北京 2026 已正式启动，本届大会以“Agentic AI 时代的软件工程重塑”为核心主线，推动技术探索从「AI For What」真正落地到可持续的「Value From AI」。从前沿技术雷达、架构设计与数据底座、效能与成本、产品与交互、可信落地、研发组织进化六大维度，系统性展开深度探索。QCon 北京 2026，邀你一起，站在拐点之上。
