先说问题

我日常主力是 Claude Code，脑子够用。但它有个硬伤——看不了图。

报错截图、架构图、扫描件、别人发来的设计稿，往对话框一贴，它回你一句：

[Unsupported Image]

不是它不想看，是这条链路根本没把图喂给它。我先后试过 DeepSeek V4、GLM-5.1，配置里都标着"支持图片"，实测一律 [Unsupported Image]。配置标记 ≠ 真能看，这点后面还要再坑我一次。

正好，我用的这个 IDE 里还跑着另一个 AI——CodeBuddy，它有多模态模型（走的是 deepseek-v4-pro，确实能认图）。

一个有脑没眼，一个有眼。那就让它俩组队：我贴图，主模型转交给"眼睛"看，看完把结果传回来，主模型接着推理。 我全程只做一件事——粘贴，发送。

整条链路长这样

你粘贴截图+发送
   │
   ├─ 剪贴板钩子 → 检测到图 → 存成文件 → 把路径塞进上下文
   │
   └─ 主模型拿到路径 → 推一条"看图请求"到共享收件箱
                                    │
                          常驻桥接（agent-bridge）3秒内扫到
                                    │
                          调 CodeBuddy（deepseek-v4-pro）看图
                                    │
                          结果写回收件箱
                                    │
              主模型这边原地轮询 ←────┘
              （每2秒查一次，最多等90秒）
                                    │
              拿到文字结果 → 整理好回复你

全程本地文件交换，不走网络。这对涉密行业是硬需求——图不能往外传。

几个关键技术决定

这方案我迭代了四版。前几版能用但脆，动不动超时。稳定下来的关键就四条。

把"帮我看图"变成结构化协议

最早我发给眼睛的请求就一句话："请分析这张图片"。结果它时好时坏——有时详细得像报告，有时一句话打发你。质量全凭它心情。

后来我定了个协议，请求长这样：

[ANALYSIS_REQUEST]
image_type: chart          # 图的类型：截图/照片/文档/图表/手写
depth: extract             # 分析深度：四档可选（见下）
focus: 提取所有数值和日期   # 重点看什么
context: 这是Q2财务报表     # 背景说明
output_format: 列表或表格   # 期望的输出结构

关键是 depth 这一项，我定了四档，每档对应一套不同的提问策略：

  • ocr —— 逐字转录，一个字都不许改、不许漏（扫描件最爱）
  • extract —— 只抽关键数据（数字、名称、金额、日期），结构化输出
  • summary —— 两三句话概括
  • detailed —— 详尽描述，布局+文字+元素全讲

这一下质量就稳了。自然语言当入口可以，但 Agent 之间内部流转，得靠协议。 跟 API 设计一个道理。

常驻桥接 + 心跳自愈

前几版最大的毛病：那个负责转发请求的"桥接进程"挂了没人知道。你发图，等90秒，超时。一查，桥接早崩了，请求堆在收件箱里没人处理。

现在的版本，桥接是常驻后台的（一个 Node 进程），并且：

  • 每 30 秒写一次心跳文件
  • 我在发图前先探一次心跳——心跳超过 90 秒没更新，判定它死了，当场自动拉起一个新进程再发图
  • 外挂一个看门狗，桥接崩了自动重启

之前是"我祈祷它还活着"，现在是"发图前自己确认它活着，死了自己拉起来"。从"能用"变成"可用"，就差这一个自愈环节。

同步轮询，一句话闭环

主模型发完请求怎么拿结果？它俩没法实时通信。我的做法是发完之后原地等：每 2 秒翻一次收件箱，按消息 ID 配对找回复，最长等 90 秒，找到了就接着往下走，超时就告诉我"那边没回，你催一下"。

这样我不用中间补一句"好了吗"。粘贴、发送、出结果，一个回合搞定。实测大部分图 10~48 秒回来，其中绝大多数是看图模型本身在思考，转发基本零延迟。

长回复自动落盘

看图结果有时很长（一整页扫描件转录）。超过 3000 字符的回复，桥接会自动存成文件再返回路径，避免被截断。这是个细节，但少了它长图就经常读到一半。

踩过的坑（按血泪程度排序）

坑一，最大的坑：直接调 CLI 走错了模型。

我一开始图省事，直接 codebuddy -p "看图"。能跑，但它走的是默认模型 混元3（hy3）——纯文本模型，根本没有多模态。它在那儿一本正经地"分析"一张它根本没看见的图，编得还挺像。

正确姿势是必须显式走桥接，桥接里写死了 --model deepseek-v4-pro（多模态那个）。怎么验证？让模型自报家门，但问题里别带模型名（否则它复述给你看）。

坑二：配置标记骗人。 前面说了，配置标 supportsImages: true 不等于真能看。必须实贴一张图测。我现在对所有"支持图片"的声明都保留一分怀疑。

坑三：超大图直接被拒。 扔一张 9000 像素宽的图过去，CodeBuddy 直接拒绝处理，提示输入长度超限。得先缩到最长边 ≤ 3000 像素再发。

其他小坑： PDF 不能直接喂（扫描件得先用 PyMuPDF 渲染成 PNG 再发，文字版直接提文本更快）；中文路径在老版 PowerShell 里会乱码，统一用 PowerShell 7（pwsh）跑就没事。

一点感受

这四版折腾下来，我最深的体会是：很多"能力边界"，限制不在模型本身，在你怎么搭桥。

主模型看不了图，不是它的错，是这条链路没把图喂进去。我做的不过是：在两个现成的 AI 之间，铺一条标准化的路——协议定清楚、进程保证活着、结果可靠传回。桥铺好之后，看图只是第一个跑在上面的场景，方案互审、任务派发走的是同一条路。

两个不太完美的 AI 组起来，能干出一个完美 AI 干不了的事。

这是「双 Agent 互联互通」系列在多模态看图维度的最新迭代。完整技术方案（含目录结构、协议字段表、配置注册、8 个踩坑详解、性能数据、实施清单）整理成了 15 页 PDF，照着就能自己布局出来：多模态看图技术方案.pdf。系列前作见 两个AI，一个会看一个会想。