每个人都应该理解的：大话LLM对话协议 Chat Completions、Responses API、Anthropic Messages API

三大 AI API 协议深度解析Chat Completions、Responses API 与 Anthropic Messages原始鼻祖Chat Completions模型路径特征/v1/chat/completionsChat Completions API是大语言模型领域最重要的接口协议之一。它的历史背景是一部大模型从单次文本生成演进到多轮智能对话与智能体Agent调用的发展史。历史演进三阶段Chat Completions 协议的演进主要分为三个阶段1. 缘起从 Completion 到 Chat Completion (2023年春)最初OpenAI 的 GPT-3 等模型使用的是基础的Completions API即/v1/completions。工作方式接收一段提示词Prompt模型直接续写文本。痛点不适合做对话。要进行多轮聊天开发者必须手动将所有历史对话拼成一段长字符串发给模型体验极差。{model:text-davinci-003,prompt:以下是人类与一个AI助手的对话。\n\nSystem: 你是一个 helpful AI。\nUser: 你好我是小明。\nAI: 你好小明很高兴认识你。有什么我可以帮你的吗\nUser: 我刚才说我叫什么名字来着\nAI:,max_tokens:50,stop:[\nUser:,\nAI:]}诞生2023年3月随着 GPT-3.5-Turbo 的发布OpenAI 推出了Chat Completions API即/v1/chat/completions。2. 成为行业标准 (2023年 - 2025年)Chat Completions 协议引入了messages数组的概念要求开发者将每一轮对话拆分为带有角色的结构化数据system设定模型的行为和背景。user代表人类用户的输入。assistant代表模型回复的内容。成为事实标准由于 OpenAI 在该领域的统治地位加上协议设计的简洁高效各大模型厂商如 DeepSeek、Google、 Anthropic 等纷纷在其 API 中提供了兼容 OpenAI Chat Completions 格式的接口。3. 工具调用与结构化演进 (2023夏 - 2024年)随着大模型能力的扩展Chat Completions 协议进行了多次重要升级以支持高级功能Function Calling函数调用协议增加了tools字段允许模型输出符合特定格式的 JSON从而调用外部 API如查天气、查数据库或运行代码。多模态支持协议扩展了content字段的结构支持在单条消息中同时传入文本和图像、音频等多媒体数据。4. 现状与向 Responses API 的过渡 (2026年及以后)随着新型推理模型如 OpenAI o 系列和原生 Agent智能体平台的兴起传统的 Chat Completions 协议暴露出局限性无状态开销每次请求都必须发送完整的历史记录随着上下文变长会导致大量的 Token 浪费和延迟增加。手动编排工具调用的多轮循环必须由开发者在客户端代码中自行编写。演进OpenAI 针对原生智能体平台推出了新的Responses API。该协议采用有状态设计服务端存储上下文、平台自动编排工具执行流等。总结Chat Completions 协议是大模型多轮对话的基石。虽然未来复杂智能体平台可能会转向有状态的新协议但由于其轻量、灵活以及极高的兼容性它依然是目前开发大模型应用、实现跨平台模型切换的最核心协议。行业常规配置BaseUrl填写域名与前缀如https://api.deepseek.com再拼接接口路径/chat/completions组成完整请求地址。拼接接口路径一般是由 SDK比如python openai库自行完成开发者一般只需填写 BaseUrl:https://api.deepseek.com即可fromopenaiimportOpenAI clientOpenAI(api_keyyour_deepseek_api_key,base_urlhttps://api.deepseek.com# 开发者只需填到这里SDK 会自动拼接)# 当你调用下面这行代码时SDK 自动向 https://api.deepseek.com/chat/completions 发送请求responseclient.chat.completions.create(modeldeepseek-chat,messages[{role:user,content:你好}])使用场景示例我们想向大模型询问北京的天气大模型需要调用工具去获取当前的天气这个场景的完整的工具调用流程需要经历两次 API 请求。在请求模型的过程中tool 字段提供了一个获取当前的天气的函数可调用工具get_current_weathercurlhttps://api.openai.com/v1/chat/completions\-HContent-Type: application/json\-HAuthorization: Bearer YOUR_API_KEY\-d{ model: gpt-4o, messages: [ { role: user, content: 帮我查一下北京今天的天气。 } ], tools: [ { type: function, function: { name: get_current_weather, description: 获取指定城市的天气预报, parameters: { type: object, properties: { location: { type: string, description: 城市名称例如北京 } }, required: [location] } } } ] }模型返回客户端请求对工具进行调用{choices:[{message:{role:assistant,tool_calls:[{id:call_123,type:function,function:{name:get_current_weather,arguments:{location: 北京}}}]}}]}客户端收到大模型的执行工具的请求自行调用工具获取到结果之后将工具调用的结果 push 到 messages 数组之后再次调用大模型 API大模型再根据工具调用的结果回答问题。curlhttps://api.openai.com/v1/chat/completions\-HContent-Type: application/json\-HAuthorization: Bearer YOUR_API_KEY\-d{ model: gpt-4o, messages: [ { role: user, content: 帮我查一下北京今天的天气。 }, { role: assistant, tool_calls: [ { id: call_123, type: function, function: { name: get_current_weather, arguments: {location: 北京} } } ] }, { role: tool, tool_call_id: call_123, content: {temperature: 25℃, weather: 晴朗} } ] }后浪Responses API历史演进阶段Responses API是 OpenAI 推出的一款全新核心 API 基座旨在替代传统的 Chat Completions API成为开发智能体Agent和进行多轮对话的首选原生接口。它从底层开始重构将文本、多模态、推理思考以及工具调用整合成统一的、原生支持状态管理和流式传输的开发体验。第一阶段Completions API2020年 — 2023年定位自由文本补全。技术特点这是最原始的 OpenAI 接口。当时还没有对话的概念采用无状态Stateless设计。用户输入一段前缀文本Prompt模型预测并拼接后续的文本。它无法区分系统指令、用户提问或AI回答一切都需要开发者在 Prompt 中通过特殊的文本换行和标记自行模拟。第二阶段Chat Completions API2023年 — 至今定位行业事实标准回合制对话接口。技术特点随着 ChatGPT 的爆发OpenAI 在 2023 年推出了/v1/chat/completions。它首次引入了结构化的消息数组如system、user、assistant角色声明。历史局限性它依然是无状态的。为了维持多轮对话客户端必须在每次请求时把所有历史聊天记录打包重新发送给服务器。当引入自定义函数调用Function Calling时开发者需要在客户端编写复杂的循环Agent Loop来反复接收模型指令、执行本地代码、再将结果送回 API开发成本极高。第三阶段Assistants API 的探索2023年底 — 2025年定位首次尝试 Agent 托管服务。技术特点在 2023 年底的 DevDay 上OpenAI 推出了 Assistants API引入了Threads线程和Runs运行的概念。这套 API 首次在服务端帮开发者管理对话状态并内置了代码解释器Code Interpreter和文件检索File Search/RAG。历史局限性由于设计过于臃肿、响应延迟高、流式传输Streaming解析极其繁琐且黑盒化的编排让开发者丧失了对模型行为的微调控制权导致社区反馈不佳。第四阶段Responses API 的诞生与确立2025年3月至今定位下一代核心基础原语融合简洁性与智能体能力的终极接口。历史时间线2025年3月OpenAI 官方正式发布 Responses API Beta 版。它吸取了 Assistants API 的教训选择直接作为 Chat Completions 的“正统演进继承者”。它保留了 Chat Completions 的简洁结构但底层原生支持状态化Stateful-by-default、多模态以及服务端托管工具。2025年5月OpenAI 进一步扩展功能完善了内置网络搜索Web Search等工具数个独角兽企业如 Coding 智能体、市场情报智能体开始大规模将其应用于复杂的商业场景。2025年8月随着平台能力的完全对齐OpenAI 正式宣布废弃旧的 Assistants API并给出了 12 个月的迁移缓冲期计划于 2026 年 8 月底前彻底停用。2025年9月OpenAI 配合 Responses API 推出官方 Agents SDK使得基于该接口构建长时运行、自主规划的复杂 Agent 变得极其轻量化。针对 o3、o4-mini 等新一代推理模型Responses API 能够完美保留模型多轮对话中的推理连续性测试表明其基准性能比 Chat Completions 提升了 5% 以上。2026年3月OpenAI 继续扩展 Responses API 边界引入了容器运行上下文、上下文压缩Compaction和技能系统使其正式成为支持长时运行任务Long-running tasks的行业最前沿 Agent 平台基座。总结从Completions到Chat Completions再到如今的ResponsesAPI 端点的演变反映了整个 AI 行业从“文本补全工具”向“全能型数字员工Agent平台”的范式转移。使用场景示例查询指定城市的实时天气curlhttps://api.openai.com/v1/responses\-HContent-Type: application/json\-HAuthorization: Bearer$OPENAI_API_KEY\-d{ model: gpt-5.5, tools: [ { type: function, function: { name: get_current_weather, description: 获取指定城市的实时天气状况, parameters: { type: object, properties: { location: { type: string, description: 城市名称例如北京 } }, required: [location] } } } ], input: 请问今天北京的天气怎么样 }模型回复请求调用工具客户端收到请求后调用相应的工具{id:resp_123,object:response,status:requires_action,output:[{id:item_01,type:function_call,call_id:call_abc,name:get_current_weather,arguments:{location:北京}}]}随后客户端调用工具完成获取调用结果再次通过 API 调用模型注意这里带了个 “previous_response_id”: “resp_123” 将多轮对话串联起来不用像 Chat Completions一直携带历史记录了。curlhttps://api.openai.com/v1/responses\-HContent-Type: application/json\-HAuthorization: Bearer$OPENAI_API_KEY\-d{ model: gpt-5.5, previous_response_id: resp_123, input: [ { type: function_call_output, call_id: call_abc, output: {temperature: 26°C, condition: 晴朗} } ] }模型根据上下文回复输出{id:resp_124,object:response,status:completed,output_text:今天北京的天气非常晴朗目前的实时气温是 26°C很适合出行。}上下文压缩机制Responses API 既然不用传递上下文只需要传递id那么消息上下文是不是就不计入token消耗答案是不消息上下文依然会完整计入 Token 消耗并正常计费。尽管在调用Responses API时只需要传递一个简单的previous_response_id但这只是在客户端代码层面省去了手动拼接和传输历史消息的麻烦由 OpenAI 的服务器在后台自动完成拼接。从大模型的底层运行逻辑来看以下是关于 Token 计费和其核心优化机制的真相底层大模型的运行逻辑没有变大模型本身依然是无状态的。模型在生成最新一轮的回答时必须“看”一遍所有的历史上下文。因此OpenAI 的服务器在接收到previous_response_id后会在内部数据库中查出历史对话并把历史记录与当前输入的新问题一起塞给大模型。计算公式本次请求的总输入 Token历史多轮对话的总 Token当前新输入的 Token。只要上下文存在服务器就需要为其消耗算力所以这部分历史 Token 依然会计费。使用 Responses API 的核心好处是大幅简化了 Agent 的工程开发量免去了管理数据库、拼接字符串、处理 Tool 复杂状态的痛苦而不是直接免除历史 Token 的费用。上下文压缩机制既然历史上下文依然计费为了防止多轮对话导致 Token 成本无限滚雪球Responses API 引入了一项 Assistants API 所不具备的杀手级功能——自动长文本上下文压缩Compaction智能删减当多轮对话导致上下文窗口过长或即将溢出时Responses API 会在后台自动或通过配置触发对历史上下文进行“压缩摘要”或“有损删减”。保留核心它会智能保留最初的系统指令、关键实体信息以及最近几轮的对话而将中间冗余的、不重要的旧对话 Token 剃掉。实际效果通过这种方式它在物理层面上减少了需要传给模型的 Token 数量从而被动降低了长期运行的 Token 成本。Anthropic Messages APIAnthropic Messages API是 Anthropic 公司Claude 模型的母公司的核心基础基座接口。如果说 OpenAI 的未来押注在全新的Responses API上那么 Anthropic 的所有尖端能力如 Claude 4.5/4.6 的长时思考Extended Thinking、计算机使用Computer Use、以及强化的工具调用全部都是原生围绕Messages API构建的。与 OpenAI 最新的有状态StatefulResponses API 不同Anthropic Messages API 在底层设计上坚持无状态Stateless。为了维持多轮对话或进行自定义工具调用依然需要将完整的历史记录或工具执行状态包装进messages数组发送给服务器。为了抵消重复发送导致的成本增加Anthropic 引入了极具代表性的提示词缓存Prompt Caching技术。历史发展阶段第一阶段/v1/complete文本补全时代的人类对抗游戏2023年3月 — 2024年初在最初发布 Claude 1 和 Claude 2 时Anthropic 提供的是极其老旧的Text Completions API。历史背景当时大模型接口还没有行业标准。Anthropic 为了强迫模型区分“人类提问”和“AI回答”要求开发者在 Prompt 中必须严格手动拼接\n\nHuman: [提问]\n\nAssistant: [回答]这样的硬编码字符串。痛点如果不写\n\nHuman:模型经常会陷入混乱或拒绝回答。这种文本拼接方式对多轮对话和复杂逻辑极其不友好。第二阶段/v1/messages强类型内容块架构的诞生2024年3月随着Claude 3 家族Opus、Sonnet、Haiku的发布Anthropic 彻底废弃了老旧接口推出了延续至今的核心基座Messages API。技术创新内容块 Content BlocksOpenAI 的 Chat Completions 传回的结构是非常死板的纯文本字符串。而 Anthropic 极具前瞻性地将返回体设计为了一个数组Array of Content Blocks。为什么这样做Anthropic 坚信未来的模型是高度多模态且原生具备工具属性的。在这个数组中文字、图片、PDF、甚至是工具调用指令Tool Use在底层享有完全平等的“一等公民”数据结构。这为后来的多模态混排、思维链暴露奠定了架构基础。第三阶段思维链与智能体时代的终极原语2024年底 — 2026年随着模型向高阶推理Reasoning和 Agent 演进OpenAI 经历了 Assistants API 的失败并重构出了 Responses API而Anthropic 的 Messages API 凭借其弹性的内容块架构不需要改动核心 Endpoint 结构直接顺畅地扩展了三大里程碑功能原生工具调用Tool Use与 MCP 的引入 (2024年末)Messages API 原生支持在请求中声明 Tools。2024 年底Anthropic 推出了模型上下文协议MCP使得 Messages API 可以无缝连接到外部数据库和开发工具中成为了构建自主 Agent 的首选。思维链暴露原生“Thinking”块 (2025年初)当行业进入深度推理时代如 Claude 3.7 Sonnet 推出OpenAI 在旧接口里只能通过复杂的reasoning_tokens或重构 Responses API 来隐藏或传递思维过程。而 Anthropic 的 Messages API 只需要在返回的 Content 数组里直接塞入一个type: thinking的内容块就完美实现了边思考、边输出、边调用工具的动态长程推理。海量上下文与提示词缓存Prompt Caching(2025年—2026年)随着 Claude 4 世代支持高达100万 Token 的超长上下文窗口长文本在 Messages API 中的传输成本变得极高。Anthropic 在 Messages API 中率先引入了极其细粒度的cache_control标志允许开发者对 System Prompt 或历史对话进行精确缓存使多轮对话的延迟和 Token 成本直接暴跌了 90%。总结两家大厂的历史哲学差异OpenAI (Chat Completions - Responses API)早期的路线比较实用主义、注重简单导致后面在面对有状态 Agent、工具链和推理模型时旧架构无力承受不得不推倒重来推出了Responses API。Anthropic (Text Completions - Messages API)从 2024 年起就带有浓厚的“学院派与安全至上”色彩。其精心设计的Messages API一步到位用“强类型、内容块、流式事件”的精妙设计包容了过去两年内出现的多模态、工具调用、MCP 协议、思维链暴露以及超长缓存的所有技术变革。使用场景示例curlhttps://api.anthropic.com/v1/messages\-Hcontent-type: application/json\-Hx-api-key:$ANTHROPIC_API_KEY\-Hanthropic-version: 2023-06-01\-d{ model: claude-3-7-sonnet, max_tokens: 1024, tools: [ { name: get_weather, description: 获取指定城市的实时天气, input_schema: { type: object, properties: { city: { type: string, description: 城市名称例如北京 } }, required: [city] } } ], messages: [ { role: user, content: 请问今天北京的天气怎么样 } ] }API 返回模型决定调用工具模型会返回stop_reason: tool_use。请注意content数组中包含了一个特殊的type: tool_use块。请记录其中的id例如toolu_01下一步需要用到。{id:msg_01,type:message,role:assistant,model:claude-3-7-sonnet,content:[{type:text,text:好的我来帮您查询北京的天气。},{type:tool_use,id:toolu_01,name:get_weather,input:{city:北京}}],stop_reason:tool_use}第三步提交工具结果模型给出最终回答在 Anthropic 的 Messages 哲学中必须要把上一轮模型返回的完整content数组作为assistant的消息原样传回紧接着追传一条包含type: tool_result的user消息。curlhttps://api.anthropic.com/v1/messages\-Hcontent-type: application/json\-Hx-api-key:$ANTHROPIC_API_KEY\-Hanthropic-version: 2023-06-01\-d{ model: claude-3-7-sonnet, max_tokens: 1024, tools: [ { name: get_weather, description: 获取指定城市的实时天气, input_schema: { type: object, properties: { city: { type: string, description: 城市名称例如北京 } }, required: [city] } } ], messages: [ { role: user, content: 请问今天北京的天气怎么样 }, { role: assistant, content: [ { type: text, text: 好的我来帮您查询北京的天气。 }, { type: tool_use, id: toolu_01, name: get_weather, input: { city: 北京 } } ] }, { role: user, content: [ { type: tool_result, tool_use_id: toolu_01, content: {temperature: 26°C, condition: 晴朗} } ] } ] }API 最终返回{id:msg_02,type:message,role:assistant,model:claude-3-7-sonnet,content:[{type:text,text:根据最新的气象数据显示今天北京的天气非常晴朗目前的实时气温是 26°C很适合出行。}],stop_reason:end_turn}核心设计差异内容块并列在第一步返回和第三步传回中模型的纯文本解释text和工具调用指令tool_use是作为同等地位的 Block 并列放在一个content数组里的。工具结果伪装成 UserAnthropic 规定本地代码执行出来的结果必须包装成type: tool_result并以role: user的身份塞回消息历史。使用缓存目前 API 支持显式设置断点与全自动缓存两种模式1. 显式缓存Explicit Breakpoints在特定内容块的末尾手动塞入cache_control: {type: ephemeral}标记。API 允许在一个请求中最多设置4 个缓存断点。显式缓存的curl示例curlhttps://api.anthropic.com/v1/messages\-Hcontent-type: application/json\-Hx-api-key:$ANTHROPIC_API_KEY\-Hanthropic-version: 2023-06-01\-d{ model: claude-3-7-sonnet, max_tokens: 1024, system: [ { type: text, text: 你是一个极其严谨的法律条文分析专家。这里有一份长达5万字的合同规范..., cache_control: {type: ephemeral} } ], messages: [ { role: user, content: 请帮我找出这份合同中关于违约金的条款。 } ] }2. 自动缓存Automatic Caching无需在具体的内容块里写cache_control直接在请求体最外层声明即可。系统会自动识别最长且重复的静态前缀非常适合多轮聊天或复杂智能体架构自动缓存的curl示例curlhttps://api.anthropic.com/v1/messages\-Hcontent-type: application/json\-Hx-api-key:$ANTHROPIC_API_KEY\-Hanthropic-version: 2023-06-01\-d{ model: claude-3-7-sonnet, max_tokens: 1024, cache_control: {type: ephemeral}, system: 你是一个高度定制化的 AI 助手..., messages: [ {role: user, content: 这是我们的第一轮超长对话历史...}, {role: assistant, content: 收到请继续。}, {role: user, content: 现在我要问新问题了。} ] }检查缓存是否生效当 API 响应该请求时可以在返回的 JSON 最底部的usage字段中看到精确的扣费及命中凭证{usage:{input_tokens:350,output_tokens:120,cache_creation_input_tokens:0,cache_read_input_tokens:4200}}cache_creation_input_tokens代表本次请求中新写入缓存的 Token 数量按 1.25x 或 2x 计费。cache_read_input_tokens代表成功命中并从缓存读取的 Token 数量按 0.1x 计费节省成本的核心指标。缓存会失效的情况文本一字之差缓存采用字符精确匹配。即使你在系统提示词里多加了一个空格或标点符号整个缓存全盘失效需要重新付钱写入。工具定义变更如果你在多轮对话中修改了工具Tools的参数结构、名字或描述之前的缓存会彻底失效。Lookback 窗口限制如果你设置的断点距离上一次写入的断点相隔了超过 20 个消息块Blocks模型在回溯时会“找不到”之前的缓存。后记Anthropic Messages API由于是无状态的它采用“空间换时间/金钱”的策略。历史上下文必须每次都全量传来但只要命中了服务器的缓存断点这部分历史 Token 直接打 1 折0.1x 计费。OpenAI Responses API采用“有状态编排”的策略。您不需要传历史省了网络带宽服务器内部帮存着并引入压缩Compaction直接把不需要的 Token 删掉。三大协议对比总结维度Chat CompletionsResponses APIAnthropic Messages厂商OpenAI行业事实标准OpenAI下一代Anthropic端点/v1/chat/completions/v1/responses/v1/messages状态管理无状态客户端传完整历史有状态服务端存储上下文无状态客户端传完整历史工具调用tools字段 客户端编排循环tools字段 平台自动编排tools字段 内容块并列多轮续接每次携带完整messages数组仅传previous_response_id每次携带完整messages数组Token 优化策略无内置优化上下文压缩Compaction提示词缓存Prompt Caching0.1x 计费返回结构choices[].message.content字符串output[]结构化项content[]强类型内容块数组认证方式Authorization: BearerAuthorization: Bearerx-api-key或Authorization: Bearer适用场景通用对话、跨平台兼容复杂 Agent、长时运行任务长上下文、深度推理、思维链暴露Chat Completions、Responses、Anthropic Messages API 都是目前最常见的协议我们如果频繁使用 AI 工具的话几乎每天都会接触到。这些协议理解起来很简单无非就是规定的表达数据的一种方式。但是我们却可以从中以小见大理解两个顶级的大模型厂商不同的设计理念也能够理解为什么我对大模型仅仅输入了一个Hi我的钱包却瘪了这其中上下文占了大头。我们也能够看出两个厂商面临这个问题所提供的方案都体现了不同角度思考问题的方式。当然我们也希望模型能够形成统一的标准找到一个最好的节省 Token 的方案而不是我们在这里长篇大论的说他们之间的区别。我是麻辣凉茶如果文章对你有用欢迎点赞关注鼓励你的支持就是我最大的动力下篇再见掘金主页https://juejin.cn/user/4380873673177646