Open Responses：对标 OpenAI Responses API 的多提供商可互操作 LLM 接口规范

Open Responses 是一份开源、厂商中立的 LLM API 规范，灵感来自并兼容 OpenAI 的 /v1/responses API，目标是定义共享的请求/响应模型、流式语义与工具调用模式，让客户端和提供商以一致的形状交换结构化输入输出。项目仓库 github.com/openresponses/openresponses，规范与文档采用 CC-BY-4.0，代码采用 Apache-2.0。本文基于规范页、变更日志、技术章程与 OpenAPI 参考页做一手核对。

一、背景动机：基础能力趋同，各家编码不同

聊天补全（chat/completions）时代之后，LLM API 的基础组件正在趋同：多轮上下文、推理项、工具调用、流式输出、上下文压缩。但每家提供商在字段命名、事件形状、工具回执格式上各自实现，客户端换一家模型就要重写适配层。Open Responses 的动机不是发明新模型能力，而是把已经趋同的部分固化成一份可版本化的共享 schema，把厂商特有功能留给扩展位。

二、是什么：规范 + 参考实现 + 合规测试，而非一个 SDK 产品

仓库内容包括：最新 OpenAPI（public/openapi/openapi.json）、按日期不可变归档的规范版本、CHANGELOG、文档源码、合规测试（bin/compliance-test.ts）。站点提供交互式合规测试页 /compliance 与同名 CLI。它本身不是模型、不是托管服务，而是一份”实现了即兼容”的契约。

三、技术机制：Items 原子单元 + 语义事件 + agentic loop

3.1 Items 作为上下文原子

规范把一切（用户输入、模型输出、推理、工具调用与回执）抽象为 Item，每个 Item 必带 id、type、status（in_progress/completed/failed 等生命周期）。Item 是双向的、按 type 多态、可流式、可扩展；服务端与客户端围绕同一批 Item 重建上下文，previous_response_id 让服务端加载上一轮的输入输出。

3.2 语义流式事件，而非裸文本增量

规范区分两类事件：语义事件（对象级生命周期，如 item added/done）与 delta 事件（内容增量）。传输用 SSE（text/event-stream），终止于 [DONE]；事件的 event 字段必须与 type 匹配，规范建议不使用 id 字段。

3.3 Agentic loop 与工具

模型分析请求、决定直接回答或调用工具；外部托管工具（function、MCP）在提供商之外执行、结果在下一轮回传，内部托管工具由提供商直接执行并流式回传。tool_choice 支持 auto/required/none，也可用结构化对象强制某个 function；allowed_tools 在不改动共享 tools 列表（保住提示缓存）的前提下收窄本次可调用子集，服务端必须硬约束。

3.4 扩展位：实现者前缀

非标准 Item 类型、流式事件、扩展字段必须加实现者 slug 前缀（如 acme:search_result），避免类型名碰撞；依赖扩展字段的轨迹不保证跨厂商可移植，客户端应能忽略未知类型。

3.5 错误与压缩

错误类型含 server_error(500)、invalid_request(400)、not_found(404)、model_error(500)、too_many_requests(429)，错误也可流式并跟随 response.failed。2026-04-24 新增 POST /v1/responses/compact，返回 response.compaction 对象保存长上下文，且不强制规定厂商内部压缩算法。

四、关键数据：可核对的官方口径

五、评测方法批判：规范承诺与落地现实的偏差

1. “兼容 OpenAI Responses”是形状对齐，不是零成本迁移：规范受其启发并保持可互操作，但厂商特有字段、托管工具、缓存语义不在标准内，迁移仍需适配层。
2. 合规测试是契约自检，不是性能基准：30 秒是测试截止时限，不代表 SLA；通过测试只说明覆盖的请求/响应形状达标，不代表延迟、并发或成本优势。
3. 扩展可移植性被明确降级：带前缀的自定义类型”不应被假定为可移植”，跨厂商合同不要建立在非标准字段上——这是规范自己写的边界。
4. WebSocket/compact 是 4 月修订新增：首发版本（2026-01-15）不含，实现方支持度不齐，客户端需做能力探测。
5. 治理是章程设计而非既成事实：TSC、75% 罢免 Lead Maintainer、无厂商多数席位都是章程条款，实际采用广度与厂商参与度需另行核实；官网展示的 NVIDIA、Llama Stack 等是社区背书标识，不等于全部已兼容实现。
6. 规范不含模型质量评测：错误率、回答质量与本规范无关，规范只管接口形状。

六、适用 / 不适用场景

适合：

• 构建需要在多家模型后端之间切换的客户端/网关，希望一套请求结构跑通；
• 自研模型或推理服务（vLLM、LM Studio、Ollama、自定义后端）想提供标准接口、降低接入成本；
• 需要合规测试套件自检实现一致性的平台团队；
• 希望把厂商功能留在前缀扩展、不污染核心 schema 的中立生态。

不适合：

• 只绑定单一厂商、且重度依赖其私有托管工具与缓存特性的应用（规范收益小）；
• 期待规范统一计费、限流、模型目录等商业策略的团队（这些不在标准内）；
• 把社区背书 logo 当成”已全面兼容”证明的采购决策。

七、客观分析：优势与局限

优势：

1. 抓住趋同层：Items、语义事件、工具 loop、压缩都是高频公共需求，版本化 schema 减少适配重复；
2. 扩展克制：slug 前缀把私有功能隔离在标准之外，避免核心 schema 膨胀；
3. 治理中立：席位归个人、无单一厂商多数、资产由中立实体托管，CC-BY/Apache 双协议清晰；
4. 自带合规测试：Web UI 与 CLI 两套入口，CI 可跑；
5. 传输务实：SSE 为主，4 月补 WebSocket，不强制替换现有 HTTP 栈。

局限：

1. 生态早期：采纳厂商与实现数量需自行核实，规范文本不等于市场事实；
2. 私有能力仍需适配：托管工具、推理加密内容、缓存键等厂商差异无法靠标准消除；
3. 双修订版本并存：首发与 4 月修订能力不同，客户端要处理版本协商；
4. 不解决模型层问题：质量、价格、速度由提供商决定；
5. 文档参考页夹杂示例模型名（如 gpt-5.2），属示例而非规范要求。

八、它意味着什么 / 谁该关注

Open Responses 走的是”接口标准化”路线：像 HTTP 之于 Web，试图在 LLM API 层沉淀一份厂商中立的契约，把竞争留在模型本身而非字段命名。值得关注：做多模型网关/客户端的基础设施团队、自研推理服务想降低接入摩擦的工程师、MCP/Agent 平台需要统一工具回执格式的作者。采用前建议先跑 /compliance 确认目标后端覆盖度，再把私有能力放在前缀扩展里。

参考来源

• Open Responses 官网与规范 2026-01-15
• Changelog（2026-04-24 WebSocket/compact 修订）
• Technical Charter 治理章程
• Reference（POST /v1/responses 与 OpenAPI）
• GitHub 仓库 openresponses/openresponses
• Koala 项目库条目 #1530