多模态看图不是噱头，是排障提速的实招
—— 系列第 2 篇 ——
2026 年 10 月
目 录
一、现场：白天，网站 502 了
二、多模态：把截图丢给 AI
三、从截图到根因：AI 的只读排查链
四、修复与加固：一次确认的重启
五、复盘：为什么看图不是噱头
一、现场：白天，网站 502 了
上一篇是凌晨的值守告警，这一篇换成白天最常见的突发：下午两点，运营同事在群里喊「网站打不开了」。web01 是一台 Rocky Linux 9 虚拟机，Nginx 反代后面的 PHP 应用，平时稳得没存在感。
这种场景有个特点：你不是从告警开始的，而是从一句模糊的转述开始的——「打不开」「一直转圈」「报了个错」。传统做法下，你要么自己登服务器漫无目的翻日志，要么让同事把报错截图发过来，再对着截图猜是哪一层的毛病：Nginx？PHP？数据库？防火墙？
502 这个词对运维人不陌生，但对报障的人是黑话。这一篇要展示的核心能力是：把报障同事的截图原样丢给 AI，让它自己「看懂」这是哪一层的错误，然后带着方向去排查——而不是让你当人肉翻译，把截图转述成技术语言再喂给工具。
二、多模态：把截图丢给 AI
AI 运维助手支持在对话里直接传图。Web GUI 里把图片拖进输入框（或点上传按钮），CLI 终端里用 /img 命令指定本地图片路径，两者效果一样：图片会被转成模型可读的格式，和你的文字一起发给大模型。单张图片上限 5MB，一次可以带多张。
需要说明的是，看图走的是你所配置的大模型的多模态能力——接 DeepSeek 这类纯文本模型时图片不参与理解，换成通义千问、GLM、豆包等多模态模型（或本地 Ollama 里的视觉模型）即可，软件本身对图片不做任何加工，原图不出你的电脑（本地模型）或只进你选定的模型厂商（云端模型）。
回到现场。我让同事把浏览器报错页截了图，拖进对话框，附一句话：
我：[图片] 网站打不开了，同事说一直转圈然后跳这个页面
AI 看完图，第一句话就把错误层定位了：
AI：截图显示的是 Nginx 502 Bad Gateway。这个错误说明 Nginx 本身
在运行，但它后面的应用服务（PHP-FPM）没有响应——请求到了
Nginx，后端没人接。我先确认后端进程状态。
注意这里发生了什么：报障同事没有说一个技术词，我没有做任何转述，AI 从截图里读出了错误类型，并且直接给出了排障方向。传统流程里「发截图 → 人看图 → 人翻译成术语 → 人登服务器」的四步，被压缩成「发截图 → AI 登服务器」。
三、从截图到根因：AI 的只读排查链
接下来的排查是 AI 自主完成的，每一步都是只读命令，无需确认，一气呵成：
AI：→ run_command(systemctl status php-fpm)
php-fpm.service - The PHP FastCGI Process Manager
Active: inactive (dead) since 13:47:22
AI：后端进程确实不在了。看它是怎么退出的 →
run_command(journalctl -u php-fpm --since "2 hours ago" | tail -20)
（无正常 stop 记录）
AI：→ run_command(dmesg -T | grep -i -E "out of memory|killed process" | tail -5)
[五 09月27 13:47:21 2026] Out of memory: Killed process 11873
(php-fpm) total-vm:9123456kB
三条命令，结论落地：php-fpm 进程消失，系统日志显示它是被内核的 OOM killer 干掉的——物理内存耗尽，内核挑了占用最大的进程杀掉保命。这不是 php-fpm 自己崩了，是这台小内存虚机扛不住请求高峰。AI 把根因和建议一起给了出来：
AI：根因：内存耗尽，php-fpm 被 OOM killer 杀死（不是配置写错）。
恢复：systemctl restart php-fpm，站点应立即恢复；
预防（三选一或组合）：调低 php-fpm 的 pm.max_children、
增加 swap、给这台虚机加内存。是否现在重启 php-fpm？
四、修复与加固：一次确认的重启
重启服务属于变更操作，按分级管控弹确认框，命令完整可见。点确认后：
AI：→ run_command(systemctl restart php-fpm)（已确认）
AI：验证恢复 → run_command(curl -sI http://127.0.0.1 | head -3)
HTTP/1.1 200 OK
Server: nginx
Content-Type: text/html; charset=UTF-8
从同事报障到 200 OK，全程不到十分钟。期间我做的动作：转发一张截图、看一段分析、点一次确认。预防建议我也让 AI 直接落实了其中两条：把 php-fpm 的 pm.max_children 调低并重启生效（又是熟悉的确认框），以及顺手确认了这台机器的值守状态——web01 早已被 scan_roles 识别为 web 角色主机，PHP-FPM、Nginx 的进程探针都在，下次再被 OOM 杀掉，30 秒内横幅、报警音、邮件会一起来，不用等同事在群里喊。
至于加内存和加 swap，前者要去虚拟化平台动配置，后者是一条命令的事，AI 同样给出了带确认的执行路径。整个事件里，唯一需要「运维经验」的决策只有两个：要不要现在重启，以及预防方案选哪个——而这正是人该干的事。
环节 | 传统做法 | AI 运维助手 |
理解报障 | 看截图、翻译成技术问题 | AI 直接看图定位错误层 |
排查路径 | 凭经验挑命令逐个试 | AI 带着方向连续只读排查，全程可见 |
根因结论 | 翻日志拼线索 | 三条命令给出「OOM 杀进程」的确定结论 |
执行修复 | 人手敲重启命令 | AI 拟命令，人一次确认 |
恢复验证 | 自己刷网页 | AI curl 回验 200 并报告 |
事后加固 | 常常不了了之 | AI 给出并落实预防清单 |
五、复盘：为什么看图不是噱头
很多产品都有「传图」功能，但运维场景里看图的价值经常被低估。运维信息的原始形态恰恰大量是图：监控大盘截图、报错弹窗、管理界面状态页、同事随手拍的大屏。传统自动化工具要求你先把图翻译成文字或结构化数据，而这个翻译过程既费时间又容易失真——报障的人说不清技术细节，看图的人又不在现场。
多模态把这个环节抹掉了。本篇案例里，截图承担的是「零上下文冷启动」：AI 不需要你描述现象，现象本身就在图里。同样的能力换个场景依然成立——监控大盘里 CPU 曲线异常你截给 AI，它结合数值帮你判断；K8s Pod 排查时的 describe 输出太长，截图发过去让它先扫一眼找重点，都是同一个道理。
这一篇的关键词是「白天突发 + 零上下文」：没有值守告警铺路，报障就是一句话加一张图。AI 先用眼睛看懂问题，再用 SSH 读懂机器，最后在变更前停下问你。看图、执行、刹车，三件事连成一条完整的排障流水线。
下一篇回到批量场景：月底三十台服务器要巡检，一次对话能不能巡完？
