这两个月开运维的会，绕不开一个问题：故障定位和故障排除这件事，能不能交给 AI 运维 Agent 自己做完。
答案已经有了，只是分成两半。Gartner 在 2025 年 12 月发布过一份预测。到 2029 年，70% 的企业会用 AI Agent 运营自己的 IT 基础设施。而 2025 年这个比例还不到 5%。
Forrester 2026 年的评估报告更直接：约 79% 的企业已经在试，真正跑进生产环境的只有 11%。
另一半是冷水。Gartner 还预测，到 2028 年，规模化用 Agent 做运维的企业里，40% 会遇到业务关键的服务中断。同一批研究里，超过 40% 的 Agent 项目预计在 2027 年底之前被取消。PagerDuty 调研过的企业里，76% 认为 AI 带来的复杂度会很快超过人手能管住的范围。
差距就落在一个很具体的地方：会报警的 Agent 已经很多，能自动定位到根因的还很少，敢让它自己动手排除的更少。所以现在真正要回答的，不是接不接，而是接进去之后，从自动定位走到自动排除这条路怎么打通。
智能排查：会报警的 Agent 已经很多，敢自己动手排除的还很少
凌晨两点，告警群里跳出一条消息：订单接口的错误率从 0.3% 涨到 17%。值班的同学能看到日志，能连上数据库，也能翻出配置文件，唯独看不到代码。那套服务是半年前别人交接的，服务器上只留着编译后的产物。
这个场景正在被反复复现。有团队总结过，为什么自动化排障大多只能止血。自动重启一个 Pod，看着是恢复了，几分钟后内存再次打满，因为没人能顺着代码把根因找出来。
也有调研把事故拆开归因过。企业 AI Agent 的事故里，模型本身的问题只占 35%，剩下 65% 出在工程可观测性缺失。
两件事指向同一个地方：卡住自动定位的，通常不是模型不够聪明，而是它手里没有足够的材料，也不清楚该去哪些机器上找。
把这两步拆开看会更清楚。自动定位要的是看得见：它能读到现象，也能顺着现象找到原因，这一步不改动任何东西。自动排除要的是敢动手：重启、改配置、回滚、删数据，每一步都落在生产上。前一步做错，最多是判断错；后一步做错，就是事故。多数方案卡在第二步，不是因为模型不会敲命令，而是因为没人愿意给它这个权限。
生产排障要四样东西，漏掉的常是第四样
先给结论。一次生产故障从发生到查清，需要的材料大体是四样：日志、配置、数据，还有代码。前三样大家都不陌生，第四样经常在方案里被跳过。
这四样回答的是四个不同的问题。日志回答「什么时候开始不对」。配置回答「本该是什么样」。数据回答「实际坏到了什么程度」。代码回答「为什么会这样」。前三样能把现象描述得很清楚，只有代码能把原因指出来。
顺序也差不多是这个顺序。说白了就是：先看日志知道出事了，再看配置知道哪里被动过，再查数据知道影响面有多大，回头再翻代码，知道是哪一行写错了。
那么问题来了：这四样材料，你手上现在能拿到几样？
| 要素 | 回答的问题 | 典型载体 | 缺了会怎样 |
| 日志 | 什么时候开始不对 | 应用日志、系统日志、访问日志 | 只知道「出事了」，定不出时间线 |
| 配置 | 本该是什么样 | 配置文件、环境变量、发布参数 | 分不清是代码问题还是配置问题 |
| 数据 | 实际坏到什么程度 | 业务表、缓存、消息队列 | 判断不了影响面，容易误判严重程度 |
| 代码 | 为什么会这样 | 可读源码（不是编译产物） | 能描述现象，给不出根因 |
为什么要强调配置这一环？Uptime Institute 在《年度停机分析》里给过一个数字。网络与连接类故障中，配置和变更管理的失败占到 45%。它 2025 年的报告又提到，近三年遭遇过人为错误导致的重大停机的组织接近 40%。这些停机里，85% 是因为没有按既定流程操作，或者流程本身有缺陷。
ITIC 2025 年的《停机成本调查》给的数字更直接。软件与配置错误占故障根因的 31%，是占比比较高的一类。同一份调查里，停机损失的中位数是每分钟 9000 美元，折下来一小时大约 54 万美元。这个数字从 2019 年的 5600 美元、2023 年的 7900 美元一路抬上来。New Relic 2026 年 9 月发布的《可观测性预测》报告把均值算得更高，高影响停机每小时约 185 万美元。两家的数字差得不小，读的时候得留个心眼。
这些数字怎么读，需要说明一句。ITIC 给的是中位数，样本来自受访企业的自报估算。New Relic 给的是均值，样本和统计范围是另一套。两家的口径不一致，中位数和均值不能直接相减或者相比。能用的信息是量级：一次高影响停机，对多数企业来说都在每小时百万美元这个量级上。至于具体是 54 万还是 185 万，取决于行业、规模和业务形态，别直接往自己头上套。
四样里，代码这一样有个特殊之处：它必须是能读的源码，不能是编译产物。解释型语言的部署还好办。Python、PHP、Node 这类项目，服务器上或者镜像里通常留着源文件，Agent 能直接读。麻烦的是编译型语言，Go、Java、Rust、C++ 编译之后只剩二进制。符号被剥掉以后再想还原业务逻辑，成本高到不值得。所以「Agent 能不能看生产」这件事，有时候在项目选型那一刻就定了一半。
方法一：开发环境直连生产，上手快但更考验自律
部署结构简单的中小团队，有一条更省事的路：不往生产里装任何东西，直接让开发环境里的 Agent 去看生产。
这条路能成立，是因为开发侧的 Agent 本来就握着代码上下文。VS Code 里的编码助手、Claude Code 这类工具，在本地仓库里能读代码、能跳转定义。再给它一条到生产服务器的 SSH 通道，四样材料就凑齐了。代码在本地，日志和配置在服务器上，数据用只读账号连数据库。
具体动作大致是这么几步，前面几步全是只读的，真正涉及写操作的只有后面两步。这个安排本身就是一种安全设计。
- 在本地仓库里打开 Agent，让它先通读相关模块，建立「这段逻辑本该是什么样」的基线。
- 用 SSH 连上生产服务器，把故障时间窗内的日志拉下来，先把时间线排出来。
- 把服务器上的配置文件、环境变量与本地仓库里的版本逐条核对，找出被动过的项。
- 用只读账号连生产数据库，把关键表的实际数据取出来，确认影响范围。
- 回到代码，把异常栈、配置差异、数据异常三样对齐，落到具体的函数或者分支上。
- 需要改文件或者改数据时，先让 Agent 给出改动方案和回滚方案，再由人确认执行。
这条路的优点很实在：不用改生产架构，不用额外部署，Agent 的能力直接叠在现成的开发工具上。它靠的是一个前提，人本来就能连生产。
前提的另一面就是限制。一方面是部署结构：只有单机、少量服务、没有严格网络分区的场景，才可能让开发机直达生产。另一方面，也是更容易被忽略的一点，直连不等于可以随便连。开发机一旦能碰到生产，Agent 每一次读和写都发生在生产上。它出错的位置也在生产上。
所以真要走这条路，有几件事得先做。数据库那边单独开只读子账号，只授必要的表，不要图省事直接给主账号。确实需要放开写权限时，写操作逐次确认，每一次都留记录。开发机到生产之间走公网还是走专线，直接决定这条路在安全评审里能不能过。中间隔着网络分区的话，这条路根本不成立。
方法二：Agent 进驻生产，日志好拿，代码要单独补
部署复杂、要求生产隔离的中大型团队，走的是另一条路：把运维 Agent 部署到生产环境内部。
这么做的好处是材料获取变简单了。日志本来就在这台机器上，配置也在，数据源也在同一个网络里，Agent 不需要跨过任何边界就能拿到。而且不用把生产的数据或者凭据往开发环境搬，这一点在合规评审里通常是个加分项。
短板也很明确：代码通常不在。生产的服务器或者容器里装的往往是构建产物，源码不会跟着上线。缺了这一样，Agent 能做现象级的判断，做不了根因级的判断。它能告诉你哪个接口在报错，不容易告诉你为什么会报错。
补代码有两个方案，选哪个取决于项目用什么语言写，也取决于集群的隔离要求有多硬。
| 维度 | 方案一：从运行环境读源码 | 方案二：单设运维 Agent 主机 |
| 适用语言 | 解释型（Python、PHP、Node） | 不限，编译型也能用 |
| 取码方式 | 服务器或镜像里的源文件直接读 | git 等方式拉取与线上版本对应的源码 |
| 连通性要求 | 只需本机权限 | 需能连到各业务节点 |
| 优点 | 零额外部署，看到的就是线上运行版本 | 不受语言限制，代码与节点分离 |
| 限制 | 编译型语言不适用 | 源码版本必须与线上对齐，凭据要单独设计 |
方案一，直接从运行环境里读源码，只适用于解释型语言的部署。这条路省事，看到的也确实是线上正在跑的那份代码，缺点是编译型语言用不了。
方案二，在生产集群里单独准备一台运维 Agent 主机，适用范围更广。这台主机通过 git 等方式拿到与线上版本对应的源码，再通过 SSH 连到各台业务服务器上取日志和配置。它相当于在集群内部设了一个带着代码的观察位，既不出生产网络，又能同时看到代码和运行状态。
方案二有两个前提要先说清。一是源码版本必须和线上运行版本对齐，靠分支名和提交号锁死，不能只拉主干就完事，否则你查的是另一份代码。二是它对集群连通性要求更高，需要能到各个节点。所以访问路径和凭据管理要单独设计，不能沿用通用的运维账号。
节点一多，Agent 自己怎么摆就成了下一个问题。这块放在下一节单独说。
| 维度 | 方法一：开发环境直连生产 | 方法二：生产内部署 Agent |
| 适用规模 | 中小团队，部署简单 | 中大型团队，部署复杂 |
| 生产隔离要求 | 低，允许开发机直达 | 高，数据不出生产网络 |
| 代码获取 | 天然具备，在本地仓库 | 需单独补，见上面两个方案 |
| 网络要求 | 开发机到生产可达 | Agent 主机到各节点可达 |
| 权限收敛难度 | 较高，入口在生产之外 | 较低，可在生产内收敛 |
| 典型风险 | 权限过宽，误操作直接落在生产 | 源码版本错位，跨节点凭据扩散 |
集群不止一台机器，Agent 怎么摆
方法二里那台运维 Agent 主机，如果只连一台业务机，算不上集群运维。真实场景里业务节点可能有几十台，外面还套着容器或者 Kubernetes。这时候 Agent 侧的形态有两种常见选择，也可以一起用。
一种是用天生支持主从结构的运维 Agent。主节点负责会话、编排和审计，子节点常驻在各台业务服务器上，负责本地采集和执行。主节点下发任务，子节点就近取日志、跑巡检、回传结果。这样做的好处是每台业务机上只需要一个轻量的执行体，不必把全部凭据集中在主节点，网络上只要子节点能连回主节点。代价是节点的心跳、版本和失联处理都要自己维护，主节点本身也要考虑高可用。
另一种更省事：不引入主从框架，把连接方式写成 skill，落在运维主服务器上。运维里反复用到的其实就那几样：每台服务器怎么连（主机、端口、账号、要不要跳板机）、服务部署在哪、日志目录是什么结构。还有哪个服务对应哪个进程名，配置放在哪几个路径。把这些整理成一份 skill 文件，放在主服务器的 Agent 里。每次排查就从这份文件里取连接方式和路径，再通过 SSH 去各节点取日志、读配置。
| 维度 | 主从结构 | 把连接方式写成 skill |
| 解决什么 | 进程与连接怎么组织 | 运维知识怎么固化 |
| 主节点干什么 | 会话、编排、审计、汇总 | 不涉及 |
| 子节点干什么 | 常驻各业务机，本地采集与执行 | 仍按需 SSH 连过去 |
| 加一台新机器 | 装执行体、接入心跳 | 在 skill 里补一行连接与路径 |
| 主要成本 | 心跳、版本、失联处理、主节点高可用 | 凭据要单独加密和控权 |
这两条路可以叠在一起：主从结构负责跑得动，skill 负责知道往哪跑。前者的骨架是进程和连接，后者是运维知识本身。skill 这一层的收益在排查结束之后才显出来。新人接手时不用再挨个问「日志在哪」，Agent 接手时也不用重新摸索路径，一次排查的路子下次还能照着走一遍。
有一个前提要提前说清：skill 里记的连接信息属于凭据，要单独做权限控制和加密，不能写进会被提交的文件。日志目录结构这类信息不敏感，可以放得宽一些。这个区分到下一节讲安全时还会再出现。
集群访问和安全，这两关谁都绕不开
选哪条路是策略问题，能不能落地是能力问题。真正让方案卡住的通常是两件事：集群怎么访问，安全怎么保证。
先说集群访问。生产的形态不一样，访问方式就不一样。物理机和虚拟机上通常是 SSH，容器环境里是 exec 和镜像层。Kubernetes 集群里则是 kubectl、RBAC 和各种临时凭证。麻烦的地方在于，这些访问平面各自有一套权限体系。Agent 要跨过去，就得有能跨过去的凭据，而凭据一旦给宽，前面所有的安全设计都会被绕过。
Kubernetes 官方博客在 2026 年 3 月有一篇文章，专门讲生产环境调试的安全做法。它建议把日常入口从裸 SSH 换成带权限收敛的通道。用 RBAC 控到最小权限，凭证绑定短期身份，调试会话走即时的授权网关。SSH 不是不能用，而是应该当应急通道用，并且用强制命令和白名单框住。这个思路对搭 Agent 一样成立。Agent 的默认入口应该是只读的观测通道，不是一台能随便敲命令的服务器。
再说安全。这里最好把它拆成两个问题，混在一起谈就会变成「要么全放，要么全不放」。
一个是数据安全，也就是它能读到什么。收敛的做法是：单独的只读子账号、只授必要的库表、敏感字段在查询层做脱敏、访问记录单独留存。另一个是操作安全，也就是它能改什么。思路是让破坏性动作默认关闭，让写操作逐次确认，让不可逆动作只出建议不自动执行。生成出来的脚本要在沙箱里跑，而不是直接落在生产上。仙踪问道在做 op-agent 时，把这几条设成了默认行为。
| 风险点 | 失控后的后果 | 该怎么设 |
| 读权限给整库 | 数据越权读取、泄露 | 只读子账号，只授必要的表 |
| 写权限常开 | 生产数据被误改、误删 | 默认关闭，写操作逐次确认 |
| 不可逆动作自动执行 | 删库删表无法回滚 | 只出建议，不自动执行 |
| 脚本在生产裸跑 | 越界写文件、改系统状态 | 沙箱内执行，写权限限到临时目录 |
| 操作记录可被修改 | 出事后无法追责 | 追加式记录加防篡改校验 |
| 凭据长期有效 | 泄露后长期被利用 | 临时凭证，用完即收回 |
这几个开关，你打算给 Agent 开到哪一档？
国外有团队算过一笔账。运维排障 Agent 因为要调生产接口，权限这一关常被安全团队按住。六个项目里有五个止步在试点阶段。卡住的原因不是模型不行，而是现有架构里没有给 Agent 留出一个运行位：最小权限、操作审计、沙箱执行，三样得同时到位。
国内还有一条合规线要过。《网络安全法》要求网络日志留存不少于六个月。等级保护 2.0 对安全审计的要求更细，审计记录要能还原主体、客体和操作类型。这两条对运维 Agent 的含义很具体：它做的事必须能查到、能还原、能追责。如果 Agent 的操作记录本身可以被它自己改掉，那这套审计就等于没做。把审计做成一条前后咬合的哈希链，而不是一张谁都能改的普通表，考虑的就是这一点。
反面的教训也不少。安全厂商 HiddenLayer 在 2025 年的统计里说，94.4% 的 Agent 对提示注入是脆弱的。Anthropic 2026 年 2 月的内部红队测试给得更细。纯代码任务几乎打不动。但一旦进入多步工具调用，无防护时攻击成功率 94.4%，加了防护也还有 76.2%。Elastic Security Labs 测过的 MCP 服务器实现里，43% 存在命令注入。国家互联网应急中心的实网众测，在国内 10 家厂商的 15 款产品里检出 281 个漏洞。其中六成以上是传统安全体系覆盖不到的新风险。
这些数字指向同一件事：Agent 接到手里的每一个工具，都是一个新的攻击面。给它的工具越多、权限越宽，这个面就越大。这也是仙踪问道在开源 op-agent 时优先处理的问题。
点睛：把安全当主业的那类 Agent
上面那张清单，其实就是选型时的检查表。仙踪问道开源的 op-agent 基本是照着这张表做的。它的重点不在替你干多少活，而在敢让你放手到什么程度。
它的安全设计分了四层。模式层做快速规则拦截。像 rm -rf、mkfs、find -delete 这类破坏性命令，会被这层直接拦下。不带条件的 DELETE、DROP 这类危险 SQL，同样过不去。语义层用模型再审一遍写操作和脚本，专门抓变量间接、混淆、外泄和提权这些规则不好表达的动作。两层结论取严合并，模型只能把风险往上抬，不能往下压。第三层是确认门加审计。写操作和破坏性操作要人按确认，每一条决策和执行结果都写进一条哈希链。链上任何一处被改动，都会暴露出来。第四层是操作系统沙箱，生成的脚本在沙箱里跑，写权限在进程级别被限制在临时目录和丢弃设备上。
日常用起来，它把权限分成三档。readonly 是默认档，只能写临时目录，其他一律挡住。write 档放开白名单和系统写，每次写都要确认。destructive 档才允许删除类操作，要求双重确认加上填写理由。提权必须由人点确认，降级则是即时的，不需要确认。每次等级变化都会带着批准人和理由进审计链，而硬保护路径在任何等级下都保持封锁。
它还做了一些成本上的取舍。只读巡检不进模型审计，日常监控的守护进程跑起来不花推理费用。整个程序是一个 Bun 进程加内嵌 SQLite，一台 1 核 1G 的服务器就能跑。安装是一行命令：npm install -g @xianzongwendao/op-agent。可执行文件名是 opagent，比包名短一截，别照着包名敲。
需要说明它不解决什么。它面向的是 Linux 运维场景，重点是把「能查」和「敢写」之间的边界做清楚。如果你的团队只有一两台服务器、故障频率很低，手工排查加上堡垒机可能就够了，不必为此多引入一个组件。它也不能替代人做决定，删不删数据、回不回滚，终究还是人拍板。
补一句：别把 Agent 的可靠性想得太美
材料齐了，还有一个变量不能忽略：Agent 自己靠不靠得住。这一块的正反面数据都不少。
正面看，Forrester 受 PagerDuty 委托做过一份研究。它的口径是告警噪音降低多达 91%、停机时间减少 59%。Splunk 公开的经验值，是把每天五千多条原始告警压缩到约一百条可处置事项。厂商材料里的降噪口径大多落在 70% 到 90% 之间，这部分比较一致。
反面看，情况没这么乐观。Microsoft Research 在 2026 年分析过 11771 个开源代码变更。Agent 贡献了其中 79.15% 的持续集成失败，却只修复了 60.63%。Amazon 的一位 AGI 负责人在 2026 年的技术大会上讲到，单个 Agent 的演示通过率有 88%。但三个 Agent 串起来跑，整体成功率只剩 34%。Kore.ai 调研过的四百多位 IT 负责人里，82% 说自己的 Agent 在没有监管的情况下执行关键操作。其中 79% 出现过需要人工回滚，42% 造成了可以衡量的收入损失。
这两组数据放在一起，结论其实不冲突。降噪是真的有效，这一点各家口径接近。但让 Agent 自己把故障修好这件事，可靠性还远不够，而且厂商给的停机时间改善幅度基本没有独立第三方验证过。
现在的合理姿势是「Agent 调查加人审批」。重启、扩容、回滚这类低风险动作可以放开自动化，高风险动作保留人工确认。这也正好解释了，为什么日志、配置、数据、代码这四样材料之外，还得再加上一条审计记录。它既是合规要求，也是你自己的回滚依据。
关注这个号，后续会继续写运维 Agent 的实操和踩坑记录。如果你也在搭这套东西，欢迎在评论区说说：你现在卡在哪一步？是自动定位还找不到根因，还是不敢让它自己动手排除？
