2026 年 9 月 10 日，OpenAI 把 Agents API 开了公测，向所有开发者开放。官方标题写的是「用 Codex 的框架构建并运行云端智能体，由 OpenAI 全托管」。动作本身并不意外——真正值得琢磨的是它给出的两个零：Agents API 没有平台附加费，驱动它的 Codex harness 是 Apache-2.0 开源的。这篇文章分四块：它到底给了什么，好在哪，坏在哪，以及一个我实际算过一遍的成本账。

01先把这次发布讲清楚

先把最容易混淆的一点说在前面：Agents API 不是 2025 年 3 月那个 Agents SDK 的升级版，它是第三条路。SDK 是开源的框架，你自己部署、自己管状态；Agents API 是托管服务，OpenAI 替你跑那个循环。官方文档把三条路并列摆出来了，差别只在「谁拿着这个 loop」。

表面上它的接口小得有点意外：一个端点 POST /v1/agents/sessions，一个必须带的请求头 OpenAI-Beta: agents=v1。全篇只有四个概念要记：

• Agent：模型、指令、工具、MCP server 打包成的一份「岗位说明」；
• Environment：可选的执行环境，agent 在里面读写文件、跑命令；
• Session：一份持久的工作记录，可以活几小时甚至几天；
• Events / Items：会话进行中流出来的输入与输出。

用起来就是四步：建会话、给任务、用流式或 Webhook 看进度、然后往同一个会话里继续追加任务，或者中途插话改变方向。官方示例代码大概长这样：

import OpenAI from "openai";
const client = new OpenAI();

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" } },
    ],
    multi_agent: { enabled: true, max_concurrent_subagents: 3 },
  },
  vault_ids: ["vault_YOUR_VAULT_ID"],
  environment: {
    type: "openai_hosted",
    capability_directories: ["/workspace/capabilities/skills"],
  },
  input:
    "Investigate service-api's elevated 5xx rate over the last 30 minutes. " +
    "Delegate deployment, error, and dependency analysis to subagents. " +
    "Save findings, evidence, and recommended mitigation in /workspace/outputs.",
});

SDK 覆盖 Python、TypeScript/JS、Go、Java、Ruby，统一走 client.beta.agents.sessions.create(...)。文档里的参考模型是 gpt-6-astra。执行环境可以完全不配，也可以选 OpenAI 托管沙箱、你自己的机器或 VPC，或者九家合作方——Blaxel、Cloudflare、Daytona、DigitalOcean、E2B、Modal、Oracle、Runloop、Vercel。

配套还放了五个示例应用，这五个例子其实就把官方认定的目标场景说完了：故障响应 agent（动手之前先要人工批准）、Slack 机器人、写只读 SQL 的数据分析师、在沙箱里复现 bug 的 GitHub issue 调查员、按政策审文档的 reviewer。它们的共同点是——单个请求回答不完，中间要碰好几个外部系统。

02它到底省掉了什么

官方说这个 API 能「一次调用创建生产级 agent」，这句话的说服力不在「一次调用」，而在它后面那串默认被接手的活儿。把宣传词翻译成工程量，是这些：

• 会话保活：跨请求、跨断线维持一个还在干活的状态，而不是每轮重建上下文；
• 上下文自动压缩：会话接近上限时自动把早期内容压成摘要，工作可以跨越多个上下文窗口。而且它是分层做的——主 agent 和每个子 agent 各自独立压缩，不是一刀切；
• 故障恢复：会话中断后能从保存的记录里捡起来；
• 工具调度：tool search 按需加载工具定义（不用一开始就把整本工具手册塞进 prompt），MCP 和内置工具自动发现；
• 程序化工具调用：让模型生成一段 JavaScript 批量调工具、在代码里过滤聚合，只把关键结果带回上下文——这是默认开启的；
• 子 agent 并行：把任务拆开跑、主 agent 汇总，不用自己写编排。

官方那张三选一的表把话说得很明白，我照着翻译成一句人话：Agents API 是「低接入成本」，代价是低控制权；Responses API 是反过来。

运行时	谁在跑 agent 循环	任务之间的状态	接入成本
Agents API	OpenAI 托管的 Codex harness	会话配置、轮次、items 都存下来	低
Agents SDK	你的应用	你自己的存储或 SDK 会话	中
Responses API	你，从零开始	手动管历史	高

这里有个细节值得单独点出来：注意「环境」和「循环」是两件事。你完全可以让命令跑在自己的机器上，同时那个协调模型调用、压缩上下文、重启会话的循环，仍然在 OpenAI 那边跑。这跟「我把 agent 部署到了自己机房」是两个完全不同的承诺，后面讲安全的时候还会回来。

03这两个零是真的

先说好话，而且我认为这两条都没有水分。

第一个零是费用：Agents API 本身不收平台费。官方措辞是「使用 Agents API 没有额外费用，你只为 agent 消耗的 token 和工具付费」。这意味着你不需要先买一份「agent 平台套餐」才能开始，试错成本被压到了很低。对一个还在探索期的团队，这条比任何功能都实在。

第二个零是准入：驱动它的 Codex harness 是 Apache-2.0 开源的。仓库在 github.com/openai/codex，你可以直接去读它怎么管工具、怎么管记忆、怎么管上下文，而不是把它当一个黑箱。这条对「要不要把编排层交出去」这个决策很关键——至少你能先把源代码看一遍再决定。

把这两件事放在时间轴上，能看到一条挺清晰的线。2026 年 8 月，OpenAI 把 Codex harness 以 Apache-2.0 全面开源，仓库很快攒到十万级 Star；两周后，托管版的 Agents API 就来了。开源争的是开发者心智，托管收的是工作负载的账。同一时间段里 Anthropic 在推自己的托管 agent，DeepSeek 的 harness 走的是另一条路——大家都把重兵压在了同一个地方：执行层。背后的商业逻辑不复杂，模型的推理能力正在快速商品化，只卖 token 很难筑墙，所以争的是「谁来定义 agent 怎么调工具、怎么管数据、怎么编排业务」。

顺便说个有意思的数据。官方披露，不改模型权重，只做「保留推理痕迹 + 上下文压缩」这两项框架层面的调整，GPT-5.6 Sol 在 ARC-AGI-3 上的得分从 13.3% 升到 38.3%，输出 token 数量减少约六倍。这组数字我无法独立复现，但它指向的结论和它发布这么个 API 是一致的——同一个模型，套上不同的运行框架，表现可以是两回事。

04坏话要说得具体

三条，都不算致命，但每一条都会在实际决策里咬人。

第一，宣传数字要打折看。官方列了一串客户指标：Ciridae 的评估分数从 0.71 升到 0.85，子 agent 流程延迟降低 4 倍；SafetyKit 迁移后单案成本下降 60%；Hypha 把 harness 和沙箱分开之后，失败的 agent 响应少了 86%。这些数字是真的，但读法要注意三点：这些是提前参与内测、并且在正式发布前就已经迁移完成的团队，属于最好的一批样本；这些数字衡量的是「迁移相对他们原来那套自建方案」，不是「相对不用 agent」；还有，四个团队报的是四种不同的指标，它们之间没有可比性。

第二，接入等于把编排层交出去。这是最实的一条代价，而且没法绕。你自己写的那套会话管理、重试策略、上下文压缩逻辑，一旦换成 Agents API，就变成了跟着 OpenAI 的框架一起走——框架迭代你跟着动，模型版本你跟着升。对于「差异化在工具、数据和工作流」的团队，这笔账算得过来；对于要做多模型、要跨供应商的平台型团队，更值得采纳的可能反而是 GitHub 上那个开源 harness，而不是托管 API。

第三，账单会碎成好几块，而且工具链还看不见。标准模型调用只产生一笔账：token 进、token 出。Agents API 一笔任务可以产生三笔账单——模型推理、内置工具、托管容器——而容器和工具的条目不会标注是哪次会话、哪个开发者的任务产生的。更麻烦的是，它不走 /v1/chat/completions。如果你团队用 AI 网关（比如 LiteLLM 这类）统一拦截 OpenAI 兼容端点做用量看板和审计，那所有 Agents API 的调用你的网关是看不见的，会静默消失在统计之外。同时 API key 还多出两个新的权限位（api.agents.read、api.agents.write），需要单独决定怎么发。

05把账算一遍

「没有平台费」是准确的，但它不代表便宜，只代表计价方式。我按官方公布的费率写了个成本模型跑了一遍，下面所有数字都是算出来的，不是估的。

先看计费由哪三块组成：

计费项	谁在计费	费率
模型 token	按你选的模型	参考模型 gpt-6-astra：输入 $10 / 输出 $50（每百万 token）
内置工具	OpenAI	web search $10 / 1000 次调用，内容 token 另计
托管容器	OpenAI	每容器每 20 分钟会话，按内存档位

容器这一项的费率表值得单独贴出来，因为它决定了账单的下限：

内存档	每 20 分钟会话	折合每小时	折合每天
1 GB	$0.03	$0.09	$2.16
4 GB	$0.12	$0.36	$8.64
16 GB	$0.48	$1.44	$34.56
64 GB	$1.92	$5.76	$138.24

然后拿一个真实一点的任务来算：一次 30 分钟的服务故障调查，4GB 沙箱，20 轮工具调用，每轮输入 40,000 token（缓存命中 90%），输出 3,000 token。结果是模型 $4.52、容器 $0.18，合计 $4.70——沙箱只占 3.8%。

这就出现了一个很反直觉的结论。同一个 4GB 沙箱，如果任务做完了但你没删会话，容器空转 24 小时，费用是 $8.64，而同期模型费用是 $0。空转的那一天，沙箱占账单的 100%；满载的那半小时，沙箱只占 3.8%。换句话说，那 $4.52 的模型开销，恰好等于这个沙箱空转 12.6 小时的成本。

我一直觉得「agent 可以连续跑好几天」这个宣传口径和计价器是反向的。跑得久是能力，而账单的下限由容器决定：只要会话还活着，容器就按分钟走表，与它是否在干活无关。沙箱要无活动满 1 小时才会被删除，而这个超时不可配置——你没法设成 10 分钟来省钱。

下面这四组数字，是这个账里最容易被忽略的部分。

缓存经济学。gpt-6-astra 的缓存命中输入是 $1/1M，但缓存写入是 $12.50/1M，差 12.5 倍。一个 40,000 token 的上下文前缀，命中缓存被复用是 $0.04，被迫重建为缓存写是 $0.50。这件事为什么归框架管？因为故障恢复时是框架决定重发哪段前缀，这段前缀能不能命中缓存是它的决策，不是你的决策——但它直接决定了这次重发的价钱。

272K 定价悬崖。输入超过 272,000 token 时，升倍作用于整个请求，而不是超出部分。第 272,001 个 token 不是多付一点，是把前面 272,000 个一起重新定价：

输入 token	越线前的价	实际应付	较上一行
272,000	$2.72	$2.72	—
272,001	$2.72	$5.44	2.00x
500,000	$5.00	$10.00	1.67x

所以「自动上下文压缩」这个功能的价值，在账单上比在体验上更直接——它把会话压在悬崖这一侧。但压缩本身不是免费的：它是一次真实的推理调用，要读一遍旧上下文、写出一份摘要。按 8,000 输出 token 估算，从 20 万 token 的上下文里压一次大约 $2.40，从 100 万 token 里压一次要 $20 上下。压缩越频繁、压得越晚，越贵。

子 agent 是横向扩容。主 agent 那 20 轮算下来 $4.52；如果开启多智能体、4 个子 agent 各跑 10 轮（每轮输入 30,000 + 输出 2,000），子 agent 自己就是 $16.00。合计 $20.52，是单 agent 的 4.54 倍。并发上限是框架的一个参数，而每个子 agent 都带自己独立的上下文流——「开启多智能体」在账单上等于一次语义上的横向扩容。

5 分钟最低计费。容器按分钟计费，但每个会话最低算 5 分钟。在 4GB 档上，一个 60 秒就完成的活儿按 5 分钟结算，实际是多付 5 倍；150 秒的活儿多付 2 倍。把 agent 任务切成很多个极短的调用，会比预期贵得多。

06六个坑

前五条是我从官方文档的措辞里读出来的——这类坑的共同点是不会报错，只会让你多付钱，或者在出事那天才发现语义和你以为的不一样。

坑一：沙箱不会自己消失。删会话不等于关机器。托管沙箱靠删除会话来清理；自托管环境要你另外去关。而且「空闲」这个判断本身有竞态——你看到空闲就关机，可能正好撞上刚到的任务。反过来还有一条：自托管机器换掉之后，即使复用同一个环境 ID，原来的文件也不会回来，得靠你自己的存储或快照找。把「托管」的范围看清楚——OpenAI 接手的是会话运行逻辑，自备环境的生命周期和文件持久化仍然是你的活。

坑二：恢复不等于重新执行。官方文档写得很具体：执行中如果断连，可能导致某个工具失败，重连不会自动重新运行被杀掉的命令；进程崩溃后的待处理输入也没有无条件恢复的保证。所以重试之前必须先检查原请求的结果——读日志重复一次无所谓，但发通知、建工单、回滚服务，可能已经做了一半。幂等要自己实现，框架给的是保存与唤醒，不是「每个动作只执行一次」。

坑三：工具调用失败会被包在「成功」里。一轮结束返回 completed，只是「轮次结束」的信号，并不等于每个工具都成功执行了。模型完全可能在部分查询失败之后，给出一个看起来完整的结论。验收标准要自己定，而且要能区分「查询失败」和「模型没在思考」这两种状态——官方文档也提醒了，事件处理或生命周期处理的失败，会干扰进度更新和环境管理。

坑四：压缩会造成信息损失，而且丢的东西你事后看不见。把一条含糊的推测压成一条确定的结论，后续工作就会沿着错误的前提继续跑。缓解办法不是关掉压缩（关不掉），而是在业务侧留一条回到原始材料的路径：让 agent 把「查过什么、排除了什么、还有什么待查」写进一个明确的文件，重要日志保留可重新访问的位置。「存了什么」是业务记录，和平台内部的压缩算法是两回事——你保存了前者，不代表后者不会丢东西。

坑五：子 agent 共享同一台机器。子 agent 之间独立的只有上下文（思考），不是资源。只要接了执行环境，主 agent 和子 agent 用的是同一套文件系统——两个子 agent 同时改同一个报告，照样互相覆盖。还有一条文档里的细节：子 agent 目前可以继承 MCP 工具及其凭据，但暂不支持自定义函数工具。主 agent 能用的业务函数，要先确认子 agent 是否同样支持。

坑六：三套运行时的清理方式各不相同。Agents API 的会话、SDK 的会话、Responses 的对话、沙箱——文档明确说这是四种不同的资源，各管各的状态和清理。混合部署之后，「善后」这件事完全落在你自己身上。而且别忘了，这是个 public beta：SDK 里它挂在 beta 命名空间下，HTTP 上要走 OpenAI-Beta 头，changelog 里没有 GA 的时间表。接口形状现在还在动。

07到底托管给谁了

「agent 是否托管到 OpenAI」这个问题，答案是分层的，一刀切答会答错。我把它拆成三层来看会比较清楚：

• 编排层：托管。这个没有余地。agent 循环、上下文压缩、故障恢复、子 agent 协调，全在 OpenAI 那边跑。这是产品本身，不是可选项。
• 模型层：托管，且只管 OpenAI 自己的模型。开源 harness 你可以拿去读，但托管服务不承诺能接任意模型。文档说的是「在 OpenAI 平台支持的模型和工具内选择」。
• 执行层：你选。这一层是真的给了你自由——托管沙箱、自己的机器或 VPC、九家合作方，随便挑。

所以「我用了自托管沙箱，所以数据没出我的边界」这句话是错的。你可以让命令在自己的机器上执行，但会话本身、轮次记录、工具结果，仍然存在 OpenAI 侧。文档里那句「Agents API 支持的数据驻留目前仅限美国，且不支持零数据保留（ZDR），选择自托管沙箱不会让 Agents API 具备 ZDR 资格」——最后半句就是专门为这个误解写的。

还有一条容易漏的：vault_ids 这个字段说明密钥是托管给你管的。官方安全文档提醒得很直白——放进执行环境的凭据，agent 生成的代码就可能读到。所以凡是能动手的 agent，合理的起点都是先只给只读权限，把回滚、重启这类动作放到审批之后。在指令里写一句「不要误操作」，替代不了工具调用时的身份、参数和授权校验。

08第四道安全问题

安全问题通常被问成三个，我把它们和答案一起列出来，然后补一个没人问但更值得想的。

问「我的数据会不会被留着」——会。beta 阶段不支持零数据保留，而且自托管沙箱也不改变这一点。会话状态是为了让上下文不用重建才被保留下来的，会话和已发布的产物可以按需删除。但「可以删除」不等于「不保留」，这两个说法别混。对金融、医疗、法务这类把 ZDR 写进采购要求的团队，这条是硬阻断，不是小不便。

问「数据存在哪」——只在美国。欧盟团队拿它跑真实生产数据会有 GDPR 上的麻烦。同样，没有承诺时间表。

问「沙箱够不够安全」——它是起点，不是终点。托管沙箱提供受约束的工作空间，但权限要你自己配。网络策略有三种：允许外联、禁止外联、域名白名单；在继承模板里没有限制的时候，默认是允许外联的。想要更严的边界，得显式配。社区里有人实测过限制模式，访问外部域名会直接返回「Domain forbidden」——功能有效，但它是你要主动去开的东西。

第四道问题是这样：「哪一层拥有真正的权限？」

把 agent 放沙箱里，隔离的是「命令在哪执行」；但决定这个 agent 能碰什么的，是它手上的工具、凭据、隧道和网络策略的配置。这两件事经常被混成一件，而风险恰恰住在后者。一个典型反例：沙箱配得很干净，但 agent 继承了一个能写生产数据库的 MCP 凭据——沙箱一点问题都没有，出问题的是权限。

还有一层值得补上：模型可能在部分查询失败后给出有限的结论，而 API 返回「一轮完成」只是轮次信号。所以验收一份 agent 产物，至少应该要求它说明三件事——哪些现象支持判断、哪些查询失败了、还有什么无法排除。缺了部署数据就别急着把故障归因到发布上，这种「看起来很有道理」的错误结论，比明显的报错危险得多。

09我用不用得上

把这个 API 的好处和成本压成一个判断，其实只取决于一个问题：你手上这件事的瓶颈，是在「编排」上，还是在「工具、数据、工作流」上？

如果瓶颈在编排——你花了两周写上下文压缩逻辑，还没开始写 agent 真正的业务逻辑——那这个 API 的价值是立竿见影的，上面那 3.8% 的沙箱成本和 $4.70 的单价，比你自己搭一套还要便宜。反过来，如果你的壁垒本来就建在工具和数据上，编排层交出去并不吃亏，因为你没卖掉任何不可替代的东西。

但如果瓶颈在后者，托管就没那么值。你交出去的编排层不会带来差异化，而你多承担了锁定的代价。

就我自己而言，答案分两半：这个 API 的编排部分我会用，但它不是我现在要立刻迁上去的东西。理由有两条，都很实际。

第一，我不需要无人值守。我手上的 agent 任务几乎都是「我发起、我在场、我看结果」，中间可以重试、可以打断、可以重来。这种情况下，Agents API 最值钱的那部分能力——会话保活、跨天恢复、无人值守的可靠性——正好是我用不到的。而它要求我付出的东西（把编排层交出去、账单多出两块不可见的变量、多两个 API key 权限位），却是立刻生效的。

第二，我确实在意数据留在哪。我日常处理的东西里有一部分是自己的工作内容，我不希望它必须走美国驻留、且不能要求零保留的通道。这条现在是硬的。

但有一条我会认真试：把「会话本身就是产品」这一层用起来。比如一个能连续几天追同一件事的调查型工具，它要的不是「每次问答都更快」，而是「这件事一直在被推进」。这种形态在传统请求-响应模型里是别扭的，在 Agents API 里是天然的——任务建一个会话，第二天回来接着往下做。这类需求我没有，但如果哪天有了，这个 API 会是首选而不是自研。

10什么场景用得上

我按「谁在等结果」把常见场景分了一下，这个维度比按行业分更能说明问题——因为无人值守和有人兜底，是完全不同的可靠性要求。

场景	谁在等结果	现在用得上吗	判断依据
个人 / 小团队的自用工具	你自己	可以试，别急	没有合规压力，但用个人 key 跑长任务容易失控；从 4GB 沙箱加只读权限开始
公司内部工具	同事	最先值得试	数据不敏感、省运维，而且「把两周的编排工作省掉」在这类项目上收益最明显
故障响应 / 运维	值班的人	值得试	官方示例场景；但动手类操作必须先审批——别让 agent 自己决定回滚
碰个人数据的产品	真实用户	暂缓	美国驻留 + 不支持 ZDR，换沙箱也解决不了
受监管行业 / 跨国业务	采购和法务	不行	同上，而且现阶段没有 GA 时间表，采购流程没法走
跑几小时到几天的长任务	系统	谨慎	这是它的主场，但恢复语义有硬边界：被杀的进程不会自动重跑，幂等要自己保证
多模型平台 / 中间层产品	——	用开源那半	托管 API 把你锁在 OpenAI 的模型上；该采纳的是 GitHub 上的开源 harness，不是这个 API

如果只给一条行动建议：先用一个不敏感的、边界清晰的任务试，具体验三件事。一是工具是否真的到位（尤其 MCP 连得上、凭据范围收得住）；二是执行被中断之后，状态显示是不是诚实的——它到底在「等工具返回」还是「模型还在想」，这两件事在你的界面和日志里必须能分开；三是产物能不能活到会话结束之后。这三件里任何一件不成立，都说明你的集成还没到能上生产的程度，跟 API 本身好不好无关。

有两件事我认为现在就该写进代码，而不是等出事再补：任务结束就删会话（别指望那一小时的超时），以及把所有会动手的操作做成幂等。这两条加起来几乎零成本，但它们对应的正是这个 API 最容易让你多付钱、或者在出问题那天让你判断不了的两种情形。

11信息来源与参考资料

• OpenAI，《Introducing the Agents API》，2026-09-10。含示例代码、客户引言与开源说明。
• OpenAI 开发者社区帖《Introducing the Agents API and hosted sandboxes》，2026-09-10。
• OpenAI 开发者文档：《Agents API overview》《Agents》（三种运行时对比）、《Building agents》、API changelog 2026-09-10 条目。
• 费率数据：OpenAI 定价页，模型费率与容器费率以 2026-09-11 抓取为准；容器按每容器每 20 分钟会话计费，最低 5 分钟。
• 沙箱合作方九家：Blaxel、Cloudflare、Daytona、DigitalOcean、E2B、Modal、Oracle、Runloop、Vercel。
• 本文所有金额均为按公开费率计算的模型结果，脚本为同目录 cost_model.py，完整输出见 cost_report.txt。涉及假设：模型 gpt-6-astra、缓存命中率 90%、压缩摘要按 8,000 输出 token、子 agent 各 10 轮。未做真实调用验证，实际账单以 OpenAI 官方计费为准。
• ARC-AGI-3 得分 13.3% → 38.3%、输出 token 减少约六倍等数据来自 OpenAI 公开发布材料，未做独立复现，已在正文中标注。
• 三张配图由脚本绘制：托管边界图、成本对比图、执行环境对比图。

微信公众号

欢迎关注「字与码」

如果这篇文章对你有用，也欢迎在微信里继续关注后续更新。

X

X / Twitter

关注 @ax2_zicode

更即时的技术观察、新文章提醒和一些短想法会发在 X 上。