企业官网建设流程全解析

Dify 1.17 升级实测（附）：图片直传多模态模型——LLM 节点看图能力的配置与坑

Dify 实战系列 · 1.17 升级实测 04/04 | 基于 Dify 1.17.0 实测（2026-09）
📖 摘要：Dify 1.17 打通了图片直传多模态模型的完整链路：上传、文件变量、vision 配置、视觉模型识别。「拍照报障」「图片描述」这类需求落地成本大幅下降。但这条链路有三个容易踩的坑：文件类型白名单是分类枚举、上传必须走 service API、文件绑定上传时的应用。本文是实测记录。

客户要「图片理解」的时候，我们之前的内心戏是：又来了。售后拍照报障——用户拍张设备照片，让 AI 判断故障部位；商品图自动描述——电商上架前生成文案。需求听着不复杂，但 1.16 时代做起来很折腾：图片得先转成 URL，再想办法塞进提示词，链路长还经常传不进去。

1.17 把这条链路做成了原生能力：文件变量 + vision 直传，配置三件套就能跑。实测完，三条结论 + 三个坑，都在这。

三条核心结论

1. 配置三件套。start 文件变量（type=file）+ LLM 节点 vision（enabled + variable_selector）+ 多模态模型：

# 开始节点的文件变量-id:startdata:type:startvariables:-label:图片type:filevariable:imagerequired:trueallowed_file_types:["image"]# ⚠️ 分类枚举，不是 MIME！# LLM 节点开 vision-id:llm_vdata:type:llmmodel:{provider:langgenius/tongyi/tongyi,name:qwen-vl-plus,mode:chat}prompt_template:-role:usertext:"请描述这张图片的内容，用中文。"vision:enabled:trueconfigs:variable_selector:["start","image"]detail:high

2. 上传必须走 service API。console 后台传的文件，service 端运行引用直接报 Invalid upload file——两套体系隔离。正确姿势是POST /v1/files/upload（Bearer 应用密钥）拿到 upload_file_id，运行传参时 file 变量是单个对象（不是数组）：

{"image":{"type":"image","transfer_method":"local_file","upload_file_id":"..."}}

3. 文件绑定上传时的应用。换应用引用旧文件直接失效——每个被测/交付应用独立上传，这个约束要写进交付脚本。

一次识别实测：qwen-vl-plus 看图

测试图是程序生成的：蓝色背景 + 左上角红色方块。通义 qwen-vl-plus 识别（3.9 秒）：

这张图片非常简洁，主要由两种颜色构成：蓝色和红色。整体布局：大部分区域被纯蓝色填充；左上角有一个小的红色正方形……红色正方形在蓝色背景的衬托下显得格外突出。

颜色、位置、布局全部说对——直传链路完整可用。验收建议：用「包含图中具体特征关键词」断言（测试图有红方块，就断言回答含「红色」），比泛化话术判断可靠。

三个坑速查

顺带提醒：1.17 的 LLM 节点 prompt_template 是字符串格式（1.16 的{enabled, jinja, value}包裹废除）、memory 配置 window 必填——DSL 迁移细节见系列第一篇。完整实测（上传链路、vision 全字段、模型选型）见门户全文。

适用场景

图片描述 / 拍照报障、文档视觉识别（扫描件内容提取）、图片审核。1.17 之后，「传图让 AI 看」不再是折腾事。

💬 你的图片理解场景是怎么做的？欢迎评论区分享。

📚 更多实战记录见我的博客：鱼日先生

本文基于 Dify 1.17.0 实测，配置在不同版本间可能变化，使用前请确认版本。AI 参与创作声明：本文由 AI 辅助写作，内容基于作者真实实测记录。