Gemini API Computer Use GA 落地：UI 自动化、桌面 Agent 工程实战解析

2026 年 10 月 30 日，Google 宣布 Gemini API 的 Computer Use 工具正式进入 GA（General Availability）阶段，覆盖 Interactions API 和 GenerateContent API。该能力允许模型通过屏幕截图理解界面，并生成点击、输入、滚动和页面导航等操作指令，由开发者配置的客户端执行器完成实际操作。本文梳理 Computer Use 从独立模型到内置工具的发展过程，分析两套 API 的使用方式，并通过 Python、Google GenAI SDK 和 Playwright 拆解浏览器自动化 Agent 的构建流程。同时讨论多轮任务执行、提示词注入、人工确认和沙箱隔离等生产环境问题。

一、Gemini API Computer Use 正式 GA，UI 自动化进入新阶段

2026 年 10 月 30 日，Google 在 Gemini API 官方更新日志中宣布，Computer Use 工具正式进入 GA 阶段。这次发布覆盖 Interactions API 和 GenerateContent API 两套接口。

对于开发者而言，这次更新的意义不只是增加一个模型工具，而是将视觉理解、动作规划和客户端执行进一步整合到 Gemini API 的 Agent 开发流程中。开发者可以基于统一的模型调用体系，构建能够观察屏幕、判断操作目标并执行 UI 动作的自动化应用。

Computer Use 主要面向三类环境：

• Browser：操作网页、填写表单、执行网页测试。
• Mobile：在移动设备环境中执行应用操作。
• Desktop：控制桌面界面，完成文件管理和软件操作。

这与传统的文本生成存在明显区别。过去，AI 通常输出操作步骤，用户需要自己打开软件、寻找按钮并完成任务。Computer Use 则可以将这些步骤转化为具体的界面操作请求，再交给执行环境处理。

例如，用户要求 Agent 检查一个网站的注册流程。Agent 可以打开网页、输入测试信息、提交表单、观察页面反馈，并根据新截图继续执行。

但需要明确：GA 并不意味着模型能够无条件操作所有软件，也不代表每个自动化任务都能一次成功。模型负责识别界面和提出动作，客户端负责执行。权限、异常处理和安全审核仍然需要开发者设计。

二、从 Gemini 2.5 到 Gemini 3.5 Flash：Computer Use 经历了什么变化？

Google 的 Computer Use 并不是在 10 月 30 日才首次出现。回顾官方发布记录，可以看到它经历了独立模型、内置工具预览和正式 GA 三个阶段。

Computer Use 发展时间线

• 2025 年 10 月 7 日：Gemini 2.5 Computer Use 发布。Google 首次通过 Gemini API 推出专门的 Computer Use 模型，基于 Gemini 2.5 Pro 的视觉理解和推理能力，面向浏览器和移动端 UI 自动化任务。
• 2026 年 6 月 24 日：成为 Gemini 3.5 Flash 内置工具。Computer Use 不再只依赖独立的专用模型，而是集成进 Gemini 3.5 Flash。Google 同时公布浏览器、移动端和桌面环境支持，以及安全策略和提示词注入检测能力。
• 2026 年 10 月 30 日：Computer Use 正式 GA。Google 将该工具正式推向 GA，开放 Interactions API 和 GenerateContent API 两套接口。

这条演进路线反映出一个重要变化：Computer Use 从专门的模型能力逐渐变成通用模型体系中的工具能力。

不过，不能将 2026 年 6 月的 Gemini 3.5 Flash 预览发布与 10 月的 GA 混为一谈。两次更新分别代表能力集成和产品发布阶段的变化。

还有一个值得开发者留意的细节：截至 2026 年 11 月 2 日，Google 当前文档已经将 Gemini 3.6 Flash 列为 Computer Use 推荐模型，Gemini 3.5 Flash 则被标记为上一代稳定版本；Gemini 3.5 Flash-Lite 也支持该工具。因此，部署新项目时不应只沿用 6 月的模型配置。

三、Computer Use 的底层工作机制：模型负责决策，客户端负责执行

Computer Use 的执行过程可以拆分为一个持续循环。

第一步，应用将用户指令和当前屏幕截图发送给 Gemini。模型根据界面内容判断当前状态，并生成下一步操作。

第二步，模型返回 function_call。其中包含动作名称、坐标、输入文本等参数。对于 Gemini 3.x，动作还可以携带 intent 字段，用于说明该操作的目的。

第三步，客户端解析动作，并使用 Playwright 等自动化工具执行。

第四步，客户端重新获取屏幕截图，将执行结果作为 function_result 返回模型。模型再根据最新界面状态决定下一步操作。

这个过程可以概括为：
用户任务 → Gemini API → 截图理解与动作规划 → 返回 function_call → 客户端安全检查 → Playwright / Desktop 执行 → 重新截图 → function_result → Gemini 再次决策，循环直至任务完成。

这里最重要的工程原则是：模型输出的是动作建议，不是已经完成的操作。

例如，模型返回：

{
   "type": "function_call",
   "name": "click",
   "arguments": {
     "x": 450,
     "y": 120,
     "intent": "Click the search box"
   }
}

客户端需要读取 name 和 arguments，确认动作处于允许范围内，再将坐标转换为浏览器实际像素位置。

如果客户端没有执行该动作，就不能向模型报告操作成功。只有真实执行后，才能把结果作为工具响应返回。

四、Python 实战：如何调用 Gemini Computer Use？

理解工作机制后，可以通过 Python 搭建一个简单的浏览器自动化 Agent。Google 官方示例使用 google-genai SDK 和 Playwright。前者负责调用 Gemini API，后者负责启动浏览器、执行鼠标键盘操作以及获取截图。

1. 配置开发环境

首先安装依赖：

pip install -U "google-genai>=2.7.0" playwright
playwright install chromium

配置 Gemini API Key：
Linux /macOS：

export GEMINI_API_KEY="your_api_key"

Windows PowerShell：

$env:GEMINI_API_KEY="your_api_key"

这里建议使用环境变量保存密钥，不要将 API Key 直接写入公开代码仓库。

2. 启动 Playwright 浏览器

创建一个 Python 文件：

from playwright.sync_api import sync_playwright
from google import genai
import os

SCREEN_WIDTH = 1440
SCREEN_HEIGHT = 900

client = genai.Client(
    api_key=os.environ["GEMINI_API_KEY"])

playwright = sync_playwright().start()
browser = playwright.chromium.launch(
    headless=False)
context = browser.new_context(
    viewport={
        "width": SCREEN_WIDTH,
        "height": SCREEN_HEIGHT
    })
page = context.new_page()
page.goto("https://www.google.com")
print("Browser initialized")

这里设置了 1440×900 的浏览器视口。需要注意，视口尺寸是客户端执行环境的配置，不需要额外作为 Computer Use 的屏幕尺寸参数发送给模型。模型返回的坐标采用归一化坐标，客户端负责转换成实际像素坐标。

3. 启用 Computer Use 工具

接下来初始化模型交互：

from google import genai
import os

client = genai.Client(
    api_key=os.environ["GEMINI_API_KEY"])

interaction = client.interactions.create(
    model="gemini-3.6-flash",
    input=(
        "请打开 Google 搜索页面，"
        "搜索 Gemini API Computer Use，"
        "并总结搜索结果中的主要信息。"
    ),
    tools=[
        {
            "type": "computer_use",
            "environment": "browser",
            "enable_prompt_injection_detection": True
        }
    ])
print(interaction)

这里使用的是当前官方文档推荐的 gemini-3.6-flash，而不是继续使用早期预览阶段的独立 Computer Use 模型。

表格

以上代码负责发送任务并获取模型响应，还没有真正执行浏览器点击。接下来需要开发客户端动作处理器。

4. 解析模型返回的动作

Gemini 3.x 的 Computer Use 响应中，动作通常以 function_call 形式出现在 interaction.steps 中。

坐标范围为 0—999，需要根据浏览器实际尺寸进行转换。

对应 Python 代码：

def denormalize_x(x, width):
    return int(x / 1000 * width)

def denormalize_y(y, height):
    return int(y / 1000 * height)

下面给出一个简化的浏览器动作执行器：

def execute_action(function_call, page):
    name = function_call.name
    args = function_call.arguments
    x = args.get("x")
    y = args.get("y")
    if name == "click":
        page.mouse.click(
            denormalize_x(x, SCREEN_WIDTH),
            denormalize_y(y, SCREEN_HEIGHT)
        )
    elif name == "type":
        page.keyboard.type(args["text"])
        if args.get("press_enter"):
            page.keyboard.press("Enter")
    elif name == "navigate":
        page.goto(args["url"])
    elif name == "scroll":
        page.mouse.move(
            denormalize_x(x, SCREEN_WIDTH),
            denormalize_y(y, SCREEN_HEIGHT)
        )
        page.mouse.wheel(
            0,
            args.get("magnitude_in_pixels", 300)
        )
    elif name == "go_back":
        page.go_back()

这只是一个用于理解执行逻辑的基础示例，并非完整的生产级执行器。实际开发还需要覆盖双击、拖动、快捷键、等待、截图等动作，并根据浏览器环境实现对应参数处理。

另外，不能无条件执行模型返回的所有动作。尤其是提交表单、发送消息和修改文件等操作，应当经过安全检查。

5. 如何实现 Agent 多轮自动执行？

单次调用只能获得模型当前给出的动作建议。真正的 Computer Use 应用，需要不断执行：模型决策 → 客户端执行 → 截图反馈 → 模型再次决策。

Google 官方示例通过 previous_interaction_id 延续同一交互，并将客户端执行结果作为下一轮输入。

MAX_TURNS = 10
for turn in range(MAX_TURNS):
    function_calls = [
        step
        for step in interaction.steps
        if step.type == "function_call"
    ]
    if not function_calls:
        print("Task completed")
        break
    results = []
    for call in function_calls:
        # 生产环境需要在这里执行安全审核
        execute_action(call, page)
        results.append({
            "type": "function_result",
            "name": call.name,
            "result": {
                "status": "executed"
            }
        })
    screenshot = page.screenshot(
        type="png"
    )
    # 根据官方 SDK 的工具响应格式，将执行结果和新截图组织为下一轮输入
    interaction = client.interactions.create(
        model="gemini-3.6-flash",
        previous_interaction_id=interaction.id,
        input=results,
        tools=[
            {
                "type": "computer_use",
                "environment": "browser",
                "enable_prompt_injection_detection": True
            }
        ]
    )

这段代码展示的是多轮控制的基本思路，不应直接作为完整可运行程序使用：正式实现必须按照 Google SDK 的 function_result 输入结构，关联对应的调用 ID，并将新截图作为图像输入一并提交。不能只返回一个 status=executed 就认为模型已经看到了新的页面状态。

另外，实际执行器还应处理：页面加载超时、浏览器意外关闭、动作执行失败、模型没有返回工具调用、达到最大执行轮数、模型动作与当前页面状态不匹配。

建议为每轮任务记录截图、动作，并记录每次操作的执行结果，方便定位失败环节。对于涉及登录、提交订单、删除数据等操作，还应增加人工审批机制，不能完全依赖模型自行判断。

五、Computer Use 的安全机制：为什么不能让 Agent 直接操作所有界面？

Computer Use 能够执行真实界面操作，也意味着它可能接触账号、个人资料、业务数据和具有实际后果的操作。因此，安全设计不是上线后的附加工作，而应该从开发阶段就纳入系统架构。

Google 官方 Computer Use 文档特别强调了提示词注入检测、安全确认和操作限制等问题。

1. 防范网页中的间接提示词注入

间接提示词注入（Indirect Prompt Injection）是 GUI Agent 面临的重要风险。例如，用户让 Agent 阅读一个网页，但网页正文内嵌指令，有可能诱导模型偏离原本任务。

开发者需要明确区分：用户授权的任务、系统级操作约束、网页和第三方内容、模型生成的动作建议。网页内容只能作为待分析的数据，不能自动获得更高的指令优先级。

2. 敏感操作必须增加人工确认

并不是所有动作都适合自动执行。

表格

特别是付款、删除、发布和账户权限修改等不可逆或高影响操作，不能只依靠模型生成的动作判断是否执行。

3. 使用沙箱隔离执行环境

建议为 Computer Use 单独准备浏览器配置文件或隔离运行环境。不要直接让 Agent 使用开发人员的日常浏览器会话。

可以采用以下措施：

• 使用独立测试账号；
• 限制浏览器可访问的域名；
• 隔离本地文件目录；
• 不向模型暴露不必要的凭证；
• 限制脚本和命令执行权限；
• 保存操作日志和截图；
• 对高风险动作设置人工审批。

这样即使模型出现误判，也能将影响控制在预先定义的环境中。

六、Computer Use 适合哪些实际业务？

Computer Use 并不是为了取代所有 API，而是解决部分软件没有开放合适接口、或者业务操作必须通过界面完成的问题。目前值得评估的应用方向主要有以下几类。

1. 自动化软件测试

传统 UI 自动化测试往往依赖固定选择器和预先编写的操作步骤。当页面布局变化时，测试脚本可能需要修改。Computer Use 可以让模型根据屏幕状态判断下一步操作，辅助完成表单填写、页面跳转、按钮状态检查、错误提示识别、多页面测试流程。

不过，对于要求高重复性和确定性的核心测试，Playwright 原生定位器和断言依然更适合作为主要执行方式。Computer Use 可以补充探索性测试和视觉检查。

2. 企业办公流程自动化

部分企业系统没有完整开放 API，或者不同部门使用的软件界面差异较大。GUI Agent 可以承担部分跨页面操作，例如从内部系统查询信息、整理页面中的业务数据、填写标准化表单、汇总多个页面的结果、生成操作记录。

对于涉及审批和财务的数据，应当保留人工审核节点。

3. 浏览器信息采集

在获得网站授权且遵守访问规则的前提下，可以让 Agent 执行打开指定网页、搜索公开资料、提取页面信息、整理表格、生成结构化报告。

不过，能够操作浏览器不等于可以绕过网站访问限制。登录权限、隐私要求、网站服务条款和数据使用规则仍然适用。

4. 跨软件知识工作

例如，一个办公 Agent 可能需要从浏览器读取资料，再将内容整理到文档或项目管理系统。这类任务的特点是跨多个界面，执行步骤不完全固定。Computer Use 可以负责界面操作，Function Calling 可以负责结构化数据查询和业务服务调用，两者组合更适合复杂工作流。

七、Computer Use API 正式 GA 后，开发者应该关注哪些成本？

Computer Use 的实际成本不能只看模型调用价格。一个完整任务可能需要多次截图、模型推理、动作执行和结果反馈。页面越复杂、截图越多、任务步骤越长，整体资源消耗也可能增加。

表格

需要注意，模型生成速度快，不一定代表完整任务耗时短。例如，页面加载可能需要数秒，第三方网站也可能出现响应延迟。对于多步骤任务，这些非模型因素同样会影响总执行时间。

开发者应分别记录模型响应耗时、浏览器执行耗时和任务总耗时，而不是只统计 API 响应时间。

八、多模型 Agent 的 API 接入与管理

当 Computer Use 被集成进更大的 Agent 系统后，应用可能同时使用不同模型完成不同工作。例如，Gemini 负责视觉理解和界面操作，DeepSeek 负责文本分析，Kimi 负责长文档处理。

这时，系统需要处理的不仅是模型调用，还包括不同 API 的鉴权、请求格式、上下文管理和异常处理。

对于同时使用国产模型的开发团队，可以将 KoalaAPI 作为多模型统一接入方案参考。它提供统一 Key、多供应商模型接入和 OpenAI SDK 兼容能力，适合需要集中管理不同模型调用的应用。

但需要明确，Computer Use 是 Google Gemini API 的专属工具能力之一。统一 API 网关并不意味着其他模型自动获得 Gemini 的屏幕识别和 UI 操作能力。具体模型功能仍然取决于对应厂商的接口支持情况。

实际架构中，可以将视觉操作模块和通用文本推理模块分开管理。这样既能避免把所有任务交给同一个模型，也能让模型切换和业务逻辑保持相对独立。

九、正式部署前的验证清单

Computer Use 进入 GA 后，开发者可以开始评估生产部署，但仍然需要建立完整的测试流程。

表格

建议先在测试网站和独立浏览器环境中完成验证，再逐步扩大应用范围。对于长期运行的 Agent，还应记录任务成功率、平均交互轮数、误操作率、人工介入次数和单次任务成本。这些指标能够帮助团队判断自动化是否真正带来了效率提升。

十、总结：Computer Use 的竞争重点正在转向执行可靠性

Gemini API Computer Use 正式 GA，意味着 Google 将 UI 操作能力进一步纳入正式 API 产品体系。从 Gemini 2.5 Computer Use 独立模型，到 Gemini 3.5 Flash 内置工具，再到 2026 年 10 月正式 GA，这一变化反映出 AI Agent 正从单纯的文本和工具调用，向更复杂的图形界面交互扩展。

对开发者来说，值得关注的并不只是模型能否点击按钮，而是能否在复杂环境下正确理解界面、持续维护任务状态，并在异常和风险出现时及时停止。

实际部署时，可以遵循三个原则：

能通过确定性 API 完成的任务，优先使用 API。

必须依赖图形界面的任务，再考虑 Computer Use。

涉及资金、账户、删除和外部发布等操作，保留人工审批。

对于企业团队，建议从软件测试、内部系统操作和低风险办公任务开始验证；独立开发者可以先搭建 Playwright 测试环境，熟悉截图、动作和反馈循环；个人开发者则可以从简单的网页自动化任务入手。

Computer Use 的正式开放并不意味着所有软件操作都可以完全交给 Agent。真正可持续的自动化系统，仍然需要模型能力、执行环境、权限控制和异常恢复共同配合。