大多数关于大模型运维的文章，还停留在“看日志、查文档、问知识库”这一层，很少真正把可视化信息也纳入到 Agent 的决策链路里，比如：

• Grafana / Prometheus 的时序图截图；
• 服务拓扑图（如 SkyWalking / Jaeger UI）；
• 抓包分析图（TCP 流、时延分布）；
• 容器编排面板的截图（Pod 状态、资源使用情况）。

但是在真实排障中，人类工程师非常依赖这种“看图”的能力：

一眼扫过去，看哪个服务红了、哪条链路变粗了、哪段时间响应飙升了，
再结合日志和配置，做出判断。

现在多模态大模型已经能同时理解文本 + 图片，这就给了我们一个很有意思的方向：

把「图表截图 + 日志片段 + 拓扑结构」统一丢给一个多模态 Agent，
让它帮你做“看图排障”，甚至生成下一步排查建议。

这篇文章就从工程实现的角度，讲清楚如何落地这样一个多模态运维 Agent，你可以当作你之前“可观测 / Agent / 自愈”系列的新版分支。

---

一、要解决的问题：单靠日志很难“秒看全局”

传统只靠文本日志 + 指标的排障方式，会有几个痛点：

1. 全局形态难以把握

   • 单纯看数字（CPU、QPS、错误率）难以直观看出拓扑层面的问题；
   • 谁调用谁、哪条链路变慢了，需要在多个页面来回切。

2. 时间维度的对齐成本高

   • Grafana 图表、拓扑视图、抓包时间轴，往往是分开的；
   • 人需要自己对齐时间范围、挑截图、做 mental model。

3. 跨团队沟通困难

   • “你看这个图，这一块突然凸起来了”的口头描述难以复用；
   • 排障经验很难沉淀为结构化知识。

但多模态 LLM 正好擅长：

• 看图提取关键信息（哪个时间段异常、哪个节点变红、哪个 Pod OOM）；
• 把看图结果 + 文本日志，综合成一个结构化的诊断报告；
• 用自然语言生成下一步排查命令或脚本。

所以，思路很自然：

做一个「多模态运维 Agent」，
输入：图表截图 + 拓扑截图 + 日志片段 + 基本上下文
输出：异常总结 + 可疑根因 + 推荐排查 / 修复步骤

---

二、系统设计：一个多模态运维 Agent 的骨架

2.1 整体架构

可以沿用你之前的 Agent 思维，但加上“图像输入”这条支线：

                 ┌─────────────────────┐
      Grafana    │                     │
      拓扑图      │  Screenshot Collector ──┐
      抓包界面    │                     │   │
                 └─────────────────────┘   │
                                           ▼
                                    ┌─────────────┐
日志服务 / APM / 指标 API ───────► │  Context Builder │
                                    └─────────────┘
                                           ▼
                 ┌──────────────────────────────────────────┐
                 │         Multi-Modal Ops Agent            │
                 │  - 接受图片 + 文本                       │
                 │  - 输出诊断报告 + 下一步建议             │
                 └──────────────────────────────────────────┘
                                           ▼
                                前端运维面板 / Chat UI

核心环节只有三块：

1. Screenshot Collector：
   自动从各个可观测系统拉取当前视图的截图（或导出 SVG/PNG）；
2. Context Builder：
   把同一时间窗口的日志片段、指标摘要、告警信息整理成文本；
3. Multi-Modal Ops Agent：
   多模态大模型 + 一点流程控制，生成诊断结果。

2.2 输入输出约定

统一定义 Agent 的 I/O 接口：

class MultiModalOpsAgent:
    def handle(self, images: list, text_context: str, meta: dict) -> dict:
        """
        :param images: [img_grafana, img_topology, img_packet]
        :param text_context: 日志片段 + 告警详情 + 已知操作（最近发布等）
        :param meta: {"service": "...", "env": "prod", "time_range": "..."}
        :return: {
          "summary": "整体问题总结",
          "suspected_root_causes": [...],
          "suggested_actions": [...],
          "risk_level": "low|medium|high"
        }
        """

这样无论后面你接什么前端（Web 面板、飞书机器人、CLI 工具），都可以统一调用。

---

三、数据采集层：如何拿到“给 Agent 看”的图片

3.1 从 Grafana / Prometheus 导出图表截图

Grafana 提供了直接导出 PNG 的 API，你可以通过 HTTP 调用拿到：

GET /render/d-solo/{dashboard_uid}/{panel_id}?from=...&to=...&width=1000&height=500

在你的后端里简单封装一下（Python 伪代码）：

import requests

def fetch_grafana_panel_image(panel_url: str, api_key: str) -> bytes:
    headers = {"Authorization": f"Bearer {api_key}"}
    resp = requests.get(panel_url, headers=headers)
    resp.raise_for_status()
    return resp.content  # PNG bytes

3.2 服务拓扑截图

对 SkyWalking / Jaeger / ServiceMap 这种 UI，一般有：

• 直接导出 SVG / PNG 的接口；
• 或前端可以自带“截图下载”按钮（你可以让前端自动点击/调用）。

你只需要把“当前服务拓扑”的静态图拿下来，然后一起传给 Agent。

3.3 抓包 / 网络时延图

对于 eBPF/抓包平台（如 Pixie、Cilium Hubble 等）：

• 可以导出时延分布图、TCP 流水线图的截图；
• 或者直接导出统计结果（比如 P95 RTT 曲线）。

为了多模态 Agent 效果，推荐直接用图表截图，而不是纯文本。

---

四、上下文构造：把“图 + 文”打包成一个世界状态

我们可以把当前的“运维世界状态”整理成一个 JSON 文本，作为 text_context：

{
  "alert": {
    "service": "order-service",
    "env": "prod",
    "alert_name": "p99_latency_high",
    "trigger_time": "2026-02-10T03:10:00Z",
    "threshold": "p99 > 800ms"
  },
  "metrics_summary": {
    "cpu_usage": "80% → 95%",
    "qps": "稳中略升",
    "error_rate": "0.5% → 2.1%",
    "latency_p99": "200ms → 1.2s"
  },
  "recent_changes": [
    "2026-02-10 03:05 发布了 order-service v1.3.2",
    "2026-02-10 03:06 数据库连接池参数由 100 改为 200"
  ],
  "log_samples": [
    "2026-02-10 03:08 timeout calling payment-service /pay",
    "2026-02-10 03:08 slow query SELECT ... ON orders"
  ]
}

再配上一点提示文本喂给 LLM，例如：

def build_text_context(state_json: str) -> str:
    return f"""
你是一个资深运维工程师，下面是当前系统的文本上下文信息（JSON）：

{state_json}

请结合我提供的图表截图，分析问题。
"""

---

五、多模态 Agent 的 Prompt 设计思路

多模态大模型一般支持“多图 + 文本”输入，你可以组织成这种格式：

（图1：最近1小时服务指标时序图）
（图2：当前服务拓扑图）
（图3：网络时延 / 抓包分析图）

【文本上下文】
{build_text_context(...)}

【你的任务】

1. 先分别描述每张图中和"异常"相关的关键信息；
2. 再结合文本上下文，回答下面几个问题：
   - 哪个时间段最明显异常？
   - 异常首先出现在哪个服务 / 哪条链路上？
   - 可能的根因有哪些？按可能性排序。
3. 最后给出 3~5 条具体的下一步排查 / 缓解建议。

输出严格使用 JSON，格式如下：
{
  "summary": "...",
  "suspected_root_causes": [
    {"cause": "...", "evidence": "...", "confidence": 0.8}
  ],
  "suggested_actions": [
    {"action": "...", "reason": "...", "priority": 1}
  ],
  "risk_level": "low|medium|high"
}

这样可以保证输出可被前端 / 工作流消费，而不仅仅是长篇自然语言。

---

六、前端体验：让运维同事“点图问因”

你可以在现有的监控面板上加一个按钮：

「让多模态 Agent 分析这段时间」

点击后，前端做的事是：

1. 根据当前时间范围 / 筛选条件，调用后端 API：

   • 拉取对应的 Grafana 图表 PNG；
   • 拉取对应服务拓扑图 PNG；
   • 拉取对应抓包视图 PNG（可选）；
   • 拉取该时间窗口的日志 / 告警概要。

2. 调用后端的 /ops-agent/diagnose 接口：

POST /ops-agent/diagnose
{
  "images": [
    "data:image/png;base64,...",
    "data:image/png;base64,..."
  ],
  "text_context": "...上述 JSON 文本...",
  "meta": {"service": "order-service", "env": "prod"}
}

1. 在页面右侧展示 Agent 的诊断结果，包括：

• 问题总结（summary）
• 可疑根因列表（带证据）
• 建议的排查 / 修复步骤（可点击执行或生成命令）

---

七、和你原有“自愈 / 质量闭环”体系怎么衔接？

这个多模态 Ops Agent，本质上是你之前那套体系的“图像 + 决策增强版”，可以这样接：

1. 作为新的 Agent 类型接入调度器

   • 之前有 RetrieverAgent / ExplainerAgent / EvaluatorAgent；
   • 现在再加一个 OpsVisualAgent，专门处理“图 + 文”的排障请求。

2. 把诊断结果存入质量闭环

   • 每次诊断结果，落库为一个 OpsDiagnosisEvent：
     • images_hash / text_context / diagnosis_json / 人工确认结果；
   • 未来可以再基于这些事件做SFT / DPO，持续提升排障能力。

3. 和自愈工作流联动

   • 当 risk_level = "high" 且某些 suggested_actions 置信度够高时：
     • 自动触发你已有的自愈工作流（如扩容、降级、流量切换）；
   • 或者只在工单系统里预填“建议动作”，让工程师一键执行。

---

八、如何低成本先跑一个 Demo？

建议循序渐进，不要一上来就接全量生产告警：

1. 选一个服务 + 一个告警类型试点

   • 比如 order-service 的 p99_latency_high 告警；
   • 固定几个 Grafana Panel / 拓扑视图，用静态链接先跑通。

2. 先从“辅助分析”做起，不直接操作生产

   • 只展示诊断建议，不自动执行任何动作；
   • 让值班工程师对比自己的判断和 Agent 判断的一致性。

3. 积累几十个案例后，再考虑接入自愈

   • 看看 Agent 诊断的“误判率 / 漏判率”；
   • 总结它最擅长 / 最容易犯错的场景，再做针对性优化。