# 绵里藏针才是 AIOps 的本质？

Agent 让运维编排变得柔性、可变、甚至自演进；但真正敢进入生产环境的 AIOps，仍然离不开坚实、受控、可审计、可回退的自动化底座。

从 Gartner 提出 AIOps 概念到现在，也大概有十年了。这么多年来，这个领域好像发生了很多变化，又好像没什么“本质”的变化。技术上，我们经历了传统机器学习、深度学习和神经网络、以及大模型和智能体这样“翻天覆地”的变化；业务上，我们面对的是更多品种、更大数量的基础设施、更复杂的软件拓扑，以及更大范围的地理分布。云原生、IAC 等也大大的提升了我们的自动化能力。然而从观测到 SOP 这个过程似乎没有变过：无非是观测更大范围、告警（可能）更加精确，自动化手段更加丰富、以及辅助决策、知识库等让我们更好的选择和创建 SOP。

但 Agent 大行其道之后，AIOps 的问题突然变得有点“暧昧”了。

过去我们问的是：机器能不能更快地发现异常？能不能更准地定位根因？能不能把某个已知的恢复动作自动执行掉？这些问题背后隐含着一个前提：**人写流程，机器跑流程**。机器的智能，主要体现在识别、推荐、归因、预测、降噪这些环节上。至于真正要做什么、先做什么、做到哪一步停下来，仍然由人沉淀在 SOP、Runbook、Pipeline、Workflow、Playbook 里。

今天我们开始问另一个问题：如果 Agent 能理解目标、读取上下文、调用工具、观察反馈、修正策略，那么它能不能自己把一次运维处置“编排”出来？

这时，AIOps 不再只是“更聪明的监控”或“更自动化的工单系统”。它变成了一种新的运维生产关系：**不再是人把所有步骤预先写成流程，而是人把边界、目标、工具和责任交给系统，由 Agent 在边界内完成动态决策。**

这听起来很性感，但也很危险。因为生产环境不是沙盘，Agent 的每一次探索，都可能触碰真实资产、真实流量、真实客户、真实合规责任。于是，AIOps 的本质反而显露出来：它不是让 AI 在生产里“自由发挥”，而是在柔性的智能外面，包一层足够坚硬的工程外壳。

也就是说，真正可用的 AIOps，应该是**绵里藏针**。

“绵”，是 Agent 带来的柔性：它能理解模糊目标，能组合工具，能根据反馈调整路径，能在经验中沉淀新的处理模式，甚至能让 SOP 涌现出来。

“针”，是自动化与治理底座带来的刚性：每一个动作都要有权限边界、参数校验、幂等设计、影响面评估、审计记录、回滚机制和失败保护。Agent 可以决定“用哪根针、什么时候下针、下几针”，但不能绕过针本身的工艺。

## 一、AIOps 只是豪华版 ChatOps 吗？

很多人第一次接触 AI Native AIOps 时，会自然地把它理解成一个更聪明的 ChatOps：以前是在群里 @ 机器人查指标、拉日志、重启服务；现在是把同样的事情交给大模型，用自然语言表达得更顺滑一点。

这个理解不能说错，但它只看到了表层。

ChatOps 的核心，是把“人类协作界面”搬到聊天窗口里。它真正改变的是入口：从控制台、脚本、工单系统，变成 Slack、飞书、企业微信、钉钉这样的会话界面。它降低了操作门槛，也让上下文更容易被团队共享，但主流程仍然是人控制的。人知道自己要查什么、点什么、跑什么命令，机器人只是把动作包装成更方便调用的接口。

而 AI Native AIOps 的核心，不只是入口变化，而是**控制权的部分迁移**。

过去，流程是人写好的。无论是通用编程语言、BPML、HCL，还是云原生世界里的 YAML，本质上都是用语言明确描述流程走向：先做 A，再判断 B，如果满足条件就做 C，否则做 D。流程的连接物，是机器代码和确定性逻辑。

现在，Agent 主动或者受命触发，其根本目标是完成变更或者维持稳定。中间的流程、节点、分支、重试、降级、观察和停止条件，未必都在事前被完整写死。真正把这些节点串起来的，可能是大模型在每一步做出的“小决策”。

*   当前告警是否需要扩大观测范围？
    
*   这个异常是容量问题、依赖问题、配置问题，还是发布引入的问题？
    
*   是否需要先冻结变更窗口？
    
*   是否允许执行降级？
    
*   是先切流量，还是先扩容？
    
*   当前证据是否足够进入处置阶段，还是继续观察？
    

**ChatOps 是人在聊天窗口里调用自动化；AI Native AIOps 是 Agent 在治理边界内编排自动化。**

![ChatOps 与 AI Native AIOps 的差异](assets/figure-1-chatops-vs-aiops.png align="center")

![](https://cdn.hashnode.com/uploads/covers/680de39180c68f1c7a6ae2f1/b23985cd-51af-48fc-9da4-54856dbc3451.png align="center")

## 二、从“流程即代码”到“决策即流程”

过去十几年，IT 运维自动化有一个很强的工程信念：流程要代码化。

基础设施要用 IaC 描述，部署要用 Pipeline 描述，配置要用 Git 管理，变更要用工单约束，响应要用 SOP 固化。这样的体系非常重要，因为它把人脑里的经验变成可复用、可审计、可版本化、可回滚的工程资产。

但它也有一个天然限制：**流程必须预先被想清楚。**

只要现实世界的复杂度超出设计者预期，固定流程就会变得笨拙。比如一次故障可能同时涉及云厂商网络抖动、上游依赖超时、缓存雪崩、发布变更和某个区域的容量水位。你当然可以为每一种情况写 SOP，但组合爆炸会让 SOP 越来越厚，最后变成没人敢动、没人看完、也没人能维护的知识坟场。

Agent 的价值，恰恰在于它能处理这种“不完全预定义”的场景。

它可以把一次处置理解成一个目标搜索过程：现在的目标是恢复稳定，约束是不能扩大影响面、不能违反变更窗口、不能越权操作、不能触碰某些敏感资源；可用手段包括查询监控、读取日志、比对变更、调整流量、扩缩容、回滚发布、创建工单、通知值班人员。每执行一步，都观察反馈；每获得新证据，都更新判断；每接近高风险动作，都请求审批或转人工。

这时，流程不再完全来自预写代码，而是来自连续决策。

**传统 AIOps 是“先有 SOP，再有自动化执行”；AI Native AIOps 是“先有受控自动化能力，再让 SOP 在 Agent 的决策中涌现”。**

这不是说 SOP 不重要了，而是 SOP 的形态可能发生变化。过去 SOP 是一条固定路径：第一步、第二步、第三步。未来 SOP 可能更像一个策略空间：哪些动作可以做，哪些动作不能做，做到什么程度必须停，什么证据足以进入下一阶段，什么风险必须升级给人。

## 三、越柔性的 Agent，越需要坚硬的自动化底座

这里有一个容易被忽视的悖论：

> **Agent 越聪明，底座越不能“软”。**

如果一个系统只能执行固定脚本，那么风险边界相对清楚。脚本写错当然会出事，但它至少不会临场发明一个你没见过的操作路径。

而 Agent 不一样。它的优势就是组合、迁移、泛化和探索。它可能在一次故障中发现新的关联，也可能在一次变更中选择一条过去没人写进 SOP 的路径。这正是它有价值的地方，也是它危险的地方。

因此，真正能进生产的 Agent，不能直接拿到裸 API、裸命令行、裸控制台权限。它需要调用的是一组经过工程化封装的“安全手脚”。这些手脚至少要满足几个条件：

**第一，动作边界清楚。**比如“扩容”不是一句 `kubectl scale`，而是一个受控动作：只允许在某些命名空间、某些服务等级、某些容量上限内执行；超过阈值必须审批。

**第二，参数可校验。**Agent 生成的每个参数，都必须经过类型、范围、资源归属、环境、影响面的检查。不能因为一句自然语言理解偏差，就把生产流量切到错误区域。

**第三，执行可观测。**自动化动作不仅要返回成功或失败，还要返回足够详细的状态：做了什么、影响了哪些资源、耗时多久、当前是否收敛、有没有副作用。

**第四，失败可回退。**没有回滚能力的自动化，只能叫脚本，不能叫生产级手脚。Agent 可以柔性决策，但它依赖的动作必须能安全撤销，至少要能停止、降级、隔离或补偿。

**第五，过程可审计。**谁触发的、Agent 基于什么证据做出的决策、调用了哪个工具、工具执行了什么、结果如何、是否经过审批，这些都必须被记录下来。否则，法务、合规、安全、审计等 Stakeholder 的意志就无法进入系统。

这也解释了为什么“绵里藏针”很重要。

外面看起来，AIOps Agent 像棉花一样柔软：能对话，能推理，能协作，能自我调整。但它真正触碰生产环境时，必须通过一根根硬针：标准化、可验证、可审计、可回滚的自动化能力。

图 2：Agent 可以柔性编排，但动作必须刚性受控

![](https://cdn.hashnode.com/uploads/covers/680de39180c68f1c7a6ae2f1/0ab358f7-ef3b-4b5d-82a1-a7ff1c220f71.png align="center")

## 四、合规不再只是审批流，而会成为 Agent 的知识和性格

传统运维体系里，法务、合规、安全、财务等 Stakeholder 的意志，通常通过流程表达：谁审批、谁复核、什么时间能变更、哪些系统需要双人确认、哪些数据不能出域、哪些操作需要留痕。

在 AI Native AIOps 里，这些约束不应该只存在于审批流里，还应该进入 Agent 的知识、工具描述、策略引擎和运行时守卫里。

也就是说，合规不再只是“最后拦一下”，而是从一开始就影响 Agent 的行为模式。

比如，当 Agent 处理一次跨境业务故障时，它不应该先拉取全量日志再说，而应该知道哪些字段涉及个人信息、哪些日志不能离开区域、哪些诊断动作只能在本地执行。再比如，当 Agent 准备回滚某个金融核心系统时，它不应该只看技术可行性，还要理解这类动作是否需要双人审批、是否处于交易高峰、是否触发监管留痕要求。

这意味着，未来 AIOps 的知识库不应只是故障案例库和技术文档库，还应该包括：

*   权限模型；
    
*   变更策略；
    
*   数据分级；
    
*   业务重要性；
    
*   合规条款；
    
*   风险矩阵；
    
*   人员职责；
    
*   审批条件；
    
*   停止准则。
    

这些知识会塑造 Agent 的“性格”。

一个面向开发测试环境的 Agent，可以更激进，鼓励探索和试错；一个面向生产核心链路的 Agent，则必须保守、审慎、可解释，宁可多问一次人，也不能多动一次手。

所以，AI Native AIOps 不是让大模型替代治理，而是让治理进入大模型的决策过程。

## 五、AIOps 团队会分化：上浮做“龙虾”和“爱马仕”，下沉做“感官”和“手脚”

当 Agent 成为新的运维编排中心，AIOps 团队的分工也会发生变化。

我倾向于说，未来 AIOps 团队会沿着两个方向分化：一部分人上浮，一部分人下沉。

所谓“上浮”，是去编写更像“龙虾、爱马仕”这样的 Agent：外形漂亮、交互丝滑、能理解业务语言、能处理复杂上下文、能代表某类角色完成高阶任务。它们可能是面向 SRE 的故障处置 Agent，面向研发的发布风险 Agent，面向管理者的稳定性分析 Agent，面向合规团队的变更审计 Agent。

这些 Agent 的竞争力在于认知和协作：能不能理解组织语境，能不能把模糊问题拆清楚，能不能把技术事实翻译成业务影响，能不能在多人、多系统、多约束之间推进任务。

所谓“下沉”，是去给这些 Agent 提供可靠的感官和手脚。

感官，是观测能力：指标、日志、链路、事件、拓扑、CMDB、变更记录、成本数据、业务指标、用户体验、容量水位、依赖关系。没有感官，Agent 就是盲人摸象。

手脚，是干预能力：扩缩容、切流、限流、熔断、降级、回滚、隔离、重启、配置修正、工单创建、通知升级、权限申请、演练执行。没有手脚，Agent 只能做分析报告。

但更关键的是，这些感官和手脚必须可信。观测数据要有质量，拓扑关系要足够新，自动化动作要可验证，权限边界要可执行，回滚路径要真实存在。

否则，上层 Agent 再华丽，也只是一个会说话的幻觉放大器。

图 3：AIOps 团队的新分工

![](https://cdn.hashnode.com/uploads/covers/680de39180c68f1c7a6ae2f1/9db08d1a-2c92-4102-8db0-e74d8c21c326.png align="center")

## 六、SOP 会涌现，也可能消失

从前，我们根据 SOP 编写固定流程，串联自动化工具对系统进行干预。

现在，我们应该反过来思考：先把各种基础自动化做好，再让大模型决定在什么场景下使用什么自动化过程。这个过程可以是柔性、可变、可演进的，但它执行的具体动作必须是安全、坚固、可验证、可回退的。

这会带来一个很有意思的变化：SOP 可能不再只是由专家在事后总结出来，而是在 Agent 的反复处置中逐渐涌现出来。

比如 Agent 在处理多次类似告警后，发现某种指标组合、某类变更记录、某个依赖超时模式，经常共同指向同一种风险。它可能会形成一个新的处置模式：先确认某依赖健康，再比对最近变更，再执行局部切流，再观察错误率是否收敛。这个模式经过人工确认、风险评估和演练验证后，就可以固化成新的 SOP 或策略模板。

也就是说，过去是：

**专家经验 → SOP → 自动化执行**

**↓**

**受控自动化 → Agent 探索 → 经验沉淀 → SOP 涌现**

再进一步，SOP 甚至可能从“固定文档”变成“运行时策略”。它不再是一页写满步骤的文档，而是一组可被 Agent 读取、解释和执行的约束：目标是什么，证据标准是什么，允许动作是什么，禁止动作是什么，升级条件是什么，停止条件是什么。

到那时，我们也许不会再问“有没有 SOP”，而是问：

*   这个场景有没有足够可靠的观测？
    
*   有没有经过验证的自动化动作？
    
*   有没有明确的风险边界？
    
*   有没有可执行的回滚路径？
    
*   有没有足够的审计证据？
    
*   Agent 是否知道什么时候必须停下来？
    

如果这些问题有答案，SOP 是文档、流程、策略，还是 Agent 的运行时记忆，反而没那么重要。

## 七、AI Ready 比 AI Native 更重要

很多团队在谈 AI Native AIOps 时，容易先想模型、Agent、Prompt、RAG、工具调用、多智能体协作。这些当然重要，但我认为更值得先问的是：我们的运维体系 AI Ready 吗？

所谓 AI Ready，不是买了大模型接口，也不是把知识库接进向量数据库，而是生产环境是否具备让 Agent 安全行动的条件。

可以用几个问题自检：

1.  资源是否有统一身份和拓扑关系？
    
2.  观测数据是否可信、完整、及时？
    
3.  变更记录是否能和故障上下文关联？
    
4.  自动化动作是否有清晰输入、输出和错误语义？
    
5.  高危动作是否有审批、限额和隔离机制？
    
6.  每个动作是否可审计、可追溯、可解释？
    
7.  关键动作是否具备回滚、补偿或安全停止能力？
    
8.  Agent 是否只能通过受控工具触达生产，而不是直接拿到裸权限？
    
9.  合规、安全、法务、业务连续性的要求，是否能被机器读取并执行？
    
10.  人在什么条件下必须介入，是否被明确编码？
     

这些问题没有准备好，Agent 越强，风险越大。

没有坚实的基础设施和自动化底座，谁敢让 Agent 在生产环境下“自行演进”？

反过来，如果底座足够坚固，Agent 的探索就不再是不可控的冒险，而是受约束的试探。它可以在边界内尝试新的观测路径、新的工具组合、新的恢复策略；它可以把成功经验沉淀下来，把失败路径标记出来，把高风险动作升级给人，把低风险动作逐步自动化。

这时，AIOps 才真正从“智能分析”进入“智能行动”。

## 八、结语：真正的 AIOps，不是更会说，而是更敢做，也更知道不能做什么

过去几年，大模型让很多系统突然“会说话”了。它能解释告警，能总结日志，能写排障建议，能生成 Runbook，能在聊天窗口里给人一种非常强的智能感。

但运维不是客服，生产环境也不是问答游戏。

AIOps 的关键，不是让系统说得更像专家，而是让它在必要时能做出正确、受控、可回退的行动。更重要的是，它要知道什么不能做，什么时候该停，什么时候必须叫人。

因此，我并不认为 AI Native AIOps 的未来是“Agent 取代一切”。恰恰相反，它会重新强调那些看起来不够性感、却决定生产安全的基础能力：资源模型、观测质量、自动化封装、权限治理、审计留痕、回滚机制、风险分级、策略执行。

**Agent 是绵，自动化底座是针。**

没有绵，AIOps 只是僵硬的流程自动化；没有针，AIOps 只是危险的语言游戏。

真正的 AIOps，应该让 Agent 拥有足够的柔性去理解复杂世界，也拥有足够坚硬的边界去尊重生产环境。它不是把 SOP 简单搬进大模型，也不是把 ChatOps 换成自然语言入口，而是在可治理、可验证、可回退的工程底座上，让智能体不断试探、学习、组合，并最终涌现出新的运维秩序。

这也许就是“绵里藏针”之于 AIOps 的意义：**外面是柔性的智能，里面是坚硬的工程。外面看起来会变通，里面必须经得起追责。**