GeminiDesktop GeminiDesktop
教程指南

Gemini 3 Computer Use 实测：让 AI 帮你订酒店前必须知道的 8 件事

发布于 · 作者： GeminiDesktop Team

Gemini 3 Computer Use 实测：让 AI 帮你订酒店前必须知道的 8 件事

结论先行： Gemini 3 Computer Use 是 Google 在 2026 年投入的“AI 直接操作你的电脑”能力——模型输出的不再是文字，而是 click_at(x, y) / type_text / key_combination 这类操作指令。对比 Claude Computer Use，它在坐标归一化和安全边界上做了更激进的设计，但也因此必须装桌面客户端才能跑起来。GeminiDesktop 目前是 macOS 上相对完整的实现，底层用 scap 抓屏、用 enigo 模拟鼠标键盘、用 AtomicBool + unblock channel 做 emergency stop。这篇把在正式放 AI 出去订酒店或发推之前你必须知道的 8 件事讲透。

一句话警示： Computer Use 不是实验室玩具，是一把真刀——开启前先搞清楚 deny-list、per-step approval、emergency stop 三个保险栓都在哪里。

1. Gemini 3 Computer Use vs Claude Computer Use：3 个维度对比

两家的 “Computer Use” 名字相同，内部设计有不小的分叉：

维度 Gemini 3 Computer Use Claude Computer Use (Sonnet 4.5+)
坐标归一化 模型输出 0–1000 范围的归一化坐标，客户端按当前屏幕尺寸缩放 模型直接输出像素坐标，对分辨率变化敏感
屏幕输入 截图 + 可选的 accessibility tree 元数据 截图为主，依赖模型从像素识别 UI
动作粒度 6 种原子 action（click_at / type_text / key_combination / scroll_at / wait / finish） 类似粒度，但命名和参数命名空间不同
安全边界 模型侧 + 客户端 deny-list 双层 主要靠客户端 approval + 用户审阅
Per-step approval 默认开启，MVP 不提供 trusted bypass 可配置，企业用户可在沙箱里关闭
价格档位 按 action 次数和图像 token 计费 类似，但图像 token 消耗比 Gemini 略低

坐标归一化是 Gemini 3 这代最实用的设计决策。模型在训练时把整个屏幕映射到 1000×1000 的虚拟格子，输出的 (x, y) 总是 0–1000 的整数。这意味着你把客户端从 MacBook Pro（2560×1600）搬到外接 4K（3840×2160）上，模型不需要重新学坐标系——客户端做一次线性缩放即可。Claude 的像素直出策略在高分屏跳变时容易偏移，这是实测里最明显的稳定性差别。

2. 为什么必须装桌面 app（网页版根本跑不起来）

很多人第一次看到 Computer Use 的 demo 会问：“为什么不能直接做成 Chrome extension？” 答案是：

  1. 屏幕截屏 API 不在浏览器范围内：Chrome 的 getDisplayMedia 能录屏，但不能稳定每秒给模型一张全屏 JPEG（tab 离开前台就停了），更别提录制多显示器或系统菜单
  2. 鼠标键盘模拟更不在浏览器范围：浏览器里的 “click”、“type” 都在 DOM 沙箱内，动不了浏览器之外的系统 UI。真正要点 Spotlight、切窗口、按 Cmd+Tab，必须走 OS 级的 enigo / robotjs 这类底层库
  3. 权限模型不同：浏览器的权限粒度是“当前 tab”，而 Computer Use 需要“整机授权”——macOS 的辅助功能权限、Windows 的 UI Automation 权限，这些都只对原生 app 开放

所以 GeminiDesktop 这类桌面客户端不是锦上添花，而是 Computer Use 在 macOS 上的唯一路径——即使 Google 将来开放 web 版，也只能操作浏览器本身，跨 app 的 workflow 做不了。

3. 6 种 action 的底层含义

Gemini 3 Computer Use 把所有操作压缩成 6 个原子 action，理解它们的语义对正确使用非常关键：

  • click_at(x, y)：在 0–1000 归一化坐标上做一次左键单击；客户端缩放后调用 enigo 的 MouseClick
  • type_text(text)：在当前获得焦点的输入框里逐字符输入；不做 shortcut 转义，所以输入 Cmd+S 要用 key_combination
  • key_combination(keys[])：同时按多个键，比如 ["cmd", "shift", "z"] 来做 redo；系统会先按下再依次释放
  • scroll_at(x, y, direction, distance)：在指定坐标滚动，方向 up/down/left/right，距离以 notch 为单位
  • wait(ms)：显式等待，避免因为网页异步加载太快而截屏截不到结果
  • finish(reason)：明确告诉客户端“任务结束”，不再发 action；这个是 graceful termination 的唯一合法路径

这 6 个 action 覆盖了 99% 的桌面操作，但也意味着任何连续的拖拽、悬停 tooltip、复杂手势都做不了——比如“拖动文件到废纸篓”在 Computer Use 的世界观里无法一次完成，必须拆成“click_at 选中 → key_combination Cmd+Delete”。

4. 安全 deny-list：rm / sudo / git push –force 的自动拦截原理

GeminiDesktop 在客户端维护了一个硬编码的 deny-list，命中任何一条就会在模型的 action 真正执行之前弹一个不可跳过的确认：

  • rm / sudo / chmod 777 / chown（shell 破坏性命令）
  • Cmd+Q / Alt+F4（强制退出，可能丢失未保存状态）
  • git push --force / git reset --hard（仓库状态破坏）
  • Cmd+Shift+Delete（跳过回收站直删）

拦截的实现思路是：客户端在执行 type_text 之前先把将要输入的字符串用一组正则匹配这个 deny-list；命中就把 action 挂起，推给主线程弹出 modal dialog。模型是“看不见”这个拦截的——它只会在下一轮收到一个 “rejected by user” 的状态，然后决定是改写策略还是停下来问你。

这个设计的哲学是：永远不相信模型“它自己会避免的”。即使 Gemini 3 的 RLHF 数据里教过它不要乱 rm，production 场景里让客户端兜底是唯一负责任的选择。

5. Per-step approval：为什么 MVP 不敢做 trusted bypass

默认配置下，每一个 action 在执行前都会弹一个简短的 approval prompt：“模型要 click_at(450, 230)——允许吗？” 用户按 Enter 放行、按 Escape 拒绝。

很多人第一反应是：“太烦了，能不能加一个 ‘trust this session’ 的开关？” MVP 阶段 GeminiDesktop 明确不做，原因：

  1. 模型偏见仍然真实：即使 Gemini 3 准确率比 2.5 高一大截，仍然存在“在错误的 button 上 click”的低概率事件。在一次 20 步的 workflow 里，单步错误率 0.5% 意味着整体失败率接近 10%——如果所有步骤都 bypass 掉 approval，用户损失会大
  2. UI 变化不可预期：网页的 A/B 实验、弹窗广告、Cookie banner 都会动态改变坐标。Approval 是用户确认“这确实是我想点的那个位置”的唯一机会
  3. 审计需求：对企业用户来说，每一次 AI 代操作都应该可回溯。Per-step approval 等于自动生成了一份操作 log

未来方向：根据“操作类型 + 用户历史习惯”做自适应 approval——比如你已经重复做过 20 次“订同一家酒店”，系统可以把这条链路标记为可信模板并允许 skip；但只要 UI 布局有显著变化，就立刻回到严格模式。

6. 实战 demo：让 AI 填一个表单 + 发一条推

我跑的一个完整 demo——让 Gemini 3 帮我去一个新产品的 landing page 上填 “Join Waitlist” 表单，然后到 Twitter 发一条推宣传。

Prompt： “帮我做两件事：1）去 example.com/waitlist，用 alice@example.com 提交邮箱订阅；2）然后到 Twitter 发一条推，内容大意是’我刚加入了 X 产品的 waitlist，看起来挺有意思’。”

模型的 action 序列大致如下（省略部分 wait）：

  1. click_at(500, 300) — 点地址栏
  2. type_text("example.com/waitlist")
  3. key_combination(["return"]) — 提交
  4. wait(800) — 等页面加载
  5. click_at(420, 510) — 点 email 输入框
  6. type_text("alice@example.com")
  7. click_at(500, 580) — 点 “Join Waitlist” 按钮
  8. wait(1200) — 等待“订阅成功”反馈
  9. key_combination(["cmd", "t"]) — 新标签
  10. type_text("twitter.com/compose/post")
  11. …（继续）
  12. finish("已提交邮箱订阅并发布推文")

整个过程在我的 M2 MacBook 上大约 90 秒完成，其中 40 秒是等网页加载和 approval 确认。相比我自己手动做同样两件事大约 3 分钟，提效确实明显。但更关键的观察是：在第 5 步模型第一次认错了位置（把一个装饰图标当成输入框），被我 reject 之后它自己重新 planning 找到正确的坐标——这正是 per-step approval 的价值。

7. Emergency stop：AtomicBool + unblock pending approval 的原理

当 AI 跑疯了怎么办？GeminiDesktop 的设计里有一个全局 emergency stop（默认快捷键 Cmd+Shift+.），按下后的行为：

  1. 设置全局 AtomicBool 为 true
  2. 正在执行的 enigo 动作会在下一次 tick 检查到此标志后立刻 abort
  3. 正挂起等待 approval 的 channel 会被 unblock，对等方收到 “cancelled” 信号
  4. WebSocket 连接主动关闭，模型不会再收到新的 frame

为什么要 AtomicBool + channel 两路？因为 AI 的动作可能处于两种状态：

  • 正在执行 OS 调用（enigo 里的 mouse move）→ 需要 AtomicBool 来让 worker thread 在下一次循环 check 时退出
  • 在等待用户 approval（channel 阻塞）→ 需要主动 unblock 那条 channel，否则 AtomicBool 无效（worker 还卡在 channel recv 上）

这个双路拦截是很多 “half-finished” AI 自动化工具的坑——只做了 AtomicBool 就不够，用户按下 emergency stop 后还会卡好几秒才停。GeminiDesktop 的实现是双路并行发信号，确保最多 200ms 内完全停下。

8. 已知限制：macOS 辅助权限 + Windows 屏幕捕获

最后三个实战中会踩到的限制：

  • macOS 辅助功能权限：Computer Use 要用 enigo 模拟鼠标键盘，这需要在 “系统设置 → 隐私与安全性 → 辅助功能” 里给 GeminiDesktop 开权限。MacOS 对这个权限很敏感，首次开启需要重启 app；跨版本升级有时会把权限自动撤销
  • Windows 屏幕捕获：目前 scap 库在 Windows 上的支持还不完整，GeminiDesktop 官方构建在 Windows 侧暂时还不能跑 Computer Use（能跑文本聊天和 Live，但 Computer Use 禁用）。roadmap 上是 2026 Q3
  • 跨显示器一致性：当你有多台显示器且分辨率不同时，模型的 1000×1000 坐标系会应用到“当前活动窗口所在的那块屏幕”上。跨屏拖动的 workflow 仍然不稳定，建议在单屏环境下跑

想先在风险更低的语音引导场景里体验 Gemini 3 的能力，可以参考姊妹篇 Gemini Live Mac 桌面版教程——那里是“让 AI 看屏幕给你建议”，不会真的去点什么。如果你想直接深挖 Google 的官方 API 文档，Google AI 开发者平台 有完整的 Computer Use 接口说明。

常见问题

Q1：可以用我自己的 Gemini API Key 跑 Computer Use 吗？

A： 可以。GeminiDesktop 的 BYOK 方案把你的 key 直传到 Google；客户端本地调用 computerUse: 工具接口。注意 Computer Use 的 token 消耗比纯文本高 3–5 倍（要传屏幕截图），BYOK 用户需要监控账单。

Q2：AI 看到我的敏感窗口怎么办？

A： 在开启 Computer Use 之前把不想被看到的窗口（密码管理器、私人聊天）关掉或最小化到其他桌面。roadmap 里有“按窗口白名单”的捕获模式，但 MVP 阶段只能靠用户自律。

Q3：Computer Use 能完全自动化跑一个长 workflow 吗（比如 50 步）？

A： 技术上可以，实践上不建议。每增加 10 步失败率会显著放大，而且 per-step approval 的存在就是要你在过程中随时叫停。推荐把长 workflow 拆成若干 3–8 步的小任务，每个任务独立跑。

Q4：它和 Zapier / n8n 这类工作流工具是竞争关系吗？

A： 不完全是。Zapier 靠的是“有 API 的 SaaS 互相连接”，Computer Use 靠的是“没 API 的桌面 UI 也能自动化”。真正的 killer 场景是那些老旧企业软件——它们没有任何 API，但长得像普通网页/客户端，AI 可以用眼睛看着点。两者更多是互补。

结语

Gemini 3 Computer Use 让“AI 自主操作电脑”从 demo 走到 production 入口，但离“放心让它干任何事”还有距离。理解 deny-list、per-step approval、emergency stop 这三道保险的机制，是你把它用到真实任务里的前提。从“订酒店”这种低风险单项任务开始，逐步建立对模型稳定性的信任——这也是 MVP 不提供 trusted bypass 的潜台词。