17. Computer Use / 浏览器 Agent 的核心挑战是什么？

简单回答

Computer Use（如 Anthropic Computer Use、OpenAI Operator）是让 LLM 直接操作图形界面——看屏幕截图、决定鼠标点哪里、键盘输什么——以此完成跨应用的任意任务。它的吸引力是"零集成"：不需要每个应用都写 API 适配，理论上人能做的 GUI 操作 Agent 都能做。但工程上极难——视觉定位精度有限、动作延迟高、错误恢复困难、不可见状态多。目前在结构化网页上能用，跨复杂软件还远未到生产级别。

详细解释

为什么会出现 Computer Use 这条路线

正常的 Tool Calling 路线（见本专题第 03 篇文章）依赖每个外部能力暴露 API。但现实中很多任务不存在 API——内部老系统、桌面软件、需要登录的网页、PDF 表单等。这些场景下 Agent 想做事就只能"像人一样"通过 GUI 操作。

Computer Use 把 GUI 当成统一接口：屏幕截图作为观察，鼠标键盘动作作为输出。优势是泛化能力强，原则上能覆盖任何用户能完成的任务。代价是把所有"接口标准化"的工作都压到了模型身上。

工作流程

以 Anthropic Computer Use 为例，一个典型的循环是：

截屏作为 observation——把当前桌面或浏览器画面截图，编码成图像 token 喂给 VLM（视觉语言模型）。

模型决定动作——输出一个结构化的 action，比如 click(x=320, y=440)、type("hello")、scroll(down)、key("Ctrl+T") 等。这本质上是一种特殊形式的 Tool Calling，工具就是"鼠标和键盘"。

执行动作——后端的控制层（一个浏览器自动化框架或操作系统级的输入注入工具）真的去点这个坐标、敲这些键。

再截图、再决策——形成 ReAct 风格的循环，直到任务完成或失败。

浏览器 Agent（比如 Browser-Use、Playwright + LLM）是 Computer Use 的一个子集，把范围限定在网页上。它的好处是可以拿到 DOM 结构作为辅助观察——除了截图外还能给模型一棵简化的 accessibility tree，定位精度比纯视觉高得多。

核心挑战 1：视觉定位精度

模型要精确说出"点击坐标 (x, y)"——这件事对 VLM 来说非常困难。日常的 VLM 训练目标是"描述图片"，不是"在图片上找精确像素位置"。一个按钮的实际可点击区域可能只有几十像素宽，模型偏几个像素就点空了。

业界的缓解手段有几种。一是用专门的"GUI grounding"模型（如 SeeClick、CogAgent）替代通用 VLM，在 UI 元素定位数据上专门训练过。二是给画面加视觉标注——把可交互元素用框圈出来、编号，让模型只输出"点击元素 7"而不是输出坐标，这叫 set-of-mark prompting。三是在浏览器场景下直接用 DOM 信息绕开视觉定位问题。

核心挑战 2：每步延迟和成本都很高

每一步循环都要做一次截图编码（图像 token 量大）、一次 VLM 推理（视觉模型本来就慢）、一次实际 GUI 操作（鼠标移动、页面渲染需要时间）。一个任务往往要十几到几十步，整个流程可能要几分钟到十几分钟才能完成一个人类几十秒就能做完的事。

成本上每一帧截图轻松就是几千到上万 token。如果每步都把历史所有截图都带在上下文里，token 消耗会爆炸。实际系统通常会做截图压缩、只保留最近几帧、或者用文字摘要替代旧截图。

核心挑战 3：错误难恢复

GUI 操作的副作用很多。点错了按钮可能弹一个对话框、跳到一个完全不相关的页面、甚至触发不可逆的操作（删除、提交、付款）。Agent 需要从新画面识别"我是不是搞砸了、当前在哪、怎么回去"——这件事在视觉上比在 API 上难得多。

而且 GUI 状态有大量不可见信息：模态对话框遮挡、隐藏菜单、焦点在哪个输入框、页面是否还在加载。模型只看一帧静态截图很难判断这些。

工程上常见的兜底是引入硬性约束——遇到带"删除"、"支付"等关键词的按钮强制需要用户确认，类似本专题第 10 篇文章里讲的高风险操作授权。再就是设置严格的最大步数和动作白名单。

核心挑战 4：评测和可靠性

Computer Use 类 Agent 的评测本身就是难题。WebArena、OSWorld 这类 benchmark 提供了一些标准化任务，但真实环境千变万化——同一个网站不同时间界面可能就改了，A/B 测试可能给不同用户看不同布局。Anthropic 自己公布的数字是 Claude 在 OSWorld 上成功率约 22%（2024 年）——这意味着 4 次里有 3 次会失败。这个数字距离生产级可用还差很远。

浏览器 Agent 是更现实的中间态

纯 Computer Use 太难，所以很多团队走"浏览器 Agent"这条更窄但更实用的路线。浏览器场景下可以拿到 DOM、可以用 CSS 选择器精确定位元素、可以拦截网络请求、可以无头运行——可控性比操作系统级 GUI 高几个量级。

Browser-Use、Playwright Agent、AutoGPT 这类项目本质上是给 LLM 装了一套结构化的"网页操作 API"——click(selector)、fill(selector, text)、extract(selector)，让模型不必直接面对像素。这其实退回到了 Tool Calling 路线，只是工具是"网页操作原语"。这个折中目前在生产环境（爬数据、自动填表、客户旅程模拟）已经能用。

面试时可以这样答

Computer Use 是让 LLM 通过看屏幕截图、输出鼠标键盘动作来操作 GUI。动机是绕过"必须有 API 才能集成"的限制——人能做的 GUI 操作 Agent 都能做。代价是几乎所有难题都被压到了模型身上。

核心挑战有几块。第一是视觉定位精度——VLM 输出一个精确的点击坐标本来就很难，业界的缓解手段是用 GUI 专用模型，或者把可交互元素加视觉标注让模型选编号，或者在浏览器里直接用 DOM 绕过视觉定位。第二是每步的延迟和成本——截图 token 量很大，每步都要 VLM 推理，一个任务下来要几分钟，token 消耗也很高。第三是错误难恢复——点错了按钮的副作用比 API 调错难处理得多，模态对话框、隐藏菜单这些不可见状态识别不准。第四是可靠性远未到生产级——Claude 在 OSWorld 上成功率才 22% 左右。

实际工程里更常见的是浏览器 Agent 这种中间态——把范围限定在网页，借 DOM 提供结构化定位，模型操作的是 click(selector) 这种结构化 API 而不是像素坐标。这本质上又回到了 Tool Calling 路线，只是工具变成"网页操作原语"。这种折中目前已经能在爬数据、自动填表、流程自动化场景里实用了。

常见追问

1. Set-of-mark prompting 具体怎么实现？标注的元素 ID 怎么编、怎么传给模型？
2. 浏览器 Agent 用 DOM 选择器和用视觉定位各自的失败模式有什么不同？
3. 怎么给 Computer Use 类 Agent 加权限边界，避免它点到不该点的按钮？