凌晨2点47分我盯着屏幕上一条告警K8s集群某个节点 NotReady。放在以前我的肌肉记忆是打开监控、翻日志、 ssh 上去手动排障运气好半小时恢复运气不好吵醒整个值班群。但这次我什么都没做——我把这个故障交给了基于 GLM 搭出来的 Infra Agent。它自己执行、自己验证、自己收敛最后还在工单里留了一份变更摘要。做完这轮 RSI 探索之后我在团队群里说了那句话Infra 被替代也不远了。这里说的 RSI 不是股票里的相对强弱指标是我拿来评估 Infrastructure Agent 能不能真正干活的三个维度Reliability可靠性、Scalability扩展性、Intelligence智能性。这篇就把我这几周的实验过程、实测数据、接入方式、以及我为什么开始认真看待Infra 被替代这件事完整写出来。适合正在拿 AI 辅助运维、或者犹豫到底能不能让 Agent 碰生产环境的工程师。1. 一次故障演练让我开始认真评估 Agent 的基础设施能力先说背景。我搭了一套模拟生产环境三台 ECS 组成的 K8s 集群上面跑着 Prometheus Grafana、一套 MySQL 主从、一个 Nginx 入口。我对这套环境做了两件事把告警 webhook 接到 Agent 上然后给它一批工具权限——查看节点状态、读日志、执行 kubectl 相关命令。然后我做了一个之前一直不敢做的实验人为注入故障。我在一台节点上用 dd 塞满了磁盘直接把节点压到 NotReadyPod 被驱逐业务接口开始报错。整个流程走下来Agent 的行为路径让我挺意外收到告警后它先调用了节点列表工具确认是哪台节点 NotReady。查看磁盘使用率发现 / 分区 99%。顺着进程和日志定位到罪魁祸首——一个不断增长的日志文件。执行清理动作只删了旧日志没有碰任何业务数据。等待 Pod 重新调度确认恢复后在工单里写了变更摘要。全程我没有做任何干预。最让我在意的不是它能把命令跑对而是它的决策方式它不是一次性生成一串命令然后执行而是先建立假设用命令验证假设再根据验证结果决定下一步。比如它查完磁盘后并没有立刻删日志而是先看是哪个进程在写日志、日志文件是否还被占用确认清理不会影响正在运行的容器才动手。这个过程让我意识到评估一个 Infra Agent 能不能用标准早就不是它会不会聊天而是它能不能在一个闭环里完成感知 → 假设 → 验证 → 操作 → 复核。这也是 RSI 这个框架的起点如果只有命令执行能力那是脚本如果只有对话能力那是聊天机器人。真正值得评估的是这三件事——可靠不可靠、扛不扛得住规模、是不是真的理解故障因果。2. 拆解 GLM 的 Infra Agent它到底在什么层面干活很多朋友看到AI 运维第一反应是这不就是我让 ChatGPT 帮我写个 kubectl 命令吗其实差得很远。我搭的这个 Agent架构上分成四层工具层kubectl、docker、systemctl、jq、curl以及一个受控的 shell 执行器。感知层接 Prometheus 告警 webhook、Grafana 通知、消息队列里的事件流。决策层GLM 模型。system prompt 里注入环境约束、操作边界、目标描述。执行层走 function calling模型输出结构化的工具调用意图本地执行后把结果回传给模型。2.1 和普通 ChatBot 的本质区别闭环普通 ChatBot 的工作方式是你告诉它需求它给你一段命令你复制到终端自己跑跑完再把报错粘回去。这个过程中执行和决策是断开的人永远是最后一环。Infra Agent 不一样。它拿到工具结果之后会自己消化、自己判断下一步。这个闭环是替代的起点。打个比方普通 ChatBot 像驾校教练坐在副驾上告诉你打方向盘、踩刹车Infra Agent 是坐在驾驶位上的司机你在旁边监督它自己完成从看到红灯到停车的一系列动作。这个闭环带来的直接变化是——人的角色从操作者变成了定义目标和边界的人。我不再需要告诉它执行 kubectl get nodes 然后把输出发给我而是告诉它集群有一个节点异常请定位问题并在不影响业务的前提下恢复。它自己决定要调用什么工具、按什么顺序调用。2.2 Agent 怎么感知环境这里有个设计细节值得展开。Agent 感知环境有两种方式轮询和事件驱动。我一开始用的是轮询每 30 秒拉一次指标效果很差——不仅浪费 token而且 Agent 在没有异常的时候不知道该干什么容易自己编造任务。后来改成事件驱动Prometheus 的告警直接通过 webhook 推到 Agent 的队列里。有事件才唤醒没事件就休眠。日志读取也是一样的逻辑不是把所有日志都塞进上下文而是先从告警里拿到时间和节点信息再去精准取那段时间的关键日志段。这样上下文消耗能控制到最小响应速度也快了。选择 GLM 作为决策层坦白说不是因为它在所有基准测试里分数最高而是三个现实原因第一函数调用的稳定性经得住连续测试不会频繁地不想调用工具或乱调用工具第二中文运维场景理解确实好很多告警信息是中文的它能正确理解节点 NotReady和节点 Not Ready是同一件事第三智谱开放平台可以单独买 API token不绑定任何 IDE接入成本低。后面会讲到我是怎么把它接进现有工作流的。3. RSI 三维评估我对三个关键能力做了实测框架不能停留在嘴上。我做了一套很笨但有效的测试把日常运维里最高频的几十个任务分类分别在三个维度下反复跑记录成功率、失败模式、决策质量。3.1 R Reliability可靠性我第一个测的是可靠性这也是我最初担心的点。一个 Infra Agent 如果偶尔抽风那它在生产环境就是隐患。测试方式是同一批任务连续执行多次观察成功率。任务类型次数成功率典型失败模式节点状态查询10099%偶尔把 JSON 字段名记错磁盘占用排查与清理10095%有一次把清理日志目录内容执行成了删除整个目录结构MySQL 主从状态检查5098%命令超时后没有重试就直接报失败服务重启与健康检查5094%重启前没检查优雅终止配置最让我后怕的是那次删除整个目录结构。复盘时发现Agent 在一条命令里把日志目录路径解析错了导致 rm -rf 的目标变成上级目录。虽然我在工具层做了保护没有真正删掉东西但这个案例让我确定了第一条规则所有危险操作必须二次确认Agent 只有申请权没有最终执行权。排查类任务相对可靠但变更类任务必须加保险。我的应对策略是三层工具白名单、危险命令拦截、变更操作人工确认开关。实测下来加了三层之后高风险操作成功率虽然不变但出错后的爆炸半径被控制住了。3.2 S Scalability扩展性第二个维度是扩展性。单个 Agent 处理单个告警很轻松但真实场景往往是一堆事情同时发生。我做了两个方向的测试单 Agent 同时订阅了 5 个集群的告警。故障注入后Agent 在 5 个事件里出现了优先级误判——它先处理了一个影响面很小的告警把真正导致业务异常的另一个告警排在了后面。问题不在模型而在架构没有做事件优先级预处理。后来我加了一个轻量级的预处理器先把告警按影响面、紧急程度、关联性排序再交给 Agent误判问题基本消失。第二个测试是工具数量对决策质量的影响。我一开始给 Agent 挂了 30 多个工具结果它经常在该用哪个工具上犹豫。后来我把高频工具收敛到 12 个低频操作通过一个执行任意 shell 命令的工具兜底反而更稳。结论工具不是越多越好给 Agent 太多选择等于不给选择。这个维度上模型的上下文窗口反而不是瓶颈。真正的瓶颈是架构设计——事件怎么排队、工具怎么分组、并发任务怎么隔离。这也是我在探索中最大的认知更新Infra Agent 的扩展性问题本质是工程问题不是模型问题。3.3 I Intelligence智能性最后说 Intelligence这是我原来最不看好的维度实测结果却让我最意外。我设计了一个模糊故障场景同时注入 MySQL 主从延迟和磁盘 IO 升高。如果是人来排查很容易掉进主从延迟导致 IO 升高的错误因果里。Agent 的做法是先列出两个可能的假设方向——IO 升高导致主从延迟或者主从延迟导致 IO 升高——然后它没有停在假设阶段而是自己调用了 iostat 和 show slave status 两条命令对比了磁盘等待时间和复制线程状态最后收敛到磁盘 IO 被写满导致主从复制拉取 binlog 变慢。这个结论和正确根因完全一致。更让我触动的是它的不确定性表达。在拿到第一条 iostat 输出时它没有直接下结论而是说当前证据不足以排除另一种可能需要再看复制线程的运行状态。这种能力很重要。很多初级工程师在排障时喜欢拍板看到现象就下结论而 Agent 学会了证据不足时不乱猜。当然它也有明显短板面对从未见过的新型故障时它倾向于按已有知识模板套答案缺乏从零推理的能力。但说实话很多从事执行型运维两三年的人也差不多是这个水平。这就是我说替代不远了的底气。4. 为什么 Infra 被替代也不远了我的三个判断依据单点实验只能说明能力不能说明趋势。真正让我改变判断的是三个量级上的变化。4.1 成本拐点变更 SOP 的执行成本趋近于零传统运维做一次变更人力成本有多高学习成本理解文档、掌握工具、操作时间登录跳板机、敲命令、失误风险一个参数写错可能引发故障、交接成本换个人还要重新培训。折算成钱一次需要评审和开窗的变更成本是几百到几千块钱。Agent 做一次变更呢一次 API 调用几厘钱到几分钱加上一点工具执行时间。更关键的是它不需要学习——你把 SOP 写成 system prompt 或工具描述它立刻就会了。以前做容量扩容要申请资源、排期、手动操作现在 Agent 可以在灰度范围内快速执行失败了回滚成本趋近于零。当一个动作的执行成本趋近于零那这个动作对应的岗位就非常危险了。4.2 速度拐点MTTR 的量级变化我拉了一次传统排障的时长分布发现问题 5 分钟定位问题 30 分钟操作修复 15 分钟合计 50 分钟左右。这还是值班人员经验丰富的情况。Agent 的表现是告警到感知 秒级定位问题 1 到 3 分钟操作修复 1 到 5 分钟合计基本控制在 10 分钟以内。环节传统人工GLM Infra Agent发现问题5 分钟依赖告警人工确认秒级webhook 直接触发定位问题30 分钟翻监控、查日志1~3 分钟工具链自动调用操作修复15 分钟写命令、等审批1~5 分钟自动化执行恢复确认5 分钟秒级自动轮询健康状态MTTR 从小时级降到分钟级对业务的影响是完全不同的量级。以前慢悠悠排查可能已经造成用户投诉了现在往往用户还没感知到故障已经被收敛了。4.3 覆盖面拐点Agent 可以同时盯着所有系统人的注意力是单线程的。看监控大屏的时候没法同时看日志处理一个故障的时候会漏掉另一个告警。Agent 没有这个问题。它可以同时订阅上百个指标、几十个集群的事件流而且不会因为凌晨 3 点而反应迟钝不会因为刚上线了一个高危变更而心态波动。这个覆盖面的不对称是我认为最本质的替代逻辑。以前一个 SRE 能管好的系统数量是有限的因为他的时间、注意力、精力都有限。Agent 打破了这层限制10 个系统和 1000 个系统对它来说只是配置差异不是人力叠加。4.4 一个反直觉的结论AI 先替代的不是高级工程师而是执行型岗位很多人觉得AI 替代人肯定先替代低端岗位高级工程师安全。我的观察恰恰相反Agent 替代的是大量标准化执行动作不管执行者是初级还是高级。一个会写复杂脚本的工程师如果日常充满了看告警、查日志、清磁盘、重启服务这类动作那么这个岗位就是高危的。高级工程师真正的护城河在于设计——设计系统架构、设计故障预案、设计 Agent 的工具边界和决策策略。AI 不是在替代这个人而是在替代他身上的执行类工作。但对那些没有架构能力、只会执行的人来说替代是真的。5. 实操如何把 GLM 接进自己的 Agent 工作流理论说多了容易飘这部分直接给可以照抄的操作路径。我会按买 token → 配置切换工具 → 跑通最小 Demo → 三个可直接用的 Prompt 模板的顺序写。5.1 先到智谱开放平台买 Token很多人问智谱 GLM 可以单独买 API 的 token 吗答案是肯定的。去智谱开放平台注册完成实名认证创建一个 API Key然后充值。不需要买任何绑定 IDE 的套餐API 是独立的。我的建议是先充小额比如 50 到 100 块钱够你跑完一整轮探索实验。控制台里记得设置用量预警避免某个脚本失控把额度烧完。另外模型版本以你在控制台实际能选的为准不同时期开放的版本不一样选最新的稳定版就好。5.2 用 cc switch 管理多模型接入在探索阶段我不可能只测 GLM 一个模型还要横向对比 DeepSeek、Qwen 等。手动改环境变量切模型太痛苦了这里用到了 cc switch。它是个社区常用的模型切换工具可以在 Claude Code、Codex 这些环境里快速切换不同模型供应商。配置思路很简单把各个模型的名称、API Key、base URL 配进去之后一键切换方便做横向评估。举例配 GLM 大概是这样具体字段按工具版本为准cc switch add provider glm \ --api-key sk-你的key \ --base-url https://open.bigmodel.cn/api/paas/v4 \ --model glm-当前版本配好之后在 Claude Code 里切换供应商就是一条命令的事。实测下来GLM 在中文环境的工具调用稳定性不错DeepSeek 在长上下文推理上表现可以Qwen 在结构化和 JSON 输出上比较规整。没有绝对最好只有适合场景。需要提醒的是不同模型的 function calling 格式兼容性有差异。同一个工具定义在 GLM 上正常切到另一个模型上可能解析失败。遇到这种情况不用慌把 tools 定义的结构微调一下或者减少参数嵌套层数基本都能解决。5.3 在 VS Code 里跑通最小 Infra Agent Demo有两种方式。一种是直接在 Claude Code 里接入 GLM 模型用自然语言指挥它执行本地命令这种方式最快10 分钟能跑通。另一种是自己写一个最小工具循环适合想做深度定制的朋友。我给出第二种的骨架代码import json import subprocess from openai import OpenAI client OpenAI( api_keysk-你的key, base_urlhttps://open.bigmodel.cn/api/paas/v4 ) tools [ { type: function, function: { name: kubectl_get_nodes, description: 获取集群节点状态, parameters: {type: object, properties: {}} } } ] def run_cmd(cmd): result subprocess.run(cmd, shellTrue, capture_outputTrue, textTrue) return result.stdout or result.stderr messages [ {role: system, content: 你是基础设施助手负责排查集群异常。必须先验证假设再执行操作。}, {role: user, content: 检查一下集群节点是否有异常。} ] while True: resp client.chat.completions.create( modelglm-当前版本, messagesmessages, toolstools ) msg resp.choices[0].message messages.append(msg) if msg.tool_calls: for call in msg.tool_calls: if call.function.name kubectl_get_nodes: output run_cmd(kubectl get nodes) messages.append({ role: tool, tool_call_id: call.id, content: output }) else: print(msg.content) break这段代码很简单但能让你直观看到闭环是怎么形成的模型请求调用工具 → 本地执行 → 结果回传 → 模型继续决策。实际使用时把工具列表扩展成真实的 kubectl、服务检查脚本就成了一个能用的 Infra Agent 骨架。这里踩过一个坑一开始我给了 Agent 执行任意 shell 命令的能力它会为了凑输出而执行一些无关命令白白消耗 token。后来我把执行权限收敛到命令白名单查状态的走专用函数只有特殊情况才允许走到兜底 shell。这个改动让 token 消耗下降了接近一半决策质量还更稳了。5.4 我自己在用的三个 Prompt 模板这三个模板是我现在写到 system prompt 里的直接抄就能用。故障排查模板你是基础设施排障助手。环境信息如下{集群拓扑}。 收到告警时按以下步骤执行 1. 先描述你对问题的初步假设。 2. 调用工具验证假设只采集能区分不同假设的数据。 3. 证据不足时明确说当前证据不足以判断不要强行下结论。 4. 执行变更前先说明影响范围并申请确认。 5. 恢复后用健康检查确认再输出变更摘要。变更执行模板你的任务是完成配置变更。目标{变更目标}。 影响范围{节点/服务列表}。 约束不得跳过回滚预案变更前快照必须是成功的任何一步失败立即停止并报告。定期巡检模板每天{固定时间}执行一次巡检。巡检范围{指标列表}。 输出格式 - 正常项一句话说明依据 - 异常项附关键数据链路 - 建议动作标注优先级这三个模板分别覆盖了故障、变更、巡检三类最高频场景。模板本身不复杂关键是里面嵌的先假设后验证证据不足不乱说变更前确认影响范围这些约束比你在对话里反复强调一万遍都管用。6. RSI 之外我还想提醒的三个边界问题能力再强边界问题不解决Agent 永远只能停留在 Demo 阶段。这几个月我踩过的坑整理成三条最重要的提醒。6.1 权限边界Agent 不能拥有无限 root这是最重要的一条。我给 Agent 的所有权限都遵循最小权限原则查状态用只读账号变更操作走专门包装过的脚本危险命令在工具层直接拦截。比如 rm -rf 这类命令Agent 可以申请但必须有单独的二次确认通道确认人只能是真正理解了风险的人类。配套要做的是完整的审计日志。每个 Agent 动作谁触发、做了什么、输出什么、耗时多少全部落库。没有审计能力的 Agent就算能力再强我也不会放进生产环境。6.2 幻觉可能造成误变更模型在上下文缺失时可能为凑出一个看似合理的答案而编造命令。比如有一次模拟场景Agent 在拿不到节点 IP 的情况下试图用一个看起来像的 IP 去执行操作。这提醒我所有变更动作必须强制经过 dry-run 或 diff先看预期差异再决定是否执行。更稳妥的做法是高风险操作一律走人工 approve 流程。Agent 把执行计划和影响范围写清楚人点确认Agent 才动手。这个过程虽然多了一步但换来的是可控性值得。6.3 Agent 密度被低估的组织问题当团队里只有一个人在用 Agent 时风险是可控的。但当一堆 Agent 同时在系统里跑变更人的大脑就跟不上了到底是谁改了什么哪个变更导致了指标抖动如果没有统一的变更记录和追踪系统几台 Agent 同时在跑就是一个灾难。我的建议是所有 Agent 动作落地为可审计的工单或 Pull Request而不是直接改服务器。让每一次变更都像一次代码提交一样有记录、有审批、有回滚点。这套流程成熟之前我不建议大规模放权。6.4 对 Infra 从业者的建议成为定义 Agent 的人我理解很多做运维的朋友看到被替代三个字会不舒服。但根据我这几个月的经验最值得做的不是抵制而是换赛道。以前你的价值在于知道怎么操作——会配 Nginx、会调内核参数、会搭监控。这些确定性极强的操作Agent 学得比你想象中快得多。真正抗替代的能力是知道为什么这么设计。为什么这个系统要这样拆分为什么故障预案要留这个回滚点一个指标抖动是改阈值还是改架构这些决策层面的问题Agent 暂时还给不出比人更好的答案。所以我的建议是把时间和精力从背命令、写脚本转移到设计 Agent 的 system prompt、定义 tool policy、梳理故障树这些事情上。你不再是一个手动执行者而是成为 Agent 的架构师。不是 Infra 这个领域会消失而是手动操作 Infra这个技能会贬值。尽早转换风险远小于收益。7. 最后再说几句这轮 RSI 探索做下来我最直接的感受是以前我的日常是写 runbook、写告警规则、把一次次排障经验沉淀成文档给别人看。现在的日常变成了写 system prompt、定义工具边界、给 Agent 的决策流程加保险。工具变了但让系统稳定运行这个目标没变。如果你也在观望要不要让 Agent 参与基础设施工作我的建议是先从只读和巡检类任务开始跑一个最小的闭环把 RSI 三个维度都测一遍再逐步扩大权限范围。这个过程你会更清楚地看到哪些工作真的可以被替代哪些必须由人来决定。最后再分享一个小技巧评估任何 Infra Agent 之前先设计好它试验失败时会发生什么。只要失败被安全地控制在模拟环境或灰度范围内大胆让它多跑几次比你在文档里纠结一个月更有用。毕竟我们这行最不缺的就是真实故障缺的是敢于把故障交给 Agent 试一次的第一步。