中转站支持 Responses API 吗？迁移前要测这些点

Responses API 把文本、工具、图片、多模态输入统一到一个接口里，对开发者很方便。但中转站是否真正支持，不能只看 `/v1/responses` 这个路径是否存在。 第一，测试最小请求。用简单 input 发起请求，确认返回结构里是否有 id、status、output、usage 等关键字段。如果只是把 Chat Completions 的结果包了一层，后续复杂能力很可能不稳定。 第二，测试流式返回。Responses API 的 stream 事件和传统 Chat Completions 不一样。你要看事件类型是否完整、增量文本是否正常、结束事件是否明确、usage 是否能返回。如果流式格式错了，前端或 SDK 很容易解析失败。 第三，测试工具调用。很多中转站普通对话能跑，但工具调用会失败。你可以定义一个简单工具，比如 get_time，让模型触发工具调用。真正兼容的接口应该能返回结构化工具调用，而不是把工具参数当普通文本吐出来。 第四，测试图片输入。如果站点声称支持多模态，就要用一张小图测试。常见问题包括 base64 不支持、URL 图片不支持、content type 写法不兼容、模型名映射错误。 第五，测试错误格式。迁移到 Responses API 后，业务代码经常依赖错误体判断重试、降级或提示用户。如果中转站错误格式混乱，线上排障会很难。至少要确认模型不存在、余额不足、参数错误、上游超时这几类错误能被区分。 第六，测试模型映射。某些站会把 Responses API 请求转到旧的 Chat Completions 模型，短文本看不出来，一到工具、多模态、结构化输出就露馅。迁移前要用目标业务真实场景跑一遍。 结论是：Responses API 迁移不是换一个 URL。对中转站来说，它考验的是完整兼容层。最稳妥的做法是先保留旧接口兜底，逐站检测 Responses API 能力，确认稳定后再切正式流量。