无头浏览器与有头浏览器：AI Agent 该怎么选

先说核心结论，因为大多数读者不会往下翻：依赖已有登录态、且已获得用户授权的工作，通常应该放在隔离的带持久配置文件的有头浏览器里；而批量、无状态的任务（获准的公开页面采集、生成 PDF、CI 检查）则适合放在无头浏览器里。两种模式都不会授予权限，也无法可靠地绕过反爬控制。

获准的大规模公开数据采集仍然用无头浏览器，因为渲染出桌面只会增加成本，并不会带来一条受支持的数据访问路径。有头浏览器这条路线则必须回答账号状态存在哪里，ego (lite) 的做法是把它留在你自己的机器上，而不是交给托管的浏览器环境。

先给刚接触的读者解释术语：无头浏览器运行的是同一个引擎，只是没有可见窗口，完全由代码驱动。有头浏览器是人实际在用的那个，带着持久的浏览器配置文件和会话；在自动化圈子里它叫有头（headed，会渲染出窗口），但一个使用全新配置文件的有头自动化浏览器，还不能算日常在用的浏览器环境。

下面全是证据：先按名字列出有头浏览器一侧的具体工具，再深入讲三个决定性维度（登录态、检测、成本），最后给一张可以直接照着选的任务对照表。

按任务选浏览器，而不是按个人偏好选。

如何判断该用带持久配置文件的有头浏览器还是无头浏览器？

这个问题听起来是二选一，大体上确实是，但分界线划在任务上，而不是工具上。两种模式都通过相同的自动化协议驱动相同的引擎（Chromium、Firefox、WebKit），所以能力并不是区分点。

真正的区分点是三件事：你的登录态会不会跟着走、自动化对防守方网站有多显眼、以及跑一个实例要花多少钱。下面的表格是总结；工具部分紧随其后，每个维度在工具之后还会各自展开细讲。

有一点需要澄清，能省掉很多困惑：无头并不等于“会被检测出来”，有头也不等于“安全”。一个带持久配置文件的有头浏览器如果被糟糕地驱动（速度离谱、路径像机器人），照样会被标记；而现代无头方案在公开页面上可以顺利通过。模式只是设定了一条基线，行为会让你往任一方向偏离这条基线。

先一眼看完整张对比，再看细节。找到你的任务最在意的那一行，那一行的胜出者就是你要选的浏览器。

Agent 需要的是一台持久化的电脑，而不是沙箱？

对于一次性脚本，临时沙箱通常就是合适的边界。对于明天还会回来的 Agent，持久计算机是更有用的心智模型：它在多次运行之间保留文件系统、已安装的软件包、浏览器配置文件和任务状态。Cloudflare 把这一区别描述为给每个 Agent 一台计算机，而不只是一个容器；LangChain 也持同样观点，强调文件系统、shell、包管理器和持久状态。 Cloudflare 的解释和LangChain 的运行时视角把基础设施层面的取舍讲得很清楚。

持久化并不是取消隔离的理由。有用的设计是一个隔离的、经用户授权的工作区，其状态在任务结束后仍然保留，并提供明确的重置和交接控制。沙箱保护主机免受不可信代码的影响；持久计算机保护 Agent 的连续性。它们解决的是不同问题，可以叠加使用。CNCF 对 Agent 沙箱的分析也指出了同一点：仅靠执行隔离，无法提供 Agent 完成多步工作所需的持久环境。 阅读 CNCF 的分析，了解隔离方面的背景。

这正是带持久配置文件的有头浏览器与通用云虚拟机或全新无头上下文的不同之处。在 ego (lite) 中，配置文件、Cookie 和登录信息都留在你自己的机器上，因此状态可以跨任务延续，而不必把已认证的浏览器状态交给托管环境。它不会绕过身份验证、验证码或网站的访问规则；会话仍由你授权，敏感操作仍由你决定。

有头浏览器阵营的工具清单

有头浏览器这一侧也有一份具体的名单，按 Agent 接触浏览器的方式可分为四类：为这项任务专门打造的共享会话浏览器、接入你现有 Chrome 的连接方式、厂商扩展程序，以及无代码录制工具。

ego (lite)

ego (lite)（免费）是我们自己的产品，直说无妨：Agent 在自己的 Space 中运行，用自己的标签页，所以窗口始终归你。

在这份名单里，它是唯一一个既让 Agent 拿到真实会话、又不把窗口交给它的方案。

这个隔离的 Space 实际会返回什么，今天对真实页面跑一遍的结果是：一个真实的 ego-browser 会话打开任务、导航页面，最后只返回所需的字段，不附带无障碍树转储。

const task = await egoBrowser.newTaskSpace('evidence-egobrowser-hn')
await task.page.goto('https://news.ycombinator.com/', { waitUntil: 'load', timeout: 20000 })
const title = await task.page.title()
const topStory = await task.page.locator('.athing .titleline > a').first().innerText()
const points = await task.page.locator('.subtext .score').first().innerText().catch(() => null)

{
  "taskSpaceId": 13
}
{
  "title": "Hacker News",
  "url": "https://news.ycombinator.com/",
  "topStory": "Qwen 3.8 27B",
  "points": "412 points"
}

下载 Mac 版 ego (lite)，免费，或查看完整的会话模型，见 登录态浏览器指南。

Chrome DevTools MCP 自动连接

Chrome DevTools MCP 自动连接（Google，免费）是官方的接入方式：在 Chrome 144+ 上，于 chrome://inspect 启用远程调试，并加上 --autoConnect 标志，Agent 便会在你已登录的 Chrome 内运行，每次会话需经一次权限确认对话框。完整会话、真实指纹，外加其他方案都没有的调试工具集；代价是它工作时驱动的是你的窗口。

Browser MCP

Browser MCP（browsermcp.io，免费）是社区版的接入方式：扩展程序加服务器的一对组合，把 Cursor、Claude、VS Code 等 MCP 客户端连接到你现在用的浏览器。自动化在本地运行，使用你现有的配置文件，因此登录信息一并带上，并沿用你的真实指纹；和所有接入方式一样，它驱动的是你正在使用的浏览器，一次只能跑一个任务。

Claude in Chrome 与 Codex for Chrome

Claude in Chrome 与 Codex for Chrome 属于厂商扩展程序这一类：Anthropic 的产品读取你已登录的页面，然后点击、输入并填写表单，适用于所有付费 Claude 套餐；OpenAI 的产品在你已登录的网站上执行操作（其文档提到 LinkedIn、Salesforce、Gmail），任务会归入 Chrome 标签页组。

零技术配置、成熟的逐站点权限提示，以及两项共同代价：各自只服务自家厂商的 Agent，且都在你的窗口中工作。

Axiom、Browse AI 与 Simplescraper

Axiom、Browse AI 和 Simplescraper 属于无代码阵营：通过点击录制，在带持久配置文件的有头浏览器会话中录下“登录并提取”的流程，然后按计划回放。对于只想从一个门户网站拉取一张表格的非开发者来说，它们是本文里上手最快的方案；代价是网站改版后容易失效，而且托管运行器会把你的会话带到别人的基础设施上。

看“代价”这一列就能发现规律：除了第一行，其他方案要么借用你的窗口，要么把你的会话送到别处。这正是共享会话这一阵营存在的结构性原因。

无头浏览器阵营的工具清单

“改用无头浏览器”是一个类别，而不是一个决策，所以这里按名称列出这个类别。它分为三层：你编写脚本调用的库、专为 Agent 打造的工具，以及当单台机器不够用时租用的云端机群。

Playwright

Playwright（Microsoft 出品，GitHub 星标 90K+）是库这一层的默认答案。一套 API 即可驱动 Chromium、Firefox 和 WebKit，功能完全对等。它的四种官方语言系列是 Node.js（JavaScript/TypeScript）、Python、Java 和 .NET/C#，自动等待的可操作性检查让脚本无需手写 sleep 也能保持稳定。

无头模式是它在 CI 中的原生环境，而在 Agent 使用场景中还有Playwright MCP，运行在同一个引擎之上。

Puppeteer

Puppeteer（由 Google 的 Chrome DevTools 团队维护，95K+ stars）是更精简、以 Chrome 为先的替代方案：只支持 JavaScript 和 TypeScript，通过 WebDriver BiDi 对 Firefox 的支持仍处于 beta，不支持 WebKit。它的优势在于单个任务的简洁性：生成 PDF、截图，以及开销极低的简单爬取，这也是许多爬虫集群至今仍统一使用它的原因。

Selenium

Selenium 是存活最久的方案，也是兼容性兜底之选。它的文档列出了五种语言绑定：Java、Python、C#、Ruby 和 JavaScript。它还提供广泛的 WebDriver 覆盖，以及用于把测试套件分发到多台机器上的 Selenium Grid。它的 WebDriver 协议每条命令都要多走一次 HTTP 往返，而原生 CDP 的工具可以跳过这一步，所以新写的爬虫很少选它，但在既有测试资产里，没有别的方案能比它覆盖得更广。

agent-browser

agent-browser（Vercel Labs 出品，约 40K stars，Apache-2.0）展示了 Agent 原生这一层的样子：一个 Rust 编写的 CLI，带一个直接说 CDP 的守护进程，驱动下载好的 Chrome for Testing。Agent 运行 agent-browser snapshot 拿到带 @e1 这类引用的可访问性树，再用 click @e2 之类的命令对其操作。会话被刻意隔离，输出可过滤以保持 Token 精简，整套设计都假设没有人在旁边看着。

Browser Use

Browser Use（MIT，约 109K stars）放进这份清单要加个星号：它是自主的 Python 框架，而不是浏览器，但它在自己管理的浏览器里通过直接 CDP 运行“感知-决策-行动”循环，而它的 headless 开关正是本文讨论的那个开关。需要规模化、目标驱动的爬取时用无头模式；目标站点开始对抗时改用有头模式。

下面是这个“感知-决策-行动”循环实际运行的样子：一个真实的 Agent（browser-use 0.13.7，通过 OPENAI_API_KEY 调用 gpt-4.1-mini）今天对着一个线上页面运行，无头模式，真实消耗了 LLM Token。

agent = Agent(
    task="Go to https://news.ycombinator.com/ and tell me the exact title text of the #1 story on the front page, plus its points count.",
    llm=llm,
)
history = await agent.run(max_steps=8)

INFO     [Agent] Starting a browser-use agent with version 0.13.7, with provider=openai and model=gpt-4.1-mini
INFO     [Agent]   navigate: url: https://news.ycombinator.com/, new_tab: False
INFO     [tools] Navigated to https://news.ycombinator.com/
INFO     [Agent] Step 1:
INFO     [Agent]   Eval: Successfully located the #1 story title and its points count on the Hacker News front page.
INFO     [Agent]   Memory: Located the top story on Hacker News with title 'Qwen 3.8 27B' and points count '415 points'.
INFO     [Agent]   Next goal: Report the exact title text and points count of the #1 story to the user.
INFO     [Agent]   done: text: The #1 story on Hacker News front page is titled "Qwen 3.8 27B" with 415 points., success: True
Final Result:
The #1 story on Hacker News front page is titled "Qwen 3.8 27B" with 415 points.
INFO     [Agent] Task completed successfully

Browserbase 和 Stagehand

当集群规模超出你自己的机器时，就该云这一层接手了。Browserbase以数千个并发会话的规模出售托管浏览器基础设施（2026 年 3 月的月度统计中有 3690 万个独立会话，覆盖 10000+ 家公司），配合Stagehand（23.7K stars）作为其开源 SDK，在 Playwright 风格的代码之上叠加 act、extract 和 observe 原语。

Browserless

Browserless 占据同样的位置，但形态是 API 优先：提供 /screenshot、/pdf、/content、/scrape 等 REST 端点，一个用于处理机器人检测的 /unblock 端点，以及用于多步流程的 BrowserQL，任何能发送 HTTP 请求的东西都能调用，包括 n8n 工作流。

隐身层

再往上还有一层需要如实说明：隐身生态。Selenium 有 undetected-chromedriver 和 SeleniumBase；Puppeteer 的 puppeteer-extra-plugin-stealth 是成熟的老牌方案，playwright-extra 可以加载它的插件；Camoufox 和 Patchright 目前只支持 Playwright。把这一切都当作移动靶，而不是一次购买就能解决的问题：r/webscraping 上的实践者报告过隐身分支被拦截、而默认 Playwright 反而通过的案例。

七个名字，一项共同运维成本：每个都默认使用全新或单独管理的浏览器状态。会话可以注入或持久化，但都需要配置、保护、刷新和调试。如果这正是你的任务反复撞上的墙，上面那份有头浏览器名单就是答案；如果不是，这七个仍然是更轻量的自动化路线。

登录态在谁手里？

无头不等于免登录。全新的上下文一开始是空的，但 Playwright 可以通过以下方式恢复认证：storageState 或持久化配置文件（Profile）真正的差别在于：准备这份状态、复用它，以及在服务器让它失效之后恢复，各需要多少工作量。

2026 年 8 月 21 日，我们在 M4 Mac 上针对同一个第一方登录测试环境，把每条路径各跑了五次。Playwright 1.59.1 使用 Chromium 147；ego (lite) 为 0.4.7.1。

四条路径在五次运行中全部完成，没有一次重试。会话就绪时，一个全新的 ego (lite) Space 在 0.43 秒内到达受保护页面，而 Playwright 需要 1.42 到 1.61 秒。复用任何会话，也意味着把该账号的权限一并交给 Agent。

Zillow 只能算现场观察

在一次单独的只读运行中，全新的 Playwright 停在 Zillow 的 Press & Hold 页面，而继承了会话的 ego (lite) 进入了首页和账号菜单。 先阅读 Zillow 当前的条款再决定是否自动化。登录态、自动化信号、防御措施和配置文件历史是一起变化的，所以这仍然只是一次现场观察，而不是因果基准测试。

被检测出来的差距有多大？

差距比过去小了很多，原因是一次具体的改动。Chrome 推出了新的无头模式（--headless=new），它运行的是和可见浏览器相同的浏览器二进制文件，取代了旧的那套独立无头实现，而旧实现会泄露明显的破绽。

在旧模式下，网站可以通过 user agent 里的 HeadlessChrome 标识、缺失的 plugin 和 MIME 数组、以及被精简过的渲染路径等特征识别出无头实例。新模式堵住了其中大部分，因为已经不存在一个独立的、更精简的浏览器可供识别。

仍然会泄露的信号更隐蔽，而且很少出现在 user agent 里。自动化标志（navigator.webdriver 默认为 true，除非被抑制）、缺少真实显示器及其设备缩放特性、人类不会产生的时序和交互模式，以及来自数据中心 IP 的连接信号，这些对有心防御的网站来说依然可见。

2026 年的检测是一个综合评分问题，而不是单一检查：没有任何一个信号能单独判定你，但一堆信号叠加起来就可以。所以诚实的说法是基线加行为，而不是无头就坏、真实就好。

我们的三模式检测测试

我们还在同一台 Apple M4 Mac 和同一网络下，用三种模式打开了 Sannysoft 的公开检测器：Playwright 1.62.1 默认无头 Chromium、Playwright 有头 Chromium 配合全新配置文件，以及 ego (lite) 的持久化有头浏览器。每种模式重复三次，下面列出的可见信号在多次重复中保持稳定。

实际结果比“有头胜过无头”要更微妙。让 Playwright 可见确实消除了若干环境差异，但全新有头运行仍然暴露了 WebDriver。持久化的 ego (lite) 运行在这个页面上更接近已安装的桌面环境。防御方网站还可以利用 IP 信誉、请求模式、交互时序、账号历史以及本次测试从未看到的私有信号。

还有一个重要的版本细节：Playwright 将其默认的 Chromium 无头 shell 与更新的无头模式区分开来可通过 Chromium 渠道获取。我们的默认无头模式结果不能推广到所有现代 Chrome 无头配置。如果检测结果很重要，请记录确切的软件包、浏览器构建版本、启动渠道、flag、浏览器配置文件（Profile）、网络和日期。

这些工具实际跑起来是什么体验

Playwright 是进行受控全新上下文测试的更干净选择。浏览器版本和启动模式明确，运行可重复，在固定视口下截图也很容易。摩擦出现在任务涉及账号状态时：有头模式给了我们一个窗口，但全新浏览器配置文件（Profile）仍然是全新的。在进行有用的账号操作之前，我们需要先认证、导入状态或维护一个持久化的浏览器配置文件（Profile）。

ego-browser 采用了不同的方式：它创建了一个隔离的 Space，并在 ego (lite) 中打开 YC Hacker News。下方截图展示了实际运行情况，包括浏览器界面、Agent 的 Browsing Hacker News 光标以及实时控制面板。Agent 在自己的标签页中工作，用户可以随时查看进度、接管或停止任务。

这次体验也让产品之间的分工更清晰。当公开测试需要受控、可丢弃的环境时，我们会使用全新的 Playwright 上下文。当任务依赖已授权的现有会话时，ego (lite) 会跳过重建浏览器配置文件（Profile），让 Agent 从你已经准备好的状态开始。

各自的运行成本是多少？

我们在同一台 M4 Mac 和第一方页面上，对每种模式运行了五次冷启动。Playwright 1.59.1 使用 Chromium 147；ego (lite) 为 0.4.7.1。我们记录了时间、RSS、重试次数和失败次数。

默认 shell 是 Playwright 完整进程树中最精简的，加载后为 263 MB。新无头模式和有头模式分别达到 627 MB 和 641 MB，仅相差 2.2%。ego (lite) Space 启动最快，增加了 178 MB 的 Space 进程；其数据行不包括正在运行的共享应用、GPU 和网络进程。全部 20 次运行均成功，无重试。

端到端 Agent 成本还涉及另一层。在我们使用相同模型和评判器的 31 项任务基准测试中，ego-browser 记录了最低的平均每任务成本，为 $1.64。在相同设置下，Playwright CLI 为 $3.42，Chrome DevTools CLI 为 $4.95。

哪类任务该用哪种浏览器？

这三个维度可以归结为一张任务查找表。找到与你实际在做的事情匹配的那一行；一旦诚实地命名任务，选择很少会有歧义。

大多数真实项目最终会落到这种组合：无状态任务用无头浏览器批量跑，需要登录和面对风控的任务用带持久配置文件的有头浏览器，不强行让一种模式去做另一种模式的活。常见的失败模式是凭喜好选模式（“无头感觉更轻”“有头浏览器感觉更安全”），然后在每个不合适的任务上跟自己的选择较劲。

为什么爬虫在本地能跑，上了生产就失败？

本地能跑通，不代表生产环境能访问。一旦部署到生产，IP 信誉、TLS 与浏览器构建版本、显示环境、时序、并发、Cookie 和请求量都会变化，而这些正是目标站点风控评估的信号。无头浏览器本身完全正确，但当这些信号发生变化时，仍可能收到验证码（CAPTCHA）或残缺的响应。

• 每次金丝雀运行都记录浏览器版本、启动参数、视口、网络、浏览器配置文件（Profile）模式、响应状态和时间戳。
• 先用低频、已获授权的金丝雀任务，把字段完整度（而不只是 HTTP 200）与本地基线做对比。
• 遇到 403、429、验证码（CAPTCHA）、同意页或挑战页时，暂停、退避、申请访问权限，或改用官方 API 或授权数据源。

不要用代理轮换、指纹伪造、Cookie 重放或身份切换来应对生产环境的封禁。这些做法可能违反服务条款，也会让排查更难；真正持久的修复方法是走已批准的访问路径，并把负载控制在目标站点能承受的范围内。

Agent 应该如何复用登录会话？

只有在账号所有者授权的前提下才复用登录态，并把该状态与无关 Agent 隔离。持久化的浏览器配置文件（Profile）或已批准的 storage-state 文件可以免去反复走 SSO 和 MFA，但它会变成一个高价值密钥，需要访问控制、过期、吊销和审计日志。

• 自动化优先使用专用的最小权限账号或浏览器配置文件（Profile）；绝不要把密码、Cookie、refresh Token 或恢复码写进提示词或提交到版本控制。
• MFA 和同意环节交给密码管理器或人工接管，会话过期就停下，不要试图绕过检查点。
• 无头 CI 场景下，通过官方支持的测试流程创建短时效状态，并在运行结束后删除产物；交互式场景下，那个已授权的 Chrome 会话可以留在本地，由 ego (lite) 直接使用，无需导出到托管运行时。

会话复用提升的是连续性，不是授权。每开始一个新工作流前，都要重新核对目标站点的条款、账号角色、数据敏感度和当前同意状态。

浏览器指纹和 TLS 信号究竟能证明什么？

指纹是一组信号的集合，不是判决书，也不是隐身开关。站点可以把 User-Agent 和 WebGL 值、插件列表、canvas 输出、TLS 特征、IP 信誉、时序、导航模式和账号历史组合起来判断。把某一个信号伪装成日常在用的浏览器环境，并不能让自动化工作流变得无法区分，也不代表它被允许。

• 使用标准、受支持的浏览器构建版本和贴近真实的负载上限；当检测结果发生变化时，记录下改动了什么。
• 把隐身插件和反检测浏览器当作未经审核的第三方代码，它们自带隐私和维护风险。
• 如果站点封禁了你的工作流，改用 API、导出或书面授权，而不是去复刻 TLS、WebGL 或他人的身份。

带持久配置文件的有头浏览器可以减少全新自动化上下文带来的浏览器配置文件（Profile）不匹配问题，但它无法突破频率限制、账号策略或站点的风控模型。

如何在多个 Agent 之间隔离浏览器配置文件和 Cookie？

给每个 Agent 分配独立的浏览器配置文件（Profile）或隔离的 Space，指定负责人并记录重置路径。多个 Agent 共用一个浏览器配置文件（Profile），会带来跨账号操作、Cookie 泄漏、扩展程序状态冲突，以及 Agent 读到本属于其他任务的数据等风险。

• 在威胁模型有要求时，使用不同的操作系统用户、容器或浏览器配置文件（Profile）目录；不要拿标签页名称当隔离边界。
• 按浏览器配置文件（Profile）设置扩展程序和网络目标白名单，并把下载、本地存储、缓存和 trace 都放在任务专属目录里。
• 重置时，关闭浏览器、吊销 Token、删除 Cookie 和浏览器配置文件（Profile）残留、清理日志，并确认没有进程仍占用锁或调试端口。

隔离属于纵深防御。它能减少意外串扰，但不会让恶意页面变安全，也不能免除最小权限授权和人工复核的必要性。

如何识别页面已过期和假成功？

要求提供证据，证明页面是最新的、请求的操作已生效。检查最终 URL、可见的标题或记录 ID、新的时间戳、预期的行数或字段数，以及每次写操作后的状态变化；HTTP 200 或点击了某个坐标都不能证明成功。

• 对时效性有要求时，刷新或重新查询，并把页面显示的周期与请求的日期范围做对比。
• 对于 canvas 或纯图片页面，改用第二种信号，例如 OCR、无障碍元数据或下载下来的产物，并把低置信度字段标记为不可用。
• 在检查点保存截图、trace、来源 URL 和检查时间，方便复核者重现结论。

可信的 Agent 会报告不确定并停下来。它绝不会用上一页的值填补缺失字段，也不会因为浏览器不再报错就宣称任务完成。

无头浏览器崩溃、清理失败时该怎么恢复？

让浏览器崩溃可恢复：把进程、浏览器配置文件（Profile）和队列条目当作彼此独立的状态。为导航和 evaluate 调用设置超时，在每个条目开始前持久化检查点，崩溃后用全新的上下文重启，而不是复用可能已损坏的会话。

• 启动时检测是否已有进程或浏览器配置文件（Profile）锁，确认它属于同一个任务，只有在进程已退出且锁确认过期后才删除。
• 使用带退避的有界重试；把浏览器崩溃与目标站点的 5xx 错误、认证失败、应用超时分开归类。
• 在 finally 块中关闭页面和上下文，限制内存和并发标签页数量，并保留崩溃日志和最后的 URL 用于诊断。

重启必须幂等。用记录键或检查点，避免进程中断后重复提交表单、重复下载文件或重复写入同一行。

Agent 能看到什么，扩展程序又如何影响隐私？

Agent 可能收到 DOM 或无障碍数据、截图、网络元数据、下载的文件，也可能只收到你返回的命令输出；浏览器模式本身并不决定这一点。要显式定义观察边界，并在工具响应到达模型之前，对密钥、个人数据、支付信息和无关标签页做脱敏。

• 审查扩展程序的权限和厂商的数据保留策略。广告拦截器会改变页面行为，密码管理器和隐私类扩展则可能暴露或修改敏感流程。
• 为敏感账号使用独立的浏览器配置文件（Profile），禁用不必要的扩展程序，并让 DevTools 或 CDP 端点保持本地且需要认证。
• 告诉 Agent 哪些域名和字段在范围内；不要让页面文本授予新的工具或权限。

本地执行能减少一部分数据传输，但它不是隐私保证。要把日志、截图、模型提供商、扩展程序和崩溃转储一并纳入数据流审查。

什么情况下不该用带持久配置文件的有头浏览器？

当 API、导出、数据库查询或服务端集成可用且已获授权时，不要用带持久配置文件的有头浏览器。对于大批量公开页面、确定性 CI、PDF 生成和可复现测试，无头自动化通常更便宜；浏览器无法替代受支持的数据接口。

• 稳定的结构化数据和明确的配额，用 API 或导出；可重复的断言和 CI，用无头测试运行器。
• 用户授权的交互式会话、视觉检查，或确实需要桌面环境的工作流，用带持久配置文件的有头浏览器；不要用它来注册账号或绕过访问控制。系统原生的打开和保存对话框不在页面内；不点击它们也能完成上传的路径见如何自动化原生文件对话框。
• 只有在确认支持 JavaScript、认证、渲染以及站点契约之后，才考虑原生浏览器引擎或 HTTP 客户端；更小的引擎可能不具备这些能力。

合适的架构能同时降低风险和维护成本。选择能产出工作流所需证据的最窄受支持接口，再为确实需要浏览器的场景保留一条回退路径。

FAQ

最适合 AI Agent 的无头浏览器是哪个？

对大多数 Agent 任务来说，是由 Playwright 驱动的无头 Chromium，因为它工具生态广、有四个官方语言家族，并能使用现代 Chromium 的无头模式；只做 Chrome 相关任务时 Puppeteer 更轻量，而 agent-browser 是专为 Agent 打造的 CLI。需要跨引擎覆盖时，Firefox 和 WebKit 的无头模式才有意义。

“最好”取决于任务：适合 CI 检查的无头浏览器，和适合对抗加固目标的无头浏览器可能不是同一个；而对加固目标来说，更好的答案往往是带持久配置文件的有头浏览器。

像 ego (lite) 这种浏览器，算有头浏览器吗？

两种说法都有用，但英文里的 real browser 并不是一个正式的行业分类。「有头」只说明渲染出了窗口，而 Playwright 启动的有头 Chromium 仍可能使用全新的自动化配置文件。本文所说的这种浏览器，指的是人日常在用的那种带持久配置文件的浏览器环境：已安装的配置文件、活跃会话，以及周围的桌面环境。ego (lite) 符合这个实用定义，因为它能在隔离的 Space 里继承已授权的 Chrome 会话。

网站能检测出无头浏览器吗？

能，但比以前更难了。Chrome 的新无头模式去掉了那些明显的特征（HeadlessChrome 的 user-agent 标记、缺失的插件数组），所以现在的检测更依赖自动化标志、环境信号（比如没有显示器）以及行为模式。它是一套打分机制，而不是单一检查，这也是为什么配置得当的无头环境能通过公开页面的检测，而粗心配置的仍会被识别。

Browser Use 应该以无头模式运行吗？

取决于任务，这个开关正是为此而设。无状态抓取和 CI 类任务用无头模式，成本和速度更优。目标站点有登录墙或防护严密时，用有头模式（或带持久配置文件的有头浏览器方案），一个可见、携带会话的浏览器值得付出资源成本。框架两种都支持，该由任务来决定用哪种。

有头浏览器一定更不容易被封禁吗？

不是。有头浏览器降低了基础检测面，但封禁看的是行为：任何浏览器里，人类不会产生的访问量、速度和访问模式都会被标记。一个被滥用驱动的有头浏览器，比一个在公开数据上谨慎爬取的无头爬虫更容易被检测到。浏览器决定了底线，你的行为决定你是否能留在底线上。

无头就意味着更快吗？

通常在单实例和规模化场景下是的，因为没有窗口需要渲染，实例可以密集打包并行工作。对于单个交互式任务，差别很小，而且如果站点封了无头实例、你不得不重试，速度优势就消失了。无头在其经济性适用的地方更快（大量无状态任务），并非普遍更快。

我能把登录信息共享给无头浏览器吗？

可以。Playwright 能加载保存的认证状态、添加 Cookie，或启动持久化上下文，但这些状态必须被创建、保护、刷新，并在过期时调试。如果重点是复用已有的授权登录，一个能在隔离 Space 内继承用户会话的带持久配置文件的有头浏览器工具可以省去注入步骤，代价是它是桌面浏览器，而不是适合 CI 的无头浏览器。

AI Agent 需要的是持久计算机，而不是沙箱吗？

需要的是适合任务的组合。临时沙箱适合隔离不受信任的一次性代码；持久计算机适合 Agent 必须在多次运行之间保留文件、已安装工具、记忆或浏览器会话的场景。最强的设计是把两者分层：隔离工作区，只持久化工作流需要的状态，并给用户清晰的方式来检查、重置、撤销或接管。

无头浏览器和有头浏览器有什么区别？

无头浏览器没有可见窗口，适合在服务器上做脚本化、并行的工作。本文中，有头浏览器指的是普通的持久桌面浏览器环境，带有用户授权的浏览器配置文件和活跃会话。实际的分界线往往是状态管理：全新的自动化上下文从空开始，而已有的持久会话已经准备就绪。

隐身插件能让无头浏览器无法被检测吗？

不能。puppeteer-extra-plugin-stealth 这类插件，或 Camoufox、Patchright 这类分支，能压制已知信号，但检测是动态对抗的，有实践者报告过隐身分支被封而默认 Playwright 通过的情况。隐身改变的是少数信号，买不来不可见、授权或可靠性。当合法任务依赖授权会话时，带持久配置文件的有头浏览器能减少配置文件不匹配的问题，但不承诺绕过任何管控。

选择下一步

如果你是在全新的 Playwright 工作流和隔离的携带会话的浏览器之间做选择，请阅读ego (lite) 与 Playwright 对比。如果任务需要已有的授权登录，下载 ego (lite)，并在单独的 Space 中启动，而不是把 Agent 接到你正在使用的浏览器窗口上。