绵里藏针才是 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 在治理边界内编排自动化。
二、从“流程即代码”到“决策即流程”
过去十几年，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 可以柔性编排，但动作必须刚性受控
四、合规不再只是审批流，而会成为 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 团队的新分工
六、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 安全行动的条件。
可以用几个问题自检：
资源是否有统一身份和拓扑关系？
观测数据是否可信、完整、及时？
变更记录是否能和故障上下文关联？
自动化动作是否有清晰输入、输出和错误语义？
高危动作是否有审批、限额和隔离机制？
每个动作是否可审计、可追溯、可解释？
关键动作是否具备回滚、补偿或安全停止能力？
Agent 是否只能通过受控工具触达生产，而不是直接拿到裸权限？
合规、安全、法务、业务连续性的要求，是否能被机器读取并执行？
人在什么条件下必须介入，是否被明确编码？
这些问题没有准备好，Agent 越强，风险越大。
没有坚实的基础设施和自动化底座，谁敢让 Agent 在生产环境下“自行演进”？
反过来，如果底座足够坚固，Agent 的探索就不再是不可控的冒险，而是受约束的试探。它可以在边界内尝试新的观测路径、新的工具组合、新的恢复策略；它可以把成功经验沉淀下来，把失败路径标记出来，把高风险动作升级给人，把低风险动作逐步自动化。
这时，AIOps 才真正从“智能分析”进入“智能行动”。
八、结语：真正的 AIOps，不是更会说，而是更敢做，也更知道不能做什么
过去几年，大模型让很多系统突然“会说话”了。它能解释告警，能总结日志，能写排障建议，能生成 Runbook，能在聊天窗口里给人一种非常强的智能感。
但运维不是客服，生产环境也不是问答游戏。
AIOps 的关键，不是让系统说得更像专家，而是让它在必要时能做出正确、受控、可回退的行动。更重要的是，它要知道什么不能做，什么时候该停，什么时候必须叫人。
因此，我并不认为 AI Native AIOps 的未来是“Agent 取代一切”。恰恰相反，它会重新强调那些看起来不够性感、却决定生产安全的基础能力：资源模型、观测质量、自动化封装、权限治理、审计留痕、回滚机制、风险分级、策略执行。
Agent 是绵，自动化底座是针。
没有绵，AIOps 只是僵硬的流程自动化；没有针，AIOps 只是危险的语言游戏。
真正的 AIOps，应该让 Agent 拥有足够的柔性去理解复杂世界，也拥有足够坚硬的边界去尊重生产环境。它不是把 SOP 简单搬进大模型，也不是把 ChatOps 换成自然语言入口，而是在可治理、可验证、可回退的工程底座上，让智能体不断试探、学习、组合，并最终涌现出新的运维秩序。
这也许就是“绵里藏针”之于 AIOps 的意义：外面是柔性的智能，里面是坚硬的工程。外面看起来会变通，里面必须经得起追责。