WorkBuddy 直连 DeepSeek v4 Flash，一发截图就崩？我们在网关层一招根治

DeepSeek v4 Flash 便宜好用，已经成为企业级大模型的事实标准——谁没接上，谁就掉队。WorkBuddy 则在企业办公领域一骑绝尘，稳坐第一生产力品牌的位置。二者结合，本该如虎添翼。

但真把自建 DeepSeek v4 Flash 推理服务接进 WorkBuddy，你会发现一个令人抓狂的问题：对话框里一发截图，必报错。

折腾各种姿势，结果都是这样：

发截图是刚需行为——总不能每回都先存盘再贴路径。下面看四川汉扬智能自研的 Tokengine 平台，是如何优雅地解决这个问题的。

四川汉扬智能研发的 Tokengine 平台，是上市公司扬电科技在人工智能领域的重要战略布局，目前已开启公测。平台基于自有算力、自研推理框架搭建了 MaaS Token 工厂，并外接第三方供应商提供灵活的算力补充。

---

一、为什么截图不行？

众所周知，DeepSeek v4 Flash 是纯文本大模型，本身不识图。

DeepSeek 官方 App 专门出了"识图模式"——但这并不意味着大模型本身识图了。它的做法是：网关层面拦截用户发送的图片，转给其他识图服务解析，再把解析出的文本送回 DSv4 主模型处理。

同样的道理，WorkBuddy 内置的 DeepSeek v4 Flash 能识图，也不是模型自身的能力，而是前置网关做了同样的事。总之，DeepSeek v4 Flash 大模型本身从头到尾没收到过图片。

而当你直连自建推理服务、在 WorkBuddy 里直接发截图时，vLLM 推理服务收到的 content 数组里赫然躺着 image_url，于是必然抛出 400 错误：

deepseek-ai/DeepSeek-V4-Flash is not a multimodal model

对应的请求长这样：

POST /v1/chat/completions
{
  "model": "deepseek-v4-flash",
  "messages": [
    {
      "role": "user",
      "content": [
        { "type": "text", "text": "这是什么？" },
        { "type": "image_url",
          "image_url": {
            "url": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA..."
          }
        }
      ]
    }
  ],
  "stream": true,
  "temperature": 0.7,
  "max_tokens": 1024
}

多模态请求里，content 是数组而非字符串；粘贴的截图就藏在 image_url 字段里。vLLM 一看就知道：这个模型不吃图，拒绝。

---

二、各路博主的尝试与弯路

网上有不少人尝试各种"魔法"来绕过这个问题，最主流的一条路是：

使用识图 Skill 外挂视觉大模型。 WorkBuddy 内部有一个名为 Vision 的 Skill，外接视觉大模型，设计初衷是解析图片、将结果文本发送给主模型：

vision：让没有原生 vision 能力的模型获得识图能力。当用户发送图片、分享图片路径，或要求分析/描述/识别图片内容时触发。

听起来能解决问题，但实际上这条路走不通。

原因在于：Skill 是作为提示词上下文的一部分存在的，它并不具备在大模型处理请求之前拦截信息的能力。WorkBuddy 对话框收到截图后，会连同图片一起发给大模型——用不用 Skill，DSv4 收到的请求里都带着 image_url 字段，该报 400 还是报 400。

不过，识图 Skill 虽然解决不了直接发截图的问题，却提供了一条关键思路：

在 WorkBuddy 对话框里，不要发截图，而是指定图片路径。

---

三、为什么给图片路径就行？

核心在于 WorkBuddy 是 Agent 架构，而非简单的 API 透传：

1. 在 WorkBuddy 对话框指定图片地址（如 D:/xxx.png），并加载识图 Skill；
2. DSv4 收到的是一段纯文本路径字符串 D:/xxx.png，能正常处理；
3. DSv4 识别到这是图片任务，会通知 WorkBuddy 调用识图 Skill 解析图片，将解析出的文本注入上下文，再送回 DSv4 做进一步推理。

核心证据见下图红框——主模型收到的就是路径文本，而非图片 payload：

简单说：只要图片不以 image_url 形式出现在请求里，DSv4 就不会炸。

但问题是——用户不会每次都乖乖存盘贴路径。截图是刚需。

---

四、网关层旁路解析：优雅且透明

既然 Agent 端的方案不够优雅，那就到服务端做手脚。

汉扬智能的 MaaS 平台在推理服务前面部署了 Higress AI 网关，整体链路如下：

WorkBuddy → Higress AI 网关 → LLM Router Service → vLLM 推理服务

我们基于 Higress AI 网关自研了 ai-image-reader WASM 插件。它会在 DSv4 收到请求之前介入：对直接截图产生的 image_url 请求，先转发给视觉大模型解析，再将解析出的文本注入原始上下文，最后送到 DSv4 处理。

流程如下：

插件支持白名单配置：只对特定模型开启旁路解析逻辑，不影响其他多模态模型的正常调用。我们已经向 Higress 官方提交了 PR，申请将这个插件贡献到开源社区。

apiVersion: extensions.higress.io/v1alpha1
kind: WasmPlugin
metadata:
  name: ai-image-reader
  namespace: higress-system
spec:
  url: oci://10.8.65.4/hanyotech/ai-image-reader:latest-local-router2
  defaultConfig:
    type: local                           # 自实现 local provider，用 K8sCluster 走 k8s service 发现
    serviceName: router-spec-router-service                              # OCR 旁路指向 router-spec（经它按 model 分流到 qwen3-vl）
    namespace: vllm-inference            
    model: Qwen/Qwen3-VL-8B-Instruct       # router-spec 据此把 OCR 请求路由到 qwen3-vl
    servicePort: 80                        
    timeout: 30000                         

    # --- 模型白名单（正则表达式列表）---
    modelPatterns:
      - "^deepseek-ai/DeepSeek-V4-Flash$"
      - "^deepseek-ai/DeepSeek-V4$"
      - "^MiniMax/MiniMax-M3$"
      - "^MiniMax/MiniMax-M2\\.7$"
      - "^MiniMax/MiniMax-M2$"

实际效果——截图直接发，不再报错：

---

五、复盘

本文的源头是一个真实的用户反馈：在 WorkBuddy 上直连自建 DeepSeek v4 Flash 推理服务时，无法发送截图。

DeepSeek v4 Flash 是纯文本模型，直连时任何携带 image_url 的请求都会被 vLLM 以 400 拒绝。WorkBuddy 内置版本之所以能识图，靠的是官方前置网关的拦截转译——而我们自建服务没有这一层。

最终落地了两套方案：

	方案	体验
①	Agent 端配置视觉 Skill，改为指定图片路径	能用，但不够优雅，门槛高，用户不可能每次都存盘贴路径
②	服务端网关层做旁路解析（ai-image-reader 插件）	优雅、透明，用户无感知，直接截图即可

方案②的思路并不复杂：把官方内置大模型在网关层做的事，在自建链路上复刻一遍。 用户不需要改任何习惯，截图照发不误，视觉解析在网关侧自动完成。

这就是汉扬智能自研推理框架向官方能力对齐的一次实践——积极响应真实用户需求，让自建大模型服务也能拥有"开箱即用"的体验。