2026-01-15 发布，Apache-2.0。厂商中立的 LLM API 规范（客户端 ↔ 模型提供方），schema 源自 OpenAI 的一方 API。核心维护者来自 OpenAI、Databricks、Amazon、Hugging Face、Ollama、OpenRouter 等；治理条款写明任何单一厂商不得占据多数核心维护者席位，且所有治理角色由个人而非组织担任。
Open Responses
2026-01-15。由 OpenAI 员工主导维护、schema 源自 OpenAI 一方 API 的开放规范；治理上明确禁止任何厂商独占多数席位。
1 - Open Responses（材料）
按仓库、变更日志与治理文件转述：发起方、治理条款、规范内容，以及发布性质的区分。
主要出处：openresponses/openresponses（Apache-2.0，仓库创建于 2026-01-15）、其 CHANGELOG 与 CONTRIBUTING、以及 openresponses.org 的治理页。
发起方：要区分「谁维护」与「谁发布」
- 变更日志写明：2026-01-15 作为开放的多供应商规范发布。
- 首席核心维护者是 OpenAI 的员工，核心维护者名单覆盖 Databricks、Amazon、Hugging Face、Ollama、OpenAI、OpenRouter。
- 规范 schema 的说明写明：
schema/下的 OpenAPI 源文件复制自 OpenAI 的一方 API。
但要分清：找不到 OpenAI 的官方公告页。OpenAI 官方新闻源里没有这条，站内也只有 Responses API 的功能页。所以正确表述是——由 OpenAI 员工主导维护、schema 源自 OpenAI 一方 API 的开源规范，不是「OpenAI 官方发布的标准」。
治理条款
原文两条值得记：
- 「任何单一厂商不得控制多数核心维护者席位。」
- 「所有治理角色由个人而非组织担任。」
规范内容
- 一个 agentic loop：让模型发出工具调用、接收结果、继续。
- items 作为上下文的原子单位。
- 语义化的流式事件，而不是原始文本增量。
- 默认无状态，可扩展。
后续 2026-04-24 的版本加入 WebSocket 传输、/v1/responses/compact 与 phase 字段。
当时不是什么
它不是 Agent 通信协议。它管的是客户端与模型提供方之间的接口形状，与 MCP（模型↔工具与资源）、A2A（Agent↔Agent）不在同一层。放进时间线时按「模型接口层的标准化尝试」记，不要与工具总线并列。
2 - Open Responses 讲解
模型接口层的标准化：供应商员工主导、schema 来自一家，但用治理条款禁止任何一家独占。
当时解决了什么问题
2024–2025 年，Agent 的接线分三层：模型↔工具（MCP）、Agent↔Agent（A2A）、以及客户端↔模型提供方。前两层有公开协议，第三层一直是一方 API 的形状——换供应商就要改代码。
Open Responses 处理的是第三层：把「一个能发工具调用、收结果、继续」的循环写成规范，并保留语义化的流式事件（而不是让调用方自己去解析文本增量）。
值得单独记的一点：治理设计
发起方是一家厂商的员工，schema 也来自一家的 API——这本来很像「事实标准的单方面输出」。但治理条款写了两条反向约束：任何单一厂商不得占多数维护者席位、治理角色由个人而非组织担任。
这与 A2A 由 Google 发起、MCP 由 Anthropic 发起的路径不同：这一次从一开始就把「不被一家控制」写进了规则。是否奏效要看后续，但作为设计选择，它是 2026 年协议治理的一个新样本。
对后续 LLM 与 Agent 的影响
对时间线的意义在于分层：不要把这条和 MCP / A2A 混成一类。它们各管一层接线，调研方法 里说的「协议」是这一层的统称。
也需要克制：截至 2026 年 9 月，它的采纳仍集中在模型供应商与推理服务侧，没有出现跨厂商的强制采用。按「标准」标签的门槛（多方默认）看，它还没到。它同样不满足「工程化」的门槛（把某项此前只被演示、未被交付的能力第一次交到他人手上），因此本条不带标签。