GPTs 怎么通过 Actions 添加第三方模型服务商接口，OpenAPI Schema、鉴权方式和调用触发条件该怎么配？

GPTs 添加第三方模型服务商接口，靠的不是换掉底层模型，而是在自定义 GPT 的配置页里新建一个 Action，把对方提供的 HTTPS 接口按 OpenAPI 规范描述成可被调用的工具；如果你想要的是让对话框本身由第三方模型生成，这条路走不通，应该改用 API 自建应用。 理解这个边界要先看 Actions 的机制：一次调用由三部分组成，一份 OpenAPI 描述文件告诉平台有哪些操作和参数，一套认证配置让平台在发请求时带上凭证，一段调用策略让模型自己判断该不该用。模型并不会“读”你的接口文档，它只根据每个 operation 的 summary 和 description 决定是否触发，然后把参数拼成 JSON 发出去，再把响应体当作工具结果写进回答。 OpenAPI 描述的第一处硬性要求是 servers 字段里的地址必须是公网可达的 HTTPS 域名，自签证书、内网地址、带端口的内网穿透一律不行。operationId 在同一份描述里必须唯一且语义清晰，参数能用 required 和 enum 收窄的不要留给模型自由发挥，因为参数越开放，模型编造字段的概率越高。 每个 operation 的 description 要写明何时该用、何时不该用，不能写成产品宣传文案。实操写法是“当用户询问某某类问题时调用，参数为必填”这类指令式语句，同时在 GPT 的 instructions 里补一到两个调用示例，让模型知道触发条件长什么样，这一点比把说明写得华丽有用得多。 响应结构建议统一成扁平 JSON，只返回模型组织回答真正需要的字段。第三方模型服务商的原始响应往往包含用量统计、请求 ID、多层嵌套的 choices 数组，直接透传容易超出平台的响应体积上限而被截断，正确做法是在代理层裁剪成一段文本加少量状态字段。 认证方式有三类可选：无认证、API Key（放在 Bearer 头或自定义请求头）、OAuth。密钥只能填在认证配置里，绝不能写进 OpenAPI 描述文件或 instructions，因为描述文件会随 GPT 分享出去；更稳妥的做法是让 Actions 只认一把自建网关的密钥，真正的上游模型厂商密钥留在服务端，任何情况下都不经过前端参数传递。 自建一层代理是这类接入的常规做法，原因是 Actions 的调用是无状态单次 HTTP，不支持流式返回，也不帮你保存多轮上下文。代理层要替它完成鉴权、限流、超时重试、错误码归一，并把外部接口需要的 messages 数组按本次请求从参数里拼装出来，上下文长度和会话拼接规则都由你的服务端控制。 调用触发失败最常见的原因不是接口写错，而是描述写得太模糊。模型在“用户问了一个相关问题”时是否调用 Action，取决于描述里的语义边界，所以要把“只处理 X、不处理 Y”写进 description，并用一次完整的预览测试确认触发行为；测试顺序是先手动执行单个 operation 看返回，再用自然语言提问看是否会触发，最后构造缺参数、超时、鉴权失败三类异常。 排错时优先看三件事：平台侧报的是描述校验失败还是请求失败，前者多半是 OpenAPI 用了平台不支持的语法子集或 $ref 嵌套过深，后者要看代理层日志里的真实状态码。接口返回 4xx 但 GPT 仍回答“已成功”是常见现象，因为模型只看到你返回的字段，所以代理层要在响应体里显式带一个 success 标志和可读的错误信息，否则模型无从判断。 数据边界必须在动手前确认：走这条路径，用户的输入会被发送到你配置的外部地址，如果对方是境外服务商，就意味着内容出境，需要在 GPT 的描述和关联的隐私政策里说明数据流向。面向企业内部或对数据位置敏感的场景，更合适的选择是接入境内可签合同、可审计的模型服务，或者把 Action 设计成只传必要字段，不传完整对话历史。 成本由两部分组成，Actions 本身不单独计费，实际支出是第三方模型按 token 结算的调用费，加上代理层的算力与带宽。估算时要考虑模型可能重复调用同一个 operation，因此代理层需要做幂等键和短时缓存，对相同的输入直接返回上一次结果，否则用户一句追问就可能触发两到三次计费请求。 最后给出适用判断：把第三方模型当工具用，例如调用一次翻译、摘要、分类接口，用 Actions 接 GPTs 是成立的，代价是复杂度和一次额外的网络往返；要把第三方模型当作主对话引擎，或者需要流式输出、长上下文延续、多模态原生支持，就不该在 GPTs 里绕，而应该在自建应用侧完成模型切换，把配置权留在自己手里。