一个软件的生命周期里，90% 以上的时间都处在运行状态。可当 AI 把 Coding 世界卷得人人提效两三倍的时候，Running 世界却进展缓慢。代码越写越快，早已不是问题；怎么让它跑得更稳，依然要靠大量人力去堆。
以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。
先从一个反差说起。这两年 AI Coding 的发展有目共睹。工具上，从最早的编译器插件，到 Cursor 这样的 AI IDE，再到 Claude Code 这样的 coding agent，现在已经走到多 Agent 并行协作、端到端交付的 agent system。范式上，从早期复制粘贴和代码补全，到一句话生成 demo 的 vibe coding，再到生产级的 spec coding。去年还在讲 harness engineering，今年就变成 loop engineering，马上又有人说 loop 已死，进入 graph engineering。连推特的大神 Karpathy 都说，很多知识还没来得及学就已经过时了。
玩笑归玩笑，这背后是一个很实际的结论：个人的编码效率已经快速提升，越来越不是整个软件研发过程的主要瓶颈。我们业内线下交流时，大家普遍觉得个人编码速率已经提升了大概 2 到 3 倍。但交付效率还涉及到大家公司的组织架构及研发流程等因素，暂且不展开。
但我想说的是另一面。一个软件整个生命周期里，90% 以上的时间都处在运行状态。代码越写越快已经越来越不是问题，怎么让它跑得更稳，依然要靠大量人力投入。为什么突然告警了？为什么发布会出问题？为什么重启只能短暂恢复？根因是什么？为什么换个环境就不一样？这些问题，AI 还远远没解决。
这里对比一下 Coding World 和 Running World。CodingWorld 的环境相对确定可控，写代码可以测试、可以稳定复现，难点主要在架构设计和代码实现。但 RunningWorld 不一样，它时刻面临各种不确定性：环境、基础设施、依赖项，随时随地可能发生的故障。哪边的光缆又被挖断了，哪个机房又着火了，这些都比写代码难预测得多。所以 Running 的场景更难被完全自动化，AI 在这方面的进展也明显偏慢。
那为什么传统的 SRE 很难做好这件事？相信大家都有这种感受。我们要对接越来越多的可观测平台，做很多自动化流程，编写很多处理工具，还有 SOP、runbook 等等。这些东西本来是想把人从重复劳动里解放出来，可实际做下来，做得越多，效果反倒收效甚微。为什么？因为真正的瓶颈点不在工具多少，而在人怎么去理解、人怎么做决策。工具可以把数据摆到你面前，但看懂数据、做出判断，还得靠人。所以传统 SRE 的困局，就是缺少真正具备泛化级别的智能。
不过现在条件开始具备了。因为前面提到的各种传统 SRE 的底座数据，都已经非常成熟了。叠加这几年 AI 的发展，我们看到各种前沿模型，不管国内国外的，都已经达到了生产级可用，越过了这条基线。再加上现在各种工具调用能力的积累，以及 Harness 工程的成熟落地，我们整个运行世界第一次变得可以理解、可以操作、可以验证。于是我们就可以开发出真正自动化、智能化的 SRE Agent。
我先给出 RunningWorld 治理架构的一个整体概览。
先看左边的数据层，主要分三个部分：infra、可观测、knowledge。中间是我们的认知层，是一个思考引擎，基于本体和语义层，构建出 RunningWorld 的全景图谱。下面是 Agent 的思考决策循环链路。右侧是基于 Agent 的能力构建出来的场景化能力，像架构可视化、根因分析、变更风控等等。底下又是一个基于评测的工程闭环。
这三类的分工很明确：infra 描述的是这个世界长什么样，也就是系统的静态结构；可观测描述的是世界正在发生什么，也就是系统当下的运行状态；knowledge 描述的是我们以前是怎么去解决这些问题的，也就是沉淀下来的经验。三者合在一起，才能拼出一个完整的运行世界。
先看 infra，这块的数据都是大家经常打交道的，计算、网络、存储、数据库、云资源等等。它们的特点是低频变更，彼此之间基本上都有关联关系。可观测大家也很熟，就是 OpenTelemetry 三件套 metric、log、trace，再加上一些变更事件和告警。这些数据的特点是高频变更，失效期很短，可能是秒级或者分钟级的更新。再看 knowledge，就是大家平时积累的各种经验文档、架构文档、历史故障、还有一些工单等等。这些数据的特点是相对非结构化，信息密度比较高。在没有 AI 之前，理解这些知识库都是靠人去做的，所以它的作用发挥相对比较弱。但有了 AI 的能力之后，它就有了一个指数级的增长。
但这三块数据本身，可能是一个一个的孤岛，是隔离的。那我们怎么通过一些规则机制，把这些数据建立起联系来，变成一条一条可解释的因果链，这是一个非常重要的问题。
这就到了我们的认知层，让 Agent 去建立对软件运行世界的理解。认知层的第一层是本体，也就是 ontology。简单介绍一下：本体其实就是前面提到的各种实体对象，以及它们的属性、相互之间的关系，还有它们运行的一些硬性规则及约束。第二层是语义层。语义层要做的，就是把这些实体对齐，进行关系抽取，把有歧义的部分消解掉。基于前面两层的基础，我们就可以构建出一个运行世界的全景图谱。这个图谱带有非常强的复杂图查询能力，以及基于这个图查询能力带来的逻辑推理能力。
我举一个例子，讲清楚构建图谱前后的差别。左边是四条分散的原始数据。第一条是 service A 的一条告警，说它 P99 延迟升高了，那这个 service A 到底是一个什么服务？它的 owner 是谁？不知道。第二条是一条日志，说连接某个 IP 的 43 端口有 timeout，这个 IP 又是做什么的？它的上下游关系是什么？不知道。第三条是一个网络策略的变更单，这个变更单它改变了什么？对上下游的影响是什么？也不知道。第四条是 CMDB 里的一条数据，描述 payment 这个支付服务，它跟前面的 service A 又有什么关系？同样不知道。
这四条数据单独看，都是一堆信息碎片。但在图谱里梳理呈现之后，效果就变得非常清晰了：这个 order service 是一个订单服务，它的别名就是 service A，owner 是张三，它有三个 pod，都在广州地域。它依赖了 payment 这个支付服务，并且近期做了一个网络变更，这个变更内容可以拿到，时序上是吻合的，变更的地域也都吻合。再叠加上历史上这类网络故障变更的处理经验，Agent 就可以推理出整个发生的因果链：广州地域的一个网络策略变更，导致了支付服务的访问出现问题，进一步又导致上面的订单服务，因为依赖支付服务，所以整体延时变得更高了。
建图只是一个开始，怎么保证它不腐烂、持续可用，才是关键。构建图谱的核心步骤主要有四步：第一是多元的数据采集，这块其实还跟大数据处理等技术相关，我们一般会做增量同步，全量兜底；第二是做实体归一，实体归一可能会遇到各种冲突等等问题，需要去介入解决；第三是构建属性和关系，我们要采用高可信源的数据；最后是做质量校验，以及图数据的分层存储。
构建出来之后，怎么保证它不腐烂呢？这里我列了六大问题，在实际经验当中，这些才是更加难以解决的。这些比较细节，我这里就不展开了，给大家大概展示一下可能会遇到的这些概念。
进入场景实践，图谱建出来之后，我们实际的应用是什么？首先是架构可视化，刚才前面蚂蚁的老师也讲到了，有些是基于代码把架构画出来。在架构可视化领域，有一个更有指导意义的模型叫 C4 模型。它是从上往下的，最上面是 context 层，一般我们叫系统层。拿电商网站举例，它就是用户系统、支付系统、物流系统等等这个级别的架构交互。第二层是 Container 层，是单个系统下面的一些微服务等等可部署单元的交互，比如订单服务、库存服务、数据库，都是可以部署的粒度。第三层是 Component 层，更细分到一个服务里面的一些逻辑模块，比如创建一个订单、做价格计算、做库存校验等等这个层级。最底层是 code 层，这个大家很熟，就是类、实例、函数等等这些层面。
基于这个模型的指导，我们把前面说的全景图谱构建出来之后，底下其实是一张非常大的底图。这张图里，把所有不同层次的实例全部关联起来，它们的上下游关系、调用、规则等等，都在这张底图里。Agent 就可以基于这张大的底图，随时根据用户的需求，去绘制出右边的分级架构图，有系统级的、服务级的，还有代码级的。
所以这里有个关键的认识：这个图谱其实不是给人看的，它是给 Agent 看的。Agent 经过图谱画出来的，才是给人看的。
这是我们腾讯云 CloudQ 基于刚才的理念做出来的架构可视化效果。最左边是一些经典的 3D 架构图，这种图的特点就是很「好看」，大家一般用在公司大屏，或者给领导汇报。第二个比较实用，一般在排障过程中用，你通过对话可以实时圈定一些范围，画出基于 Mermaid 图的一些呈现。第三个就是刚才讲到的，从系统层下钻到应用层、再下钻到代码层的分层下钻效果。
再讲第二个实践案例，就是我们 CloudQ 基于全景图谱的影响面分析，左右两边对比的是 Agent 接入图谱前后的效果。
接入图谱之前，比如我们想让它分析一下，CLB 如果挂掉之后会有哪些影响。Agent 可能能拿到 CLB 本身的监控、配置等等数据，它也可能基于时间去拿一些对应的告警数据。但它这些始终都是一些相关性上的猜测。大家都知道，模型可能一本正经胡说八道，输出一些看起来挺有道理、其实经不起推敲的结论。
但有了全景图谱之后，我们的 Agent 收到这个问题，就可以基于图谱节点层次的各种下钻关系，拿到各种一跳、两跳的上下游数据，包括告警、变更等等。所有这些都是基于因果链、有因果关系的数据，而不是简单的相关性。并且图谱查询大家熟悉都知道，做这种多跳关联的查询，比关系型数据库效率会高非常多。所以这里展示的是，有了图谱画出因果关系之后，影响面分析的效果会好很多，而且它是非常可信的。
这是我们做 Harness 的一个概览图。最上层是入口层，这里我们首先支持各种 IM 工具的接入，比如主流的企微、飞书、钉钉等等，也支持网页对话框的输入。整个 Agent 又可以作为一个 skill，让最近很火的 Workbuddy 或者 OpenClaw 这类智能体来调用，也就是说它本身又可以被嵌入到别的系统里。
左边是我们内置的一些专业能力，各种工具集，还有各种场景化的子 Agent，比如巡检的、护航的、演练的等等，是一种多 Agent 的架构。还有各种知识库，是一些内部梳理出来的专家经验。当然这些也支持用户自定义上传，上传他自己觉得很好用的 skill、MCP、知识库等等。中间就是我们整个 SuperAgent 的编排中枢，这里主要去做 Agent 都比较通用的理解、规划、执行、上下文、安全控制等等。
再往下，有一个多云适配层。相信大家公司里一般也不会只用一个云，都是多云的架构。那这里就不只支持腾讯云，也支持像 AWS 、阿里云、华为云等国内外主流的云厂商。最下面就是模型服务、数据分析、沙箱以及 Agent 运行依赖的一些外部服务。
再讲一下 Agent 运行当中三条非常重要的机制。
第一条是编排边界。Agent 或者说大模型，非常容易被 prompt 绕过。所以我们很多执行边界上的问题，要在模型的范围之外，最好基于规则去实现。我们的图引擎，就把 ReAct 的机制限制在了固定的几个节点当中，其他都是不允许它去发挥的。
第二条是记忆机制。历史对话的摘要、工具返回的大量结果的压缩、近期轮次的保鲜等等。这些经过上半年 OpenClaw 小龙虾的爆火之后，现在业界都有很多非常成熟的方案。
第三条是环境与沙箱的治理。沙箱的使用方式一般有两种。一种是你把整个 Agent 跑在沙箱里面；第二种是你把沙箱只是当作一个工具去调用，把一些特殊的执行环节放到沙箱里。云端 Agent 一般基于第二种，就是把用户上传的、可能会存在风险的 skill，它的执行放到沙箱里去做，只给它注入一些特定需要的环境变量，还有它的一些脚本环境等等。最重要的一点，就是要跟内网去做隔离。执行完之后，要把整个沙箱销毁。
评测也是非常重要的一环。我们做的评测机制，是实时加离线相结合的方式。对于实时评测，用户的各种问答，经过信息脱敏之后，就进入多模型的评审器，对结果和轨迹去做交叉的、基于五个维度的评分。这里就会发现，有的是结果不符合预期，有的是运行轨迹、调用工具等不符合预期，有些甚至是无响应，直接跑崩了。还有一些比较隐晦的，我们还得去分析用户的下一条对话记录。它可能是一句骂人的话，属于差评类的 badcase。基于实时评测发现的这些 case，又要沉淀到我们的一些离线回归的评测集当中，这个评测集本身也包含各种主要功能路径上的 case。
离线回归是早八晚八一天跑两次，并且如果相关的 Agent 有变更发布，也会触发流水线跑一次。如果说有一些 case 没过，那我们就要阻塞这个发布过程，人为地去介入优化。所以其实这个实时加离线的这套评测机制，做得越自动化，大家就越能感受到，它其实就是一个自进化的雏形。我们先通过评测发现问题，再去做分析优化，然后再验证它的优化效果，最后变成一个新的能力的沉淀。现在业界大部分的 skill 的自进化，也大体都是这个思路。
定时任务这个场景也很有趣，如果早期我们去实现一个定时任务，最简单的方式，就是把它当作一个普通的任务，每次定时调起，就把用户的问题从头到尾执行一遍。但是这会引入三个问题。第一，无差别的推理，成本很高。现在如果用的是稍微好一点的模型，DeepSeek、Kimi 这些都涨价了，那可能跑一遍就要十几块钱或者几十块钱。第二，效率低。你每次都得靠模型重新理解规划，来回地调用，可能单次模型的一来一回就要十几秒，那整个任务可能就要几分钟、几十分钟。第三，确定性的问题。因为模型每次都是基于概率的发挥，它并不一定每次都能跑成功。
我们去分析了一些任务。这里有一个典型的例子：用户说，每天帮我去清理一些没有用的日志。这个场景在传统年代，有经验的同学一下就知道，我应该写一个脚本，到服务器的日志目录里面去找，因为一般日志都是按时间或者按大小做切割的，一下就可以把它清理掉。但如果是一些新手，纯粹把这个需求发给模型，模型就要重新去理解，每次都要先说去找哪些目录，目录找到了，再去找哪些日志等等。这个完全可以脚本化，不用每次都靠模型的能力去实现。
第二个场景也很典型：帮我做一下容量分析，或者大家很感兴趣的，上午股票大盘的分析。这种任务的特点就是分两个阶段，第一阶段是拉各种数据，把它拉回来，再由模型去做总结。这种类型的任务就可以把前半部分脚本化，后半部分交给模型执行。
所以我们就把定时任务这个场景，升级成了一个执行计划引擎。它会去识别这个任务，适合把哪些环节做脚本化，哪些去做模型的泛化能力总结。如果执行失败了，就把失败的这个步骤交给模型；如果整个任务都失败了，就把它当作一个普通的任务，让模型整体去重试一遍，这是一个双重兜底机制，用户是完全无感知的。这样就解决了前面提到的成本高、耗时久、不确定性的问题。
先整体看一下 SRE Agent 场景化闭环的概览。治理问题我们总结一下，其实就是三大类：系统现在怎么样？异常为什么会发生？下一步应该怎么做？SRE Agent 的各种原子化能力，包括目标理解、关系探索、取证推理、策略生成等等。基于这些原子能力的组合拼装，我们就可以做很多场景化的治理，包括前面已经提到的架构可视化、根因分析、变更风控、FinOps 等等。
先看根因分析这个例子，我们从一条告警下钻到一行代码，又从 Running World 回到了 Coding World。首先是工程师收到了一个帖子服务不可用的告警，Agent 去理解整条告警的语义，确定它不是单节点就能分析出来的，需要做一次架构级的诊断。所以第一步，就是绘制出整个链路上相关的、从前到后的调用链路，就呈现在左边，比较简单，从入口到一个后台，再到一个数据库。
第二步，它先去分析告警的这台 CVM 服务器，内存比较高。但内存高一般都不会是根因，都是一些表象。所以 Agent 就根据调用链路，先去查这台 CVM 的上游，看接入流量有没有突发变高，因为这样也会导致它崩掉。查出来之后发现，上游的流量是正常的，所以它就继续往下找原因。它找到了服务的日志，在日志里面发现了大量 MySQL 连接过多的报错。连接过多，一般就是一些代码实现层面的问题了，所以它就继续往下探索。发现确实有一些堆栈报错，是有一行代码没有做释放，导致了连接池的泄漏。整个根因就串起来了，就是一个代码实现上的问题，最终导致了告警的产生。
它也会给出处理建议。首先是做临时恢复，应该先把服务拉起来，所以建议工程师先把这些无用的连接清理掉，加大一下最大连接数的配置。并且给出长期修复方案，代码应该怎么修。
第二个场景是变更风控，做开发运维的肯定少不了这个场景。我们一般基于事前、事中、事后三个步骤。事前，基于刚才已有的图谱数据，根据变更的节点，算出它一跳、两跳的整个业务影响链路。事中，Agent 自动拉取一些历史上它觉得比较重要的指标，建立一个基线，通过定时任务等方法，实时把这些监控数据拉回来跟基线对比。一旦发现异常情况，并且跟变更相关，就要阻断变更过程，让人为介入。事后，比如变更失败了，要有回滚预案等等机制去执行，最后输出一个变更的总结报告。
接下来是智能巡检。巡检的目的，主要是为了让一些还比较轻微的风险，在变成大故障之前能被发现和治理。有了 SRE Agent 之后，我们可以通过对话的方式，让它自己去确定风险诊断的范围。以前发现风险之后，可能是一些提前写好的处理建议；有了 Agent 能力之后，就可以针对性地告诉每一个客户，他的风险项应该怎么个性化处理，最后沉淀成经验。原来我们可能只能基于单点，说某台服务器或者单个数据库是不是存在风险；有了全景架构图之后，就可以判断出 AZ 级别的风险，这在应对大规模故障，比如机房断电这种规模级别的故障时非常有用，是一种架构级的治理。
容量和 FinOps，这两个场景非常相似。容量管的是够不够，成本视角管的是到底贵不贵。这两个场景我们都分三步走：首先是「看见」，要有一个全局概念，知道现在哪些地方是高负载、哪些地方是低负载；第二步是「看懂」，也就是去动它，比如某个地方堆了 100 台服务器，是不是太贵了，能不能缩容 50 台，就要有 Agent 来帮你做一个详细的评估；最后是做行动，行动完之后帮你总结，这次缩容到底节省了多少成本，或者这次针对未来的一个大促，我们把容量扩到了什么样的水位。
混沌工程这一块大家应该也都挺熟悉。由 Agent 赋能之后，首先做拓扑发现，再建立一些稳态基线，再通过对话式的方式生成整个演练方案，原来手写一个还是挺累的。最后输出一个演练复盘报告。
最后一个问题是，到底敢不敢让 Agent 自己去动手？我们的经验是把它分为三个不同的阶段。
第一，对于只读类的场景，刚才说的做根因分析什么的，就大胆让 Agent 自己去做、去探索，我们只要做好审计留痕就好了。第二，建议类的场景。Agent 发现问题之后，有时会说，我可以帮你直接解决，只要你点一下授权动作就好了。这类就是要由 Agent 给出建议，人去做授权。第三类，是真正的自动化执行。就是把一些提前知道的低风险写操作，比如缩容、扩容这种操作，如果评估它是没有风险的，可以预授权给 Agent，它在遇到这些问题的时候就可以自动执行。
我们现在是三个阶段并存的状态。像 L3 这个级别，也是今年 Agent 或者说模型能力进一步提升之后，我们才开始逐步去尝试的。
最后总结一下，今天这个分享，就是一条可参照的 SRE Agent 建设路径。大家可以跟我们一样，先梳理好数据，建立起图谱，并做好更新维护。然后是 Harness 和 评测，驾驭好 Agent。最后是从只读开始，逐步去做有限的执行。
会议推荐
