跳到主要内容

Browser and Computer Use Agents

当 AI Agent 开始离开纯文本环境，直接进入网页、桌面应用和图形界面时，系统会进入一类明显不同的工程问题。

这类问题不再只是：

  • 要不要调用工具
  • 该怎么维护状态
  • 什么时候该停止

而会进一步变成：

  • 该不该把浏览器当成执行环境
  • 该不该让系统直接操作图形界面
  • 哪些动作可以自动执行，哪些动作必须拦住
  • 当页面结构、视觉状态和环境噪声一起变化时，系统怎么保持稳定

这篇文档主要讨论两类系统：

  • Browser Agent
  • Computer Use Agent

重点包括：

  • 它们分别是什么
  • 它们和普通 Tool Use 的关系
  • 适用场景在哪里
  • 风险边界在哪里
  • 工程上该怎么设计

1. 两个概念先分开​

1.1 Browser Agent​

Browser Agent 指的是：

Agent 通过浏览器环境完成任务，例如打开网页、读取页面内容、填写表单、点击元素、提交请求、在多页面之间跳转。

它通常面对的是：

  • 网站
  • Web 应用
  • 登录流程
  • 在线后台
  • 搜索结果页
  • 表单与列表页

从执行方式看，Browser Agent 一般有两种实现路径：

  • 基于 DOM、可访问性树或页面结构操作
  • 基于视觉观察再配合点击、输入、滚动等动作操作

1.2 Computer Use Agent​

Computer Use Agent 指的是：

Agent 直接面对图形界面，在更一般的操作系统环境里观察屏幕并执行操作。

它操作的不只是浏览器，也可能包括：

  • 桌面应用
  • 文件管理器
  • 系统弹窗
  • 设置面板
  • 多窗口界面
  • 混合型工作台

它通常要处理：

  • 鼠标移动
  • 点击
  • 输入
  • 快捷键
  • 窗口切换
  • 屏幕区域识别

1.3 两者的关系​

两者有交集，但不是同一件事。

  • Browser Agent 的作用域通常限定在 Web 环境
  • Computer Use Agent 的作用域更大，浏览器只是其中一种界面

可以把它们理解成：

  • Browser Agent：面向网页和 Web 工作流的界面代理
  • Computer Use Agent：面向整个图形操作环境的界面代理

2. 它们和 Tool Use 的关系​

这一点最好单独分清。

2.1 Tool Use 解决什么​

Tool Use 解决的是：

  • 模型如何调用外部能力
  • 工具的输入输出怎样结构化
  • 系统如何以稳定接口访问外部世界

典型形式包括：

  • 调 API
  • 查数据库
  • 调搜索接口
  • 执行代码
  • 调内部服务

这类能力的共同点是：

接口清晰，输入结构明确，返回结果通常可解析。

2.2 Browser / Computer Use 解决什么​

Browser Agent 和 Computer Use Agent 解决的是另一类问题：

  • 没有现成 API
  • 有 API 但权限或接入成本很高
  • 任务天然发生在图形界面中
  • 页面结构和系统界面本身就是工作对象

它们本质上仍然属于“工具能力”的扩展，但和普通 Tool Use 相比，抽象层更高，不确定性也更强。

普通工具调用通常是：

明确调用 -> 结构化返回

Browser / Computer Use 更常见的是：

观察界面 -> 判断下一步 -> 执行动作 -> 再观察界面

所以它们更接近：

感知 + 决策 + 动作 的闭环

2.3 一个实用判断​

如果一个任务可以稳定地改写成：

  • 调一个内部 API
  • 查一条数据库记录
  • 用结构化参数调用外部服务

那通常优先选择普通 Tool Use，而不是直接上浏览器或桌面代理。

原因很简单：

  • 更稳
  • 更快
  • 更便宜
  • 更容易观测
  • 更容易回归测试

界面代理更适合放在这些场景：

  • 只有界面，没有接口
  • 接口不可得，但业务流程必须走界面
  • 任务本身就在“读界面、改界面、穿过多步界面流程”

3. 什么时候适合用 Browser Agent​

Browser Agent 更适合下面几类任务。

3.1 面向网站的只读研究任务​

例如：

  • 打开官网
  • 搜索某个产品页面
  • 读取文档页
  • 在控制台后台里查看状态
  • 按页面结构采集公开信息

这类任务通常以：

  • 搜索
  • 浏览
  • 抽取
  • 比对

为主，风险相对可控。

3.2 多步网页流程​

例如：

  • 登录后台
  • 切换租户
  • 打开某个页面
  • 读取状态
  • 导出结果

它的重点不是“某一个动作”，而是：

整条网页工作流需要跨多个页面完成。

3.3 表单驱动型任务​

例如：

  • 填写工单
  • 提交申请
  • 更新后台配置草稿
  • 创建某种记录但先停在确认页

这类场景常常适合做成：

  • 前面自动填
  • 最后人工确认

4. 什么时候适合用 Computer Use Agent​

Computer Use Agent 更适合下面几类任务。

4.1 浏览器以外的桌面流程​

例如：

  • 同时操作本地文件和网页
  • 在桌面应用里读取信息
  • 在多窗口之间搬运内容
  • 处理带系统弹窗的流程

4.2 环境高度依赖图形界面​

例如：

  • 只有图形界面，没有脚本接口
  • 页面结构不稳定，但界面模式相对固定
  • 任务高度依赖视觉确认

4.3 临时性自动化和人机协同流程​

例如：

  • 操作一套很少使用的内部工具
  • 处理低频但步骤繁琐的后台任务
  • 由系统执行前半程，人负责最终确认

这类流程不一定值得单独建设 API 集成，但又确实需要自动化支持。

5. 哪些场景不适合​

这部分比“适合什么”更重要。

5.1 高价值写操作​

例如：

  • 直接转账
  • 直接删数据
  • 直接发正式通知
  • 直接改生产配置

如果必须走界面，通常也应当加入：

  • 多重确认
  • 权限隔离
  • 人工审批
  • 操作回放

5.2 高吞吐、强稳定、强一致任务​

例如：

  • 每秒大批量处理
  • 精确数据同步
  • 大规模重复任务
  • 严格 SLA 的后台作业

这类任务更适合：

  • API
  • Workflow
  • 批处理系统

而不是图形界面代理。

5.3 页面变化频繁、选择器不稳定、流程常改的环境​

如果一个系统界面本身变化很快，Browser Agent 的维护成本会持续上升。

这时更适合先判断：

  • 是否能拿到内部接口
  • 是否能和业务系统协商更稳定的集成方式

6. Browser Agent 和 Computer Use 的主要风险​

这类系统的风险和普通 Tool Use 不完全一样。

6.1 感知误差​

系统可能：

  • 读错页面
  • 误认按钮
  • 没看见弹窗
  • 没理解界面当前状态

这种问题在视觉驱动路径里尤其常见。

6.2 动作误触发​

例如：

  • 点错按钮
  • 在错误页面提交
  • 把临时草稿当成正式提交
  • 切错窗口后继续执行

6.3 环境漂移​

例如：

  • 页面改版
  • 元素位置变化
  • 登录态失效
  • 网络卡顿导致状态不同步

图形界面代理比结构化 API 更容易受环境漂移影响。

6.4 权限与数据泄露​

一旦系统具备界面访问能力，它往往也能接触到：

  • 账号会话
  • 内部后台
  • 敏感页面
  • 文件内容

如果权限隔离做得不好，风险会比普通只读工具更高。

6.5 成本与时延​

界面代理往往更慢：

  • 要加载页面
  • 要等待渲染
  • 要观察当前界面
  • 要逐步执行动作

可以直接看到：

  • 成本更高
  • 时延更长
  • 回归测试更重

7. 工程上怎么做边界设计​

这类系统最忌讳“先让它自己点着试试看”。

更稳的做法通常包括下面几层。

7.1 任务分层​

先分清哪些步骤属于：

  • 只读观察
  • 低风险填写
  • 高风险提交

把高风险动作尽量压缩到最少节点。

7.2 显式状态机​

哪怕底层用了 agent loop，外层也最好有显式状态：

  • 已登录
  • 已定位目标页面
  • 已读到关键字段
  • 已填写草稿
  • 等待确认
  • 已提交

这样更容易做：

  • 回放
  • 中断恢复
  • 错误定位

7.3 动作白名单​

不要让系统默认拥有完整操作空间。

更合适的是把动作限制成有限集合，例如：

  • 打开 URL
  • 点击允许区域内的元素
  • 读取指定区域文本
  • 在指定字段输入
  • 截图
  • 滚动

7.4 提交前确认​

高风险动作通常至少要有一层：

  • 人工确认
  • 二次校验
  • 明确的“预览态”

尤其是这些动作：

  • 发送
  • 删除
  • 覆盖
  • 正式提交

8. Browser Agent 和 Workflow 的关系​

很多浏览器流程看起来像 agent，其实不一定需要完全开放式执行。

更稳的做法通常是：

  • 外层用 Workflow
  • 关键节点再调用 Agent

例如：

  1. Workflow 负责打开指定站点
  2. Workflow 负责检查登录态
  3. Agent 负责在复杂页面里定位目标信息
  4. Workflow 负责把结果写回固定结构
  5. 高风险动作进入人工确认

这种设计的好处是：

  • 可控边界更清楚
  • 调试更容易
  • 回归测试更稳定

9. Browser / Computer Use 和 Evals​

这类系统不能只看最终有没有“做成”。

至少还要评估：

  • 是否读对界面
  • 是否走了正确路径
  • 是否在错误状态下及时停住
  • 是否把高风险动作留在确认节点
  • 页面变动后退化程度怎样

可以记录的最小评估项包括：

  • 任务成功率
  • 平均步数
  • 平均耗时
  • 高风险动作触发率
  • 误点击率
  • 人工接管率
  • 页面改版后的回归结果

10. 和 Observability 的关系​

对这类系统来说，观测信息比普通工具调用更重要。

最好至少保留：

  • 每一步截图
  • 当前页面 URL 或窗口上下文
  • 动作类型
  • 动作目标
  • 执行前后状态
  • 停止原因

如果不保留这些信息，很多失败只能看到“任务没做成”，但不知道失败发生在哪一步。

11. 一个稳妥的落地顺序​

如果要落这类能力，顺序通常可以是：

  1. 先把任务拆成 只读 和 写入 两类
  2. 先做只读浏览器任务
  3. 再做低风险填写型任务
  4. 高风险动作默认保持人工确认
  5. 在稳定之前，不要急着扩到完全开放的 computer use

这个顺序的核心是：

先拿到可观测、可回放、可中断的最小闭环，再考虑更强的自动化。

12. 一组很实用的判断标准​

判断一个任务是否适合交给 Browser Agent 或 Computer Use Agent，可以先问下面几个问题：

  • 有没有稳定 API 可以替代
  • 任务主要发生在网页还是整个桌面环境
  • 动作是只读、低风险写入，还是高风险提交
  • 页面和流程改动频率高不高
  • 一旦误操作，成本有多大
  • 是否需要人工确认节点
  • 是否能够记录足够细的轨迹和截图

如果这些问题里有几项答不上来，通常先不要急着把任务交给界面代理。

13. 小结​

Browser Agent 和 Computer Use Agent 不是普通 Tool Use 的简单放大版。

它们引入了更强的环境依赖、更高的动作风险和更重的观测要求。

在工程上，更稳的做法通常是：

  • 优先选择结构化接口
  • 把界面代理放在 API 不可得或任务天然发生在界面的场景
  • 用 workflow 包住高不确定性步骤
  • 给高风险动作加确认、回放和中断机制

只有这样，这类系统才更可能从“能演示”走到“可上线”。