Marico's space
你还在用「会不会用 AI」的维度衡量程序员？过时了。
2026 年的今天，真正拉开差距的是——你会不会用 AI 浏览器工具。不是那种 ChatGPT 聊天，而是让 AI 真正接管浏览器，替你干活。
这篇是浏览器工具系列的第二篇，讲框架。第一篇讲了底层基础设施（远程浏览器、CDP、无头 Chromium），没看的先去补。今天要聊的是：browser-use、Stagehand、Skyvern这几个框架，各有什么门道。
说实话，这几个框架放一起比较，但它们解决的根本不是同一个问题。很多人一上来就问「哪个最好」，然后就开始选错了。
在进入具体工具之前，先把这个本质分歧搞清楚。AI 要操作网页，必须先「看到」网页。只有三种方式：
DOM 优先：解析 HTML、提取无障碍树、转成文本喂给语言模型。模型在结构化数据上推理。这速度快、token 效率高，在现代 web 应用上表现很好。
视觉优先：截屏，把截图直接喂给有视觉能力的模型。模型看到的是人类眼中的样子——按钮、表单、导航。没有 DOM 解析，没有无障碍树，只有像素。这更慢、更贵，每一步都在烧 token。但在任何页面上都能 work——包括 Canvas 应用、PDF 渲染页面、DOM 乱成一锅粥的旧系统。
混合：两个都用，让模型自己选。或者 DOM 处理结构化元素，DOM 失效时回退到视觉。
每个框架都在这场战争里选了一边。这个选择会级联到所有方面：速度、成本、准确率、能处理的网站类型。搞清这个，再看工具，才能不被 marketing 带着走。
8.5 万 GitHub stars，9000 个 fork，MIT 许可。如果你去年 Google 过「AI browser automation」，肯定见过它。
架构很直接：底层 Playwright（Chromium、Firefox、WebKit 都能跑），上面套一个 agent 循环——接收自然语言指令、观察浏览器状态、选动作、执行、再观察。循环往复。支持基本上所有主流 LLM：Claude、GPT-4o、Gemini，甚至可以通过 Ollama 用本地模型。
89.1% 的 WebVoyager 分数被它 marketing 翻来覆去用。这个成绩确实不错，但 benchmark 和生产环境是两码事，你的体感取决于目标网站的复杂度、认证流程和反爬强度。
不过说实话，有个问题一直在那：每一步都需要调用 LLM。每个观察、每个动作决策、每次验证，都要付费。一个十步的工作流，用 GPT-4o 大概烧掉 0.15-0.30 美元。一天跑一千次？你的 CFO 开始有意见了。一天一万次？CFO 开始更新简历了。
这感觉就像：一个特别聪明的实习生，但每个决定之前都要打电话问导师。靠谱吗？靠谱。规模大了贵吗？真的贵。
2.18 万 stars，Browserbase 出品，TypeScript 原生。这家团队想明白了一件事，而 browser-use 那边似乎没太在意——缓存。
Stagehand v3 是认真的架构重写。直接抛弃 Playwright，走 CDP（Chrome DevTools Protocol）。结果是 shadow DOM 和 iframe 交互快了 44%。但速度不是重点，重点是重复动作的缓存。
第一次访问一个页面，Stagehand 和别人一样：调用 LLM、弄清楚要点哪里、输入什么、提取什么。然后它把映射关系缓存下来。下次遇到相同或足够相似的页面，直接重放缓存动作，零 LLM 调用、零延迟。
想想这对生产环境意味着：你的 agent 每天填 50 次同样的保险表单？第一次跑要花钱，第 2-50 次基本免费。每任务摊销成本直接崩下来。
API 很简单：act() 单动作，extract() 结构化数据提取（带 Zod schema 验证），agent() 多步骤流程。自愈机制也很聪明：DOM 变化导致缓存动作失败时，自动重新调用 LLM 找出新映射，缓存后继续。
但有几点要掂量：Stagehand 是 TypeScript。如果你的 agent 栈是 Python（大概率是），你要么包装成子进程、跑 sidecar 服务、要么重写编排层。摩擦不小。
另外，Stagehand 是 Browserbase 做的。开源 SDK 能本地跑，但预期部署路径是他们的云浏览器基础设施。SDK 是入口匝道，云是收费公路。搞清楚再上车。
这感觉就像：写脚本的开发者——任何事做超过两次就写脚本。是偷懒，但是最好的那种偷懒。
2.1 万 stars。唯一一家看截图而不解析 HTML 的。
Skyvern 的论点是：DOM 是个谎言。这话虽然偏激，但也不无道理。现代 web 应用是 React 虚拟 DOM、Web Components、shadow root、嵌套 iframe、Canvas 元素、SVG 做 SVG 永远不该做的事的丛林。把这堆东西可靠地解析出来，确实是傻子才干的事。
所以 Skyvern 的思路是：截一张图，喂给视觉模型。模型看到的是人类眼中的样子：按钮、表单、导航、文字。
Skyvern 2.0 是三阶段 agent 循环：Planner 把目标分解为子目标，Actor 在网站上执行动作，Validator 确认成功并在出问题触发重规划。这套循环把 WebVoyager 分数从 v1 的 45% 推到了 v2 的 85.85%。他们在 eval.skyvern.com 发了完整评估轨迹，这透明度比大多数竞品强。
什么时候我会选 Skyvern 而不是 DOM 优先工具？旧企业门户（2008 年那种 HR 还在让你用的 GWT 怪物）、Canvas 密集型应用、标记故意混淆的网站、视觉布局是唯一可靠真相的地方。对于标准的现代 React 应用，干净的语义 HTML？DOM 优先工具更快更便宜。
成本问题是真的。视觉模型贵，截图每步都要烧。他们的云产品绑定了反机器人检测、代理轮换、CAPTCHA 解决和并行执行，这才是价值真正所在。私有部署有，但你得自己搞定基础设施。
这感觉就像：雇了一个人类承包商来手动测试你的网站。每任务更贵，但什么幺蛾子都能处理。
重复工作流（同网站、同表单、一天跑很多次）：Stagehand 的缓存意味着第一次之后成本趋近于零。前提是你能吃下 TypeScript。
视觉密集或遗留网站，DOM 靠不住：Skyvern 的视觉方案是务实选择。每步多花钱，换取在奇怪网站上的可靠性。
最大社区和最多例子：browser-use 是安全选择。Python，到处都有，确实能 work。每步都付钱，但至少知道能用。
另外还有个有趣的点：expect 这个工具经常被人和 browser-use 放一起比，但它们根本不是一回事。browser-use 是让 agent 操作浏览器完成任务；expect 是测试 agent，用浏览器验证你的代码有没有坏。方向完全相反。一个是让 AI 替你干活，一个是让 AI 替你 QA。把这两比较，就像把赛车和碰撞测试设备放一起比较——都涉及高速移动，但目的完全不同。
框架是构建块，不是宗教。实际项目中，Stagehand 用于重复工作流，Skyvern 用于遗留旧系统，expect 用于 CI 验证——组合使用才是常态。
原文：browser-use vs Stagehand vs Skyvern：AI 代理浏览器框架对比