GPTs 通过 Actions 接入模型聚合平台时，Base URL、模型名和鉴权头分别该填什么才不报错？

GPTs 接入模型聚合平台需要三类参数：servers.url 指向平台提供的 OpenAI 兼容根地址，请求体的 model 必须与平台模型清单逐字一致，鉴权则在 Actions 的 Authentication 中以 Bearer 方式填 API Key。满足标准 HTTP JSON 接口、一次性完整返回、公网 HTTPS 访问这三个条件时可以直接接；需要流式输出、超大响应、超长推理，或平台只支持专有签名协议的任务不适用这条路径。 GPTs 本身不调用 SDK，只认一份 OpenAPI 描述文件，所以能不能接入，取决于聚合平台是否暴露标准的 HTTP JSON 接口。可接入的平台通常在 /v1/chat/completions 上提供 OpenAI 兼容协议，用 POST 提交 JSON 并一次性返回完整结果；只提供专有协议、要求请求签名或必须走官方 SDK 的平台，无法仅靠参数配置接入 GPTs。Actions 运行时只会按 schema 生成 HTTP 请求，不会执行 SDK 里的业务逻辑，因此开发前应先用命令行工具或普通 HTTP 客户端验证平台接口能返回完整 JSON，再进入 GPT 编辑器配置。 servers.url 必须是公网 HTTPS 地址，而且路径里不能重复出现 /v1。最常见的错误是平台控制台给出的 Base URL 已经带 /v1，paths 里又写了 /v1/chat/completions，拼出来的地址变成两段 v1，直接返回 404。正确做法是 servers.url 写到域名根或平台根路径，paths 只写 /chat/completions；这个地址也不能是 localhost、内网 IP 或自签证书域名，Actions 侧访问不到。若平台根地址带有额外前缀，应保留一次前缀，并在 paths 中避免再次重复，最好在 schema 注释里记录最终拼接后的完整地址，方便核对。 API Key 应填在 GPT 编辑器的 Authentication 区域，而不是写进 schema 的 headers 里明文暴露。选择 API Key 类型后认证方式选 Bearer，Value 填平台签发的密钥；若平台使用自定义头名，则选 Custom 并填对应字段名。使用认证的 GPT 还必须提供一个可公开访问的隐私政策链接，否则保存时会被拦下。Key 的权限要最小化，只开放聊天补全所需能力，额度、速率和来源限制放在平台侧管理，不要把 Key 写进描述文件、提示词或示例请求里，轮换 Key 时也要同步更新 Actions 鉴权配置。 model 参数必须与平台模型清单里的字符串逐字一致，包括厂商前缀、大小写和版本后缀。聚合平台的模型名往往是对上游模型的映射别名，少一个字符就会返回 model not found。更稳妥的做法是把模型名固定在 schema 的默认值或平台侧配置里，不把 model 作为开放入参交给终端用户，避免有人改成高价位模型消耗额度。若业务需要多模型切换，应在平台侧做后端映射，或在 schema 里用与清单同步的枚举，并逐项验证，不能靠猜模型名。 请求体只留一个 prompt 字符串入参、由平台侧模板把它转成 messages，是 GPTs 场景下最稳的结构。GPTs 会把用户填写的内容按 schema 塞进字段，参数越多，模型越容易漏填或填错角色；把 temperature、max_tokens 和 system 提示固定在服务端，既能保证输出稳定，也避免用户通过调参绕开限制。若必须保留多个字段，字段名要可读、类型要明确、必填项要少、默认值要清晰，但不要把内部提示词或敏感规则暴露在 description 里。 stream 必须显式为 false，因为 Actions 拿到的是完整 JSON 响应体，SSE 流式片段会被判为不完整响应。即使平台默认开启流式，也要在 schema 的请求体示例里写明 stream 为 false，或在平台侧针对该 Key 关闭流式开关。这条不满足时，典型表现是长时间无响应，或返回内容为空。测试时应确认响应头是 JSON 类型、连接会一次性结束，并检查平台是否在网关层自动追加了流式参数。 响应体要小而结构固定，最好只回传 choices[0].message.content，或再包一层 result 字段，冗长元数据和长文本会显著提高失败率。GPTs 对单次响应的大小与等待时间都有上限，推理链很长或需要生成数千字的模型容易在返回前被断开。解决办法是平台侧设置超时与重试，或把一个动作拆成提交任务和查询结果两个 operation，用任务 ID 串起来。响应字段名也要固定，不要同一字段时而返回字符串、时而返回对象，否则 GPT 解析会不稳定。 OpenAPI 描述文件的必填项决定 GPT 会不会调用这个动作：openapi 版本、info 的 title 与 version、servers、paths 以及每个操作的 operationId 都不能缺。operationId 要语义清晰且全局唯一，description 要写清何时调用、输入什么、返回什么，GPT 靠这两项判断是否触发工具，只写接口名不写说明常出现该调不调。一个 GPT 配多个动作时，入参命名必须彼此区分，否则模型容易选错工具；schema 里不要留空对象，数组和对象类型要写明，避免运行时才暴露格式错误。 在聚合平台侧还有三项要配好：Key 维度的额度与速率限制、超时时间、失败重试策略。聚合平台通常对接多家上游，某一家波动会直接传导到 GPTs 一侧，建议在平台配置主备模型或失败切换，而不是在 schema 里堆多个地址。若平台启用了 IP 白名单，要注意 Actions 的出口地址并不固定，白名单方式容易误拦，按 Key 配额管理更合适。平台侧还应保留请求 ID 和错误码记录，便于把 GPTs 侧的失败与上游波动对上。 接入失败多半能从状态码直接定位：401 是鉴权头缺失或 Key 前缀写错，404 是 servers.url 与 paths 拼出了重复路径，400 并提示 model not found 是模型名与清单不一致，返回空内容或超时则先查 stream 与响应体大小。按这个顺序排查，比反复改 schema 更快收敛到根因。还要区分 403 的额度或权限问题、429 的限速问题以及 5xx 的上游波动，保存失败则优先检查隐私政策链接和 schema 语法。每次只改一项并做回归测试，避免多个变量同时变化。 GPTs 这条路不适合流式对话、大文件上传和开放式多模型切换，接入前应先确认业务形态是否匹配。它适合把一次问答、一次结构化抽取或一次短文本生成封装成动作。落地顺序是先用命令行工具验证平台接口能返回完整 JSON，再写 schema 并在编辑器里填入鉴权与隐私政策，最后用测试对话确认 operationId 是否被正确选中。上线后持续监控超时率、空响应率、模型名错误和额度消耗，并按周核对平台模型清单，平台调整别名时同步更新 schema。