1FlowBase实战：为DeepSeek V4挂载视觉工具实现多模态能力

纯文本模型也能看图？DeepSeek V4的多模态破局思路

DeepSeek V4 是当前备受关注的大语言模型，但它目前仍然是一个纯文本模型，不具备原生的图像理解能力。对于需要多模态交互的场景来说，这是一个明显的短板。

当前大语言模型（LLM）领域存在一个明显的技术分野：纯文本模型和多模态模型。纯文本模型如 DeepSeek V4 基于 Transformer 架构，仅处理 token 化的文本序列；而多模态模型（如 GPT-4o、Gemini）则在架构层面集成了视觉编码器（通常是 ViT 变体），能够将图像 patch 转化为与文本 token 同一向量空间的嵌入表示。这种架构差异意味着纯文本模型无法直接"看到"图片——它缺少将像素信息转化为语义表征的编码通路。

有没有办法在不等官方更新的情况下，让 DeepSeek V4 也能处理图片？答案是肯定的——通过 1FlowBase 搭建一套组合模型，将视觉模型 MIMO 2.5 作为"外挂"工具挂载到 DeepSeek V4 上，就能实现 Fusion 多模态入口。B站UP主分享了完整的搭建流程，本文将详细拆解这一方案的架构设计与实现步骤。

核心架构：DeepSeek V4 + MIMO 2.5 的工具编排逻辑

这套方案的核心逻辑并不复杂，但设计得相当精巧：

• DeepSeek V4 负责文本推理和组织回答，是整个链路的"大脑"
• MIMO 2.5 作为视觉工具被挂载，专门负责图片理解
• 1FlowBase 充当中间编排层，将两个模型的能力串联起来，对外发布统一的 API 入口

MIMO 2.5 是一款专注于视觉理解的多模态模型，其核心能力在于图像描述（Image Captioning）、视觉问答（VQA）和 OCR 识别等任务。与 GPT-4V 等端到端多模态模型不同，MIMO 2.5 更适合作为独立的视觉理解组件被调用——它接收图片输入，输出结构化的文字描述。这种"视觉转文本"的工作模式，恰好使其能够作为纯文本模型的"眼睛"，将视觉信息翻译成文本模型可以理解和推理的语言形式。

当用户输入包含图片时，DeepSeek V4 会自动触发视觉工具调用，让 MIMO 2.5 先"看懂"图片并生成文字描述，再将描述结果交回给 DeepSeek 进行综合推理。这种架构的好处在于：每个模型只做自己最擅长的事，通过工具调用机制实现无缝协作。

这里的工具调用（Tool Use / Function Calling）是现代大语言模型的一项关键能力。其原理是：模型在训练阶段学会了识别何时需要外部工具的帮助，并以结构化的 JSON 格式输出工具调用请求（包含函数名和参数）。编排系统捕获这个请求后，执行对应的外部工具，再将工具返回的结果注入到模型的上下文中，模型基于这些新信息继续生成回答。DeepSeek V4 支持 Function Calling 能力，这是整套方案得以成立的技术前提——没有这个能力，文本模型就无法"主动"决定何时调用视觉工具。

从实际测试结果来看，Cloud Code 在接入这套组合模型后，已经能够围绕图片内容进行分析和回答，而不再局限于纯文本处理。

1FlowBase搭建多模态链路的完整步骤

第一步：创建应用与配置开始节点

在 1FlowBase 中创建一个新应用，目标是将其配置成一个可发布的中间层服务。1FlowBase 属于 AI 应用编排平台（类似 Dify、Coze 等），其核心价值在于提供可视化的工作流编排能力，让开发者无需编写大量胶水代码就能将多个 AI 模型、工具和数据源串联成完整的应用链路。这类平台通常提供节点化的流程设计器，支持条件分支、变量传递、API 发布等功能。在本方案中，1FlowBase 扮演的角色类似于微服务架构中的 API Gateway + Orchestrator，负责请求路由、模型调度和结果聚合。

开始节点负责接收外部请求——也就是后续 Cloud Code 传进来的提示词、上下文和各类参数。这个节点是整个流程的入口，确保外部信息能够正确流入后续处理环节。

第二步：配置 LM 节点（选择 DeepSeek V4）

在 LM 节点中选择 DeepSeek 作为最终负责推理和组织回答的文本模型。这里有几个关键配置需要注意：

1. 系统提示词变量注入：将系统提示词变量注入到 LM 节点中，确保外部客户端传来的角色设定不会在中间层丢失
2. 推理强度设置：选择"追随外部请求"，让 Cloud Code 传来的思考强度参数继续传递给 LM 节点，保持推理行为的一致性

第三步：开启工具挂载——实现视觉能力的关键环节

这是让纯文本模型获得视觉能力的核心操作。开启工具挂载后，LM 节点下方会出现工具调用能力，DeepSeek 可以按条件触发视觉工具。

在工具配置中，有几个重要的设置项：

• 前置拦截规则：要求请求必须携带图片参数，否则视觉工具不会被调用，避免不必要的模型调用开销。前置拦截规则本质上是一种请求级别的路由策略，在 AI 应用工程化中具有重要意义。每次调用视觉模型都会产生额外的 API 费用和延迟（通常图像理解的推理时间是纯文本的 2-5 倍）。如果不设置拦截条件，即使是纯文本请求也会触发视觉工具的调用链路，造成不必要的资源浪费。这种"按需调用"的设计模式在微服务架构中被称为"断路器"（Circuit Breaker）的变体，是生产环境中控制成本和延迟的标准实践。
• 视觉模型选择：使用 MIMO 2.5，并且必须开启 History，否则视觉模型无法获取前面聊天中已经发生的上下文信息。在多轮对话场景中，"开启 History"意味着将之前的对话历史（包括用户消息和模型回复）一并传递给被调用的工具模型。对于视觉模型来说，这一点至关重要：如果用户在第三轮对话中发送了一张图片并问"这和我之前说的方案有什么关系？"，视觉模型不仅需要理解图片内容，还需要知道"之前说的方案"是什么。没有 History，视觉模型就像一个失忆的观察者——能看到图片，但完全不理解对话的上下文语境，导致生成的描述缺乏针对性。
• ToolTask 变量绑定：对应上游传下来的任务变量，视觉模型会根据这个任务描述去理解图片内容

第四步：自定义工具返回结果

工具返回结果需要自定义处理——将视觉模型看到的图片描述重新交回给 DeepSeek 使用。这一步确保了视觉理解的结果能够被文本模型正确消费，形成完整的推理闭环。从技术实现角度看，工具返回的结果会被插入到 DeepSeek 的上下文窗口中，作为一条特殊的"工具响应"消息。DeepSeek 在后续生成中会将这段视觉描述视为可信的事实依据，基于它进行逻辑推理、总结归纳或回答用户的具体问题。

第五步：发布组合模型并接入 Cloud Code

完成所有配置后，发布这个组合模型，1FlowBase 会生成一个可调用的 API 入口。将这个 API 配置到 Cloud Code 中，之后当用户输入图片时，请求就会自动走刚才配置好的多模态链路。

架构优势与适用场景分析

模块化设计带来的灵活性

这套方案最大的亮点在于模块化和可替换性。文本模型和视觉模型是解耦的，未来如果有更强的视觉模型出现，只需要在 1FlowBase 中替换工具节点即可，不需要重新设计整个流程。同样，如果 DeepSeek 未来原生支持多模态，也可以轻松切换。这种设计理念与软件工程中的"关注点分离"（Separation of Concerns）原则一脉相承——每个组件只负责单一职责，通过标准化接口进行通信，从而实现高内聚、低耦合的系统架构。

条件触发机制降低调用成本

前置拦截机制的设计值得称赞。只有当请求中包含图片时才会触发视觉工具调用，纯文本请求仍然直接走 DeepSeek，不会产生额外的延迟和成本。这种按需调用的策略在实际生产环境中非常重要。

典型适用场景

这套 Fusion 多模态方案特别适合以下场景：

• 已经在使用 DeepSeek V4 但需要临时增加图像理解能力的项目
• 希望灵活组合不同模型能力的开发者
• 通过 Cloud Code 等工具进行 AI 辅助开发，需要多模态输入支持的用户

总结：用能力编排替代全能模型

通过 1FlowBase 的编排能力，我们可以将 DeepSeek V4 的强大文本推理与 MIMO 2.5 的视觉理解组合成一个统一的多模态入口。整个方案的核心在于工具挂载机制——让文本模型在需要时自动调用视觉工具，获取图片描述后继续完成推理任务。

这种"给模型挂甲"的思路，本质上是一种能力编排的范式。它不依赖单一模型的全能性，而是通过合理的架构设计，让每个模型发挥各自的长处。这一思路在业界也有广泛的实践基础——从早期的 LangChain Agent 到 OpenAI 的 Function Calling 生态，再到各类 AI 编排平台的兴起，"组合优于全能"正在成为 AI 应用开发的主流范式。对于追求灵活性和可控性的开发者来说，这是一个值得尝试的方案。