回顾 OpenAI 的一年，如果只列出模型名称，很快会陷入版本迷宫。更清楚的观察方式是看产品的“工作单位”怎样变化：早期用户向聊天框提一个问题，后来模型在回答前进行更长推理，再后来系统开始调用网页、文件、代码和计算机工具，完成持续数分钟甚至数小时的任务。
本文覆盖 2025 年初至 2026 年 8 月 30 日的关键变化，只引用 OpenAI 官方发布与文档确认时间线。官方基准和客户案例属于厂商材料，适合说明产品定位，不应被当成独立性能证明。
## 2025年：从模型接口转向Agent基础设施
2025 年 3 月，OpenAI 发布 Responses API、内置网页搜索与文件搜索、计算机使用工具，以及 Agents SDK 和追踪能力。这个组合的重要性不在于多了一个接口名称，而在于开发者开始用统一响应对象组织模型输出、工具调用和多步执行。
传统 Chat Completions 更像一次对话请求。Agent 系统还要管理工具参数、状态、重试、权限和执行记录。一个网页搜索失败，系统是换查询、等待还是交回用户；一个文件结论来自哪一段；一次工具调用花了多少时间，都需要在模型之外处理。
同年 7 月，ChatGPT agent 把深度研究、网页操作和对话整合为面向用户的执行系统。它显示了一个明显方向：模型不只解释“应该怎么做”，还尝试在受控计算机环境中完成步骤。
## GPT-5把快答与深度推理放进统一体验
2025 年 8 月发布的 GPT-5，在 ChatGPT 中采用快速模型、推理模型和路由器组成的统一系统。系统卡说明，路由器会根据问题类型、复杂度、工具需要和用户意图决定使用哪条路径。
这种设计减少了普通用户手动挑模型的负担，也带来新的评测问题。同一句提示可能因路由或推理设置得到不同成本与时延。开发者若需要稳定复现，仍应记录具体 API 模型、推理强度、工具配置和日期。
2025 年 12 月的 GPT-5.2 继续把重点放在专业工作、长上下文、视觉、工具调用和长时间 Agent。模型发布的主叙事已经从“回答更多知识题”转到“能否在真实材料和工具中完成任务”。
## 2026年：能力层级与计算预算变得显式
2026 年 7 月发布的 GPT-5.6 家族采用 Sol、Terra、Luna 三个能力层级，分别面向高能力、平衡和成本效率场景，并在 ChatGPT Work、Codex 与 API 中提供不同推理强度。
这反映了模型产品化的一个变化：用户不再只选择“哪个模型”，还选择为任务投入多少计算。简单分类若使用最高推理预算，会浪费时间与费用；复杂代码迁移若预算过低，又可能在中途丢失约束。
官方发布称最高能力设置可以协调并行工作流，但这仍需在真实项目中验证。并行 Agent 能扩大搜索范围，也会增加重复工作、合并冲突和工具调用成本。最重要的指标不是启动了多少 Agent，而是合格结果是否更快、更便宜。
## Codex让“对话”变成可检查的工作过程
代码 Agent 的价值不只是生成函数。它可以读取仓库、搜索引用、修改多个文件、运行测试并根据失败继续迭代。用户看到的不再是一段建议，而是一组可审查的差异、命令结果和交付物。
OpenAI 2026 年发布的内部使用研究显示，其员工越来越多地把 Codex 用于长时间任务，甚至扩展到非开发岗位。这是公司自身的观察，不能代表所有组织，却说明 Agent 的使用单位正在从短对话变为委派任务。
团队引入代码 Agent 时，应记录完成率、测试通过、人工审查时间、回滚次数和隐藏故障。生成代码量或 Agent 运行时长都不是生产力本身。一个运行两小时却需要重写的任务，不如一个十分钟内给出准确诊断的任务。
## 年度回顾也要记录下线与迁移
技术盘点最容易只写发布，不写消失。OpenAI 的 Sora 产品已在 2026 年 4 月停止提供；2025 年推出的 Agent Builder 和 Evals 产品也在 2026 年 6 月宣布逐步关闭，并建议分别迁移到 Agents SDK 或 Workspace Agents 等路线。
产品下线不等于相关技术方向失败，但会直接影响用户。视觉流程、评测集、版本和追踪若只保存在某个托管界面里，迁移成本会很高。关键工作流应保留可导出的提示、代码、测试样本和执行记录。
API 别名与界面默认模型也可能变化。生产系统应固定版本，监控弃用通知，并在替换前回放真实任务。年度回顾若不包含迁移成本，就会高估连续性。
## 五条主线比型号清单更有用
第一条是模型统一。快速响应、深度推理、视觉与工具使用逐渐被放进一个可路由体验。第二条是从回答到行动，Responses API、Agents SDK、ChatGPT agent 和 Codex 都围绕多步执行。
第三条是计算分层。模型家族与推理强度让能力、速度和成本之间的选择更明确。第四条是可观察性，追踪工具调用、执行路径和评测结果成为 Agent 工程的一部分。
第五条是生命周期。快速发布伴随快速替换，开发者需要把可迁移性当作架构要求，而不是等停服后再处理。
## 怎样独立判断这一年的进步
准备一组跨版本固定任务，比抄录厂商榜单更有价值。任务应包含短问答、长文档、图像理解、结构化输出、网页研究、工具失败恢复和代码修改。
每次记录正确率、证据、首字延迟、总时间、工具调用数、成本和人工修改。Agent 任务还要设置明确停止条件，避免系统靠更多调用堆出答案。对相同任务比较快模型、深度推理和多 Agent 路线，才能知道额外计算是否值得。
不要只测成功样本。人为删除一个文件、制造网络超时、提供互相冲突的来源，观察系统是否说明问题并安全退出。真实工作中，恢复能力往往比一次演示中的最高分更重要。
## 回顾之后的实际行动
若正在使用旧聊天接口，把新项目优先建立在 Responses API 与当前 SDK 上，同时检查旧端点的维护状态。若工作流依赖托管可视化工具，立即导出提示、评测与配置。
模型升级时不要一次替换全部流量。先固定 50 到 100 个真实任务做影子评测，再小比例切换；对成本敏感的简单任务使用较轻层级，对复杂任务按失败信号升级推理预算。
过去一年最显著的变化，并非某个模型在一张榜单上多了几分，而是 AI 产品开始接管更长的任务链。能力扩大后，工程重点也从“如何问得漂亮”转向“如何授权、观察、验证和迁移”。这才是年度盘点最值得留下的结论。
## 官方资料