n8n 很适合把 OpenAI Chat Model、AI Agent、HTTP Request、数据库和通知节点组合成自动化工作流。通过 DeepAI API 中转站 接入 GPT-5 或其他 OpenAI-compatible 模型时，最常见的坑并不总是 Base URL 或 Key，而是客户端节点在请求体里悄悄带了模型不支持的参数。一个典型报错就是：unsupported STOP parameter。
stop 参数，排查时要看真实请求体，而不只看 n8n 界面。问题背景：界面没填 stop，为什么还是报 STOP
这个问题来自 n8n Issue #18149。用户在 n8n 1.105.4 的 OpenAI Chat Model 节点里选择 gpt-5，节点参数里只有 model 和空的 options: {}，却返回 unsupported STOP parameter。这说明问题不一定来自用户显式配置，而可能来自 n8n 节点、LangChain 封装或旧工作流模板默认传入的参数。
维护者随后说明该问题由 PR #18213 修复，PR 内容是更新 LangChain 及相关依赖，以解决 GPT-5 相关问题。评论里也有人补充，后来遇到类似错误时，是因为从网上复制了旧 JSON 模板，里面使用了旧版 AI Agent / Chat Model 节点，升级工作流节点后恢复正常。
为什么 GPT-5 对 stop 更敏感
OpenAI API 文档中已经明确提到，stop 参数并不适用于部分最新 reasoning 模型。对 GPT-5 这类模型来说，客户端如果继续把旧 Chat Completions 参数无条件套上去，就可能被上游拒绝。通过 DeepAI API 中转站时，这种错误通常会以 400 形式透传回来，错误字段会指向 stop 或 STOP。
{
"model": "gpt-5",
"messages": [
{"role": "user", "content": "总结今天的订单异常"}
],
"stop": []
}
很多人会忽略空数组或空字符串形式的 stop。但对严格校验的模型后端来说，只要字段存在，就可能被视为不支持参数。正确做法不是传空，而是当模型不支持 stop 时完全移除该字段。
{
"model": "gpt-5",
"messages": [
{"role": "user", "content": "总结今天的订单异常"}
]
}
DeepAI API 中转站场景下的排查步骤
如果 n8n 接入 DeepAI API 中转站后出现 unsupported STOP parameter，建议按下面顺序排查。核心原则是先看真实请求体，再改节点配置。
- 确认 n8n OpenAI 凭据或 OpenAI Chat Model 的 Base URL 写为
https://api.deepai.wang/v1，不要写到/chat/completions。 - 在 DeepAI API 中转站后台查看失败请求日志，确认请求体是否包含
stop字段。 - 如果模型是 GPT-5、o 系列或其他 reasoning 模型，优先移除
stop，不要传空数组、空字符串或默认停止词。 - 升级 n8n 到包含 PR #18213 后续 LangChain 依赖更新的版本。
- 如果工作流来自网络模板，重新拖拽最新 AI Agent / OpenAI Chat Model 节点，避免旧节点 JSON 继续携带旧参数。
推荐的验证方式
在 n8n 里改之前，可以先用 curl 直接验证 DeepAI API 中转站是否能正常调用同一个模型。这样可以把问题拆成两段：中转站和模型是否可用；n8n 节点是否生成了不兼容请求体。
curl https://api.deepai.wang/v1/chat/completions \
-H "Content-Type: application/json" \
-H "Authorization: Bearer YOUR_DEEPAI_KEY" \
-d '{
"model": "gpt-5",
"messages": [
{"role": "user", "content": "用三点说明 n8n 自动化工作流的价值"}
],
"max_completion_tokens": 512
}'
如果 curl 不带 stop 能返回，而 n8n 节点失败，就说明 DeepAI API 中转站、模型 ID、Key 都基本没问题。下一步应该更新 n8n 节点、LangChain 依赖或旧工作流模板，而不是继续更换模型供应商。
旧模板为什么容易复现
n8n 工作流经常通过 JSON 复制传播。问题是，节点版本也会被模板一起复制下来。一个 2025 年能跑的 OpenAI Chat Model 节点模板，到了 GPT-5 或新 reasoning 模型时代，可能仍然带着旧参数、旧 LangChain 默认值或旧 tool calling 行为。Issue #18149 评论里就有人提到，后来遇到同样错误，是因为使用了网上的旧 AI Agent 模板，更新到最新工具节点后解决。
- 从模板导入工作流后，检查 AI Agent、OpenAI Chat Model、Tools Agent 的节点版本。
- 如果节点面板提示有新版本，优先用新节点重新配置，而不是只编辑旧 JSON。
- 查看执行日志和 DeepAI 中转站日志，确认旧字段是否还在请求体里。
- 对 GPT-5、o 系列模型，避免沿用旧模型的 stop、max_tokens、parallel tool 等默认参数。
API 中转站的价值：把隐藏参数变成可见证据
DeepAI API 中转站在这类问题里最重要的价值是可观测性。n8n 前端可能只显示一句 unsupported STOP parameter，但中转站日志可以告诉你：请求到底发到了哪个模型、路径是不是 /v1/chat/completions、是否带了 stop、上游返回的 param 和 code 是什么。
对站长来说，建议把常见不兼容参数做成文档清单：GPT-5 类模型不要传 stop；reasoning 模型优先用 max_completion_tokens；工具调用模型要检查 tools、tool_choice 和流式响应；旧 n8n 模板导入后要升级节点。这样用户搜索“n8n GPT-5 unsupported STOP parameter”“OpenAI Chat Model stop 400”“API 中转站 GPT-5 n8n 接入”时，就能直接找到解决路径。
常见坑位
- stop 为空也算传参：不要传
stop: []或stop: ""，不支持时应完全移除字段。 - 只升级 Docker 镜像不升级节点：导入的旧工作流模板可能仍保留旧节点版本，需要重新保存或替换节点。
- Base URL 写成完整接口：n8n 凭据里建议填
https://api.deepai.wang/v1。 - 把 GPT-5 当普通 ChatGPT 模型：新模型参数支持范围不同，不能沿用所有旧默认值。
- 忽略中转站日志：没有日志就很难判断错误是来自 n8n、DeepAI 中转层还是上游模型。
参考资料
- n8n Issue #18149：GPT 5 not working in OpenAI Chat Model node – unsupported STOP parameter
- n8n PR #18213：Update LangChain dependencies to fix GPT-5 related issues
- OpenAI Chat Completions API 参数说明
- Dify max_tokens / max_completion_tokens 参数兼容排查
总结
n8n 接入 DeepAI API 中转站调用 GPT-5 时，如果 OpenAI Chat Model 节点报 unsupported STOP parameter，优先检查真实请求体，而不是只看节点界面。升级 n8n 和 LangChain 相关依赖、替换旧 AI Agent 模板、移除不支持的 stop 字段，再用 DeepAI API 中转站日志核对请求，通常就能让 GPT-5 工作流恢复正常。
