Open Responses：面向多模型提供商的统一响应协议
围绕多提供商 LLM 接口互操作建立的开放规范，统一请求、响应、工具调用、流式事件和智能体循环中的核心对象。
Open Responses agent-protocol agent-interoperability open-source 围绕多提供商 LLM 接口互操作建立的开放规范，统一请求、响应、工具调用、流式事件和智能体循环中的核心对象。
1. 调研缘由
模型供应商的接口都包含消息、工具调用和流式输出，但字段与事件语义并不一致，迁移常被适配代码绑住。Open Responses 在 2026 年 1 月公开，目标是提供面向多供应商的开放响应规范与工具生态。[S1] 它值得关注的不是新增一个客户端，而是能否形成稳定的互操作边界。
2. 简介与产品工作流
Open Responses 以共享 schema 描述请求、输出、流式事件和智能体工作流，并允许映射到多家模型或本地实现。[S1] 使用路径通常是让提供方实现兼容端点，客户端按同一对象模型发出请求，再用验收测试检查行为；路由器也可在这一层切换后端。
3. 团队与资本背景
官网把项目描述为开放、多厂商生态，并列出 NVIDIA、Vercel、OpenRouter、Hugging Face、AWS、OpenAI、vLLM 等支持者。[S1] 这不代表每家实现已覆盖全部可选字段，评估重点仍是兼容测试。
4. 技术基础与生态位
规范把 item 作为上下文的基本单元，可表示消息、函数调用或推理状态；流式输出使用语义事件而非原始文本差量，对象则按进行中、完成或失败等状态推进。[S2] HTTP 请求使用 JSON，流式响应使用事件流；提供商特有 item 通过命名空间扩展。[S2]
5. 市场与外部信号
官网同时提供规范、OpenAPI 参考、验收测试、变更记录与技术章程。[S1] 这比只有概念说明更接近可实施标准。真正的采用信号仍应看不同服务器能否通过同一测试套件，以及常见 SDK、路由器和观测工具是否减少专用适配代码。
6. 公开评价与主要分歧
统一接口能降低基础消息和工具调用的迁移成本，但抽象层也可能只覆盖各家能力的交集。Open Responses 允许提供商扩展 item，可减轻“最低公分母”问题，同时会带来可移植性折损。[S2] 因此兼容不能只看请求成功，还要检查事件顺序、错误语义和工具状态。
7. 同类对比
它与 MCP 的职责不同：MCP偏向模型或智能体连接外部工具与数据，Open Responses 偏向客户端如何调用模型提供方并接收输出。与单一厂商 API 相比，它强调跨提供商 schema；与简单兼容代理相比，它还定义 item 生命周期、语义流事件和验收路径。[S1][S2]
8. 信息缺口与后续观察
规范仍会演进，提供商扩展、推理内容披露和新增传输方式可能造成版本差异。采用前应固定规范版本，列出必需与可选能力，并准备厂商特性逃生口。还需观察治理决策、破坏性变更策略和验收测试是否覆盖真实长连接与失败恢复。
9. 归纳洞察 ★
Open Responses 最适合先用于可替换性要求高的模型网关，而不是一次性抹平所有厂商差异。可选两家后端，用同一组文本、工具调用和流式中断用例做契约测试；记录成功率、事件一致性、错误映射和专有字段占比。只有专有分支足够少，统一层才真正降低维护成本。
10. 来源与更新时间
更新时间：2026-08-12。