别再跟 AI 的 API 格式较劲了：2026 年开发者生存指南

它跟 Chat Completions 有什么区别？#

一句话：Chat Completions 是”一问一答”，Responses API 是”给个目标，AI 自己干活”。

几个你必须知道的关键点#

① 有状态模式：方便但有隐藏成本

你传一个 previous_response_id，OpenAI 帮你存着对话历史，不用自己管。

但注意： 每次调用，OpenAI 会把存储的历史重新读出来、重新计费 input tokens。对话越长，每轮越贵。

② Compaction（自动压缩）：上下文快满了怎么办？

当对话 token 总量达到阈值（默认约为上下文窗口的 80%），OpenAI 会自动把早期对话压缩成摘要。

• 阈值可以手动设置（trigger_tokens 参数）
• 压缩是有损的——早期对话的细节可能丢失
• 压缩本身也消耗 token 和费用

③ 后台异步模式

设 background: true，API 立刻返回，不阻塞。适合耗时很长的 Agent 任务。

④ 托管容器 + Shell 工具（2026年3月）

你发一个请求，模型自己开 Linux 容器、装依赖、写代码、跑测试、修 bug——全程你只发了一次 API 调用。这就是 Codex 的底层架构。

⑤ Open Responses 开放规范（2026年1月）

OpenAI 把 Responses API 的格式开放成了行业标准。Hugging Face、Ollama、阿里云百炼都在跟进。它正在从”OpenAI 私家花园”变成”下一个行业通用协议”。

⑥ Assistants API 已死

OpenAI 明确：Assistants API 被 Responses API 完全取代。还在用 threads、runs 那套的，该迁移了。

先看清现实#

按场景选#

面向未来的押注#

押 Responses API 格式，但保留 Chat Completions 的降级路径。

理由：新能力（Agent 循环、Shell 工具、Compaction）都不会再加到 Chat Completions 上了。但 Claude 短期内不会兼容 Responses 格式，所以你的方案必须同时支持两种。

一个生活类比#

你家里有很多电器：空调用三孔插头，台灯用两孔插头，手机充电器用 USB-C，老式耳机用 3.5mm 圆孔。

你不想为了每个电器买不同的插座。 你想要的是：墙上只有一个插孔，不管插什么电器都能用。

这个”万能插孔”，就是抽象层。

没有抽象层 vs 有抽象层#

没有抽象层： 你的业务代码里全是格式处理

1
# 客服功能
2
def 回答用户问题(问题):
3
    if 模型 == "claude":
4
        请求 = {"model": "claude-sonnet-4", "messages": [...]}
5
        结果 = 发给anthropic(请求)
6
        回答 = 结果["content"][0]["text"]
7
    elif 模型 == "gpt":
8
        请求 = {"model": "gpt-5.5", "input": 问题}
9
        结果 = 发给openai(请求)
10
        回答 = 结果["output_text"]
11
    elif 模型 == "gemini":
12
        ...
13
    return 回答
14

15
# 摘要功能
16
def 生成摘要(文章):
17
    if 模型 == "claude":      # ← 又写了一遍！
18
        ...
19
    elif 模型 == "gpt":       # ← 又写了一遍！
20
        ...
21

22
# 翻译功能
23
def 翻译(文本):
24
    if 模型 == "claude":      # ← 又又写了一遍！
25
        ...

换模型？改 N 个地方。漏改一个就出 bug。

有抽象层： if-else 被关在一个独立的”笼子”里

1
# ========== 抽象层（只写一次，单独一个文件）==========
2
class LLM客户端:
3
    def 问AI(self, 问题):
4
        if 模型 == "claude":
5
            ...
6
        elif 模型 == "gpt":
7
            ...
8
        elif 模型 == "gemini":
9
            ...
10
        return 统一格式的结果
11

12
# ========== 业务代码（干干净净）==========
13
# app.py
14

15
llm = LLM客户端()
16

17
def 回答用户问题(问题):
18
    return llm.问AI(问题)
19

20
def 生成摘要(文章):
21
    return llm.问AI("请总结：" + 文章)
22

23
def 翻译(文本):
24
    return llm.问AI("请翻译：" + 文本)

换模型？只改 llm_client.py 这一个文件。 业务代码永远不用动。

核心区别不是”有没有 if-else”，而是 if-else 在哪#

三种”抽象层”方案#

用餐厅类比：

• LiteLLM = 你从中介公司请了一个现成的、培训好的前台小妹（免费开源，自己部署）
• OpenRouter = 你找了一个旅行社，你只说”我要去日本”，它帮你搞定一切（付费服务，不用运维）
• 自己写 Adapter = 你自己从零培训一个小妹（最灵活，最费人力）