Agents API 支持 computer use 了：让 AI 点界面之前，这笔账得先算清楚

本文是「Agent 工程实战」系列的第 11 篇，属于界面线。
系列索引（21 篇阅读路线）：Agent 放权前，先补权限、出站、发现这三道口子

摘要：09.29 DevDay 上，OpenAI 把 computer use 正式做进了 Agents API——之前还是"模型能操作界面"的能力演示，现在变成开发者可以调用的 API 能力。但这背后有一笔账：Agent 走"截图→坐标→点击"循环，每一步都在烧 token，成本可能比让 AI 直接调接口高一个量级。本文从官方定价出发，把"AI 点界面"和"AI 调接口"的成本结构拆开算了一遍，给出一张成本对照表和一套决策框架，文末附可直接勾选的检查清单。

先说这次的变化

9 月 29 号 OpenAI 开完 DevDay，发的东西很多。我最关心的是这一条：

The Agents API now supports computer use so developers can build agents that interact with software to complete tasks. It also brings Codex’s multi-agent capabilities, tool search, tool calling, and context compaction into your application. OpenAI runs the underlying infrastructure so your team can focus on building the application.
（来源：DevDay 2026 Recap）

Agents API 支持 computer use 了，开发者可以构建能操作软件的 agent；Codex 的多 agent、tool search、tool calling、context compaction 这些能力一并带进来；底层基础设施由 OpenAI 托管。

这条消息放在九月初还不敢想。九月初我写"AI 都要自己点界面了"的时候，computer use 还是模型能力层面的演示；9 月 10 号 Agents API 上线，官方示例里全是 MCP 和工具调用；现在官方把 computer use 作为托管的 API 能力交到开发者手里——"让 AI 操作界面"从演示变成了开发者接口。

computer use 到底怎么干活

要把账算明白，先得知道 computer use 是怎么干活的。主流的 computer use 走的是"观察-行动循环"：

┌─────────┐ 截图 ┌──────────────┐ 预测坐标 ┌─────────┐ │ 目标界面 │ ───────→ │ 模型(看屏幕) │ ────────→ │ 执行点击 │ │(桌面/页面)│ ←─────── │ │ ←──────── │ 滚动/输入 │ └─────────┘ 状态变化 └──────────────┘ 动作结果 └─────────┘ 每一轮循环：截图 → 判断 → 动作 → 再看

模型拿一张屏幕截图，判断"这里有个按钮"，输出一个坐标，系统去点击；点完再看一眼新截图，决定下一步。整个任务就是无数个这样的循环叠出来的。Codex、OpenAI 的 CUA（Computer-Using Agent）、Anthropic 的同名方案，基本都是这套思路——各家在"感知"上的具体实现有差异，有的纯截图，有的结合可访问性树拿语义，但"看→判断→操作→再看"这个循环和它的成本结构是共同的，差别只在单轮烧多少 token。

这套机制的好处是通用：不挑系统、不挑页面，有屏幕就能操作。代价也在这里——每一步都要把"看屏幕"这件事变成 token 花出去。

这笔账怎么算

官方定价先摆出来

GPT-6.1 Sol 是 09.29 和 DevDay 一起发的，官方说它在编码、computer use、专业文档处理这些方向上接近 Astra，价格是 Astra 的五分之一，适合日常 agent 任务。官方 API 标准价（来源：Introducing GPT-6.1 Sol）：

"五分之一的价格"在表里看得很清楚：输入输出都是五分之一，缓存输入干脆差了一个量级。

注意缓存输入那个价格，它只对"重复喂同一段上下文"有效，不是所有输入都能按这个算。我刚看到这个数字的时候差点误会，以为整篇对话都能按缓存价走——实际缓存价只是标准输入的 5%，省是真省，但不是全部对话都适用。

一轮"截图→判断→点击"烧什么

• 截图本身：作为图像输入喂给模型，按图像 token 计费。一张高清量级的截图，按各家的估算口径大概折合一两千 token，具体跟分辨率、跟模型都有关系（也有实现走可访问性树拿文本，单轮更省——那种就把脚本里的图像 token 参数调小就行，成本结构不变）
• 模型判断：看屏幕、想"该点什么"，这部分走输出 token
• 动作执行：输出一个坐标、一次点击指令，token 很少但架不住次数多

所以单轮循环的大头在"看图"和"思考"。一个任务几十轮循环下来，token 就滚起来了。

社区里有人测过的对比

之前社区有人做过一次公开对比实验：同一个内部工具任务，让"视觉派 agent"（截图+坐标那套）和"结构化接口"（直接调 API）各走一遍——视觉派跑了四五十步、烧掉接近五十万 token，结构化接口七八次调用、一万多 token，光 token 量就差了几十倍。数据来自社区公开实验，不是官方基准，你换任务换模型数字会变，但量级关系基本是这个意思。

我的经验也是这个方向。第二弹那篇写过，我们后台给老系统补了个只读导出接口之后，Agent 从"十几步界面点选"变成"一次接口调用"，回放里点偏造成的错文件再没出现过——不是界面操作不可用，是每一步都在付账。

用官方定价把两边算出来

光说"贵一个量级"不够，我用官方价格自己写了个小脚本，把两边的成本结构按同一口径算出来。为啥要看这段：同样的计费规则下，"点界面"和"调接口"的成本差距到底是多少，不能拍脑袋，得算。

// 成本估算：GPT-6.1 Sol 官方价，$/百万tokenconstPRICES={input:2,// 标准输入output:10,// 输出};// computer use：每轮循环 = 1张截图(图像token) + 判断输出 + 动作输出functioncomputerUseCost(steps,imgTokensPerShot,thinkTokensPerStep){constinputTokens=steps*imgTokensPerShot;// 截图累积constoutputTokens=steps*thinkTokensPerStep;// 思考+动作累积return{steps,inputTokens,outputTokens,totalUsd:(inputTokens/1e6)*PRICES.input+(outputTokens/1e6)*PRICES.output,};}// 结构化通道：几次调用，文本输入为主functionapiCost(calls,inputTokensPerCall,outputTokensPerCall){constinputTokens=calls*inputTokensPerCall;constoutputTokens=calls*outputTokensPerCall;return{calls,inputTokens,outputTokens,totalUsd:(inputTokens/1e6)*PRICES.input+(outputTokens/1e6)*PRICES.output,};}// 演示参数：点界面45轮(截图1800tok/张+思考600tok/轮)；调接口8次(输入800+输出400)constcu=computerUseCost(45,1800,600);constapi=apiCost(8,800,400);console.log("computer use(点界面) 成本明细:");console.log(JSON.stringify(cu,null,2));console.log("structured API(调接口) 成本明细:");console.log(JSON.stringify(api,null,2));console.log("倍率: "+(cu.totalUsd/api.totalUsd).toFixed(1)+"x");

运行结果（Node 25.8.2 实测，参数只是演示口径，你按自己场景改）：

computer use(点界面) 成本明细: { "steps": 45, "inputTokens": 81000, "outputTokens": 27000, "totalUsd": 0.432 } structured API(调接口) 成本明细: { "calls": 8, "inputTokens": 6400, "outputTokens": 3200, "totalUsd": 0.0448 } 倍率: 9.6x

同样一个任务，按同一条计费口径算，点界面比调接口贵了将近十倍。这四毛多花在哪？拆开看，computer use 版的成本是两块："看图"的截图输入占四成左右，"思考"的输出占六成——输出单价贵 5 倍，所以单笔大头其实在思考那半边。两块都要算，但截图这块最容易被漏掉：读一个数据也要先"看"一眼，很多人算账时根本没把它当成本。

这个"忽略"不是说着玩的。我自己给预算的时候也犯过同样的错：只盯着模型的输出 token，觉得"每一步就点一下，能有多少"，截图作为图像输入那部分完全没算进去。同样是 45 轮循环，两种算法的结果差多少？看这段（独立可跑）：

// 反例：错误算法 vs 完整算法，同一任务同一口径constPRICES={input:2,output:10};// GPT-6.1 Sol// 完整算法：输出 token + 截图(图像输入) token 一起算functionfullCost(steps,imgTokensPerShot,thinkTokensPerStep){constinputTokens=steps*imgTokensPerShot;constoutputTokens=steps*thinkTokensPerStep;return{totalUsd:(inputTokens/1e6)*PRICES.input+(outputTokens/1e6)*PRICES.output,};}// 错误算法：只算输出 token，漏掉图像输入这块functionwrongCost(steps,thinkTokensPerStep){constoutputTokens=steps*thinkTokensPerStep;return{totalUsd:(outputTokens/1e6)*PRICES.output};}constright=fullCost(45,1800,600);constwrong=wrongCost(45,600);console.log("错误估法(只看输出): "+wrong.totalUsd.toFixed(3)+" USD");console.log("完整估法(含截图输入): "+right.totalUsd.toFixed(3)+" USD");console.log("低估比例: "+(right.totalUsd/wrong.totalUsd).toFixed(1)+"x");

运行结果（Node 25.8.2 实测）：

错误估法(只看输出): 0.270 USD 完整估法(含截图输入): 0.432 USD 低估比例: 1.6x

漏掉图像输入，预算少算四成左右——错误算法估出来 0.27，真实要 0.43。算 computer use 的账，图像 token 那项不能省。前面两个脚本你拿回去就能用：把 PRICES 换成你用的模型价格，把步数和每轮 token 换成你任务的实际值，跑一遍就是你的账单；图像 token 的估算口径也写在脚本里，你可以在自己模型上实测后替换。

核心结论：差在哪

把两件事的成本结构摆一起看，核心差距在"读数据的方式"——接口一次查询就拿到，截图派得先"看"一眼：

画成条形图更直观（数据来自上面脚本的真实输出）：

同一任务成本对比（GPT-6.1 Sol，Node 25.8.2 实测） 结构化接口 ▏ 0.045 $ computer use █████████ 0.432 $ ← 约 9.6 倍

注意，这个对比的前提是同一个任务、两条路都走得通。这个前提很重要，后面讲决策的时候会回到这里。

那到底什么时候该用 computer use

不是所有任务都适合走结构化通道，也不是所有任务都该让 AI 点界面。我按"有没有接口"把场景分成三类：

判断可以套三句话：这个任务 Agent 会不会反复跑？这个数据能不能只读拿到？这个界面值不值得为它开接口？三句话都是"否"，computer use 就是正解；有任何一句"是"，先往结构化通道上靠。

computer use 的边界

把话再说回来，computer use 有几个现实约束得认清：

• token 消耗是硬成本：截图派每轮循环都要付费，长任务之前先估预算
• 像素操作脆弱：界面布局动一下、弹窗冒出来，坐标就可能点偏（第二弹"操作层"那篇讲过这个方向）
• 需要反馈信号：点完没反应，Agent 只能靠猜重试，循环越拖越长
• 能力在变强，但评估口径别混：官方最新是 OSWorld 2.0 的 offline 子集，GPT-6.1 Sol 比上一代 Sol 高 7 个百分点、离 Astra 差 2.1 个百分点、成本大概只有 Astra 的七分之一——注意这是另一套评估题，跟早前那篇说的"OSWorld 完成率七成上下"不是同一个东西，两个数字不能直接比
• 可用范围：官方公告的表述是 computer use"通过 API 以及 Codex、ChatGPT Work 提供，Codex 和 ChatGPT Work 需要 Pro 500 / Enterprise 套餐"——API 侧有没有额外门槛公告没细说，动手前以官方文档为准（computer use 文档），别只看一句"支持了"就觉得所有套餐都有

检查清单

顺手说一句：写这篇文章的时候，我还没在真环境里把 OpenAI 的 computer use 完整跑通一轮（需要 API 环境），上面所有推算都基于官方公告、官方定价和社区公开实验。这个"算账"的方法你自己就能复现——脚本参数按你的任务改一改，跑出来就是你的账单。至于"把同一任务按 computer use 的循环机制拆开算，账单会因为等待和重试膨胀成什么样"这件事，我下一篇写，结果比预想的有意思。

另外提醒一句：本文写于 09.29 DevDay 公告之后，computer use 的能力、价格和文档都在快速迭代，动手之前以官方文档最新版本为准。

「Agent 工程实战」系列

• 路线：界面线（computer use / Agent UI）
• 上一篇：10 A 公司数据记到 B 公司
• 下一篇：12 点界面贵 30 倍
• 系列索引（21 篇阅读路线）：Agent 放权前，先补权限、出站、发现这三道口子
• 专栏：Agent 工程实战
• 如果这篇对你有用，欢迎收藏；想追更可以关注「Agent 工程实战」专栏。