版本发布后错误率飙升，告警响了，指标、日志、链路数据一应俱全——然后呢？SRE 还是要在监控系统、日志平台、CMDB、研发平台之间反复横跳：确认影响面、关联变更、评估 AI 建议靠不靠谱、处置完盯着业务指标确认恢复。数据和 AI 让"发现问题"变容易了，从发现到解决的那一公里，依然靠人。智能体运维（Agentic Ops）要收的就是这段路。
和 AIOps 的本质区别：谁驱动谁
运维演进四阶段，驱动力完全不同：人工运维靠规则阈值，被动响应；AIOps 数据驱动，做异常检测和关联分析，辅助决策；运维助手提问驱动，自然语言查数看告警；智能体运维目标驱动——人只定目标，Agent 自主观察、诊断、处置、验证。
前三阶段的共同点是每一步都要人推：你问它答，你查它给。智能体运维的分工是"人定目标，Agent 跑过程"。比如给系统下这样一个持续目标："核心应用每次发布后自动检查运行状态，发现异常就关联变更调查，跟进处置效果。"之后 Agent 自己观察环境、收集证据、推进诊断，人只在关键决策点出现。
第一步：让 Agent 真懂你的系统
自主工作的前提是理解环境。现实是指标在监控系统、日志在日志平台、资产在 CMDB、发布在研发平台，语义各不统一。一次合格的诊断需要回答：这个报错接口属于哪个服务、跑在哪些实例上、依赖哪个数据库、最近有没有发布。
补齐这件事靠两层能力：统一连接——授权范围内自动发现资源、自然语言描述接入诉求自动完成匹配和校验；统一建模——把可观测数据和资源对象关联成持续维护的运维知识图谱，统一语义加动态拓扑。这张图谱就是 Agent 的工作记忆，所有跨系统调查的地基。
诊断要有证据链，不是概率游戏
有了上下文，从"最近一小时错误率最高的应用"这类问题切入很自然。但真正值钱的是异常发生时的证据链能力：
- 锁定范围：异常对象、影响面、时间窗口；
- 全域取证：指标、日志、链路、变更记录、代码提交；
- 假设驱动验证：提出可能原因，取证，支持或排除，调整方向继续；
- 输出结论：根因、影响路径、传播链路、证据、处置建议。
核心原则只有一条：证据不足就继续调查，不强行给结论。
这里有一个必须写进验收标准的反模式：只信 Agent 自报"已修复"。 模型说修好了不算数，必须回到产生告警的同一套遥测数据里复读验证——错误率回落了吗？慢调用消失了吗？工具返回码 200 和业务恢复是两码事，拿前者代替后者是智能运维落地的头号翻车点。
从诊断到闭环：三个机制
长期任务：目标设定后在后台异步持续运行，观察环境、发现异常、自主生成问题对象——一个 7×24 在线的数字 SRE，不靠人不断提问驱动。配合状态托管和检查点，长任务可断点续跑、可人工挂起。
问题对象全生命周期：现象、证据、根因、责任人、动作、结果聚合在同一个对象里，多轮交接沿同一条线索推进，不散落在聊天记录和工单里。调查轨迹、处置 SOP、验证结果持续回写知识库——下次同类问题收敛更快。
分级执行：低风险查询报告自动放行；改配置、重启、扩缩容必须人工确认；命中禁止规则直接阻断。两条硬约束：执行前策略加权限双校验，人工确认不能突破权限边界；执行后用业务指标验证恢复，不恢复就回退或转人工。
落地路径与边界
不颠覆现有流程是务实的起点：能力服务化，API/SDK、页面嵌入、IM 集成、CLI 插件多入口，在熟悉的工作台里获得能力，而不是强迫迁移新平台。
切入点建议从高频重复的小场景开始——比如单个核心应用的发布后守护，先跑通"统一上下文 → 跨域诊断 → 分级执行"的小闭环，验证价值后再扩目标范围。一上来就全域铺开的失败案例，几乎都死在上下文接入没做完、Agent 无据可查上。
终极目标不是让 AI 替人做决策，而是让数据、判断、行动连成连续的工作过程：Agent 承担持续性工作，人专注关键决策。运维从被动响应走向主动自治，这段路要一段一段验收着走。
评论0