每次处理工单都要把用户发来的截图一个字一个字抄到文档里。这种苦活现在可以让 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 类型的大 keyuser: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 快速入门 客服工单里的截图，终于不用人工抄写了
每次处理工单都要把用户发来的截图一个字一个字抄到文档里。这种苦活现在可以让 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 类型的大 keyuser: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 快速入门