Open Responses 是什么：一个面向智能体的开放推理标准

Open Responses 是一个全新的开放推理标准。由 OpenAI 发起，由开源 AI 社区构建，并获得 HF Mirror 生态系统的支持，Open Responses 基于 Responses API，专为 Agent 的未来而设计。在这篇博文中，我们将探讨 Open Responses 如何运作，以及为什么开源社区应该使用 Open Responses。

聊天机器人的时代早已远去，如今 Agent 主宰了推理工作负载。开发者正转向能够进行长时间推理、规划和行动的自主系统。尽管发生了这一转变，生态系统中大部分仍然使用 Chat Completion 格式，该格式是为基于轮次的对话而设计的，无法满足 Agent 用例的需求。Responses 格式旨在解决这些局限，但它是封闭的，且未被广泛采用。尽管存在替代方案，Chat Completion 格式仍然是事实上的标准。

Agent 工作流需求与根深蒂固的接口之间的这种错配，催生了对开放推理标准的需求。在接下来的几个月里，我们将与社区和推理提供商合作，将 Open Responses 实现并适配为一种共享格式，使其在实际应用中能够取代 chat completions。

Open Responses 建立在 OpenAI 通过其于 2025 年 3 月推出的 Responses API 所设定的方向之上，该 API 取代了现有的 Completion 和 Assistants API，提供了一致的方式来：

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

什么是 Open Responses？

Open Responses 扩展并将 Responses API 开源，使构建者和路由提供商能够更轻松地互操作，并在共同利益上开展协作。

一些关键要点包括：

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

使用 Open Responses 构建需要了解什么？

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

向 Open Responses 发起的客户端请求

向 Open Responses 发起的客户端请求与现有的 Responses API 类似。下面我们使用 curl 演示一个向 Open Responses API 发起的请求。我们调用的是一个代理端点，它使用 Open Responses API schema 路由到 Inference Providers。

 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 暴露其原始推理内容。从先前仅返回摘要和加密内容的提供商迁移过来的客户端，现在有机会在所选的提供商支持时接收并处理原始推理流。

实现更丰富的状态变更和负载，包括更详细的可观测性——例如，托管的 Code Interpreter 可以发送特定的 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 获取推理增量的区别：

// Open weight models stream raw reasoning
event: response.reasoning.delta
data: { "delta": "User asked: 'Where should I eat...' Step 1: Parse location...", ... }

// Models with encrypted reasoning send summaries, or sent as a convenience by Open Weight models
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 将智能体循环形式化，该循环通常由推理、工具调用和响应生成的重复周期组成，使模型能够自主完成多步骤任务。

图片来源：openresponses.org

该循环的运行方式如下：

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

对于内部托管的工具，提供商管理整个循环；执行工具、将结果返回给模型，并流式传输输出。这意味着像“搜索文档、总结发现，然后起草一封电子邮件”这样的多步骤工作流只需一次请求。

客户端通过 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": 5,
  "tool_choice": "auto"
}

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

后续步骤

Open Responses 扩展并改进了 Responses API，提供了更丰富、更详细的内容定义、兼容性和部署选项。它还提供了一种在主推理调用期间执行子智能体循环的标准方式，为 AI 应用开辟了强大的能力。我们期待与 Open Responses 团队以及整个社区携手推进该规范的未来发展。

你现在就可以通过 HF Mirror Inference Providers 试用 Open Responses。我们在 HF Mirror Spaces 上提供了可供使用的早期访问版本——现在就搭配你的客户端和 Open Responses 合规工具试试吧！