Web Access Tools Decision

TLDR

本次只解决“浏览器能力应该怎么接入”这个问题

---

前几天刷twitter，看到 web-access-tools 这篇post

post原文

刷 GitHub，看到 几个给 AI Agent“接互联网”的开源项目

1.web-access

给 Claude Code 补完整上网能力，它可以直接接管你正在用的 Chrome，连登录态都能复用。你已经登录的小红书、GitHub、各种网站，AI 都能直接进去看。还可以开子 Agent 并行查资料，查多个网站时速度明显快很多。

2.Lightpanda

它是直接从零造了一个给机器用的浏览器。不是 Chromium 魔改，是 Zig 从头写的。
特点：更轻、更快、更适合 Agent。跑大规模网页抓取和自动化时，性能和内存占用都挺夸张，属于那种一看就知道是冲着 Agent 时代来的基础设施。

3.OpenClaw Zero Token

通过浏览器自动化去复用网页端能力，想办法绕开官方 API 付费体系，还做了一个兼容 OpenAI 的网关，能直接接很多第三方客户端。
一句话总结就是：一个项目，尽量把 ChatGPT、Claude、Gemini 这类工具都“白嫖式”串起来。不过这种玩法合规和安全风险都不小，看看思路可以，真上生产得谨慎小心。

4.bb-browser

通过扩展 + CLI + MCP，把真实浏览器直接变成 Agent 的操作入口。很多常用网站都已经做好适配，AI 想搜内容、看社区、翻新闻，基本开箱就能跑。

---

今天来做个evaluation，本文就是该选型过程的record

最终决定只安装 bb-browser

具体决策过程如下

【技术选型】对相关工具的基本认知

https://github.com/eze-is/web-access

https://github.com/tinyfish-io/tinyfish-cookbook

---

• web-access / bb-browser：和 agent-browser 最接近，都是“让 agent 操作真实浏览器”的上层入口，只是它们更偏 MCP / browser-extension 接入。
• TinyFish MCP：更偏“联网研究 / 网页抓取 / 结构化返回”的 MCP，不一定强调真实 DOM 交互、表单点击、登录态页面操作。
• Lightpanda：更像底层浏览器 runtime / 基础设施，不是你直接往 catalog 里放的那种 end-user skill。
• OpenClaw Zero Token：方向更像“网页端能力复用 + 网关旁路”，不只是 browser automation，而且合规/安全边界明显更差。

如果按“功能上是不是同类”来分：

• 第一类，真实浏览器交互：agent-browser、web-access、bb-browser。
• 第二类，网页研究/抓取：TinyFish MCP。
• 第三类，底层基础设施：Lightpanda。
• 第四类，灰色绕路/网关方案：OpenClaw Zero Token。

具体决策过程

首先排除掉 Lightpanda 和 OpenClaw Zero Token

Lightpanda

• 不再继续讨论。
• 原因：它更像底层浏览器 runtime / infra，而不是当前 dotfiles 里要接入的 agent-facing MCP 入口。
• 它解决的是“浏览器底层实现效率”问题，不是“给当前 agent 环境补一个长期主力浏览器入口”问题。

OpenClaw Zero Token

• 不再继续讨论。
• 原因：它的主要卖点并不是“浏览器能力抽象得更好”，而是带有明显灰色边界的网页端复用/旁路思路。
• 这类方案天然带来合规、稳定性和维护风险，不适合当前仓库追求的长期可维护能力栈。

这类 web-access 应该用 MCP 还是 skill?

• skill 是 workflow 层：定义什么时候用、怎么用、失败时怎么回退。
• MCP 是能力层：把浏览器本身作为长期可复用工具暴露给 agent。

浏览器属于基础能力，而不是单一 workflow。

因此这次应该优先决定“能力层接什么”，再决定以后是否还要叠加 browser skill。

所以排除掉 agent-browser 和 web-access 这两个skill

TinyFish MCP 与现有 mcp-servers.nix 的关系

https://www.tinyfish.ai/

TinyFish MCP，这个我觉得挺好，它能让 Claude 直接上网浏览、抓取网页、做资料调研，还能返回结构化结果，不只是给一段静态回答。我最近会拿它来给自己的周刊找 AI 新闻，比如抓最近几小时 Hacker News 上比较热门的内容，再整理成一份干净的摘要列表，效率很高。

---

现有相关能力：

• ddg
  • 搜索入口。
• chrome-devtools
  • 通用浏览器调试、页面观察、DOM 交互。
• octocode / deepwiki
  • repo / GitHub 研究。

判断：

• TinyFish MCP 与现有配置存在部分重叠，但不等价。
• 它更像“研究型网页 MCP”，不是“真实浏览器控制 MCP”。
• 只有在你明确经常做网页调研、结构化抓取、新闻/资料汇总，而且嫌 ddg + chrome-devtools 组合太散时，它才值得补。
• 当前没有必要与 bb-browser 一起同时引入。

具体实现

基于以上排除，最终在 web-access 和 bb-browser 这两个同类MCP里，选择了后者

---

• 在 home/base/tui/AI/mcp-servers.nix 中新增 bb-browser
• 暂不将 agent-browser 放入 home/base/tui/AI/skills-catalog.nix
• 暂不引入 TinyFish MCP

zzz [2026-04-03]

https://x.com/runes_leo/status/2037479240837579242

# https://x.com/runes_leo/status/2037479240837579242
# https://github.com/eze-is/web-access 也是少有的，将联网搜索和浏览器操控结合到一起的skill，也是我自己现在默认的联网skill了。Claude code本身自带的搜索工具，并不能够搜到非公开的站内信息，碰到小红书、B站这种站内内容，基本搜不到什么有用的东西。但装上这个skill之后，搜索能力就完全不一样了。可以通过Chrome DevTools Protocol直接连你本地的Chrome进程，带着你的登录状态，所以其实你平时登录过的微博、小红书、B站、飞书，它都能直接用，不需要重新登录。
# web-access
#  读推文 → xreach
#  公开网页 → Jina
#  需要登录的站 → web-access（CDP 直连 Chrome）
#  浏览器交互 → Chrome MCP
#  反爬 → Scrapling
#  JS 重渲染 → Playwright
#  全都不行 → XCrawl 兜底

**web-access 和 bb-browser 都是专为 Claude Code（以及类似 OpenClaw 等 AI Agent 框架）设计的开源 Skill，主要解决 AI 联网/浏览器自动化痛点：复用用户真实 Chrome 登录态、绕过反爬/登录墙、实现可靠网页操作。**

两者核心都通过 **Chrome DevTools Protocol (CDP)** 连接本地 Chrome，实现“你的浏览器就是 API”的效果。但实现思路和侧重点不同：
- **web-access**（repo: eze-is/web-access）强调**智能调度 + 通用自动化**，内置 3 层通道策略（WebSearch/WebFetch/curl/Jina/CDP 自动选择）、并行分治、站点经验积累。
- **bb-browser**（repo: epiral/bb-browser）强调**浏览器即 API + 平台预适配**，提供 36+ 平台（Twitter、Reddit、GitHub、知乎、B站、小红书等）、103 个高阶 CLI 命令，直接在页面上下文 eval JS / fetch（带真实 cookie），极致隐身。

### 为什么我选择这些对比项？
我慎重筛选了 **9 个最实用、最能体现差异的核心维度**（避免泛泛的“开源/免费”等无关项）：
- 优先考虑**用户实际体验**（安装、易用性）、**核心技术差异**（调度 vs 预适配）、**场景适配**（通用任务 vs 特定平台）、**性能/稳定性**（社区实测反馈）。
- 排除重复或不关键的（如两者都支持本地 Chrome、都开源 MIT 协议、都依赖 CDP）。
- 依据来自官方 GitHub、Zhihu/X 社区实测对比（如公众号/小红书/B站/GitHub 场景），确保客观且对 Agent 用户有指导意义。

### 对比表格（✅ = 该项明显优势 / 更强；❌ = 相对劣势 / 较弱；⚖️ = 基本相当）

| 对比项              | web-access                  | bb-browser                  | 优劣说明 |
|---------------------|-----------------------------|-----------------------------|----------|
| **安装配置难度**   | ✅（Claude Code Skill 一键安装，文档清晰） | ❌（早期需 Chrome 扩展，后续 CLI 简化但仍较繁琐） | bb-browser 配置门槛更高，社区反馈“去掉版本问题后难度仍大于 web-access”。 |
| **登录态复用**     | ⚖️（CDP 连接用户 Chrome） | ⚖️（CDP + 真实 tab 上下文） | 两者都极强，利用已有登录态，无需二次认证。 |
| **反检测/隐身能力**| ❌                         | ✅（JS eval + webpack 调用，网站以为是“真人”操作） | bb-browser 更激进，隐身效果更好，尤其反爬严格的平台。 |
| **通用浏览器自动化**（点击、输入、上传、复杂交互） | ✅（完整 CDP 操作 + 结构化浏览哲学） | ⚖️（支持但更偏 CLI 命令） | web-access 更适合复杂多步网页任务（如表单填写）。 |
| **特定平台适配**（知乎、B站、小红书等中文站点） | ❌                         | ✅（36 平台 103 命令，开箱即用结构化数据） | bb-browser 胜出，中文平台体验碾压，社区实测最优。 |
| **智能调度策略**   | ✅（3 层通道自动选择 + 并行分治 + 站点经验积累） | ❌                         | web-access 更“聪明”，能自主判断用搜索还是浏览器，长期越用越稳。 |
| **并行任务处理**   | ✅（支持多 Agent 并行）     | ❌                         | web-access 效率更高，适合批量任务。 |
| **输出结构化程度** | ⚖️（依赖 CDP 提取）        | ✅（预置 CLI 命令直接返回 JSON） | bb-browser 输出更规整，适合数据抓取/分析。 |
| **最佳适用场景**   | ✅（通用研究、复杂网页操作、需要智能决策的任务） | ✅（高频特定平台数据提取、极致隐身需求） | web-access 更万金油；bb-browser 在中文社交/视频平台场景更强。 |

### 总结建议（基于社区反馈）
- **选 web-access**：如果你追求**智能、通用、易用**，想让 Agent 像人一样“思考”怎么上网（搜索/浏览混合），推荐优先。适合大多数日常 Agent 任务。
- **选 bb-browser**：如果你重度依赖**特定平台**（尤其是中文网站），需要极致隐身 + 结构化 API 式调用，bb-browser 更合适。
- **可以两者共用**：很多用户同时装，两者互补（web-access 管调度，bb-browser 管特定站点）。

两者都在快速迭代，如果你有具体使用场景（比如某个网站），我可以再帮你细化推荐！

[2026-05-01]

这篇blog是我之前写的，你可以先做个勘误（并给我列出来），另外我有些问题：

1、这种 web-access 工具跟 chrome-devtools 是不是同类工具？

2、 # MAYBE: [2026-04-16] 找到更好用的 Agent Browser （尝试 GenericAgent） # https://linux.do/t/topic/1962519 # https://github.com/lsdefine/GenericAgent # https://linux.do/t/topic/1979802 需要你判断这个 GenericAgent 又跟上面这些 web-access-tools 以及 chrome-devtools 是啥关系？ --- 3、你觉得还有哪些相关的有价值问题？给我列出并解答

我按你贴出来的旧文，加上 2026-04-19 现在各项目官方 README / 文档，先给一个总判断：

你的核心判断方向大体没跑偏，但**最大的问题是把不同层级的东西混着比了**。更准确的分层应该是：

* **`GenericAgent`**：agent/runtime 层，本地自治代理框架，浏览器只是它的一部分。([GitHub][1])
* **`web-access`**：skill / workflow 层，做的是“联网策略 + CDP 浏览器 + 经验积累”的编排，不是单纯一个 MCP server。([GitHub][2])
* **`bb-browser`、`chrome-devtools-mcp`**：更接近能力层 / browser tool 层，前者偏“真实浏览器登录态 + 站点适配 + 结构化提取”，后者偏“DevTools 调试 / 性能 / 网络 / 控制”。([GitHub][3])

所以，`web-access-tools` 和 `chrome-devtools` 不是一句“同类”就能说清的；**它们同域，但不完全同层**。

## 一、先做勘误

### 1）“最终决定只安装 `bb-browser`”这句，和全文后面的实现不一致

从你贴的正文看，你的实际动作是“**新增 `bb-browser`**”，不是“系统里只保留 `bb-browser`”。因为你前文已经有 `chrome-devtools`，而且现在还在考虑要不要移除它。

更稳的改法：

> 最终决定：在新增候选里只引入 `bb-browser`；现有 `chrome-devtools` 暂时保留，后续再根据实际分工决定是否移除。

这个是**文内自相矛盾**，不属于外部事实问题，但很值得改。

### 2）“在 `web-access` 和 `bb-browser` 这两个同类 MCP 里，选择了后者”不准确

这句建议改掉。`bb-browser` 官方当前定位是 **CLI + MCP server for AI agents**，而 `web-access` 官方当前定位是 **给 AI Agent 装上完整联网能力的 skill**，里面再带自己的 CDP Proxy、调度策略和站点经验。也就是说，`web-access` 顶层是 **skill**，`bb-browser` 顶层是 **tool / MCP**。([GitHub][3])

更准确的写法：

> 在“浏览器能力入口”上，我选择 `bb-browser` 作为新增的 MCP；`web-access` 若要引入，应被视作 skill 层方案，而不是和 `bb-browser` 同层的 MCP 备选。

### 3）你把 `web-access` 描述成“更偏 MCP / browser-extension 接入”，有点缩窄了

`web-access` 官方现在强调的不只是“接浏览器”，而是 **WebSearch / WebFetch / curl / Jina / CDP 自动选择**、**CDP Proxy 浏览器操作**、**并行分治**、**站点经验积累**。它的价值不只是浏览器入口，更是“联网工作流编排”。([GitHub][2])

更好的说法：

> `web-access` 不是单点浏览器工具，而是一个把“搜索、抓取、CDP 操作、经验复用”捏在一起的联网 skill。

### 4）你后面那段对比文里，把 `bb-browser` 说成“早期需 Chrome 扩展，配置门槛更高”，现在看已经过时了

`bb-browser` 当前官方 README 的标准路径是 `npm install -g bb-browser`，然后 CLI / daemon / MCP 使用；架构上是 `CLI -> Daemon -> CDP WebSocket -> 真实浏览器`。另外它还明确写了 **OpenClaw 模式不需要额外安装扩展**。所以“它现在主要靠扩展，安装更繁琐”这个说法，至少按当前官方文档，已经不适合作为主叙述。([GitHub][3])

更稳的改法：

> `bb-browser` 当前主路径是 CLI / MCP + daemon + CDP 连接真实浏览器；历史上你看到的扩展形态，不该再写成它的主安装印象。

### 5）“中文平台体验碾压”“社区实测最优”“长期越用越稳”这类结论，建议降调

这些句子不一定错，但**官方文档本身并不能直接证明**。官方能证明的是：

* `bb-browser` 有 36 个平台、103 个命令、支持用真实登录态执行 `eval` / `fetch` / network / screenshot / click / fill。([GitHub][3])
* `web-access` 有自动工具选择、CDP、并行分治、站点经验积累。([GitHub][2])

所以更推荐写成 feature-based 结论，而不是“碾压 / 最优”这种总评。

### 6）你对 `chrome-devtools` 的描述偏“浏览器交互”，但漏掉了它最独特的部分

`chrome-devtools-mcp` 的强项不是“能不能点按钮”本身，而是 **performance trace、DevTools insight、network / console 调试、Lighthouse / 性能分析**。官方直接把它定位成 **reliable automation + in-depth debugging + performance analysis**。([GitHub][4])

这不是硬伤，但你这篇文如果要更完整，建议补一句：

> `chrome-devtools` 的不可替代点在于 DevTools 语义：调试、性能、请求、控制台，而不只是浏览器自动化。

---

## 二、问题 1：这种 web-access 工具和 `chrome-devtools` 是不是同类工具？

我的结论：**广义上同域，狭义上不同类。**

### 广义上：算同域

它们都在解决“给 agent 补 Web / browser access”这个问题，都能碰真实浏览器、登录态页面、页面交互。`web-access` 用 CDP Proxy 连日常 Chrome；`chrome-devtools-mcp` 让 agent 控制和检查 live Chrome；`bb-browser` 也是把你的真实浏览器当 API。([GitHub][2])

### 狭义上：不该归成一个类

更准确的分类是：

* **`chrome-devtools-mcp`**：DevTools 型 browser MCP。强在调试、网络、控制台、性能、trace，也能做自动化。([GitHub][4])
* **`bb-browser`**：browser-native site adapter / extraction 型工具。强在真实登录态、页面上下文 `eval` / `fetch`、平台适配、结构化返回，也兼顾通用自动化。([GitHub][3])
* **`web-access`**：联网 orchestration skill。强在自动挑搜索/抓取/CDP 路径、并行、多站点经验复用。([GitHub][2])

所以最准确的一句话是：

> **`bb-browser` 和 `chrome-devtools` 更接近“同层不同风格”；`web-access` 更像“上层调度者”。**

### 顺带回答你最开头那个“要不要移除 `chrome-devtools`”

我不建议因为装了 `bb-browser` 就立刻移除。

保留它的条件很简单：只要你还会做下面任一类事，就值得留：

* 看 console / network
* 抓请求细节
* 跑 performance trace
* 做 Lighthouse / performance insight
* 调试网页行为而不是只做内容抓取

这些正是 `chrome-devtools-mcp` 官方强调的核心能力。`bb-browser` 虽然也有 `network requests`、`eval`、`screenshot`、`click`、`fill`，但它的中心不是 DevTools 语义。([GitHub][4])

反过来，假如你的主要需求已经变成：

* 带登录态抓站内内容
* 做结构化站点提取
* 跑知乎/B站/小红书/GitHub/招聘站这类适配命令
* 偶尔点点填填就够了

那 `bb-browser` 可以当主力，而 `chrome-devtools` 可以考虑移除，或者至少降级成“只在 debug/perf 场景启用”的备用工具。([GitHub][3])

---

## 三、问题 2：`GenericAgent` 跟这些 web-access-tools 以及 `chrome-devtools` 是什么关系？

结论先说：**`GenericAgent` 不是又一个浏览器 MCP；它是一个更大的 agent runtime。**

官方 README 对它的自我定义是：一个 **minimal, self-evolving autonomous agent framework**，通过 9 个原子工具给 LLM 系统级控制本地电脑的能力，覆盖 **browser、terminal、filesystem、keyboard/mouse、screen vision、ADB**。它自己对比的对象也是 `OpenClaw`、`Claude Code` 这种 agent/runtime，而不是 `bb-browser` 或 `chrome-devtools-mcp`。([GitHub][1])

### 它和上面几类工具的关系，最好这么看

#### 1）和 `chrome-devtools`

不是替代关系，而是**层级不同**。

* `chrome-devtools-mcp`：一个可插拔的浏览器 MCP，主打 DevTools 能力。([GitHub][4])
* `GenericAgent`：一个本地自治代理框架，浏览器只是它的一个子系统。它内置 `web_scan`、`web_execute_js` 等浏览器工具，还能同时控终端、文件、键鼠、屏幕、ADB。([GitHub][1])

所以，**在 `mcp-servers.nix` 里把 GenericAgent 当作 `chrome-devtools` 的并列替代项，不太对。**

#### 2）和 `bb-browser`

两者都重视“真实浏览器 + 保留登录态”，但目标不同。

* `bb-browser` 是一个给别的 agent 用的 CLI/MCP/browser adapter 工具，强调站点适配、带 Cookie 的 `fetch`、页面内 `eval`、结构化返回。([GitHub][3])
* `GenericAgent` 是一个自己带 agent loop、记忆、技能生长的系统。它的浏览器能力来自自身工具链；官方文档里还提到 `web_scan / web_execute_js` 基于 Chrome 扩展接管真实浏览器，复杂场景再走 CDP bridge。([GitHub][1])

所以，`GenericAgent` 更像“**包含了一个浏览器子系统的 agent OS**”，而 `bb-browser` 更像“**可插拔的浏览器能力模块**”。

#### 3）和 `web-access`

这两个在“哲学”上反而有一点像：都强调经验/技能积累。

* `web-access` 强调站点经验积累、联网策略、并行分治，是 skill 形态。([GitHub][2])
* `GenericAgent` 强调 self-evolving，把执行路径固化成 skill tree。([GitHub][1])

但它们还是不同层：

* `web-access` 是给现有 agent 叠加联网 workflow。
* `GenericAgent` 是直接提供一个 agent runtime，本体就带循环、记忆、工具、自进化。

### 对你这套 dotfiles 来说，最实用的判断

* **`GenericAgent` 不该被归进 “web-access-tools 候选 MCP” 这一栏。**
* 它更适合被归进：**“是否额外引入一套本地自治 agent runtime”** 这个议题。
* 所以它和 `bb-browser` / `chrome-devtools` 不是一个决策层面；跟 `web-access` 也只是“哲学相邻”，不是同种安装位点。

一句话版：

> **`GenericAgent` 不是下一个 browser MCP；它是一个带浏览器能力的 agent 系统。**

---

## 四、问题 3：还有哪些相关的有价值问题？我给你列出并直接解答

### 1）这些东西应该分别放在哪一层配置里？

这是最有价值、也最容易配错的问题。

我的建议是：

* **`mcp-servers.nix`**：放 `bb-browser`、`chrome-devtools-mcp`
* **skills / skills-catalog**：放 `web-access`
* **独立 app / service / launcher**：放 `GenericAgent`

理由很直接：`bb-browser` 官方是 CLI + MCP，`chrome-devtools-mcp` 官方是 MCP server，`web-access` 官方是 skill，`GenericAgent` 官方是 autonomous agent framework。([GitHub][3])

### 2）在“主力浏览器能力”上，到底该让谁当默认？

按场景分最清楚：

* **站内搜索 / 登录态抓取 / 平台适配 / 结构化返回**：`bb-browser` 更合适。([GitHub][3])
* **网页调试 / console / network / performance / trace**：`chrome-devtools-mcp` 更合适。([GitHub][4])
* **希望 agent 自己决定用搜索还是抓取还是 CDP**：`web-access` 更合适。([GitHub][2])
* **想跑一个长期自进化、本地电脑全控的代理**：那是 `GenericAgent` 的题目。([GitHub][1])

### 3）这些方案里，风险最大的差异是什么？

三个最重要的风险点：

第一，**真实登录态复用**。`bb-browser` 直接在你的浏览器 tab 里跑 `eval`，用你的 Cookie 做 `fetch`；`GenericAgent` 的 web 工具也是接管真实浏览器并保留登录态；`web-access` 的 CDP 模式同样直连你的日常 Chrome。权限都很高。([GitHub][3])

第二，**对社交平台的账号风险**。`web-access` 官方甚至明确提醒：通过浏览器自动化操作社交平台，存在限流或封禁风险。([GitHub][2])

第三，**`chrome-devtools-mcp` 的默认遥测/连接面**。官方说明它默认会收集 usage statistics；而 `--autoConnect` 会尝试连接你正在运行的 Chrome，接入默认 profile 的所有已开窗口，并弹权限确认。你现在这份配置正是 `--autoConnect --channel stable`，这比 isolated/headless 模式更贴近日常浏览器，也更敏感。([GitHub][4])

所以，哪怕你保留 `chrome-devtools`，我也建议至少考虑把 `--no-usage-statistics` 加上。([GitHub][4])

### 4）`bb-browser` 和 `chrome-devtools` 要不要同时保留？

可以，但前提是**明确分工**。

推荐分工：

* `bb-browser`：内容获取 / 站点适配 / 登录态提取
* `chrome-devtools`：调试 / 性能 / 请求 / 控制台

这样互补性很强。([GitHub][3])

不推荐的情况是：你让两个工具都承担“随便打开网页、点点点、抓内容”的模糊职责。那样 agent 选工具时会更乱，人自己维护也更累。

### 5）如果只能留一个，留谁？

我会这样选：

* **你更像“内容研究 / 站点抓取 / 登录态操作”用户**：留 `bb-browser`。([GitHub][3])
* **你更像“前端调试 / 性能 / 排查请求”用户**：留 `chrome-devtools-mcp`。([GitHub][4])
* **你更在意 agent 的联网决策质量**：那其实不是二选一，而是该加 `web-access` 当 skill。([GitHub][2])
* **你想要的是一整套本地自治 agent**：另开 `GenericAgent` 这个议题，不要和 MCP 选型混在一起。([GitHub][1])

---

## 我给你的最终建议

你的博客结论，建议收敛成这版：

> 这次真正的决策不是“所有 web-access 项目里选一个”，而是先分清层级：
> `chrome-devtools` / `bb-browser` 属于能力层浏览器工具，`web-access` 属于联网 workflow skill，`GenericAgent` 属于更上层的 agent runtime。
> 在当前 dotfiles 里，我新增 `bb-browser` 作为登录态网页能力入口；`chrome-devtools` 是否移除，取决于我是否还需要 DevTools 调试 / 性能 / 网络分析。`web-access` 若要引入，应放到 skill 层，而不是拿来和 MCP 直接二选一。`GenericAgent` 则应单独作为“是否引入本地自治 agent 框架”来评估。

基于你现在这套配置，我的倾向是：

* **先不要删 `chrome-devtools`**
* 先把它的定位改成“debug/perf 专用”
* 让 `bb-browser` 成为“登录态抓取 / 站点适配主力”
* 真要做下一轮整理，再讨论要不要把 `web-access` 加到 skill 层
* `GenericAgent` 单开一篇，不要塞进这篇“浏览器能力接入”里

你要的话，我下一条可以直接把这篇 blog 的“勘误后版本”帮你改成一版可直接贴回去的正文。

[1]: https://github.com/lsdefine/GenericAgent/blob/main/README.md "GenericAgent/README.md at main · lsdefine/GenericAgent · GitHub"
[2]: https://github.com/eze-is/web-access/tree/main "GitHub - eze-is/web-access: 给 Claude Code 装上完整联网能力的 skill：三层通道调度 + 浏览器 CDP + 并行分治 · GitHub"
[3]: https://github.com/epiral/bb-browser/blob/main/README.zh-CN.md "bb-browser/README.zh-CN.md at main · epiral/bb-browser · GitHub"
[4]: https://github.com/ChromeDevTools/chrome-devtools-mcp/ "GitHub - ChromeDevTools/chrome-devtools-mcp: Chrome DevTools for coding agents · GitHub"

结论是 chrome-devtools-mcp 需要保留，因为跟 web-access-tools 的能力并不完全重合

而 GenericAgent 实际上是个agent (类似 codex, cc 这种的)，能这么理解吗？

对，可以这么理解，而且这两个结论都成立。

第一，**`chrome-devtools-mcp` 需要保留**，前提是你还在乎 DevTools 这一整套能力：它官方定位就是给 AI assistant 提供 “reliable automation, in-depth debugging, and performance analysis”，也就是不只是“能操作网页”，还包括调试、性能分析、trace、network、console 这些更偏开发/排障的能力。这个和 `web-access` / `bb-browser` 那类“上网访问、登录态读取、站点交互/提取”能力有明显交集，但**不完全重合**。([GitHub][1])

第二，**`GenericAgent` 基本可以理解成一个 agent，本质上更像 Codex / Claude Code 这一层，而不是一个单独的 browser MCP**。它官方自我描述是 “minimal, self-evolving autonomous agent framework”，通过 agent loop 和一组原子工具，给 LLM 提供对本地电脑的系统级控制，覆盖 browser、terminal、filesystem、keyboard/mouse、screen vision、ADB 等。也就是说，浏览器只是它能力集合里的一个子模块，不是它的全部。([GitHub][2])

所以你可以直接把关系写成这句：

> `chrome-devtools-mcp` 是浏览器/DevTools 能力工具；`web-access` 是联网 workflow/skill；`GenericAgent` 是更上层的 agent runtime。

再压缩一点：

> `GenericAgent` ≈ “一个能自己跑任务的 agent 框架”；
> `chrome-devtools-mcp` ≈ “给别的 agent 用的浏览器调试工具”。

你这轮结论里，最稳的一版表述是：

> 保留 `chrome-devtools-mcp`，因为它和 web-access 类工具存在交集，但其 DevTools 调试、性能分析、网络观察能力并未被完全覆盖；而 `GenericAgent` 不属于同层 browser MCP，它更接近一套本地自治 agent 框架。

你要的话，我可以下一条直接把这句话改写成适合放进 blog 的正式段落。

[1]: https://github.com/ChromeDevTools/chrome-devtools-mcp/blob/main/README.md?utm_source=chatgpt.com "chrome-devtools-mcp/README.md at main - GitHub"
[2]: https://github.com/lsdefine/GenericAgent/blob/main/README.md?utm_source=chatgpt.com "GenericAgent/README.md at main · lsdefine/GenericAgent"