大模型 API 的范式转移：从 Chat Completions 到 Responses API

引言2025 年 3 月OpenAI 正式推出 Responses API。一年后的今天它已成为构建 AI Agent 的首选接口。2026 年 3 月OpenAI 进一步扩展了 Responses API加入 Shell 工具和托管容器工作空间。与此同时Assistants API 将于 2026 年 8 月 26 日正式下线。这些变化看似是常规的接口迭代实则揭示了一个更深层的趋势大模型 API 正在从“让模型说话”的聊天接口演进为“让模型干活”的 Agent 运行时。本文将从 API 演进脉络、核心差异、工具系统到 Agentic Loop 的编排机制系统梳理这一范式转移的全貌。一、三条接口线的演进与统一理解 Responses API 的价值需要先回顾 OpenAI 走过的三条技术路线。Chat Completions API2023 年是无状态的对话补全接口。开发者传入messages模型返回completion。它简单、稳定至今仍是行业的事实标准。但局限同样明显每次请求需重传完整历史工具调用需自行编写循环逻辑多轮对话的成本随长度线性增长。Assistants API2023 年试图解决状态管理问题引入了 Thread、Run 和内置工具等抽象。但其接口复杂、延迟偏高、灵活性不足始终未能广泛普及。Responses API2025 年旨在统一前两者的优势像 Chat Completions 一样简洁像 Assistants 一样强大并专为推理模型和 Agent 工作流优化。用 Java 生态作类比Chat Completions 像是原始的 JDBC——开发者自行管理连接、编写 SQL、处理结果集Responses API 则像是 Spring Data JPA——平台代为管理大量样板逻辑开发者只需声明意图。二、核心差异不只是版本号的变化2.1 无状态 vs 有状态这是两代 API 最本质的分水岭。Chat Completions 是无状态的。每次请求相互独立。要实现多轮对话开发者必须自行拼接完整的messages数组每次重传全部历史。对话越长Token 消耗越高。Responses API 是有状态的。通过previous_response_id参数服务端自动管理对话历史。推理状态在轮次之间得以保留——模型“带着笔记本”进入下一轮对话而非每次从头开始。2.2 核心参数对比维度Chat CompletionsResponses API端点/v1/chat/completions/v1/responses输入格式messages数组完整历史inputprevious_response_id系统提示messages中的role: system独立的instructions字段状态管理无状态客户端维护历史有状态服务端存储历史工具类型仅function自定义函数function 多种内置工具工具执行客户端自行编写循环平台自动编排 Agent Loop响应结构choices[0].message.contentoutput[0].content[0].text2.3 状态管理示例# 第一轮responseclient.responses.create(modelgpt-4.1,input你好我叫小明,storeTrue)response_idresponse.id# 第二轮 —— 只需传入 previous_response_idresponseclient.responses.create(modelgpt-4.1,input我叫什么名字,previous_response_idresponse_id)2.4 数据模型的升级items替代messagesChat Completions 的messages数组将文本、工具调用、系统提示等不同类型的内容混在同一个扁平结构中。Responses API 引入items[]强类型数组将message、reasoning、function_call、function_call_output、compaction等每一步动作独立为结构化 item清晰还原 Agent 的完整执行轨迹。2.5 其他重要变化原生推理过程输出Chat Completions 中 o 系列模型的推理思考内容混在content字符串中以...标识需自行解析。Responses API 提供独立的type: reasoningitem推理过程以结构化对象呈现思考与最终回答干净分离。原生结构化输出client.responses.parse()方法传入 JSON Schema服务端直接校验并解析为对象。相比旧版response_format: json_schema解析失败的容错性更好返回结构化错误信息。WebSocket 流式接口Chat Completions 仅支持 HTTP SSE 流式Responses API 额外支持 WebSocket 长连接流式更适合高并发的持续 Agent 会话。缓存优化服务端会话缓存复用官方数据显示可降低 40%–80% 的输入 Token 开销。三、内置工具系统运行在哪里Responses API 的内置工具并非全部运行在 OpenAI 服务器上而是采用混合部署模式。开发者需要理解不同工具的运行位置才能正确使用。3.1 完全托管型运行于 OpenAI 云端以下工具完全运行在 OpenAI 服务器上无需安装任何依赖在请求中声明即可使用工具功能Web Search联网搜索基于最新数据回答问题File Search从已上传文件中检索上下文Code Interpreter在沙箱中执行 Python 代码Image Generation生成图像这类工具的特点是“即用即走”——开发者无需考虑运行环境、依赖安装或算力资源。3.2 本地执行型运行于开发者环境以下工具由模型发起调用请求但实际执行发生在开发者的本地环境工具功能Computer Use操作虚拟计算机Shell执行 Shell 命令提供 grep、curl、awk 等常用 Unix 工具3.3 远程连接型运行于外部服务器Remote MCPsModel Context Protocol既不运行在 OpenAI 云端也不直接在本地执行。开发者需将 MCP 服务器部署至公网可访问的地址Responses API 调用时OpenAI 服务器会直接向该地址发起请求。3.4 分类记忆Web Search / File Search / Code Interpreter / Image Generation OpenAI 托管的“官方服务”直接执行。Computer Use / Shell “DIY 工具包”模型发出指令开发者环境负责执行。Remote MCPs “第三方集成”开发者自行部署服务OpenAI 远程调用。四、文件操作内置工具能否访问本地文件答案是否定的除非开发者主动上传。内置工具运行在 OpenAI 服务器上无法直接读取本地硬盘上的任何文件。标准操作流程如下上传通过 OpenAI Files API 将本地文件上传至云端获得file_id。引用调用 Responses API 时通过file_ids参数引用该file_id。处理内置工具在 OpenAI 沙箱环境中处理云端副本。# 1. 上传本地文件至 OpenAI 云端fileclient.files.create(fileopen(本地财报.pdf,rb),purposeuser_data)# 2. 引用 file_id而非本地路径responseclient.responses.create(modelgpt-4.1,input总结这份财报的核心数据,tools[{type:file_search}],tool_resources{file_search:{vector_stores:[{file_ids:[file.id]}]}})Code Interpreter 同理——其执行的 Python 代码读取的是 OpenAI 沙箱环境中的临时文件夹其中的文件要么通过 API 上传要么由之前的工具调用生成。本地文件是安全的。内置工具只识别file_id不识别文件路径。五、Agentic Loop范式转移的核心体现为了直观感受Agentic Loop智能体循环的范式转移以“联网搜索天气”这一常见任务为例进行对比。场景设定用户提问“今天北京天气怎么样适合户外运动吗”模型需先联网搜索获取天气再据此给出运动建议。5.1 旧模式Chat Completions API客户端驱动循环Chat Completions没有内置联网搜索工具。开发者需自行定义search_web函数并手动实现完整的“请求-判断-执行-再请求”循环。importjsondefmock_web_search(query):if北京inqueryand天气inquery:return{city: 北京, temperature: 25°C, weather: 晴}returntools[{type:function,function:{name:search_web,description:获取实时信息,parameters:{type:object,properties:{query:{type:string}},required:[query]}}}]messages[{role:user,content:今天北京天气怎么样适合户外运动吗}]responseclient.chat.completions.create(modelgpt-4,messagesmessages,toolstools)assistant_messageresponse.choices[0].message messages.append(assistant_message)ifassistant_message.tool_calls:fortool_callinassistant_message.tool_calls:iftool_call.function.namesearch_web:argsjson.loads(tool_call.function.arguments)search_resultmock_web_search(args.get(query))messages.append({role:tool,tool_call_id:tool_call.id,content:search_result})final_responseclient.chat.completions.create(modelgpt-4,messagesmessages)print(final_response.choices[0].message.content)else:print(assistant_message.content)这一模式的问题在于循环控制权在客户端开发者需手写if判断和for循环解析tool_calls将 Agent 的推理-执行循环暴露给调用方。状态维护在客户端每次交互均需手动将assistant消息和tool结果追加至messages数组。成本随历史线性增长第二轮请求须重传完整messages数组历史越长 Token 消耗越大。换言之Chat Completions 只提供了“推理”能力而“执行”和“循环”的编排逻辑完全由开发者自行实现。5.2 新模式Responses API服务端托管循环Responses API 中联网搜索是内置工具。平台服务端内部处理“调用搜索-获取结果-继续生成”的完整循环。开发者只需一次请求responseclient.responses.create(modelgpt-4.1,input今天北京天气怎么样适合户外运动吗,tools[{type:web_search}])print(response.output[0].content[0].text)平台内部自动执行的 Agentic Loop模型决定调用web_search。OpenAI 服务端自动执行搜索 API。服务端自动将搜索结果注入当前上下文。模型基于搜索结果生成最终建议。一次性返回最终结果。这里的变化是根本性的开发者不再需要编写循环逻辑Agent 的推理-执行-再推理的闭环从客户端转移到了服务端。API 的抽象层级从“调用模型推理”提升到了“提交任务并获取结果”。5.3 自定义工具场景下的对比若使用自定义函数如查询内部数据库Responses API 中执行动作仍需开发者后端执行但循环编排和状态管理被服务端接管# 第一次调用模型返回 function_call 请求response1client.responses.create(modelgpt-4.1,input查一下订单12345的状态,tools[{type:function,name:query_order,...}],storeTrue)# 后端执行 query_order获取结果这是开发者唯一需要做的事情order_status已发货# 第二次调用利用 previous_response_id 延续上下文response2client.responses.create(modelgpt-4.1,previous_response_idresponse1.id,input[{type:function_call_output,call_id:response1.output[0].call_id,output:order_status}])print(response2.output[0].content[0].text)对比 Chat Completions 的实现方式Responses API 的关键改进在于开发者不再需要维护messages数组——状态由服务端通过previous_response_id管理。开发者不再需要编写循环判断——平台负责判断是否需要继续调用工具、何时返回最终结果。开发者只需关注两件事定义工具、执行工具。5.4 Agentic Loop 的范式转移本质维度Chat CompletionsResponses API循环控制权客户端开发者编写while/if服务端平台内部自动编排历史管理客户端维护messages数组全量重传服务端缓存previous_response_id引用工具调用编排客户端自行解析tool_calls并拼接结果平台自动处理工具调用链API 抽象层级推理接口“请生成下一段文本”任务接口“请完成这个任务”代码量约 30–40 行约 5–10 行一句话总结Chat Completions 暴露的是“模型推理”能力开发者需要在其之上构建 Agent 循环Responses API 暴露的是“Agent 执行”能力Agent 循环已被内置为平台的原生能力。这便是“从聊天接口到 Agent 运行时”这一范式转移的最直观体现。六、重要边界与注意事项6.1 服务端状态并非强制设置storeFalse后previous_response_id失效开发者自行维护items数组。此模式下Responses API 可作为增强版 Chat Completions 使用依然可享受内置工具、推理过程输出、结构化解析等新能力。这为需要精细控制状态的企业场景提供了灵活性。6.2 企业级选型考量C 端 Demo / 原型storeTrueprevious_response_id省时省力。企业生产环境多数选择storeFalse自行管理items以规避 Compaction 黑盒、会话 ID 过期、合规零数据保留ZDR等限制。6.3 Assistants API 下线Assistants API 已标记为废弃官方推荐迁移至 Responses API。Responses API 已合并 Assistants 的大部分能力文件处理、代码解释器等。七、迁移路径与时间节点7.1 参数映射速查表Chat CompletionsResponses APImessages数组inputprevious_response_idrole: system独立的instructions字段response_formattext.formatchoices[0].message.contentoutput[0].content[0].textmax_completion_tokensmax_output_tokens无storestore: bool是否服务端存储会话无previous_response_idprevious_response_id无context_managementcontext_management压缩配置7.2 关键时间节点事件时间Assistants API 正式下线2026 年 8 月 26 日GPT-5 及更新模型必须使用 Responses APIChat Completions 状态进入维护模式新功能仅迭代于 Responses APIOpenAI 已提供迁移工具包completions-responses-migration-pack由 Codex CLI 引导完成迁移。八、选型建议场景推荐方案新项目Agent / 工作流直接使用 Responses API纯文本生成、简单问答可暂用 Chat Completions建议规划迁移依赖 Assistants API 的项目须在 2026 年 8 月 26 日前完成迁移使用 GPT-5 及更新模型必须使用 Responses API结语从接口升级到思维转型回顾全文可以梳理出 Responses API 所带来的范式转移的三个层面第一层是状态管理的变革。从无状态到有状态previous_response_id的出现意味着服务端开始承担对话历史的存储与管理职责开发者不再需要手动拼接和重传messages数组。第二层是工具系统的扩展。从仅支持自定义函数到内置 Web Search、File Search、Code Interpreter、Shell、Computer Use 等多种工具模型获得了与外部世界交互的标准化能力。第三层是 Agentic Loop 的托管。这是最根本的变化——工具调用的判断、执行结果的注入、多轮推理的循环从客户端的业务逻辑转变为平台的内置能力。API 的抽象层级从“调用一次模型推理”上升为“提交一个任务并获取完成结果”。这三层变化共同指向一个方向大模型 API 正在从“模型即服务”Model as a Service演进为“Agent 即服务”Agent as a Service。开发者不再需要自行搭建 Agent 的编排框架平台提供了开箱即用的运行时环境。正如 OpenAI 官方所述“Chat Completions 会继续支持但 Responses 是推荐所有新项目使用的接口。这不是营销话术而是能力分叉的现实。”对于正在规划新 AI 应用的开发者而言当下正是认真了解并着手使用 Responses API 的最佳时机。