Open Responses：面向智能体时代的开放推理API新标准

原文链接： https://huggingface.co/blog/open-responses
作者： Shaun Smith， Ben Burtenshaw， Merve， Pedro Cuenca

什么是 Open Responses？

Open Responses 是一个新的开放推理标准。由 OpenAI 发起，开源 AI 社区构建，并由 Hugging Face 生态系统支持，它基于 Responses API，专为智能体的未来而设计。本文将介绍 Open Responses 的工作原理以及开源社区为何应予以关注。

注：已有一个 Open Responses 中文镜像站点 openresponses-cn.top，提供了文档的中文翻译，方便学习。

聊天机器人的时代正在过去，智能体正主导着推理工作负载。 开发者越来越多地转向能够推理、规划并在长时间范围内行动的自主系统。尽管发生了这种转变，但生态系统中大部分仍在使用 Chat Completion 格式，该格式专为轮次对话设计，对于复杂的智能体用例而言已显得力不从心。

Responses 格式旨在解决这些限制，但它本身是封闭的，并未被广泛采纳。因此，Chat Completion 格式仍然是事实上的标准，尽管存在更优的替代方案。

智能体工作流的需求与根深蒂固的接口之间的这种不匹配，催生了对一个开放推理标准的迫切需求。未来几个月，社区将与推理提供商合作，共同实施并调整 Open Responses，使其成为一个能够实际取代 Chat Completion 的共享格式。

Open Responses 建立在 OpenAI 于 2025 年 3 月推出的 Responses API 基础之上，它用一套一致的方式取代了现有的 Completion 和 Assistants API，能够：

• 生成文本、图像和 JSON 结构化输出
• 通过基于任务的单独端点创建视频内容
• 在提供商端运行智能体循环，自主执行工具调用并返回最终结果

深入理解 Open Responses

Open Responses 对 Responses API 进行了扩展并开源，使开发者和路由提供商更容易实现互操作，并就共同利益展开协作。

其关键特性包括：

• 默认无状态，支持需要加密推理的提供商
• 标准化的模型配置参数
• 流式传输被建模为一系列语义事件，而非原始文本或对象增量
• 可通过特定于某些模型提供商的可配置参数进行扩展

使用 Open Responses 须知

我们将简要探讨影响大多数社区成员的核心变化。若想深入了解规范，请查阅 Open Responses 文档。

客户端如何请求 Open Responses？

客户端对 Open Responses 的请求与现有的 Responses API 类似。以下演示使用 curl 向遵循 Open Responses API 模式的路由代理端点发出的请求。

curl https://evalstate-openresponses.hf.space/v1/responses \\
   -H "Content-Type: application/json" \\
   -H "Authorization: Bearer $HF_TOKEN" \\
   -H "OpenResponses-Version: latest" \\
   -N \\
   -d '{
         "model": "moonshotai/Kimi-K2-Thinking:nebius",
         "input": "explain the theory of life"
       }'

推理客户端和提供商的改变

已经支持 Responses API 的客户端可以相对轻松地迁移到 Open Responses。主要变化涉及推理内容的暴露方式：

扩展的推理可见性： Open Responses 为推理项目形式化了三个可选字段：

• content （原始推理跟踪）
• encrypted_content （提供商特定的保护内容）
• summary （从原始跟踪中清理得出的摘要）

此前，OpenAI 模型仅暴露 summary 和 encrypted_content。使用 Open Responses，提供商可以通过 API 选择性地暴露其原始推理过程。

对于之前仅返回摘要和加密内容的提供商，迁移后，客户端将有机会在所选提供商支持时接收并处理原始推理流。

此外，它还支持实现更丰富的状态更改和有效负载，包括更详细的可观察性。例如，托管的代码解释器可以发送特定的 interpreting 状态，以在长时间运行的操作期间改善智能体与用户的可见性。

对于模型提供商而言，如果已遵守 Responses API 规范，那么实施 Open Responses 的更改应该是直接的。对于路由器，现在有机会标准化一致的端点，并在需要时支持配置选项进行自定义。

随着提供商的持续创新，某些功能将在基础规范中得到标准化。

总之，迁移到 Open Responses 将使推理体验更加一致，并提升质量，因为传统 Completions API 中未记录的扩展、解释和变通方法在 Open Responses 中得到了规范化。

以下示例展示如何流式传输推理内容：

{
  "model": "moonshotai/Kimi-K2-Thinking:together",
  "input": [
    {
      "type": "message",
      "role": "user",
      "content": "explain photosynthesis."
    }
  ],
  "stream": true
}

获取 Open Response 与使用 OpenAI Responses 进行推理增量的区别如下：

// 开放权重模型流式传输原始推理
event: response.reasoning.delta
data: {"delta": "User asked: 'Where should I eat...' Step 1: Parse location..."}

// 具有加密推理的模型发送摘要，或由开放权重模型作为便利发送
event: response.reasoning_summary_text.delta
data: {"delta": "Determined user wants restaurant recommendations"}

Open Responses 在路由中的应用

Open Responses 区分了“模型提供商”（提供推理服务的一方）和“路由器”（在多个提供商之间进行编排的中间方）。

客户端现在可以在发出请求时指定提供商以及提供商特定的 API 选项，从而允许中间路由器在上游提供商之间灵活地编排请求。

工具支持

Open Responses 原生支持两类工具：内部工具和外部工具。

• 外部托管工具在模型提供商的系统之外实施。例如，由客户端执行的函数或 MCP 服务器。
• 内部托管工具在模型提供商的系统内实施。例如，OpenAI 的文件搜索或 Google Drive 集成。模型调用、执行并完全在提供商的基础设施内检索结果，无需开发者干预。

子代理循环

Open Responses 形式化了智能体循环。这通常由推理、工具调用和响应生成的重复循环组成，使模型能够自主完成多步骤任务，这正是现代 人工智能 应用的核心。

循环操作如下：

1. API 接收用户请求并从模型采样。
2. 如果模型发出工具调用，API 会执行它（内部或外部）。
3. 工具结果被反馈给模型以继续推理。
4. 循环重复，直到模型发出完成信号。

对于内部托管工具，提供商管理整个循环：执行工具，将结果返回给模型，并流式传输输出。这意味着多步骤工作流（例如“搜索文档、总结发现、然后起草电子邮件”）可以通过单个请求完成。

客户端通过 max_tool_calls 限制迭代次数，并通过 tool_choice 约束可调用工具，从而控制循环行为：

{
  "model": "zai-org/GLM-4.7",
  "input": "Find Q3 sales data and email a summary to the team",
  "tools": {...},
  "max_tool_calls": 10,
  "tool_choice": "auto"
}

响应将包含所有中间项目：工具调用、结果和推理过程。

总结

Open Responses 扩展并改进了 Responses API，提供了更丰富、更详细的内容定义、更好的兼容性以及更多部署选项。它还提供了一种在主推理调用期间执行子代理循环的标准方法，为 AI 应用程序开启了更强大的功能之门。

再次提醒，可通过 Open Responses 中文镜像站点 openresponses-cn.top 获取文档的中文翻译。

希望本文能帮助你理解这一即将到来的重要标准。如果你想了解更多关于 API 设计、智能体开发或其他技术话题，欢迎在 云栈社区 与其他开发者交流探讨。