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 也不惯着，报错就来了。

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

先确认版本，别上来就改

我朋友上来就想改 .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 我列一下：

模型模型 ID定位Solgpt-5.6-sol最难的问题丢给它Terragpt-5.6-terra日常默认，最均衡Lunagpt-5.6-luna便宜、快、高并发自动路由gpt-5.6OpenAI 自己选

我日常 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 的推理链可以保存、回放

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

Chat CompletionsResponses API说明messagesinput请求体结构变了response_formattext.format格式控制字段更名tool_callsfunction_call事件结构不同无reasoning新增推理深度控制无previous_response_id有状态续接无store是否服务端存储

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

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

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

报错/现象原因解决unsupported parameter: reasoningChat Completions 不支持 reasoning切 Responsesmodel does not support response_formatGPT-5.6 在旧接口下限制 response_format切 Responses，用 text.formatinvalid messages format插件还在用 messages 结构升级 OpenAI 插件到 v1.0.3+function calling 返回空tool_calls 事件结构不兼容切 Responses + 升级插件流式响应中断流式结束标志不同切 Responses升级后 GPT-4o 也报错把旧模型也改成 Responses 了GPT-4o 继续用 Chat Completions

最经典的场景是保留了 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 上。

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

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，关注起来。这工作看起来虚，但真出事的时候，早一天知道就少一天损失。

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

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

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

成本项迁移前（月）迁移后（月）输入 Token$75$45缓存命中$5$3输出 Token$300$270合计$380$318

月省 $62，年省 $744。

JOTO 企业落地观察

• 企业部署 GPT-5.6 需明确区分「模型能力」与「接口契约」：Responses API 的 reasoning、stateful context 等特性并非开箱即用，必须通过 Dify v1.16+ 的模型配置层显式启用，否则仍退化为兼容模式。
• 这类系统的取舍在于「功能完备性」与「运维确定性」之间：Responses API 提供的推理链回放、增量上下文等能力虽强，但要求团队同步升级插件、重构参数映射逻辑，对存量自动化脚本构成隐性改造成本。
• AI 安全治理不能仅依赖模型层降级（如 Luna），必须结合 Dify v1.16.1 的沙箱网络隔离、Shell 输出脱敏、人工审批三重机制——尤其当 Responses API 允许更复杂的 tool calling 时，攻击面随之扩大。
• RAG 知识工程中若引入 GPT-5.6 的 reasoning items，需同步改造知识缓存策略：原基于 Chat Completions 的 token-level 缓存无法复用 reasoning chain 的中间状态，必须升级为 response-level 或 step-level 存储粒度。