playwright还有公司在用吗

如果你之前做过一图一测试，那你肯定听过 playwrite， 微软就与它开发了一个 mcp playwrite mcp github 上十大数已经达到了三十一 k。 简单说，它 让 ai 可以 直接操作你的浏览器，不是截图识别，是真的点真的填，真的验证，安装超简单，只要在科室的 mcp 配置里面加上 playwrite 的 配置就搞定了。我给你看一个真实的例子，我直接让 ai 帮我打开当前项目首页， 检查一下所有的链接是不是都正常跳转。为了不要让蝙蝠使用自带的工具，我让他直接用 play right m c p。 然后你可以看到 ai 自己打开了浏览器，并且一个链接的一个链接的去点 去验证，最后给你出一份完整的报告。整个过程我一行代码都没写，那他为什么这么快这么准呢？因为 play right m c p。 不是 像你想的那样，给 ai 看截图 用的是 accessibility tree， 这是个什么玩意呢？可以看到 gpt 给它的解释是跟 don tree 不 一样，它会过滤掉纯视觉无与义的节点。简单说也就是页面的结构化数据， ai 直接读懂页面的结构，不需要去看，所以不依赖任何视觉模型， 能做到又快又稳。那这东西能干什么呢？这可就太多了，最常用的就是自动化测试了，你用自然语言描述测试用力， ai 会帮你执行，帮你断言以及帮你出最终的报告。第二种是竞品分析，也就是说你可以让 ai 定期去竞品网站抓价格，抓功能，更新 后自动整理成表格来进行分析。第三个就是表达自动填写，这个在一些中后台系统的应用中非常重要，因为这里的成本是非常高的，运营或业务人员日常工作中需要频繁的去填写一些重复的注册啊，提交后台录入等等，那么现在就可以结合 ai 一 次性搞定，非常的提效。另一个是网页数据采集， 老总可能都不用写了，你告诉 ai 你 要什么数据，让他自己去对应的网页上去找。所以如果你是做前端开发，一推一测试，或者经常需要手动操作网页的岗位， play right m c p 必须装它能省下你大量重复劳动的时间，赶紧去试试吧！

大家好，让我来向你介绍一下 playrite c l i 是 什么。它是 playrite 家族中的一款新工具。在本视频中，我们将讨论 playrite c l i 是 什么，并将它与 m c p 进行对比，展示一些演示，讲解令牌效率和一些功能。 希望你能更清楚地了解未来应该使用哪一个。让我先从演示开始。这次 playrite c l i 功能的一个演示，我现在在一个空文件夹 demo c l i 里开始操作。 接下来我要全局安装 playrite c l i， 这意味着它将在所有位置都可用。我做的第一件事是初设化我的工作区。我输入 playrite c l i install， 这会创建一个名为 playrite 的 空文件夹。就是这样，我们用这个方法来区分你词盘上的不同工作区。 每个工作区都会有自己要使用的一套浏览器。关于这一点，我们稍后会详细介绍，但我还想在这个工作区里安装一些技能。我输入 install skills， 他 会在我的工作区安装一堆 cloud 技能。当我启动 cloud 并给他分配一个任务， 我要让它打开 playwrite dev。 这是一个网页，搜索 locators 这个词，并检查每种语言的文档是否都可用。这里所说的语言是指它支持 javascript， python， java 和 dapplet。 我 还让它为每种语言的文档都截一张屏。 那么让我们看看它是怎么做的。我们现在看到的是一个十六倍速的延时画面，展示了刚才发生的过程。刚才发生的事情其实就是 cloud 在 用 c l i 工具和浏览器进行对话，让我们看看结果出来了没有。 我们来看一下上下文，这样可以看到我们已经消耗了多少 tokens， 但我们不会在这里停留太久。接下来我们将用 mcp 版本来完成同样的任务。让我开始吧。 cloud 这里 我看到 mcp 服务器已经安装， play red mcp 也已经安装，这个文件夹里没有安装任何技能，所以我接下来要做的就是给他分配完全相同的任务。 同样，第十六倍速快进任务完成了，我们也来打开这里的上下文统计，看看我们消耗了多少 tokens。 好 的，所以我们在这里看到的是我们总共用了十一万四千个 tokens， 对 于这个操作来说，这个消耗是相当高的。我们来和 cli 的 结果对比一下， c r i 只用了二万六千八百个 tokens， 所以 我们在演示中看到 m c p 消耗了更多的上下文。但这是为什么呢？让我们深入探究一下，这就是 m c p 所做的事情。所以我们来看看这两个雕用。首先，它尝试导航到一个页面， 而 playrite dev 是 一个 docker source 页面，这个页面相当大，内容很多，有很多 dom 控件，脚本等等。 尽管 playwrite msp 在 指传递可访问性快照给 llm 方面非常高效，但他仍然回复了全部内容。这些内容都进入了上下文窗口， 我们可以看到这个结果已经超过了最大临牌数。最后他截取了一张屏幕截图，但当 mcp 截屏时，是 llm 要求他这么做的，所以我们把所有这些字节都回复给了 llm 本身。同样，图片的 token 也进入了上下文。 而在这种情况下，这并不是我们的目标，我们想要的只是截取一张屏幕截图并保存在此盘上。让我们来对比一下 c r i 的 做法。 c r i 说我想去一个位置，然后他甚至没有补获快照，也没有从此盘读取由这次调用生成的快照文件，而是直接截取了屏幕并保存了这个文件。结果，他保存了上下文，这些 tokens 都没有进入上下文。因为 l m 实际上并不需要他们， 所以 c i 的 做法是，他会把所有输出的数据都保存到文件中，然后你的编码代理会决定是否需要将这些数据发送给 l l m。 我 们来谈谈功能。我们已经看到了 m c p 是 如何工作的，但你会发现 m c p 只用了几十个命令。这并不是因为 我们并不是没有这些命令。我们确实有这些命令。事实上，所有 c l i 的 功能在 m c p 中也都可以使用，只是我们默认没有起用它们，因为它们会消耗上下文。另一方面，在 c l i 上我们没有这种限制，所以我们可以开放所有这些命令，甚至更多。好了，我们已经看过了 token 的 使用情况，也讨论了功能。 那看起来这似乎是显而易见的选择，应该使用 c l i， 对 吧？好吧，让我们稍微聊聊这个问题。 c l i 是 一款新工具，当它作为编码代理的一部分使用时，它的优势就会体现出来。 而编码代理可以是你的云端代码 github compile， 或者任何能够编辑文件访问你的工作区的代理。在这种场景下，我们可以非常高效。 你可以捕捉这些快照，并将它们保存到词盘上。将这些截图保存到词盘上，然后让编码代理决定是要完整读取它们，还是要将全部内容发送给 l l m。 这样一来就能实现偷看的高效利用。所以， c l i 需要配合编码代理才能高效运行。除此之外，它是基于技能的， 你可以将关于 playwrite 和你的场景的知识添加到这些技能中，因此它可以与其他基于技能的工具互操作。它默认也是无头模式，因为我们假设你会在编码代理中运行许多后台代理。另一方面， mcp 可以 与任何通用代理合作， 它是一个严格的标准工具，知道该期待什么，如何调用这些 mcp 工具以及结果会是什么。但在这种情况下，一切都掌握在 lm 手中， 因此所有的回复很可能都会返回到 l o m， 并且有可能会使其上下文超载。你在 m c p 中仍然可以拥有多个浏览器，这没有问题。而且 m c p 的 效率实际上是可以配置的。你可以允许或禁止这些工具，并根据需要进行选择。 在这方面，他稍微需要更多手动操作。此外，从历史上看， m c p 默认是被添加的。所以总结一下，如果你在使用编码代理，如果你的任务是编码测试，你再用 close gitop compile， 你 可能更想用 c r i。 另一方面， 如果你正在创建一个能够执行特定任务的代理循环，用于你的场景， m c p 依然是首选，大致就是这些内容。祝你测试顺利。

哈喽，今天给大家分享一个微软出品的这个浏览器自动化的一个程序啊，这个程序的话感觉还是挺厉害的，它相当于是实时的启动一个浏览器，然后包括了谷歌的 chrome， 还有火狐，还有个 webkit 啊， 然后这些浏览器的话，你都是可以直接在后台运行，然后让他帮你打开操作的。为什么要说他厉害呢？因为他跟之前的那种爬虫框架不一样啊，他是真实的去模拟 你在浏览器内的一个操作，然后去读取浏览器这个页面上面的所有数据，然后去决定下一步的这个动作啊，就是结合 ai 的 话，你随便打开一个网站，就比如说一些电商平台的，你直接打开了，打开以后你直接让你的 a 键，比如说你是 你说帮我安装这个 play word， 然后你现在进入这个电商网站，帮我查询某些衣服或者饰品或者什么东西的一个销量，包括它的一个价格，帮我把前十的列表都给我列出去，列出来也就输入这么一个简单的指令，然后你过一会你再回来看你的文件夹里面， 他就把这些内容都给你列出来了，有些需要验证的情况，可能需要需要你手动的去帮他过一下验证，其他的他基本上都能帮你完成，特别厉害了啊， 然后这个能帮你做什么事？那真的是太多了，就比如说你想写一个程序的时候，对吧？你现在有些后端数据读不到， 你把它跑一下子，你然后让 ai 帮你找这个网页当中，比如说这个价格搜索这个标签到底是在哪？然后如果我用后端去调用的话，应该使用什么数据，它全部都能帮你跑出来。 然后你如果是想要采集某些网站的一些热点啊，对吧？你还是同样的，你第一次跑的时候，你用 ai 加上这个 play white 帮你把整个流程跑通，整个流程跑通以后，然后你把它写成一个固定化的程序，后期就不需要用 ai， 用你的 token 你 就可以完整的把这个东西给跑通。 我也十指也是接触了比较多的一个项目者，对吧？他搞这些东西的时候，他不去选大众化的市场，不去搞什么 ai 漫剧啊，不去搞什么 ai 小 说啊，去做什么中转站呢？他就 利用这一些工具加上 ai 的 一个优势，帮别人定制化一些行业的热点新闻，或者是其他的一些商业上需要的一些数量比较多的时候，不方便人去找的时候，帮别人定制化这种工具也做到了一些成绩啊。 然后十字这一边的话，目前也是接触到了一些筹融资的渠道，就是如果你有更好的 ai 项目的话，你可以联系十字，十字这边可以给你提供渠道去对接，好吧？然后感谢您的观看，我们下期再见，拜拜。

大家好，想不想让你的 ai 助手直接上手操作浏览器？那这两工具你肯定会碰到，一个是微软的 playwrite， 另一个是谷歌的 chromev tools， 今天咱们就来把它们俩掰开了，揉碎了讲清楚，帮你做出最正确的选择。 你的 ai 编程助手他真的超厉害，能理解，生成重构代码什么都行，但问题是，他就像被关在一个透明的盒子里，只能纸上谈兵。他没法真的去跟网页互动，比如说点个按钮，填个表单，或者去测试一个线上跑着的网站， 它能看，但它摸不着。那怎么把这个盒子打开呢？答案就是 m c p， 也就是模型上下文协议，你可以把它想象成一把万能钥匙， 它给 ai 模型提供了一个标准的安全的接口，让 ai 能够连上并且操作像浏览器这样的外部工具。这一下 ai 就 真的有了手和脚能干活了。 好了，那我们今天就顺着这个思路聊下去，先看看 ai 为什么被困住了，再聊聊 mcp 是 怎么解锁浏览器的。 然后就是咱们的两位主角， player right 和 devtools， 我 们会深入剖析它们各自的特长，最后再告诉你怎么搭配它们，打造你自己的终极 ai 工具箱。 行，咱们找到了解锁浏览器的钥匙，但马上就遇到了一个新问题，咱们手上有两把功能都超强的钥匙，一把微软的，一把谷歌的， 这就不只是个技术选择了，对吧？这其实是个策略问题，这个选择到底有多重要？这么说吧，有句话讲的特别好，高达百分之九十的人都在错误的使用这两个工具，这不是因为工具本身不好，而是因为场景用错了。 咱们今天就是要解决这个核心问题，保证你成为那懂行的百分之十。好，咱们先来看看第一位选手，微软的 play right mcp。 你 就把它想象成一个特别靠谱的实干家，一个天生就是为了自动化而生的巨头。 这张图啊，一下子就说清楚了 play right 最核心的理念，你看左边，这是 ai 平时看到的一堆乱七八糟的 html 代码，看的头都大了。 那 playwrite 的 思路呢？他说咱们得像个普通人一样看网页，所以他给 ai 看的是右边这个，一个超级简化版的无障碍数，把所有代码噪音都过滤掉，只留下关键信息。这儿有个按钮叫提交，你能点 这么一简化，好处可就太大了，它能把 ai 消耗的 token 直接砍掉，最多百分之八十。 这意味着你的 ai 操作不仅便宜了，而且因为信号强，噪音少，反应也更快更准了。除了省钱， playrite 本身的设计就非常厉害，首先它跨浏览器，你写一套代码在 chrome、 firefox、 safari 上都能跑。 还有啊，它有个自动等待机制， ai 只要下命令就行， play right 会自己等那个按钮准备好了再点可靠，秀一下就上去了。最后，它看的是寓意，就算前端把代码改了，只要那个东西还是登录按钮，它就能找到，特别稳。 好了，说完了这个实干家 play right， 我 们再来看看另一位角色，谷歌的 chromevtools mcp。 你可以把它想成一个深度侦探，专门就是为了检查和诊断问题而生的。 devtools 有 个真正的杀手锏，这也是它跟 playwrite 最大的不同，就是它可以直接连上你现在正在用的那个 chrome 浏览器。 你想象这意味着什么？你所有的登录状态、 cookies、 绘画数据，全都能直接用 ai， 根本不需要重新登录。这在调试那些需要复杂登录才能进的网站时，简直是神奇。 而且啊，连起来也特别简单，你就三步，第一，在地址栏里输个 chrome 斜杠 inspect。 第二，点开那个远程调试的官框儿。最后呢，启动 m c p 服务的时候，加个杠 also connect 参数， 搞定你的 ai， 就 能接管你当前的浏览器了。 devtools 的 核心优势就在于一个字儿，深， 它给 ai 看的是整个浏览器的内部运行时状态，就等于把整个 chrome 开发者工具面板全都交给了 ai。 ai 可以 看网络请求的瀑布图、 js 的 调用栈、性能轨迹等等。当然啦，它的应用范围也仅限于 chrome em 内核的浏览器。 好，现在两位专家我们都认识了，那最关键的部分来了，到底什么时候该用？谁怎么才能用对地方？ 这张表总结的特别清楚，你看 play right， 它的核心就是自动化和测试，所有主流浏览器都支持像个普通用户一样看页面儿， 而 devtools 呢，它的核心是调试和检查，只支持 chrome 内核的，像个开发者一样看页面。所以你看，一个适合跑测试抓数据，另一个呢，适合分析性能查网络问题。 咱们来看个具体的场景啊，假如你的任务是写一个自动化测试脚本，并且要求它必须要在 chrome、 firefox 和 safari 上都能稳定运行， 那不用想了，这绝对是 playrite 的 活，它的跨甭谁成能力和为自动化而生的稳定性，就是为这个场景量身定做的。好。换个场景，你正在开发一个网站，已经手动登录了账号， 现在你发现有个网络请求老是失败，需要深入排查它的请求头响应，还有时间线。 那这时候就该 devtools 上场了，你可以让 ai 连上你当前的浏览器，直接用你的登录状态，然后深入到网络面板里，把问题根源给找出来。 所以，聊到这儿，你可能觉得这是个二选一的问题。但实际上啊，真正的高手早就打破这种思维了，他们的目标是打造一个终极 ai 工具箱。 我特别喜欢这个比喻， playrite 就 像你天天都用的螺丝刀，可靠通用，解决大部分日常自动化任务。而 daptos 呢，就像那个精密的万用表，虽然不常拿出来，但真要诊断什么电路问题的时候，没它还真不行。 咱们再总结一下他们的分工， play right 是 用来干活的，执行所有常规的交互操作，比如挠倒、点击、填表单、抓数据。而 deftools 呢，是用来诊断的，当你遇到性能瓶颈、网络请求失败，或者需要看控制台里的详细错误时，就该它上场了。 所以啊，我给你一个特别简单的行动指南，百分之九十五的情况下，你就默认用 play right， 准没错，它稳定、省钱、靠谱。等到真遇上那五百分之疑难杂症了，再请出 devtools 这位专家来做深度诊断 好了。那么现在你已经知道怎么给你的 ai 助手配上最强的眼睛和手了，那真正的问题就来了，当你的 ai 真的 突破了，那个透明的盒子能跟真实世界互动了，你打算和它一起去创造点什么呢？这后面的想象空间可就太大了。

今天是二零二六年的四月十一号，那如果说想了解浏览器自动化，基本上你就得去要了解 cdp 到底是什么， brother use 和 playret 到底是什么关系， brother mcp 又是干嘛呢？ 如果我想让 ai 来操作我的浏览器，比如自动发布视频至各大平台，过程中遇到一些登录态的问题 该怎么解决？然后页面结构中可能会遇到沙粒 dom， 也就是影子 dom 这种普通话自动工具，抓不到他又点不动的页面结构，哎，该怎么去处理？ 我今天正好做一个多平台同步发布视频的自动化 skill， 小 红书和抖音整体上还算顺利，把发布的视频流这发布视频的整个流程给拆清楚之后，然后让他用 bug 去执行，基本上都能够跑通跑起来。 但是真正卡住的是视频号，因为视频号后台有一部分页面结构是用了无界的沙林 dum 结构，你从视觉上看，哎，那个是发表视频，他就在那里，但是很多基于 dum 的 自动化工具他就是拿不到，或者说特别的不稳定。 因为之前做过一些 ipa 相关的项目，知道自己也有一道基于 ai 多模态的方案，是 media cine， 后来就换成了他。他本质上不是先理解底层的盗墓结构再决定怎么点，而是先去理解整个页面截图里面到底有什么什么元素在什么位置，什么按钮在什么位置。知道位置后，接下来他还是利用底层操作浏览器的工具去执行。 其实整个过程我发现其实里面还有很多概念和术语，然后就想着把这些概念从底层的 domain 到最上层的一些框架和应用，把它给整理梳理一下，然后也分享给大家，希望对大家有用吧。 其实最核心的底层还是 chromium， 你 可以把 chromium 理解成一个浏览器的底座。谷歌的 chromium 是 基于它做出来的 ad 级和 brion， 这些浏览器本质上也都是在这个体系里。所以当我们说浏览器做动画的时候，很多时候我们真正操作的并不是整个网页本身，而是 chromin 浏览器对外爆出了一套能力，这套能力最核心的一个东西就是 c d p， 它全称叫 chrome d v taurus protex， 你 可以把它理解成浏览器对外开放的一套远程操控协议， 就是你要操作我的浏览器，我给你开放能力，然后你来操作，然后通过这套协议，外部的程序就可以 让浏览器做很多事情了。比如打开一个页面，执行 js 脚本，读取 dom， 监听网络请求，获取控制台的日期截图，输入文本，点击元素，甚至接管 tab 和 tab 里的生，整个生命周期 都可以。那有了这个开放的接口协议之后，下一步自然就是得有人把它更方便的给用起来。 于是就有了像 c d p 柚子啊这种东西。你可以把 c d p 柚子理解成一个更贴近 c d p 协议本身的客户端的一个封装啊。这是底层协议，协议完了之后，它有一层客户端的封装， 它负责呢，建立连接，发送命令，接收事件，管理他该着和筛选。这个层级已经比自己要手写协议要好了很多了，但是呢，它还是偏底层的， 直接拿它去写完整的整个业务流程，细节会很多，操作起来也很麻烦，比较重。然后呢，这个时候就有了在上一层的 popular 和 playret 这种更高层的浏览器自动化框架 啊。 popular 更早一些，和 chrome、 chrome 这条线的关系也更近，所以很多人第一次接触浏览器自动化就是从它开始。 playware 呢，其实会更完整一点，等待机制，多上下文，多标签这些能力也更加的系统。所以如果今年是从零开始做一个稳定的众动化项目，我自己的形象还是 playware， 你 可以粗暴理解成它们都是比 c d p 柚子更高一层的工程化封装 框架，只不过在成熟度和使用体验上各自重新不太一样。那 brad 的 柚子又是什么呢？ lebro 柚子，它是不是要替代 play， 也不是要替代 cdp？ 它更像是在上面一层包了一层，专门为了 ai 和 a 进程这种使用方式设计出了一套更对 ai 更加友好的 c o i 命令行。 它想解决的问题不是浏览器能不能点，而是 ai 该怎么更顺手的去操作浏览器。 你会看到它强调的就是 open 啊， state 啊， click 啊， input upload 啊， script script 啊 这些动作，本质上是在把这些浏览器的能力整理成一组更适合智能体逐步调用的命令。这也是为什么用 brother 柚子去做小红书、抖音这类平台上传行政其实会更加的顺手。 ai 先 open 一个页面，然后看 c 列的元素，然后再刻立一个上传再音符的标题和内容，最后 screenshot 给人确认。整个流程非常符合 a 阶的主播执行的方式，而且 它在处理身份问题上也很实用。如果你不想去处理这个登录的操作，那可以基于它的 profile 这个命令去启动。它会去找系统里安装好的 chrome， 然后读取你本机的用户数据和 profile 信息， 把对应的 pdf 复制到一个临时的目录里，然后再拉起一个新的科目进程来跑速动画。也就是说，这个时候打开的科目是携带你的身份信息的，包括你之前登录的一些网站的一些库克数据，库克数据等等都会携带过来。 然后呢，这个 profile 里已经沉淀下来的是一些库克呀，本地存储啊和登了态登录态的一些数据。当然这也不是绝对的百分之百。如果说某个平台 特别依赖设备指纹，或者说做了更严格的封控交易，或者你的登录信息没有真正持久化到 profile profile 里，那他还是有可能要求你重新登录的。但大部分人普通的后台基本上就够用了，这条路就是能走通的。 那有了 browser use 和 play it， 基本上大部分场景都可以做到了。但是像视频号这种后台采用的 shardendown browser use 还是会出问题，总是拿不到对应的节点去操作， 这个时候你可能就得换另外一条线路去实现了啊。这也就是 mini c e 这种基于视觉的驱动方案，它是自己出的一款基于 ai 视觉驱动的 ui 自动化框架。它的核心思路不是先理解到再决定怎么点，而是 通过截图的方式，然后去分析每一个这个元素，它具体是在什么样的一个位置，拿到对应的位置之后，然后再去控制底层的命令指令去操作。 嗯，像点击发表视频按钮啊，描述输入这种这种话指令啊，就不必过分依赖底层的 dom 结构了，而是基于位置信息。 所以对于这种影子 dom 呢，结构 mid sight 会比纯 dom 做动画会更加的 靠谱一些。但是呢，它也有它的缺点，就是第一，因为它依赖于大模型的多模态 啊，去看看图，所以他很慢，因为中间多了一层视觉理解。第二呢，就是有模型的成本在里面，他不像纯到我们做动画那样成本会更低一点。然后呢，他也有稳定性的问题，有时候计算也会不准。 呃，所以他更多的场景像是一个补位。 嗯，前面说的这些，不管是 brother user 还是 playwrite 或者是 mid scene， 本质上大多都还是重新拉起一个 浏览器，或者是唤醒一个功能的进程，或者重新跑一个做动画的进程吧。呃，但是如果说我现在就想利用我自己本身装的这个浏览器，我就想让 ai 直接看到我当前浏览器正在发生什么，并且顺着这个上下文去继续操作， 那有没有办法？其实也有，就是官方最近出的一个叫 brother m c p， 它可以基于你当前正在使用的浏览器，把页面内容、盗版结构和操作的能力更加友好地暴露给 ai。 这样一来， ai 不 需要每次都重新打开一个浏览器，也不需要把整个浏览从头到尾再跑一遍，而是基于你当前打开的浏览器的一个状态， 再继续往下操作。那对于一些日常的携带码呀，排查问题，或者是调试前端界面，其实会非常的方便。 当然了， prada m c p 现在还不是很完美，对于一些看内容啊，或者是一些基本的输入点击操作是够用了，但是如果说涉及到像一些上传呐，或者是这种比较复杂的，还是场景不太够， 我今天试了一下，视频文件的上传还是不行。嗯，所以整个东西把这些概念术语连起来之后，你会发现它们之间是基于一层一层一层的 长出来的。最底层是 qq 这样的浏览器的底座，然后它对外暴露的核心能力是 cdp， 又有了像 cdp 柚子这样的底层公众化工装。 然后再往上就是 public 和 play 这种更适合开发者写自动化逻辑的框架，再往上才轮到 brotherhood 这种面向智能体工作流的风霜。而当当我们这条路不够用了， 又会分出 medium 这种视觉路线，或者 brother m c p 这种更贴近当前浏览器上下文的路线，去补补其不同方向的夺命。 以前很多浏览器能力是给人点的，是给开发者调试的，现在越来越多的能力直接为 ai 而准备的，或者至少是在快速变得更适合 ai 使用。好，今天的视频就到这里，明天见，拜拜。

欢迎观看 hamis agent 加 playright ai 驱动浏览器自动化实战教程！为什么要 ai 驱动浏览器？重复性的操作非常多，耗时费力，让人头疼，人工操作容易出错，效率很低，而且需要七成二十四小时监控，根本无法执手。 整体架构分为双层， ai 决策层，负责分析和规划浏览器控制层由 playwrite 驱动， chromium 浏览器实际执行操作形成闭环， ai 决策执行反馈不断循环环境。准备很简单，确认安装了 node js 十八以上版本，以及 python 三和 playwrite 一行命令，安装 peep 三 install playrite， 然后运行 playrite install 来安装 chromium 浏览器。安装 playrite 非常简单， peep 三 install playrite， 然后 playrite install chromium 来安装浏览器。 国内用户可以使用加速镜像，安装完成后即可使用，无需复杂配置。第一种调用方式是 terminal 命令行模式，适合快速验证命令。 playwrite screenshot url pass， 适合单次操作和测试，快速返回结构化的页面快照。第二种方式是 execute code， 在 python 脚本中内嵌运行， 支持 headless 模式启动。 chromium 支持复杂自动化流程，与 ai 对 话无缝集成，实现智能控制模式。一是 ai 分 析快照决策页面加载后自动提取页面结构和内容， ai 分 析页面语义，然后 ai 决定下一步操作是什么， 循环执行，直到任务完成模式二是多轮对话控制， ai 先规划出一系列操作系列， playwrite 依次执行每一步，每步结果都返回给 ai 判断，适合复杂多步骤的任务模式。三是 ai 自主探索，没有固定流程， ai 根据页面内容自主判断下一步， 每次提取页面后，判断哪个链接值得点击，通过深度控制防止无限循环。实战技巧，语义化提取页面结构，带重视机制的 ai 点击提高稳定性。 每次操作后截图记录状态，拦截无关图片，可以大幅加速页面加载。跨平台连接 windows 浏览器很简单， windows 上开启调试端口九千两百二十二 wsl， 通过 cdp 协议连接，可以附用已登录的浏览器环境操控任意网页应用。总结一下 ai 决策，配合 playright 执行页面状态返回，给 ai 进行下一轮决策。 terminal 命令行模式做快速验证， execute code 模式做复杂自动化任务。感谢观看，欢迎关注交流 ai 自动化技术！

头盔消耗直接降百分之九十！强烈建议给可乐扣子装上 agentbrad 这个工具，它不仅能让 ai 更快的操作你的浏览器，而且头盔消耗比 prada 低百分之九十。真正的降本增效神器 agentbrad 是 warsoft 团队用 rap 开发的 c r i 版本的 prad， 但它不是对 prad 的 进行简单的工作，而是做了大量的优化，可以让可乐以命令行的形式玩转浏览器，比如打开网页，控制鼠标移动，点击浏览器第八个，甚至是对页面进行截图分析。 知识的命令非常的丰富，可以让 ai 完成非常复杂的浏览器自动化任务。安装方法也很简单，在终端执行两条命令，或者直接把命令丢为可拉倒来安装，然后就能用了。安装命令我放到了评论区，需要的同学咨询推荐的使用场景。 ai a 镜的自动化测试自动化表单，填写网页内容，抓取页面系统优化，点赞关注，每天获取一个新知识！

今天想分享 playwrite， 最近看 ai 的 一些工具，很多的 ui 自动化脚本， ai 生成的时候都是选择的 playwrite， 如果你没有给它指定语言的话，它自动默认的去选的都是 playwrite。 那 大胆的预测一下， playwrite 它的市场占比会越来越高。我们今天先看一下 playwrite 大 概是一个什么样子的东西， 它跟协议有什么区别。 playrite 的 官网是这个，然后它是一个外部自动化的测试框架，它可以支持多个语言，并且它可以跨平台， windows、 nooks 都可以，而且它是支持多个浏览器的，就是它的官网的一个页面。 然后 playrite 的 原理是什么呢？它是编程语言去调用 playrite 库，然后调用的是它的这个工具，然后通过 chrome 的 一个 dvtoos 协议去调用的浏览器。 它跟 cyanum 的 比较的话，就是说在语言支持方面， playrite 只支持这几种语言， cyanum 呢，支持几乎所有的语言。在浏览器的支持方面， playrite 它是支持这几种浏览器的，而 cyanum 支持几乎所有。 执行速度上， playrite 要快一些， cyanum 就 稍微慢点。自动等待方面， playrite 它是有一个内置的智能等待，而 cyanum 呢，它是需要显示等待的。 这个录制工具方面， playrite 它有一个非常强大的叫抠劲的这个工具，而咸柠檬的 ide 稍微就弱一些，在生态上，现在咸柠檬还是非常成熟，非常丰富的，但是 playrite 它增长的速度会比较快。 那我们再简单的看一下 playwrite 它的四个核心的工具，刚才提到的 call 键，它是一个代码生成器，或者可以你理解为一个录制器，通过录制你的操作来自动的生成测试脚本，然后把它保存为这几种语言， 支持录制时自动的生成智能选择器，它也可以去保存为这种配置 object 的 模式， 然后录制的时候也可以去设置慢动作去查看操作。另外 playwrite inspector 写了这么多的点，比如说检查页面、生成选择器，逐步执行测试，嗯，简单来说的话，其实它就是在你 执行自动化测试脚本的过程中，方便你去看当前页面是哪一个页面，然后点击的哪个按钮，输入的哪些文字，然后点击之后跳转到哪个页面，就是方便做这件事情。 swaver 这个工具跟刚才的区别在于它把我们的记录全部都录制下来了，录制下来了之后，你在后期的时候就可以去看一个回放，这个 ui mode 呢，其实就是刚才这些工具的一个组合， 它弄成了一个 i d e， 一个格式化的一个页面，在这个页面你就可以看到你的代码以及执行的过程，以及看回放这些。

今天和大家来聊一下自动化测试，这是我自己认为非常重要的一期，之前我们聊了很多 skills， hooks 以及工作流的优化，那这些东西呢，都只是框架，它能够帮助你更高效地完成你的项目， 但是你项目最终的质量如何，其实最最最重要的还是你的测试写得好不好。对于网页端呢，我更推荐大家去用 callcode 加 playwrite 的 方式。那么首先先简单的聊一下什么是 playwrite， playwrite 呢，其实是一个端到端的测试框架，也是一种工具，那么它的优势呢，就是它其实是真的帮你打开了一个浏览器，然后通过一些访用户的点击去帮你做了一个完整的测试。 为什么说这个东西很重要呢？因为我们现在是 vcoding 嘛，所以其实我们并没有 对于代码的质量有那么高的掌控权，因为本身代代码也不是我们写的，我们最终希望的呢，是用户到我们这个产品来是可以点击，然后可以正常的运行的。 所以这一套真浏览器的点击模拟测试呢，就能保证说当用户到我们的网页上的时候，他确实是可以跑这些东西确实可以玩我们的游戏的。 呃，第二个呢是 play right， 这个东西你也不用自己去写很多的呃，等待啊之类的东西，它会有一套自己的流程，会等你的界面漏得出来之后才去进行接下来的操作。第三呢就是这个东西是可以回放的， 当你这个测试挂掉的时候呢，其实 playwrite 是 可以帮我们做一个截图的，那当你想要回头去看到底出了什么问题的时候呢，你就可以用这些截图去看当时发生了什么东西，所以非常好溯源。 那当然 playwrite 这个东西它不仅仅是测试啊，我们这一期讲的主要是测试，但实际上它可以帮你做很多别的东西，比如说它可以去帮你抓一些数据，去帮你做一些批量的截图等等。 这些东西呢我们今天就不会展开，主要来看一下一个真实的案例，就是我们怎么用 playwrite 去写这个测试。那今天要讲的案例呢？就是啊，关于一个好吃没声音的故事。那之前几期我其实聊到了，我做了一个 丹卡小镇，里面有一个猫语词典，然后每一个词条呢都是可以播放声音的，但是我在测试的过程中呢，我就发现有一个词条这好吃，这个词条点击了之后是没有声音的，所以我就让 coco 的 去帮我加了这么一个测试，保证说类似的事情不会再发生。 我们先切到这个代码这里看一下，这个呢就是一个完整的 playwrite 的 测试啊，大家不用觉得说这个东西很复杂或者怎么样，因为 call code 全都可以帮你写。今天我们只是过一个例子，简单的让大家了解一下 playwrite 这个东西到底在做什么。那我们就按照它的步骤来。 第一步呢，你可以看到他先进了我的网站，然后呢他就是往下滚，滚到了我这个猫猫转盘的这个界面，然后点击了猫语词典，就进了我对应的游戏。 那么我回到我这个主页，我先登录了，之后呢？呃，我也可以做一模一样的事情，我就是先往下滚，然后可以看到这个地方就是刚刚我们测试中提到的这个小猫的页面，然后他就点了这个猫语词典，然后进入游戏。啊，其实就和这个测试里面是一模一样的。 那么在这个进入游戏之后呢，我们就可以看到他去找到了一个对应的按键，然后找到了这个吃饭时间，然后他找到了好吃这个按键，然后他就去点了一下， 那么一样的，我们就可以到这个吃饭时间这个好吃的页面，然后他就点击播放了一下， 那这个其实就是我这个 playwrite 做的完整的事情了。那你看可以看到这个地方它其实是做了一个呃按键的点击操作，然后之后呢其实它就做了一些分析，然后去保证说我们这个 呃声音是有的，就不是一个空的音频。那我们日常呢也可以去跑这个测试，我可以简单给大家试一下。好，那么在这里呢，我们其实也可以让 carco 的 直接去帮我们跑这个测试。 呃，这个是我输入的一个 prompt 啊，其实就比较简单，当然大家也可以直接用 command line 去跑，是一样的。 好，那么这里 call code 先帮我做了一些设置，然后现在他开始工作了。呃，这个刚刚完全不是我在做，就是我的电脑自己在做这个事情，就是 playwrite 测试。呃，如果大家看的 比较清楚的话，因为因为它比较快，我我不是很确定大家有没有看到，但它做的操作就和我刚刚演示的是一模一样的。那么通过这样一个 playwrite 测试呢，就可以保证说我们整一个 user flow 是 通的，就是用户是可以使用我们这个工具的。 我自己平常做这个的流程呢，是我会先让 call 去根据我的业务需求帮我写一些基础的 playwrite 测试。 然后呢，我会自己手动地去进行一些额外的测试。当我发现有些问题的时候呢，我就会告诉 plato 的 我做了哪些操作，让他帮我把我的操作再写成额外的 plato， 呃，再写成额外的 playwrite 测试，通过这种方式呢，来帮我反复地迭代，然后进行一些 产品的修复，呃，然后做一些质量的保证。那这一期呢，我们就聊到这里，下一期我们会讲一下怎么用 metro 去做一个我们移动端的类似 playwrite 的 自动化测试。

如果你还在手动写测试脚本，那真的太浪费时间了。用 playrite 的 录制功能，也就是 codegen， 你 只需要像平时一样点击页面，它就能自动帮你生成代码，支持 python、 javascript、 java、 c、 shop 等多种语言。而且它会智能推荐最稳定的元素定位方式， 比如 get by run get by text。 脚本不容易因为界面改动而失效。怎么开启录制？最简单的是用 vs code 的 playwrite 扩展，点击 root new 按钮，浏览器和记录面板就会自动打开，你一边操作代码一边生成。或者你也可以用代码 输入 npx playwrite codegen， 加上网址，同样会弹出浏览器和记录窗口。录制过程中，你还可以随时切换语言， 选择浏览器、添加断言，甚至模拟手机设备。比如 iphone 十三，录制完成后，一键复制代码就能直接用了。 更厉害的是，你可以先手动登录一次，把登录状态保存下来，以后录制就不需要重复登录了。总之， trent 的 录制功能不仅能帮你快速生成测试脚本，还是学习如何写渐状自动化代码的好帮手。

今天咱们聊一个很多测试朋友都关心的话题， playrite 为什么比三零年快那么多？其实 playrite 的 性能优势不是靠一个点，而是从底层到上层的全面现代化设计。我们先看一下核心对比，像通信协议 playrite， 用 web socket 长连接， 三零六用 h t t p 请求响应浏览器控制层 playrite 直连浏览器的 dev tools 协议 selenium 要通过 webdriver 协议加浏览器驱动等待机制， play right 内置智能自动等待， selenium 得手动斜显示或隐式等待资源管理 play right 支持浏览器上下文附用 三零幺幺八，每个用力启动全新浏览器网络拦截模拟 play right 原声支持三联宁要依赖外部代理工具。为什么差距这么大？ 三个核心原因。第一个，通信协议 play right 用 web socket 长连接，就像一条始终在线的电话线，指令实时双向传输，单次操作延迟可以控制在两百毫秒以内。 而三里念还是老旧的 h t p 请求响应模式，每次操作都要建立连接，发请求等响应，再关连接，单次延迟往往超过五百毫秒， 一百个操作下来差距非常明显。第二个，去中介化的直连模式 play rate， 通过 web socket 直接连到浏览器的原声调试协议，省掉了中间驱动层。 费里尼奥呢？指令得先发给一个独立的浏览器驱动，比如 chrome driver， 让它翻译一遍再转给浏览器， 多了一道翻译，就多了叙列化、反叙列化和网络延迟。第三个，更智能的自动等待 play right 内置智能等待执行操作前自动轮询等元素，真正可见稳定可点击了才动手，精准又高效。而 selenium 的 显示等待本质是客户端轮询。 乔本定期发 h t t p 请求，问元素好了没？这本身就在网络和代码层面引入了额外开销。除此之外， playright 还有两个辅助优势，一是高效附用浏览器上下文， 避免反复启动销毁浏览器。有分析说，优化前超过百分之六十的测试时间就浪费在这上面。二是原生支持网络拦截、并行执行等现代功能，不用像 selenim 那 样依赖外部工具，既省事又少了一层性能损耗。那么实际效果如何？ 数据说话，各类测试中， playrite 的 执行速度通常比 selenium 快 百分之二十到百分之四十，在复杂交互场景下甚至能快两到三倍。而且它的测试更稳定，不稳定的测试率比 selenium 降低百分之五十，这对维护大型测试套件来说太重要了。 总结一下，三令令的架构诞生在差不多二十年前，那时前端还很静态， h t t p。 请求加外部驱动的模式够用，但现在面对单页应用、动态内容复杂交互， 它的局限性越来越明显。而 play right 用 web socket 常连接加直连浏览器协议，是为现代 web 而生的新架构，不仅更快，而且更稳、更智能，所以它正迅速成为现代 web 自动化测试的首选方案。如果你还在被 selenium 的 曼和 flake 测试折磨，不妨试试 play right。