凌晨两点半告警群又开始刷屏。值班的人把几十条告警按主机和时间聚合最后发现只有一个真实故障但大家已经在列表里翻了十分钟。这个场景我见过太多次。AIOps 这个概念提了很多年告警压缩、异常检测、根因分析都逐步落地但从“知道哪里坏了”到“把问题彻底修好”之间始终隔着一个人。最近圈内开始聊 Agentic Operations直译过来是“代理式运维”我更喜欢叫它智能体运维。它不是简单把大模型接到告警群里而是让 AI 具备感知、判断、执行、复盘的能力真正参与故障处置闭环。这篇文章我想重新理一遍 AI 运维的变化AIOps 做到了哪一步Agentic Operations 补上了什么以及一个可以落地的告警处置 Agent 到底该怎么搭。1. 先别急着追概念AIOps 现在的边界我帮你划清楚1.1 AIOps 在过去几年解决的真实问题先说结论AIOps 没有失效它只是停在了决策层。过去这些年AIOps 的核心工作是把运维数据转换成判断。一个比较成熟的项目通常会把监控指标、日志、链路追踪、配置管理数据放进统一平台再通过算法做四类事情异常检测、告警降噪、根因分析、趋势预测。举一个我经手过的例子。某个系统的数据库实例抖动从应用层看是接口超时从网络层看是连接数飙升从数据库看是慢查询变多。如果没有算法值班人员会同时收到应用告警、数据库告警、网关告警每一条看起来都像根因。AIOps 来了之后它能把时间窗口内、主机拓扑相关的告警聚合成一个事件并给出“慢查询导致数据库连接池被打满”的初步判断。这个能力很值钱。它把原本需要资深运维反复对照多个系统的排查过程压缩成了几秒钟的分析结果。静态阈值也被动态基线替代比如流量在业务高峰和低峰时期走势完全不同固死的 CPU 告警阈值必然造成误报。AIOps 把“正常范围”变成了一条随业务变化的曲线这件事靠人肉经验做不完美。但你会发现这些能力都停留在“告诉人发生了什么”。它回答了“哪里有问题”却没有回答“下一步做什么”。我一直认为AIOps 的真正价值是给后面的智能体运维铺路没有准确的结构化上下文任何执行层自动化都等于盲人开车。1.2 为什么很多落地项目最后变成了“大屏监控”我在某个跨平台系统项目里见过一个典型情况异常检测算法准确率已经到 90% 以上能提前十分钟预测磁盘性能瓶颈但整体故障恢复时间几乎没有下降。为什么因为值班流程还是老样子收到告警、打开知识库、问同事、登录机器、执行命令、确认结果。AI 输出的分析报告只是被当作一个参考文档值班人员不信任它甚至懒得看。这就是“大屏监控”陷阱。很多 AIOps 项目上线之后领导看到的是炫酷的大屏、实时滚动的告警瀑布流但一线运维的日常工作方式并没有改变。分析结果和实际处置之间缺少一个执行闭环AI 再聪明也只是个“诊断书打印机”。另外配置和维护一套 AIOps 模型本身就费人力如果模型产出的建议没有直接转化为行动团队很容易失去耐心最后把模型关掉。真正的问题不在算法而在流程。人仍然是处置链路上不可替代的环节但人的时间和知识沉淀是有限的。AIOps 把决策速度提上来了可行动速度还停留在“人看手册、人敲命令”的层面。这也是 Agentic Operations 出现的最直接动因。1.3 从“辅助决策”到“自主执行”的断层传统 AIOps 的人机循环是数据采集、算法分析、通知值班人员、人员判断、人员执行。关键瓶颈在最后两环。夜间故障、突发流量、复杂的微服务环境对值班人员的要求越来越高而资深专家不可能 7×24 小时在线。这导致 AIOps 分析得再准实际恢复时间还是受制于人的响应速度和操作水平。Agentic Operations 做的事情是把“人判断、人执行”这一段改成“AI 判断、AI 执行、人监管”。如果拿自动驾驶来类比传统监控告警是 L0 或者 L1AIOps 是 L2它能帮你做分析和部分建议。而 Agentic Operations 至少是 L3 甚至 L4在限定场景内智能体可以自主完成闭环只在超出边界或者高风险动作时交给人工。注意我没有说它取代 AIOps。Agentic Operations 是以 AIOps 作为认知底座再加一层行动能力。它需要异常检测结果需要根因分析线索需要可观测数据作为反馈信号。这也是为什么目前讨论 Agentic Operations 最多的往往不是只做监控的团队而是已经有 AIOps 基础、正在尝试自动处置的团队。2. Agentic Operations 落地时先按四层架构拆2.1 核心定义与最小单元一个能看、能想、能动、能复盘的运维角色Agentic Operations 在我理解里是一套让 AI 以“智能体”形态参与运维工作的方法论。最小单元不是一个机器人而是一个具备四层能力的系统感知层、决策规划层、工具执行层、反思反馈层。感知层负责把监控指标、日志、告警、配置信息变成结构化上下文。这一步不能是“把日志全量喂给大模型”而是要按告警指纹去收集与本次事件相关的数据。决策规划层负责理解当前状态、目标和约束拆解出操作计划。它可以使用大模型但必须叠加规则和策略。工具执行层不是给 Agent 一台随便敲命令的服务器而是给它一组封装好的原子工具通过 API 或自动化平台调用。反思反馈层则负责验证动作是否生效并且把经验沉淀下来。我用一个生活化类比你招了一个新运维第一周你会这样带他。先让他看监控屏理解系统正常长什么样再教他查知识库遇到故障先翻手册执行操作前必须列计划让你批准做完之后还要写复盘。Agentic Operations 就是把这个过程软件化只不过这个“新运维”学东西很快但偶尔也会天马行空。所以你要给它设边界。2.2 为什么大模型是这个拐点但你不能裸奔很多人问以前也有自动化脚本和流程编排为什么非要用大模型因为传统自动化是 if-then-else 的逻辑它能处理已知故障却很难处理长尾问题。比如“证书快到期某些客户端开始握手失败”这种情况规则要写清楚几乎不可能。大模型可以读错误日志、看连接状态推理出“证书”这个共同原因。但大模型天生有三个问题幻觉、延迟、成本。它会一本正经地提出一个不存在的命令也会在一个简单问题上输出一大段废话。所以在 Agentic Operations 里我的原则很明确大模型负责开放性的理解和拆解规则引擎负责守住边界。两者结合而不是二选一。模型选型也要分层。不是所有告警都需要调用最强的大模型简单分类用轻量级模型复杂规划才调用大模型。这样做既能控制成本也能避免“杀鸡用牛刀”带来的响应延迟。实际操作里我甚至会要求模型输出置信度低于阈值就直接转人工不要让它硬编。2.3 最小可行 Agent 的五个模块与关键参数一个最小可行的告警处置 Agent我会拆成五个模块告警接入器、上下文收集器、策略引擎、大模型规划器、验证与记忆。告警接入器负责统一事件格式和指纹去重防止同一个故障反复触发。上下文收集器根据告警指纹决定拉哪些指标、日志和拓扑信息先拉摘要再拉明细。策略引擎先判断动作风险等级它应当优先于大模型判断。大模型规划器负责生成操作计划。验证与记忆负责在动作执行后确认指标变化并把案例写进经验库。下面是一段简化伪代码真实系统里还有很多超时、重试和审计逻辑class OpsAgent: def __init__(self, tools, policies, memory): self.tools tools self.policies policies self.memory memory def collect_context(self, alert): return build_context(alert, self.tools) def plan(self, context): similar self.memory.retrieve(context.alert_fingerprint) if similar: return similar.action_plan return llm_plan(context, self.tools.describe(), self.policies.rules) def execute(self, plan, alert): for step in plan: if self.policies.is_high_risk(step): human_approve(step) result self.tools.run(step) if not verify_effect(alert, context, result): self.replan(step, result) self.memory.save(alert, plan, result)几个关键参数值得提前定好。执行步骤上限建议不超过三步避免 Agent 在一个问题上无限循环。大模型调用超时控制在十秒以内超时就走规则通道。如果模型输出里带置信度字段低于 0.8 的动作直接转人工。单个告警的上下文 token 预算控制在三五千以内防止成本和延迟失控。这些参数来自我落地时的真实调整不一定适合所有团队但思路可以复用。3. 从零落地一个告警处置 Agent 的实操过程3.1 先选一个高频低危场景别一上来就全自治我第一次落地 Agentic Operations 时最大的教训就是贪多。什么故障都想让 Agent 处理结果既不敢自动执行模型也频繁出错。后来收敛到一个简单场景磁盘分区使用率超过 85%并且存在可安全清理的临时文件。选这个场景的理由有四个高频、低危、判断标准清晰、操作可逆。高频意味着容易收集样本和验证效果低危意味着即使判断失误影响也可控判断标准清晰意味着代码层面可以兜底而不是完全依赖大模型操作可逆意味着删除前可以先移动到回收目录而不是真正抹掉数据。你最好也先找一个类似“低垂的果实”把一条链路跑通积累信心后再扩场景。场景确定后目标要具体。比如“磁盘清理 Agent 在告警出现后五分钟内完成自动确认和清理成功率超过 90%误操作率为零”。这个目标能指导后面的数据和工具设计也能用来评估灰度效果。没有目标后面很容易被各种技术细节带偏。3.2 环境准备与数据接入只读、受限、留审计告警处置 Agent 要连接三类系统告警平台、可观测平台、执行通道。告警平台提供 Webhook 或 API把告警事件推给 Agent。可观测平台提供指标查询和日志查询接口给 Agent 读取上下文使用。执行通道用于跑动作这里要特别小心我不建议直接给 Agent 一个生产环境 SSH 权限而是让它在自动化运维平台里调用封装好的原子任务。原子任务的设计举例不是给 Agent 自由执行 rm 命令而是给它一个“清理目录”工具工具的参数只能是目录白名单里的目标并且必须先生成模拟清单确认后再执行。Agent 使用的账号应当独立权限最小化每次操作都要有审计日志。这个账号还能控制来源 IP、操作时间避免被滥用。数据接入的时候有一个容易踩的坑查询接口超时。监控平台在高峰期很慢如果 Agent 等上下文等到超时它可能会基于不完整信息做判断。我建议上下文收集器设置两秒超时超时后走“仅用告警信息规则判断”的降级路径而不是硬重试等到数据齐全。宁可用少一点的数据快速转人工也不能让模型在一份残缺数据里编理由。3.3 告警处置工作流与提示词骨架一个标准的告警处置流程可以拆成八步。第一步接收告警并校验来源去重。第二步收集上下文包括分区使用率、最近三十分钟变化趋势、大文件目录快照。第三步判断是否属于允许自动处置的范围比如路径是否在白名单。第四步规划动作生成清理临时文件的候选方案。第五步影响评估预计释放空间是否足够、目标文件是否有软链风险。第六步执行清理可以 dry-run 先行。第七步验证再次查询使用率是否降至目标以下。第八步记录经验并关闭或升级告警。提示词设计上我倾向于让大模型输出结构化 JSON而不是自然语言因为程序要能稳定解析和校验。下面是一个提示词骨架可以直接参考你是运维执行代理。当前告警如下{alert} 已收集到上下文{context} 可用工具{tools} 约束{rules} 请依次输出操作计划格式为 JSON 列表。 每个操作必须包含 action, target, params, reason。 如果你没有足够信息或把握低于90%请输出 handover 并说明原因。这里的关键是“让大模型做选择器而不是发明者”。候选工具列表和路径白名单已经准备好模型只需要从里面选并排序。如果想让它自由发挥命令它会真的给你编一个 rm -rf 出来。另外提示词里要明确输出 handover 也是一种合法结果不要强迫它“必须处理”否则模型会在不确定时强行猜测。3.4 安全护栏与人工接管设计安全护栏设计是整个系统里最重要的一环。我给动作分了四个级别观察级、低风险操作、中风险操作、高风险操作。观察级包括查询指标、读取日志自动执行并记录审计。低风险操作包括清理指定临时目录、触发日志轮转可以自动执行但需要事后抽样检查。中风险操作包括重启无状态服务必须由值班人员点击确认。高风险操作包括重启数据库、变更网络策略Agent 只允许给建议不能直接执行而且要双人审批。这个审批矩阵背后的逻辑是不要用同一把尺子衡量所有操作。AI 自动执行的价值在于把人从低价值重复劳动里解放出来不是说所有决策都可以不经过人。即使是低风险自动执行也要保留事后审计和回滚手段。比如清理临时文件时我要求 Agent 先把文件移动到回收目录而不是直接删除观察一天后再物理清理这样即便判断错误也能恢复。还要加两层保护。第一循环上限Agent 在一次处置里最多执行三次验证超过三次就升级人工。第二冷却时间同一告警指纹在十分钟内不允许重复自动处置避免告警抖动导致 Agent 反复动作。3.5 灰度放量与效果评估指标上线不能一刀切。我会分成四个阶段影子模式、建议模式、半自动、全自动。影子模式里 Agent 只读不执行每次处理都输出计划人工逐条比对判断够不够准。建议模式里Agent 给值班人员推荐操作人不点执行它就不动。半自动阶段低风险动作自动执行中高风险给人确认。全自动阶段所有白名单内低风险动作都自动执行但保留人工抽检和每日审计。阶段切换的指标要提前定好。我常用的指标表如下指标计算方式参考目标自动处置率自动关闭告警数 / 应处置告警数初期 30% 以上处置成功率自动处置后指标恢复正常 / 自动处置总数90% 以上误操作率人工介入修正数 / 自动处置总数0.5% 以下MTTR 下降对比启用前后平均恢复时长下降 50% 左右这个灰度周期视场景复杂度和团队精力而定短则两周长则两个月。不要觉得影子模式浪费时间它往往是整个项目里信息浓度最高的阶段。模型在测试环境表现再好都不如真实告警流里的案例有说服力。4. 踩坑记录从“什么都想自动化”到“找到边界”4.1 最典型的坑Agent 在错误上下文里自信决策我见过一个特别典型的案例。某台业务数据服务器磁盘使用率持续上升Agent 检查后发现某个目录下有一个 backup.tmp 文件体积很大名字看起来像临时文件于是判断可以删除。但实际上那个目录挂载了独立数据卷备份脚本正依赖这个路径删掉之后备份任务直接失败数据没能完整落盘。问题出在上下文收集器没有解析挂载信息也没有做软链检查。大模型的判断基于不完整的上下文它却表现得很自信。从那之后我要求所有涉及文件删除的动作在执行前必须经过一个“路径安全校验器”先用系统接口拿到目标路径的真实路径确认它落在白名单目录内再检查目录是否存在独立挂载点最后把操作方式改成“先移动到回收目录”。这样即使判断错了还有后悔药。这个坑给我的启发是不能让大模型去理解文件系统权限和挂载关系这些事应该用确定性的代码去校验。AI 负责给方向和边界但真正的操作能不能做得由规则说了算。4.2 Token 与性能预算失控一次告警吃掉 20 万 token早期版本里我把最近一小时的原始日志全文、所有指标点、整张拓扑图全部塞给大模型想着“信息越充分判断越准”。结果是单个告警平均消耗接近二十万 token一次处理延迟超过二十秒夜间告警高峰时模型接口直接排队整个 Agent 形同虚设。后来我做了三层裁剪。第一层日志内容让规则引擎先提取摘要错误码、异常栈前二十行、时间分布这些有信息价值的字段单独结构化其他原文丢弃。第二层指标只保留最近三十分钟的采样点和环比变化不使用全量历史曲线。第三层CMDB 信息只取主机角色、归属服务、负责人、关键挂载点不拉全量配置。这样单个告警的上下文稳定在三五千 token 以内延迟降到五秒以内。计算一下成本变化更直观。假设每天自动处置一万条告警之前一条二十万 token总消耗二十亿 token。裁剪后一条五千 token总消耗五千万 token成本下降九成以上。再加上轻量模型处理简单分类大模型只处理复杂规划费用还能进一步压缩。4.3 反思层不是“写日记”我改成了结构化经验库一开始做反思层就是让大模型每次处理完写一段总结然后丢到文档库里。执行了一周发现这些总结根本没法用。当你搜“磁盘”时会出来几百条记录内容五花八门还得人一条条看。所谓的“经验沉淀”变成了没有索引的垃圾堆。后来我重新设计了经验库 schema。每条经验包含告警指纹、环境标签、问题分类、根因类别、执行动作序列、执行结果、可复用条件、负向标签。系统处理完一个事件后会把这次处置提炼成结构化记录做向量化存入检索服务。下次遇到相似告警先检索历史经验命中直接参考不重复规划。这个改动最大的价值是让 Agent 能“越用越准”。但注意自动化产生的经验也会自动积累错误所以需要定期人工抽检。我会每周抽三十条经验记录审核是否有动作不合理、结论错误如果有就标记反例并重新向量化。经验库一旦被坏案例污染Agent 的后续判断会越来越歪这个风险必须控制。4.4 常见问题速查表现象可能原因处理建议Agent 自动执行了无关操作上下文收集没有限定主机和路径维度增加关联约束和路径白名单校验Agent 不执行一直升级人工规则过严或提示词里没有给足够信息检查规则配置拆小任务让模型有明确可行的候选动作同一条告警反复触发Agent 反复处理缺少状态指纹和冷却时间增加告警指纹去重和十分钟冷却窗口大模型响应慢日志原文塞得太多模型排队裁剪上下文、并行检索、轻量模型优先模型生成了不存在的命令工具列表和参数定义不清晰改用函数调用工具白名单化禁止自由命令自动处置成功了但评估指标没变化指标取数口径和告警恢复条件不一致对齐验证逻辑用告警恢复信号作为最终判定我自己最常用的一条排查思路是先看 Agent 的上下文简化结果再看它生成的计划 JSON。大部分问题出在这两层之间上下文不够会让模型瞎猜计划不够结构化会让执行层无法兜底。把这两层日志加上 trace ID定位问题会快很多。最后再分享一个小技巧。别追求“全自动 Agent”它不是一个能一键处理所有故障的万能盒子。我目前的做法是定期把 Agent 丢回影子模式让它对新出现的故障类型做计划人工评估后再放开执行。每次大模型升级、监控平台改版、业务架构调整后都要重新跑一遍灰度。这个节奏不算性感但能让 Agent 一直保持在可信边界内。