从“写脚本”到“管Agent”：运维人的技能树该往哪长？

凌晨三点，服务器告警把你吵醒。你打开终端，熟练地敲下一串shell命令，或者跑出那个珍藏多年的Python脚本，问题解决了。但突然有一天，你发现新来的AI Agent能在30秒内定位故障、生成修复方案、自动执行变更，还附带一份人类能看懂的复盘报告——你花了五年打磨的“手艺”，好像突然不够用了。

脚本的天花板：你写的不是自动化，是“数字债务”

很多运维人引以为傲的技能，是能徒手写出一套优雅的Shell脚本或Ansible Playbook，把重复劳动一键搞定。但现实是，脚本是“把人的经验固化成代码”，而世界是动态的，代码却是静态的。

你写了个自动扩容脚本，规则是“CPU超过80%就加机器”。可某次流量突增的同时，下游数据库也出现了慢查询，脚本只会机械地扩容应用节点，不仅没解决问题，反而把数据库连接池打爆。更别提那些年久失修的脚本：参数硬编码、依赖环境隐式、异常处理靠try-except一把梭。脚本越写越多，维护成本指数级上升，最后变成一堆没人敢动的“数字债务”。

Agent进场：运维闭环正在被重写

与传统脚本不同，AI Agent介入的是完整的运维闭环：感知、决策、执行、复盘。

举个例子。一次线上支付接口超时，传统流程是你登录机器、看日志、查监控、猜原因。而现在，告警触发后，Agent可以自动拉取过去一小时的Metrics、分布式链路追踪、最近的发布记录，交叉分析后给出判断：“疑似订单服务缓存击穿，导致数据库QPS陡增，建议先限流再扩容缓存节点。”你点击确认，它执行，然后生成一份包含根因、影响面和后续优化建议的报告。运维的核心价值，正从“知道怎么修”转向“知道该不该修、修到什么程度”。

新技能树：提示工程与流程编排

当Agent成为基础设施的“新同事”，你的技能树必须换个长法。

第一是提示工程。 这不是简单的“聊天提问”，而是给Agent设定清晰的指令、边界和上下文。比如你设计一个“变更审批Agent”，你要明确告诉它：生产环境只允许重启无状态服务，涉及数据库schema变更必须停下，所有操作必须留下审计日志。提示写得越精准，Agent的决策越靠谱。

第二是流程编排。 现实中的运维场景很少靠一个Agent搞定。你可能需要“监控Agent”发现异常，“诊断Agent”分析根因，“执行Agent”负责变更，“通知Agent”同步给人。你的工作，是设计这些Agent如何分工、如何交权、如何在异常时升级到人类。你不再是“命令执行者”，而是“智能体策略设计师”。

别让黑箱失控：构建可解释的运维工作流

运维最怕不可控，AI最怕不可解释。如果你只让Agent跑，却看不懂它为什么这么做，那等于把生产环境交给了一个黑箱。

我的实践原则是：可解释性不是技术选项，是运维的安全带。 每个Agent的关键决策必须可追溯，涉及数据删除、核心配置修改、资金相关操作，必须设置人工确认点，并且用人类能看懂的语言解释“我建议这么做，因为……”。以前我们写“运维手册”，现在我们要写“Agent策略文档”——规定它能做什么、不能做什么、遇到模糊情况如何求助。把黑箱变成灰箱，甚至白箱，是运维人管理AI的底线。

未来已来：人机协作的新范式

未来的运维，不是“人管机器”，也不是“机器管机器”，而是“人管Agent，Agent管基础设施”。

想象一个普通的工作日：你早上到工位，Agent已经自动处理了80%的常规告警，重启了僵死的Pod，清理了磁盘，还拦截了一次异常登录。你不需要逐条审阅日志，只需要看它的“晨报”，调整一下昨晚新上线服务的扩容阈值策略。你的时间，花在定义规则、设计边界、处理Agent搞不定的边缘case，以及持续优化它的表现上。最贵的不是算力，是你设计规则的能力。

从写脚本到管Agent，变的不是“技术”，是“思维方式”。脚本时代，我们追求“一次写对，永远运行”；Agent时代，我们要接受“持续对话，动态纠偏”。运维人的护城河，从来不是会写多少行代码，而是对系统复杂度的理解，和对风险的敬畏。

技能树该往哪长？往“让AI替你打工，但你能看懂它每一步”的方向长。

你开始用AI Agent做运维了吗？或者你觉得哪些环节绝对不能交给AI？评论区聊聊。