Agent 操作电脑的三条路径：Computer Use、Browser Use 与 MCP 选型指南

Agent 操作电脑常被简化为“模型会不会点按钮”，但实际链路是：观察当前页面、判断下一步、让工具执行点击或输入、接收新状态、核验结果，再决定下一步。ReAct 论文讨论的“推理与行动交替”可作为理解这一循环的研究范式，但它不是商业产品的统一内部标准。真正决定任务成败的，往往是每一环拿到的数据是否足够、执行环境是否一致、动作后有没有验证。

来源说明：本文涉及的产品能力描述主要来自社区文章转述及文中引用的官方文档链接。由于当前可用证据等级为社区信号，以下对具体产品行为的描述均标注为“据社区文章转述/官方文档链接显示”，建议读者以对应官方文档为准。

三条路径回答的是不同问题

Computer Use、Browser Use、MCP 经常被并列成三种竞争技术，其实它们回答的问题不同：Computer Use 解决“Agent 如何通过屏幕和键鼠操作电脑”；Browser Use 解决“Agent 如何在网页或浏览器环境中观察和操作”；MCP 解决“Agent 如何连接外部工具和数据源”。前两者描述操作环境与交互方式，MCP 描述工具接入方式。一个 MCP Server 可以连接浏览器并提供网页结构或截图，具体返回什么取决于该 Server 实现了哪些能力。

从 Agent 实际收到的数据看，差异更清楚：

Computer Use：截图—动作—重新截图的循环

据社区文章转述，Google 的 Computer Use 文档描述了“发送截图、返回界面动作、执行后重新截图”的循环（原文链接：https://ai.google.dev/gemini-api/docs/computer-use）。这种方式的通用性来自像素：网页、桌面应用、设置弹窗都能看。但模型看到的只是图像，不一定知道某区域在程序里是按钮、广告还是装饰图，还需要把视觉位置换算成点击坐标。窗口缩放、分辨率变化或页面滚动都会让坐标失准。公开的 Codex 问题记录中，有用户报告应用内浏览器截图区域与实际坐标不一致；这只是一条具体报告，不代表所有实现都会遇到，但说明像素坐标与执行环境的对应关系是必须处理的工程问题。

Browser Use：用结构信息替代坐标估算

浏览器能提供比截图更结构化的信息，例如“搜索框”“按钮：搜索”“链接：产品文档”。一些工具把这些元素连同引用编号交给模型，模型可以说“点击搜索按钮”，而不必从截图估坐标。据社区文章转述，Playwright MCP 默认用可访问性快照描述网页元素，并支持通过元素引用交互（原文链接：https://playwright.dev/mcp/snapshots）。

但结构信息也有边界：某些内容没有可用的可访问性信息，画布绘制的界面、视频、特殊嵌入内容可能需要退回截图；页面导航或更新后，之前的元素引用可能失效，需要重新获取快照。据社区文章转述，Playwright 文档也建议页面变化后重新获取快照。因此截图与结构并非互相取代，很多实现会在结构足够时优先元素定位，需要判断视觉布局时再看截图。

MCP：能力边界由 Server 定义

MCP 是工具连接协议，不是“DOM 模式”也不是“截图模式”。以查订单为例：浏览器路径是读取页面、找到订单、打开详情、抄录状态和金额；业务工具路径是调用订单查询工具，直接得到结构化记录。后者更直接，但只能做 Server 明确提供的操作——没有“取消订单”工具，Agent 也不能凭空获得该能力。比较 MCP 时不能只问“它比 Computer Use 好不好”，而要问：连接的是什么服务、工具返回哪些字段、Agent 能执行哪些动作、使用什么权限。

登录状态为什么不同步

“我本机 Chrome 已登录，Agent 却看到未登录”是常见困惑。原因通常不是 Agent 不会看登录状态，而是它操作的浏览器和你登录的浏览器不是同一个环境。云端虚拟浏览器有独立 Cookie 和会话；桌面应用内置浏览器可能有自己的配置；浏览器扩展则可能连接本机当前 Chrome 配置。据社区文章转述，ChatGPT 桌面端说明指出，内置浏览器和普通浏览器配置相互独立，需要使用现有 Chrome 会话时应通过扩展连接（原文链接：https://learn.chatgpt.com/docs/browser）。使用外部 Browser MCP 时也要检查它启动的是全新浏览器、持久化配置，还是连接现有浏览器；据社区文章转述，Playwright MCP 提供不同配置方式，持久化状态可保留登录信息，但这是具体 Server 的能力，不是 MCP 协议自动带来的特性（原文链接：https://playwright.dev/mcp/configuration/user-profile）。

排查顺序应是：Agent 操作的是内置、云端还是本机浏览器；当前标签页和账号是否正确；该环境是否保留登录会话；浏览器工具是否有读取和操作该网站的权限。只检查“我电脑上的 Chrome 已登录”不够。

选型决策树

按任务特征选型比按产品名气更可靠。以下决策树可作为工程起点：

任务是否需要操作桌面软件/设置窗口/无网页接口的应用？
├─ 是 → Computer Use（截图+坐标）
└─ 否 → 任务是否在网页内查找和操作控件？
    ├─ 是 → 系统是否提供可靠 API 或 MCP 工具？
    │   ├─ 是 → 优先 MCP 结构化接口；否则 Browser Use（DOM/可访问性树）
    │   └─ 否 → Browser Use
    └─ 否 → 读取或修改业务记录？
        ├─ 是 → 若系统提供可靠 API 或 MCP 工具，优先结构化接口
        └─ 否 → 需要已有登录状态？
            ├─ 是 → 先确认连接的是本机浏览器还是独立环境，再判断是否需要扩展或持久化会话
            └─ 否 → 按上述能力边界选择

工程上三者可以组合：MCP 作为工具总线，统一接入业务 API 和浏览器工具；Browser Use 作为网页执行器，优先用可访问性树定位元素；Computer Use 作为兜底通道，处理画布、特殊嵌入或桌面应用。这种分层是工程建议，不是官方规定，但符合各自能力边界。

最小可运行示例：MCP 工具调用骨架

以下示例展示一个最小 MCP 客户端如何连接 Server 并调用工具。代码为工程示意，不依赖特定产品实现。

# 最小 MCP 客户端骨架（示意）
import asyncio
from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client

async def main():
    # 启动一个 MCP Server 子进程（以 stdio 传输为例）
    server_params = StdioServerParameters(
        command="python",
        args=["my_mcp_server.py"],
    )
    async with stdio_client(server_params) as (read, write):
        async with ClientSession(read, write) as session:
            await session.initialize()
            # 列出可用工具
            tools = await session.list_tools()
            print("可用工具:", [t.name for t in tools.tools])
            # 调用一个查询订单的工具
            result = await session.call_tool(
                "query_order",
                arguments={"order_id": "12345"},
            )
            print("订单结果:", result.content)

asyncio.run(main())

要点：MCP 只负责连接和调用，返回什么字段、能执行什么动作，完全由 Server 实现决定。若 Server 未提供 cancel_order 工具，Agent 无法通过 MCP 取消订单。

故障排查清单

任务描述与安全边界

无论用哪种方式，任务描述都应包含目标、边界和完成标准。例如：“找到编号 12345 的订单，核对商品名称和金额。不要提交、取消或付款。找到后把页面显示的状态和金额告诉我，等我确认后再继续。”对付款、发送消息、删除内容等有后果的动作保留人工确认；长任务拆成可检查阶段；完成后要求 Agent 说明页面上看到的依据。这些做法不能保证不出错，但能缩短错误被发现的距离。

理解 Agent 操作电脑，关键是把链路拆开：观察数据从哪里来、工具怎样连接、动作在哪里执行、结果如何验证。看懂这条链路，“AI 为什么有时灵有时笨”就不再是模型玄学，而是可以逐环检查的工程问题。