Computer Use与Browser Use：Agent如何操作电脑和浏览器

1. 从RPA说起

从网站下载报表，打开Excel整理，再把结果填进另一个系统。这样的活儿，单看每一步都不难，但天天都要找入口、切窗口、复制粘贴，多少有点烦人。

这种重复的人肉操作，早就有人想让软件代劳了。RPA，中文叫“机器人流程自动化”，说白了就是把这些操作编成流程，让程序照着做。填写表单、读取文件、按条件选择下一步，甚至出错后重试，都可以安排进去。RPA工作流介绍

不过，流程得有人设计。文件没找到怎么办，搜出了几个同名结果怎么办，突然弹出一个提示框怎么办，都需要提前考虑。步骤明确、规则稳定的工作，很适合这么处理；遇到没考虑过的情况，就可能需要补规则、改流程。

大模型给这件事带来了一个新思路：能不能让它一边看界面，一边决定下一步？比如找一份会议纪要，先按名称搜索，发现有好几个版本，再根据日期和内容挑出需要的那份。下面干活的还是搜索、点击、输入这些工具，部分判断则交给模型临场完成。

这类围绕目标调用工具、根据结果继续做事的系统，通常叫Agent，也就是智能体。像Codex这样的Agent，已经把操作电脑和浏览器做成了可用的功能。用户说想做什么，它再尝试把中间的操作串起来。

具体到操作软件，经常会看到两个名字：

• Computer Use：让Agent使用电脑上的软件，后面用Word另存为PDF来讲。
• Browser Use：让Agent操作浏览器，后面用网盘里查找文件来讲。

浏览器也是软件，所以两者有交集。分开讲，是因为浏览器还提供了专门操作网页的办法。接下来就把这些能力拆开看看：模型怎样知道界面上有什么，又是谁把它的判断变成了真正的点击？

2. 先看整体：模型与执行层怎样配合

2.1 架构：模型说要做什么，执行层负责动手

模型可以判断“下一步应该点击保存”，但要让Word真的响应，还得有程序把这件事做出来。一个负责拿主意，一个负责动手，先把这两件事分开。

负责读取界面、执行点击和输入的程序，本文叫它执行器。这些实际操作的能力放在一起，就是后面说的执行层。模型根据它返回的信息决定下一步，再把新的操作请求交给它。

模型通过工具发出请求，执行器通过系统或浏览器接口接触软件。这里的“接口”，可以理解成软件留给其他程序的操作入口。先看它们的关系：

整体关系。箭头表示谁调用谁，结果沿原路返回。

有了执行器，还得让模型知道怎么用它。比如截图用哪个命令，点击时要传位置还是控件名称，执行完会返回什么。这些内容可以写进Skill，相当于给模型准备一份工具说明书。

真正发出操作时，可以通过CLI，也就是命令行工具。模型按照说明组织命令，CLI把命令交给执行程序，再把结果带回来。这就是“Skill配合CLI”这套接法里，各自负责的事情。

执行程序也不必从头写。现成的自动化代码组件，也就是“库”，已经能完成不少截图、点击和输入工作，接过来调用就可以了。如果还要持续接收命令、保持与应用的连接，也可以让一个后台控制服务一直运行。后面介绍具体工具时，会看到这些能力怎样组合起来。

2.2 流程：看一眼，操作一下，再看一眼

以打开Word的另存为窗口为例：

1. 读取界面。执行器把当前画面或控件信息交给模型。
2. 判断并操作。模型找到“另存为”入口，要求工具点击。
3. 读取结果。保存窗口出现了，就继续填写文件名；出现了其他提示，就先处理提示。

这样，模型不用一开始就猜出后面所有步骤。它先做当前有把握的操作，拿到新结果以后再继续。如果填写文件名和点击保存都已经明确，也可以一起执行，不必每敲一个字都重新推理。

不过，工具报告“点击成功”，只说明按钮操作执行了。我们的目标是得到一份PDF，所以还得确认文件有没有生成、内容对不对。这个检查也属于任务的一部分。

2.3 连续操作时，怎么知道还在操作哪个窗口

上一轮打开了Word的保存窗口，下一轮说“点击保存”，工具怎么知道该点哪个窗口？

这里可以有两种做法：

做法	连续两次操作的示意	特点
每次明确带上目标	“读取7号窗口” → “点击7号窗口里的保存按钮”	每次请求都说清楚对象，切换多个目标时比较直观
执行器记住当前目标	先选中7号窗口，后面继续调用“读取窗口”“点击保存”	请求可以省略已选过的目标，由执行器补上

第二种做法，就是把“当前正在操作哪个窗口”记在中间程序里。模型后面再说“点击保存”，执行器就到这次任务选中的窗口里去找。保存下来的这些信息，叫会话状态，也就是Session。

浏览器里也是一样：每个打开的页面对应一个标签页，执行器可以记住当前选中了哪个。后续请求看起来变短了，是因为一部分信息已经由中间层保存，不需要模型每次重新带上。

不过，记住目标不等于知道最新画面。用户关掉窗口，或者网页发生跳转，旧的信息就可能失效，仍然要重新读取。会话与应用自身状态的区别，附录里再展开。

3. Computer Use：桌面操作是怎么实现的

3.1 架构：借用操作系统已有的能力

继续用Word另存为PDF的例子。人通常会打开另存为窗口，选择PDF格式，检查文件名和保存位置，再点击保存。Agent需要完成的也是这些步骤。

要让程序完成这些操作，就得往下看操作系统提供了什么。系统能获取窗口画面，也能提供按钮、输入框等界面组件的信息，还允许程序模拟键盘和鼠标。我们把按钮、输入框这些组件统称为控件，执行器通过系统接口读取和操作它们。

桌面架构。三条连接对应不同的系统能力，执行器可以按需要选用。

截图很好理解：把窗口画面取出来，交给能看图的模型，判断文件名填在哪里、保存按钮在哪里。图中左边的可访问性接口，则提供了另一种“看法”。

3.2 可访问性：把界面里的控件告诉模型

除了画面，程序还可以直接告诉我们：“这里有一个输入框，名称是文件名，内容是会议纪要.pdf；旁边有一个保存按钮，现在可以点击。”操作系统自带的可访问性接口（Accessibility），就能提供这类信息。

它原本用于帮助屏幕阅读器等辅助软件理解界面。即使用户看不见画面，辅助软件也得知道有哪些控件、叫什么名字、现在是什么状态。应用把这些信息提供给系统，其他程序再通过接口读取。

窗口里有面板，面板里有输入框和按钮，这些信息组织起来就形成了可访问性树。自动化程序同样可以利用它。Chromium可访问性说明

同一个保存窗口的两种看法。界面经过简化，假设已经选择了PDF格式。

有了这份信息，工具就能直接告诉模型“保存按钮现在可用”，不用再从截图里猜它是不是灰色。控件的名称、值和状态由应用提供，整理成文字清单就可以交给模型。

因此，只处理文字的大语言模型（LLM）也能利用这份清单判断下一步。要直接看截图，才需要模型具备视觉能力，或者借助其他图像处理工具。这也是可访问性信息很适合被Agent复用的原因。

两种看法各有长处：

观察方式	擅长什么	主要限制
可访问性信息	找按钮、读输入框，判断是否选中、能否操作	依赖应用提供的信息；应用自行绘制的画布、图表等可能描述不全
截图	看实际布局、图标、颜色和图表	需要识别图像和位置；小字、遮挡、缩放都可能影响判断

回到Word保存窗口，我们主要关心文件名填了什么、保存按钮能不能点。对这类标准表单，先读控件信息、不够再补截图，是一个实用的选择，可以省去从图片里辨认控件的工作。

但如果任务换成“看看这页排版有没有问题”，按钮名称就帮不上多少忙了，直接看图更合适。所以，选择哪种观察方式，还是得看任务需要什么；也有实现会从一开始就以视觉为主。

文字也不一定更省。把一大棵控件树原样塞给模型，同样会增加输入量和等待时间。效率要看返回了多少信息、误判后要重试几次，不能只按文字和图片来判断。

3.3 执行动作：先从模拟鼠标说起

现在模型已经知道保存按钮在哪里，最直观的实现就是：把鼠标移过去，按下左键，再松开。

程序可以调用系统输入接口，模拟这几个动作。对输入框也是类似的过程：先点击让它接收输入，再模拟按键。我们平时手工做的动作，就这样被拆成了一组程序调用。

有了可访问性接口，还可能走另一条路：如果应用支持，程序可以直接触发保存按钮的功能，不必先移动鼠标指针。

两种执行方式。右侧需要控件支持相应动作。

怎么找到按钮，和怎么点击按钮，是两件事。 从可访问性信息找到按钮后，仍然可以根据它的位置模拟点击；根据截图找到位置，也可以把模拟的操作直接交给目标应用，不一定要移动你正在使用的鼠标指针。

有些产品还会额外显示一个鼠标指针，用移动动画标出正在操作的位置，Codex就是一个例子。你看到的动画和真正的点击可以分别处理，具体做法放在附录说明。

3.4 其他Agent能不能用开源工具实现

Codex把这些能力做进了产品。换成Claude Code、pi等Agent，也可以接上开源自动化工具，搭出自己的Computer Use方案。

例如，PyAutoGUI能截图、移动鼠标、点击和输入。我们可以写一个小脚本，把这些操作做成命令，再用Skill说明怎么调用。

以Claude Code为例，组件可以这样连接：

Claude Code接上PyAutoGUI的一种方案，需要自行编写连接脚本。

实际执行时，按下面的顺序配合：

1. Claude Code运行截图命令，读取生成的图片。
2. 模型看图判断目标位置，调用点击命令。
3. 重新截图，确认界面变化，再决定下一步。

走完这一轮就能看到，模型负责判断位置和下一步，脚本负责把请求交给PyAutoGUI，再把截图带回来。前面讲的分工，用这几个现成组件就能接起来。Claude Code的Skill机制、工具能力说明

PyAutoGUI负责的是截图和键鼠操作，不会自己理解“把文档另存为PDF”，也不提供通用的可访问性树读取能力。如果希望读取系统控件，Windows上还可以使用pywinauto等工具。

基础能力可以这样组合，但系统是否允许控制、中文怎样输入、操作会不会打断用户，还需要连接这些工具的代码来处理。能点起来，与用起来顺手，中间还有不少工作。

4. Browser Use：浏览器里还有更直接的办法

4.1 架构：直接和浏览器打交道

桌面工具能操作Word，当然也能把Chrome当作普通应用，截图、找位置、点击。照着这条路走，网页里的很多事情也能做。

不过，浏览器还维护着网页的内部结构，知道哪些元素是输入框、哪些是按钮，并提供了专门的控制接口。如果直接接上这些接口，就能选中标签页、读取页面结构，再按元素执行操作，不必始终从屏幕位置入手。这就有了专门的Browser Use路径。

浏览器架构。执行器直接连接浏览器，操作指定标签页。

这次用一个网盘任务来说明：搜索“会议纪要”，找到需要的PDF并打开。Agent需要识别搜索框、输入关键词、等待列表，再根据文件名和日期选择文件。

4.2 观察：网页既有画面，也有结构

浏览器会把网页里的文字、输入框、按钮等组成一棵树，记录它们的类型、属性和相互关系。这个结构叫DOM，文档对象模型，工具可以从中查找元素。

浏览器还会提供可访问性信息，描述这些元素怎样供人使用：是按钮还是输入框，叫什么名字，目前能否操作。两种结构与实际画面的关系，可以放在一起看：

同一网页的三种看法。中间用网页标记代码（HTML）示意DOM结构，文字和按钮都能与左侧画面对上。

有了这些信息，执行器可以按“文件名”找到输入框，按“搜索”找到按钮。页面只是把按钮挪了位置，但这些特征没变，工具仍可能找到它；只记旧坐标就容易点错。

网页里的扫描件、图表等内容，仍可能需要看图。这里沿用前面的取舍：能从控件信息说清楚的，就直接读取；需要看外观和内容的，再利用图像。

浏览器也会把网页可访问性信息提供给操作系统，因此桌面工具同样可能读到网页控件。Browser Use多出来的，是直接利用DOM、管理标签页、上传文件等专门面向浏览器的能力。Chromium可访问性架构

4.3 流程：找到元素，再让浏览器执行动作

以网盘里搜索“会议纪要”为例，模型与执行器的分工如下：

阶段	执行器做什么	模型判断什么
读取页面	获取当前页面的控件信息或截图	在哪里填写搜索条件
执行搜索	输入关键词、点击搜索，等待并读取列表	哪份文件符合名称、日期等要求
打开文件	打开选中的文件，返回内容或预览	是否找到了用户需要的文件

这里有两类不同的判断。列表还没加载出来，执行器可以先等一等，没必要让模型对着空白页面猜结果。等几份同名文件都出现了，才需要结合用户要求，判断日期、名称和内容是否合适。

所以，工具可以负责按钮能不能点、结果有没有出现这些检查；模型则在需要理解新内容、选择下一步时参与。这样既能利用程序处理确定步骤的能力，也保留了根据结果调整动作的空间。

点击也延续了桌面部分的思路：工具找到元素后，可以算出它的位置，再通过浏览器接口发送鼠标按下、松开等输入。这些操作直接送给指定页面，不一定会改变你正在使用的鼠标指针的位置。

4.4 现成工具：Playwright和Selenium

前面的操作，不需要自己从头写。浏览器自动化已经有现成的开源工具：

工具	怎样参与执行
Playwright	查找网页元素、填写、点击，并处理相应的等待
Selenium WebDriver	把操作交给对应的浏览器驱动，由驱动控制浏览器

这里的浏览器驱动，就是把控制命令交给对应浏览器的程序。它们在整个链路中的位置如下：

两种可选的接法。Agent通过工具使用这些库，不需要自己实现每个浏览器的控制细节。

这与前面接入PyAutoGUI的思路一样：模型决定做什么，现成工具负责把操作落到软件上。

4.5 连接已有浏览器：扩展有什么用

实际使用时，用户往往已经登录了网站，也打开了要处理的页面。我们希望Agent接着在这里操作；如果换到另一个浏览器环境，可能还要重新登录、重新找到页面。

浏览器扩展提供了一种接入已有浏览器的办法。它就是装在浏览器里的小程序，平时也叫浏览器插件。利用它，外部的控制程序就有机会接上浏览器里已经打开的标签页。

以Codex连接Chrome为例，本机的浏览器服务通过扩展接上目标标签页：

扩展接入示意，省略了本机组件之间的消息转发细节。

扩展借助Chrome提供的接口，把读取页面、点击等命令送进去，再把结果传回来。Chrome提示“已开始调试此浏览器”，就与这条控制通道有关。具体协议放在附录说明。

扩展也能与自动化库一起使用。比如Playwright也有通过扩展连接已有浏览器的方式：库提供操作能力，扩展负责在浏览器内部接上目标页面。

5. 回头看，其实还是那几件事

从RPA到Agent，截图、点击、输入这些基础动作并没有突然变成黑科技。模型加入以后，可以根据目标和当前观察决定下一步，再借用现有工具把动作做出来。

把这层关系看清楚，很多看着神奇的现象就能解释了。系统已经提供了控件信息，Agent就不必每次都从截图里认按钮；浏览器能够直接接收控制命令，页面就可以响应点击，而用户自己的鼠标指针不必跟着移动。

限制也藏在同一条链路里。应用没把控件信息提供完整，模型可能认错；窗口挪了位置，旧坐标可能点偏。能把步骤接起来、在结果不对时发现问题并调整，才是这套方案真正需要做好的地方。

实际任务也不用死守一种方式。有能直接完成任务的程序接口，就直接调用；网页里用浏览器工具，遇到原生窗口再用桌面能力。目的是把事情做成，没必要为了模仿人的操作多绕一圈。

---

6. 附录

6.1 浏览器连接与后台服务

“有后台服务”和“装了浏览器扩展”，听起来都像是在后台替Agent干活，但它们可能处在不同的位置。以Playwright CLI的扩展连接模式为例，先把浏览器里面和外面的组件分开看：

Playwright CLI扩展模式的组件关系：后台进程与浏览器扩展分别承担工作。

浏览器外的后台进程接收CLI命令、保存会话。一次命令执行完，CLI可以退出，后台进程仍然保留连接，后面的命令再接着使用。这类后台运行的进程，通常就叫daemon。

扩展则运行在Chrome里面，负责接上目标标签页。它通过chrome.debugger使用CDP（Chrome DevTools Protocol），把读取页面、鼠标点击等控制命令交给浏览器，再把结果传回去。Chrome扩展debugger接口

因此，扩展并没有把外部的后台进程“装进去”。扩展自己的后台脚本也由Chrome管理：在Manifest V3这版扩展规范下，它采用Service Worker的运行方式，可能在空闲时结束，活动连接等又会影响存活时间。它与独立的后台进程是两回事。扩展后台脚本生命周期

当然，连接浏览器不必都经过扩展。普通Playwright库启动Chromium时，可以通过管道直接建立控制连接；Selenium的本地用法也可以通过本机驱动控制浏览器，不必部署远程Selenium Server。库、后台进程和扩展怎样组合，取决于具体的接入方式。Playwright浏览器启动源码、Chromium启动实现

6.2 控件信息与图片识字有什么区别

可访问性接口返回控件类型、名称、值和层级等数据，执行器可以整理成文字树或JSON等结构化文本格式。Playwright MCP就利用当前页面的这类控件信息，为Agent提供浏览器操作工具，无需先让模型识别截图。

这与OCR，也就是从图片中识别文字，有所不同。OCR可以认出“保存”两个字，但还不一定知道它是按钮、现在能否点击。DOM描述网页元素的结构，可访问性信息描述控件怎样使用，OCR提取画面里的文字，三者提供的信息不同。

6.3 鼠标动画与输入焦点

先分开两件事：屏幕上给人看的动画，以及应用真正收到的操作。画出一个鼠标指针，让它移动到按钮附近，本身并不会触发按钮，实际点击还要通过输入接口完成。

Chrome网页案例里，扩展在页面上叠加一层画面来绘制指针，点击则通过CDP发送。桌面应用的案例里，可以用一个独立的透明小窗口显示动画，再由本机程序把模拟操作交给目标应用。两种实现都把“显示到哪里了”和“实际操作哪里”分开处理。

键盘输入又有另一个问题：现在应该把文字交给哪个窗口、哪个输入框？这由输入焦点决定。我们平时用鼠标点击，窗口切到前台、输入框获得焦点，常常一起发生；自动化程序可能分别处理这些状态。

所以，鼠标指针没有移动，不代表应用没有收到输入；画面上的动画很顺畅，也不能保证操作不会改变用户当前的输入位置。具体表现还取决于应用和执行方式。

6.4 会话状态与软件状态

正文提到的会话，记住的是这次任务正在操作谁。不同任务需要区分各自的目标，避免共用一份“当前标签页”后点错页面。即使每次请求都明确带目标，浏览器本身也仍然保存着表单和登录信息。

这些状态分别保存在不同地方：

状态	例子	需要注意什么
Agent上下文	用户目标、刚才看到的界面、下一步判断	旧观察可能过期
中间层的会话状态	当前浏览器、标签页或应用窗口	应按任务或连接区分，目标关闭后需要更新
应用或网页状态	文档、表单、选区、登录信息	用户和其他程序也可能修改

重新选中标签页，不会自动恢复先前的表单；清理工具会话，也不等于退出网站登录。即使屏幕上有两个鼠标指针，人和Agent仍可能在修改同一份文档或同一个输入框。