每次处理工单，都要把用户发来的截图一个字一个字抄到文档里。这种苦活，现在可以让 Agent 来干了。
运维人的截图噩梦
做过运维或技术支持的人都熟悉这个场景。
用户提了一个工单，说"页面报错了"，下面附了 5 张截图：浏览器报错页面、应用日志、两张配置管理界面、一张监控面板告警。
你得打开每张截图仔细辨认，把错误信息、日志内容、配置参数手动敲进工单系统的文本字段，从截图里提取错误码、时间戳、服务名填到排查表单。截图模糊或者字太小，还得放大了一行行对。
一个工单 5 张截图，每张平均 3-5 分钟提取文字。一天处理 20 个工单，光抄截图就要花掉 5-8 个小时。
更麻烦的是这些信息没被沉淀下来。今天你处理了一个 Nginx 502 工单，从截图里识别了上游服务的超时配置参数，排查解决了。三个月后同样的问题再出现，那次工单的截图信息只存在你脑子里。你忘了，或者换了个人值班，一切从头来过。
多模态识别的思路
这个问题的本质是：截图里的信息需要被提取出来、结构化、然后存下来。传统做法是 OCR 提取文字，然后人工整理。现在大模型的视觉能力已经强到可以"看懂"截图，不只是做文字识别，还能理解截图的含义。
ContextDB 近期增强了多模态支持，能处理文本之外的信息：图片、表格、PDF。单看是个功能点，放到运维场景里，它能改变信息处理的链路。
截图内容识别。 工单中的截图直接输入系统，自动识别截图中的文字——错误信息、日志内容、配置参数、监控指标数值。不是纯 OCR，它结合了上下文理解。一张 Nginx 错误日志的截图，系统不仅识别出文字，还能判断"这是一个 Nginx 的 upstream timeout 错误"，不是把日志当成一堆无意义文本。
自动提炼与结构化。 识别出来的原始信息会被自动提炼，提取关键要素：
工单 #20240315-042 ├── 错误类型：Nginx 502 Bad Gateway ├── 上游服务：payment-service:8080 ├── 超时配置：proxy_read_timeout 30s ├── 错误时间：2024-03-15 14:32:07 ├── 监控指标：payment-service P99 延迟 45s（超过阈值） └── 根因推断：上游服务延迟超过 Nginx 超时配置
这条结构化记录直接进入知识库，变成可检索、可引用的知识资产。
不过有一点要说：目前对于手写注释的截图、复杂的拓扑图或者多层嵌套的表格截图，识别准确率会明显下降。如果你的工单里经常有这类图片，还是建议人工复核一遍。多张截图有重叠信息时，去重效果也不够理想，偶尔会出现重复入库的情况。
知识关联与沉淀。 新入库的工单知识会自动与已有知识建立关联。之前有过类似的 Nginx 502 工单，系统把它们关联到同一个记忆实体下。下次再出现类似问题，Agent 可以直接检索到历史处理方案和关键参数。
工作流对比
纯人工流程长这样：
用户提交工单（含截图） ↓ 运维人员打开工单，逐张查看截图 ↓ 手动识别截图内容，提取关键信息 ↓ 将信息填入排查系统 ↓ 根据经验排查问题 ↓ 解决问题，关闭工单 ↓ 截图信息随工单归档，逐渐被遗忘
接了 ContextDB 的 Agent 流程：
用户提交工单（含截图） ↓ Agent 自动接收工单，截图送入多模态处理 ↓ 自动识别截图内容，提炼关键信息，结构化入库 ↓ Agent 基于结构化信息 + 历史知识，自动进行初步排查 ↓ Agent 给出排查建议和可能的解决方案 ↓ 运维人员审核确认，执行修复 ↓ 本次工单的处理过程（含截图识别结果）沉淀为知识 ↓ 下次类似问题，Agent 直接调取历史方案
变化体现在两个地方。效率上，截图识别和信息提取从人工的 15-25 分钟变成自动的几秒钟，运维人员的时间从抄截图转移到了做决策。知识沉淀上，每次工单处理的信息都被结构化保存并关联到知识图谱，团队的故障处理经验不再只存在于个人记忆里。
当然，这个流程的前提是你的 Agent 框架本身能接收图片消息并转发。如果 Agent 端不支持图片类型，这些能力就用不上。
一个具体的例子
假设你的团队处理过一个 Redis 集群故障的工单。用户附了 3 张截图：Redis 监控面板显示某节点内存使用率突增到 95%、应用日志里大量 MISCONF Redis is configured to save RDB snapshots 错误、运维终端上 CONFIG SET stop-writes-on-bgsave-error no 的临时修复命令。
传统方式下，运维工程师手动抄写这些信息，排查后解决。三个月后类似问题再出现，新值班的同事不知道上次怎么处理的，从头排查一遍。
接了这套系统之后，截图自动识别出内存使用率 95%、MISCONF 错误、bgsave-error 配置，自动结构化成：故障类型（Redis 内存告警 + RDB 持久化失败）、临时方案（关闭写保护）、根因（大 key 导致内存突增 + fork 失败）。然后与已有的"Redis 运维知识"实体关联。
三个月后新同事遇到类似问题，Agent 直接给出：
"上次出现过类似问题（工单 #20240120-018）。根因是 hash 类型的大 key（user:session:*）导致内存突增，RDB 持久化 fork 失败。临时方案是
CONFIG SET stop-writes-on-bgsave-error no，最终方案是拆分大 key 并调整repl-diskless-sync参数。以下是当时的完整处理记录。"
这就是知识沉淀的实际价值。团队的经验属于团队，不属于某个人的大脑。
接入和替代方案
已经在用 ContextDB 的团队，多模态能力是平台级的能力增强，不需要额外接入步骤。你只需要确保 Agent 端能接收和转发图片类型的消息，Workspace 中开启了多模态解析，图片以支持的格式（PNG、JPG、WebP）传入。
还没接入的话，一条命令就可以开始：
curl -fsSL 'https://context-database-client.oss-cn-hangzhou.aliyuncs.com/install.sh' | bash -s -- --agent <your-agent> --api-key <your-api-key>
不过如果你的团队已经有自建的工单知识库，也不一定要换。截图识别这件事，GPT-4V 或者 Claude 的 Vision API 也能做，你可以自己搭一条 OCR + LLM 的管道来实现类似的效果。ContextDB 的价值主要在省事——把识别、结构化、关联、检索串在了一起。如果你愿意自己维护管道，开源的 OCR（比如 PaddleOCR）加上 LLM 也能走通。
不只是截图
工单截图之外，这个能力在其他场景也用得上。架构图里提取服务拓扑和依赖关系。Excel 截图或报表截图中提取结构化数据。PDF 格式的运维手册、部署文档中提取关键配置和步骤。管理后台截图里提取配置参数。
逻辑是一样的：需要人"看"和"理解"的信息，都可以被自动化处理并沉淀为知识。
少做信息搬运
运维工作中有大量"人肉中转"的环节。截图转文字、口头沟通转文档、会议讨论转操作记录。这些工作不产生新价值，但消耗大量时间和精力。
多模态识别想解决的不是某个具体技术问题，而是这类信息搬运工作本身——识别、提取、结构化、关联、检索让机器做，判断、决策、执行人来做。
下次再看到工单里那一堆截图，至少抄写这一步可以省了。
参考链接：ContextDB 快速入门
