2026 年上半年，OpenAI API 的更新密度明显加快。几乎每个月都有新模型发布，几乎每两周就有接口层面的能力增补。如果只看单条 Changelog，很容易觉得这只是「又发了一个更强的模型」；但如果把这些更新串起来看，会发现一条清晰的演进主线：

GPT API 正在从「让模型说话」的聊天接口，变成「让模型干活」的 Agent 运行时。

这条主线贯穿了模型迭代、接口重构、工具能力扩展和治理能力增强。理解这条主线，比记住每一个新参数名更重要——因为它决定了开发者接下来该怎么选型、怎么迁移、怎么设计应用架构。

一、三条接口线：Chat Completions、Assistants、Responses

要理解 GPT API 今天的形态，得先看清它走过的三条路。

1. Chat Completions：简单、普及、但不够用

/v1/chat/completions 是大多数开发者接触 OpenAI API 的起点。它的设计哲学很直接：你发一组消息，模型回一段文本。简单、稳定、生态成熟。

但 Agent 时代的需求很快就超出了这个模型的边界：

• 多轮对话的状态要开发者自己维护
• 工具调用结果要开发者自己拼装回上下文
• 推理模型的 reasoning token 要开发者手动传递
• 内置工具（搜索、代码执行、MCP）无法原生接入

Chat Completions 并没有被废弃，官方仍持续为其发布新模型（GPT-5.4、GPT-5.5、GPT-5.6 均支持）。但越来越多的高级能力开始只在 Responses API 提供——比如 GPT-5.5 Pro、GPT-5.6 的 Programmatic Tool Calling 和 Multi-agent。

2. Assistants API：一次失败的中间态

2023 年推出的 Assistants API 试图解决「有状态的 Agent」问题：Thread、Run、内置文件检索和代码解释器，把 Agent 需要的运行时能力打包成了一个产品化的接口。

它做对了几件事——证明了开发者确实需要服务端托管的状态管理和工具执行。但它也暴露了几个根本问题：接口复杂、延迟偏高、灵活性不足、难以跟上推理模型和多模态能力的快速迭代。

2025 年 8 月，OpenAI 宣布 Assistants API 将于 2026 年 8 月 26 日 下线。官方明确表示：Responses API 吸收了 Assistants 的核心改进，是未来构建 Agent 的方向。

3. Responses API：新的默认原语

/v1/responses 是 OpenAI 当前主推的接口原语。它的设计目标很明确：像 Chat Completions 一样简单，像 Assistants 一样强大，同时为推理模型和 Agent 工作流专门优化。

几个关键设计决策：

官方的说法很直白：Chat Completions 会继续支持，但 Responses 是推荐所有新项目使用的接口。这不是营销话术，而是能力分叉的现实——越往后的新功能，越只在 Responses 落地。

二、模型迭代：能力阶梯，而非简单换代

2026 年的模型发布节奏，几乎形成了固定的「家族化」模式：每个大版本推出旗舰版（Sol/Pro）、平衡版（Terra/mini）、高效版（Luna/nano），能力逐级下放，价格逐级降低。

GPT-5.3：从 ChatGPT 到 API 的桥梁

• gpt-5.3-chat-latest：指向 ChatGPT 当前使用的 Instant 快照，方便开发者对齐 ChatGPT 体验
• gpt-5.3-codex：面向代码场景的专用模型
• Responses API 开始支持 WebSocket 模式和 phase 字段（区分中间 commentary 与最终答案）

这一阶段的信号是：API 开始主动区分「对话体验」和「任务执行」两种场景。

GPT-5.4：Agent 能力的第一次系统性补齐

3 月发布的 GPT-5.4 是 Agent 演进的一个里程碑，因为它首次把三类能力打包进了同一个模型：

1. 更长的上下文与 Compaction

1M token 上下文窗口，配合 Compaction API，让长时间运行的 Agent 工作流有了可行的内存管理方案——不必在上下文爆满时粗暴截断，而是可以有策略地压缩历史。

2. Tool Search：按需加载工具

过去，所有工具定义都要塞进 system prompt，token 消耗大、缓存效率低。Tool Search 让模型在运行时按需检索和加载工具，显著降低了大型工具面的 token 开销，也改善了 prompt caching 的命中率。

3. Built-in Computer Use：从文本到界面

通过 Responses API 的 computer 工具，模型可以基于截图与 UI 元素交互——点击、输入、滚动。这标志着 GPT API 从「处理文本和文件」扩展到「操作图形界面」。

此外还有 GPT-5.4 Pro（Responses 专用，更多算力）、mini 和 nano 版本的能力下沉。

GPT-5.5：专业工作的默认选择

4 月发布的 GPT-5.5 定位为「复杂专业工作」的前沿模型。相比 5.4，它更像一次全面打磨：

• 1M token 上下文，完整保留 Agent 工具链（computer use、hosted shell、apply patch、Skills、MCP、web search、tool search）
• reasoning_effort 默认值改为 medium——官方在引导开发者把推理深度当作可调控的参数，而非开关
• 仅支持 extended prompt caching（24h），不再支持 in-memory 缓存——这是成本优化的重要信号
• GPT-5.5 Pro 仅通过 Responses API 提供，面向需要更多算力的高难任务

同期发布的 GPT Image 2 也值得关注：图像生成从按张计费转向 token 计价，并支持 Batch API 50% 折扣，说明多模态能力的商业化也在向 Agent 工作负载靠拢。

GPT-5.6：Agent 运行时的成型（2026 年 7 月）

GPT-5.6 是目前最新、也最能体现演进方向的一次发布。三个模型定位清晰：

但模型本身只是表象。GPT-5.6 真正重要的是它在 Responses API 上引入的四项机制——它们共同构成了「Agent 运行时」的核心组件：

Programmatic Tool Calling

模型不再只是逐个调用工具、等结果、再决定下一步。它可以在内存中编写并运行程序，在程序内部协调多个工具、处理中间结果、做条件分支。关键优势：兼容 Zero Data Retention (ZDR)，工具协调逻辑在服务端沙箱内完成，敏感数据不必反复往返客户端。

Multi-agent Orchestration（Beta）

单请求内并发运行多个子 Agent，各自处理子任务，最终由主 Agent 汇总。支持 spawn_agent、followup_task、send_message 等动作。配合 ultra reasoning effort，默认启用四 Agent 并行——这是从「一个模型做所有事」到「一个请求调度一组劳动力」的范式转变。

显式 Prompt Caching 控制

GPT-5.6 起支持 cache breakpoints（在 prompt 中标记缓存锚点），缓存最短保留 30 分钟。写入缓存按 1.25x 输入价格计费，读取享受 90% 折扣。这让长 system prompt 和多轮 Agent 工作流的成本变得可预测。

Reasoning Effort 分级扩展

从 low → medium → high → xhigh → max → ultra，推理深度不再是非此即彼的选择，而是可以根据任务复杂度精细调配的计算预算。

三、工具链演进：从 Function Calling 到 Programmatic Orchestration

如果把 GPT API 的工具能力按时间线排列，会看到一条清晰的升级路径：

Function Calling（2023）
    ↓ 开发者定义工具，模型决定何时调用
Built-in Tools（2024）
    ↓ web search、code interpreter、file search 由服务端托管
MCP Support（2025）
    ↓ 开放协议，连接任意外部工具和数据源
Tool Search（2026.03）
    ↓ 运行时按需加载，降低 token 开销
Computer Use（2026.03）
    ↓ 截图式 UI 交互
Programmatic Tool Calling（2026.07）
    ↓ 模型编写程序协调工具，ZDR 兼容
Multi-agent（2026.07）
    ↓ 单请求内并行子 Agent

每一步解决的是上一阶段的核心瓶颈：

• Function Calling 解决了「模型能触发外部动作」，但开发者要处理所有编排逻辑
• Built-in Tools 解决了「常见工具不必自己实现」，但工具集合固定
• MCP 解决了「连接任意企业系统」，但每次调用仍有往返延迟
• Tool Search 解决了「工具太多撑爆上下文」，但仍是逐个调用模式
• Computer Use 解决了「操作图形界面」，但受限于截图-动作的循环
• Programmatic Tool Calling 解决了「复杂编排的往返开销和 ZDR 合规」，让模型在沙箱内完成多步工具协调
• Multi-agent 解决了「单 Agent 能力上限」，通过并行化突破复杂任务的瓶颈

这个演进路径说明：OpenAI 在工具层的策略不是「给模型更多工具」，而是「给模型更好的工具运行时」。

四、接口层面的「隐性」重要更新

模型和工具能力之外，还有一批看似不起眼、实际影响工程决策的基础设施更新。

Prompt Caching 策略变化

• 5 月：非 ZDR 组织默认 prompt_cache_retention 从 in_memory 改为 24h
• 7 月：GPT-5.6 支持显式 cache breakpoints，30 分钟最短缓存寿命

这意味着：长 prompt 的 Agent 应用，成本结构正在根本性改变。 过去开发者需要精心设计 prompt 结构来命中缓存；现在可以更激进地使用长 system prompt 和工具定义，因为缓存保障更长了。

安全与治理能力

• Moderation 分数内嵌（6 月）：请求中传入 moderation 对象，同一响应返回输入和输出的审核分数——不必额外调 Moderation API
• Safety Usage Dashboard（6 月）：基于 safety_identifier 追踪被拦截的请求
• Workload Identity Federation（5 月）：工作负载用外部身份令牌换短期 OpenAI token，告别长期 API Key
• Secure MCP Tunnel（5 月）：企业客户通过 tunnel-client 连接私有 MCP 服务，不暴露到公网
• Admin API 增强（5 月）：spend alerts、模型白名单、数据保留设置、hosted tool 权限

这些更新的共同主题是：API 在从「开发者工具」变成「企业级平台」。 当 Agent 能发消息、改数据、走审批时，身份、权限、审计、成本管控就不再是可选功能。

Realtime API 的成熟

Realtime API 经历了从 Beta 到正式版的完整周期：

• 5 月：Beta 下线，发布 gpt-realtime-2、translate、whisper
• 7 月：gpt-realtime-2.1 改进识别和打断处理

Realtime 与 Responses API 的 Agent 能力是互补关系——前者管「语音实时的听和说」，后者管「复杂任务的想和做」。

多模态扩展

• Sora API：角色引用、20 秒生成、1080p、视频扩展、Batch API
• GPT Image 2：token 计价、灵活尺寸、Batch 50% 折扣
• Web Search 图片结果（6 月）：搜索工具返回图片，不再只是文本摘要
• input_file 扩展（2 月）：支持更多文档、表格、代码文件类型

五、正在消失的东西：迁移压力是真实的

演进不只有加法，也有减法。几个重要的下线时间表值得所有在用开发者关注：

其中 Assistants API 的下线影响面最大。如果你的生产系统还在用 Thread/Run 模型，剩下的时间窗口已经不多了。官方提供了迁移指南，核心映射关系是：

• Assistant → System prompt + Tools 配置
• Thread → Conversation 或 previous_response_id 链
• Run → 单次 Response 请求
• File Search / Code Interpreter → Responses API 内置工具

六、开发者该怎么理解这些变化

把所有更新归纳成三个判断，供架构决策参考。

判断一：Responses API 不是「新接口」，而是「新运行时」

它承载的不只是对话，而是状态管理、工具执行、推理保留、多 Agent 编排的完整运行时。继续只用 Chat Completions 不是不行，但你会系统性错过过去半年最重要的能力增量。

建议：新功能用 Responses API；存量 Chat Completions 按模块逐步迁移，优先迁移需要工具调用和推理链路的流程。

判断二：Agent 成本模型正在从「按 token 计费」转向「按工作负载计费」

Prompt caching 默认 24h、cache breakpoints、Batch API 折扣、容器按分钟计费（取代 20 分钟保底）——这些变化指向同一个方向：OpenAI 在鼓励长运行、高缓存命中、批量执行的 Agent 工作负载，同时降低短任务和试探性调用的成本。

设计 Agent 应用时，应该把 caching 策略和 reasoning effort 当作一等公民来规划，而不是事后优化。

判断三：API 的竞争力正在从「模型智商」转向「工程完整度」

GPT-5.6 Sol 当然更强，但开发者真正关心的可能是：

• 我的 Agent 能不能连上公司内网的 MCP 服务？（Secure MCP Tunnel）
• 我的工具编排能不能通过 ZDR 审计？（Programmatic Tool Calling）
• 我的多步任务能不能并行加速？（Multi-agent）
• 我的成本能不能预测和控制？（Prompt caching + Admin spend alerts）

模型能力的竞争仍在继续，但 API 平台层的竞争已经开始了——谁能提供更好的 Agent 运行时、治理工具和成本透明度，谁就能留住企业开发者。

七、结语：接口即产品

回顾 GPT API 从 2023 到 2026 上半年的演进，最本质的变化不是某个模型分数又涨了多少，而是 接口本身的语义在变：

• 2023 年，API 的回答是：「我给你一段文本。」
• 2024 年，API 的回答是：「我给你一段文本，顺便帮你调了个工具。」
• 2025 年，API 的回答是：「我帮你搜了、算了、看了屏幕，这是结果。」
• 2026 年，API 的回答是：「我写了段程序协调了五个工具，派了三个子 Agent 并行处理，这是汇总。」

每一次升级，都在把开发者从「编排者」推向「监督者」——你定义目标和边界，运行时负责执行细节。

对于正在构建 AI 应用的团队来说，现在可能是重新评估技术栈的好时机：

• 你的接口选型是否还停留在 Chat Completions 时代？
• 你的工具集成是逐个 Function Calling，还是可以利用 Programmatic Tool Calling？
• 你的成本模型是否考虑了 24h prompt caching 和 reasoning effort 分级？
• 你的安全治理是否跟上了 Moderation 内嵌和 Workload Identity 的节奏？

GPT API 的演进还没有停止。Assistants 的退场、Responses 的成熟、Multi-agent 的 Beta——这些都在暗示，下一个半年的主题，可能是从「单 Agent 应用」走向「多 Agent 系统」的工程化落地。

那时候，接口不再只是模型的包装纸。它本身，就是 AI 应用的基础设施。

文章来自：51CTO