Gemini Computer Use 需要一个信任闭环

Google 在 6 月 24 日的公告中，将 computer use 作为 Gemini 3.5 Flash 的内置工具。此前这项能力以独立的 Gemini 2.5 computer use 模型形式提供；现在 Google 表示，开发者可以用 3.5 Flash 构建能在浏览器、移动端和桌面环境中观察、推理并执行操作的 Agent。

我认为这件事值得关注，因为 computer use 正在从专项演示赛道进入常规 Agent 工具箱。这很有用，但也让人不安。一个能查看屏幕、决定点哪里、并持续推进多步工作流的模型，已经不只是在回答问题。它在操作用户界面，而真正的产品是围绕这些操作建立的信任闭环。

答案快照

问题	我的看法
发生了什么？	Google 将 computer use 整合进 Gemini 3.5 Flash，并表示已通过 Gemini API 和 Gemini Enterprise Agent Platform 提供。
为何重要	屏幕驱动型 Agent 被纳入通用 Flash 模型，而不是走单独的预览通道，因此更容易嵌入日常自动化工作流。
落地门槛	文档明确提到沙箱、用户确认、白名单、防护栏、可观测性和规范的 GUI 环境，这些都是必须完成的工程工作。
我的核心观点	只有当团队把每个屏幕都视为不可信输入、每次点击都视为可审计操作时，computer use 才具备规模化价值。

产品动作的本质是整合

源页面将此举定位为 Gemini 3.5 Flash 在 agentic computer-use 任务上的最佳表现。Google 同时列出了希望开发者关注的用例：持续软件测试、长周期企业自动化，以及跨专业应用的知识工作。

配套的 Gemini API 文档让这次整合更加具体。文档列出了浏览器、移动端和桌面环境；带有 intent 字段的简化操作；可配置的安全策略；以及可选的截图扫描用于 prompt injection 检测。文档还指出 Gemini 3.5 Flash 是 computer use 的推荐模型，Gemini 3 Flash Preview 和 Gemini 2.5 旧版预览仍作为受支持选项列出。

这是一次实用的改进。如果我在构建 Agent，我更愿意通过一个统一的模型接口来处理工具调用、搜索 grounding、函数调用和 computer use，而不是为每个 GUI 任务拼凑一条独立的模型路径。好处显而易见：大量业务工作流藏在屏幕后面，而不是干净的 API 背后。

演示路径仍然满是工程细节

Google 提供了一个 参考实现，这个仓库提醒我们：computer use 并不是撒在桌面上的一把魔法粉。快速开始使用 Python、Playwright，以及本地浏览器或 Browserbase。可用模型中 gemini-3.5-flash 为默认选项。README 还指出了一个具体的 GUI 限制：Playwright 可能无法干净地捕获操作系统渲染的 select 菜单，建议的解决方案是使用 Browserbase 或注入自定义的 select 渲染。

这类细节很有价值，因为它戳破了 computer use 的美好幻想。屏幕 Agent 仍然受制于浏览器状态、应用布局、弹窗、认证、渲染差异和执行环境。模型是 headline，但运行框架才决定了 Agent 是否拥有一个足够干净的世界来施展动作。

安全故事才是真正的产品

Google 的博文用了一个简短但重要的章节来讲安全。文中表示 Google 针对 Gemini 3.5 Flash 的 computer use 做了定向对抗训练，并发布了两套可选的企业级防护系统：一套在敏感或不可逆操作时要求用户明确确认，另一套在识别到间接 prompt injection 时中止任务。文档还建议纵深防御，包括安全沙箱、人在回路验证和严格的访问控制。

API 文档走得更远。其最佳实践清单包括：沙箱执行、输入消毒、输入输出防护栏、导航白名单或黑名单，以及对 prompt、截图、模型建议动作、安全响应和客户端实际执行动作的详细日志记录。这份清单是我最信任的部分，因为它把 computer use 当作一个系统设计问题，而不是一个模型能力问题。

基准测试需要保持谦逊

围绕这则公告的 Hacker News 讨论很快聚焦到基准图、成本与速度的权衡、Flash 是否应该与更重量级的前沿模型对比，以及公开演示能否充分反映企业现实。这种反应在我看来很合理。对 Agent 来说，基准是起点，不是部署方案。

Google 自己的 Gemini 3.5 Flash 评估方法论指出，Gemini 的分数为 pass @1（除非另有说明），单次尝试设置不使用多数投票或并行测试时计算，非 Gemini 的结果通常来自提供商自报的数字，且往往使用了最大可用推理设置。这些并不让图表失去参考价值，只是意味着我会把它当作方向性证据，在给 Agent 接入任何关键系统之前，先跑自己的工作流评估。

真正的难点是不可信屏幕

Google DeepMind 关于 防御 Gemini 免受间接 prompt injection 的报告是我认为最重要的背景资料。报告指出，当前模型无法完美区分可信指令与不可信数据，能力更强的模型也不会自动更安全。报告还主张自适应评估和纵深防御，同时提醒不应单独依赖对抗训练。

这正是 computer use 的危险地带。一个网页、仪表板、邮件、工单或文档都可能成为模型的视觉上下文。如果这些内容能影响 Agent 下一步的操作，那么屏幕就不只是一张图片——它是一个部分由他人控制的输入通道。

Hacker News 讨论区以更直接的方式表达了同样的实际焦虑。开发者追问 SSO 背后如何运作、Agent 是否应该接触密钥、无障碍 API 是否比截图更干净的中间方案，以及屏幕控制是否只是一种更慢的 RPA 形式。我不认为这些质疑能推翻这个方向，它们恰恰定义了这个领域的工作内容。

我的结论

Gemini 3.5 Flash 获得内置 computer use 能力是有意义的，因为它降低了操作现有软件的 Agent 的接入门槛。我能看到它在测试、内部运营、调研，以及 API 不完整或缺失的重复性表单密集型工作流中的吸引力。

但我不会把这描述为一个已解决的自主性问题。更恰当的姿态是收窄一步：把它当作监督式自动化的一个更好的原语。最终胜出的实现，不会是那些让模型到处点击的方案，而是那些让模型的屏幕阅读、建议动作、确认、失败和日志足够透明，让团队能够信任整个闭环的方案。