第 31 章 · Computer Use

那个没有 API 的物流商后台

那个卖家最近头疼一件事。他合作了五年的一家小型海外仓，服务一直靠谱，价格也好，唯独一点：对接方式停留在上个世纪——没有 API，没有 webhook，甚至连一份能导出的 CSV 都没有。每天他要登录那个界面粗糙的老后台，一个订单一个订单地翻，把已入库、已出库、卡在清关的状态抄进自己的表格。

他找过对方技术，得到的回复是：“我们没有开放接口的计划。”

这就尴尬了。前面几章我们讲的工具调用（第 4 章）、MCP（第 5 章），全都建立在一个前提上：目标系统有一个能编程调用的入口。可现实里，大量系统偏偏没有——老旧的内部管理后台、只有网页版的第三方服务、某个必须点来点去的桌面软件。对这些系统，Agent 想帮上忙，就只剩一条路：像人一样用它——看屏幕、移动鼠标、点击、打字。

这种“让 Agent 直接操作图形界面”的能力，就是本章的主角：Computer Use（计算机操作）。

Computer Use 与 Browser Use：让 Agent 长出手和眼睛

先把两个术语分清楚。

Computer Use（计算机操作） 是个大概念：让 Agent 像人一样操作一台计算机的图形界面（GUI）——不管是浏览器、桌面应用，还是整个操作系统。它给 Agent 补上了两样人类操作电脑时最基本的东西：眼睛（看到屏幕上有什么）和手（把光标移过去、点下、输入）。

Browser Use（浏览器操作） 是 Computer Use 里最常见、也最重要的一个子集——只操作浏览器里的网页。之所以单独拎出来，是因为绝大多数“没有 API 的系统”其实都是网页后台，而网页有一个桌面软件没有的巨大优势：它的界面结构是可以被程序读到的（后面会讲的 DOM 和无障碍树）。这让浏览器操作比操作任意桌面软件可靠得多，专门的库和方案也最成熟。

一句话记住这层关系：Computer Use 是“操作任意界面”，Browser Use 是“只操作网页”，后者是前者里最好啃的一块。 那个卖家的物流商后台是网页，所以他要的其实是 Browser Use。

它的骨架，还是第 3 章那个循环

如果你觉得 Computer Use 听起来很新，其实一点都不。它的运行骨架，就是把第 3 章的 ReAct 循环原样套在图形界面上，只不过每个阶段换了具体形态：

  1. 感知（Perceive）：获取当前界面的状态——屏幕上现在长什么样、有哪些可点的东西。这一步对应 ReAct 里的 Observation（观察）。
  2. 决策（Decide）：模型结合界面现状和总目标，想清楚下一步该做什么——“该点那个绿色的‘登录’按钮”“该在搜索框里输入订单号”。这对应 Thought（推理）。
  3. 操作（Act）：把决策变成一个真实的界面动作——模拟一次点击、一次键盘输入、一次滚动。这对应 Action（行动）。
  4. 观察（Observe）：动作执行后界面变了，重新感知新状态，回到第 1 步。

于是“感知—决策—操作—观察”转起来，就是一轮又一轮，直到任务达成。写成轨迹，和第 3 章那张几乎一模一样：

感知    → 当前是登录页，有用户名框、密码框、"登录"按钮
决策    → 先填用户名
操作    → fill: 用户名框 ← "seller@example.com"
观察    → 用户名已填入，密码框仍为空

决策    → 再填密码，然后点登录
操作    → fill 密码框、click "登录" 按钮
观察    → 页面跳转到订单列表，出现一张表格

决策    → 目标是抄订单状态，读这张表
操作    → snapshot: 读取订单表格的结构
观察    → 拿到 20 行订单，各带状态字段 ✅

看出来了吧——Computer Use 不是一门新范式，它是 ReAct 换了一身“操作 GUI”的行头。 你在第 3 章学会的那套“想一步、做一步、看一步、绝不凭记忆瞎冲”，在这里照样管用，甚至更要紧：界面比 API 善变得多，每一步都必须看着真实屏幕做决定。

关键的岔路口：怎么“看”这块屏幕

整个 Computer Use 里，最重要的一个工程选择，落在“感知”这一步：Agent 到底靠什么方式看屏幕？ 主流有两条路，各有各的脾气。

第一条：截图（Screenshot）。 把当前屏幕截成一张图，直接喂给能看图的多模态模型（multimodal model），让它像人一样“看”。

  • 优点：通用。只要能截图，什么界面都能看——网页、桌面软件、游戏、远程桌面，一视同仁。
  • 缺点：贵、慢、还可能看不准。一张高分辨率截图会占掉大量图片 token，成本蹭蹭涨；而且模型是从像素里“猜”每个按钮的坐标，稍微复杂一点的页面，它可能把点击落在偏几十像素的地方，点空、点错都是常事。

第二条：结构化元素树（structured element tree）。 不看图，而是直接读界面背后的结构描述。网页里就是 DOM（Document Object Model，文档对象模型）；更规范的是 无障碍树（accessibility tree，也叫 a11y tree）——操作系统和浏览器本来就为屏幕阅读器等辅助工具维护着这样一棵树，上面清清楚楚写着“这里有一个按钮，文字是‘登录’，这里有一个输入框，标签是‘密码’”。

  • 优点：精确、便宜、可靠。它拿到的是“这有个叫‘登录’的按钮”这种确定信息，不用从像素里猜坐标；文本比图片省得多的 token；而且点击是按元素定位（选择器）而非屏幕坐标，页面挪个位置也不容易点空。
  • 缺点：只在能拿到结构的地方可用——主要是网页。对一张纯图片、一段视频、或者一个自己绘制界面、不暴露结构的桌面软件，这棵树是空的，你只能退回截图。

这里有一条几乎可以当铁律记的经验：

能拿到结构就别用截图。 网页操作优先走 DOM / 无障碍树，只有在拿不到结构（纯图形界面、Canvas 绘制、桌面软件）时，才退而求其次用截图。

原因很直白：截图是“猜”，结构树是“看确切答案”。既省钱又可靠的那条路摆在面前，没理由为了通用性去多花几倍的钱、多担一份点错的风险。那个卖家的物流后台是标准 HTML 网页，DOM 拿得到——他的 Agent 就该走结构树这条路。

多模态理解，不等于 Computer Use

这里顺手补一个边界。第 6 章说过，图片、PDF、截图都可以作为多模态输入进入消息或工具链，再输出结构化结果。但看懂一张图和操作一个界面不是一回事。

场景本质主要风险
审核商品主图、识别发票字段、理解截图内容多模态理解看错、漏字段、置信度不足
看着网页/桌面一步步点击、输入、提交Computer Use点错、状态变化、真实副作用

所以多模态理解通常应该回到第 6 章的做法：看完后输出结构化字段、置信度和依据。Computer Use 则必须多一层运行时控制：每一步都要观察页面状态，危险动作要确认，最好在沙箱或测试账号里跑。

一句话：多模态让 Agent 看见更多输入，Computer Use 让 Agent 对环境产生动作。 前者重点是结构化理解，后者重点是可控执行。

用 pi 实现：dev-browser 技能

在 pi 里，浏览器操作能力由一个叫 dev-browser 的技能承载（在 pi 的 .pi/skills/dev-browser/ 里）。回顾第 7 章——技能（Skill）是按需加载的能力包，遵循 Agent Skills 标准，一个 SKILL.md 加一个目录，平时不占上下文，需要时才被加载进来。dev-browser 正是把“如何驱动浏览器完成开发调试与网页操作”这套完整工作流打包成了这样一个技能。

而它揭示了 Computer Use 落地时一个很漂亮的分工，值得单独讲清楚：

Computer Use 能力 = 技能 + 工具的组合。

  • 工具（Tool，第 4 章）：提供底层操作原语——最小的、单一职责的动作：打开一个网址、点一个元素、往输入框填字、读一次界面结构。这些原语通常由 Playwright 这类浏览器控制库在底下真正驱动浏览器执行。
  • 技能（Skill，第 7 章）：提供上层工作流——它不关心某个点击怎么实现，而是告诉模型“面对一个任务，该按什么顺序、什么时机去组合这些原语”，比如“先 snapshot 看清页面有什么，再决定点哪里，而不是上来就瞎点”。

概念上，浏览器操作的这批底层工具大致长这样：

// 底层操作原语（由浏览器控制库如 Playwright 支撑）—— 概念示意
browser.registerTools([
  { name: "navigate", description: "打开指定 URL" },
  { name: "click",    description: "点击某个元素（按选择器定位，而非屏幕坐标）" },
  { name: "fill",     description: "在指定输入框里填入文本" },
  { name: "snapshot", description: "读取当前页面的无障碍树 / DOM —— 优先于截图" },
  { name: "screenshot", description: "截图（仅当拿不到结构时的兜底手段）" },
]);

而 dev-browser 技能里的 SKILL.md，写的则是“怎么用好这批工具”的策略，概念上像这样：

<!-- .pi/skills/dev-browser/SKILL.md 概念示意 -->
# dev-browser

操作网页时遵循以下工作流：
1. 每次到达新页面，先用 `snapshot` 读取结构，看清有哪些可交互元素，
   不要凭截图猜坐标。
2. 用元素的可见文本/标签来定位，而不是脆弱的绝对坐标。
3. 每次 click / fill 之后，再 snapshot 一次确认界面确实变到了预期状态。
4. 只有在页面是 Canvas、图表等拿不到结构的情况下，才 `screenshot`。

注意两处细节：一是 snapshot（读结构）被摆在 screenshot（截图）前面、并被反复强调——这正是“能拿结构就别用截图”原则在工程上的落地；二是技能和工具各管一段、互不越界：工具只负责“能点一下”“能填一个字”，要不要点、先点哪个、点完怎么核实，全是技能这层的工作流在指挥。这种分工的好处是——换个更强的浏览器库，只动工具那层；调整操作策略，只改技能那层，两边解耦。

动手看看

找一台装了 pi 的机器，打开 .pi/skills/dev-browser/ 这个目录（如果你的版本带这个技能），先读一读里面的 SKILL.md——重点看它对“感知方式”的措辞：它是不是也把“先读结构、别急着截图”写进了工作流？这比我们讲十遍都直观。

如果暂时没有这个技能，也可以自己做个极小的实验感受感知方式的差异：随便打开一个网页，在浏览器开发者工具的 Console 里敲一行 document.querySelectorAll('button')，看它列出的按钮文本；再对同一个页面截一张图。对照着想一下——如果你是模型，是从那份带文字的按钮列表里挑一个来点，更靠谱，还是从一张图里数像素来猜坐标更靠谱？答案会让你对“能拿结构就别用截图”这句话记得更牢。

实战中的几个坑

坑一：界面一改版，Agent 就迷路。

  • 现象：昨天跑得好好的流程，今天对方后台改了版，Agent 到处点不中，任务全挂。
  • 原因：界面是给人看的、随时会变，Agent 依赖的按钮位置或结构一变就失配——这是 Computer Use 天生的“脆”。
  • 对策：定位尽量用稳定的可见文本/标签而非绝对坐标；关键步骤做失败重试与断言校验；把“没找到预期元素”当异常处理，而不是硬点下去。

坑二：弹窗、加载、动画把它卡住。

  • 现象：Agent 点完按钮就“愣住”，或对着一个还在转圈加载的页面就急着读，读到空的。
  • 原因：真实网页有异步加载、有 Cookie 弹窗、有过场动画，界面不是瞬间就位的。
  • 对策：操作后加“等待元素出现/网络空闲”的显式等待，而不是固定 sleep；把常见弹窗（同意 Cookie、关闭广告）作为流程里预置的一步先处理掉。

坑三：截图省事却又贵又不准。

  • 现象：图省事全程用截图驱动，token 花费高得吓人，点击还老是偏一点点点空。
  • 原因：违背了“能拿结构就别用截图”——网页明明有 DOM 却不用，硬走多模态看图。
  • 对策：网页一律优先 snapshot 读结构，截图只当拿不到结构时的兜底。

坑四：真实操作误操作，后果收不回来。

  • 现象：Agent 在真实账号里点了“确认下单”“删除”“付款”，钱花了、单发了，撤不回。
  • 原因：Computer Use 操作的是真实系统和账号，副作用真实且可能不可逆——这是它最大的风险，比 API 调用危险得多。
  • 对策：务必配合隔离环境（第 28 章，让它在受控沙箱/容器里跑）与确认门（第 8 章，涉及付款、删除、提交等高危动作时暂停、等人点头再继续）。

对比：其他框架

Computer Use 是一种相当专门的能力，绝大多数通用 Agent 框架并不内建“看屏幕、点鼠标”这一层——它们通常依赖模型厂商的原生能力（如 Anthropic Computer Use、OpenAI Operator）或专用库（如 Browser Use、Playwright MCP）来提供实际的界面操作，框架自己负责把这层能力接进来、编排进循环。

框架Computer Use 怎么做特点
LangGraph自身不提供界面操作，但很适合把“感知—决策—操作—观察”循环画成状态图，浏览器/桌面操作作为工具节点接进去编排清晰，能力靠外接
CrewAI不内建 GUI 操作，可给某个角色 Agent 配上浏览器自动化工具，由它承担“操作界面”的分工以角色分工承接
PydanticAI不涉及 GUI；若要用，把 Computer Use 封成带类型的工具调用，框架只负责类型约束与校验类型化接入
Agno内置工具生态较全，可挂浏览器/自动化类工具，但“看屏幕操作”的多模态部分仍主要依赖底层模型或专用库工具丰富，核心仍外借
pi以 dev-browser 技能 + 浏览器工具组合实现，体现“技能管工作流、工具管原语”的分工，感知优先用结构化元素树而非截图分工清晰、结构优先

一句话点本质：Computer Use 的核心能力其实来自模型和专用库，框架的活是把它接进 ReAct 循环、编排好流程；而“有 API 就别用它”这条，对每一家都一样适用。

小结

  1. 面对没有 API 的系统，Agent 只能像人一样操作界面——这就是 Computer Use（计算机操作）；只操作网页的那个子集叫 Browser Use（浏览器操作），是其中最成熟、最好啃的一块。
  2. 它的骨架就是第 3 章的 ReAct 循环套在 GUI 上：感知—决策—操作—观察，一步步来，绝不凭记忆瞎点。
  3. 最关键的工程选择是感知方式：截图（多模态看图，通用但贵、慢、可能看不准坐标）对比结构化元素树（DOM / 无障碍树，精确、便宜、可靠但只在能拿到结构处可用）——铁律是“能拿到结构就别用截图”。
  4. 多模态理解和 Computer Use 的边界不同：前者重点是把图片/文件变成结构化结论，后者重点是让 Agent 对界面产生可控动作。
  5. pi 用 dev-browser 技能 + 浏览器工具实现，体现“技能管工作流、工具管原语”的分工，snapshot 读结构优先于截图。
  6. Computer Use 又慢又脆又有风险，务必配合隔离（第 28 章）与确认门（第 8 章）；能用 API 就用 API（第 3、4 章），只有没 API 才退而求其次用它。

Computer Use 让 Agent 的手伸到了没有 API 的角落。而下一章我们要看 pi 最本命的一种形态——它自己就是一个会写代码、改代码、跑测试的 Agentic Coding Agent。