AI Agent 的浏览器能力：三层分类与选型逻辑

---

1. 引言

1.1 问题从何而来

在 AI Agent 大规模进入开发工作流之前，"Web 自动化"这个领域有一个清晰的坐标轴。说到 UI 自动化，就是 Selenium / Cypress / Playwright / Appium。说到数据抓取，就是 Scrapy / Puppeteer / curl。界线分明，不容易混淆。

但过去两年，情况发生了质变。一批新工具集中涌现：

Chrome DevTools MCP、Playwright MCP、Midscene MCP、browser-use、Stagehand、Shortest、web-access、bb-browser、OpenCLI、AutoCLI、TinyFish MCP、Lightpanda……

这些工具的名字里可能有相同的关键词（MCP、browser、web），看起来做的事情也重叠——"让 AI 操作网页"。但一旦你真的去比较它们，就会陷入混乱：Chrome DevTools MCP 和 Playwright MCP 有什么区别？Midscene 和 browser-use 是不是同类？bb-browser 和 OpenCLI 谁更适合抓数据？

这些比较的共同问题是：比较的前提就错了。 它们根本不在同一个能力层上。

1.2 这篇文章在做什么

本文不是工具测评。它不会告诉你"Playwright 比 Cypress 好在哪里"或"bb-browser 比 web-access 强在哪里"——这些结论会随着版本更新迅速过时。

本文提供一个判断框架：不要按工具分类，要按能力层分类。 在这个框架下，任何新工具出现时，你都能快速回答"它属于哪一层？""它的主战场是什么？""它和我现有的工具链是什么关系？"

这个框架来自对过去几个月实际决策过程的整理和反思——从最初把 web-access 和 chrome-devtools 混着比，到后来逐步发现它们根本不同层、不同类。这篇文章就是这段认知过程的输出。它是一篇"判断框架文"，不是一篇"工具测评文"。

1.3 先看结论：三层能力总图

在展开讨论之前，先把结论放在前面：

能力层	核心问题	典型工具	是否产生测试资产
Browser Control	Agent 能不能操作浏览器？	Chrome DevTools MCP / Playwright MCP / Midscene MCP	不一定
Reusable E2E	测试能不能沉淀为可复用资产？	Playwright Test / Midscene YAML / Shortest	是
Web Access / Data Extraction	网页数据能不能拿到？	bb-browser / OpenCLI / TinyFish	不一定

这三层是讨论 Web 自动化的基本坐标系。它们不是工具类别，而是能力维度——一个工具可以覆盖多个能力，但通常只有一个主战场。当你把任何一个工具放对位置，所有的比较和选型就都说得清楚了。

---

2. 三层能力

2.1 Browser Control——让 Agent 能操作浏览器

定义与边界

Browser Control 是整个三层中最基础的一层，也是 AI 时代新增工具最多、最活跃的一层。它解决的核心问题只有一个：Agent 能不能操作一个真实的浏览器？

这个问题的答案涉及一系列能力：打开页面、观察 DOM / accessibility tree / screenshot、点击、输入、滚动、切换 tab、抓 console / network / performance trace、复用登录态或浏览器 profile。

它的边界同样清晰：Browser Control 不承诺可复跑、不承诺断言、不承诺 CI 集成。 它只承诺一件事——Agent 现在能控制这个页面了。至于控制完之后拿这个操作来做什么（沉淀成测试、提取数据、还是临时调试），它不负责。

内部细分：三种发力方向

虽然同属 Browser Control 层，但不同工具的发力点差异很大。理解这些差异，是避免选型错误的关键。

调试/诊断型——Chrome DevTools MCP

Chrome DevTools MCP 的核心不可替代点在于 DevTools 语义。它不是来"点按钮"的，它是来调试的：

• 让 Agent 控制真实 Chrome
• 查看 DOM / accessibility tree
• 查看 console 输出和 JS 错误
• 查看 network 请求细节
• 抓 performance trace
• 跑 Lighthouse 做性能分析
• 做 debug / verification

它的官方定位很明确：给 AI assistant 提供 reliable automation, in-depth debugging, and performance analysis。也就是说，它的核心场景是开发期验证和失败诊断，而不是作为 E2E 测试框架。

Chrome DevTools MCP 很适合开发期验证和失败诊断，但它本身不是一个 E2E 测试框架。

另外需要特别注意它的连接模型：--autoConnect 会尝试连接你正在运行的 Chrome，接入默认 profile 的所有已开窗口。这在提供便利的同时也意味着权限极高——你个人的登录态、cookie、浏览记录都对 MCP server 开放。官方说明它默认会收集 usage statistics，建议至少加上 --no-usage-statistics 参数。

交互/操作型——Playwright MCP

Playwright MCP 是微软官方提供的 MCP server，让 Agent 通过 Playwright 驱动浏览器。它的侧重点和 Chrome DevTools MCP 不同：

• 让 Agent 通过结构化 accessibility snapshot 与页面交互
• 导航、点击、输入、截图、tabs、network 控制
• 支持 browser_run_code 执行自定义 Playwright 片段
• 探索 UI、生成测试草稿
• 辅助调试 Playwright 脚本

Playwright 官方 repo 现在把产品形态分得很清楚：Playwright Test 用于 E2E 测试资产；Playwright CLI 给 coding agent 用；Playwright MCP 给 AI agents / LLM-driven automation；Playwright Library 用于浏览器自动化脚本。

Playwright MCP 是能力入口，Playwright Test 才是测试资产。两者是上下游关系，不是替代关系。

视觉驱动型——Midscene MCP / Skills

Midscene 在这一层的定位比较特殊。它基于视觉模型操作 UI，不依赖 DOM selector，因此非常适合传统 selector 不稳定的场景：canvas、shadow DOM、非标准控件、跨端 UI。

Midscene 提供两种 Agent 入口：

• MCP 服务：把 Midscene Agent 的动作暴露成 MCP tools，支持 Web bridge、iOS、Android、computer desktop
• Agent Skills：让 AI coding tools 通过 CLI 驱动 UI automation，不需要 MCP server

它支持的平台覆盖面很广：Web、Mobile（Android/iOS）、Desktop、HarmonyOS。这种视觉驱动 + 跨端覆盖的组合，使它填补了 Playwright MCP 和 Chrome DevTools MCP 覆盖不到的那块——"UI 太复杂，selector 搞不定，但我要 Agent 能操作它"。

但同时也要注意，Midscene 的特殊之处在于它同时覆盖了两层：MCP / Skills 是 Browser Control 入口，YAML / SDK 是可复用测试脚本。这种"跨层"能力让它成为一个例外，而不是规则。

常见误区

在研究过程中，我收集了几个最常见的认知偏差，值得单独列出：

❌ "有 MCP 的都算 Browser Control"

一个工具采用 MCP 协议暴露接口，只说明它的接入方式是 MCP，不说明它属于哪一层。bb-browser 也是 MCP，但它的主战场是 Web Access / Data Extraction——它用 MCP 暴露的是站内数据提取能力，不是浏览器调试能力。MCP 是传输层，不是能力层。

❌ "Browser Control 就是 E2E 测试"

Agent 操作了一次页面，不等于形成了一个测试资产。Browser Control 是一次性的操作入口，E2E 是沉淀下来的可复跑脚本。把"Agent 点了按钮"等同于"E2E 测过了"，是当前最危险的认知偏差——它让人误以为产品已经经过了质量验证，实际上 Agent 只是做了一次无法复现的操作。

❌ "工具能操作页面，所以它是 E2E 框架"

能点 ≠ 能测。E2E 要求可复现的 setup、确定性或边界化的断言、artifact 捕获、失败诊断、CI 集成。Chrome DevTools MCP 能操作页面，Playwright MCP 能操作页面，browser-use 能操作页面——但它们都不是 E2E 框架。唯一真正属于 E2E 框架的，是 Playwright Test 这种产生测试资产的东西。

---

2.2 Reusable E2E Script——测试必须沉淀成可复用资产

什么才算真的 E2E 测试资产

如果说 Browser Control 是"能操作"，Reusable E2E 就是"能复跑"。两层的分水岭在于一个问题：你的测试是不是一份可以提交进 repo、在 CI 里作为门禁、被团队长期维护的资产？

我整理出 5 条判断标准，用来区分"一次性的 Agent 操作"和"真正的 E2E 测试资产"：

1. 是否有可复用脚本？ 不是 Agent 临时点了一遍，而是文件化的测试代码（.spec.ts / .yaml / .test.ts），可以进版本管理。
2. 是否有明确断言？ 不是"看起来没问题"，而是可量化的成功/失败标准。expect(locator).toBeVisible() 是断言，agent prompt 里的"确认页面正常"不是断言。
3. 是否能进 CI/CD？ 能在流水线里作为发布门禁，失败则阻断发布。Playwright Test 有 --forbid-only、--retries、--reporter 这些 CI 原生设计；Agent 操作后的"看起来通过了"不行。
4. 是否有失败报告？ trace、screenshot、video、HTML report——至少要有其中两项以上的失败证据留存，否则失败无法定位。Playwright 的 trace viewer 提供了完整的操作回放、DOM 快照、网络请求、控制台日志，这就是资产级的证据设计。
5. 是否能被团队长期维护？ 有版本、有 review、有重构空间。一个测试脚本如果写完后没人敢改、改了就挂，那它不是资产，是债务。

Playwright / Midscene YAML / Shortest 的能力分层

Playwright Test：确定性 E2E 的主干

Playwright Test 在这一层的位置是天花板级的。它提供的不是"浏览器自动化"，而是一个完整的测试资产系统：

• Web-first assertions：断言自动等待目标状态满足，不需要手写 sleep 或 waitForTimeout。这不是便利性问题，而是 flaky 管理的根本手段。
• Actionability checks：Playwright 在操作前会等待元素可见、稳定、可接收事件、已启用——这些检查把"不确定的浏览器状态"变成"可预测的操作环境"。
• Trace Viewer：录制完整的操作回放，包含每个 action 的 DOM 快照、网络请求、控制台日志、时间轴。对 AI 修复循环来说，trace 是根因分析的关键证据。
• 原生工程化设计：配置文件版本化、fixture 依赖注入、describe/tag 组织、双 reporter（list + html）、并行执行、CI 集成。

Playwright 并不只是一个"写测试的库"——它是一个测试资产管理系统。使用 Playwright Test 产出的脚本，可以被提交、被 review、被重构、在 CI 里稳定跑上百次。这种"资产属性"是 Browser Control 层的工具无法提供的。

（Playwright 的具体最佳实践和 3SQ 框架已在《Playwright 最佳实践》中详细展开，本文不做重复。）

Midscene YAML：AI 视觉驱动的可复用脚本

Midscene YAML 是这一层里最值得关注的 AI 原生方案。它的核心价值在于：

• 自然语言步骤：用人类能读懂的描述编写测试流程，而非 Playwright 的 page.click() 语法
• 视觉定位：基于视觉模型识别 UI 元素，不依赖 DOM selector，适用于 canvas、shadow DOM、复杂 UI
• CLI runner：midscene ./xxx.yaml 直接运行，生成可视化 HTML/JSON 报告
• 跨端覆盖：Web / Android / iOS / Desktop / HarmonyOS

Midscene YAML 的定位是"Playwright 的 AI/视觉增强层，而不是完全替代 Playwright"。它最适合的路径是：Agent 生成 YAML 脚本 → 人审阅 → 进 CI 跑 → 用报告排查。

Shortest：自然语言 E2E 的实验方向

Shortest 是走得更极端的方案——底层 Playwright，但测试直接用自然语言描述：

shortest("Login to the app using email and password")

优点很明显：写测试的门槛极低，适合快速补覆盖。它支持 hooks、callback assertions、reusable flows、CI 集成。

但问题同样明显：执行过程依赖 LLM。每次运行都会调用 LLM 解析自然语言描述、决定操作步骤。这意味着：

• 确定性弱于手写 Playwright——同样的描述在不同 LLM 版本下可能产生不同的执行路径
• 成本和速度要评估——每次测试运行都有 LLM 调用开销
• flaky 来源从"页面不稳定"增加到"LLM 输出不稳定"

所以我建议 Shortest 的使用场景是：探索性测试、低风险业务流、快速补覆盖、生成 Playwright 测试前的过渡层。它不应该作为唯一的发布门禁。

与 Browser Control 的上下游关系：MCP 是入口，E2E 是资产

Browser Control 和 Reusable E2E 的关系不是替代，而是上下游：

Browser Control（探索入口）→ 生成草稿/调试失败 → Reusable E2E（资产沉淀）

一个理想的 Agent 驱动 E2E 工作流：

PR 提交
  → Agent 用 Playwright MCP 探索页面结构
  → Agent 生成 Playwright spec 草稿
  → 人 review selector、assertion、fixture
  → CI 跑 Playwright Test
  → 失败时 Agent 用 Chrome DevTools MCP 看 console/network/perf
  → Agent 修复 spec 或代码
  → 再跑回归

在这个工作流里，MCP 是 Agent 获得能力的入口，Playwright Test 是最终资产。不要把入口当终点，也不要把资产降级成入口。

---

2.3 Web Access / Data Extraction——核心不是测试，是获取信息

定义与典型场景

Web Access 是三层里最容易被误解的一层。人们看到"工具能打开网页"，就以为它在做 E2E 测试。实际上，它的目标完全不同：不是"证明产品没问题"，而是"获取网页上的信息"。

E2E 测试关注的是流程是否稳定正确——"这个按钮点完之后，状态是否变化符合预期？"Web Access 关注的是内容是否能拿到——"这个页面上的信息，Agent 能不能读到？"

典型场景：

• 搜索资料和研究：让 Agent 搜索特定关键词，阅读多个页面后综合回答
• 读取登录态页面：需要 Agent 访问你的登录态才能看到的页面——公司内网、社交媒体、带权限的文档
• 提取结构化数据：竞品调研、批量抓取公开信息、监控价格/状态变化
• 调研竞品页面：对比多个网站的布局、内容、定价策略
• 让 Agent 访问 JS 重渲染页面：静态 fetch 拿不到的内容，需要浏览器渲染后才能访问

核心工具的选择逻辑：方案 vs 工具

在 Web Access 这一层，有几个常用的接入点，它们的定位差异值得仔细区分。

bb-browser——"浏览器即 API"的预适配方案

bb-browser 通过 CLI / MCP / daemon + CDP 连接真实浏览器，核心思路是把你的真实浏览器变成 Agent 的 API。它的关键能力：

• 36+ 平台预适配：Twitter、Reddit、GitHub、知乎、B 站、小红书等平台都有预置 CLI 命令
• 103 个高阶 CLI 命令：每个平台 2-5 个命令，覆盖搜索、读取、内容获取等常见操作
• JS eval + webpack 调用：直接在页面上下文执行 JS，使用真实 cookie，网站以为是真人操作
• 结构化返回：预置 CLI 命令直接返回 JSON，适合数据抓取/分析场景

bb-browser 的主战场是"高频特定平台的结构化数据提取"。如果你每天都要让 Agent 去知乎搜几篇文章、去 B 站看视频信息、去 GitHub 读 issue，bb-browser 开箱即用的体验远好于自己写脚本。

但它是"预适配"思路——有适配的平台体验极好，没适配的平台就只能退回到通用 CDP 操作，灵活性不如通用方案。

web-access（skill 形态）——智能调度的编排者

web-access 的定位和 bb-browser 不同。它不是一个纯工具，而是一个"联网策略编排器 + CDP 浏览器 + 经验积累"的 skill。它内置的策略不止 CDP：

• WebSearch：搜索入口
• WebFetch / curl / Jina：静态或代理抓取
• CDP Proxy：浏览器操作
• 并行分治：多 Agent 并行查多个网站
• 站点经验积累：越用越知道某个站点该怎么抓

web-access 的价值在于"调度"。如果目标信息能通过搜索拿到，它不启动浏览器；如果静态 fetch 能拿到，它不用 CDP。这种智能决策让它在"不知道这个网站能不能直接抓"的场景下特别好用。

所以 web-access 和 bb-browser 不是"A 好还是 B 好"的关系——它们是互补的。web-access 管调度决策，bb-browser 管特定站点的执行效率。很多社区用户同时装两者。

TinyFish MCP——研究型网页 MCP

TinyFish 的方向更窄：网页研究 / 抓取 / 结构化返回。它在调研型场景中很实用——抓 Hacker News 热门内容、整理摘要、返回结构化结果。它不强调 DOM 交互、表单点击、登录态页面操作，而更像"让 Agent 能快速调研一个主题"的数据管道。

它和 ddg（搜索入口）+ chrome-devtools（页面观察）的组合存在部分重叠，但在研究型场景下比后两者更专注：TinyFish 一条命令完成"搜索 → 抓取 → 结构化"组合，ddg + chrome-devtools 需要 agent 两步操作。

OpenCLI / AutoCLI——面向未来的浏览器接入框架

OpenCLI 是一个通用的 CLI + MCP 框架，通过 adapter 机制接入各种浏览器操作能力。它不预设站点，而是提供一个"让 Agent 能用命令行访问网页"的通用入口。

AutoCLI 更进一步，强调自动化适配：Agent 提出需求，AutoCLI 自动选择合适的 adapter 完成操作。两者代表的方向是"广度优先"——什么网站都可能碰，我不提前适配，但我提供一个机制让 Agent 能快速适配。

私域 CLI 扩展：一个值得注意的趋势

在通用工具之外，还有一个值得单独提的趋势：围绕特定私域构建的 CLI 接入层。

tg-cli 操作 Telegram、discord-cli 读 Discord、wx-cli 操作微信——这些工具在语义上属于 Web Access 层。它们不是"通用浏览器"入口，而是"特定平台的适配入口"，核心逻辑和 bb-browser 完全一致：把真实浏览器的登录态和页面能力，封装成一个 Agent 可以直接调用的接口。

如果你做的是一个面向开发者的工具生态，为你的平台提供一个 CLI 扩展，可能比提供一个网页版 API 更容易被 AI Agent 集成。

与 Browser Control 的关系

Web Access 和 Browser Control 在技术上有重叠（都操作浏览器），但意图不同：

• Browser Control 解决："Agent 能不能操作这个页面？"
• Web Access 解决："Agent 能不能拿到这个页面上的信息？"

bb-browser 是最能说明这种区别的例子。它通过 CDP（Chrome DevTools Protocol）连接真实浏览器——这套协议和 Chrome DevTools MCP 用的是同一套底层机制。但 bb-browser 使用 CDP 不是为了调试页面或诊断性能，而是为了带着登录态拿到站内信息。它的目标不是控制浏览器，而是通过浏览器获取数据。

这也验证了前面说的元认知：一个工具可以跨层，但它的主战场只有一个。 bb-browser 用了 Browser Control 的技术，但它的产品目标是 Web Access / Data Extraction。Chrome DevTools MCP 也能操作页面，但它的产品目标是调试/诊断。

所以在你的能力地图里，bb-browser 属于 Web Access / Data Extraction 层，Chrome DevTools MCP 属于 Browser Control（调试/诊断）层。它们同技术域，但不同能力层。

---

3. 选型结论

3.1 工具→能力层的最终映射

回到实际接入场景，经过对每个工具的官方文档、社区反馈和实际使用体验的梳理，我的最终映射如下：

工具	所属能力层	理由
Chrome DevTools MCP	Browser Control（调试/诊断型）	核心是 DevTools 语义：perf / network / console / Lighthouse
Playwright MCP	Browser Control（交互/操作型）	Agent 入口，不是测试资产
Midscene MCP / Skills	Browser Control（视觉驱动型）	Agent 实时操作 UI 的入口
Midscene YAML	Reusable E2E	脚本格式 + CLI runner + 报告 + CI
Playwright Test	Reusable E2E	确定性测试框架，发布门禁
bb-browser	Web Access / Data Extraction	核心是 site-specific 结构化提取，不是通用浏览器操作
OpenCLI / AutoCLI / TinyFish	Web Access / Data Extraction	通用/特定站点内容读取
web-access skill	跨层编排（上层调度者）	整合搜索、抓取、CDP 操作、经验复用，不属于单一能力层

3.2 几个核心判断

Playwright Test 和 Playwright MCP 是两个东西。 前者是测试资产，后者是 Agent 入口。官方分得清楚，使用者也要分清楚。把 Playwright MCP 当成"Playwright 的 AI 版"而把 Playwright Test 替换掉，会同时失去资产层和入口层。

bb-browser 和 Chrome DevTools MCP 的取舍取决于你的使用模式。 如果主要诉求是"带登录态抓站内内容 + 平台适配 + 结构化返回"，bb-browser 已覆盖大部分场景，可以当主力。但如果还需要 DevTools 调试 / performance / network 分析，保留 Chrome DevTools MCP 是有价值的——两个工具可以共存，前提是角色分工清楚：bb-browser 管内容获取，Chrome DevTools MCP 管调试/性能。

web-access（skill 形态）是一个上层调度者，不是和它们同层的工具。 它把搜索、抓取、CDP 操作、经验积累整合到一起，适合做 Agent 的联网入口。如果要引入 web-access，应该放在 skill 层，而不是拿来和 MCP 直接二选一。

GenericAgent 不应该出现在这个对比表里。 GenericAgent 是一个"带浏览器能力的本地自治 agent 框架"，本质上是和 Claude Code / Codex 同层的东西，不是一个 browser MCP。如果评估它，应该单独开议题"是否引入一套本地自治 agent runtime"，不要和这个选型表混在一起。

3.3 快速决策指南

如果你的主要场景是…	优先配置	备注
控制浏览器、调试页面、排查问题	Chrome DevTools MCP	开发期验证和失败诊断的首选
Agent 探索页面、生成测试草稿	Playwright MCP	和 Playwright Test 配合使用
UI 操作复杂、selector 不稳定	Midscene MCP / Skills	视觉驱动，适合复杂 UI 和跨端
业务链路回归、发布门禁	Playwright Test	不可替代的测试资产层
视觉驱动可复用测试	Midscene YAML	适合复杂 UI / 跨端场景
带登录态抓站内内容	bb-browser	平台适配最广，结构化返回最佳
研究型网页抓取	TinyFish MCP	专注网页研究/结构化返回
通用联网策略编排	web-access skill	上层调度者，负责决策用哪种通道

---

4. 扩展视野：从三层到七层能力地图

前三层（Browser Control / Reusable E2E / Web Access）覆盖了"AI 怎么访问、理解、操作网页"这个范围。如果讨论范围就是 Web 自动化，三层基本足够。

但如果讨论的是从开发到测试验证的完整闭环——从 PR 提交到上线后持续验证——三层还不够。

下面四层是前者的自然延伸。它们与前三层没有直接竞争关系，但在一个成熟工程体系中是不可或缺的。

4.1 API / Contract Testing

UI E2E 是最贵、最慢、最容易 flaky 的验证方式。服务契约问题应该在 API / Contract 层提前发现，而不是靠浏览器点一遍来验证。

核心观点：Reusable E2E Script 验证用户路径；API / Contract Testing 验证服务边界。

典型的 Contract 测试工具和场景：

• Pact：consumer-driven contract testing，服务间调用契约的验证
• Postman / Newman：API 自动化测试和 CI 集成
• Schemathesis：基于 schema 的 API 属性测试
• supertest：Node.js 轻量 HTTP 断言

为什么这一层必须单独列？因为很多问题根本不该靠 UI E2E 测——前后端接口不兼容、字段类型变更、可选字段变成必选——这些在 API 层就能发现的问题，用 UI E2E 来测不仅成本高，而且定位复杂。

API / Contract Testing 与 E2E 的分工：

E2E: 验证"用户能不能完成一个业务操作？"
Contract: 验证"服务之间的约定有没有被破坏？"

两者分开，独立跑，独立门禁。

4.2 Component / Visual Regression

E2E 能证明流程走通，但不一定能发现 UI 错位、样式回归、组件状态异常。这一层验证的是局部 UI 正确性，不是业务链路。

典型工具和场景：

• Storybook：组件开发、组件交互测试、设计系统文档化。不是 E2E 替代品
• Chromatic：Storybook 的视觉回归平台，每次 commit 自动截图 + diff
• Percy：快照 + 视觉差异对比 + reviewer 审核流程
• Applitools：Visual AI + Ultrafast Grid，跨浏览器并行验证
• Playwright screenshot tests：轻量截图比较

与 E2E 的区别：

E2E: 验证完整业务链路
Component / Visual: 验证局部 UI 状态和视觉一致性

视觉回归验证的是一个不同的失败类：布局回归、渲染差异、缺失元素、样式断裂。它不能替代功能断言（"发票已创建"、"支付已确认"这类业务结果还是要 E2E 或 API 测），但 E2E 也替代不了它——E2E 的断言粒度不足以发现"按钮左移了 2px"这类视觉问题。

另外需要注意：视觉测试在动态内容、日期、动画、第三方小部件、A/B 测试广告等场景下会非常嘈杂。需要 baseline、ignore region、确定性数据和 review workflow 来管理。

4.3 LLM / Agent Evaluation

如果你的产品包含 LLM、RAG、Chatbot 或 Agent，这一层是强制性的，不是可选的。

为什么？传统 E2E 只能验证"页面流程是否走通"，不能验证"AI 回答是否正确"。 一个 RAG 应用可以在 UI E2E 中完全通过——页面正常渲染、搜索结果正常展示——但检索到的上下文完全无关，或者生成的回答包含幻觉。UI E2E 发现不了。

评估资产不是 test script，而是：

• eval dataset：评估用例集
• golden answer：标准答案
• rubric：评分标准
• judge prompt：用来评估输出的 prompt
• metric：评估指标（faithfulness / relevancy / precision / recall）
• red-team cases：安全/毒性的对抗测试用例

典型工具：

• promptfoo：prompt / RAG / Agent 的自动化评测、安全红队、CI/CD 集成
• DeepEval：类似 pytest 的 LLM 测试框架
• LangSmith：LangChain / Agent / RAG 追踪 + 离线评测 + 线上监控
• OpenAI Evals：评估 LLM 系统输出质量的框架
• Ragas：RAG 评估（faithfulness、answer relevancy、context precision/recall）

对于 AI 功能，测试闭环需要从"断言 DOM 状态"扩展到"评估输出质量、工具调用轨迹、RAG 命中率、幻觉、安全性"。UI E2E 验证回答出现了，eval 层验证回答是否正确、可信、安全、有用。

注意： LLM eval metrics 本身并非完美的。RAG 评估指标（faithfulness、answer relevancy 等）有用，但取决于测试集质量和 judge 模型可靠性。任何一个"eval score 提升了 X%"的主张，都必须附带 dataset、judge model、prompt、样本量和置信区间。

4.4 Observability / Synthetic Monitoring

CI 里全绿，不代表线上真实用户没问题。E2E 是发布前验证，Observability / Synthetic Monitoring 是发布后持续验证。

核心能力：

• 分布式追踪（Tracing）：请求在微服务间的完整路径，定位延迟和错误源头
• 指标（Metrics）：延迟分布、错误率、吞吐量、饱和度
• 日志（Logging）：结构化日志，可搜索可关联
• 错误追踪（Error Tracking）：Sentry 类工具，聚合错误并按影响面排序
• 合成监控（Synthetic Monitoring）：定时用 Playwright 脚本模拟真实用户操作，探测线上可用性
• SLO / SLI：服务等级目标，量化"线上是否健康"

典型工具：

• OpenTelemetry：厂商中立的 observability framework（traces / metrics / logs）
• Sentry：错误追踪和性能监控
• Datadog / Grafana / Prometheus：指标 + 可视化 + 告警
• New Relic：APM + 浏览器监控
• Checkly：Playwright 合成监控，专为现代栈设计

这一层是从"测试"走向"闭环"的关键。没有这一层，E2E 测试覆盖的环境和真实生产环境就是两个世界——预发布环境全绿但上线即 crash，是很多团队的日常。

4.5 七层能力总表与推荐流水线

能力层	解决什么	典型工具	是否测试资产
Browser Control	Agent 操作浏览器	Chrome MCP / Playwright MCP / Midscene MCP	不一定
Reusable E2E	业务流回归	Playwright Test / Midscene YAML / Cypress	是
Web Access / Extraction	读取网页数据	bb-browser / OpenCLI / TinyFish	不一定
API / Contract Testing	服务边界验证	Pact / Postman / supertest	是
Component / Visual	UI 状态和视觉回归	Storybook / Percy / Applitools	是
LLM / Agent Eval	AI 输出质量	promptfoo / DeepEval / LangSmith	是
Observability	上线后持续验证	OTel / Sentry / Datadog / Checkly	是，但偏运行时

推荐的整体架构：

开发阶段：
  Agent + Playwright MCP / Chrome DevTools MCP / Midscene Skills

测试资产：
  Playwright Test + Midscene YAML + API / Contract tests

UI 质量：
  Storybook + Visual Regression

AI 功能：
  promptfoo / DeepEval / LangSmith

上线后：
  OpenTelemetry + Sentry + Synthetic Monitoring

从 PR 到上线后的完整流水线：

PR 创建
  ↓
Unit / API / Contract tests（快速验证服务边界）
  ↓
Playwright E2E（验证关键业务链路）
  ↓
Visual Regression（验证 UI 一致性）
  ↓
LLM / Agent Eval（验证 AI 输出质量）
  ↓
Preview 环境验证（人工或 Agent 探索性验证）
  ↓
发布
  ↓
Synthetic Monitoring + Observability（持续验证线上健康度）
  ↓
失败自动归因，回写 Issue / PR（修复闭环）

---

5. 方法论总结

不要把这篇文章当成工具选型清单，它只是一个判断框架。框架的价值不在于给出答案，而在于提供一种提问的方式。

如果你只从这篇文章带走三件事，我希望是这三句：

第一，先问能力，再问工具。

不要问"Chrome MCP 和 Playwright 谁更好"，问"我现在需要哪种能力——是操作浏览器、沉淀测试资产、还是获取网页数据？"能力层比工具选型更重要，前者决定框架，后者决定实现。框架选对了，工具可以换；框架选错了，工具换再多也解决不了根本的问题。

第二，一个工具只有一个主战场。

Chrome DevTools MCP 可以操作页面、可以辅助 E2E、可以提取数据——但它的主战场是 DevTools 调试/诊断。bb-browser 用了 CDP 协议，可以做 Browser Control 的事——但它的主战场是结构化数据提取。搞清楚一个工具的主战场，比罗列它能做什么更有价值。主战场告诉你在什么场景下优先用这个工具，其他场景只是"也能用但不是最擅长的"。

第三，完整闭环不是配齐工具，而是填补能力缺口。

七层能力地图的真正价值不是让人"配齐七层"，而是让你检查自己的工程体系在哪一层存在缺口。如果你做的是 AI 产品但没有 LLM / Agent Eval 层，那问题是"缺失了能力"，而不是"少装了一个工具"。填补能力缺口，比在已有的层上加更多工具重要得多。

最后，关于本文的结构本身也有一层元认知：文章的三层分类来自于"先把最核心的概念抽象出来，再扩展边界"的思考方式。这种框架优先、细节填充的方法论，比直接讨论"Playwright vs Midscene vs bb-browser"更容易持续迭代——因为工具会变，但你在哪一层做事、要解决什么问题，不会变。