Feature request / 功能建议
你好，团队：
我想提一个功能建议：希望智谱官方 API endpoint 支持 OpenAI 兼容的 /responses 接口。
这个能力现在越来越重要，因为 OpenAI Codex 已经在逐步弃用 chat/completions，并转向 responses 作为推理模型、多轮工作流、工具调用型
agent 场景的主要接口：
openai/codex#7782
Codex 维护者在讨论中明确提到，chat/completions 属于 GPT-3.5 时代的旧协议，并不适合今天这种 agentic coding、reasoning、tool-rich
workflow 的场景。Codex 正在围绕 /responses 进行标准化，这意味着如果一个模型提供方不支持该接口，后续接入 Codex 的成本会越来越高，甚
至无法稳定兼容。
从几个角度看，我认为智谱官方支持 `/responses`` 会是一个非常有价值的能力：
- 直接提升 Codex 兼容性
如果智谱官方 endpoint 支持 /responses，那么 GLM 模型接入 Codex 的门槛会显著下降。对于希望在 Codex 中使用 GLM 的开发者来说，这是
最关键的一步。
- 进入正在形成的 Codex 生态
Codex 正在成为 AI 编程和 agent 工作流的重要入口之一。支持 /responses，意味着智谱可以更顺畅地进入这类开发生态，而不是因为协议不
兼容被排除在外。
- 大幅降低开发者切换和试用成本
很多团队已经围绕 OpenAI 兼容接口搭建了基础设施。如果智谱支持 /responses，开发者几乎可以以更低成本把 GLM 纳入现有的 coding
agent、CLI 和自动化工作流进行评估与使用。
- 更适合推理、工具调用和多轮交互
/responses 本身就是为更复杂的推理、多轮状态管理、工具增强流程设计的。今天一个 coding model 是否“好用”，很大程度上取决于它能否在
这类 agent 场景中稳定工作。接口层面的支持，不只是“兼容”，而是直接影响产品可用性。
- 这是一个实际的商业机会
如果 GLM 能通过官方 /responses endpoint 良好兼容 Codex，那么它就有机会承接一部分原本流向其他模型的开发者流量。对很多用户来说，
模型质量、成本、区域可达性、合规性、部署灵活度都可能成为选择 GLM 的理由。而协议兼容，正是让这些优势真正转化为市场份额的前提。
- 官方支持优于社区代理或兼容层
虽然可以通过代理、网关、适配层来间接兼容，但这类方案通常会引入额外延迟、稳定性问题和维护负担。对于生产环境和团队级使用来说，官
方原生支持会可靠得多。
我建议的范围可以是：
- 提供官方 OpenAI 兼容的 /responses endpoint
- 尽量兼容主流 OpenAI 客户端所依赖的常见字段和流式行为
- 对 GLM 特有差异做清晰文档说明
- 最好补充一个 Codex 或类似 agent 编程工具的接入示例
即使第一阶段只是做一个以兼容性为目标的版本，也会非常有价值。
这不只是增加一个接口，而是一次高杠杆的生态入口建设。
如果智谱能补齐这个能力，我相信 GLM 在 Codex 相关开发者生态里，一定有机会拿到一部分市场份额。
感谢考虑这个需求。
Motivation / 动机
目前仅支持 /chat/completions 接口，这个接口目前已经被codex弃用。codex目前采用 /responses 接口
Your contribution / 您的贡献
None
Feature request / 功能建议
你好，团队：
我想提一个功能建议：希望智谱官方 API endpoint 支持 OpenAI 兼容的 /responses 接口。
这个能力现在越来越重要，因为 OpenAI Codex 已经在逐步弃用 chat/completions，并转向 responses 作为推理模型、多轮工作流、工具调用型
agent 场景的主要接口：
openai/codex#7782
Codex 维护者在讨论中明确提到，chat/completions 属于 GPT-3.5 时代的旧协议，并不适合今天这种 agentic coding、reasoning、tool-rich
workflow 的场景。Codex 正在围绕 /responses 进行标准化，这意味着如果一个模型提供方不支持该接口，后续接入 Codex 的成本会越来越高，甚
至无法稳定兼容。
从几个角度看，我认为智谱官方支持 `/responses`` 会是一个非常有价值的能力：
如果智谱官方 endpoint 支持 /responses，那么 GLM 模型接入 Codex 的门槛会显著下降。对于希望在 Codex 中使用 GLM 的开发者来说，这是
最关键的一步。
Codex 正在成为 AI 编程和 agent 工作流的重要入口之一。支持 /responses，意味着智谱可以更顺畅地进入这类开发生态，而不是因为协议不
兼容被排除在外。
很多团队已经围绕 OpenAI 兼容接口搭建了基础设施。如果智谱支持 /responses，开发者几乎可以以更低成本把 GLM 纳入现有的 coding
agent、CLI 和自动化工作流进行评估与使用。
/responses 本身就是为更复杂的推理、多轮状态管理、工具增强流程设计的。今天一个 coding model 是否“好用”，很大程度上取决于它能否在
这类 agent 场景中稳定工作。接口层面的支持，不只是“兼容”，而是直接影响产品可用性。
如果 GLM 能通过官方 /responses endpoint 良好兼容 Codex，那么它就有机会承接一部分原本流向其他模型的开发者流量。对很多用户来说，
模型质量、成本、区域可达性、合规性、部署灵活度都可能成为选择 GLM 的理由。而协议兼容，正是让这些优势真正转化为市场份额的前提。
虽然可以通过代理、网关、适配层来间接兼容，但这类方案通常会引入额外延迟、稳定性问题和维护负担。对于生产环境和团队级使用来说，官
方原生支持会可靠得多。
我建议的范围可以是：
即使第一阶段只是做一个以兼容性为目标的版本，也会非常有价值。
这不只是增加一个接口，而是一次高杠杆的生态入口建设。
如果智谱能补齐这个能力，我相信 GLM 在 Codex 相关开发者生态里，一定有机会拿到一部分市场份额。
感谢考虑这个需求。
Motivation / 动机
目前仅支持 /chat/completions 接口，这个接口目前已经被codex弃用。codex目前采用 /responses 接口
Your contribution / 您的贡献
None