OpenAI发布Open Responses，取代聊天补全API，标准化LLM接口，解决无状态痛点。它开启智能体时代，赋能有状态、多模态、工具集成AI应用，对企业和开源社区意义深远。
译自：Open Responses vs. Chat Completion: A new era for AI apps
作者：Janakiram MSV
构建可移植、与提供商无关的AI应用是智能体开发（agentic development）的未来。在过去几年中，OpenAI 的 聊天补全API 被认为是与大型语言模型（LLMs）交互的事实标准。主要的模型提供商、开源服务平台和AI网关都支持这一标准。虽然这个API在无状态聊天机器人时代表现良好，但它未能满足智能体（agents）所期望的许多功能。
OpenAI 已于2025年3月正式从聊天补全API（Chat Completion API）过渡到 响应API。与前者相比，响应API旨在支持原生的有状态对话，以处理多轮交互。通过缓存和推理支持，它显著提高了API的性能。其他功能包括内置工具集成、事件流以及对多模态输入（包括文本和图像）的支持。
最近，OpenAI 与包括 Nvidia、Vercel、OpenRouter、Hugging Face、LM Studio、Ollama 和 vLLM 在内的主要生态系统参与者合作，创建了一个名为 Open Responses 的规范。该规范基于响应API，旨在构建多提供商、可互操作的大型语言模型接口。它定义了一个共享的模式、客户端库和工具层，可以实现与模型类型和模型提供商无关的统一体验。
对于构建智能应用的数据科学家和AI开发者来说，理解 Open Responses 至关重要。其模式与OpenAI生态系统中熟悉的API概念相似，包括用于消息交换的聊天补全、用于函数调用的工具调用、用于实时响应的流式输出以及用于处理文本和图像的多模态输入。
本文通过这些易于理解的类比来解读 Open Responses，为在生产环境中工作的从业者提供清晰的认识。
Open Responses 解决的问题
现代大型语言模型应用已经超越了聊天机器人范式。构建自主智能体（autonomous agents）的开发者需要模型能够进行多步骤推理、自主调用工具并在复杂工作流中维护上下文。然而，生态系统仍然围绕聊天补全（Chat Completions）格式碎片化，该规范最初是为回合制对话设计的，但对于智能体用例来说力不从心。
这种不匹配体现在几个具体问题上：
手动状态管理： 聊天补全（Chat Completions）是无状态的，要求开发者在每次请求中来回传递完整的对话历史记录。
工具编排复杂性： 多步骤工具调用需要在应用代码中手动编写“循环直到完成”逻辑。
推理上下文丢失： 像 o3 和 o4-mini 等模型的推理令牌在回合之间被丢弃，这会降低智能体任务的性能。
缺乏内置功能： 网页搜索、文件检索和代码执行都需要自定义基础设施。
尽管OpenAI在2025年3月通过响应API（/v1/responses）解决了这些限制，但它仍然是一个不透明、专有的接口。Open Responses 定义了一个任何提供商都可以实现的、一致的请求/响应形式。实际上，它允许您在切换后端模型运行时保持一个客户端集成。如果您曾为多个模型提供商维护过多个SDK，您就会明白这消除了多少痛苦。
对于同时使用托管前沿模型和本地开源模型的团队来说，在没有统一API的情况下，管理跨应用的 ब्रांच 逻辑会变得复杂。通过采用 Open Responses，集成可以实现稳定性，只需修改路由即可。这种以稳定契约和可互换实现为核心的方法，对于维护健壮且可维护的真实世界系统至关重要。
聊天补全API与Open Responses对比
要理解这一转变的巨大影响，我们必须比较两种范式的开发者体验和架构足迹。
| 功能 | 传统聊天补全 (v1/chat) | Open Responses (v1/responses) |
|---|---|---|
| 控制逻辑 | 客户端：开发者编写 loops 循环，解析 JSON，处理重试。 | 服务端：开发者声明意图；服务器管理循环/状态机。 |
| 状态 | 无状态：每次请求都必须重新上传历史记录。 | 有状态：previous_response_id 从服务器缓存加载上下文。 |
| 流式传输 | 令牌增量：原始文本块。难以解析的结构。 | 语义事件：类型化事件（tool.start、tool.end、content.add）。 |
| 工具执行 | 客户端驱动：客户端执行，重新提示。高延迟。 | 服务端驱动：服务器执行内部工具；管理外部工具的流程。 |
| 推理 | 隐式：混入内容或通过 thinking 标签实现。 | 显式：专用字段（content、encrypted_content、summary）。 |
| 多模态 | 附加：图像作为URL在文本消息中发送。 | 原生：多态项（Polymorphic Items）支持图像/视频作为一等公民。 |
| 网络流量 | 高：N 步需要 N 次往返。上传完整历史记录。 | 低：N 步只需 1 次请求。仅上传增量输入。 |
生态系统支持
发布合作伙伴代表了对响应API规范的全面生态系统覆盖：
| 提供商 | 实现状态 |
|---|---|
| OpenAI | 完整响应API（原始） |
| Hugging Face | 推理提供商集成，通过 Spaces 早期访问 |
| OpenRouter | 启动合作伙伴，支持“几乎所有现有模型” |
| NVIDIA NIM | 实验性 /v1/responses 端点支持 |
| Ollama | 已在 v0.13.3 中添加，非有状态版本 |
| vLLM | 完整响应API兼容服务器 |
| LM Studio | Open Responses 兼容端点 |
| Azure OpenAI | 通过微软提供完整响应API |
智能体时代的开启
Open Responses 的引入标志着“聊天机器人时代”的终结和“智能体时代”的开启。长期以来，开发者一直面临着“方枘圆凿”的问题，即强行将自主行为整合到对话式API中。由此产生的“智能体地狱”（Agentic Hell）——脆弱、高延迟的客户端循环——阻碍了AI的真正潜力。
Open Responses 解决了这个问题，因为它认识到智能体能力（Agency）是一个基础设施问题，而不仅仅是一个模型能力问题。通过标准化智能体循环（Agentic Loop）、定义多态项（polymorphic Items）并解决状态管理危机，它为构建下一代软件提供了所需的坚实基础。
对于企业而言，道路是清晰的：采用该标准可以使应用具备面向未来的能力，防止供应商锁定，并通过Nvidia NIM和本地模型实现混合云部署。对于开源社区而言，该标准提供了一个号召——一种共享语言，允许模型、工具和路由器的联邦生态系统与专有巨头的单一体系竞争。
新标准为企业和开源社区都带来了明显的益处。
对于企业： 采用该标准是确保应用程序面向未来、防止供应商锁定以及通过利用Nvidia NIM和本地托管模型促进混合云部署的关键。
对于开源社区： 该标准充当统一力量，提供通用语言。这使得模型、工具和路由器的联邦生态系统能够有效地与主要行业参与者的封闭式专有系统竞争。
我们不再仅仅是与文本聊天。我们正在编排认知，而 Open Responses 便是指挥棒。
