如果你最近一直在看 OpenAI 的产品更新，很容易产生一种错觉：

• 一会儿是 Responses API
• 一会儿是 Web Search / File Search / Computer Use
• 一会儿是 Tracing / Evaluations
• 一会儿又是 Codex
• 到了 2026-04-08，OpenAI 甚至开始直接谈“company-wide agents”

很多人看到这里会下意识地问一句：

OpenAI 到底在推哪个东西？

我的判断是，答案不是某一个单独产品，而是一条越来越清晰的主线：

Responses API 负责成为 Agent 的统一执行入口，Tools 负责把能力接进来，Tracing/Evals 负责把执行过程变得可观测，Codex 负责把这套能力推进到真正的长任务执行场景。

如果把这几件事拆开看，会觉得 OpenAI 在同时做很多条线；但把时间线拼起来看，你会发现它们其实在收敛到一件事：

把 Agent 从“能演示”推进到“能上线、能观察、能持续优化”。

一、为什么很多人会看乱

过去一年里，开发者最熟悉的心智模型还是：

• 模型负责回答
• Function Calling 负责调工具
• 应用自己做状态管理
• 日志和评估自己补

这套模式不是不能做 Agent，而是越做越碎。

一旦任务开始变复杂，你很快会遇到这些问题：

• 一个请求里要不要多轮工具调用
• 检索、联网、文件搜索要不要自己拼
• Agent 执行链怎么追踪
• 结果差，是 prompt 问题、工具问题，还是状态问题
• 编码 Agent 真正长时间跑起来之后，怎么做闭环

所以真正的变化，不是 OpenAI 又发了几个新名词，而是它在把这些零散能力往一条统一链路上收。

二、时间线一拼，主线就出来了

我觉得最值得盯住的是 4 个官方时间点。

1. 2025-03-11：Responses API 发布

OpenAI 在《New tools for building agents》里给出的定位其实已经很明确了：

• Responses API 是构建 Agent 的新基础接口
• 它把 Chat Completions 的简洁性和 Assistants API 的工具能力合到了一起
• 官方明确建议：新集成优先从 Responses API 开始

更关键的是，同一波发布里一起出现的，不只是 API 本身，还有：

• 内建工具
• Agents SDK
• Tracing

这说明 OpenAI 从那时起，就已经不是在做“更强一点的对话接口”，而是在做 Agent 平台的执行层。

2. 2025-08-26：Assistants API 进入弃用节奏

在 OpenAI 官方迁移文档里，表述已经非常直接：

• Responses API 是构建 Agent 的未来方向
• 官方鼓励用户迁移
• Assistants API 的 sunset date 是 2026-08-26

这意味着平台收敛已经不是“趋势判断”，而是明确路线。

3. 2026-02-05：GPT-5.3-Codex 发布

OpenAI 在《Introducing GPT-5.3-Codex》里强调了一点：

Codex 不只是生成代码，而是可以承担长运行、研究、工具使用和复杂执行的任务。

这件事很重要，因为它把 Agent 的讨论，从“接口层”推进到了“执行层”。

换句话说，Responses API 解决的是“怎么组织 Agent 的调用链”，而 Codex 在告诉你：

现在这条调用链，已经可以真正跑更长、更复杂的工作了。

4. 2026-02-11 到 2026-04-08：Harness Engineering 和 Enterprise AI

OpenAI 在 2026-02-11 的《Harness engineering》里说得很透：

• 人类越来越少直接写代码
• 工程团队越来越多在设计环境、反馈回路和约束
• 关键不是让 Agent 更努力，而是让系统更“可被 Agent 看懂和利用”

到了 2026-04-08 的《The next phase of enterprise AI》，OpenAI 又把同样的逻辑往企业侧推进：

• 企业不想要彼此割裂的 AI 点工具
• 企业要的是统一的 AI operating layer
• 公司在往“company-wide agents”方向走

这两篇文章放在一起看，意思就很明确了：

OpenAI 的主线已经从“让模型更会答”，转向“让 Agent 真正变成生产系统的一层”。

三、我理解的 OpenAI Agent 主线

如果把这条主线压缩成一张图，大概是这样：

这里最核心的不是某个单点能力，而是这 6 层正在逐步扣在一起：

1. Responses API

这是统一入口。

它负责：

• 接受用户输入
• 协调多轮推理
• 驱动工具调用
• 汇总输出结果

从平台角度看，Responses API 像是 Agent 的控制平面。

2. Built-in Tools

这是 Agent 和现实世界的接口层。

OpenAI 官方文档和模型页已经把很多工具能力直接挂在 Responses API 之下，比如：

• Web search
• File search
• Computer use
• Code interpreter
• MCP

这说明 OpenAI 的方向不是让开发者自己拼一堆外围系统，而是越来越多把常见能力纳入统一运行时。

3. State

以前很多团队自己做 thread、history、turn chaining。

现在 Responses API 已经在往更统一的多轮上下文管理靠拢。官方迁移文档也明确提到：

• 它支持更自然的 multi-turn
• 通过 previous_response_id 或 conversation-like 机制去保持连续性

这让 Agent 不再只是“一次调用”，而更像一个持续运行的任务过程。

4. Tracing / Evals

这是最容易被低估的一层。

真正的 Agent 应用上线后，最贵的问题不是“第一版能不能跑”，而是：

• 为什么这一步调用错了
• 哪个工具最容易失败
• 哪个提示词造成了误判
• 哪类任务延迟最高

如果没有 tracing，Agent 很快就会变成一个不可调的黑盒。

所以我一直觉得，Tracing/Evals 不是附属功能，而是 OpenAI Agent 主线里非常核心的一部分。

5. Codex

Codex 是这条线里最偏“执行者”的一层。

它的意义不是再提供一个模型名，而是把上面这套平台能力，推进到真正的长任务执行、代码修改、验证、回归、持续迭代场景里。

如果说 Responses API 更像“编排入口”，那 Codex 更像“高级执行工人”。

6. Harness

Harness 不一定是一个单独产品，但它是 OpenAI 在 2026 年反复强调的工程思想：

• 让仓库更 legible
• 让工具更可访问
• 让 UI、日志、指标更能被 Agent 直接利用
• 让约束和反馈循环内化进环境

也正因为有了这层，Codex 才不是一次性演示，而是真正能持续工作的 Agent。

四、为什么这条主线比“选模型”更重要

很多团队现在还停留在一个旧问题上：

我应该选 GPT-5.4，还是选某个更强的 coding model？

但从 OpenAI 最近这些官方信号看，真正更重要的问题其实是：

你的系统到底是不是按 Agent 的方式在设计？

比如下面这两种团队，结果会完全不同。

团队 A：只是在原有聊天接口上加一点工具调用

• 有 function calling
• 没有统一状态层
• 没有 tracing
• 没有稳定的长任务执行环境

这种系统通常“能跑 demo”，但很难稳定扩展。

团队 B：把 Agent 当成一条平台链路来做

• 用 Responses API 做统一入口
• 把常用工具接进统一接口
• 从第一天就做 tracing/evals
• 对长任务单独设计 runtime 和 harness

这种系统才更像 OpenAI 正在推动的方向。

五、最小示意代码：为什么 Responses API 是主入口

下面这段代码不是为了展示全部细节，而是为了说明 OpenAI 现在的 Agent 心智模型。

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.OPENAI_API_KEY,
});

const response = await client.responses.create({
  model: "gpt-5.4-mini",
  input: "先联网搜索本周 AI Agent 的重要发布，再输出 5 条中文摘要。",
  tools: [
    { type: "web_search" }
  ]
});

console.log(response.output_text);

这段代码背后的关键不是“能搜索网页”，而是：

• 请求入口统一了
• 工具调用被纳入同一个接口
• 返回结果也走统一对象模型

一旦你把这一步迈出去，后面继续叠：

• file_search
• computer_use
• remote MCP
• tracing
• 更长的任务循环

都会变得顺得多。

六、生产环境更像下面这条链

如果是一个更真实的企业 Agent，执行链通常更接近这样：

所以你会发现：

• Responses API 不是“另一个接口”
• Tools 不是“附带能力”
• Tracing 不是“锦上添花”
• Codex 也不是“孤立模型”

它们正在一起构成 OpenAI 的 Agent 默认栈。

七、哪些判断我认为现在已经可以下了

截至 2026-04-17，基于 OpenAI 官方公开信息，我认为下面几条判断已经很稳：

1. Responses API 已经不是可选边缘接口

它已经是新集成的优先入口。

这是官方明确给出的方向，不是社区猜测。

2. Agent 的重点正在从“会不会调用工具”转向“能不能形成平台闭环”

闭环包括：

• 状态
• 工具
• 可观测
• 评估
• 长任务执行

3. Codex 的意义越来越偏执行层，而不是单纯模型宣传

Codex 把 OpenAI 的 Agent 叙事，从“平台能力”推进到“真实工作负载”。

4. 企业侧正在从 AI 点工具，转向统一 Agent layer

这点在 2026-04-08 的企业文章里非常明显。

八、我的结论

如果你只盯着最近 OpenAI 发了哪些模型名，很容易看不清大方向。

但如果把 2025-03-11 到 2026-04-08 这条时间线串起来，逻辑其实越来越清楚：

OpenAI 的主线不是某个单点产品，而是一条 Agent 平台栈。

它大致可以概括成：

• Responses API 统一执行入口
• Built-in tools / MCP 统一能力接入
• Tracing / Evals 统一观测和调优
• Codex 承担越来越重的长任务执行
• Harness 让整个系统真正可持续

所以，接下来真正值得问的问题，已经不是：

OpenAI 又出了什么新接口？

而是：

你的系统，是不是已经开始按这条 Agent 主线来设计了？

参考资料

• OpenAI, New tools for building agents, 2025-03-11
  https://openai.com/index/new-tools-for-building-agents/
• OpenAI API Docs, Migrate to the Responses API
  https://developers.openai.com/api/docs/guides/migrate-to-responses
• OpenAI, Introducing GPT-5.3-Codex, 2026-02-05
  https://openai.com/index/introducing-gpt-5-3-codex/
• OpenAI, Harness engineering: leveraging Codex in an agent-first world, 2026-02-11
  https://openai.com/index/harness-engineering/
• OpenAI, The next phase of enterprise AI, 2026-04-08
  https://openai.com/index/next-phase-of-enterprise-ai/