OpenAI DevDay 2026 开发者回顾：有哪些变化

OpenAI DevDay 2026 并不只是一场模型发布会。在 9 月 29 日发布的回顾文章中，OpenAI 把一款更便宜的主力模型、托管式智能体运行时、云端编码环境，以及一款常驻型消费级智能体放在了同一条产品线上。对开发者来说，真正重要的变化在架构层：围绕模型运行的更多环节——包括会话、工具、执行环境和后台任务——正在转移到由 OpenAI 托管的产品中。

开发者该如何判断

GPT-6.1 Sol 是近期最清晰的 API 方向。OpenAI 将其列为 gpt-6.1-sol，支持 Responses API、工具调用、计算机使用和 MCP。Agents API 则是一个公开测试版，用于构建托管式 Codex 风格智能体。Codex Cloud 把异步编码变成了云端工作流。Dots 面向消费者，展示的也是同一趋势，但它并不能替代开发者 API。

实际采用时，建议先测试 Sol 和 Agents API；对于远程执行能够减少协作成本的场景，再使用 Codex Cloud；至于 Dots，更适合被视为产品方向信号，而不是稳定的集成接口。

哪些已经发布，哪些仍在逐步开放

OpenAI 的官方 DevDay 回顾介绍了 20 多项发布内容，但其中与开发者最相关的四项，当前状态并不相同。

API 访问情况应以 OpenAI 的模型文档为准；Agents API 的测试版状态则由官方公告明确说明。不要把这些页面解读为所有账户都能获得相同配额或区域可用性的承诺。

GPT-6.1 Sol 正在改变智能体循环的成本结构

OpenAI 在GPT-6.1 Sol 公告中称，Sol 是 GPT-6 Sol 的升级版，在编程和计算机使用方面接近 Astra 的表现，同时运行成本更低。RuntimeWire 报道称，OpenAI 在 DevDay 公布的价格为：每百万输入 token 2 美元、每百万缓存输入 token 0.10 美元、每百万输出 token 10 美元。也就是说，如果应用可以复用缓存输入，而不是反复发送全新的上下文，重复上下文的成本会低很多。

这样的定价更适合包含长指令、工具调用轨迹或重复项目上下文的智能体工作流。但这并不意味着所有任务都会变得便宜：输出量大的循环、重试、浏览器操作以及外部工具费用，都可能成为主要成本。OpenAI 所说的“接近 Astra”属于定性描述，不能代替你在自己的代码仓库、工具 schema 和故障预算上进行实测。

一个实用的起点，是把 20–50 个有代表性的任务分别交给 Sol 和当前生产模型，然后记录成功完成率、工具调用修复率、延迟和总 token 数。这样才能看出，在真实编排开销下，较低的 token 价格是否仍然成立。

Agents API：从调用模型走向托管执行

Agents API 是这次最重要的开发者发布，因为它关注的不再只是模型选择。OpenAI 将其描述为一个托管式 Codex 运行框架，负责会话、编排、上下文压缩和故障恢复；开发者则提供工具和执行环境。

公开测试版公告及相关发布报道提到，该 API 支持代码执行、文件编辑、MCP 连接、委派给其他智能体，以及通过 OpenAI 托管浏览器实现计算机使用。它解决的是智能体周边的运行时问题，而不只是调用一次 responses.create，再塞进更长的系统提示词。

身份认证、业务权限、工具设计、审批策略、可观测性、域名白名单、敏感操作确认、审计日志，以及可重放的失败案例，仍然由你的应用负责。托管式计算机使用可以减少浏览器基础设施，但不会替你解决这些控制问题。

“关于 Sol 6.1 和 Opus 5.5 的性能，有新消息吗？”——u/Ashamed-Subject-8573，发表于 r/codex 讨论

这个问题正好体现了主题演讲与生产落地之间的差距。开发者真正需要关注的是模型在自己工作负载下的实际表现、工具可靠性和成本，而不只是发布会上的横向比较。应把 Agents API 当作一个需要评估的测试版运行时，而不是把它当成所有智能体工作负载都必须迁移到 OpenAI 托管栈的理由。

Codex Cloud 把运行时变成产品的一部分

Codex Cloud 让编码智能体不再局限于开发者当前打开的终端。发布报道称，它提供可复用的环境，里面包含项目仓库、依赖、工具和访问设置。任务可以从桌面端、网页端或移动端远程运行，开发者即使合上笔记本，也能之后回来继续处理。

它带来的影响主要体现在运行和协作层面：

1. 长任务可以异步执行。代码审查、测试修复或迁移任务可以在本地会话关闭后继续运行。
2. 环境配置可以共享。团队可以定义经过批准的工作区，不必为每个任务重新安装依赖。
3. 人与智能体之间的交接更顺畅。开发者可以检查 diff、恢复会话，并决定哪些改动最终合并。
4. 安全问题会变成部署问题。仓库访问、密钥、网络出口和云端身份都需要明确的策略。

OpenAI 的DevDay 回顾以及同一份产品盘点还提到 Codex CLI 智能体视图、语音控制、桌面端代码审查，以及面向已连接 GitHub 仓库的 Codex Security Cloud。这些功能让 Codex 不再只是代码补全工具，而更像是一层远程工程运营系统。

Codex Cloud 并不会自动取代本地开发环境。团队仍需验证仓库支持情况、依赖安装、网络访问、密钥处理、会话时长，以及失败任务是否会留下可复现的工作区。在把生产迁移或发布关键改动交给它之前，建议先从低风险维护任务开始。

Dots 是面向消费者的示范，不是开发者 API

Dots 展示了 OpenAI 希望智能体产品走向何方：一个常驻运行、拥有自己的云端计算机、能够连接应用、保留持久上下文并在后台工作的助手。OpenAI 的Dots 公告和工作区文档介绍了连接服务及访问控制；发布报道则称，符合条件的计划和市场可以通过 ChatGPT、Slack 和 Microsoft Teams 使用相关入口。

对开发者来说，Dots 代表着从逐轮提示转向任务委派，但同时也带来了尚未解决的自主性和隐私问题。OpenAI 的工作区文档确认，访问权限由工作区和计划设置控制；发布报道则称，符合条件的市场提供 ChatGPT、Slack 和 Microsoft Teams 入口。Dots 并不是面向开发者的契约：在选择托管式智能体之前，应将它与 Agents API 在控制能力、数据位置、工具权限、可审计性和退出成本方面进行比较。

工程团队的实际采用顺序

这四项发布可以按照一个相对合理的顺序进行评估：

1. 用真实工作负载测试 GPT-6.1 Sol。选择代码仓库任务、结构化工具调用和有代表性的上下文，并把缓存输入假设纳入成本模型。
2. 构建一个范围明确的 Agents API 工作流。可以从问题分流、测试诊断或文档更新等可回滚任务开始。在扩大权限之前，先加入审批关卡。
3. 有选择地把异步编码迁移到 Codex Cloud。先用非敏感仓库测试可复用环境，再明确密钥和网络控制措施。
4. 把 Dots 当作产品研究信号。关注它的权限、集成能力和可用性，但不要让它成为应用架构的依赖。
5. 保留可移植层。将工具定义、提示词、评测用例和审批逻辑保存在自己的代码仓库中，这样当预览版 API 的限制或行为发生变化时，可以替换它。

Sol 已经有 API 模型条目和公开价格；Agents API 明确处于公开测试阶段；Codex Cloud 是一个仍有不少运行细节待确认的托管式工作流；Dots 则是最不适合作为开发者契约基础的产品。

常见问题

GPT-6.1 Sol 可以通过 API 使用吗？

可以。OpenAI 的开发者模型页面列出了可用于 API 的 gpt-6.1-sol，包括 Responses API 和面向工具的能力。具体访问权限和限制可能因账户及发布进度而异。

Agents API 已经正式发布了吗？

没有。OpenAI 宣布 Agents API 为公开测试版。如果要将它用于不可逆的生产操作，应先建立评测、日志记录和备用路径。

Dots 是开发者可以调用的 API 吗？

不是。Dots 是 OpenAI 的智能体产品，有自己的发布进度和计划规则。对于构建托管式智能体，Agents API 才是相关的开发者接口。

Codex Cloud 会取代本地开发环境吗？

默认不会。它增加了远程执行和可复用环境，但团队仍需验证仓库访问、依赖、密钥、网络策略、持久化能力和审查流程。

把生产工作迁移过去之前，团队应该确认什么？

应确认实际提供服务的模型、考虑重试和工具调用后的真实价格、数据处理方式、权限边界、故障恢复、可观测性、区域可用性，以及当测试版功能发生变化时的退出路径。

开发者不能跳过的取舍

取舍其实很明确：托管式会话和浏览器可以减少基础设施工作，但自建运行时能让你更好地控制数据、凭证、调试过程和模型变更。建议先从 Sol 和 Agents API 开始，只有在 Codex Cloud 的运维收益足够明确时，再把它用于实际工作。