Lightpanda Browser 正在 GitHub Trending 走红，因为 Chromium 的无头优势也有代价

Lightpanda 于 2026 年 9 月 8 日升至 GitHub Trending 第 12 位，再次把对 Chromium 的直接挑战带回开发者的信息流。lightpanda browser 承诺为 AI agents 和网页自动化提供更轻量、更快速的基础。它的走红值得关注，因为浏览器基础设施已成为 agent 系统中一项反复出现的成本。

这并不是一款刚发布的浏览器。这个开源仓库在 9 月的排名之前就已存在，并且积累了多年的开发工作。GitHub Trending 反映的是一波关注热度，而不是经核实的发布日期或产品里程碑。

这波关注背后存在一个重要矛盾。大多数浏览器自动化仍依赖 Chromium，即使根本不需要有人看到最终页面。Lightpanda 去除了图形渲染管线，仅实现机器所需的浏览器功能。

这种更聚焦的设计能够降低基础设施需求。但它也带来了 Chromium 已经花费多年解决的兼容性负担。Lightpanda 的机会取决于团队是否足够重视更低的资源消耗，并愿意应对尚存的缺口。

Lightpanda Browser 正在走红，但这并非一次发布

经核实的事件是开发者关注度的激增，而不是 9 月 8 日发布了一款新浏览器。

BettaFish 的 GitHub Trending 快照显示，Lightpanda repository 于 2026 年 9 月 8 日位列第 12。这一排名表明该项目是当前热门仓库，但并不能证明底层软件最初的发布时间。

这一差别对新闻准确性至关重要。GitHub Trending 衡量的是一个滚动周期内的活跃度，而软件发布通常会伴随公告、版本号或带标签的 release。所提供的来源快照未给出经过核实的发布时间。

Lightpanda 的仓库将该项目描述为一款从零构建、面向 AI agents 和自动化的 headless browser。headless browser 能够加载和操作网站，但不会向人展示传统浏览器窗口。

该项目主要使用 Zig 编写。Zig 是一种旨在实现明确资源控制的系统编程语言。它并非 Chromium、Blink 或 WebKit 的 fork。不过，目前它使用 Google 的 V8 engine 来执行 JavaScript。

该仓库在 9 月 8 日查看时约有 34,700 个 stars 和 1,600 个 forks。它还显示了超过 9,200 次 commits，表明项目的曝光度建立在持续开发之上，而非昙花一现的实验。

Linux 和 macOS 的 x86-64 与 Arm 架构均可获得 nightly binaries。该项目还提供了官方 Docker image 以及 Homebrew 安装方式。由于未列出原生 Windows binary，Windows 用户需要使用 Windows Subsystem for Linux。

该软件提供了多种供机器控制的方式，包括抓取页面的命令、Chrome DevTools Protocol server、WebDriver BiDi support、HTTP interface，以及 Model Context Protocol server。

Chrome DevTools Protocol，通常简称 CDP，可让自动化客户端通过结构化消息控制浏览器。Lightpanda 的 CDP support 允许 Puppeteer 和 Playwright 等常见客户端连接，无需采用全新的控制模型。

该项目还提供原生 agent mode。用户可以用自然语言描述浏览任务，让模型完成任务，并将生成的操作保存为 JavaScript。

Lightpanda 将这一输出称为 PandaScript。项目称，保存后的脚本可在不再次调用 language model 的情况下以确定性方式运行。这种方法将探索性的 agent 行为与重复性的生产自动化分离开来。

这一组合有助于解释重新升温的关注。Lightpanda 不再只是一款轻量级页面加载器，它正尝试让一个浏览器 engine 同时支撑传统自动化协议、agent tools 和可重复运行的脚本。

不过，GitHub 的热度仍只是关注度信号。Stars 并不衡量生产环境中成功的 sessions、网站覆盖率或失败率。Trending 排名让 Lightpanda 值得进一步研究，但并不能终结技术层面的争论。

这场争论始于：为完全不产生视觉输出的工作使用可视化浏览器，究竟要付出多少成本。

为什么 AI Agents 正在给 Headless Chrome 带来压力

AI agents 会将浏览器开销转化为持续发生的基础设施支出，因为每一项并发任务都可能需要各自活跃的浏览上下文。

传统浏览器自动化通常处理边界明确的任务。测试套件会在部署期间打开页面，或 crawler 处理一份已知的 URL 列表。由于 sessions 有限且可预测，团队可以接受相对沉重的浏览器。

AI agents 改变了这种运行模式。它们会在研究、客服工作、产品比较、数据采集和多步骤 workflows 中浏览网页。一项用户请求可能触发多次搜索、页面加载、点击和信息提取。

将这一模式扩展至大量用户，浏览器 sessions 会迅速增加。内存消耗影响一台 worker 可容纳多少 sessions。启动时间影响延迟，而 CPU 需求决定基础设施容量。

Chromium 仍是默认选择，因为它对现代 web 有着广泛的兼容性。它包含布局、样式、绘制、合成、媒体处理，以及大量 browser APIs。

当人需要看到像素时，这些能力必不可少。当自动化 workflow 依赖布局、screenshots、canvas 内容，或 Chromium 特有的浏览器行为时，它们同样重要。

不过，许多机器任务主要需要文档结构、JavaScript 执行、cookies、网络请求和交互元素。它们未必需要在每次导航后生成图形化界面。

Lightpanda 的核心押注是，机器需要一款围绕这些要求设计的浏览器。其架构概览称，该 engine 完全省去了图形渲染管线。

浏览器仍会下载资源、解析 HTML、创建内存中的 Document Object Model，并执行 JavaScript。Document Object Model，即 DOM，将页面表示为软件可检查和修改的对象。

Lightpanda 以编译后的 Zig 实现 web APIs，并将其暴露给 V8。这使页面脚本能够与其 DOM 交互，而不需要传统图形栈。

去除渲染会改变浏览器的资源特征。当所需输出是结构化文本时，无需计算所有视觉布局、绘制像素或合成图形图层。

这在并发 workloads 中尤为重要。单次页面加载中的小幅节省，在服务同时运行数十或数百个 sessions 时会变得非常可观。

因此，承受压力的是运行基于 Chrome 自动化的团队，而不是选择 desktop browser 的普通用户。Lightpanda 并非要取代人们用来阅读新闻、观看视频或运行日常 web applications 的 Chrome。

它在服务器端与 headless Chromium 竞争。Browserless services、scraping platforms、testing systems 和 AI-agent frameworks 都依赖浏览器容量。它们的客户最终会通过延迟、限制或运营成本为这类容量买单。

Lightpanda 也挑战了一项架构假设。开发者一直将 headless mode 视为去掉可见窗口的可视化浏览器；Lightpanda 则将浏览器自动化视为一种独立的计算 workload。

该项目较早前的融资为这一策略提供了背景。Lightpanda 于 2025 年 6 月 10 日宣布完成 pre-seed round，由 ISAI 领投，Kima Ventures、Factorial Capital 和 Prototype Capital 参投。

其融资公告未披露具体金额。公司表示将利用这笔融资扩充工程团队、提升浏览器覆盖率，并为 AI workflows 添加功能。

未披露金额限制了对公司财务状况的判断。不过，具名投资者和持续开发表明，该项目获得的支持不止于志愿者层面的关注。

AI 需求也为这款浏览器带来了比早期替代 engines 更清晰的市场。Agents 需要读取和操作网站，但为每项操作运行完整的可视化栈可能效率不高。

使用自动化 agents 进行研究的开发者还会遇到相关的信息管理问题。结果分散在浏览器 sessions、logs、documents 和生成的 summaries 之中。一套可搜索的知识库可以在浏览器 session 结束后保留这些材料。

由此形成了对 Chromium 默认地位的可信压力来源。但只有当更轻量的 engine 能够可靠完成所需工作时，更低的开销才有意义。

Lightpanda 与 Chrome 的较量是性能和兼容性的权衡

Lightpanda 通过实现更少的可视化 web 功能来提升效率，而 Chrome 则通过承担平台的完整负担来获得可靠性。

Lightpanda 发布了大量性能声明。其当前仓库称，在高并发下，浏览器约在五秒内处理了 933 个网络页面。同一项目运行的测试中，headless Chrome 据称需要约 46 秒。

仓库还报告，在对比 workload 中，Lightpanda 的 peak memory 为 123 MB，Chrome 为 2 GB。这相当于完成速度约快九倍，peak memory 约低 16 倍。

公司扩展版的browser benchmarks提供了更多方法细节。这项 crawl 在 AWS instance 上运行，并跟随链接遍历一个包含 933 个页面的演示目录。

两个 engines 都使用同一个 Go crawler 通过 CDP 控制。Chrome 在一个 browser process 中使用多个 tabs；Lightpanda 则使用多个独立 processes，因为它不支持在单一 process 中打开多个 tabs。

在 25 个并行 tasks 下，Lightpanda 报告称以 123 MB 的 peak memory 在 4.81 秒内完成 crawl。Chrome 据称使用了 2 GB，并在 46.70 秒内完成。

另一项本地 e-commerce test 将加载并提取的任务重复 100 次。Lightpanda 报告的平均运行时间为 16 milliseconds，而 Chrome 平均为 185 milliseconds。

Lightpanda 还报告该测试的 peak memory 为 21.2 MB，Chrome 则为 402.1 MB。测试通过使用 local server 排除了正常的互联网延迟。

这些数据描述了真实的测试执行，但 benchmarks 由 Lightpanda 设计并发布。即便公司提供了用于复现的命令和原始输出，它们仍应被视为厂商结果。

这一比较还体现了两种不同的扩展模型。Chrome 会在 tabs 之间共享基础设施，包括 renderer processes 和 V8 resources。Lightpanda 的独立 processes 则无法获得同样的共享收益。

这一选择并不会使 benchmark 失效。但这意味着团队应使用自己的并发模型、页面组合、地理延迟、proxy configuration 和 session duration 来复现 workload。

平均速度只是众多生产指标之一。一款浏览器即便能快速处理大部分页面，若在关键少数页面上失败，仍可能提高 workflow 的总成本。重试、fallbacks、调试和人工审查同样会消耗资源。

兼容性是 Chromium 最突出的优势所在。现代网站可能依赖复杂的样式计算、嵌套框架、浏览器存储、Service Worker、媒体功能、布局测量以及未公开的行为细节。

Lightpanda 公开表示，其 Web 平台覆盖范围仍不完整。该项目实现了无头自动化所使用的 API，并会随着时间推移扩展覆盖范围。

其代码仓库列出的核心能力包括 Ajax、Cookie、表单、代理、网络拦截、自定义请求头，以及可选的 robots.txt 处理。负责管理大量跨域 Web 请求的 CORS 支持仍被标注为实验性功能。

该项目每天都会发布针对 Web Platform Tests 的测试结果；这是一套用于评估浏览器行为的标准化测试集合。公开测试比笼统地承诺兼容性，能为开发者提供更有价值的信号。

不过，通过 API 测试并不意味着复杂的生产网站一定能正常运行。网站会以难以预测的方式组合浏览器功能，其中一些还会主动检测自动化行为，或依赖视觉状态。

Chrome 提供截图、准确的布局，以及对图形相关行为的广泛支持。Lightpanda 的无渲染器设计意味着，它无法复现所有依赖实际像素的工作流。

根据其代码仓库，Lightpanda 可以输出以文本为导向的 PNG 或 PDF。该功能不应与由完整布局和渲染引擎生成的传统视觉截图混为一谈。

这种取舍界定了 lightpanda browser 的适用场景。当自动化任务需要 JavaScript、DOM 访问、页面导航和结构化提取，而不要求视觉保真度时，它最具优势。

当任务成败取决于 canvas 输出、精确的元素几何位置、丰富媒体内容或非典型浏览器 API 时，其优势则会减弱。视觉质量保证仍属于能够渲染页面的浏览器。

对于 AI agent 而言，这条分界线并不那么明显。一个读取产品页面的 agent 可能只需要文本和交互控件；而一个解读图表、地图、示意图或视觉编码状态的 agent，则可能丢失关键信息。

Lightpanda 自己的 agent 评估也反映了这种张力。该公司在 AssistantBench 和 GAIA 验证任务中，测试了其原生 agent 及多种浏览器工具组合。

其公布的结果显示，在 33 个 AssistantBench 任务中，严格准确率为 69.7%；在 53 个 GAIA Level 1 任务中，准确率为 83%。这些测试使用 Claude Sonnet 4.6，超时限制为 1,800 秒。

在另一项对比中，Lightpanda 的 MCP 工具在 AssistantBench 上获得 66.7%，在 GAIA 上获得 86.8%。使用 Chromium 的 Agent-browser 分别获得 57.6% 和 84.9%。

不过，使用 Lightpanda 的 Agent-browser 在 AssistantBench 上与 Chromium 持平，均为 57.6%。在 GAIA 上，其得分为 81.1%，而 Chromium 为 84.9%。

该公司将 AssistantBench 上的差距解释为工具界面效应，因为同一个 Agent-browser 封装在两种引擎上产生了相同结果。GAIA 的差异也显示，在某些情况下，仅文本输出会遗漏以视觉形式呈现的信息。

这些发现削弱了“某一种浏览器在所有场景下都更好”的简单说法。Agent 性能取决于引擎、向模型暴露的工具，以及每次操作后返回的信息。

因此，Lightpanda 的性能承诺足够可信，值得测试；但它过于依赖具体工作负载，不能被视为通用替代方案。

Lightpanda Browser 的数据无法证明什么

快速的厂商基准测试并不能证明其具备完整 Web 兼容性、更低的总成本，或能在各类生产网站上可靠运行。

第一个不确定性涉及工作负载选择。演示目录为每个引擎提供稳定目标，并使测量可重复，但它无法代表公共网站的全部多样性。

真实自动化会遇到身份验证、同意弹窗、客户端路由、速率限制、反机器人防护、嵌套框架以及意外的网络故障。长时间运行的会话还可能暴露短时爬取无法发现的内存泄漏或状态管理问题。

第二个不确定性涉及视觉信息。Lightpanda 缺少图形管线带来了资源优势，但这种缺失也移除了一个重要的上下文来源。

按钮的 DOM 标签或许足以让 agent 理解其含义，但颜色编码的图表、canvas 应用或视觉重排的界面则未必如此。无障碍树可以提供帮助，但无法完美重现视觉语义。

第三个不确定性涉及 API 覆盖范围。Lightpanda 的文档表示，覆盖范围会随着时间推移扩大，其代码仓库也引导开发者查看每日标准测试。

对于一个年轻的浏览器引擎而言，部分覆盖是常态。但这也意味着，兼容性必须依据各团队实际使用的网站和功能来评估。

Playwright 和 Puppeteer 的连接能力可能会带来不切实际的期待。CDP 兼容性允许现有客户端建立控制连接，但并不意味着每条客户端命令或每种页面行为都与 Chromium 一致。

熟悉的连接方式可以减少迁移工作，但无法消除生命周期事件、时序、框架、下载、存储、调试和未支持 API 方面的差异。

许可问题同样值得关注。该代码仓库采用 GNU Affero General Public License 第 3 版。AGPL 的义务可能会影响修改软件并通过网络提供访问的组织。

Lightpanda 还发布了单独的许可信息。考虑再分发、专有修改或嵌入式服务的团队，应在适当法律顾问的协助下审阅相关条款。

安全性和隐私需要通过实际测试验证。浏览器自动化会处理不受信任的页面并执行 JavaScript。任何新引擎都必须在沙箱机制、漏洞响应、依赖更新和隔离能力方面建立信心。

Chromium 得益于庞大的安全团队和成熟的发布流程。这并不意味着 Chrome 没有风险，但它提高了替代引擎必须达到的标准。

Lightpanda 的独立进程模型可以在会话之间提供运行层面的隔离，但并不能自动证明它能防护每一种恶意页面或引擎级漏洞。

该代码仓库称，默认启用使用遥测，且可通过环境变量禁用。对数据控制要求严格的组织，应在处理敏感浏览任务前审查隐私政策和部署配置。

团队还必须区分浏览器效率与 agent 效率。轻量级引擎可以降低 RAM 和 CPU 使用，但低效的模型循环仍可能产生过多请求和 token。

Lightpanda 的 PandaScript 概念解决了其中一部分问题。它允许开发者在探索工作流时使用模型，随后无需再调用模型即可重放保存的 JavaScript。

这种方法最适用于在探索后趋于稳定的任务。对于页面结构不会频繁变化的重复提取、监控和导航流程，它较为合适。

当网站发生变化时，确定性脚本仍需维护。浏览器可以降低执行成本，但无法消除自动化由他人控制的界面所固有的脆弱性。

对于生产系统而言，混合式设计目前看起来比立即全面迁移更稳妥。Lightpanda 可以处理以文本为主的页面，而当需要渲染或遇到不支持的 API 时，Chromium 仍可作为后备。

该项目曾讨论将自动回退至 Chrome 作为弥补这些缺口的一种途径。这样的系统会将问题从选择单一引擎，转变为将每个页面路由至成本最低且能力足够的引擎。

回退同样会引入复杂性。团队必须识别不完整输出、不支持的行为或静默的语义错误。导航失败比页面成功加载却遗漏关键信息更容易被路由处理。

因此，有意义的评估应衡量任务完成情况，而不只是页面加载速度。一套有价值的测试集应包括组织实际使用的网站、操作、认证流程和预期输出。

开发者应记录成功率、回退频率、中位数和尾部延迟、峰值内存、CPU 时间以及维护事件。这些指标能够揭示较低的浏览器开销是否真正带来了较低的总运营成本。

lightpanda browser 之所以前景可期，是因为其设计针对了一项真实的低效问题。它的局限性并非偶然缺陷，其中一些直接源于使其具有吸引力的架构选择。

更小的浏览器如何改变 Agent 基础设施的构建方式

Lightpanda 更深层的贡献在于：它将浏览器自动化视为机器接口，而不是桌面应用的隐藏副本。

这种方法支持的不只是更快的爬取。紧凑的进程可以让一个工作节点承载更多彼此隔离的会话。当 agent 分别携带 Cookie、浏览历史和任务状态时，隔离尤为重要。

Lightpanda 基于 HTTP 的 MCP 服务器可以为不同客户端分配独立会话。Model Context Protocol 是一种用于将 AI 应用与外部工具和数据连接起来的标准接口。

独立的会话标识符可防止 agent 相互覆盖页面。当工作流需要协调访问时，多个客户端也可以共享一个浏览上下文。

原生 HTTP fetch 端点提供了另一种路径。客户端可以请求页面，并在无需编写完整 CDP 自动化脚本的情况下获得 HTML 或 Markdown。

这对需要在 JavaScript 执行后获取渲染文档内容的检索系统很有用。它介于简单的 HTTP 下载器与完整浏览器控制工作流之间。

内置 agent 则通过减少模型与浏览器之间的通信更进一步。同一进程内的直接操作可以避免部分工具调用开销。

Agent 系统通常会在每一步后，将大量页面表示发送回模型。即便浏览器本身运行高效，这种做法依然会消耗 token 并增加延迟。

Lightpanda 提供了面向机器消费的语义信息和结构化交互工具。更好的工具设计与原始引擎速度同样重要，因为它决定了模型能看到什么。

公开的 agent 对比结果支持这一观点。同一引擎会因周围的工具接口不同而产生不同准确率。浏览器选择本身并不能决定最终结果。

这使竞争转向垂直整合的 agent 基础设施。Chromium 作为通用平台提供广泛兼容性；Lightpanda 则将更聚焦的引擎与围绕自动化和模型使用设计的接口相结合。

构建研究 agent、监控系统或提取产品的公司，可以通过多种方式使用这种架构：在本地运行 Lightpanda、部署 Docker 镜像，或通过 Lightpanda 的云服务连接。

本地部署能更好地控制网络、会话数据和执行过程。托管服务可以减少维护工作，但也增加了一个供应商和数据处理边界。

该项目对 robots.txt 的支持也表明，它正越来越关注运营责任。Robots.txt 是由网站控制的文件，用于告知爬虫应避免哪些自动访问路径。

Lightpanda 通过 --obey-robots 标志将合规设为可选项。这种实现不能替代法律审查、合同限制、速率限制或负责任的数据收集实践。

这一差异很重要，因为更轻量的基础设施能够提高采集能力。技术效率不应被理解为可以无限制发起请求的许可。

对开发者而言，最具吸引力的近期使用场景，是在已知网站上进行可控的高吞吐量工作。团队可以验证每一个目标、衡量失败模式，并为例外情况保留 Chrome。

预渲染是另一个合理的适用场景。文档网站和内容平台有时会为爬虫或预览生成经浏览器处理的 HTML。这些任务未必需要视觉渲染。

DeveloperHub.io 表示，它将一项预渲染工作负载从无头 Chrome 迁移到 Lightpanda 后，显著降低了负载。这一客户说法提供了一个生产环境案例，但证据仍由 Lightpanda 选择并发布。

测试则呈现出更为分化的情况。以 DOM 为核心的检查可能受益于更快的隔离会话。视觉回归测试和对布局敏感的断言，仍然需要渲染引擎。

AI 研究代理同样存在混合需求。以文本为主的来源适合 Lightpanda 的设计。PDF 查看器、图表、地图和基于图像的界面，通常需要 Chromium 作为后备方案，或采用专门的提取路径。

记录代理研究成果的团队，可以将浏览与知识融合结合，把检索到的页面与本地资料整合起来。浏览器负责收集，知识层则为后续工作保留上下文。

Lightpanda 并不能取代这一更广泛的工作流。它提供的是一个执行层，能够让重复性的网页交互成本更低、结构更清晰。

这也是为什么该项目的 Trending 时刻，其意义不止于星标数量。它让开发者看到了一种明确的替代方案：自动化浏览未必总得继承完整桌面浏览器的模式。

该项目无需在所有场景中取代 Chromium 才有价值。若能覆盖浏览器工作负载中面向文本、高并发的部分，就足以确立一个有意义的基础设施类别。

三项信号将决定 Lightpanda 能否持续发展

兼容性的提升、独立的生产结果，以及可靠的回退行为，将决定当前的关注能否转化为持久采用。

第一项信号是可衡量的 Web 平台覆盖度。未来三个月，开发者应关注 Lightpanda 的每日测试结果和代码仓库变更。

跨源请求、框架、存储、导航事件以及常用 DOM API 方面的进展，将强化其替代方案的说服力。覆盖进展停滞或反复出现回归问题，则会削弱这一论点。

原始通过总数需要结合语境解读。某些浏览器 API 对自动化的意义远大于其他 API。改进情况应与真实 Puppeteer、Playwright 和代理工作流报告的失败案例相对照。

第二项信号是独立的工作负载证据。Lightpanda 提供了可复现的基准测试，但还需要更多团队公布针对公开网站和持续会话的测试结果。

最有价值的报告应涵盖完整任务的成功情况，而不只是执行时间。报告应披露网站类别、并发量、回退率、浏览器版本和失败定义。

若独立测量能够复现更低的内存占用，同时保持可接受的完成率，就能验证 Lightpanda 的核心主张。若兼容性代价很大，则说明基础设施节省被转移到了重试环节。

第三项信号是回退质量。一个实用的多引擎系统必须能够识别：何时 Lightpanda 缺少某项任务所需的信息或 API 行为。

可靠地路由到 Chromium，将使团队能够渐进式采用 Lightpanda。它也会将不完整的兼容性从硬性阻碍，转变为可衡量的运营成本。

检测不佳比明显崩溃更危险。自动化系统可以从页面加载失败中恢复，却可能在毫不知情的情况下信任不完整的文本，或遗漏关键控件。

评估 lightpanda browser 的开发者，应从一组具有代表性的测试语料开始。其中应包括简单的内容页面、需要身份验证的应用、客户端渲染界面以及依赖视觉能力的任务。

让这些任务分别通过 Lightpanda 和当前的 Chromium 技术栈运行。先衡量两套系统是否产出相同的预期结果，再只在成功执行的任务中比较资源消耗。

应将不受支持的功能、错误输出、超时失败和可恢复的导航错误分为不同类别。这种分类将揭示回退是否能够安全地自动化。

团队还应测试代理、Cookie、请求拦截、会话清理和崩溃恢复等运行细节。这些功能往往比醒目的基准测试结果更能决定生产环境的可靠性。

GitHub Trending 为 Lightpanda 带来了新的受众，但关注度只是开场测试。更艰难的考验发生在开发者让该引擎面对复杂网站和周期性工作负载之时。

如果兼容性持续扩大，同时资源优势得以保持，Lightpanda 可以成为机器浏览的标准一线引擎。Chromium 将保留为兼容性的后备方案，而非默认起点。

如果这些缺口仍然难以预测，Lightpanda 依然会服务于专用爬虫和受控提取任务。但其更广泛的代理浏览器愿景将面临更低的上限。

这一选择不需要对某一引擎作出意识形态式的承诺。开发者可以识别哪些任务真正需要像素级呈现，再将其余工作负载迁移到更轻量的执行路径上。

这正是 Lightpanda 在 9 月 8 日登上 Trending 所提出的实际问题：你的浏览器自动化中，有多少确实需要完整的可视化浏览器，又有多少只是因为默认设置而继承了它？