# Gemini Computer Use 需要一个信任闭环

**Summary:** Google 将 computer use 整合进 Gemini 3.5 Flash；真正的考验在于，团队能否让屏幕驱动型 Agent 变得可观测、可沙箱化、可中断。

- Canonical: https://markhuang.ai/zh/news/gemini-computer-use-trust-loop
- Language: zh-CN
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-06-25
- Section: News
- Tags: AI, Gemini, Agent, 安全, 自动化
- Source: [Google Blog](https://blog.google/innovation-and-ai/models-and-research/gemini-models/introducing-computer-use-gemini-3-5-flash/)
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![一个卡通 AI 助手穿梭在浏览器、手机和桌面屏幕之间，人类监督员在旁守护安全动作循环](https://cdn.markhuang.ai/news/gemini-computer-use-trust-loop/hero.webp)

*真正重要的变化不是模型学会了点击，而是一个主流模型学会了在混乱的软件环境中执行操作——信任必须在每一步周围被工程化地构建出来。*

Google 在 [6 月 24 日的公告](https://blog.google/innovation-and-ai/models-and-research/gemini-models/introducing-computer-use-gemini-3-5-flash/)中，将 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 文档](https://ai.google.dev/gemini-api/docs/computer-use)让这次整合更加具体。文档列出了浏览器、移动端和桌面环境；带有 `intent` 字段的简化操作；可配置的安全策略；以及可选的截图扫描用于 prompt injection 检测。文档还指出 Gemini 3.5 Flash 是 computer use 的推荐模型，Gemini 3 Flash Preview 和 Gemini 2.5 旧版预览仍作为受支持选项列出。

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

![一个卡通 AI 助手沿着蜿蜒的工作流穿过多个空白应用面板，人类监督员在旁观察](https://cdn.markhuang.ai/news/gemini-computer-use-trust-loop/why-it-matters.webp)

*computer use 最有说服力的理由不是优雅，而是真实的工作往往运行在笨拙的界面上——这些界面从来不是为 Agent API 而设计的。*

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

Google 提供了一个 [参考实现](https://github.com/google-gemini/computer-use-preview)，这个仓库提醒我们：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 当作一个系统设计问题，而不是一个模型能力问题。

> **Info:**
>
> 如果我在公司内部落地这套方案，我会从最无聊的控制措施开始：一个严格限制的浏览器配置、不暴露任何环境变量中的密钥、白名单、动作日志、确认关卡，以及每个任务之间的干净重置。只有当工作流积累了足够的证据之后，才应该给模型更多自由度——而不是因为某张基准图很亮眼就放手。

## 基准测试需要保持谦逊

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

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

![一个卡通 AI 助手站在快速自动化路径与受保护的人类审批关卡之间](https://cdn.markhuang.ai/news/gemini-computer-use-trust-loop/tradeoff.webp)

*权衡很简单：Agent 的自主性越高，确认边界就需要越刻意地设计。*

## 真正的难点是不可信屏幕

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

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

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

![一个卡通 AI 助手在透明沙箱内检查不可信的屏幕内容，人类在旁审阅空白审计卡片](https://cdn.markhuang.ai/news/gemini-computer-use-trust-loop/workflow-risk.webp)

*屏幕驱动型 Agent 需要沙箱，因为屏幕本身可能携带用户从未打算传达的指令。*

## 我的结论

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

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