OpenAI DevDay：计算机使用代理与新开发者栈的进展
OpenAI DevDay 的两条主线：Computer Use 与开发者 API
这期 DevDay 相关访谈聚焦两组 OpenAI 团队：一组负责 Computer Use Agent（计算机使用代理），另一组负责 API 平台。讨论内容主要围绕两个方向展开：
- 计算机使用能力为何在近期发生明显变化
- OpenAI 新一代开发者栈如何支持更快、更实时的 Agent 应用
受访者包括负责 OpenAI Computer Use 产品与工程的 Ari Weinstein，以及 OpenAI API 产品团队的 Nikunj Handa。
Computer Use：从“会点操作”到更能调试与恢复
访谈中，Ari Weinstein 表示，Computer Use 与数月前相比已经“180 度不同”。这里的核心变化不只是模型能看屏幕、点击按钮，而是代理在操作软件时具备了更强的上下文理解、调试能力和失败恢复能力。
讨论中提到，现代 Computer Use Agent 不再只依赖单一截图，而是会结合多种信号：
- 屏幕截图
- 无障碍信息树
- DOM
- Playwright
- 生成的 JavaScript 代码
这些信号共同帮助模型更准确地理解界面、定位元素、执行操作，并在失败后尝试修复路径。相比传统“看图点击”的方式，这种组合更接近一个带有浏览器自动化、程序化操作和视觉理解能力的混合系统。
每个 Agent 拥有自己的 Linux 电脑意味着什么
访谈还讨论了 Dots 以及“每个 Agent 拥有自己的 Linux computer”的概念。其意义在于，Agent 不只是调用 API 或执行孤立任务，而是拥有一个可持续工作的计算环境。
这可能让 Agent 更适合处理长流程任务，例如：
- 打开和操作网页应用
- 在多个工具间切换
- 执行软件测试
- 写代码后直接验证结果
- 在失败时重新尝试或调试
文中提到，Computer Use 在某些任务上已经可以比普通人更快完成。团队也将下一阶段目标描述为让代理在软件使用上达到“literally superhuman”的水平。不过，这仍是受访者对方向的描述，并不等同于所有任务都已达到超人水平。
Computer Use 对软件开发的影响
一个重要场景是软件开发闭环：Agent 不只写代码，还能打开软件、运行流程、观察结果并进行测试。
这意味着 Computer Use 可以连接两个过去常分离的环节：
- 编写软件
- 实际使用和测试软件
如果代理能够在真实界面中测试自己生成的功能，就可能提升编码代理在质量验证、回归测试和 QA 场景中的实用性。
信任、权限与安全问题
当 Agent 能够操作网站、提交表单，甚至进行支付时，权限和安全边界会变得非常关键。访谈中提到，Agents API 相关设计需要处理信任、授权和安全问题。
这类问题包括：
- 哪些操作需要用户确认
- Agent 能否访问敏感网页或本地信息
- 支付、提交、删除等高风险动作如何审批
- 长时间运行的代理线程如何被监控和中断
这部分没有给出完整解决方案，但明确被列为开发者栈设计中的重点议题。
新开发者栈：让 Agent 更实时、更低延迟
访谈后半部分由 Nikunj Handa 介绍 OpenAI API 平台的新能力，重点包括：
- 异步工具调用（async tool calling）
- Mid-turn steering
- WebSockets
- UltraFast inference
- Decisions API
- Prompt caching
- Cache pre-warming
- Context compaction
- Agents API
这些能力的共同目标，是让开发者构建更快、更实时、更稳定的 Agent 应用。
异步工具调用：模型不必等待工具完成
传统工具调用流程中，模型往往需要先停止生成，等待工具执行结果返回，再继续推理。异步工具调用的思路是让工具运行和模型推理更好地并行化。
这对 Agent 应用尤其重要，因为许多真实任务会调用多个慢工具，例如：
- 浏览器操作
- 数据库查询
- 文件处理
- 第三方 API
- 外部自动化流程
如果模型每次都必须停下来等待，整体响应会变慢。异步工具调用试图减少这种阻塞。
Mid-turn steering、WebSockets 与实时控制
访谈还提到 mid-turn steering 和 WebSockets。它们与实时交互、持续控制有关。
在更实时的 Agent 架构中，开发者可能希望在模型生成或执行过程中插入新的指令、调整方向，或者持续接收状态变化。WebSockets 则有助于建立更低延迟的双向通信。
这对实时计算机控制、语音交互、快速工具调用等场景都有意义。
UltraFast inference：降低前沿模型延迟
OpenAI 还讨论了 UltraFast inference，即推动前沿模型向更低延迟方向发展。低延迟对 Agent 体验很关键，因为 Agent 往往不是一次性回答问题，而是持续观察、决策、调用工具、等待反馈、再决策。
如果每一步都延迟较高，完整任务体验会明显变差。因此，更快推理、缓存、预热和更高效的上下文管理会成为 Agent 基础设施的重要组成部分。
Decisions API：面向实时决策的接口
访谈特别讨论了 Decisions API。根据介绍，它用于让应用进行实时决策，例如：
- 内容分类
- 请求路由
- 选择下一个 Agent 动作
- 支持工单分类
- 内部工作流判断
文中提到，当前 Decisions API 暂时是基于 GPT-6 Luna 的封装，但团队认为复制优秀模式并快速产品化是有价值的。
受访者还强调，Decisions API 不只是“低延迟结构化输出”。它更像是面向开发者的高层决策原语，让应用能以更简单方式把模型判断嵌入实时系统。
Prompt caching、预热与长线程压缩
开发者栈中还包括与性能和成本相关的能力：
- 更长的 prompt caching
- cache pre-warming
- cache-aware applications
- server-side compaction
- manual compaction
对于长时间运行的 Agent 来说，上下文会不断增长。如果所有历史都原样保留，成本和延迟都会上升。上下文压缩可以帮助系统保留关键状态，同时降低后续调用负担。
访谈区分了服务端压缩与开发者手动压缩：前者由平台自动处理，后者则让开发者根据业务需求自行控制摘要和记忆结构。
Agents API 与“AI Cloud”方向
最后，讨论延伸到 Agents API 与 OpenAI 作为“AI cloud”的定位。核心问题是：哪些能力应该由 OpenAI 的高层 API 提供，哪些应该留给开发者自己的 harness？
可以放入平台层的能力包括：
- 工具调用管理
- 长线程状态
- 权限与安全控制
- 上下文压缩
- 缓存与预热
- 多步骤 Agent 执行
而开发者可能仍希望保留对业务逻辑、工具编排、状态管理和用户体验的控制。
这反映出 OpenAI 正在从“模型 API”向更高层的 Agent 基础设施演进：不只是提供模型调用，而是提供构建智能应用所需的执行、决策、记忆和实时交互组件。
主要讨论点概览
- Computer Use 在近期被认为出现显著进展
- Agent 可以结合截图、无障碍树、DOM、Playwright 和生成代码操作软件
- 代理正在增强调试和失败恢复能力
- Dots 与个人云电脑让 Agent 拥有持续运行环境
- Computer Use 可用于编码、测试与 QA 闭环
- Agents API 需要处理信任、权限与安全问题
- 异步工具调用减少模型等待工具的阻塞
- Mid-turn steering 与 WebSockets 支持更实时的 Agent
- UltraFast inference 面向更低延迟的前沿模型体验
- Decisions API 用于分类、路由和实时决策
- Prompt caching、预热和上下文压缩改善性能与成本
- OpenAI 正在探索模型 API 之上的更高层 AI 云原语