一句话定义：Responses API 是一种“有状态”的模型调用接口——请求里只发这一轮的新内容，服务端记住前面发生过什么，并用一个 ID 把整段对话串起来。它由 OpenAI 推出，与长期作为默认做法的 Chat Completions API 并存。
先看老办法的麻烦
Chat Completions 是典型的无状态（stateless）接口。每次调用，你都要把系统提示、历史问答、这一轮的新问题，整包塞进 messages 数组重新发一遍。
打个比方：像每次去银行办事，都得把身份证、合同、上次的办理记录从头复印一份交上去，柜员那边不留档。好处是简单、好扩容；坏处是聊得越长，请求越胖，重复内容越多，模型还得把这些“复读”再读一遍。
Responses API 相当于给你配了个会议秘书。第一次见面把需求讲完，秘书留一份纪要，给你一个编号。下次你只说“接着上次那个方案改一版”，把编号带上就行。
它顺手统一的两件事
1. 工具调用。网页搜索、文件检索、代码执行这类工具可以由服务端托管。以前你得自己写循环：模型返回工具调用请求，你执行，把结果塞回消息数组，再请求一次。现在这些中间步骤本身属于这段对话状态，跟着 ID 一路延续。
2. 流式事件。流出来的不再只是文本碎片，而是带类型的事件：文本增量、工具调用开始、参数增量、完成等等。前端可以据此显示“正在查资料”“正在跑代码”这类状态。
| 对比项 | Chat Completions | Responses API |
|---|---|---|
| 状态 | 无状态，每次传全量历史 | 有状态，传 ID 续接 |
| 工具 | 基本靠自建循环 | 服务端托管的内置工具 |
| 流式 | 以文本增量为主 | 带类型的事件流 |
| 会话数据 | 完全由你保管 | 默认服务端存，可设为不存 |
需要注意的
状态放在服务端，意味着数据留存、合规，以及“这个 ID 归谁、能不能被别人复用”都要按自己的场景确认。多数实现允许关闭存储，退化成无状态用法。具体字段、能力范围与计费方式，以官方页面为准。
另外要区分的是：它不是 Assistants API 那种“线程 + 运行”的重型封装，而是把状态和工具这两件事收进了一个更贴近普通请求-响应的接口里。
对从业者的实际意义
写多轮 agent 时，能少写一堆“搬运历史”的样板代码，也少传重复内容，长对话的请求体积不会线性膨胀；代价是要重新适配事件流的解析方式和会话生命周期管理。
对普通职场人，最直观的变化是：带工具的 AI 助手接话更自然了。你说“把刚才那张表再画成图”，它知道“刚才”指什么，而不需要你重新粘一遍上下文。