正式可用不等于可以撒手：Gemini Computer Use GA 到底变了什么

一句话先说清楚：变的是状态，不是魔法

2026 年 10 月 30 日，谷歌在 Gemini API 的更新日志里只写了两行：Computer Use 工具在 Interactions API 和 GenerateContent API 上正式可用（GA）。没有新模型、没有新价格、没有新的动作表。这句话值得单独拎出来，因为它决定了整篇文章的调子：如果你之前因为“还是预览”而不敢把这条路放进生产计划，现在那个挡箭牌没有了；但如果你以为 GA 意味着“模型会自己把电脑操作好”，那恰恰是误读。谷歌的文档从头到尾讲的都是一套分工：模型只负责看屏幕、提建议，真正点鼠标、敲键盘、拍下一张截图的，永远是你写的客户端代码。

这个区分不是咬文嚼字。过去一年里，电脑操作类 agent 最常见的翻车，恰恰来自把“建议”当成“执行”：演示里模型点对了按钮，上线后却在某个弹窗、某个加载延迟、某个分辨率变化处一路错下去。GA 没有把这部分不确定性收走，它只是告诉你，接口的这一侧已经稳定到可以认真建系统了。稳定的是契约，不是结果。

它到底怎么跑：四步循环，一个都不能省

按谷歌官方文档的写法，一个 Computer Use 任务是这样转起来的。第一步，你的应用发请求，里面带上 Computer Use 工具、目标环境、用户指令和当前屏幕截图。第二步，模型看图、读指令，返回一个建议的函数调用，比如点击、滚动或按键；对 Gemini 4 和 Gemini 3.x 模型，返回里还会带一个 intent 字段，用一句话解释它为什么选这一步。第三步，你的客户端解析这个调用，把归一化坐标换算成真实视口尺寸，再用 Playwright 之类的工具真正执行；如果动作被安全系统拦下，你的客户端要停下来或者处理中断。第四步，执行完拍一张新截图，用 function_result 发回去，换下一步。如此循环，直到任务完成或被终止。

这里有三个细节值得做开发的人停下来想一想。第一，坐标是归一化的，文档示例里是按 1000×1000 的参考尺寸给的，换算错了，点得再准也是错地方。第二，intent 不是装饰，它是你事后复盘、事中审计的唯一线索：没有它，你只知道 agent 点了哪里，不知道它以为自己在点什么。第三，截图是循环的燃料，也是成本的来源：每一步都要传一张图，步骤一多，账单和延迟都会跟着涨。一个只会在演示里跑三步的流程，和一个要在生产里跑三十步的流程，根本不是同一个工程问题。

官方文档给的最小示例也印证了这种朴素：Python 里用 google-genai 客户端，模型字段填 gemini-3.8-flash，工具数组里写 type 为 computer_use、environment 为 browser，就能发起一次交互。示例的模型只是文档示例，不是 GA 条目本身的保证——GA 条目里没有点名任何模型。做选型的人要分清这两层：条目告诉你工具可用了，文档告诉你现在能怎么调，真正落到你的账号上，还要以你那边的模型列表和配额为准。

两个 API、三种环境，先把边界画对

这次 GA 横跨两个接口：Interactions API 和 GenerateContent API。不要把这理解成“随便用哪个都一样”。Interactions 是谷歌为 agent 式交互准备的入口，文档里的 Computer Use 示例也以它为主；GenerateContent 则是更通用的生成接口。你的老代码如果本来就走 GenerateContent，GA 意味着你不用为了用这个工具而整体迁移；你的新项目如果从零开始，跟着文档示例走 Interactions 会少踩很多对不上的地方。选哪个，取决于你现有的调用链，而不是哪个名字听起来更新。

环境分三种：浏览器、手机、桌面。文档列出的典型用途也很克制：重复的数据录入和表单填写、网页应用与用户流程的自动化测试、跨网站搜集商品信息和价格评论。注意这份清单里没有“帮我把这台电脑全权接管”这种话。浏览器环境是最容易落地的，因为执行器就是 Playwright 这样的浏览器自动化工具，沙箱也相对好做；桌面和手机环境的执行面更广，意味着你要自己补的隔离、权限和回滚也更多。先从浏览器环境把循环跑稳，再谈扩展，是更诚实的顺序。

同一份更新日志里还有两条邻居，值得一起读。10 月 27 日，Gemini API CLI 进入 beta，给写脚本和跑 CI 的人一个无依赖的命令行入口；10 月 26 日，付费层的新 GenerateContent 项目默认开始存请求，老项目保持原设置。这两条和 Computer Use 没有直接关系，但它们拼出同一幅图：谷歌在把 Gemini API 从“调一次模型”往“跑长期 agent 任务”的方向收拢。Computer Use 的 GA 是这幅图里的一块，而不是孤立的一次发布。

安全那部分，文档写得比营销话实在

真正让我觉得这篇文档值得认真读的，是它的安全一节没有含糊。模型返回里可能带 safety_decision，把动作分成三档：常规放行、需要确认、直接拦截。需要确认时，你要先问用户，拿到确认后再把 safety_acknowledgement 放进 function_result；被拦截时，客户端应该停下来，而不是换个说法再试一次。文档还列了一组内置的安全策略类别：金融交易、敏感数据修改、通信工具、账号注册、数据修改、用户同意管理、法律条款与协议。翻译成人话就是：凡是会花钱、会改数据、会对外发消息、会替用户签东西的动作，都不应该让 agent 自己悄悄干完。

另外还有一个默认关闭的开关，必须单独点名：提示注入检测。开启后，它会扫描截图里有没有藏着的对抗性指令，比如“忽略之前的命令”；默认是关闭的。这意味着，如果你直接照抄最小示例上线，你的 agent 默认是没有这层扫描的。把检测打开、把沙箱搭好、把需要确认的动作清单写进系统指令，这三件事不是“上线前再补”的优化项，而是 Computer Use 项目的上线门槛。文档还明确建议在沙箱虚拟机或容器里跑执行环境，把 agent 和宿主机隔离开——这不是可选项，是这类工具的基本卫生。

判断一个团队有没有准备好用 Computer Use，有个很简单的试金石：它能不能说清楚，哪些动作 agent 永远不许自己做。这个清单如果写不出来，GA 与否都不重要，因为第一个出事的场景一定在清单之外。反过来，清单写得越具体，GA 的价值越大：接口稳定了，你才值得花时间把清单、确认流程和审计日志做扎实。

给 vibe coder 的判断：值得试点，不值得全押

对独立开发者和小团队来说，我的判断是这样：Computer Use GA 值得放进你的工具箱，但不值得成为你下一个产品的唯一支柱。值得试点的场景有三个特征：任务本身就是“在现成界面上重复操作”，比如跨站比价、表单回填、回归测试里那几条每次都要人肉点一遍的流程；失败的代价可控，比如填错了可以重填、点错了可以撤销；你有能力搭沙箱、有能力接确认流程。三个特征缺一个，都应该先缓一缓。

不值得全押的理由也很直接。第一，GA 条目只有两行，没有给这个工具单独定价、单独定限额、单独给基准成绩——你没法拿着这篇公告去跟老板或客户承诺准确率和成本，只能拿自己的测试集去测。第二，截图循环天然怕长任务：步骤越多，坐标漂移、页面变化、弹窗干扰的概率越高，兜底逻辑比主流程更重要。第三，能用 API 或 MCP 直接调的服务，永远优先于“让 agent 去点界面”：界面是给人看的契约，API 才是给机器准备的契约。Computer Use 应该是你走投无路时的桥，而不是第一选择。

如果你决定试点，建议按这个顺序来：先在浏览器环境、只读或可撤销的任务上跑通循环；把模型 ID 写死，不要依赖示例默认值；打开提示注入检测；把金融、发消息、改数据、签协议四类动作默认设为需要确认；每一轮循环都把截图、建议动作、intent 和安全判定记下来，方便出问题时复盘；最后再去碰桌面环境。GA 给你的不是一张免检牌，而是一个可以长期维护的起点。把起点当成终点的人，会在第一个生产事故里重新认识这个工具。

它和同周期的其他“电脑使用权”有什么不同

同一周里，“让 agent 操作电脑”这个题目出现了好几种解法，放在一起看才有意思。Vercel 的 agent-desktop 走的是系统无障碍树：不靠猜像素，而是读界面本身的结构，引用稳定、动作可重试；谷歌的 Computer Use 走的是截图路线：模型看图、给坐标，你的客户端再执行。前者适合结构清晰的桌面应用，后者适合那些没有结构化接口、只能看界面的网页流程。两者不是谁取代谁，而是同一道题的不同约束：有结构就用结构，没结构才用眼睛。

同样，VS Code 1.144 里那个实验性的 Computer Use 也值得区分：那是编辑器里的 agent 去驱动你本机的桌面应用，场景是开发工作流本身；而 Gemini 的 Computer Use 是 API 里的一个工具，场景是你自己产品的自动化任务。一个是“帮我写代码的人顺手帮我点一下”，一个是“我的服务要替用户去操作第三方界面”。把这两个混在一起谈“电脑使用权”，很容易得出错误的选型结论。GA 的真正意义，其实就藏在这个区分里：它不是给聊天窗口加了个新玩具，而是给开发者多了一个可以写进自己产品的、状态稳定的工具。至于这个工具能不能撑起你的产品，那要看你的沙箱、确认流程和兜底逻辑，而不是看公告里的 GA 两个字母。

成本和延迟：截图循环的账要先算清楚

很多团队在评估 Computer Use 时只算模型调用价，漏掉了真正的大头：截图本身。循环里的每一步都要把一张图发给模型，模型每一步都要重新看图、重新定位。任务越长，这个账就越难看：十步的任务要传十张图，三十步的任务要传三十张图，中间任何一步因为页面加载慢了一拍而多拍一张，成本和延迟就再往上走一格。更麻烦的是，截图不是可以随意压缩的输入，压得太狠，按钮文字糊了、坐标就飘了；不压，账单就涨了。这个平衡点没有通用答案，只能在你自己的目标网站上实测：同一个任务跑十遍，看步骤数的分布、看失败集中在哪一步、看重试策略到底是在救场还是在烧钱。

还有一个经常被忽略的成本：人工确认。安全判定里那一档需要确认，意味着你的流程里必须留一个等人点“继续”的口子。口子留得太宽，agent 几乎每步都要等人，自动化就退化成“有人在旁边看着的半自动”；口子留得太窄，真正危险的动作又可能滑过去。我的建议是按动作分级，而不是按步骤分级：浏览、搜索、翻页这类只读动作可以放行；填表、提交、改设置这类动作先填好、停下来等确认；付款、发消息、删数据、签协议这类动作永远不自动执行。这个分级表应该写在产品文档里，而不是只存在某个开发者的脑子里，因为它就是你这个功能的安全边界本身。

对小团队来说，还有一个更现实的算法：如果一个任务用截图循环跑十次要花掉的钱，已经超过请人写一个专用爬虫或接一个官方接口的成本，那就不要用 Computer Use。GA 没有改变这个算式，它只是让算式里的“接口会不会下个月就变”这一项从不确定变成了确定。确定性值得付费，但不值得为它多付每一张截图的钱。先算账，再谈架构，这句话对所有 agent 工具都适用，对截图循环尤其适用。

写给准备动手的人：一份可以直接照做的清单

最后把前面所有的判断收成一份清单，照着做至少不会在第一天就踩坑。第一，环境先选浏览器，任务先选只读或可撤销，模型 ID 写死成你实测过的版本，不要跟着示例默认值走。第二，执行器必须跑在沙箱虚拟机或容器里，宿主机上不要放真实账号的登录态和敏感文件，测试账号和生产账号从第一天就分开。第三，提示注入检测默认是关闭的，记得手动打开，并且在你的测试集里专门放几张带干扰文字的截图，看它是不是真的拦得住。

第四，确认流程要先于自动化流程上线：需要确认的动作必须真的停下来等用户，确认通过后才把确认标记写回下一轮请求；被拦截的动作要记录原因、停止任务，而不是悄悄换一条路重试。第五，每一步都记日志：截图、模型建议的动作、intent 解释、安全判定、实际执行结果，缺了任何一项，出问题时你都只能猜。第六，给任务设上限：最多步数、最多重试次数、单任务最长耗时，超了就体面地停下来、把中间状态还给用户，而不是无限循环下去烧钱。第七，定期回归：目标网站一改版，你的截图循环就要重新跑一遍测试集，因为界面变了，坐标和 intent 的假设可能全都不成立了。

这份清单没有一条是 GA 公告里直接给你的，但每一条都是 GA 之后才值得认真投入的理由。预览期的工具可以先玩着，GA 的工具才值得配上沙箱、日志、确认流程和回归测试。谷歌这次只发了两行公告，恰恰说明它把剩下的工作都留给了开发者：接口稳定了，责任也就到你这边了。能把这份责任接住的团队，会发现 Computer Use 是一个很趁手的工具；接不住的团队，会发现它是一个很贵的教训。两种结果的分界线，从来不在公告里，而在你上线前写的那份清单里。

最后再补一句：不要等到用户投诉才发现你的 agent 在某个网站上走偏了。试点阶段就把失败案例攒起来，按“看错、点错、没停住”三类归档，每周看一次分布。看错多，说明截图质量或提示要调；点错多，说明坐标换算或执行器要修；没停住多，说明安全判定和确认流程有洞。这三类数字，才是你判断一个 Computer Use 功能能不能从试点走向正式的真正依据，比任何公告里的状态词都可靠。