. 背景

早期 LLM API 的主要任务是“给一段上下文，生成一段回复”。怎么说呢，Chat Completions 采用了非常直接的抽象：客户端传入 messages模型返回一条 assistant message。说起来，这一设计适合聊天、问答、摘要、 、简单结构化输出等场景。也成为大量 OpenAI-compatible API 的事实标准。

但模型能力已经从“文本生成器”演进为“可调用工具的执行单元”。一次模型请求可能包含多轮推理、工具调用、文件检索、网页搜索、代码执行、图片生成、后台任务、结构化输出和流式事件。此时把所有能力继续塞进 assistant message 会使接口语义变得混乱：message 既是文本回复，又承载工具调用、工具结果、运行状态和执行轨迹。

OpenAI Responses API 的出现，代表抽象从 chat completion 转向 model run / response。Claude Messages API 则走了另一条路线：仍保留 messages -> assistant message 的顶层模型，但通过 typed content blocks 表达工具调用、多模态和结构化内容。

使用者痛点

• 上下文管理繁琐：每次请求都要把完整历史拼回去，导致 token 开销爆炸。
• 事件粒度不足：streaming 只能看到 token 流，无法捕获工具调用开始/结束等关键节点。
• 协议膨胀：message 中混杂多种类型，解析逻辑变得脆弱。
• 多模态 说到阻力。content 从 string 变 array，导致旧版 SDK 难以兼容。

. Chat Completions 的 message-centric 抽象

Chat Completions 的主要模型是：

messages -> assistant message

典型请求：

{
"model": "gpt-"。"messages":
}

典型响应：

{
说到"id"，"chatcmpl_xxx","choices":,"usage": {
"prompt_tokens":,"completion_tokens":,"total_tokens":
}
}

这个模型的优点是简单、稳定、容易代理。后端只需要维护一个 messages 数组。 每轮把历史消息拼进去，再把 assistant message 追加到历史中。对兼容层、简单业务和多模型路由这仍然是最小公分母。

• 单轮假设破裂：因为 function calling 与 tool calling 出现，一次调用往往不止返回文本。
• 状态全靠客户端：必须自行保存并裁剪历史，否则会超出 token 限制。
• SSE 流难以表达非文本事件：Kafka/消息队列需要自行包装 tool_calls 等信息。

但 Chat Completions 的主要限制也来自这个抽象本身：它默认一次调用的目标是生成一条 assistant message。后续的 function calling、tool calling、structured output、多模态输入，都是在这个模型上逐步 出来的。

工具调用时assistant message 可能不包含最终文本，而是包含 tool_calls

{
"role"这方面，"assistant","tool_calls":
}

后端执行工具后再把结果作为 tool role message 追加回去：

{
从"role"来看，"tool","tool_call_id": "call_1"。“content”: "{\"status\":\"shipped\"}"
}

This mechanism works,but it essentially simulates an execution flow inside a chat timeline. As tools and multimodal capabilities grow,this encoding becomes increasingly heavy.

. Chat 抽象的工程边界

A) 状态完全由客户端维护。

{
“messages”:
}

This forces gateways to handle context trimming,summarization,token budgeting,history reconstruction and audit persistence.

B) Streaming only emits token deltas.

If you need to surface “tool started”。“partial arguments”,or “background task progress”,you have to invent custom events on top of plain token stream.

C) Tool calls are just an extension field of a message.

The backend must parse a.tool_calls → tool_message →…,turning what should be first‑class actions into ad‑hoc payloads.

D) Multimodal & structured output bloats schema.

`content` evolves from a simple string to an array of heterogeneous blocks . The chat‑centric model slowly morphs into a generic runtime protocol.

This is *** OpenAI needed Responses API: not because Chat Completions is broken。but because it’s no longer optimal abstraction for agentic workflows.

User Pain Points Recap

• Lack of native event types makes orchestration code noisy.
• The client bears entire state burden → scaling challenges for high‑throughput gateways.
• Evolving schemas lead to version‑drift and backward‑compatibility headaches.
• No explicit continuation token;every round repeats large payloads.

. Responses 的 model-run 抽象

The core model of Responses API is:

input items -> response/model run -> output items

The notion of an “assistant message” disappears;instead a single run can emit multiple typed items such as text chunks,function calls,reasoning steps,image blobs or background task updates.

Simplified request example:

{
“model”: “gpt-”,“input”: “查询订单 A001 的状态”,“tools”:
}
}
]
}

{
“id”的观点是，“resp_xxx”,“status”: “completed”,“output”:
}

The backend executes tool and feeds result back as a new input item:

{
\"model\": \"gpt-\"。\"previous_response_id\": \"resp_xxx\",\"input\":
}

The key shift: tool calls become first‑class output items rar than hidden inside a chat message. Consumers can treat response as an ordered event log instead of parsing free‑form text.

User Pain Points Addressed by Responses

• No more manual stitching of tool calls – y are explicit objects.
• The provider retains execution state;clients only send a pointer plus new inputs.SSE can now stream structured events without abusing token deltas.A single run encapsulates multimodal outputs – no need to overload chat schema repeatedly.

  . Responses 的状态性

  The Responses API is deliberately stateful on provider side. It does **not** try to memorize every user turn;instead it offers an explicit continuation handle via previous_response_id.

  {
  \"model\": \"gpt-\",\"previous_response_id\": \"resp_abc123\",\"input\": \"继续上一个问题\"
  }

  This tells service: *attach my new input to execution context that produced `resp_abc123`*. OpenAI can n reconstruct prior inputs,outputs and tool interactions without requiring client to resend m all.

  /tbody>/table

  #维度##体现#"
  "Response object""每次调用返回稳定 response.id"	"Continuation""下一轮通过 previous_response_id 链接"	"Tool state""function_call 与 function_call_output 用 call_id 对齐"	"Background task""response 可处于 in_progress / completed / failed 状态"	"Execution trace""output 保存结构化执行轨迹"

  Please note that previous_response_id is **not** a business conversation ID nor a user memory ID—it’s a provider‑side execution pointer. Enterprises should still keep ir own conversation event log for audit。replay and cross‑model migration purposes.

  User Pain Point Mitigation

  • No need to ship full history each turn → lower network overhead .
  • Provider can cache & reuse prior context automatically → 娱乐ter latency & cost .
  • Explicit state pointer avoids ambiguous replay bugs .

  . ​<​c ode>`previous_response_id​`​ 与 prompt cache​<\/c ode>

  ​

  ​ previous_response_id​ 和缓存不是同一个概念。​​

  text previous_response_id: 解决上下文从哪里续接 prompt cache:            解决相同或稳定上下文能否复用以减少成本/延迟

---