OpenAI API 演进路径：从 Chat Completions 到 Responses / Lindaren

OpenAI API 的演进路径清晰地分为三个阶段：Chat Completions → Assistants API → Responses API。理解这条脉络，有助于在新项目中做出正确的技术选型。

整体对比

方面	Chat Completions	Assistants API	Responses API
后端状态维护	完全无（自己管）	有（Threads）	有（previous_response_id + Conversations）
Agent 维护难度	高（手动循环）	中（较重）	低（原生支持）
持久化	自己存数据库	Threads（将废弃）	Conversations（推荐）

Chat Completions API（基础阶段）

发布时间：2023 年左右成为主流（从早期 Completions 演变而来）

定位：最简单、最通用的聊天接口。

特点：

Stateless（无状态）：每次调用必须自己传入完整的历史消息
手动处理工具调用（Function Calling）
适合简单聊天机器人、单次生成等场景

优点：轻量、速度快、兼容性强、成本可控

缺点：复杂 Agent 场景需要开发者自己写大量 orchestration 代码

响应体结构（Go）：

type ChatCompletionResponse struct {
    ID      string `json:"id"`
    Choices []struct {
        Message struct {
            Role    string `json:"role"`
            Content string `json:"content"` // 简单字符串
            // ToolCalls 等
        } `json:"message"`
    } `json:"choices"`
}

Assistants API（探索阶段）

发布时间：2023 年底推出

定位：试图解决复杂 Agent 问题，提供持久化线程（Threads）、内置工具（Code Interpreter、File Search、Function Calling）、Assistant 配置等。

目标：让开发者更容易构建有状态的、多步骤的 AI 助手。

实际表现：

功能强大，但架构复杂、性能较慢、调试困难、长期处于 Beta 状态
很多开发者反馈“概念重、容易卡住、成本高”

现状：收集了大量反馈，但没有成为最终形态。已被宣布 deprecated（弃用），计划 2026 年 8 月 26 日正式下线。

响应体特点：输出分散在多个对象（Message、Run、RunStep），不统一。

Responses API（当前与未来方向）

发布时间：2025 年推出

定位：Agentic + Reasoning 的统一且优化的下一代接口，融合了 Chat Completions 的简洁性和 Assistants 的强大能力。

核心特性

有状态 + 多 turn 能力：OpenAI 在后端持续维护模型的推理过程、tool call 上下文、隐藏 reasoning tokens 等，再返回给客户端。这让模型在一次 API 调用中就能完成「思考 → 调用工具 → 观察 → 再思考」的完整循环，无需手动编排。
更好利用 reasoning effort、prompt caching 等新特性 → 更智能、更低成本、更好性能
输入输出模型更清晰（input items → output items），支持原生多模态，结构化输出更干净
内置工具和外部 function calling 集成更无缝

与前两者的关系

比 Chat Completions 强大（内置 Agent 循环、状态管理）
比 Assistants 更干净、灵活、高效

响应体结构（Go）

type Response struct {
    ID          string `json:"id"`
    Object      string `json:"object"` // "response"
    CreatedAt   int64  `json:"created_at"`
    Status      string `json:"status"` // "completed", "failed", "in_progress" 等
    Model       string `json:"model"`
    Output      []ResponseOutputItem `json:"output"` // 关键！Item 数组
    Usage       ResponseUsage `json:"usage"`
    Error       *ResponseError `json:"error,omitempty"`
}

状态管理方式

OpenAI 明确推荐新项目优先使用 Responses API。Chat Completions 会长期维护，但新功能优先在 Responses 上落地。

Responses API 在 OpenAI 后端帮你维护 agent 的部分状态，但不是完全自动的“永久维护”，而是轻量级、有控制的状态管理：

① previous_response_id（推荐，最简单）

第一次调用得到 response.id
下次调用时，把这个 id 作为 previous_response_id 传回去
OpenAI 后端自动拉取之前的对话历史、推理轨迹、工具调用上下文并接续

② Conversations API（更持久）

创建持久的 conversation 对象（有自己的 ID）
所有交互基于该 conversation，适合跨会话、跨设备、长期 agent
OpenAI 后端存储和管理 items（消息、工具输出等）

③ store 参数控制

store: true → 开启后端存储（推荐用于 agent）
store: false → 接近无状态，速度更快（适合一次性任务）

如果需要长期记忆（超出上下文窗口），仍需在应用层加 Memory（如向量数据库、总结机制）——OpenAI 后端主要管理当前对话上下文，不是无限长期记忆。

兼容性说明

真正原生支持 Responses API 的目前几乎只有 OpenAI（包括 GPT/o 系列）。其他厂商（DeepSeek、GLM、Gemini、Claude 等）主流还是兼容 Chat Completions，通过改 base_url + API Key 即可切换。