OpenAI智能体新栈：计算机操作、决策API与超速工作流

OpenAI在最近的Dev Day上发布了一系列围绕智能体（Agent）的重磅更新，从能直接操作电脑的Computer Use，到主打低延迟的Decisions API，再到全新的Agents API和GPT-6.1 Sol模型。这不仅仅是几个新功能的堆叠，而是一套让AI真正“动手干活”的完整技术栈。本文基于公开的播客访谈内容，梳理这套新栈的核心逻辑、实测表现与开发者落地要点。

从“能开始”到“能搞定”：Computer Use的质变

Computer Use并非新概念，但过去很长一段时间里，智能体虽然能启动任务，却常常在遇到弹窗、加载延迟或页面结构变化时卡住。OpenAI计算机操作智能体产品与工程负责人Ari在访谈中坦言，早期模型“能可靠地开始任务，但随后就会遇到问题”。如今最大的变化在于调试能力：模型学会了重试、自查，并判断“哪里不对”。

技术层面，Computer Use不再只依赖单一动作循环。它会直接编写JavaScript代码，在浏览器环境中批量执行多步操作；同时融合截图、无障碍树（accessibility tree）和Playwright等多种模态信息。在Codex中展开工具调用可以看到，模型往往一次生成并执行一段脚本，而非机械地“点一下、截个图、再点一下”。这种“写代码来操作电脑”的方式，大幅压缩了往返延迟。

另一个容易被忽视的更新是App Shots。用户双击Command键，看似只是截了张图，实际上拉取的是整个应用的元数据、可点击元素和完整文本表示。Ari强调，截图里链接的跳转地址、日历中被截断的事件标题，这些信息在App Shot中都是完整的。对语言模型而言，这相当于从“看图片”升级为“读结构”， token效率也经过专门优化。

无障碍树（Accessibility Tree） 是操作系统或浏览器为辅助技术（如屏幕阅读器）构建的界面语义结构，它将页面上的按钮、输入框、链接等元素以层级化的节点形式暴露出来，并附带角色、名称、状态等属性。与像素截图相比，无障碍树直接提供“这个元素是什么、能不能点、当前是否可用”的结构化信息。对智能体而言，读取无障碍树比解析图像更省 token、更少歧义，尤其在元素被遮挡或动态加载时仍能稳定定位。不过无障碍树并非万能：部分自定义控件、Canvas 渲染内容或跨 iframe 场景可能信息缺失，因此实践中常与截图、DOM 查询等手段互补使用。

Decisions API：不是新模型，而是被压榨到极致的Luna

Decisions API是本次发布中最具话题性的产品之一。它主打极低延迟的分类与决策推理，被外界视为对Jeff等新兴推理服务的回应。但OpenAI API产品负责人Nikunj澄清了一个关键事实：Decisions API并未训练新模型，而是基于现有Luna权重，通过结构化输出、并行推理和推理栈优化，把首token延迟（TTFD）压到极限。

“我们基本上是零样本地在Luna上做这件事，先推出去，再看反馈迭代。”Nikunj表示。这意味着开发者可以以接近Luna的价格，获得针对分类任务深度优化的端点。它支持视觉输入，能并行处理多个问题，适合客服工单分类、实时路由、低延迟评测等场景。不过，它不具备长程推理能力，复杂任务仍需交给Astra或GPT-6.1 Sol。

有意思的是，OpenAI内部从Jeff的发布中获得了明显启发。Nikunj形容团队“被nerd sniped了”，基础设施和推理团队的工程师在一周内搭出原型，随后开始对延迟进行爬坡优化。这种黑客文化驱动的快速跟进，也解释了为何Decisions API能在如此短的时间内面世。

首 token 延迟（TTFT/TTFD） 指从请求发出到收到模型第一个输出 token 的时间，是衡量交互式 AI 响应速度的核心指标之一。对于分类、路由、实时决策等任务，用户或下游系统往往只需一个简短结果，此时首 token 延迟几乎决定了整体体验，而非总生成时长。压低这一指标通常依赖多条路径：减少输入预处理开销、复用 KV 缓存、并行执行候选推理、优化调度与批处理策略，以及采用更小的模型权重。Decisions API 宣称的“把延迟压到极限”，本质上是在这些工程环节上做系统性取舍，而非依赖模型能力本身的跃升。

GPT-6.1 Sol：为计算机操作而生的性价比模型

GPT-6.1 Sol被定位为“特别适合计算机操作”的模型。官方在主题演讲中给出的数据是：其成本约为Astra的五分之一，而在计算机操作场景下，成本仅为Astra的七分之一。这一成本优势来自推理效率的持续优化，而非单纯的模型缩水。

Ari分享了一个具体的效率对比：在订阅定制餐食服务的任务中，人工操作需要两小时，而Computer Use在GPT-6.1 Sol上15分钟完成，速度约为人工的八倍。这类“高重复、高定制、低API化”的任务，正是Computer Use最能发挥价值的地带。

模型加速与工具链改进是并行的。OpenAI内部用多种测试框架和配置来度量计算机操作能力，包括带安全约束的生产级配置。尽管度量方式复杂，但结论一致：提升既来自模型本身，也来自harness（执行框架）的优化。

Agents API：把同一套Computer Use开放给开发者

对于开发者而言，Agents API中内置Computer Use可能是最具实际意义的更新。过去，构建一个可靠的计算机操作智能体需要自研harness、处理截图解析、重试逻辑和安全边界，门槛极高。现在，开发者可以直接调用与Codex、ChatGPT同源的Computer Use实现。

Ari给出了一个务实的理由：OpenAI的模型就是在这个harness上训练的，使用官方实现可能在速度、成本和准确率上都有优势。当然，如果开发者有特殊需求，自建harness仍然可行，但需要承担相应的工程复杂度。

在安全层面，Ari建议开发者遵循几个原则：只授予任务必需的网站和应用访问权限；在执行支付等关键操作前请求用户确认；通过可靠性设计逐步建立用户信任。他用自己“让智能体配置DNS、支付账单”的体验来说明，信任是随着产品成熟度逐步累积的。

Harness（执行框架） 指包裹在模型外围、负责驱动智能体完成任务的工程层：它决定如何组织提示词、如何调用工具、如何解析截图或结构化输出、失败时如何重试、何时终止以及如何施加安全约束。同一个模型在不同 harness 下表现可能差异显著，因为工具调用的节奏、上下文管理和错误恢复策略都会影响最终成功率。OpenAI 强调其模型正是在自家 harness 上训练和评测的，这意味着官方实现与模型行为分布高度匹配；开发者自建 harness 虽然灵活，但需要自行复现这些隐性约定，并承担相应的调试与可靠性成本。

开发者工作流正在被改写

Computer Use对开发流程的影响可能比想象中更直接。Ari最喜欢的用例之一是让智能体测试自己刚写完的软件。传统流程中，Codex生成代码后，开发者要手动充当QA；现在，智能体可以自己构建、自己测试，把可运行的产物交给人类。这补全了软件开发生命周期的最后一环。

另一位受访者、同时也是内容创作者的Chase则提到，YouTube等平台大量功能不开放API，Computer Use成为自动化社区帖子、A/B测试等操作的现实方案。他还会让智能体在等待客服回复时调用子智能体去研究替代方案，形成一种“人类设定策略、智能体并行执行”的混合工作流。

API侧的基础设施也在同步进化。Nikunj介绍了GPT-6带来的异步工具调用、回合中转向（mid-turn steering）以及基于WebSocket的双向通信。异步工具调用允许模型在工具执行期间继续推理，不必阻塞等待；回合中转向则让开发者可以在模型思考过程中注入新指令。这些能力与UltraFast推理模式结合，为实时性要求高的智能体应用提供了底层支撑。

缓存、压缩与性能：平台层的隐形战场

对于构建长期运行的个人智能体， Responses API的性能优化同样关键。Nikunj透露团队正在重写Responses API以降低首token延迟，并在缓存上加大投入：目前提供30分钟内的缓存命中保证，针对部分用户已推出12小时缓存窗口的预览。此外，pre-warming功能允许开发者提前写入缓存，为后续请求准备好上下文。

上下文压缩方面，OpenAI提供服务器端自动压缩和手动/compact两种方式。Codex的harness中还实验了基于文件的压缩系统。对于需要长时间维持会话状态的智能体产品，这些机制直接影响成本和响应速度。

上下文压缩（Context Compression） 解决的是长会话中 token 预算有限与信息量持续增长之间的矛盾。常见做法包括：对历史对话做摘要、丢弃低价值轮次、将结构化状态外置到文件或数据库，以及在服务端自动触发压缩。压缩策略直接影响智能体的“记忆”质量——压得太狠会丢失关键约束，压得太松则成本和延迟上升。文章提到的服务器端自动压缩、手动 /compact 以及基于文件的压缩实验，代表了从全自动到半可控的几种路线，开发者需根据任务对历史依赖的程度选择合适粒度。

写在最后：智能体的“超人类操作”还有多远

Ari在访谈中给出了一个清晰的判断：Computer Use目前在大多数任务上已经比普通人更快，下一个前沿是超越专家级电脑用户的操作速度。当智能体操作软件的速度达到或超过熟练人类时，实时性产品将迎来新的可能性，人们也会逐渐把更多手动操作默认交给智能体。

瓶颈依然存在：模型能力、推理速度、harness设计、界面表示、甚至目标网站本身的加载时间。DoorDash页面加载快慢这样的外部因素，都会成为端到端延迟的一部分。但方向已经明确——让智能体像人一样使用所有为人类设计的软件，同时比人更快、更稳、更可委托。对开发者来说，现在正是用Agents API和Decisions API动手构建的时候。