skill刚开源就斩获 1.7K Star！web-access让AI真正“上网“

实测中,我用 10 个子 Agent 同时调研小红书、微博、B站、GitHub、知乎等 10 个平台,一次性打开 100 个网页,CPU 占用始终在可控范围内,而每个子 Agent 的执行速度几乎和单独跑一个任务一样快。最离谱的是,有时候它还会用 WebSearch 去搜索小红书、微博这些平台的站内内容——就像用百度去搜朋友圈,除了瞎忙活,什么也搜不到。这就是为什么 web-access 能够处理

datayx

623人浏览 · 2026-03-31 08:36:48

datayx · 2026-03-31 08:36:48 发布

向AI转型的程序员都关注公众号机器学习AI算法工程

你是否也遇到过这些尴尬时刻？

让 Claude 去查某个技术文档,结果它只能搜到一些过时的博客文章;

想让它帮你收集某个开源项目的最新动态,但 GitHub 上那些需要登录才能看到的内容,它完全无法访问;

最离谱的是,有时候它还会用 WebSearch 去搜索小红书、微博这些平台的站内内容——就像用百度去搜朋友圈,除了瞎忙活,什么也搜不到。

这些问题的根源不在 Claude 本身,而在于它缺了一样东西:真正意义上的联网能力。

最近开源的 web-access Skill,就是要彻底解决这个痛点。让我用实战案例告诉你,它到底能做什么。

从单工具到工具链:智能调度的底层逻辑

web-access 的核心不是"给 Claude 装个浏览器"这么简单。它的真正威力在于,把联网从"单一工具选择"升级为"智能工具链调度" 。

五层工具的精准分工

不同于传统方案中"要么全靠搜索,要么全靠浏览器"的粗暴做法,web-access 设计了一套五层工具链:

快速信息层:
WebSearch → 搜索引擎入口
Jina → 高效内容提取(比 WebFetch 节省 75-99% token)

深入访问层:
WebFetch → 获取静态网页
curl → HTTP 请求、API 调用

浏览器操作层:
CDP Proxy → 完整的浏览器自动化

这个分层设计的精妙之处在于,web-access 会根据任务特点自动选择最优工具组合:

场景一:查询某个 API 文档

WebSearch 找到官方文档链接
WebFetch 或 Jina 直接获取内容
整个过程几秒钟完成,无需启动浏览器

场景二:获取需要登录的 GitHub 私有仓库信息

自动切换到 CDP 模式
复用你 Chrome 中已登录的 GitHub session
访问私有仓库,提取你需要的 commit 历史、Issue 列表

场景三:调研小红书上某个话题的讨论热度

识别出这是需要站内搜索的平台
直接启动 CDP 浏览器
在小红书内执行搜索、翻页、提取内容
自动识别哪些是"热门推荐",哪些是"最新发布"

关键差异:传统方案中,模型往往被关键词"搜索"锚定,导致它在需要浏览器操作时还在用搜索引擎。web-access 通过 Skill Prompt 设计,让模型理解任务本质而非执行步骤。

CDP Proxy:为什么选择 Chrome 原生协议?

在 web-access 之前,我也试过其他浏览器自动化方案,比如 Puppeteer、Playwright。但它们都有一个共同问题:启动速度慢,资源占用大。

web-access 最终选择了 Chrome DevTools Protocol(CDP),这个决定让它实现了三个关键突破:

1. 共享你的登录态,而不是另起炉灶

CDP 直连你日常使用的 Chrome 浏览器,这意味着:

你在 GitHub 上登录的账号,web-access 能直接使用
你在小红书、微博上保存的 Cookie,全都能复用
不需要为 AI 单独配置一套"虚拟身份"

对比一下传统方案:

表格

方案	登录态处理	配置复杂度
Puppeteer/Playwright	需要手动导出 Cookie 文件	高
Browser MCP	需要单独维护 Profile	中高
web-access (CDP)	直接复用 Chrome 已登录状态	低

2. 单浏览器多 Tab,真正的并行不干扰

web-access 的并行机制有一个容易被忽略但至关重要的设计:所有子 Agent 共享同一个 Chrome 实例,但各自操作独立的 Tab。

这意味着:

同时调研 10 个网站,只启动一个 Chrome 进程
每个子 Agent 有独立的 Target ID,互不干扰
不会出现"抢浏览器控制权"的情况——浏览器照样你可以用,AI 在后台 tab 里忙它的

实测中,我用 10 个子 Agent 同时调研小红书、微博、B站、GitHub、知乎等 10 个平台,一次性打开 100 个网页,CPU 占用始终在可控范围内,而每个子 Agent 的执行速度几乎和单独跑一个任务一样快。

3. 视频截帧、DOM 深度操作

CDP 让 web-access 能够做一些其他方案做不到的事情:

视频内容分析:

# 获取视频时长
curl-s"http://localhost:3456/eval?target=ID"\
-d'document.querySelector("video").duration'

# 跳转到第 60 秒并截图
curl-s-X POST "http://localhost:3456/eval?target=ID"\
-d'var v=document.querySelector("video"); v.currentTime=60; v.play()'

# 等待 2 秒让视频渲染
sleep2

# 截取当前帧
curl-s"http://localhost:3456/screenshot?target=ID&file=/tmp/frame.png"

DOM 深度遍历:

很多网站的元素藏在 Shadow DOM 或 iframe 里,普通的选择器根本点不到。web-access 的 /eval 命令可以直接执行 JavaScript,递归遍历所有层级,找到你需要的元素。

实战案例:多平台内容调研

让我用一个真实案例,展示 web-access 的多任务并行能力。

任务需求

调研"AIGC 工具"这个话题在以下平台的热度和讨论点:

小红书 (用户分享)
知乎 (专业问答)
GitHub (开源项目)
B站 (视频教程)
Hacker News (国际技术圈)

每个平台提取 10 条最热门的内容,最后汇总成一份综合报告。

传统方案的耗时

如果你手动做这个调研:

每个平台平均需要 15-20 分钟(搜索、筛选、阅读、整理)
5 个平台串行处理,总耗时 1.5-2 小时
整理汇总还需要额外 30 分钟

总计:约 2 小时

web-access 方案的执行

对 Claude 说一句话:

帮我用 web-access 开 5 个子 Agent,分别去:
1. 小红书 → 搜索"AIGC工具",找 10 个讨论度高的笔记
2. 知乎 → 搜索"AIGC",找 10 个高赞回答
3. GitHub → 搜索"AIGC",找 10 个最近活跃的开源项目
4. B站 → 搜索"AIGC",找 10 个播放量高的视频
5. Hacker News → 找首页前 10 条与 AIGC 相关的帖子

最后汇总成一份报告,分析每个平台的关注重点

执行过程:

Claude 自动识别这是多平台并行任务
创建 5 个子 Agent,每个分配一个独立端口
所有子 Agent 共享同一个 CDP Proxy,但各自打开独立的 Chrome Tab
并行执行,每个 Agent 只需要处理自己的平台
主 Agent 接收汇总后的结果,不浪费 token 在中间内容上

实际耗时:约 5-7 分钟

效率提升:20 倍以上

输出质量对比

表格

维度	手动调研	web-access
信息覆盖	容易遗漏	系统性覆盖
数据提取	部分靠记忆	精准提取
时效性	可能看到过时内容	实时获取最新
整理成本	高	自动汇总

站点经验积累:越用越聪明的秘密武器

web-access 最让我惊喜的设计,是它的经验沉淀机制。

它是如何工作的?

每次 web-access 完成一个平台的访问后,会自动保存以下信息:

按域名存储:
- URL 模式(哪些 URL 可以直接构造,哪些必须模拟点击)
- 平台特征(小红书需要登录才能看到完整内容,GitHub 私有仓库需要认证)
- 已知陷阱(某些页面会跳转到登录页,某些按钮有延迟加载)
- 成功的操作路径(如何最快地找到目标内容)

下次再访问同一个域名时,web-access 会直接复用这些经验,跳过试错环节。

实际效果对比

第一次访问小红书:

尝试用 WebSearch 搜小红书站内内容 → 失败
切换到 CDP 模式
发现需要登录 → 暂停,提示用户登录
登录后重新访问,搜索目标内容
试了几次才找到正确的翻页方式
总耗时:约 3 分钟

第二次访问小红书:

直接加载 CDP 模式(知道小红书需要登录)
使用已知的搜索 URL 模式(无需手动搜索框)
直接使用正确的翻页逻辑
总耗时:约 45 秒

效率提升:4 倍

这是一个持续优化的过程。你用得越多,它积累的经验越丰富,执行速度越快。

安装配置:5 分钟上手指南

前置要求

Node.js 22+
(CDP Proxy 需要)
Chrome 或 Edge 浏览器
Git Bash
(Windows 用户需要)

安装步骤

1. 启用 Chrome 远程调试

在 Chrome 地址栏输入:

chrome://inspect/#remote-debugging

勾选"Allow remote debugging for this browser instance",可能需要重启浏览器。

2. 让 Claude 自动安装

直接对 Claude 说:

帮我安装这个 skill:https://github.com/eze-is/web-access

Claude 会自动完成以下操作:

下载 skill 文件到 ~/.claude/skills/web-access
检测并安装依赖
配置环境

3. 验证安装

运行检查脚本:

bash ~/.claude/skills/web-access/scripts/check-deps.sh

如果一切正常,会看到"CDP mode ready"的提示。

4. 启动 CDP Proxy

node ~/.claude/skills/web-access/scripts/cdp-proxy.mjs &

这个命令会在后台启动 CDP Proxy 服务,默认监听 http://localhost:3456。

常用命令速查

web-access 的所有操作都通过 curl 调用 HTTP API,这里列出最常用的几个:

页面操作

# 创建新 tab 并打开指定 URL
curl-s"http://localhost:3456/new?url=https://example.com"

# 获取页面信息
curl-s"http://localhost:3456/info?target=ID"

# 在页面中执行 JavaScript
curl-s-X POST "http://localhost:3456/eval?target=ID"\
-d'document.title'

# 截取当前页面
curl-s"http://localhost:3456/screenshot?target=ID&file=/tmp/shot.png"

# 导航到新 URL
curl-s"http://localhost:3456/navigate?target=ID&url=https://new-url.com"

# 后退
curl-s"http://localhost:3456/back?target=ID"

# 关闭 tab
curl-s"http://localhost:3456/close?target=ID"

交互操作

# JS 点击(适合大部分常规按钮)
curl-s-X POST "http://localhost:3456/click?target=ID"\
-d'button.submit'

# 真实鼠标点击(适合对点击方式有严格校验的网站)
curl-s-X POST "http://localhost:3456/clickAt?target=ID"\
-d'.upload-btn'

# 文件上传(直接设置文件路径,绕过文件对话框)
curl-s-X POST "http://localhost:3456/setFiles?target=ID"\
-d'{"selector":"input[type=file]","files":["/path/to/file.png"]}'

# 滚动页面(触发懒加载)
curl-s"http://localhost:3456/scroll?target=ID&y=3000"

# 滚动到底部
curl-s"http://localhost:3456/scroll?target=ID&direction=bottom"

管理操作

# 列出所有打开的 tab
curl-s"http://localhost:3456/targets"

实战话术模板

为了让 web-access 发挥最大威力,这里整理了一些常用的 Prompt 模板:

单平台调研

帮我去小红书搜索"[关键词]",提取前 20 条热门笔记,
分析它们的共同特点、用户关注点、热门标签,
最后给出一份总结报告

多平台并行调研

帮我用 web-access 开 N 个子 Agent,分别调研:
1. 小红书 → 搜索"[关键词]",找 X 条内容
2. 知乎 → 搜索"[关键词]",找 X 条内容
3. GitHub → 搜索"[关键词]",找 X 个项目
...

最后汇总成对比分析报告,说明各平台的差异和关注重点

内容采集

帮我去[网站],找到[目标内容],提取其:
- 标题
- 正文
- 发布时间
- 作者信息
- 图片 URL

整理成结构化数据返回给我

网站自动化测试

帮我测试[网站]的用户注册流程:
1. 打开注册页面
2. 填写测试数据
3. 提交表单
4. 检查是否跳转到成功页面
5. 如果有错误,截图并记录

每一步都要截图保存

常见问题解决

Q1: 为什么 CDP 模式启动失败?

可能原因:

Chrome 没有启用远程调试
端口 3456 被占用
Node.js 版本低于 22

解决方法:

# 检查 Chrome 远程调试是否启用
chrome://inspect/#remote-debugging

# 检查端口占用
lsof-i :3456  # macOS/Linux
netstat-ano| findstr :3456  # Windows

# 检查 Node.js 版本
node-v

Q2: 为什么某些网站还是打不开?

可能原因:

网站有严格的人机验证
网站检测到自动化工具
需要特定的 Cookie 或 Token

解决方法:

在你自己的 Chrome 中先手动登录一次
等待 web-access 暂停并提示你手动操作
检查网站是否有反爬策略

Q3: 如何提高任务执行速度?

优化建议:

合理使用子 Agent 分治(适合多平台、多目标任务)
优先使用 Jina 提取内容(比 WebFetch 节省 token)
避免不必要的截图(只在需要视觉验证时截图)
充分利用站点经验积累(常用网站会越来越快)

性能对比:web-access vs 其他方案

基于我的实测,这里给一个客观的对比:

表格

维度	web-access	Browser-use	Playwright MCP	Chrome DevTools MCP
Token 消耗	低	极低	较高	中等
登录态处理	共享 Chrome	支持 Profile	需手动处理	共享 Chrome
并行能力	高	中	低	中
资源占用	低	中	高	中
上手难度	低	中	高	中
适用场景	通用联网	纯浏览器操作	自动化测试	调试开发