Codex 接入硅基流动的兼容性检查

当前结论（2026-08 核对）：不能作为已验证的 Codex 原生 provider。 SiliconFlow 官方公开文档主要提供 Chat Completions；对公开 /v1/responses 的匿名路由探测返回 404。不要继续写配置。

教程目标

正确判断聚合模型平台的“OpenAI 兼容”范围，避免把模型丰富等同于协议兼容。

第 1 步：分开检查三件事

1. 平台是否有目标模型。
2. 平台是否提供 POST /v1/responses。
3. 该端点是否兼容 Codex 需要的流式事件与工具调用。

只有三项都通过，才进入配置与账号实测。当前第二项没有通过。

第 2 步：核对官方来源

只使用 SiliconFlow 官方 API 文档和控制台模型列表。Chat Completions 示例、OpenAI SDK 的 chat.completions.create 或 /chat/completions 都不能作为 Responses 支持证据。

路由探测只能辅助判断：404 是明确的停止信号；401 也不能证明完整兼容。

第 3 步：不要让转换层伪装成官方支持

第三方网关可以转换协议，但这改变了数据路径、故障点和信任边界。使用前必须确认：

• 源码与发布包能否对应。
• API Key 是否只在本机或自有服务器处理。
• 是否记录提示词、源码、响应和工具参数。
• 是否完整支持流式事件、函数调用和错误语义。
• 如何固定版本、限制网络、撤销 Key 和回滚。

第 4 步：未来支持后的最小测试

请先核对 SiliconFlow 官方 Responses API 文档，不要修改配置。
确认端点、模型、认证和流式事件后，生成只含环境变量名的 config.toml 草稿。
先完成最小响应，再完成只读项目分析；失败时保留状态码和脱敏错误，不修改业务文件。

真实验收还应包含工具调用、多轮响应、超时与限流，并检查 Git 工作区无变化。

常见误区

• 模型列表有 DeepSeek/Qwen，就认为任何客户端都能接：模型与协议是两层。
• base_url 后手写 /responses：不存在的路由不会因配置而出现。
• 只测一句聊天：不能覆盖 Codex 工具调用链。
• 把 Key 交给在线转换网站：密钥和源码可能被记录。

验收结果

1. 已确认当前公开 Responses 路由与官方文档不足以支持原生配置。
2. 没有写入或宣传未经验证的 SiliconFlow Codex provider。
3. 第三方转换层被视为独立、需审查的安全组件。
4. 知道未来必须完成官方文档与真实账号的端到端验收。

参考：https://docs.siliconflow.cn/

下一篇看：使用第三方 Codex 工具前的安全检查。