Dify 已支持 GPT Image 2.5 吗？

官方 OpenAI Tools 源码已在 PR 3860 中加入 Flare/Sunburst，版本为 0.2.0；9 月 9 日尚未独立确认 Marketplace 分发状态。请看已安装工具的版本与型号选项。

为什么升级后还是 Image 2？

新版仍默认 gpt-image-2，需要在工具节点显式选择新型号。返回 usage 时可看附带的 model，没有 usage 则查节点参数和请求记录。

本文讲 OpenAI Tools 的图片生成和编辑工具。修改语言模型供应商或 LLM 节点，不代表另一个图片工具的 model 也变了。

Dify 接入 GPT Image 2.5，要检查已安装的 OpenAI 工具插件，并在生图工具的 model 参数里明确选择 Flare 或 Sunburst。 新版源码仍默认使用 gpt-image-2，升级插件不会自动替你选新模型。

截至 2026 年 9 月 9 日，官方 PR #3860已合并，manifest 版本为 0.2.0。本次没有独立确认所有 Marketplace 安装都已分发该版本。下文是根据源码核验的配置检查，不是完整 Dify 部署和付费生图的实测报告。

这次变化属于 OpenAI Tools 工具插件，并非只在 OpenAI 模型供应商设置里加一个语言模型。要检查实际运行工作流中的生图工具节点。

官方源码保留了原来的工具 ID：

任务	工具 ID	要检查的参数
文生图	`gpt_image_2_generate`	Prompt、Model、尺寸、画质
编辑原图	`gpt_image_2_edit`	参考图、Prompt、Model

工具 ID 里还写着 2，不代表它不能用 2.5；真正决定请求的是 model。反过来，其他节点中出现新型号，也不等于这个生图节点已经选用了它。

打开已安装插件的详情，确认版本。再看生成或编辑工具的参数表单，检查是否出现以下选项：

找不到新型号时，检查该工具插件是否有官方更新。如果还没分发，记录安装版本和缺少的字段。源码合并不能证明托管工作区已完成升级。

自部署环境要按插件的打包和依赖要求升级，不要只改版本号。合并改动同时更新了依赖与参数处理，手动改 manifest 不会让旧代码获得新能力。

在工具节点中显式选择型号，不保留默认值。可以从速度优先的 Flare 开始尝试，精细改图则考虑 Sunburst；这是用途建议，不是对这条工作流的效果保证，详见型号选择。

第一次检查尽量只保留一段提示词、一个文生图工具和一个图片输出。尺寸用 1024x1024，主体简单些，便于把配置问题和复杂编辑问题分开。

新版源码为 Image 2.5 增加 xhigh、max 等画质选项，并在发请求前校验参数。因此，节点里的参数校验失败，不一定代表 OpenAI 已收到请求。

上游响应包含 usage 时，插件会输出附带所选 model 的 JSON。把它和本次参数一起保留，便于核算费用与定位错误。没有 usage JSON 时，检查保存的节点参数和脱敏请求记录；缺少 usage 本身不能证明调用了错误型号。

结果	下一步
usage 仍显示 `gpt-image-2`	检查显式 model，以及运行的是不是已保存的工作流版本
没有新型号选项	查安装的工具插件版本与可用更新
自定义尺寸被本地拒绝	用尺寸校验器检查
PNG 看起来不透明	按透明像素检查验原件
上游拒绝权限	按 API 端点与权限排查检查

不要凭图片风格判断型号，也不要把节点运行成功等同于成功输出了可下载图片。

使用 gpt_image_2_edit 时，要将参考文件接入图片输入，并说明修改与保留要求。仅在提示词里写文件名，不等于工具实际收到了图片。

保留原图、结果图、所选型号和 usage；标签文字改变、背景未移除时，才能回看哪一步出了问题。透明输出同时查请求格式和实际 alpha，不能只看文件扩展名。

先完成一次有明确目标的运行，检查图像与实际费用，再把工作流放进循环。验收应包括工具正确、明确选择 2.5、请求被接受和图片可用。