OpenAI Agents API 将 Codex 基础设施迁移至云端
OpenAI 于 9 月 10 日推出处于公开测试阶段的 OpenAI Agents API，通过一个 API 向所有开发者开放其 Codex 智能体基础设施。这一发布将更多内容从模型推理迁移至 OpenAI 云端，提供托管会话、编排、上下文处理、恢复能力以及可选的执行环境。
这一转变带来了真正的张力。开发者可以不再自行搭建长时间运行智能体所需的大部分基础设施，但也会将更多运营控制权置于 OpenAI 平台之内。决策不再局限于哪种模型能给出最佳答案，也涉及在智能体连续工作数小时、调用工具、委派任务并从中断中恢复时，由谁负责管理它。
该 API 进入的市场中，开发者已拥有智能体框架、云服务和自定义编排系统。OpenAI 押注于：经 Codex 验证的基础设施能够成为其他产品共享的运行时环境。公开测试将检验这种便利性是否足以抵消人们对控制权、可移植性、可观测性和不可预测用量的担忧。
OpenAI Agents API 管理的不只是模型调用
这一发布使 OpenAI 从模型端点转变为智能体持续工作循环的运营者。
传统模型请求的生命周期相对狭窄：应用发送输入，模型生成输出，应用决定下一步如何处理。构建智能体的开发者则必须自行补充周边机制，包括状态管理、重试、工具路由、后台任务和执行隔离。
OpenAI Agents API 将其中多项职责置于一个托管接口之后。根据公开测试公告，OpenAI 运行并维护与 Codex 所使用相同的智能体 harness 及配套基础设施。Harness 是协调模型调用、工具、上下文和任务进度的控制层。
开发者创建会话，并指定任务、模型、指令、工具和环境。会话是持久化的智能体实例，而非一次性提示词。它可以接收工作、发出进度事件、暂停等待输入，并在更长的运行周期中持续执行。
这种区别至关重要，因为智能体往往在模型本身之外出错。能力强大的模型仍可能丢失重要上下文、调用错误工具、重复已完成的工作，或让任务半途而废。因此，生产团队会在围绕每次模型调用的控制层上投入大量工程精力。
OpenAI 现在提出负责管理会话、编排、上下文压缩和恢复。上下文压缩是指在会话接近上下文限制时，对先前活动进行浓缩。其目标是在不要求开发者自行实现这一过程的前提下，保留后续步骤所需的信息。
该 API 还支持代码执行、文件编辑、MCP 服务器和制品创建。MCP，即 Model Context Protocol，是连接智能体与工具、数据源的标准接口。自定义函数和内置工具也可以成为智能体可用能力的一部分。
这并不只是聊天机器人的托管版本。智能体可以调查事故、审阅文档、分析仓储数据，或复现软件缺陷。它可以保留工作环境，并生成供应用稍后获取的文件。
OpenAI 表示，公开测试面向所有开发者开放。公司不对 API 层单独收取访问费用，但客户仍需为所选模型、工具和托管计算用量付费。这种结构降低了测试服务所需的投入门槛，但并不意味着持续运行智能体工作负载无需成本。
此次发布还引入了一项重要的架构分离。OpenAI 可以运营 harness，而开发者可选择智能体在何处执行命令和访问文件。这一选择是公司试图覆盖实验性项目和受控企业环境的核心。
OpenAI 云端智能体让编排承压
最直接的压力落在维护自定义智能体基础设施的团队身上，而不是编写单个提示词的开发者。
早期智能体项目通常从一个简短循环开始：模型接收目标、选择函数、读取结果，再决定是否调用另一个函数。当任务持续时间更长或会影响真实系统时，这种方式的运营难度便会提高。
生产级循环需要持久状态、重试行为、权限控制、日志、超时处理和明确的终止规则。它还必须应对模型调用之间发生的故障。丢失的进程不应抹去智能体已完成的工作，也不应导致其重复执行外部操作。
OpenAI 云端智能体将这类运营层的大部分内容打包至平台中。Agents API 概览通过四个概念描述智能体：其配置、环境、会话，以及事件和项目流。这些概念共同为应用提供了结构化方式，以创建工作、监控工作并延续工作。
这一设计给围绕早期 API 构建类似系统的内部平台团队带来压力。它们的自定义编排仍具备灵活性，但如今每个组件都需要说明其存在价值。托管替代方案改变了自建基础设施与改进面向用户工作流之间的权衡。
压力同样波及独立智能体框架。许多框架帮助开发者定义工具、路由任务并协调专门化智能体。OpenAI 的入场并不会让这些框架过时，但它确实在其软件层抽象旁边放置了一个持续维护的云端运行时。
云服务提供商也面临类似挑战。智能体服务日益成为将模型与企业数据、安全策略和计算资源连接起来的方式。即使开发者在其他地方运行执行环境，OpenAI 现在也在编排层争夺这类工作负载。
公司的优势在于它与 Codex 的联系。OpenAI 表示，其已从大规模运行 Codex 和 ChatGPT for Work 中积累经验，包括持续数小时或数天的任务。开发者实际上获得了一个在 OpenAI 自身产品中不断完善的运行模式。
这段历史颇具价值，但并不能决定市场格局。Codex 任务通常涉及软件仓库、终端、文件和结构化审查。其他智能体可能处理医疗记录、财务审批、客户沟通或实体运营。这些领域对可靠性和治理有不同要求。
因此，此次发布改变了自建与采购之间的边界。团队可以继续掌控每个编排组件，也可以将 OpenAI harness 视为托管基础设施。这一决策类似于此前从自管数据库转向云数据库服务的变化。
当编排不可或缺却并非差异化能力时，托管路线的理由最为充分。产品团队从重建上下文压缩或重连逻辑中获得的客户价值有限。其优势可能来自专有工具、可信数据、工作流设计或专业化用户体验。
当执行策略定义产品本身时，自定义基础设施仍然具有价值。安全平台可能需要异常严格的审批关卡。受监管企业可能需要对日志、保留策略、网络边界和事件响应拥有更深入的控制。研究系统可能需要非传统的协调策略。
公开测试迫使这些团队识别其技术栈中哪些部分具有战略意义。任何仅仅用于维持智能体运行的功能，如今都要与 OpenAI 托管服务竞争。
核心机制是 Harness 与 Sandbox 的分离
OpenAI 的核心设计选择，是将协调智能体的一方与智能体执行行动的地点分开。
Sandbox 是隔离的计算环境，智能体可在其中运行命令、读取文件、安装获批准的依赖项并创建输出。沙箱化可限制错误代码或不安全指令可能造成的损害，也有助于将不同用户的工作负载彼此隔离。
使用 OpenAI Agents API 的开发者可在三种大致的环境路径中选择：使用 OpenAI 托管沙箱、连接自有基础设施，或选择集成的沙箱提供商。在每一种路径中，OpenAI 仍负责运行智能体 harness。
OpenAI 托管环境提供了从配置到执行的最短路径。托管沙箱指南介绍了一个配备 Python、Node.js 和命令行工具的 Linux 工作区。应用可以提供文件、软件包、设置命令、环境变量、技能和插件。
开发者还可以控制出站网络访问。沙箱可以允许连接、阻止连接，或将连接限制在获批准的域名范围内。当智能体处理机密文件或能够安装外部软件包时，这一设置尤为重要。
托管路径减少了基础设施工作，但也将计算和执行置于 OpenAI 的托管环境中。一些组织会为低风险任务接受这种安排。另一些组织则需要私有网络、自定义镜像、专用硬件或对凭证更严格的控制。
针对这些场景，OpenAI 支持自托管沙箱。自托管环境指南称，该环境可以是笔记本电脑、容器或远程沙箱。环境中的 executor 接收 OpenAI 托管 harness 的请求并返回结果。
该连接为出站连接，因此可简化部署在企业网络控制之后的流程。OpenAI 指示开发者使用受限的 executor 密钥，并将权限更广的应用密钥保留在环境之外。不过，公司也警告称，共享同一环境的智能体可以访问共同的文件和凭证。
合作伙伴集成则处于两者之间。OpenAI 将 Blaxel、Cloudflare、Daytona、DigitalOcean、E2B、Modal、Oracle、Runloop 和 Vercel 列为生态系统提供商。这些合作伙伴可提供不同的计算配置、存储机制、部署模式和虚拟私有云选项。
这种分离是此次发布最重要的机制。OpenAI 希望开发者采用其编排层，而无需让每个工作负载都在 OpenAI 沙箱中运行。这使该 API 与拒绝完全托管执行模式的组织也具备相关性。
但这也带来了更复杂的信任边界。模型和 harness 经由 OpenAI 运行，而命令可能在其他地方执行。工具、密钥、文件、网络策略和审批系统可跨越多个提供商。每一道边界都会新增一个可能因配置错误或责任不清而产生问题的环节。
开发者必须确定每类故障由哪个组件负责。模型可能选择了不佳的操作。Harness 可能错误处理恢复流程。沙箱可能拒绝所需连接。外部工具可能返回损坏数据。应用可能批准不安全的操作。
在这种拆分式设计中，可观测性变得至关重要。团队需要能够还原：是哪条指令促成了某项决策、调用了哪个工具、工具返回了什么，以及环境中发生了哪些变化。当中间操作会影响生产系统时，仅有一份成功的最终答复并不足够。
这种架构也会影响可移植性。团队可以将执行环境从 OpenAI 托管的沙箱迁移到自己的基础设施中。若要将编排层迁离 Agents API，则需要投入更多工作，因为会话语义和事件处理属于 OpenAI 的托管服务。
这种权衡在云软件中并不罕见。托管服务通过引入特定提供商的行为来降低运维负担。实际要回答的问题是：节省下来的工程时间，是否超过未来替换这些行为的成本。
OpenAI Agents 如何跨越长会话工作
持久化会话与委派工作，是该 API 与普通工具调用最显著的区别。
长任务会带来一个基本的记忆问题。智能体会不断累积用户指令、工具定义、命令结果、文件变更以及中间结论。最终，这些历史信息会变得过大或过于嘈杂，无法被模型高效利用。
OpenAI Agents API 通过自动上下文压缩来应对这一问题。当会话接近其限制时，系统会压缩较早的上下文，同时保留继续执行所需的信息。因此，开发者无需自行构建压缩系统，也能创建跨越多个上下文窗口的工作流。
压缩很有用，但并非中立。任何摘要过程都需要决定保留什么、舍弃什么。某一步中看似不重要的细节，之后可能变得不可或缺。团队应测试压缩后的会话能否在真实工作负载中保留约束、证据与未解决的问题。
文档审查智能体说明了这种风险。它可能检查数百个文件，并在继续推进前汇总每一组内容。如果压缩遗漏了一份早期文档中隐藏的例外情况，最终报告即使看起来条理清晰，也可能错过最重要的发现。
开发者需要侧重于保留能力的评估，而不只是检验最终表达的流畅度。他们应测试智能体是否记得审批限制、来源约束、此前的失败以及用户修正。随着会话超出单个模型上下文，这些检查会变得更加重要。
第二项主要能力是多智能体委派。根据 OpenAI 的多智能体设计，主智能体可以将独立任务分配给子智能体。每个子智能体拥有自己的上下文，多个子智能体可以并行工作。
这种结构适合具有可分离工作流的调查任务。事件响应智能体可以委派部署分析、日志审查和依赖项检查。研究智能体可以将不同的来源集合分配给专门的智能体，再汇总它们的发现。
当任务确实相互独立时，并行执行可以缩短总耗时。它还能保护上下文质量，因为每个子智能体都专注于更狭窄的任务。主智能体接收到的是浓缩后的发现，而非每一项原始细节。
这种方法也有局限。相互依赖的步骤仍应按顺序进行。编辑同一批文件的智能体需要协调，重复的调查可能增加使用量却无法改善答案。糟糕的委派可能产生多份看似合理、却连基本事实都彼此矛盾的摘要。
OpenAI 为子智能体提供了并发设置，让开发者能够在一定程度上控制同时进行的工作数量。然而，仅有并发并不能解决规划问题。主智能体必须决定哪些任务值得委派、定义预期输出，并协调相互冲突的结果。
OpenAI 发布材料中的客户陈述提供了一些早期信号，但它们仍是由公司挑选的案例。Ciridae 表示，其评估得分从 0.71 提升至 0.85，子智能体支持将延迟降低了四倍。SafetyKit 表示，在迁移一项审查工作流后，每个案例的成本降低了 60%。
Hypha 表示，将 harness 与沙箱分离后，失败的智能体响应减少了 86%。Dwelly 描述了如何将突发性工作分配给数百个智能体。Nash 表示，它在涉及数亿次配送的物流业务中使用了数千个长时间运行的智能体。
这些数字很具体，但并非独立基准。OpenAI 尚未发布一项标准化比较，使买家能够在模型、工具和环境之间复现每项结果。每位客户此前使用的系统也构成了不同的基线。
更可信的结论应当更为有限。OpenAI 已找到使用该 API 处理真实多步骤工作负载的设计合作伙伴，其中一些合作伙伴报告了显著的运营收益。现在，公开测试版用户需要确定，这些收益能否迁移到较少经过精心筛选的环境中。
知识密集型智能体还将取决于团队如何组织源材料。一个可搜索的工程知识库可以减少智能体在分散文档中反复寻找决策所花费的时间。它不能替代编排，但可以改善提供给工具和会话的信息质量。
托管便利并不能消除智能体风险
公开测试版将基础设施工作转移给 OpenAI，但并未转移对智能体行为的责任。
能够运行代码和编辑文件的智能体，其失败面比仅返回文本的模型更大。它可能遵循检索内容中隐藏的恶意指令、通过工具泄露凭证、覆盖有价值的工作，或在恢复后重复执行外部操作。
沙箱能够限制一部分后果，但前提是开发者谨慎配置。具备广泛网络访问权限并存有敏感密钥的沙箱仍可能造成损害。多个工作负载共用的自托管环境，可能在会话之间暴露文件或凭证。
提示注入仍是核心问题。审查网页、工单、电子邮件或代码仓库的智能体，可能遇到旨在覆盖其真实指令的文本。工具访问会将这种操纵从内容问题转变为行动问题。
因此，权限设计必须从最小必要能力开始。研究智能体通常不需要部署凭证。文档审查者不应自动发送消息。事件调查者可以从只读访问开始，并在更改基础设施前请求批准。
网络控制同样值得重视。当智能体只需要本地文件时，开发者应限制其出站访问。若必须使用外部服务，允许列表可以降低暴露风险。在可复现性重要时，软件包和设置命令也应使用固定版本。
harness 与沙箱的拆分使安全审查更加复杂，因为责任横跨多个系统边界。OpenAI 管理编排，但开发者选择工具并决定这些工具能做什么。沙箱提供商管理计算资源，而客户提供文件、软件包和密钥。
恢复行为尤其需要仔细审查。持久化智能体应能在连接中断后继续运行，但围绕非幂等操作的重试可能存在危险。幂等操作即使重复执行，也会产生相同且安全的结果。发送付款或删除记录可能并不满足这一条件。
开发者必须设计能够暴露操作标识符、状态检查和确认步骤的工具。智能体应区分操作本身失败，与操作响应丢失之间的差异。否则，恢复过程可能重复执行已经成功的操作。
成本是另一个尚未解决的风险。该 API 没有单独的访问费用，但长会话可能会在较长时间内消耗模型、工具和计算资源。子智能体可能会放大这种使用量，因为多个上下文会同时推进。
快速得出结果并不一定意味着高效。团队需要设置每个会话的预算、委派限制，以及停止低价值调查的规则。他们还需要在智能体反复调用同一个工具或重新审视已完成工作时收到告警。
质量衡量仍然困难。编码任务可能拥有测试，而研究和运营分析通常不存在唯一正确答案。智能体可以顺利完成会话，却仍遗漏证据、误解政策，或提出不安全的建议。
OpenAI 的公开测试版标签在这里很重要。该公司表示，将根据开发者反馈迭代并迈向正式可用。在团队评估该服务期间，接口、能力、限制或运行行为都可能发生变化。
买家不应将一次测试版发布视为所有工作负载都已具备生产就绪性的证明。该 API 提供了 OpenAI 所称、受 Codex 经验塑造的基础设施，但每个应用仍需要自己的威胁模型和评估体系。
最强的早期部署很可能会对智能体施加约束。它们会使用范围狭窄的工具、明确的输出格式、隔离环境、可追溯证据，并对重大操作实行人工审批。它们会衡量故障恢复能力，而不只是测试理想化演示。
OpenAI 已降低开发者需要构建的基础设施工作量。但它并未消除为决定智能体被允许执行哪些操作所需的工程工作。
三个信号将决定公开测试版的走向
采用情况将更多取决于可靠性证据、企业控制能力和竞争对手的回应，而非吸引眼球的演示。
第一个信号是长会话中的可复现可靠性。OpenAI 所选客户的结果令人鼓舞，但市场需要更广泛的证据。开发者应关注持续工作负载下的评估得分、完成率、恢复行为和人工干预情况。
有意义的结果应当在相同模型、工具和数据条件下，将托管 harness 与团队现有的编排方案进行比较。这种比较可以将改进与模型质量、更好的提示词或无关的应用变更区分开来。
长会话的信息保留能力应获得独立评估。开发者需要知道压缩是否保留了政策、引用、失败的方法和用户修正。一个完成更多任务却遗忘关键约束的系统，会制造一种误导性的可靠性表象。
第二个信号是治理与可观测性的成熟度。企业将寻求清晰的追踪记录、权限边界、使用情况报告、保留控制和可预测的事件处理方式。它们还会测试自托管环境是否满足内部安全要求。
Agents API 已为会话、事件和环境提供了一套架构。公开测试版反馈将揭示，当出现问题时，这些抽象是否能提供足够细节。团队必须能够回答：智能体知道什么、做了什么，以及为什么这么做。
沙箱控制将与模型控制同等重要。组织将比较 OpenAI 托管环境的速度，与自身基础设施在策略灵活性上的优势。最终胜出的方案可能因工作负载而异，而非因公司而异。
第三个信号是竞争对手和独立框架如何回应。OpenAI 将模型提供商、智能体 harness 和可选计算资源整合为一项开发者服务。竞争平台可以通过更广泛的模型选择、更深入的云集成、更强的治理能力或更容易的可移植性来应对。
开源框架可能强调控制力和可检查性。云平台可能强调现有的身份、网络和数据服务。专业智能体供应商可能专注于行业工作流，在这些场景中，通用编排只是产品的一部分。
OpenAI 还表示，Agents API 以一个开源 Codex harness 为基础。这让开发者能够在一定程度上了解其协调逻辑。不过，能够查看底层代码，并不意味着这项托管服务就能与自行部署的方案完全互换。
其长期影响将取决于开发者是将该 API 视为可选的加速器，还是默认的智能体运行时。如果团队持续删去大量编排代码，OpenAI 的影响力将超越模型选择本身。若治理与可移植性方面的顾虑占据主导，这项服务可能仍只是众多运行时之一。
对开发者而言，合理的下一步是进行边界明确的评估。选择一项产出可衡量、故障情形贴近现实且权限有限的任务。分别通过现有工作流和 OpenAI Agents API 运行，然后比较完成质量、人工介入程度、延迟和总体使用量。
企业采购方还应加入安全与恢复测试：断开环境连接、返回格式错误的工具数据、注入恶意指令，并强制进行上下文压缩。可靠的智能体平台必须能在这些条件下处理问题，而不是掩盖失败。
知识工作者将间接受到这一变化的影响。产品如今可以在不自行构建每一个基础设施组件的情况下，加入运行时间更长的研究、审阅和基于文件的工作流。这可能加快新功能落地，但用户仍应了解数据在哪里运行，以及哪些操作需要审批。
OpenAI Agents API 的重要性在于，它将智能体工作周边的机制产品化。其公开测试版并未决定这些机制应由谁掌控。未来几个月将揭示：托管编排是否会成为默认选择，还是控制权仍将是更强的产品需求。
