让一个 Browser Agent 订一张机票。打开网站、登录、输入出发地和目的地、筛选时间、选航班、提取价格——听起来就六个动作。
但你真的去看第一代 Browser Agent 跑这个流程，会发现它的大部分时间根本没花在这六个动作上。它在登录——它新起的那个浏览器没有任何登录态；它在等待——等页面加载、等元素出现；它在定位 DOM——CSS 选择器又变了；它在重试——某一步失败，推倒重来。真正的业务逻辑，占比很小（这是我观察执行 trace 的估算，不同任务差异很大）。
问题不在模型不够聪明，在架构：浏览器是一次性工具，这些成本就永远摊不掉。
最近有人丢给我一个新产品 ego Lite 的资料，问值不值得试。我的第一反应和大多数人一样：又一个 Browser Agent？但把它的架构看完，我意识到这个理解是错的——它真正动的不是 Prompt，不是模型，而是浏览器在 Agent 系统里的角色。
过去 Browser 是 Tool。现在 Browser 开始变成 Runtime。
这是我认为 Browser Agent 最近一年最值得关注的技术方向。
上周帮一个朋友调他的 AI Agent。需求很简单：自动登录一个美国政府网站，填三张表，提交。
他选了 VNC 路线——Agent 通过远程桌面连上一台真实 Mac，操作真实的 Chrome 浏览器。逻辑很对：真实浏览器没有 navigator.webdriver 标记，没有 CDP 连接痕迹，TLS 指纹是真的，Canvas 指纹是真的。从浏览器的视角看，就是一个正常用户坐在键盘前。
他很有信心。然后 Agent 在第二步就被拦住了。
不是被防火墙拦的，不是被反爬拦的。是 Cloudflare Turnstile 弹了一个无感验证，Agent 的鼠标 瞬移 到了按钮上， 零毫秒 完成点击。没有移动轨迹，没有加速度变化，没有人类手指的微颤。
一个人类不可能这样操作。而 Cloudflare 知道。
凌晨两点，我的 Agent 又停了。
不是模型挂了，不是网络断了，不是 Token 用完了。是 Browser MCP 的 WebSocket 连接断了，而那个该死的 Chrome 扩展弹窗里，「Connect」按钮正安静地等着有人去点一下。
我在跑 --watch 模式——Agent 监控一个内部系统，页面一变就自动抓取数据、做分析、写报告。整条链路全自动，唯独 Browser MCP 的连接需要手动点。每次断连，我就得从床上爬起来，点开 Chrome 工具栏那个小图标，点一下 Connect。
在 Agent 操作浏览器的九条路线 里，我把 Browser MCP 归到「真实浏览器 + 扩展 + CDP + MCP」那一类，给了它四颗星的企业推荐度。但那篇文章没写的是： 它有一个致命的手动断点，而这个断点在自动化场景下足以毁掉整条链路。
这篇文章记录我怎么用 Vision 大模型 + macOS 原生自动化，把这个断点彻底消灭。不是 Demo，是从 v1.0 迭代到 v1.4.2、踩了六个坑之后的生产方案。
值得一提的是：整个项目的所有代码——从第一行 screencapture 调用到最后的 LaunchAgent plist——都是 Opus 4.8 写的。我做的事情是描述需求、测试、报错、再描述。这个过程本身就是一个有趣的发现：当你把「我需要一个能自动点击 Chrome 扩展按钮的脚本」这种模糊需求扔给一个足够强的模型，它给出的第一版方案往往方向正确但细节全错——而每一处「错」的背后，都藏着一个 macOS 平台特有的坑。
上个月一个团队来找我，说他们要做企业内部的 AI Agent，需要操作浏览器。
第一个问题就是：「用 Playwright 还是 Browser Use？」
我说这个问题本身就问错了。就像你问「盖楼用钢筋还是混凝土」——答案是都用，但用在不同的层。
Browser Automation 在 AI Agent 语境下，已经不是一道单选题。它是一张技术地图，九个梯队，各有适用场景。而真正在生产环境里跑通的企业 Agent，几乎都是 分层架构——API 优先，结构化浏览器控制居中，Vision 兜底。
上周我写了一篇 LLM 自动化 vs RPA：省的不是智能，是编排成本，提了一个「探索-编译-执行」的三层架构——LLM 先探索网页、找到可行路径，然后编译成代码，后续直接执行。
写完没几天，微软研究院发了 Webwright，几乎就是这套思路的学术验证。但让我意外的不是它验证了三层架构，而是另一个发现： harness 本身可以薄到离谱。
整个系统只有 ~1000 行代码，三个模块，没有 multi-agent 编排，没有复杂的动作空间设计。它给模型的东西只有一个——terminal。
