告警响起后，值班工程师通常要做几件事：翻日志、查 Prometheus 指标、看 CMDB 上下游、核对最近变更，再决定是否重启、回滚或降级。运维 Agent 如果只把这些材料总结成几句话，帮助有限。它还得能调用工具、遵守权限、验证结果，并在证据不足时停手。
AIOps 已经有明确的技术脉络。AWS 官方博客回顾，Gartner 在 2016 年提出 AIOps 概念，目标是持续采集系统运行数据，用机器学习识别异常、定位故障并给出修复建议。中国信通院《AI+运维：构建智能化运维新范式》则将运维技术演进概括为传统人工、自动化、小模型和大模型阶段，对应 AIOps 从 1.0 向 2.0 的变化。
大模型增加了自然语言理解和工具编排能力，但监控、CMDB、脚本库与审批系统仍是底座。缺少这些基础设施，Agent 最多是一个会解释告警的聊天窗口。
先把现有工具串起来
生产系统没必要为 Agent 重建一套采集链路。Fluentd + Kafka 可以继续接收和传输日志，Prometheus 提供指标，CMDB 保存服务关系，发布系统补充最近的变更记录。Agent 位于这些系统之上，负责理解问题、选择查询工具和整理证据。
一条可控的处理链路可以这样拆：
- 数据接入：汇集日志、指标、告警、拓扑、工单和变更记录，保留原始时间戳与来源。
- 分析与诊断：底层可以采用 Qwen2.5-7B 一类模型，但模型只能调用封装后的只读工具，例如查询 Prometheus、检查 CMDB、执行
ping、top或iostat。 - 动作执行：重启容器、摘除流量、回滚版本和服务降级仍由 K8s API、自动化脚本或编排平台完成。Agent 负责选用预案，不直接获得无限制的 shell 权限。
- 结果复核：动作结束后重新查询原先异常的指标。指标没有恢复，就回滚或转交值班工程师。
华为 NAIE 相关材料提到，可选择不同的 AIOps 原子能力，通过可视化方式串接流程，也可以使用接口调用；配置范围包括数据接入、模型参数、事件通知和 Dashboard。这种做法更接近生产工程：模型负责调度，已有系统负责执行。
日志能归类，根因要靠旁证
大模型处理非结构化日志确实方便。看到 OOM、connection refused 或 task timeout after 30s，Agent 可以统一术语、关联服务，并拉取相应指标。问题在于，日志含义明确，不代表根因也明确。
例如，task timeout after 30s 只能证明任务超时。上游响应慢、本机 I/O 堵塞、线程池耗尽或最近一次发布，都可能产生相似结果。至于 unexpected error in worker thread 这类模糊文本，仅凭一句日志更难下结论。
因此，诊断结果需要附带旁证：同一时间窗内有哪些指标变化，CMDB 上哪些依赖同时告警，近期是否发生发布或配置调整，历史工单中有没有相似记录。找不到另一类证据时，Agent 应当输出候选原因和待检查项，不能直接触发修复。
这也能压住模型幻觉。运维场景不怕 Agent 说“暂时无法判断”，更怕它用流畅语言包装一个错误根因。
自愈先过权限墙
运维 Agent 需要接触 K8s API、CDN、数据库连接池和脚本平台，这些都是高权限入口。接入方式应按自动化程序管理，而不是给模型绑定一个管理员账号。
故障可以按影响范围划分为三档：
- L1，单实例或低影响故障：允许 Agent 按既有预案处理，执行后通知值班人员。
- L2，多实例或部分用户受影响：Agent 收集证据并提出动作，得到人工确认后再执行。审批超时不能被视为默认授权。
- L3，全站故障或存在数据风险：Agent 保持只读，只负责汇总日志、拓扑、指标和变更信息。
Agent 与生产系统之间还需要专用 API 网关。网关检查目标 IP、操作时间窗、调用身份、指令参数和审批状态；修改副本数等高影响动作应进入人工审批。读权限与写权限分开，所有调用留存审计记录，值班工程师可以随时切回人工模式。
动作白名单也不能只写成“允许执行重启”。更稳妥的方式是把服务范围、参数和回滚步骤一并固化为预案，Agent 只能选择预案，不能临场生成高危命令。
命令执行完，还要看指标
容器返回“重启成功”，只能证明命令运行完毕，不能证明故障已经恢复。自愈流程需要保留一条清楚的验证链：
告警 → 证据 → 故障假设 → 修复动作 → 指标复核 → 回滚或升级
执行前，Agent 要写明预期变化。执行后，再检查对应的延迟、错误率、I/O 等待或任务积压。结果不符合预期，就标记修复失败，而不是生成一句“服务已恢复”。
硬件问题尤其容易造成误判。若底层 SSD 持续出现 I/O 抖动，重启容器可能只带来短暂缓解。Agent 应保留现场，把结果标记为临时处置，并将设备健康信息交给工程师。内核 panic、硬件慢性损坏等长尾问题也不适合交给通用模型独立处理。
大模型放在它擅长的位置
联想 xCloud AIOps 混合云实践列出的能力包括 Ops DataLake、Insight、CMDB、DCM、智能拓扑、自动数据总结、智能查询助手和问题解决推荐，并明确整合判别式 AI 与生成式 AI。生成式模型只是其中一层，数据、拓扑、设备管理和自动化执行缺一不可。
| 运维任务 | 更适合的实现方式 |
|---|---|
| 日志摘要、知识检索、工单生成 | 生成式模型 |
| 固定模式识别、异常检测 | 规则或判别式模型 |
| 权限检查、变更审批 | API 网关与策略引擎 |
| 重启、回滚、降级 | 自动化脚本与编排平台 |
| 恢复确认 | 监控指标与断言规则 |
把所有判断都交给大模型，会让原本确定的流程变得不可预测。更合适的分工是：模型理解上下文并挑选工具，规则系统守住权限，自动化平台执行动作，监控系统负责验收。
从只读试点开始
首轮试点可以只给 Agent 读权限，让它完成日志汇总、指标查询、拓扑关联和故障摘要。等这些结果稳定后，再开放已有成熟预案、影响范围可控且能够回滚的动作，例如单实例容器重启。
评估时不要只看 MTTR。误报是否增加、人工接管是否顺畅、失败动作能否回滚、审计记录是否完整，同样会决定系统能不能进入生产。模型采用 Qwen2.5-7B 还是其他方案，也应放到团队自己的历史日志和工单上测试，模型名称无法替代场景评估。
失败案例需要进入工单和复盘流程，由 SRE 确认问题出在日志理解、工具选择、权限策略还是执行预案。随后再更新知识库、提示词、脚本或模型。Agent 不会因为一次误操作就自动学会正确处理，人工校正仍然少不了。
标准可以参考，授权仍由团队负责
中国信通院的材料提到，CAICT 联合多行业 100+ 企业推动运维智能化；在其整体标准化工作中，已牵头制定国家标准 362 项、行业标准 3708 项、团体标准 751 项。这些工作能提供术语、能力分级和评估框架，但无法替企业决定哪项生产权限应该交给 Agent。
运维 Agent 更适合做一个受控的值班助手：能读日志、查拓扑、调脚本、写复盘，也知道什么时候停手。故障自愈能否投入生产，最终看三件事——权限有没有边界，动作能不能回滚，修复结果是否经过指标验证。
