9月10日，OpenAI将支撑Codex的执行框架以Agents API公开测试版开放。开发团队可以向托管会话提交长任务，由OpenAI处理上下文压缩、状态恢复和子Agent编排，同时选择代码和文件运行的沙箱。一次任务跨小时进行时，团队因此可以少建一套维持执行循环的服务，仍要负责工具权限与结果验证。
这次变化的关键是运维责任。应用定义任务、模型、工具和权限；OpenAI让Agent在同一会话中跨轮工作，管理上下文、工具调用和子Agent协作。谁维护执行框架，与谁提供算力和文件环境，成为两个可以分开选择的问题。
四月已有沙箱和恢复能力，九月交付托管会话
OpenAI在4月15日升级Agents SDK时，已经提供能读取文件、运行命令的执行框架、原生沙箱，以及快照和恢复机制。因此，持久运行或沙箱本身并非9月首次出现。
9月的Agents API公告把Codex框架放到OpenAI运营的服务里。开发者创建会话，提交输入，通过事件流查看进度，并在同一会话继续发任务；服务保存状态，在上下文接近上限时自动压缩，并可协调子Agent。应用不用自己部署和升级这套执行框架。底层Codex框架的核心代码可公开查看，托管服务的运维和控制面仍由OpenAI提供。OpenAI还称会随模型发布提供版本化的框架能力，这能减少应用逐次适配框架的工作，也使运行行为更依赖其服务版本。
官方演示的创建请求同时指定agent、environment和input：前者配置模型与工具，中间一项选择执行环境，最后一项交代任务。这三个字段对应三方分工：应用定义工作，托管框架推进会话，沙箱承接命令与文件操作。若任务只需远程MCP或应用提供的函数工具，文档也允许environment.type设为none，此时没有内置Shell和工作区文件。
沙箱可放在自己一侧，执行权限也留在自己一侧
需要运行代码时，团队可选OpenAI托管沙箱、自有环境或合作方服务。选择自托管时，OpenAI运行模型与工具循环，开发者在自己的容器或机器上运行codex exec-server；执行器向服务建立出站连接，接收命令并返回结果。应用还要启动计算资源、准备文件和依赖，并管理环境生命周期。官方架构文档明确区分了托管框架、执行环境和应用服务器。
这种分离让企业能决定文件、算力和部分凭据所在的位置，却不会自动解决数据和操作边界。Agent生成的代码能够接触沙箱里可见的文件、网络和凭据；OpenAI的安全文档要求按用户或工作负载隔离环境、限制出站网络，并把应用API密钥留在沙箱之外。能否接入生产系统，仍取决于开发者配置的工具权限、审批和验证流程。
不收框架附加费，任务总成本仍要按用量算
OpenAI称公测面向所有开发者，Agents API没有单独的接口附加费；模型token、OpenAI工具和托管容器按相应价格计费，自有或合作方算力也有各自成本。一个多轮任务的预算应把主Agent与子Agent的输入、输出token相加，再计入搜索等工具调用、沙箱运行时间和外部服务费用。“托管”减少的是框架运维工作，不保证单次任务更便宜。
发布稿列出客户自报的延迟下降、失败响应减少和单案成本下降，涉及不同公司、旧系统与工作流，不能合并成Agents API的统一性能指标。8月TechCrunch对OpenAI团队的采访也提供了一个校正视角：工程师认为模型能力与给模型的工具、上下文同样影响Agent表现。要判断托管框架是否值得迁入，开发团队需要用自己的任务集比较完成率、恢复后的结果、人工介入次数和总成本。
Agents API把“谁维护长任务执行循环”变成了一项服务选择。它让应用把精力转向业务工具与结果验证，同时保留沙箱位置的选择。公测阶段最该检验的，是一次跨小时任务失败或中断后，状态能否按预期恢复、操作记录能否解释结果，以及在所选环境下账单是否合算。
