1. 先说结论这两个工具到底解决什么问题最近两三年浏览器自动化的玩法被大模型彻底重写了一遍。以前我们写Selenium、Playwright脚本本质上是“人肉定位元素 写死操作步骤”每一步都要告诉浏览器点什么、输什么、等什么。而现在以Midscene和Stagehand为代表的AI Agent类工具把这一层彻底抽象掉了——你只需要告诉它“去干什么”它自己去看页面、理解页面、操作页面。Midscene和Stagehand是我在实际项目中反复对比过的两个方案。先说结论Midscene更适合“快速上手、零代码负担、把自然语言当脚本用”的场景Stagehand更适合“深度可控、需要精细维护、希望把AI能力嵌进现有自动化框架”的场景。如果你正纠结选哪个这篇文章会从设计思路、API细节、模型依赖、实际体验、踩坑记录这几个维度全部拆开讲。我尽量用做项目时的真实视角来讲不堆参数也不念文档。2. 两个工具的核心理念与设计思路拆解2.1 Midscene用自然语言直接驱动浏览器Midscene配合maestro midscene这类编排层的核心思路非常激进把“写脚本”变成“写指令”。它基于多模态大模型直接把网页截图 DOM结构 用户指令一起喂给模型让模型自己决定“该点哪里、该输入什么、该选哪个选项”。我第一次用它跑通一个完整流程时最大的感受是它不是在执行脚本而是在“看”页面。比如面对一个典型的电商下单流程——搜索商品、筛选条件、加入购物车、跳转结算、填写地址、提交订单——用传统Playwright写至少要50到100行定位器和状态等待代码用Midscene写可能就是一行自然语言指令加上2到3行JavaScript调用。Midscene的工作机制大致分三层感知层截取当前页面截图同时提取可见区域的DOM信息和元素坐标。这部分是它“看得见”的基础。决策层把用户指令 页面状态交给多模态大模型让模型推理出下一步应执行的动作并返回一个结构化的动作描述。执行层把模型返回的动作如点击、输入、选择翻译成浏览器原生事件在页面上真实执行执行完成后再次截图反馈给模型。这个“感知-决策-执行”闭环是Midscene的核心循环。它的好处很明显页面元素只要肉眼能看见它就能操作不需要你去翻DOM找定位符。坏处也很明显每次决策都要调用大模型速度和成本都要算进预算里。2.2 Stagehand让Playwright学会“思考”Stagehand是Browserbase推出的开源框架它没有另起炉灶而是选择在Playwright的基础上做了一层AI能力扩展。它保留了Playwright的稳定性、选择器体系、自动等待机制和调试工具同时新增了三个核心能力act执行动作、extract提取数据、observe观察页面。Stagehand的核心思路是“渐进增强”——你不需要把整个脚本推倒重来而是可以在原有Playwright代码里挑出最麻烦、最脆弱的部分交给AI处理。传统的Playwright代码可以继续跑只在需要的地方调用Stagehand的AI方法。举个例子。以前用Playwright做数据采集遇到动态加载的分页表格你得写滚动、等待、判断“下一页”按钮是否可点、循环一直到最后一页。用Stagehand的act你可以直接写一句“点击下一页直到没有更多数据”它自己处理翻页行为用extract你只需要定义“提取这个表格里所有行”的返回格式它会自动把表格内容结构化成JSON。这种“保留旧代码 只替换痛点”的设计让Stagehand非常容易嵌入已有项目。它不会让你做出二选一的决定而是渐进过渡。2.3 设计哲学差异替代还是融合这两个工具最本质的差异可以浓缩成一句话Midscene想替代你写脚本Stagehand想帮你减少写脚本的工作量。Midscene鼓励你用一句话完成一个流程脚本本身不再是“逻辑代码”而是一连串自然语言指令的清单。它的理想状态是“脚本即提示词”开发者只需要维护指令文本剩下的交给模型。Stagehand则把AI定位为“工具集”它增强Playwright而不是取代Playwright。你依然可以写精确的选择器、显式等待、条件分支只是在你不想写、写起来太痛苦、或者页面变化太频繁的地方用AI能力兜底。这就导致了两者在后续实操中的一系列差异模型依赖程度不同、运行速度不同、调试方式不同、适合的团队形态也不同。3. 关键能力逐项对比API设计、模型依赖与运行环境3.1 API设计与编程体验先说Midscene。它的API极其简洁核心就是一个agent对象绑定浏览器页面后直接调用自然语言方法import { Agent } from midscene/web; const agent new Agent({ browser: browser, model: gpt-4o }); await agent.navigate(https://example.com/products); await agent.action(在搜索框输入无线耳机点击搜索按钮); const result await agent.extract(当前页面上所有商品的价格和评分返回JSON数组); console.log(result);这个API几乎没有学习成本。你不需要理解任何浏览器自动化概念也不需要了解CSS选择器或XPath。只要你能清楚描述自己要做什么Midscene就能尝试执行。再看Stagehand。它基于Playwright核心调用方式长这样from stagehand import Stagehand async def main(): stagehand Stagehand(page) await stagehand.init() await page.goto(https://example.com/products) # act执行自然语言描述的动作 await stagehand.act(在搜索框中输入无线耳机并回车) # extract结构化提取页面数据 products await stagehand.extract({ type: array, items: { type: object, properties: { name: {type: string}, price: {type: number}, rating: {type: number} } } })Stagehand的API底层依然暴露了page对象你可以直接调用page.locator()、page.waitForSelector()等Playwright原生方法。这种设计对写过Playwright的人来说非常友好——你熟悉的那些方法一个都没丢只是多了几个AI增强接口。从“上手门槛”来说Midscene的API更简洁几乎不需要前置知识从“灵活度”来说Stagehand完胜因为你可以随时从AI模式切换回普通代码模式精细控制每一步。3.2 模型依赖与成本考量这两个工具都依赖大模型但依赖的方式和程度差别很大。Midscene对模型的依赖是硬性的。每一次动作执行、每一次数据提取都要完整调用一次多模态模型把截图和DOM信息一起送过去。这意味着必须有可用的多模态模型APIOpenAI、通义、或者其他兼容接口每次操作的响应时间通常在2到5秒复杂页面可能更久成本随操作次数线性增长跑一个100步的流程成本不容小觑Stagehand虽然也依赖模型但它的设计做了缓存和本地优先的优化。act、extract、observe都有对应的本地策略比如extract会优先尝试用可访问性树A11y Tree而非截图来做提取只有在本地策略失败时才回退到大模型。这意味着很多简单操作不会触发模型调用速度更快成本通常低于同等工作量的Midscene即使模型API暂时不可用基础Playwright能力依然可用我自己的实测数据同样做一个20步的流程Midscene大约需要40到60秒成本在0.5到1美元左右看模型Stagehand如果都是简单操作基本上10秒内跑完大部分时间走的是本地策略只有少数复杂操作才调用模型。3.3 运行环境与浏览器集成Midscene目前主要面向JavaScript/TypeScript生态支持Playwright和Puppeteer两种浏览器控制层。它还有Chrome扩展形态可以直接在浏览器里录制操作这对快速验证非常有帮助。Stagehand官方支持TypeScript和Python两种语言底层依赖Playwright。它的浏览器生态就是Playwright全家桶支持Chromium、Firefox、WebKit也支持连接已有的浏览器实例。还有一个实际项目里很要命的区别Midscene自带了一套“可视化操作报告”机制每次运行后可以生成一份报告记录AI的每一步决策、页面截图、执行结果。这对排查“模型为什么点错了按钮”极其有用。Stagehand目前也有调试能力但更多依赖Playwright自带的trace viewerAI决策过程没有Midscene那么直观透明。3.4 关键能力对比表为了让你一眼看清差异我把核心维度整理成了一张表对比维度MidsceneStagehand核心定位自然语言驱动浏览器自动化Playwright的AI增强扩展API风格一句话指令零基础可上手Playwright风格 AI方法语言支持主要JavaScript/TypeScriptTypeScript Python模型依赖高每步操作都需要模型决策中本地策略优先模型兜底运行速度较慢2-5秒/步较快简单操作用时极短调试体验自带AI决策可视化报告依赖Playwright Trace Viewer可控性较低主要靠提示词控制高可随时混用精确选择器适合人群快速验证、轻量自动化深度集成、复杂流程、精细控制这张表放大看你会发现两个工具根本不是替代关系而是补充关系。如果你做的是一次性验证或原型DemoMidscene快得离谱如果你做的是长期维护的生产级自动化Stagehand的稳定性优势会更明显。4. 实操过程与核心环节实现4.1 用Midscene 5分钟跑通一个查询流程我们拿一个真实场景来走一遍打开一个电商网站搜索“机械键盘”筛选“茶轴”然后提取前5个商品的价格和评分。先说Midscene的完整流程。第一步装包npm install midscene/web然后写脚本。这里有一个关键点Midscene要求初始化时把连接到的浏览器page传进去如果你用的是Playwright驱动代码基本长这样import { chromium } from playwright; import { Agent } from midscene/web; async function main() { const browser await chromium.launch({ headless: false }); const page await browser.newPage(); const agent new Agent({ page, // 直接把page传给agent model: gpt-4o // 也可以换成其他OpenAI兼容接口 }); await page.goto(https://example.com); // 用自然语言完成搜索 await agent.action(在搜索框中输入机械键盘点击搜索按钮); await page.waitForTimeout(2000); // 等待搜索结果加载 // 筛选茶轴 await agent.action(在左侧筛选栏中选择轴体类目下的茶轴选项); await page.waitForTimeout(2000); // 提取结构化数据 const result await agent.extract( 提取当前页面上前5个商品的信息每个商品包含 - 商品名称字符串类型 - 当前价格数字类型去掉货币符号 - 评分数字类型保留一位小数 返回JSON数组格式。 ); console.log(JSON.stringify(result, null, 2)); await browser.close(); } main();这段代码里没有任何CSS选择器、XPath、等待条件。模型自行理解“搜索框”“筛选栏”“茶轴”在页面上的位置并执行对应操作。跑完之后如果开了可视化报告你还能看到模型每一步的思考截图。实际跑的时候你会注意到Midscene对页面状态的感知是“瞬时”的——它在每个动作后都会重新截图并更新自身对页面的理解。这意味着如果页面在某个操作后弹出了广告浮层、Cookie确认框模型会自动处理掉脚本不会因为“点击被拦截”而挂掉。这是传统自动化工具非常羡慕的能力。4.2 用Stagehand完成同样的任务同样的流程用Stagehand来写import asyncio from playwright.async_api import async_playwright from stagehand import Stagehand async def main(): async with async_playwright() as p: browser await p.chromium.launch(headlessFalse) page await browser.new_page() stagehand Stagehand(page, modelgpt-4o) await stagehand.init() await page.goto(https://example.com) # AI执行动作搜索 await stagehand.act(在搜索框中输入机械键盘然后点击搜索按钮) await page.wait_for_load_state(networkidle) # AI执行动作筛选茶轴 await stagehand.act(在左侧筛选栏中选择轴体类目下的茶轴) await page.wait_for_load_state(networkidle) # 结构化提取 products await stagehand.extract({ type: array, items: { type: object, properties: { name: {type: string}, price: {type: number}, rating: {type: number} }, required: [name, price, rating] } }) print(products) await browser.close() asyncio.run(main())代码风格上Stagehand的Python版本写起来很顺手因为它保留了Playwright的page对象语义同时在关键步骤上支持自然语言。你在page上照常调用goto、wait_for_load_state只是在需要“理解页面内容”的地方用act和extract。注意一处细节Stagehand的extract要求你显式声明提取结构。好处是返回的数据格式一定是稳定的后续处理方便坏处是你要多写一点“Schema定义”。Midscene的extract则完全靠自然语言描述灵活性高但某些情况下返回格式可能不稳定需要自己做清洗和校验。4.3 两者都绕不开的关键配置参数不管用哪个工具下面这几个参数在实际项目中都要仔细调模型选择与TemperatureMidscene和Stagehand都支持配置不同的模型。大模型能力强如GPT-4o错误率低但速度和成本都会上升。Temperature建议设低0到0.2文档里常建议0因为自动化任务需要确定性和精确性不需要创意。实际操作中我还喜欢给调用设置超时与重试次数。Midscene手动在agent外层包个重试逻辑即可Stagehand内置了act的自动重试但默认值在弱网下可能不够需要调大。超时策略Stagehand里act方法有超时参数默认60秒。实测中复杂页面比如带有多个iframe的页面容易超时建议调到120秒以上。Midscene的每一步操作超时也可以配置如果不配置在慢模型或大页面下会频繁报错。本地模型还是云端API两个工具官方都推荐云端模型但如果涉及数据合规、内网环境、隐私要求你可能会希望接本地模型。Midscene对本地部署的支持在持续完善Stagehand由于定位在“可在内部环境集成”部署灵活性更强。4.4 什么时候“半自动”——混用自然语言与精确控制在实际项目里我很少把整个流程全交给AI。更稳的做法是核心步骤用精确代码控制边缘步骤用自然语言兜底。举个例子还是那个电商流程。“点击搜索按钮”这种按钮的类名可能长期不变直接写CSS选择器几毫秒完成且零成本“筛选茶轴”这种动态渲染的选项定位符很容易因为页面改版而失效于是交给AI去理解。这样大部分步数走的是精确控制只有少量“人话”行为走模型既稳又快。Midscene也支持这种混用模式你可以手动标注哪些步骤需要agent介入哪些直接用Playwright原生API控制。不过在混用体验上Stagehand更自然——因为它本身就是从Playwright扩展出来的你可以在代码里随意切换。这个混用思路适用于所有想上AI的自动化项目属于我的首要建议。5. 适用场景画像什么项目选哪个5.1 选Midscene的场景Midscene适合以下几类项目原型验证和概念Demo。比如你需要快速证明“AI能不能自动完成某某流程”或者领导让你三天内做一个自动化演示。用Midscene一小时就能跑通一条完整流程。不需要写一堆Playwright代码也不需要维护选择器核心价值在于“快速看到效果”。智能化UI回归测试。传统UI回归测试最大的痛点是页面经常改版每改一次样式选择器就要跟着改一遍。Midscene完全不依赖CSS选择器模型直接“看”页面页面上按钮换了位置、改了颜色、动了文案都不影响它找到目标元素。对于高频迭代的UI测试这个特性非常值钱。轻量级RPA工具替代。以前要做一些内部系统的自动化操作你可能需要专门买一套RPA产品成本高、部署重。用Midscene只需要一个能跑Node.js的环境写几十行代码就能实现类似效果。临时性数据采集。有些网站的数据采集需求是一次性的比如竞品价格调研、商品信息抓取。为了临时需求去写精细选择器性价比太低。用Midscene直接发指令提取就行。5.2 选Stagehand的场景Stagehand更适合以下场景生产级长期维护的自动化框架。如果你的自动化脚本要跑几个月、甚至几年稳定性是第一位的。Stagehand保留了Playwright的完整能力你可以写严格的等待条件、错误处理、重试策略把项目做得非常健壮。纯自然语言的自动化脚本一旦关键的页面行为变了调起来很费劲。需要精细断言的测试项目。如果你的脚本不仅要“操作页面”还要“验证页面是否符合预期”Stagehand更合适。你可以用expect进行断言用Playwright的assertion框架检查元素状态、URL变化、接口请求等。Midscene里虽然也能做断言但要么靠模型判断要么混入原生代码不如Stagehand顺手。已有Playwright/Selenium代码库的升级。最省事的AI落地方式不是推翻重来而是局部替换。如果你已经有一套Playwright脚本只是某些环节不稳定那么把Stagehand引进来把那些最脆弱的步骤改成act/extract改造范围小、风险低、见效快。需要对过程有完整日志与审计的场景。金融、电商等行业的自动化通常需要保留完整操作记录。Stagehand底层是Playwright能天然使用Playwright的Trace Viewer记录每一步操作的DOM快照、截图、网络请求审计能力非常完整。5.3 决策清单直接照着勾如果你还在纠结直接对照下面几条团队里有熟练的自动化测试工程师吗有选Stagehand没有选Midscene。脚本需要长期维护吗需要选Stagehand一次性任务Midscene。页面是否经常改版经常改版Midscene省心页面稳定Stagehand更高效。对操作速度和执行成本敏感吗敏感Stagehand更划算不敏感Midscene更省人力。流程中需要处理大量动态、非结构化信息吗需要Midscene更强信息相对固定Stagehand更稳。6. 常见问题与排查技巧实录6.1 我踩过的那些坑Midscene篇模型“多管闲事”。Midscene有时候会在执行完当前指令后额外做一些你没要求的操作。比如你说“输入关键词并搜索”它可能顺手把筛选条件也点了。解决办法是在指令里写清楚“只执行XX不要做其他操作”或者把复杂目标拆成多个简单指令一步一说。截图模糊导致误判。有些页面为了性能用了低分辨率图片模型截图判断时可能看不清按钮文字导致选错元素。我的做法是在启动浏览器时把viewport设置大一点截图分辨率更清晰。extract返回结果不稳定。自然语言描述提取规则模型可能偶尔返回额外字段或改字段名。我后来固定做法是extract之后在本地做一次严格的Schema校验不符合格式就重新调用一次模型。虽然浪费一次调用成本但能保证数据质量。内置DOM信息过重。Midscene会把可见区域的DOM信息一起发给模型如果页面非常复杂例如后台管理系统的复杂表单页面DOM序列化后的体积可能巨大拖慢速度也增加费用。解决办法是尽量限定操作区域缩小模型感知范围。6.2 我踩过的那些坑Stagehand篇本地策略偶尔不如预期。Stagehand的extract优先会用A11y树做提取但有些复杂内容比如canvas绘制的图表、图片中的文字A11y树里根本没有提取出来就是空的。这时候需要显式启用模型提取或者混合使用两种策略。act指令在iframe里失效。天然要处理跨域iframe页面时Playwright原生操作需要切换到iframe上下文。Stagehand的act有时会“找不到”iframe里的元素。我的绕法是在act指令里加上iframe的描述比如“在右侧的‘结果预览’区域中点击第一行”让模型有更多上下文去定位。多模型切换时行为不一致。我在项目里试过把模型从GPT-4o换成其他OpenAI兼容模型同一个Page、同一句指令两个模型的行为经常不一样。后来我固定了几条“标准指令模板”每个模型跑一遍把表现稳定的记录下来。团队里如果要换模型先跑一遍模板验证。动效与异步请求。页面有大量异步加载时模型在“等待”上的判断并不可靠。之前遇到过模型执行“点击搜索”后立刻说“搜索完成”结果数据还在加载紧接着下一步提取到了空数据。推荐手动增加等待页面加载稳定后再开始下一步。6.3 问题排查速查表症状排查方向推荐处理方式AI点错元素检查截图是否清晰、页面是否有浮层遮挡调整viewport在指令里排除浮动层提取返回空数据内容是否在iframe或canvas中切换提取策略改用模型提取操作速度慢页面DOM过大或模型响应慢缩小操作范围换更快模型偶尔多执行步骤指令不够精确拆成单步指令增加“只做XX”约束页面改版后失灵模型对新布局理解不足更新指令描述必要时回归到精确选择器API超时调用量太大或网络不稳加重试机制调大超时参数6.4 一个独家经验用“混合提示词”提升稳定性最后分享一个我后来一直在用的小技巧。无论Midscene还是Stagehand在写自然语言指令时我建议按这个模板来组织“在[区域]做[动作]目标是[结果]。如果[异常条件]请[替代处理]。”举个例子不这样写“搜索无线耳机”。而是这样写“在页面中央的搜索框中输入‘无线耳机’然后点击搜索按钮。如果搜索按钮被广告浮层遮挡请先关闭浮层再点击。”模型拿到这种带异常兜底的指令执行成功率会明显提升。因为模型不只是“按指令执行”它有了一定的问题处理空间。这个小细节是我跑了几百次自动化流程后总结出来的最有效率的提升手段。7. 最后的一点个人体会Midscene和Stagehand我试过的版本都还在快速迭代今天写的API细节可能过几个月就变了但两者背后“自然语言驱动浏览器”的大方向是确定的。我个人的做法是Midscene留着做“快速验证”和“一次性任务”Stagehand用在做正式项目的自动化框架里。它们不是二选一的对手更像是工具箱里的两把不同用途的螺丝刀。如果你刚入门我建议两个都装起来各自跑一个5分钟的小Demo亲手感受一下“一句话控制浏览器”和“精准代码AI兜底”的区别。实际用过一次比你读十篇对比文章都有用。选哪个不重要重要的是找到适合你自己项目节奏的那一个。