基于 Agent Skill 的自动化问题诊断框架

IMG_3493.jpg

最近在小规模实践一个问题:大模型时代,如何做生产环境的自动问题分析诊断。本文是一个阶段性思考,因为裁员的问题, 只能先记录下来。

前提是生产环境的数据收集、分析、整理、告警等基础设施已经比较完善。在此基础上,用 Agent 代理人工分析诊断问题的过程,并持续优化和迭代诊断能力。

终极信念当然是 AI 自动运维、排除 human-in-the-loop。但现阶段这仍是理想,尤其在生产环境:一次误操作的风险,可能比诊断不出来更大。因此,当前更务实的方式是让 Agent 多数部署在本地 corp 环境,而不是直接放进生产环境。

核心设计理念

  1. 大模型具备通用分析诊断能力,尤其对开源产品和通用技术栈。
  2. 公司内部相对静态的信息,通过 RAG 或 skill 获取,并持续添加、迭代更新。
  3. 公司内部相对动态的信息,由 skill 调用公司 API 或 MCP 工具获取,主要对接 metrics、logs、traces、topology、config 等。

基本流程可以概括为:

告警 -> Agent -> Skill/RAG -> API/MCP -> metrics/logs/traces/topology/config

工程上会涉及 Agent 编排、Memory 共享、skill 层次结构与更新、RAG 文档迭代,以及 API/MCP 的权限和认证。

本质:把人的诊断过程迁移给 Agent

使用 Agent + Skill,本质上是把原来人做的事情转成 Agent 要做的事情:

  • 人的判断分析,改成大模型的分析判断;
  • 人的信息收集整理,改成 Agent 的收集整理,并且可以并行、更快;
  • 大模型不知道的内部静态信息,通过 RAG 或 skill 中的信息获取;
  • 大模型不知道的内部动态信息,通过 skill 调用的 API 或 MCP 工具获取。

人做得慢,思维也慢;Agent 可以大规模并行收集、分析、验证,这是核心优势。

主要难点

第一,人喜欢“一图胜千言”,快速浏览一批 dashboard 就能发现可疑异常点。但 Agent 不擅长读 metrics 图表;即使喂原始数据,也需要借助其他工具分析。目前缺少现成的数据 insights 工具,更谈不上并行看多图的效率。

第二,要把原先给人看的成熟 dashboard 转成 Agent 能理解的形式。短文本问题不大,但图表需要很大改动。

第三,授权和认证。过去的登录、认证、授权都以人为基础;Agent 可以继承人的身份,但人的 UI 双因素认证与 API/MCP 认证完全不同。

第四,操作边界。仅在 skill 里约束不够,边界要清晰,并且要从 API 和 MCP 层面做强制鉴权和授权。

事后记录与 Skill 迭代

人通常只记录关键结论,并主动漏掉走弯路的部分;事情解决后,也缺少动力记录过程。Agent 可以把整个过程记录下来,并在后续分析中使用。

事后整理的 trajectory 可能需要当时的实时数据。这些数据要同步保留,供以后重跑、验证 skill 能力。

实施上,需要一个地方保留有用的 skill,并支持持续升级迭代;同时按 skill 的 scope 做分层、分类整理,便于管理和调用。至于 Agent 的并行能力,目前 Claude 和 OpenCode 提供的已在一定程度上够用。

现阶段的核心不是让大模型直接替代人,而是把人的诊断过程拆成可复用的 skill 和可强制授权的工具调用,先做一个可审计、可回退、可迭代的诊断助手。

标签: none

添加新评论