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 文件变量typefile LLM 节点 visionenabled 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:high2. 上传必须走 service API。console 后台传的文件service 端运行引用直接报 Invalid upload file——两套体系隔离。正确姿势是POST /v1/files/uploadBearer 应用密钥拿到 upload_file_id运行传参时 file 变量是单个对象不是数组{image:{type:image,transfer_method:local_file,upload_file_id:...}}3. 文件绑定上传时的应用。换应用引用旧文件直接失效——每个被测/交付应用独立上传这个约束要写进交付脚本。一次识别实测qwen-vl-plus 看图测试图是程序生成的蓝色背景 左上角红色方块。通义 qwen-vl-plus 识别3.9 秒这张图片非常简洁主要由两种颜色构成蓝色和红色。整体布局大部分区域被纯蓝色填充左上角有一个小的红色正方形……红色正方形在蓝色背景的衬托下显得格外突出。颜色、位置、布局全部说对——直传链路完整可用。验收建议用「包含图中具体特征关键词」断言测试图有红方块就断言回答含「红色」比泛化话术判断可靠。三个坑速查坑现象修复类型白名单写 MIMEallowed_file_types 写 image/png → 400用分类枚举imageconsole 文件 service 不可见运行报 Invalid upload filev1/files/upload 上传文件跨应用失效新 app 引用旧文件报错每 app 独立上传顺带提醒1.17 的 LLM 节点 prompt_template 是字符串格式1.16 的{enabled, jinja, value}包裹废除、memory 配置 window 必填——DSL 迁移细节见系列第一篇。完整实测上传链路、vision 全字段、模型选型见门户全文。适用场景图片描述 / 拍照报障、文档视觉识别扫描件内容提取、图片审核。1.17 之后「传图让 AI 看」不再是折腾事。 你的图片理解场景是怎么做的欢迎评论区分享。 更多实战记录见我的博客鱼日先生本文基于 Dify 1.17.0 实测配置在不同版本间可能变化使用前请确认版本。AI 参与创作声明本文由 AI 辅助写作内容基于作者真实实测记录。