你有没有遇到过这样的场景一段自动化脚本在本地跑得好好的部署到服务器之后开始频繁弹验证码、数据明明在浏览器里能看到脚本却抓不到、登录态隔三差五失效。我把这类问题归结为“自动化特征被识别”。市面上针对这个问题的解决方案不少但真正能做到代码侵入小、多语言可用的Patchright是我用过最顺手的一套。这篇文章我会从一个实际使用者的角度把Patchright在Python、NodeJS、.NET三种技术栈下的集成方式和盘托出。重点讲清楚它到底解决了什么问题、怎么在三个语言生态里落地以及我在实际项目中踩过的坑。无论你是写自动化测试、做公开数据采集还是给企业系统做浏览器自动化能力这篇指南都值得你花十分钟读完。1. 为什么需要Patchright多语言自动化的一致性难题1.1 自动化脚本被“识别”的本质早年写爬虫和自动化测试主要靠改User-Agent来伪装浏览器。后来发现这招越来越不灵了原因是浏览器指纹检测早已不是只看UA那么简单而是从多个维度综合判定一个会话是否来自真实用户。比较常见的泄漏点有几个维度。其一无头模式下的浏览器UA通常带着HeadlessChrome字样哪怕你把UA改了navigator.webdriver属性仍然会暴露这个属性在正常浏览器中是undefined但在自动化控制下几乎都是true。其二浏览器环境差异比如发丝级的时间戳精度、Canvas渲染结果、WebGL参数都会与正常浏览器有细微差异。其三更隐蔽的是行为特征脚本点击和真实用户点击的间隔、鼠标移动轨迹、滚动速度这些高阶信号在服务端是可以被建模分析的。这些识别手段直接影响自动化任务的稳定性例如页面提前加载了反制脚本导致关键按钮被遮挡、接口返回了伪装数据但页面渲染出来正常、登录态在几次请求之后被服务端强制销毁。这些现象的共同点是代码逻辑没变但运行环境被针对了。1.2 Patchright做了什么从协议层出发的解决方案Patchright本质上是一个基于Playwright的增强生态它保留了Playwright的API操作习惯但在浏览器底层做了一层处理让自动化浏览器在运行时更接近真实浏览器。打个不太准确但容易理解的比方Playwright是给你一辆能跑的车Patchright是给这辆车重新做了一遍涂装、调整了发动机声音、把GPS轨迹抹掉让它在车流里不容易被认出来。它没有改变驾驶方式你原来怎么开现在还怎么开但外观和行驶特征已经不太像“特殊车辆”了。具体到技术实现上Patchright会在浏览器启动环节对Chromium注入运行时修正处理掉自动化控制时容易被外部探知的痕迹。与“改UA加参数”这种表面功夫相比Patchright处理问题的层次更深它在你的代码和浏览器内核之间做了修正层因此外部看到的浏览器行为更接近原生状态。有一说一我不是在说Patchright能应对所有检测任何方案都不是万能的但它在可维护性和上手成本之间做了不错的平衡。对于多数自动化测试和合规采集场景它比从零去改Chromium源码要靠谱得多。1.3 适合哪些人来用场景、收益与边界结合我的实际经验适合使用Patchright的人大致有三类第一类是做自动化测试的工程师。你要验证的关键业务流程在真实浏览器环境下没问题但自动化执行时因为被识别导致用例不稳定Patchright能让测试更贴近真实用户路径减少“测试环境过不去、手工操作就正常”的尴尬。第二类是做公开数据采集的开发者。你抓取的是正常公开页面、有授权或至少不违反站点明文条款的数据但由于请求量和行为模式被识别采集效率很低。Patchright可以帮助降低这种误伤率让采集任务更顺畅。第三类是在企业系统内做浏览器自动化的后端开发者。比如内部系统需要定时拉取某个报表、政务平台需要自动填表、运营需要批量操作后台。这类场景本身就是内部系统自动化Patchright的价值在于稳定性更高不会被误判为异常流量。但必须强调边界任何用于破解验证码、绕过访问控制、未授权抓取隐私数据、越过付费墙的行为无论用什么工具都不应该做。这不仅是合规问题更是行业底线。2. 多语言生态版图Python、NodeJS、.NET的支持现状与选型2.1 官方支持情况与社区实践动手之前先看清地图。根据开源社区目前的情况Patchright对Python和NodeJS提供了官方SDK支持API风格与对应语言的Playwright SDK保持高度一致。也就是说你已有的Playwright使用经验可以低成本迁移过去。.NET生态相对特殊。官方并没有提供一套独立的.NET SDK但这不代表.NET项目无法使用Patchright。社区里常见的做法是把Patchright能力封装成独立Agent服务再由.NET业务代码通过HTTP或消息队列调用。我后文会详细展开这个方案这里先建立一个整体认知Python和Node是直接集成的路线.NET走的是服务化接入路线。技术栈官方SDK支持推荐接入方式主要适用场景Python官方支持直接import SDK原型验证、数据清洗、快速脚本NodeJS官方支持直接import SDK高并发采集、Web全栈项目内嵌自动化.NET无官方SDKAgent服务化封装企业级系统集成、内部运维自动化2.2 版本联动为什么升级必须“全家桶”这一点是我在多个项目里反复踩坑才重视起来的。Patchright与Playwright之间存在版本绑定关系因为Patchright是基于特定Playwright版本做的修改。升级Patchright时它依赖的Playwright协议层和Chromium内核配套关系也变了。我在一个项目里遇到过的情况是Python端把Patchright升到了新版本NodeJS端暂时没升结果两个服务连接同一个浏览器内核时行为不一致表现是一个正常、一个偶发白屏。排查了很久才发现是版本漂移导致的内核协议差异。所以如果你在同一个项目里同时使用Python和NodeJS两套Patchright环境强烈建议把版本固定下来用lock文件锁死升级时统一操作、统一验证。不要相信“升一个端没事”这种侥幸。2.3 浏览器二进制管理避免重复下载与版本打架多语言并存时还有一个容易忽略的问题浏览器内核的下载路径。Python和NodeJS的SDK在首次安装后会各自下载一份Chromium内核如果你不干预同一个项目里可能会存在两份甚至多份浏览器二进制占用大量磁盘不说版本不一致还会导致行为差异。解决方案是使用环境变量来指定浏览器内核的统一存放路径。在基于Chromium的自动化工具中通常可以通过类似PLAYWRIGHT_BROWSERS_PATH的环境变量来控制浏览器下载位置的做法Patchright大概率保留了这一机制以及对应的node版本。我在服务器上会把这个变量指向项目共享目录这样Python和NodeJS共用一份浏览器内核升级时也只要替换一遍。需要注意这个环境变量需要配置在执行用户的环境配置中而不是只在终端临时export一下。否则通过定时任务或服务方式启动进程时它可能会丢失导致脚本又去找默认路径结果找不到浏览器报错。3. Python集成指南三步上手与实战模板3.1 安装、浏览器初始化与第一个脚本Python是Patchright生态里最顺滑的入口毕竟大多数自动化原型都是先用Python验证的。安装和Playwright几乎一致pip install patchright安装完成后下一步是下载浏览器内核patchright install chromium如果你有多个项目共用内核记得在前面提到的环境变量上下文中执行这条命令。这里我先给一个最小可运行脚本你可以跑通后再替换具体业务逻辑。注意API和Playwright非常像关键区别在导入路径from patchright.sync_api import sync_playwright with sync_playwright() as p: browser p.chromium.launch(headlessTrue) page browser.new_page() page.goto(https://example.com) print(page.title()) browser.close()跑通这个脚本说明你的Patchright环境已经正常工作了。3.2 从Playwright迁移Patchright改动点复盘很多团队已经有大量Playwright存量代码迁移Patchright最关心的就是改动量。以我迁移过的一个测试项目为例核心改动点就只有三处。一是导入语句。Playwright的from playwright.sync_api要改成from patchright.sync_api异步版本的playwright.async_api对应改成patchright.async_api。二是浏览器启动后的上下文操作。Patchright并不依赖你自己去编写一大堆反检测参数这和某些方案需要你手动设置禁用项不一样。你不应该额外注入自己的隐藏脚本因为Patchright已经在启动层帮你处理了你在业务层再注入反而是画蛇添足。三是命令工具名称。原本的playwright install命令在Patchright里是patchright install其余核心API保持不变。如果你的代码里之前大量使用了page.goto、page.click、page.wait_for_selector这些操作迁移成本几乎可以忽略。操作Playwright写法Patchright写法同步API导入from playwright.sync_api import sync_playwrightfrom patchright.sync_api import sync_playwright异步API导入from playwright.async_api import async_playwrightfrom patchright.async_api import async_playwright浏览器安装命令playwright install chromiumpatchright install chromium这里我建议在正式切换前先拿一个高频用例做灰度验证确认Patchright在你的目标站点上确实比Playwright稳定再做全量替换。不要为了换而换。3.3 实战带登录态的定时数据提取任务这一节我用一个常见的真实场景来演示企业内部报表系统每天生成前一天的经营数据需要定时把报表数据拉取下来归档到本地数据库。这个系统有登录权限控制直接HTTP请求拿不到数据只能在浏览器环境里登录后操作。因为是内部系统自动化行为本身是授权的用Patchright主要是为了减少登录态被误判、提高稳定性。第一步是准备登录态。第一次运行以下脚本手动扫码或输入账号密码登录一次然后把登录态保存成文件from patchright.sync_api import sync_playwright with sync_playwright() as p: browser p.chromium.launch(headlessFalse) context browser.new_context() page context.new_page() page.goto(https://your-report.internal.example.com/login) input(登录完成后回车继续...) context.storage_state(pathauth.json) browser.close()注意这里必须使用headlessFalse因为在无头模式下有些登录系统会直接省略真人验证环境。保存的auth.json就是后续脚本的入场券。第二步是携带有状态地执行数据抓取。每次运行任务时直接加载登录态不再需要重复登录from patchright.sync_api import sync_playwright import json with sync_playwright() as p: browser p.chromium.launch(headlessTrue) context browser.new_context(storage_stateauth.json) page context.new_page() page.goto(https://your-report.internal.example.com/daily) page.wait_for_selector(#report-table tbody tr, timeout10000) rows page.query_selector_all(#report-table tbody tr) records [] for row in rows: cells row.query_selector_all(td) records.append([cell.inner_text() for cell in cells]) print(json.dumps(records, ensure_asciiFalse)) browser.close()这个模板看起来简单但有几个细节值得展开第一storage_state保存的是Cookie和本地存储数据但它有有效期。如果登录系统设置了严格过期时间你需要定期重跑第一步刷新登录态。我习惯让定时任务监控auth.json的修改时间超过一定时限就告警。第二#report-table tbody tr是一个等待条件它比固定sleep可靠得多。页面加载快慢受到网络影响固定sleep要么等不够、要么等太久理想的做法是等待关键元素出现。第三查询表格数据后建议立刻在页面内做一次数据校验比如把表格标题或者行数和预期值对比避免抓到的是空白页或错误提示页。我见过太多次因为页面渲染异常而抓到空列表结果还静默写入了数据库的案例。3.4 Python并发的边界什么时候该换语言Python的GIL决定了它在多线程场景下很难榨干多核性能尤其是浏览器自动化里如果大量核心逻辑都走I/O等待多线程还能凑合一旦有CPU密集型处理多线程的优势就没了。我在一个采集项目初期用Python写了多线程并发任务单线程稳定开了8个线程之后系统资源占用飙升浏览器进程之间还出现互相干扰。后来把任务拆到NodeJS上做并发编排Python只负责数据处理部分并发能力立马上了一个台阶。所以如果你预计并发量很大比如同时处理几十个页面我的建议是别在Python里死磕多线程直接看下一节的NodeJS方案更合适。4. NodeJS集成指南异步模型下的并发控制4.1 安装与最小可用脚本NodeJS里的Patchright集成方式和Python基本对齐安装命令npm install -D patchright随后同样需要安装浏览器内核npx patchright install chromium最小脚本长这样const { chromium } require(patchright); (async () { const browser await chromium.launch({ headless: true }); const page await browser.newPage(); await page.goto(https://example.com); console.log(await page.title()); await browser.close(); })();这段代码和Playwright的NodeJS API几乎一模一样如果你是前端工程师或者Node后端上手成本很低。4.2 与Python实现的关键差异NodeJS和Python两个版本在浏览器控制层面看起来很相似但并发模型完全不同。NodeJS的异步事件驱动意味着你在等待页面加载、等待元素出现的时候事件循环可以继续处理其他任务所以单个Node进程就能轻松管理多个并行任务。Python的同步API在等待时是阻塞的要么用多线程、要么切换异步API体验不如Node自然。另一个差异是资源管理的粒度。NodeJS里你通常不需要为每个任务都启动一个浏览器而是启动一个浏览器然后通过多个context来隔离任务。context在这里相当于一份独立的会话环境和真实用户打开多个隐身窗口类似互不共享Cookie和缓存内存开销也比启动多个浏览器进程低得多。4.3 实战并发采集多个页面的通用模式下面这个模式我在多个项目里复用逻辑是一个浏览器实例维护N个上下文每个上下文处理一批URL最终合并结果。并发数通过一个简单的信号量机制控制。const { chromium } require(patchright); async function fetchItem(page, url) { await page.goto(url, { waitUntil: domcontentloaded, timeout: 30000 }); const title await page.locator(.item-title).textContent(); return { url, title }; } (async () { const browser await chromium.launch({ headless: true }); const urls Array.from({ length: 20 }, (_, i) https://example.com/items/${i 1}); const results []; const concurrency 5; const workerCount Math.min(concurrency, urls.length); async function worker() { while (urls.length) { const url urls.shift(); const context await browser.newContext(); const page await context.newPage(); try { const data await fetchItem(page, url); results.push(data); } finally { await context.close(); } } } const workers Array.from({ length: workerCount }, () worker()); await Promise.all(workers); console.log(JSON.stringify(results, null, 2)); await browser.close(); })();这段代码里最核心的不是fetchItem函数本身而是context的创建与关闭时机。每个任务使用自己的context内页签任务结束立刻关闭context这样浏览器内存能快速释放长时间运行才稳。为什么起始页面元素定位直接用.locator而不是waitForSelector因为Patchright的locator在定位时会自动等待元素如果你先waitForSelector再locator等于做了两次等待性能浪费。直接用locator.textContent()在Playwright/Patchright中已经包含了等待逻辑。4.4 上下文隔离与内存回收上下文隔离这个概念我多说两句。真实用户上网打开不同的站点各个站点的Cookie、LocalStorage、缓存都是隔离的浏览器通过不同的进程和存储目录实现这个隔离。浏览器自动化里这个隔离粒度就是context。如果你把所有任务都堆到同一个context里跑会出现任务A的登录态污染任务B的情况尤其在采集需要登录的站点时Cookie串扰几乎必现。所以有并发任务时每个独立任务尽量使用独立的context用完就关。内存回收还有一个小技巧定时检查进程中是否存在残留的浏览器进程。我在Node脚本入口处加了进程退出钩子确保即使脚本异常结束也能调用browser.close()。没有这道保险服务器上会积累大量僵尸Chromium进程最终把内存耗尽。5. .NET集成指南没有官方SDK时的三种接入方案5.1 官方生态现状与三种路线对比说句实话Patchright官方目前没有提供.NET SDK这是一些团队犹豫是否采用的主要原因。但.NET项目并不是无路可走社区和实践中形成了几条成熟路线。路线A是子进程包装。你把Patchright脚本打包成命令行工具.NET代码通过Process启动子进程读取输出结果。优点是实现简单缺点是进程间通信能力弱传复杂对象比较麻烦而且子进程异常时难以获取到完整上下文。路线B是Agent服务化。把浏览器自动化能力独立部署成一个HTTP服务.NET业务代码通过REST接口提交任务、获取结果。优点是完全解耦语言边界清晰浏览器实例在单独的服务里管理不占用.NET应用的内存和线程资源。缺点是增加一个服务节点需要运维配合。路线C是CDP直连。在.NET里通过CDP协议直接和浏览器通信最大化定制能力。缺点是需要从零处理大量协议细节开发成本高除非你要实现极其特殊的浏览器控制逻辑否则完全不推荐。路线开发成本稳定性通信能力推荐程度子进程包装低中弱临时脚本可用Agent服务化中高强企业项目首选CDP直连高中最强除非必要否则不碰5.2 路线B实战用Agent服务封装Patchright能力这套方案我在多个.NET项目中落地过整体架构分三层.NET业务层、Agent中间层、Patchright浏览器层。Agent中间层作为独立Node服务运行对外只暴露极简HTTP接口。以下是一个最小Agent服务示例它接收一个URL参数调用Patchright打开页面返回页面标题和正文摘要const express require(express); const { chromium } require(patchright); const app express(); app.use(express.json()); app.post(/fetch, async (req, res) { const browser await chromium.launch({ headless: true }); try { const page await browser.newPage(); await page.goto(req.body.url, { waitUntil: domcontentloaded, timeout: 30000 }); const title await page.title(); const summary await page.locator(meta[namedescription]).getAttribute(content).catch(() null); res.json({ title, summary }); } finally { await browser.close(); } }); app.listen(3000, () console.log(Agent listening on 3000));.NET这边的调用代码很简洁using System.Net.Http; using System.Text; using System.Text.Json; var client new HttpClient(); var requestBody JsonSerializer.Serialize(new { url https://example.com }); var content new StringContent(requestBody, Encoding.UTF8, application/json); var response await client.PostAsync(http://localhost:3000/fetch, content); var responseBody await response.Content.ReadAsStringAsync(); var result JsonSerializer.DeserializeDictionarystring, object(responseBody); Console.WriteLine(result[title]);这套设计把复杂的老代码隔离在Agent服务内部.NET端只感知业务参数和JSON结果。后续即使Patchright升级、浏览器版本变化只要Agent服务对外接口保持不变.NET业务代码完全不需要改动。这种解耦带来的维护收益远高于一上来就用子进程直接调脚本。5.3 为什么服务化封装优于进程间直接通信很多.NET开发者第一反应是把Python或Node脚本作为子进程来跑用进程标准输出传结果。这个过程我劝你少用尤其在生产环境里。第一进程通信的数据结构极其有限。你要传一个包含嵌套对象和数组的复杂结果靠stdout输出然后正则解析是个灾难。第二异常定位困难。子进程崩溃时你只能拿到退出码和一个简短的错误输出内部哪个页面操作失败了根本排查不到。第三隔离性太差。浏览器进程如果因为内存问题挂掉子进程会把异常状态带给主进程。Agent服务化之后这些问题都变得可控接口超时、进程崩溃、浏览器异常都可以在Agent层统一捕获并返回结构化错误信息。浏览器实例的启动、销毁、并发控制也只在Agent层关心.NET业务端可以专注自己的领域逻辑。如果你是团队里第一个引入这套方案的开发者还可以把Agent服务做成容器镜像统一部署在服务器上这样.NET项目无论跑在哪个环境只要网络通就能获得稳定的浏览器自动化能力。6. 多语言项目落地的工程化要点6.1 三个语言怎么选场景驱动的选型表聊完三种语言各自的接入方式再给一个选型上的实际操作建议。场景首选语言原因快速原型开发Python生命周期最短随时改随时跑高并发采集任务NodeJS异步I/O吃满单进程效率企业业务系统内嵌.NET Agent服务类型安全和系统集成度优先数据分析与清洗Pythonpandas、numpy直接对接前端全栈项目NodeJS前后端统一语言心智更顺畅我见过最推荐的组合是用Python做日常调试和临时脚本生产环境规模化的采集任务交给NodeJS.NET业务侧需要浏览器能力时走Agent服务。这样每个技术栈都用在它最顺手的位置。6.2 任务队列、日志与失败重试工程化落地不能只满足于脚本能跑还要考虑异常处理。这里有一个最小可用清单任务队列方面不要让所有任务一股脑同时发到浏览器。即使Patchright能管理多个并发页面一个服务同时处理几十个任务也会导致内存和CPU告警。用并发信号量限制同时进行的浏览器任务数量超出来的排队等待。日志方面至少记录任务ID、目标URL、启动时间、结束时间、耗时、异常类型和堆栈。推荐使用JSONLines格式每行一条JSON方便日志采集系统检索。我在项目里习惯把页面关键操作也打上日志比如“点击登录按钮”“等待表格渲染完成”出问题时能复现操作路径。失败重试方面网络抖动和页面元素延迟是家常便饭。我的策略是网络类异常重试2次每次间隔按指数退避断言类异常不重试因为重试只会掩盖代码问题。重试时要确保同一个任务不会把相同的记录重复写入结果集给任务生成一个唯一ID在结果落库前去重。6.3 合规使用几条必须守住的底线写到这里必须把合规问题单独提出来。Patchright这类工具的确能提高自动化任务的隐蔽性但这并不意味着你可以把它用在违规场景里。我给自己定了几条红线也建议读者照做。一是遵守目标网站的服务条款明确写了禁止自动化访问的站点不要强行上。二是尊重robots.txt它表达了站点的访问意愿。三是绝不尝试破解验证码或跨越访问控制比如付费文章、私域数据。四是涉及个人信息采集时严格评估数据来源合法性和隐私合规要求收集到个人数据后务必脱敏存储。五是如果目标站点本身提供了官方API优先用官方API只有API无法覆盖的需求才考虑浏览器自动化。这五条守住工具才能成为生产力而不是风险源。7. 问题排查与避坑实录7.1 浏览器启动崩溃系统依赖缺失的解决办法在干净的Linux服务器上首次运行Patchright时最常遇到的是浏览器启动闪退控制台报错通常是一堆找不到共享库的信息。这不是Patchright的问题而是系统里缺少浏览器运行需要的底层动态链接库。Debian系系统可以执行下面这套安装命令补齐依赖sudo apt-get update sudo apt-get install -y libnss3 libnspr4 libatk1.0-0 libatk-bridge2.0-0 libcups2 libdrm2 libxkbcommon0 libxcomposite1 libxdamage1 libxfixes3 libxrandr2 libgbm1 libasound2装完之后重新跑脚本验证。如果是CentOS或RHEL系需要改用yum安装对应的compat库这个要看具体发行版。7.2 登录态丢失storage_state使用细节前面提到过storage_state保存有有效期。我遇到过登录态文件存在但脚本每次仍要重新登录的情况排查后发现是相对路径问题。定时任务的工作目录和手动运行时的工作目录不同相对路径auth.json指向了不同的文件位置。解决办法很简单在代码里把路径写死成绝对路径或者通过环境变量注入不要依赖进程工作目录。另一个隐蔽问题是浏览器上下文使用了storage_state之后如果你在脚本里手动修改过Cookie比如刷新token要记得把修改后的状态重新保存。否则下次启动用的仍然是旧登录态等于修改没生效。7.3 内存持续上涨上下文回收的常见误区内存问题在长时间运行的采集任务中最常见。很多人以为page.close()就够了其实只关页面不关context内存释放并不彻底。context内部持有的浏览器上下文资源、缓存的离线数据都要等context关闭才会归还给系统。在NodeJS方案里我推荐的模式是每个任务创建独立context、结束时context.close()。这样即使某个页面在异常情况下卡住context一关与之关联的所有资源都会被清理。Python也一样使用context.__exit__()或者with语法包裹保证无论正常还是异常路径都能关闭。如果发现进程内存曲线持续上涨首先排查代码里有没有未关闭的context。7.4 页面请求异常请求头与路由拦截排查采集时偶尔会遇到页面返回200但内容不是预期数据的情况。我用Patchright时也遇到过排查思路是先确认服务端返回的数据到底长什么样。建议在调试阶段先打开页面监听响应page.on(response, lambda resp: print(resp.status, resp.url))如果响应状态正常但页面内容异常可以进一步拦截关键请求查看请求头里有没有缺失的自定义头。部分站点会在服务端校验Referer、Origin或者自定义Token浏览器正常访问时会自动带上这些头但自动化上下文未必完全一致。这时可以通过page.route调整请求来补齐这些头注意只添加必要的请求头不要伪造身份无关信息。完成调试之后再确认一下这些自定义头是否会影响目标站的访问频率控制。7.5 遭遇风控时的正确应对方式最后说一个敏感但必须面对的话题自动化任务被风控拦截时该怎么办。我的态度很明确先把自身行为调整为合理频率再去想其他方案。遇到风控的原因通常是请求频率太高、行为模式比真实用户更规律。你可以做的是拉长任务间隔、增加随机延迟、错峰执行、限制单IP并发数。如果你的业务确实有高频采集需求合法且目标站允许可以考虑切换到目标站官方API或商业数据服务而不是试图在浏览器端绕过风控。任何强行对抗风控的行为都属于灰色操作遇到账号封禁、法律风险都得不偿失。换句话说Patchright替你减少了被“误伤”的概率但不代表你可以无视规则。工具可以帮你提升效率合规的界限最终还是要自己守住。我在实际项目里最深的体会是稳定比速度更值钱。无论你用Python写个小脚本、NodeJS跑并发采集还是.NET里封装Agent服务把这些基础工程做扎实让每个context都能干净地关闭、每条日志都有据可查、每次重试都有策略整个系统的可靠性才能真正立起来。Patchright只是让浏览器自动化少了一层阻碍真正的工程质量从来都在代码之外。