發現了一個叫web-access的神仙skill，AI聯網有救了
整理版優先睇
web-access 透過 CDP Proxy 直接操控瀏覽器，保留登錄態，解決 AI 聯網時嘅登錄牆同動態頁面問題，係 Claude Code 用家嘅必備神器。
呢篇文章嘅作者係一位經常用 Claude Code 寫 code 嘅開發者，佢一直覺得 Claude Code 嘅聯網能力好弱，連微信公眾號內容、小紅書搜尋、甚至需要登錄嘅網站都搞唔掂，等咗半年終於發現一個叫 web-access 嘅開源項目。呢個項目一週就拿到 2.8K Star，因為真係踩中咗好多人嘅痛點。
web-access 嘅核心技術係用 Chrome DevTools Protocol（CDP）直接操作你嘅瀏覽器，唔係模擬 HTTP 請求，而係真係控制 Chrome 做所有嘢。佢喺 CDP 外面包咗一層 HTTP API，叫 CDP Proxy，令到 Agent 可以透過普通 curl 指令控制瀏覽器，例如打開 URL、執行 JavaScript、點擊元素、截圖等。最大嘅好處係，因為係操作你日常用開嘅 Chrome，所以所有登錄態、cookie、token 都天然保留，唔使另外處理。
整體結論係：web-access 提供咗一條新路——讓 Agent 直接操控瀏覽器，好似真人咁打開頁面、等待渲染、點擊連結。相比起傳統嘅聯網方式（搜尋加抓取），呢種「瀏覽」式嘅聯網更能處理動態頁面、登錄牆同反爬機制，真正提升 AI 嘅聯網能力。作者仲分享咗三個實測案例，包括競品調研、小紅書用戶討論同 GitHub 技術週報，展示咗效率提升。最後佢話，工具嘅上限決定咗你能做嘅嘢嘅邊界，所以值得一試。
- web-access 透過 CDP Proxy 直接操控瀏覽器，保留登錄態，係目前最實用嘅 AI 聯網方案。
- 底層用 Chrome DevTools Protocol，提供 HTTP API 控制瀏覽器，包括導航、執行 JS、點擊、截圖等。
- 相比 MCP chrome-devtools 同 Puppeteer，最大優勢係天然攜帶瀏覽器登錄態，可以直接訪問小紅書、微信公眾號等需要登錄嘅網站。
- AI 聯網唔應該侷限於搜尋加抓取，而係讓 Agent 好似真人咁瀏覽網頁，漸進式升級工具（先輕量後瀏覽器）。
- Claude Code 或 Codex 用家可以安裝 web-access，尤其係處理動態頁面或需要登錄態嘅任務時，效率提升明顯。
web-access GitHub 專案
一個開源項目，透過 CDP Proxy 讓 AI 操控瀏覽器，解決聯網問題。
AI 聯網嘅痛點終於有解
作者用咗半年 Claude Code，寫 code 確實好勁，但聯網能力真係唔掂。叫佢去抓微信公眾號內容、小紅書搜嘢、或者訪問要登錄嘅網站，佢只會循環話「無法訪問」。
呢個痛點忍咗半年，直到發現 web-access 呢個神仙 skill
web-access 係一個開源項目，出一週就拎到 2.8K Star，唔係因為作者營銷叻，而係真係踩中咗真實痛點。
CDP Proxy 係點樣運作？
web-access 底層用 Chrome DevTools Protocol（CDP），即係你按 F12 開開發者工具時背後嘅協議。透過 CDP，外部程序可以連接 Chrome 做幾乎所有嘢。
- 控制導航：打開 URL、前進後退、刷新頁面
- 執行腳本：喺頁面上下文中直接運行 JavaScript
- 操作 DOM：讀取節點內容、修改樣式、觸發事件
- 模擬輸入：鍵盤打字、鼠標點擊、頁面滾動
- 監聽網絡：捕獲所有 HTTP 請求和響應
- 生成截圖：任何時候將當前視口截成圖片
web-access 喺 CDP 外面包咗一層 HTTP API，叫 CDP Proxy。變咗做普通 HTTP 調用，例如：
# 列出當前所有標籤頁
curl http://localhost:3456/targets
# 在指定標籤頁執行JS
curl "http://localhost:3456/eval?target=xxx" -d 'document.title'
# 點擊頁面某個元素
curl "http://localhost:3456/click?target=xxx" -d 'button.submit'
# 截圖保存當前視口
curl "http://localhost:3456/screenshot?target=xxx"就係咁簡單，Agent 可以透過呢啲 API 直接操控瀏覽器，唔使另外處理複雜嘅協議。
點解 CDP Proxy 更適合 AI 聯網？
相比 MCP chrome-devtools 同 Puppeteer，web-access 嘅 CDP Proxy 有個核心優勢：登錄態。
- 1 CDP Proxy：複用你日常用開嘅 Chrome，天然攜帶所有登錄態、cookie 同 token。
- 2 MCP chrome-devtools：每次開新瀏覽器實例，要重新登錄，好麻煩。
- 3 Puppeteer：都係開新實例，同樣要處理登錄問題。
呢個差別好大——你喺 Chrome 登錄咗小紅書、微信公眾號、公司內網，Agent 透過 CDP Proxy 操作呢個瀏覽器，直接就可以訪問，唔使再做任何額外登錄步驟。
核心區別就一個：登錄態
另外，CDP Proxy 嘅調用方式係 HTTP API，比起其他方案嘅專有協議更加簡單直接。
三個實測案例，效率提升明顯
作者用 web-access 做咗三個測試，效果好好。
- 1 競品調研：以前要自己開三個標籤頁逐個睇文檔，快都要兩三個鐘。用 web-access 後，Agent 同時派出三個子 Agent 並行調研 Dify、Coze、FastGPT，時間同調研一個差唔多，三倍提效。
- 2 小紅書用戶討論：小紅書反爬機制好完善，但 web-access 直接接管 Chrome 嘅小紅書標籤頁，Agent 可以好似真人咁瀏覽，唔使擔心被封。
- 3 GitHub 技術週報：Agent 先試用 WebFetch，發現部分內容要 JavaScript 渲染，就自動升級到 CDP 模式。呢個體現咗漸進式升級原則：輕量方式行得通就用輕量，唔得就上瀏覽器。
以前 Agent 聯網係「搜索」，而家係「瀏覽」
呢兩個動詞背後嘅能力差距，大概就等於叫人幫你查資料，同叫人幫你實地走訪一圈嘅差距。
從工具到思路嘅轉變
web-access 令作者重新思考 AI 聯網嘅本質。以前覺得聯網就係搜尋加抓取：調用搜索引擎 API，拎摘要，塞入上下文，輸出答案。但呢套遇到動態頁面、登錄牆、反爬機制就玩唔轉。
呢種思路改變咗聯網嘅方式，令 AI 真正有能力接觸實時、動態、需要登錄嘅資訊。
工具嘅上限，決定咗你能做嘅嘢嘅邊界
啊。
我俾AI嘅聯網能力激死咗半年，終於揾到解藥。
講真，Claude Code寫code真係好勁，其他工具冇得比。但係佢嘅聯網能力……點講好呢，就係好廢。
你試下叫佢去拎個微信公眾號嘅內容？唔得。叫佢去小紅書揾啲嘢？唔得。叫佢幫你查啲要登入先睇到嘅嘢？佢會喺度loop一百次然後話你知「無法訪問」。
我就覺得奇怪，你一個AI唔聯網可以做到啲乜？同盲嘅冇分別。
直到前幾日我發現咗一個開源項目——web-access。一個禮拜時間，2.8K Star。
01 技術原理
先講技術。web-access底層係用Chrome DevTools MCP加CDP直接連瀏覽器。用通俗啲講法，佢唔係模擬HTTP請求，而係真係操作緊你個瀏覽器。
呢度有個關鍵概念要拆開嚟講：CDP係乜？
CDP係Chrome DevTools Protocol嘅縮寫。你撳F12打開開發者工具，底層就係佢支援。透過CDP，外部程式可以經WebSocket連接Chrome，然後做幾乎所有你喺開發者工具入面做到嘅嘢：
- 控制導航：打開URL、前後頁、重新整理
- 執行腳本：喺頁面上下文直接執行JavaScript
- 操作DOM：讀取節點內容、修改樣式、觸發事件
- 模擬輸入：鍵盤打字、滑鼠點擊、頁面滾動
- 監聽網絡：捕獲所有HTTP請求和回應
- 生成截圖：任何時候將當前視窗截成圖片
web-access喺CDP外面包咗一層HTTP API。呢個就係CDP Proxy。有咗Proxy，操作瀏覽器就變成普通HTTP調用：
# 列出當前所有標籤頁 curl http://localhost:3456/targets # 在指定標籤頁執行JS curl "http://localhost:3456/eval?target=xxx" -d 'document.title' # 點擊頁面某個元素 curl "http://localhost:3456/click?target=xxx" -d 'button.submit' # 截圖保存當前視口 curl "http://localhost:3456/screenshot?target=xxx'
02 點解CDP Proxy更強？
但如果你淨係知呢啲技術細節，你都未明web-access真正勁嘅地方。
點解CDP Proxy比MCP chrome-devtools同Puppeteer更適合AI聯網呢個場景？
| 特性 | CDP Proxy | MCP chrome-devtools | Puppeteer |
|---|---|---|---|
| 瀏覽器 | 重用日常Chrome | 獨立新實例 | 獨立新實例 |
| 登錄態 | ✅ 天然帶埋 | ❌ 要重新登入 | ❌ 要重新登入 |
| 調用方式 | HTTP API | MCP工具 | Node.js API |
核心分別只有一個：登入狀態。
你喺Chrome入面登入咗小紅書、微信公眾號、公司內網，Agent經CDP Proxy操作呢個瀏覽器，直接就可以訪問呢啲頁面，唔使另外處理登入、cookie、token嘅問題。
03 三個實測案例
案例一：競爭對手調研
我叫Agent幫我調研Dify、Coze、FastGPT呢三個AI工作流平台。
以前呢啲嘢我要自己開三個瀏覽器分頁，一個一個睇官網文件，手動做筆記，最後整合成一張表。快嘅都要兩三個鐘。
Agent將三個調研任務拆開，同時派出三個子Agent並行去做。三個平台嘅調研時間，同淨係調研一個平台差不多。呢個係咩概念？快三倍。
案例二：小紅書用戶討論
小紅書有好完善嘅反爬機制。裝咗web-access之後，Agent直接切換到CDP模式，接管咗我Chrome入面嘅小紅書分頁。
以前Agent聯網係「搜尋」，而家係「瀏覽」。
呢兩個動詞背後嘅能力差距，大概相當於你叫一個人幫你查資料，同叫你一個人幫你實地行一圈嘅分別。
案例三：GitHub技術週報
根據GitHub嘅提交記錄生成技術週報。Agent首先嘗試用WebFetch，發現部分內容需要JavaScript渲染，就升級到CDP模式。
呢個處理方式體現咗web-access一個核心設計原則：工具升級係漸進——輕量方式行得通就行輕量，行唔通先用瀏覽器。
04 深層思考
web-access呢個項目令我再諗一個問題：AI嘅聯網能力，點解重要？
因為大模型再勁，佢都係「缸中之腦」。佢嘅訓練數據有截止日期，佢唔知即時資訊，佢訪問唔到要登入嘅內部系統，佢處理唔到動態渲染嘅網頁。
之前我認為聯網就係搜尋加抓取：調用搜尋引擎API，攞到摘要，塞入上下文，輸出答案。呢套流程遇到動態頁面、登入牆、反爬機制，即刻就玩唔掂。
web-access提供嘅係另一條路：
令Agent直接操控瀏覽器，好似真實用戶咁打開頁面、等渲染、揾內容、撳連結。遇到搜尋解決唔到嘅問題，就換瀏覽器；遇到瀏覽器操作複雜嘅任務，就並行拆分；遇到同一個網站，就重用上次累積嘅經驗。
呢個唔只係多咗個工具，係換咗種思路。
05 結尾
2.8K Star，開源一個禮拜，唔係因為作者營銷做得好，係真係踩中咗真實痛點。
Claude Code寫code嘅能力，真係勁，其他工具冇得比。但佢嘅聯網能力，真係爭啲。呢個痛點，我忍咗半年。而家終於有解藥。
如果你用Claude Code或者Codex，試下。用之前你覺得聯網能力「夠用」，用之後你會發現之前嗰啲叫做將就。
工具嘅上限，決定咗你能夠做嘅嘢嘅邊界。
想試下？㩒呢度：
https://github.com/eze-is/web-access
啊。
我被AI的聯網能力蠢笑了半年，終於找到了解藥。
說真的，Claude Code寫代碼確實牛逼，別的工具沒法比。但它的聯網能力。。。怎麼說呢，就是個弟弟。
你試試讓它去抓個微信公眾號內容？不行。讓他去小紅書搜點東西？不行。讓他幫你查點需要登錄的東西？它能在那循環100次然後告訴你"無法訪問"。
我就納了悶了，你一個AI你不聯網你能幹啥？跟個瞎子似的。
直到前幾天我發現了一個開源項目——web-access。一週時間，2.8K Star。
01 技術原理
先說技術。web-access底層用的是Chrome DevTools MCP + CDP直連瀏覽器。用大白話說就是，它不是在那模擬HTTP請求，而是真的在操作你的瀏覽器。
這裏有個關鍵概念得掰開講：CDP是什麼？
CDP是Chrome DevTools Protocol的縮寫。你按F12打開開發者工具，底層就是它在支撐。通過CDP，外部程序可以通過WebSocket連接到Chrome，然後做幾乎所有你能在開發者工具裏做的事：
- 控制導航：打開URL、前進後退、刷新
- 執行腳本：在頁面上下文裏直接運行JavaScript
- 操作DOM：讀取節點內容、修改樣式、觸發事件
- 模擬輸入：鍵盤敲字、鼠標點擊、頁面滾動
- 監聽網絡：捕獲所有的HTTP請求和響應
- 生成截圖：任意時刻把當前視口截成圖片
web-access在CDP外面包了一層HTTP API。這就是CDP Proxy。有了Proxy，操作瀏覽器就變成普通的HTTP調用：
# 列出當前所有標籤頁 curl http://localhost:3456/targets # 在指定標籤頁執行JS curl "http://localhost:3456/eval?target=xxx" -d 'document.title' # 點擊頁面某個元素 curl "http://localhost:3456/click?target=xxx" -d 'button.submit' # 截圖保存當前視口 curl "http://localhost:3456/screenshot?target=xxx'
02 為什麼CDP Proxy更強？
但如果你光知道這些技術細節，你還是沒理解web-access真正牛逼的地方。
為什麼CDP Proxy比MCP chrome-devtools和Puppeteer更適合AI聯網這個場景？
| 特性 | CDP Proxy | MCP chrome-devtools | Puppeteer |
|---|---|---|---|
| 瀏覽器 | 複用日常Chrome | 獨立新實例 | 獨立新實例 |
| 登錄態 | ✅ 天然攜帶 | ❌ 需重新登錄 | ❌ 需重新登錄 |
| 調用方式 | HTTP API | MCP工具 | Node.js API |
核心區別就一個：登錄態。
你在Chrome裏登錄了小紅書、微信公眾號、公司內網，Agent通過CDP Proxy操作這個瀏覽器，直接就能訪問這些頁面，不需要另外處理登錄、cookie、token的問題。
03 三個實測案例
案例一：競品調研
我讓Agent幫我調研Dify、Coze、FastGPT這三個AI工作流平台。
以前這種事我得自己打開三個瀏覽器標籤，一個一個翻官網文檔，手動做筆記，最後拼成一張表。快的話也要兩三個小時。
Agent把三個調研任務拆開，同時派出三個子Agent並行去跑。三個平台的調研時間，和只調研一個平台差不多。這是什麼概念？三倍提效。
案例二：小紅書用戶討論
小紅書有非常完善的反爬機制。裝了web-access之後，Agent直接切換到CDP模式，接管了我的Chrome裏的小紅書標籤頁。
以前Agent聯網是"搜索"，現在是"瀏覽"。
這兩個動詞背後的能力差距，大概就相當於你叫一個人幫你查資料，和你叫一個人幫你實地走訪一圈的差距。
案例三：GitHub技術週報
根據GitHub的提交記錄生成技術週報。Agent先嚐試用WebFetch，發現部分內容需要JavaScript渲染，隨即升級到CDP模式。
這個處理方式體現了web-access的一個核心設計原則：工具升級是漸進的——輕量方式能走就走輕量，走不通了再上瀏覽器。
04 深層思考
web-access這個項目讓我重新思考了一個問題：AI的聯網能力，為什麼重要？
因為大模型再強，它也是"缸中之腦"。它的訓練數據有截止日期，它不知道實時信息，它無法訪問需要登錄的內部系統，它處理不了動態渲染的網頁。
之前我認為聯網就是搜索加抓取：調用搜索引擎API，拿到摘要，塞進上下文，輸出答案。這套流程遇到動態頁面、登錄牆、反爬機制，立刻就玩不轉了。
web-access提供的是另一條路：
讓Agent直接操控瀏覽器，像真實用戶一樣打開頁面、等待渲染、翻找內容、點擊連結。碰到搜索解決不了的問題，就換瀏覽器；碰到瀏覽器操作複雜的任務，就並行拆分；碰到同一個網站，就複用上次積累的經驗。
這不只是多了一個工具，是換了一種思路。
05 結尾
2.8K Star，開源一週，不是因為作者營銷做得好，是真的踩在了真實痛點上。
Claude Code寫代碼的能力，確實強，別的工具沒法比。但它的聯網能力，確實差點意思。這個痛點，我忍半年了。現在終於有解藥了。
如果你用Claude Code或者Codex，試一下。用過之前你覺得聯網能力"夠用"，用過之後你會意識到之前那叫將就。
工具的上限，決定了你能做事情的邊界。
想試試？戳這裏：
https://github.com/eze-is/web-access