你可能遇到过这种情况：模型能识别截图，也能告诉你“点击右上角的提交按钮”，但程序运行结束，浏览器什么都没发生。
换个支持视觉的模型，不解决问题；把 Base URL 改成统一接口，也不一定解决问题。
因为“返回一个操作建议”和“把操作执行完”，中间还隔着一套程序。
10 月 30 日，Google 将 Gemini API 的 Computer Use 工具正式开放，覆盖 Interactions 和 GenerateContent 两套 API。这次值得开发者关注的是工具进入 GA，而不是又发布了一个新模型。来源：Google 官方更新记录
这篇不列跑分，也不做未经验证的省钱对比。我们沿着一次浏览器操作，拆清三个问题：接口负责什么，自己的代码还要负责什么，以及怎样避免把模型的建议直接变成真实操作。
核对日期：2026 年 11 月 1 日。文中的 Python 示例只对构造记录进行本地检查，不调用模型、不启动浏览器，不代表已经完成真实 Computer Use 接入。
一、模型返回了 click，不代表浏览器已经点击
Google 的实现指南给出的机制是：应用提供截图，模型返回 UI 操作建议，客户端执行后，再把新的画面和操作结果送回去。执行环境需要自己准备，可以使用 Playwright 等工具。来源：Computer Use 官方指南
把它放进一个具体场景：你希望 Agent 在测试订单后台找到一张订单，填写处理备注，并停在提交之前。
这不是一次“问答”，而是一段持续变化的工作流：
模型提出“点击坐标 A”，不等于你的程序已经知道：
现在的窗口是否还是刚才那一个；
页面有没有在请求期间滚动或弹出提示框；
A 对应的是“查看详情”，还是“确认退款”；
上一次点击是否已经生效，只是回传结果超时了。
应用层要处理的状态
这些是应用层需要处理的状态，不应该靠一句“请小心操作”来代替。
尤其是最后一种情况：页面提交成功，但截图回传失败。如果你的恢复逻辑是“超时就重试刚才的点击”，第二次提交可能发生在你还没看清页面之前。
因此，我建议把异常恢复设计成：先重新观察、核对业务状态，再决定是否允许下一步。不要把模型请求的重试策略，直接套到有副作用的 UI 操作上。
二、统一 Base URL 解决入口，不自动解决执行链
Google 确实提供了兼容 OpenAI SDK 的调用方式，官方示例通过配置 Key、Base URL 和模型调用 Gemini。不过，那份兼容性说明不能作为“所有原生工具都能原样迁移”的证明。来源：Google 的兼容接口说明
三个层面要分清
这里要分清三个层面：
|
层面
|
需要验证什么
|
仅凭什么还不够
|
| --- | --- | --- |
|
模型入口
|
账户能否调用目标模型，鉴权与路由是否正确
|
控制台能看到模型名
|
|
工具协议
|
请求字段、动作响应、结果回传是否完整支持
|
一次普通聊天返回 200
|
|
执行闭环
|
能否执行、确认、观察结果并处理异常
|
响应里出现了 click
|
举个容易误判的例子：你用同一个模型完成了一次图片问答，只能说明这条路径能处理该次图片问答，不能顺带证明它能保留 Computer Use 的工具配置、安全信息和后续结果回传。
对 API 聚合或中转服务也是一样。统一入口有价值，但接入时应当逐项验收，不要把“兼容聊天格式”理解为“兼容全部 Agent 能力”。
如果使用 Google 原生 Interactions，官方将一次交互组织为多个步骤，包括工具调用、工具结果和模型输出；它也支持通过交互 ID 关联后续轮次。适配时，这些状态关系同样需要被保留。来源：Interactions API 概览
这也是为什么本文没有把一个通用聊天端点，直接填进 Computer Use 示例：没有经过对应协议和工具链验证，就不能写成“改地址即可运行”。
三、最先补的代码，不是点击函数，而是动作检查
一个最简执行器很容易写成这样：收到 click 就点，收到 type 就输入，收到 navigate 就打开网页。
但这样会把模型输出直接接到有权限的浏览器上。
我更建议先把动作分成三类：
停止：不认识的动作、无法解释的安全状态、格式错误或越界参数。
人工审核：可能影响页面或业务状态的操作。
仅通过本地检查：满足当前示例规则，但仍未执行，更不代表业务完成。
Google 的文档要求应用处理 require_confirmation，不能自动跳过人工确认。文档的动作参数表使用 0—999 的归一化坐标，执行前需要换算到实际视口。来源：动作参数及安全处理
保守检查器示例
下面这段是我们自己写的保守检查器，不是 Google SDK，也不是完整安全系统。
它只识别 click、take_screenshot、wait 三种动作；所有点击都交给人工审核。其他动作即便是平台支持的合法动作，在这个示例里也会停止，等你明确实现后再开放。
保存为 action_check.py。这段函数不需要安装任何第三方库，Python 3 即可运行。传入的是从原生响应里提取、转成普通字典的单个 function_call 步骤，不是完整响应，也不是任意 SDK 对象。
在文件末尾追加下面的构造样例：
执行：
六条构造记录的本地结果如下：
|
输入
|
结果
|
原因
|
| --- | --- | --- |
|
点击 (450, 120)
|
REVIEW，像素为 (648, 108)
|
坐标可解释，但不自动批准点击
|
|
同一点击，附带确认要求
|
REVIEW
|
等待人工审核，不写确认回执
|
|
截图动作
|
READY_DRY_RUN
|
仅通过此处的参数检查，没有真的截图
|
|
等待 100000 秒
|
STOP
|
超过本示例允许的单次等待预算
|
|
点击坐标包含 1000
|
STOP
|
不在本例采用的 0—999 范围
|
|
execute_shell
|
STOP
|
未实现的动作，不能擅自交给系统执行
|
两个实现选择
注意两个实现选择。
第一，type(v) is int 是有意这样写的。在 Python 里，布尔值也能通过 isinstance(v, int)，但这里不应把 True 当成有效坐标。
第二，越界坐标直接拒绝，不把 1000 静默修正成 999。修正后的点击可能落到另一个控件上，参数看起来“合法”了，实际意图却可能已经改变。
等待最多 5 秒、视口边长最多 16384，是本文检查器的本地约束，不是 Gemini 官方限制。生产系统还需要总时长、总轮次、费用、文件和访问范围等独立预算。
四、检查通过，不等于获得了操作授权
最容易被误用的是 READY_DRY_RUN。
这个状态只表示：“这个动作符合本示例认识的格式和参数规则。”它不表示用户同意执行，也不表示截图里没有隐私，更不表示执行后会成功。
READY_DRY_RUN 不含授权
因此，这个函数刻意没有以下功能：
没有访问 API 或浏览器的代码；
没有接受一个
approved=True就放行动作的入口；没有自动生成
safety_acknowledgement；没有根据
intent文字判断“这个动作安全”。
安全字段如果存在，本例只识别 require_confirmation，其余值一律停止，包括它尚未处理的允许状态。这样的策略会拒绝一部分实际可用响应，但不会假装已经实现完整协议。
更重要的是，即使响应没有安全字段，点击仍然进入人工审核。模型没有要求确认，不等于应用已经获得授权。
真正接执行器时，人工确认还应绑定本次动作、目标环境和当前页面。确认之后如果页面跳转了，不能拿旧确认继续点击新页面。
这套状态检查，也无法代替容器隔离、访问控制、截图脱敏或网络策略。比如“截图”本身通常不修改页面，却仍然可能包含客户信息；把截图发给外部模型之前，需要另行解决数据权限问题。
五、如何判断自己真正跑通了，而不只是返回了 200
我建议第一轮验证放在不含真实客户数据、没有付款能力的测试后台。沿着前面的订单备注流程，一次只验收一条完整链：读取页面、定位订单、填写备注、提交前暂停。
第一轮验证放在测试后台
至少留下这几份对应证据：
发给模型的是哪张截图，当时页面、视口和任务是什么。
返回了哪个动作，参数和安全信息有没有在适配过程中丢失。
应用为什么放行、停止或要求人工审核。
执行器实际做了什么，页面发生了什么变化。
任务为什么结束，是达到目标、等待人工，还是异常中断。
如果浏览器没动，先看动作有没有进入执行器；如果点错位置，先看截图尺寸、视口和页面状态；如果越过了提交边界，先看授权与动作检查；如果任务反复循环，先看状态回传和终止条件。
不要一出现问题就换模型。把这些记录对齐之后，才知道问题发生在哪一层。
Google 也提供了可参考的浏览器执行项目，其中区分本地 Playwright 和远程浏览器环境。不过仓库示例的模型、配置与当前文档可能不完全同步，接入时应逐项核对，不要直接把旧默认值当成最新推荐。来源：Google 官方参考仓库
本文的本地验证覆盖了坐标边界、类型、未知动作、安全状态、等待预算等 9 项检查，全部通过。但没有进行付费模型调用、真实浏览器闭环或成功率测试；这些仍是部署前要补的验证。
六、对多模型接入来说，真正值得统一的是验收口径
今天让模型看懂截图，明天可能希望它操作浏览器、调用业务工具，再切换另一家模型做复核。
到这一步，仅仅统一 Key 或请求地址还不够。你还需要知道：换模型之后，动作和结果如何表达，哪部分由服务端负责，哪部分必须由自己的应用执行，出了问题能否定位到具体步骤。
Computer Use 进入 GA 是一个值得跟进的信号，但对开发者来说，下一步不是直接扩大 Agent 的操作权限，而是把这一条链测完整。
通过 Genvis 接入的起点
如果你正在通过 Genvis 接入多模型，可以先带着“目标模型、客户端、所需工具、脱敏报错”做一次兼容性核对。 先确认模型与协议在当前渠道可用，再决定是否迁移完整工作流；本文不代表 Genvis 已支持 Gemini 原生 Computer Use，也不代表某条聊天接口已经通过上述验收。
接口接通，是开始。知道它何时能动、何时必须停，才是自动化真正可用的前提。
