企业官网建设流程全解析

凌晨两点半，告警群又开始刷屏。值班的人把几十条告警按主机和时间聚合，最后发现只有一个真实故障，但大家已经在列表里翻了十分钟。这个场景我见过太多次。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 或者 L1，AIOps 是 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 给值班人员推荐操作，人不点执行它就不动。半自动阶段，低风险动作自动执行，中高风险给人确认。全自动阶段，所有白名单内低风险动作都自动执行，但保留人工抽检和每日审计。

阶段切换的指标要提前定好。我常用的指标表如下：

这个灰度周期视场景复杂度和团队精力而定，短则两周，长则两个月。不要觉得影子模式浪费时间，它往往是整个项目里信息浓度最高的阶段。模型在测试环境表现再好，都不如真实告警流里的案例有说服力。

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 的上下文简化结果，再看它生成的计划 JSON。大部分问题出在这两层之间，上下文不够会让模型瞎猜，计划不够结构化会让执行层无法兜底。把这两层日志加上 trace ID，定位问题会快很多。

最后再分享一个小技巧。别追求“全自动 Agent”，它不是一个能一键处理所有故障的万能盒子。我目前的做法是定期把 Agent 丢回影子模式，让它对新出现的故障类型做计划，人工评估后再放开执行。每次大模型升级、监控平台改版、业务架构调整后，都要重新跑一遍灰度。这个节奏不算性感，但能让 Agent 一直保持在可信边界内。