9 月 10 号，OpenAI 把 Codex 背后那套"Agent 执行框架"打包成了 Agents API 公测版。以前你要自己搭 planning、memory、tool use、并发编排；现在你配好 agent（模型、工具、任务描述）和运行环境，一次 API 调用就能拉起一个能跑数小时甚至数天的生产级 Agent。这不是又多一个 SDK，是造 Agent 的门槛被砍了一刀。
如果你最近还在纠结"LangGraph 还是 CrewAI"，建议先看完这篇，再决定要不要继续手搓。
一、发生了什么
当地时间 9 月 10 日，OpenAI 推出 Agents API 公测版，给开发者提供一个由 OpenAI 托管的云端 Agent 运行环境。
它的底层 harness，直接复用了 Codex 的智能体执行框架和基础设施。换句话说，跑你代码的那套沙箱、调度、状态管理，跟 ChatGPT 里写代码的 Codex 是同一套东西。
最关键的卖点只有一句话：一次 API 调用，就能创建一个生产环境级别的智能体，让它在云端持续运行——任务过程中的中间结果会被保存，执行时间可以覆盖数小时甚至数天。
测试期间 OpenAI 不收额外费用，但 token 和工具调用的钱照常算。
二、开发者最该关心的 4 个能力
1. 一次调用，跑好几天
传统做法里，长任务最头疼的是"进程挂了怎么办""状态怎么续"。Agents API 把执行搬到了云端托管环境，中间产物落盘，断点续跑不用你自己管。
import OpenAI from "openai";
const client = new OpenAI();
// 创建一次会话（session），即拉起一个生产级 Agent
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:
"调查 service-api 过去 30 分钟的 5xx 升高问题，" +
"把部署、错误、依赖分析分派给子 Agent，" +
"将结论、证据和修复建议保存到 /workspace/outputs。",
});
2. 上下文快爆了？它自己压缩
长对话最怕撞上上下文窗口上限。Agents API 内置上下文管理：会话接近限制时，自动压缩早期信息，让 Agent 能跨越多个上下文窗口继续执行。
这意味着你不用再自己写"摘要兜底"的中间层了——至少官方说它帮你兜了。
3. 多 Agent 协作，最多 3 个并发
复杂任务可以拆成多个独立子任务，由不同子 Agent 并行处理，再由主 Agent 协调汇总。官方示例里最多可配置 3 个并发子 Agent。
对写过多 Agent 编排的人来说，光是"调度 + 汇总 + 错误重试"这套，过去能写一整个模块。现在变成配置项。
4. 沙箱你说了算
Agent 可以跑在：
-
• OpenAI 托管沙箱（开箱即用） -
• 你自己的基础设施 -
• 合作伙伴环境：Cloudflare、Modal、Vercel、E2B、Daytona、DigitalOcean、Oracle、Runloop、Blaxel 等
同期还推出了 OpenAI Hosted Sandbox：不用自建沙盒，就能给 Agent 配置文件、软件包、技能和插件，用来跑代码、处理文件、生成任务产物。
三、和手写框架比，到底差在哪
把 Agents API 跟 LangGraph / CrewAI / AutoGen 摆一起看，结论很直接：
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
它省掉的是"重复造轮子"的部分。但你得想清楚一件事：哪些活该放自己的机器，哪些放托管沙箱——编排和执行解耦之后，边界划分才是新的核心竞争力。
四、账怎么算：长任务才是真成本
测试期免的是"额外管理费"，token 和工具调用照常计费。
一个能跑"数小时甚至数天"的 Agent，如果每步都调工具、每轮都喂长上下文，账单会非常诚实。别被"免费公测"冲昏头，上生产前先算清楚：
-
• 单次任务的 token 上限和预计消耗 -
• 工具调用次数（每次都可能单独计费） -
• 跑满 N 天的固定成本 vs 它替你省下的人力
建议：先用小任务测通链路，再逐步拉长运行时间，盯着账单调阈值。
五、给开发者的判断与行动清单
我的判断：编排与执行解耦是确定性趋势。自研框架里"搭基建"的那部分价值会被持续压缩，但边界治理（权限、密钥、沙箱归属、审计）会变成新的护城河——谁把这块做扎实，谁才不会被下一个"API 升级"反噬。
今晚就能做的 3 件事：
-
1. 拉个 demo：用一次调用跑通一个多步骤任务（比如"抓数据→清洗→出报告"），验证云端续跑是否如官方所说。 -
2. 重点测两个痛点：① 长任务成本曲线；② 上下文压缩的边界在哪、压缩后信息是否丢关键上下文。 -
3. 列一张决策清单：哪些敏感步骤必须放自有环境、哪些可以放心交给托管沙箱。
结尾
Agents API 不会让所有 Agent 框架一夜消失——但"造一个能干活的数字员工"这件事，已经从"组建一支工程团队"降级成了"填一张表"。
接下来一年，拼的不再是你会不会写编排代码，而是你想让 Agent 替你管多大的一块地盘，又留了多少护栏。
END
#agent #codex #openai #harness #LangGraph
如果这篇文章对你有帮助，欢迎点赞、在看、转发