OpenAI 这次发布 Agents API，最容易让人误会的地方，恰好是它看起来太简单了。官方说，一次调用就可以指定任务、模型、工具和运行环境。于是很多人会把它理解成“模型 API 多加了几个参数”，甚至进一步问：既然模型可以配置，那是不是也能把自己的 API 服务填进去？

答案要分层看。Agents API 提供的是一套托管的 Agent 运行框架，模型、工具和运行环境各自负责不同的事情。把这三层拆开，才能知道什么可以接，什么不能直接换。

图 1｜OpenAI 官方发布 Agents API，并展示 Harness 与 Sandbox 的关系，来源：https://openai.com/index/introducing-the-agents-api/

Agents API 不是一个新模型

官方文档对它的描述很直接：Agents API 让应用通过 OpenAI 管理的 API 使用 Codex harness。OpenAI 负责会话、编排、上下文压缩和恢复，应用则提供工具并选择执行环境。

它解决的是“一个 Agent 怎样持续把任务做完”，而不是单纯回答一次文本请求。Agent 可以保存 session 状态，执行代码、编辑文件、连接 MCP 服务，或把复杂任务拆给子 Agent。官方 Overview 把这套系统拆成 Agent、Environment、Session、Events and items 四个概念，分别对应能力配置、执行位置、持续状态和输入输出记录。

图 2｜Agents API 的核心概念、托管能力与计费说明，来源：https://developers.openai.com/api/docs/guides/agents-api/overview

模型层：model 决定谁负责推理

模型负责理解任务、生成计划，并决定什么时候调用工具。配置文档把它写成“Which model does the work”，和指令、工具、环境并列。

当前 Agents API 的公开配置包括 model、instructions、tools、推理和输出设置，环境选择 none、openai_hosted 或 self_hosted。官方 API reference 没有 provider、base_url 或自定义模型 endpoint 字段。

因此，按当前公开文档，Agents API 不能直接把任意第三方模型 API 配成底层推理服务。

工具层：外部 API 可以放在这里

如果 Agent 需要查业务数据、调用内部系统或执行一项外部能力，正确的接入位置是工具层。官方支持 MCP、自定义函数和内置工具。

一次请求可以同时配置模型和工具。例如官方示例把 MCP 服务写进 tools：

const session = await client.beta.agents.sessions.create({
  agent: {
    model: "gpt-6-astra",
    tools: [{
      type: "mcp",
      server_label: "observability",
      transport: {
        type: "http",
        server_url: "https://observability.example.com/mcp"
      }
    }]
  },
  environment: { type: "openai_hosted" },
  input: "Investigate the service error rate."
});

这条链路里，模型仍由 Agents API 选择和调用；Agent 决定调用 MCP 工具，MCP 服务访问外部 API 并返回结果。外部 API 是工具背后的服务，不是底层模型。

图 3｜官方单调用示例：模型、MCP 工具、环境和任务同时配置，来源：https://openai.com/index/introducing-the-agents-api/

运行环境层：代码和文件在哪里执行

Environment 决定 Agent 在哪里运行命令、读取文件、安装依赖和保存产物。官方文档提供 none、OpenAI 托管环境和自有环境几种选择；发布页还列出了多个沙箱生态合作方。

这层解决的是计算资源和数据边界，不负责更换模型。换成自有执行环境，不等于换了底层推理模型；接入 MCP，也不等于把 Agents API 变成普通模型接口。

官方 overview 还说明，模型调用按所选模型的 API 费率计费，OpenAI 工具和托管沙箱分别按各自费率计费。使用前要把模型 token、工具调用和容器资源放在同一份预算里看。

图 4｜运行环境选项与沙箱合作方，属于执行层而非模型层，来源：https://openai.com/index/introducing-the-agents-api/

别把 Agents API 和 Agents SDK 混在一起

OpenAI 的 Agents SDK 文档明确提到，非 OpenAI 模型或混合模型栈可以使用语言 SDK 的 provider 或 adapter。但这不等于 Agents API 也支持同样的模型替换方式：前者是托管服务接口，后者提供更靠近应用代码的运行和模型适配层。

什么时候选 Agents API

需要 OpenAI 托管的长任务、session 状态、工具调度和沙箱执行，可以优先考虑 Agents API。已有业务 API，就包装成 MCP 或自定义函数；需要自定义底层模型、统一多家模型或完全控制运行时，则使用 Agents SDK 的 provider/adapter 或自建 Agent 运行层。

Agents API 的价值，在于把 Codex 背后的长任务 harness 和执行基础设施开放出来。它并没有把模型、工具和运行环境揉成一个无法区分的黑盒。先分清自己要解决的是 Agent 编排、外部工具接入，还是底层模型选择，后面的配置和迁移才不会走错方向。

模型定下来之后，还要选 API 服务

Agent 架构选好、底层模型定下之后，接下来要解决的是具体使用哪项 API 服务。即使模型相同，也要逐项核对输入与输出价格、缓存计费、近期可用性、响应耗时和模型一致性，这些数据会直接影响长期任务的成本和完成率。

这正是模型详情页和测评报告能发挥作用的地方：先集中查看同一模型下各项 API 服务的价格与运行状态，再通过报告核对模型一致性、token 消耗和缓存表现。用这些数据缩小候选范围后，再安排小流量业务验证，会比拿一项服务直接上线更稳妥。

图5｜GPT-6-Astra 模型详情页，来源：OkenAI

图6｜模型线路测评报告，来源：OkenAI