Dify 接入 GPT-5.6 Responses API：我踩过的那些坑

本文基于 OpenAI 官方文档、Dify v1.16.0/1.16.1 Release Notes 及开发者实测整理。价格与配置信息截至 2026 年 8 月 9 日，以官方最新公告为准。

周四晚上十一点，我正准备关掉 Dify 后台回家，微信群突然炸了。一个做智能客服的朋友甩过来一张报错截图：

Unsupported parameter: 'response_format' is not supported
with model gpt-5.6-luna on Chat Completions API.
Please use the Responses API.

他文字里带着那种被坑惯了的疲惫："白天还好好的，晚上跑批就挂了。"

我一看就知道怎么回事。升级到 Dify v1.16.0 之后，新配的 OpenAI 模型默认走 Responses API，但他那个账号是两个月前配的，API Type 还卡在 Chat Completions。OpenAI 已经明牌弃用 Chat Completions，GPT-5.6 系列在旧接口下就是后娘养的——能用，但只给你最低限度的兼容。Dify 没帮你自动切，OpenAI 也不惯着，报错就来了。

这个问题不复杂，但坑在"你以为它会自动处理"。

[配图建议 1：封面图。深色科技风，画面中心是 Dify Logo 与 OpenAI Logo 之间一条从"Chat Completions"断裂过渡到"Responses API"的光带，右侧有 GPT-5.6 三颗天体（太阳/地球/月亮）的抽象符号，左下角标注"迁移实战 + 安全加固"。整体色调为深蓝+青绿，传达技术迁移的专业感。]

先确认版本，别上来就改

我朋友上来就想改 .env，被我拦住了。第一步永远是先看版本。

Dify 要到 v1.16.0 才支持 Responses API 类型选项。低于这个版本，你菜单里根本没有那个下拉框，折腾半天发现是版本问题，血压会更高。OpenAI 官方插件也要 v1.0.3 以上，这个版本开始默认用 Responses，同时支持 reasoning replay 和加密 reasoning items。

检查方式很简单：

# 看 Dify 版本
docker exec -it dify-api flask version

# 看 OpenAI 插件版本
# 后台 → 插件管理 → 已安装 → 搜 OpenAI

版本不对先升级。别跟我对着干，我见过太多人因为跳过这一步，后面所有操作都是错的。

迁移就一步，但细节要命

核心动作其实就一句话：把 API Type 从 Chat Completions 改成 Responses。

路径在这：

Dify 后台 → Settings → Model Providers → OpenAI → 编辑模型 → API Type → Responses

但改完不等于完事。

模型 ID 也要对应。GPT-5.6 这次用了天体命名，四个常用 ID 我列一下：

我日常 Agent 场景用 Luna 最多。不是因为它最强，是因为它够便宜，响应够快，大部分客服、摘要、分类任务它都能搞定。

改完记得点"测试"。这一步很多人会漏。测试通过再保存，不通过回头看版本和 ID。

两套 API 到底差在哪

Chat Completions 和 Responses API 不是同一个接口改个名那么简单。我最早也以为就是 endpoint 从 /v1/chat/completions 变成 /v1/responses，结果调了一天才发现参数结构全变了。

最直观的几处差异：

• • messages 变成 input
• • response_format 变成 text.format
• • tool_calls 的事件结构换了
• • Responses 支持 previous_response_id，多轮对话不用每次都传完整上下文
• • Responses 支持 reasoning items，GPT-5.6 的推理链可以保存、回放

这里我画张表，方便你回头查：

如果你是自己写插件或者在 Dify 外面调 OpenAI，这些映射必须搞清楚。不然迁移完 Dify 能跑了，你自己的脚本还在报错。

[配图建议 4：一张对比信息图，左侧蓝色区域列示 Chat Completions 的请求结构（messages → response_format → tool_calls），右侧绿色区域列示 Responses API 的请求结构（input → text.format → function_call + reasoning），中间用箭头标注参数映射关系，底部用红色标注"GPT-5.6 仅在 Responses 下完整支持"。]

报错排查：十有八九是这个

我把迁移过程中最常见的报错整理了一份速查。不敢说全覆盖，但够应付 90% 的情况。

最经典的场景是保留了 Chat Completions，然后请求里带了 response_format：

{
  "model": "gpt-5.6-luna",
  "messages": [{"role": "user", "content": "Hello"}],
  "response_format": {"type": "json_object"},
  "stream": true
}

OpenAI 直接甩给你一个 400，告诉你用 Responses。

改成 Responses 后：

{
  "model": "gpt-5.6-luna",
  "input": [{"role": "user", "content": "Hello"}],
  "text": {"format": {"type": "json_object"}},
  "stream": true
}

就好使了。

口诀我帮你想好了：看到 GPT-5.6 报参数错，先看 API Type。十有八九还赖在 Chat Completions 上。

[配图建议 5：报错排查流程图。从"GPT-5.6 报错"开始，分支判断"API Type 是否为 Responses？"→否→切换为 Responses→重新测试；→是→检查插件版本≥v1.0.3？→否→升级插件→重新测试；→是→检查模型 ID 是否正确？→否→修正模型 ID。流程图用简洁的方框+箭头，绿/红/黄三色标注状态。]

迁移完先别上线，把安全做了

Astra 暂停那件事，大家应该都看到了。OpenAI 自己都说"无法排除模型具备关键性网络能力"，直接把项目按暂停。这不是小题大做，是这个行业终于开始认真面对 Agent 的安全问题了。

Dify v1.16.1 的沙箱加固来得正是时候。我迁移完之后，会顺手做这几件事：

模型降级。 越高危的操作，越不要用最强的模型。文件写入、网络请求、代码执行这种，我会强制切到 Luna，并且把 reasoning_effort 调低。要的是可控，不是聪明。

沙箱网络隔离。 Dify v1.16.1 内置了 Squid 代理 + ACL 白名单 + Bearer Token + Jinja2 沙箱 + Docker 网络隔离。但默认配置不一定安全，生产环境一定要把 DIFY_AGENT_API_TOKEN 和 AGENT_BACKEND_API_TOKEN 从默认值换成高强度随机 Token。

docker network ls | grep agent_sandbox
docker compose ps | grep ssrf
grep DIFY_AGENT_API_TOKEN .env
grep AGENT_BACKEND_API_TOKEN .env

权限白名单。 Agent 能调什么工具、能访问什么域名、能执行什么命令，必须显式声明。默认拒绝，按需放行。rm -rf、curl、wget 这种命令，没有特殊原因一律禁掉。

输出审计。 所有 Agent 输出都要留痕。v1.16.0 新增的 Shell 输出脱敏可以配起来：

DIFY_AGENT_SHELL_REDACT_PATTERNS='["sk-[a-zA-Z0-9]{48}", "password.*=.*", "token.*=.*"]'

人工审批。 发邮件、改数据库、执行支付、删文件，这些操作必须加 Human-in-the-Loop。Dify v1.13.0 就支持了，别浪费。

跟踪供应商安全公告。 OpenAI 博客、status 页面、Dify GitHub Releases，关注起来。这工作看起来虚，但真出事的时候，早一天知道就少一天损失。

[配图建议 6：Agent 安全加固架构图。画面中心是 Dify Agent 节点，外围环绕 6 层防护环（从内到外依次标注：模型降级、沙箱隔离、权限白名单、输出审计、人工审批、供应商跟踪），每层用不同颜色区分，外圈标注"Astra 事件警示"。整体风格类似盾牌或堡垒的横截面，传达纵深防御理念。]

成本账：便宜归便宜，账单不一定少

Luna 降价之后是输入 、缓存命中0.1/MTok、输出 $6/MTok。这个数字放在一年前我不敢想。

我按日均 500 万 Token 的 Agent 应用粗算了一下：

月省 ，年省744。数字不大，但重点不是这个。

Responses API 真正的价值在于 previous_response_id 和 reasoning replay。多轮对话不用每次都把完整上下文塞过去，推理链还能复用。这些省下来的不只是 Token，是调试和审计时的时间。

不过我得泼盆冷水：单价下降不等于账单下降。Luna 便宜了，你会更舍得让它多跑几轮、多试几次。最后账单怎么变，取决于你的使用方式，而不是 OpenAI 的定价表。

[配图建议 7：成本对比柱状图。横轴为"迁移前/迁移后"，纵轴为月成本（美元），用两组柱状图分别展示输入/缓存/输出三项成本，迁移后总柱明显变矮，旁边用绿色标注"月省 ，年省744"。图表配色与文章整体色调一致。]

几个我觉得该说的

迁移这件事本身没什么技术含量，但它暴露了一个很现实的问题：很多人对上游 API 的变更没有预期。

OpenAI 从 Chat Completions 切到 Responses，不是最后一个接口变动。你今天学会迁移，下次换接口就不会慌。这种"迁移肌肉记忆"比任何单一操作都值钱。

另外，Responses API 的有状态续接是好东西，但别把所有状态都外包给 OpenAI 服务端。万一服务端状态丢了，你的业务逻辑就断了。关键状态自己留着。

Agent 安全也是。Astra 暂停是给全行业敲的警钟，但不是丧钟。该用还是用，只是在关键节点设防。等"绝对安全"再动手，永远等不到。

参考资料

• • Dify v1.16.0 Release Notes: github.com/langgenius/dify/releases/tag/v1.16.0
• • Dify v1.16.1 Release Notes: github.com/langgenius/dify/releases/tag/v1.16.1
• • OpenAI Responses API 文档: platform.openai.com/docs/api-reference/responses
• • OpenAI GPT-5.6 定价公告: openai.com/api/pricing/
• • OpenAI Astra 暂停声明: openai.com/blog（2026/8/7）
• • 本号 Dify v1.16.0 解读: 《Dify v1.16.0 正式发布：Agent 沙箱全面开放》
• • 本号 Astra 事件解读: 《OpenAI 踩下刹车：Astra 暂停研发背后的 AI 安全范式拐点》
• • 本号 GPT-5.6 全面解读: 《GPT-5.6 全面解读：政府门控首发 + 三档天体分级》

现在我的 Dify 后台已经切好了，朋友的应用也恢复正常。我最后检查了一遍 Agent 安全配置，把 Token 换成随机生成的，然后关掉了笔记本。

窗外凌晨一点，楼下便利店还亮着灯。 migration 这种事，永远不会在白天发生。