2026年AI开发新标准来了!Chat Completion已过时,Open Responses横空出世!
2026年AI开发新标准来了!Open Responses专为智能体时代打造,告别Chat Completion的局限,解锁原始推理流、自主工具调用等强大能力。本文带你深入理解这个将改变AI开发生态的开放标准,开发者不容错过!
2026年AI开发新标准来了!Chat Completion已过时,Open Responses横空出世!
原文链接: https://huggingface.co/blog/open-responses
作者: Shaun Smith, Ben Burtenshaw, Merve, Pedro Cuenca
译者: 倔强青铜三
前言
大家好,我是倔强青铜三。欢迎关注我,微信公众号:倔强青铜三。欢迎点赞、收藏、关注,一键三连!!!
什么是 Open Responses?
Open Responses 是一个新的开放推理标准。由 OpenAI 发起,开源 AI 社区构建,并由 Hugging Face 生态系统支持,Open Responses 基于 Responses API,专为智能体的未来而设计。在这篇博客中,我们将了解 Open Responses 的工作原理以及为什么开源社区应该使用它。
我已经弄了一个
Open Responses中文镜像站点openresponses-cn.top,把Open Responses文档进行了中文翻译,方便大家学习!
聊天机器人的时代已经过去,智能体主导着推理工作负载。 开发者正在转向能够推理、规划并在长时间范围内行动的自主系统。尽管发生了这种转变,但生态系统中大部分仍在使用 Chat Completion 格式,该格式专为轮次对话而设计,对于智能体用例来说力不从心。
Responses 格式旨在解决这些限制,但它是封闭的,没有被广泛采用。Chat Completion 格式仍然是事实上的标准,尽管存在替代方案。
智能体工作流需求与根深蒂固的接口之间的这种不匹配,推动了对开放推理标准的需求。在未来几个月里,我们将与社区和推理提供商合作,实施并调整 Open Responses 为一个共享的格式,实际上能够取代聊天完成。
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 发出的请求。我们正在调用一个代理端点,该端点使用 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.deltadata: {"delta": "User asked: 'Where should I eat...' Step 1: Parse location..."}
// 具有加密推理的模型发送摘要,或由开放权重模型作为便利发送event: response.reasoning_summary_text.deltadata: {"delta": "Determined user wants restaurant recommendations"}Open Responses 用于路由
Open Responses 区分”模型提供商”(提供推理的人)和”路由器”(在多个提供商之间编排的中间人)。
客户端现在可以在发出请求时指定提供商以及提供商特定的 API 选项,允许中间路由器在上游提供商之间编排请求。
工具
Open Responses 原生支持两类工具:内部和外部。
外部托管工具在模型提供商的系统之外实施。例如,要执行的客户端功能或 MCP 服务器。内部托管工具在模型提供商的系统内。例如,OpenAI 的文件搜索或 Google Drive 集成。模型调用、执行并完全在提供商的基础设施内检索结果,无需开发人员干预。
子代理循环
Open Responses 形式化了智能体循环,它通常由推理、工具调用和响应生成的重复循环组成,使模型能够自主完成多步骤任务。
循环操作如下:
- 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": 10, "tool_choice": "auto"}响应包含所有中间项目:工具调用、结果、推理。
总结
Open Responses 扩展并改进了 Responses API,提供更丰富和更详细的内容定义、兼容性和部署选项。它还提供了一种在主推理调用期间执行子代理循环的标准方法,为 AI 应用程序打开强大的功能。
我已经弄了一个
Open Responses中文镜像站点openresponses-cn.top,把Open Responses文档进行了中文翻译,方便大家学习!
欢迎关注我的微信公众号:倔强青铜三,获取更多 AI 自动化和开发技巧分享!