浏览器自动化到底分几层：Harness、browser-use、Playwright、坐标流怎么选

接上一篇，聊完我自己那套云端浏览器，朋友顺着往下问了一串：browser-use 和 Harness 到底什么区别，固定坐标到底能不能用，selector 是不是正道。这些问题看着是问工具，其实是问同一件事——浏览器自动化到底分几层。这篇还是问答实录。

问：最近老看到有人吵，Harness 跟 browser-use 到底什么区别？

先别急着比工具名。这俩压根不在一个层面。我习惯把浏览器自动化拆成四层楼，从地下室往上数：

地下室：像素坐标，看到哪点哪；
一楼：DOM 脚本，也就是 Playwright 那类，把操作写成可复现的脚本和断言；
二楼：Agent 工具层，Harness 在这，它不替你完成任务，只给 Codex、Claude Code 这类上层 Agent 一套操作浏览器的接口；
顶楼：自然语言 Agent，browser-use 在这，你给一句任务它自己规划、观察、执行。

所以 Harness 和 browser-use 的区别很清楚：一个是工具层，给 Agent 提供浏览器控制能力；一个是完整的自然语言任务执行器，自带规划和观察。你选的不是工具名，是你的任务该住几楼。

问：你这么说是不是先入为主了？有数据吗？

我拿同一把尺子跑过。同一台机器、同一个本地页面、同一个任务：填一个搜索词、勾选数据来源、把报告模式切到高级、点击生成。然后我搞了五种变化——页面不动、按钮换位置、按钮文案改了、顶部多一条横幅、弹窗遮挡——四种方法挨个跑。

结果摆这儿：

Playwright 用 get_by_role / get_by_label 这类语义定位器，五个场景全过，平均 137ms，而且每次都带 DOM 断言确认结果。
Harness 用 Codex 写 CDP helper 跑同样五个场景，也全过，平均 277ms，靠 CDP 读状态来验证。
固定坐标五个只过了三个，稳定页面最快 82ms，比 Playwright 还快，但按钮一挪、横幅一插就废。
browser-use 跑了两个轻量场景都完成了，连按钮换位置也处理了，但平均要 37 秒，而且结果靠 Agent 自己报告，我没给它做独立断言。

得说清楚口径：固定坐标和 Playwright 都不需要模型，一个认像素一个认 DOM。Harness 这次也没额外调模型，是 Codex 写脚本时介入。真正让模型全程介入、观察页面、决定动作、判断结果的是 browser-use。所以问题从来不是「要不要 API key」，而是模型参与到了哪一步。只要模型参与判断结果，你就得想清楚信不信它的判断，还是一样需要 DOM 断言兜底。

问：那坐标漂移是偶发 bug 吗？

不是偶发，是结构性缺陷。你今天录的坐标，明天页面改版就点空了。截图里看得最清楚：左边稳定页面固定坐标准确点到按钮，七十多毫秒搞定；右边按钮挪了位置，坐标还在点老地方，表单压根没提交；顶部加个横幅，整页往下推几十像素，坐标全偏。

但别误会我否定截图。截图作为观察手段非常好——留证据、看 Canvas、确认视觉状态都离不开它。我反对的是拿固定坐标当长期控制方案。Playwright 和 Harness 不靠像素定位，靠的是 DOM 结构和语义，所以页面微调影响不到它们。

问：为什么四个方案差这么多？

出发点就不一样。

Playwright 是微软做的，目标是跨浏览器测试，核心诉求是确定性和可复现，所以它压根不碰模型，就认 DOM 的语义。

browser-use 的目标是让网站变成 AI 能用的东西，所以它围绕自然语言和模型规划来做。

Harness 的定位是 Agent 工具层，不替你完成任务，只给 Codex Cloud 这类 Agent 一个操作浏览器的接口。

固定坐标没有项目方，就是最朴素的一招：看到哪里点哪里。

它们长得不一样，是因为服务的用户完全不同。不是四个人打擂台，是四层楼。

问：一楼 Playwright，你说是稳定性冠军，展开讲讲。

它的逻辑很朴素：用 role、label 这些语义定位器找元素，等元素可操作了再执行动作，最后用断言确认结果。按钮挪了位置，只要 label 没变照样找得到；文案改了，用正则匹配就行。

弱点也明确：页面结构大改你得改脚本，探索型任务它帮不了你。所以结论很直接——固定流程、回归测试、CI 里的自动化检查，Playwright 是起点。

问：二楼 Harness 呢？它跑得比 Playwright 慢，图啥？

别拿它和 Playwright 比速度，它的价值在别处。它给的是一套接口，Agent 能看到 DOM 树、能截屏、能读页面状态，操作失败了还能判断下一步怎么补救。这对 AI 编程工具很关键——Agent 不只是要点按钮，它需要知道点完之后页面变成了什么样。

你要是用 Codex 或者 Claude Code，想让它打开浏览器验证结果，Harness 就是那座桥。

问：顶楼 browser-use，最像人的方案？

对，也最贵。你说「打开这个页面，填个表，点生成」，它自己去看页面、决定先点哪里再填什么。这次我跑了两个场景都完成了，按钮换位置它也处理掉了。

但成本明确：每次都要 LLM 跑几十秒，结果最好再用别的方式复合一遍。所以它不是 Playwright 的替代品，更适合临时任务、没有现成脚本的页面，或者你想先快速验证「Agent 能不能搞定这件事」。把它想成一个会操作浏览器的助手，不是测试框架。

问：地下室固定坐标，是不是一无是处？

被高估得最厉害的就是它。优点就一个字，快——跳过找元素这步，稳定页面七十多毫秒。但它五个场景只过了三个，按钮移动和顶部横幅直接挂掉。

它也不是完全没用：录个一次性演示、页面永远不变的公司内部小工具、做个概念验证，坐标流可以救急。但心里得清楚这是一次性的。把固定坐标当长期自动化方案，等于把房子建在沙子上。

问：回到最开始那三个问题——坐标漂移、selector 是不是正道、Harness 和 browser-use 区别？

坐标漂移不是偶发 bug，是结构性缺陷，页面布局一变就触发。selector 之所以被说成完爆坐标流，是因为它绑的是语义——按钮的名字、角色、层级关系，不是像素位置。Harness 和 browser-use 的区别，一个是工具层给 Agent 提供浏览器控制能力，一个是完整的自然语言任务执行器，自带规划和观察。

问：那你最后会怎么推荐落地？

路径其实很清楚：

你有一个固定的网页流程要自动化，先写 Playwright，不要上来就上 Agent；
你再用 Codex 或 Claude Code，希望 Agent 能打开浏览器看效果、点按钮，加 Harness；
偶尔有个临时网页任务不想写脚本，试试 browser-use；
只是录个演示，用坐标流，但心里清楚这是一次性的。

成熟的路线不是从第一天就上 Agent，而是先把能脚本化的部分固定下来，再把没法预判的部分交给 Agent。如果非要只推一个默认方案，我选 Playwright——最容易验证、最容易维护、最适合长期留在工程里。但默认推荐不等于唯一答案：让 Agent 控浏览器我会加 Harness，自然语言临时任务用 browser-use，一次性演示坐标流留够用。

说到底，能脚本化的别交给 Agent，需要 Agent 的别硬写脚本。未来的浏览器自动化不是一种方案干掉另一种，而是四层叠在一起：底层是浏览器和 DOM，第二层是 Playwright 这类确定性工具，负责所有可复现的流程，第三层是 Harness 这类 Agent 工具层，让 AI 能看到、操作、判断真实页面，最上层是 browser-use，用自然语言执行器处理没法预先写好脚本的任务，坐标流作为最轻的兜底一直会在。

所以这个趋势不是 AI 取代 selector，恰恰相反——AI 越强，越需要 DOM selector 和工具层帮它理解页面。