大家好，我是若风。

先说个刚发生的事。我让 Claude 帮我读一下 Docker 公司最近的 LinkedIn 动态，就这一句话。几秒之后它把 Docker 最近 20 条动态整理成了中文摘要，哪条在讲 AI Agent 沙箱。哪条在预热 AI Engineer World's Fair，互动数据都带出来了。

实际来说，我盯着屏幕愣了一下。不是结果多惊艳，是我突然意识到，这一句话背后的工程量。

你想想看，AI 怎么知道 LinkedIn 上有什么？它又不会上网，它调用了一个叫 mcp-server-linkedin 的工具。这个工具底层不是 LinkedIn 官方 API，而是用浏览器去抓页面的程序。而这个浏览器，被一个叫 Patchright 的库控制着，Patchright 又是 Playwright 的反检测分支。Playwright 通过一套叫 CDP 的协议，真正指挥 Chromium 这个浏览器内核干活，最终把页面渲染出来的是 Blink。老实说，

一层套一层。我数了数，整整 8 层。

这篇文章就沿着这一句话，一层层拆开。看看 AI 从「想看一下 LinkedIn」到「真的打开浏览器抓回数据」，中间穿过了什么。

第 1 层 AI 模型：听懂你说话的那个大脑

一切从你那句话开始：「读一下 Docker 公司最近的 LinkedIn 动态」。

这句话进到 AI 模型里它得做两件事：先听懂你要什么再去想怎么拿。它自己上不了网，但它知道手里有一堆工具，其中有个能查 LinkedIn。老实说，

这层是整条链的大脑。没有它对意图的理解和对工具的调度，后面 7 层再强也启动不了。

第 2 层 MCP：让 AI 知道有工具可以调

AI 本身不会上网。不会读文件，不会操作浏览器。它能做的只有读文本、写文本。那它怎么完成「读 LinkedIn」这种事？靠工具，但工具怎么告诉 AI 自己存在、自己能接收什么参数？这就得有一套约定——MCP。

MCP 就是一套翻译协议。让 AI 和外部世界说同一种语言，解决接口问题而非智能问题。

MCP 将 mcp‑server‑linkedin 注册为一个能力：查公司资料、刷动态、搜职位、读私信等。当 AI 想「读 Docker 动态」时会调用 get_company_posts，并传入 docker 参数。

第 3 层 mcp-server-linkedin：把抓 LinkedIn 包装成一个工具

工单递到了 mcp-server-linkedin 手里它接到 docker 参数后要去拿 Docker 公司的动态。

为什么不直接调 LinkedIn 的 API？因为普通人没有权限，LinkedIn 的数据被登录态锁住需要像真人使用者一样登录并加载页面接下来抓取内容。

底层不是 API 调用，而是浏览器自动化：启动真实浏览器。用已登录会话导航到 Docker 公司主页，把动态逐条抓取下来。这一步奠定了后续所有层的根源，因为用浏览器抓页面比调用 API 更复杂、更耗时也更易被检测到。

第 4 层 Patchright：为什么不能直接用 Playwright？说起来，

Patchright 是一个大多数人没听过但非常关键的库。它是 Playwright 的反爬版本，为了逃避 LinkedIn 的 Cloudflare 等反爬服务所做的改动。

• MCP.enableRuntime: 替换 Runtime.enable，让 JS 在隔离环境执行；
• MCP.disableConsole: 禁掉 Console.enable；
• MCP.removeAutomationFlag: 去掉 --enable-automation 标记；
• MCP.cleanUpFingerprint: 清理其它可识别“自动化”的指纹。

这些改动让机器人成为“人类”，从而降低被检测到的概率。

第 5 层 Playwright：API 来自哪里？

Puppeteer 最早由 Google 发布，在 Chrome DevTools Protocol之上封装成易用 API。话说回来，三年后微软推出 Playwright，将 Puppeteer 部分代码 fork 并 支持多浏览器、多语言。还专门为 AI Agent 提供 CLI 与 MCP 接口。

第 6 层 CDP：真正控制浏览器的协议

• Name: Chrome DevTools Protocol
• Description: 通过 WebSocket 与 Chromium 通讯。以 JSON 消息格式传输命令与事件
• Main Domains: Page,Runtime,Network,Target 等

说到举例，

// 打开新标签页
Target.createTarget;按理说，// 附加到标签页
Target.attachToTarget;// 执行 JavaScript
Runtime.evaluate;// 截图
Page.captureScreenshot;

• Description: Google 开源项目，是 Chrome、Edge 等多家浏览器主要
• Main Design: 多进程架构——Browser 主进程、Renderer 子进程、GPU 子进程
• Sandboxing: Renderer 在沙箱内运行。明显提高安全性

痛点 #1 — 加载延迟 & 网络波动导致半截页面返回：

• "Page.loadEventFired" 必须等全局渲染完成才能继续；如果网络慢或出现懒加载，这一步会卡顿或返回空壳。"
• "Chromium 多进程使得请求与渲染相互耦合，需要额外等待网络空闲与 DOM 完全渲染。"
• "在实际使用中。你可能只能得到部分内容，需要显式滚动触发懒加载。"
• "Debug 时常见错误信息类似 `TimeoutError` 或 `EmptyDOM`。"
  • "解决办法这方面，"设置更长 timeout"、“显式等待 Page.loadEventFired”还有“使用 ScrollIntoView”来触发懒加载。"

痛点 #2 — 被反爬检测拦截：

• "Cloudflare/LinkedIn 检测是否为自动化脚本，一旦发现 Runtime.enable 等指令就会触发验证码或封禁 IP。"
• "Patchright 能够消除这些指纹。但仍需保持一样功能，否则会影响业务流程。"
• "Debug 时常见报错 `blocked by client-side policy` 或 `automation detected`。"
  • 从"解决办法来看，"启用 Patchright 或自定义 CDP 指令绕过标记；如果不可行，可考虑代理轮换 IP 或使用头部。"

痛点 #3 — 框架升级导致 API 弃用：

• "Playwright/Puppeteer 更新频繁，新版可能废弃旧方法。如 page.goto 改为 context.newPage.goto"
• "MCP 与 Patchright 必须同步更新，否则接口不兼容导致错误 `"method not found"`"
  • "解决办法这方面，"继续关注框架发布说明，并及时调整本地实现或迁移至当前版本。"

痛点 #4 — 可 性与维护成本这方面。

• "多层栈代表着每次变更都需跨越几代技术栈进行调试"
• "当需要支持更多网站时需要重新实现或适配不同协议"
  • 再看"建议做法，"将主要业务逻辑抽象成插件化模块，让不同协议只负责底层交互，而业务保持一致。"

横切一下——四种路线怎么选？

• 完整链路AI 模型 → MCP → mcp‑server‑linkedin → Patchright → Playwright → CDP → Chromium → Blink。
• 关键痛点
  • 加载延迟 / 网络波动 导致半截页面；
  • 反爬检测 阻断请求；按理说，
  • 框架升级 & API 弃用 难以维护；
  • 可 性 & 成本 难以快速迭代。
• 实践建议
  • 对每一层进行日志记录和监控；其实，
  • 使用 Patchright 或自定义 “无自动化” 策略；按理说，
  • 定期检查 CDP 与 Browser 协议兼容性；
  • 如需高并发抓取，可考虑采用 WebDriver BiDi 或未来原生 MCP 接口。其实，

只要掌握好每一块拼图。你就能在面对 “超时”“空壳”“被封禁”等问题时准确定位，到哪一层该排查，而不是盯着报错敲键盘无效。这样，你就能把看似神奇的 “AI 打开浏览器” 拆解成可管理、可调整的一条可靠流程。

祝你抓取顺利！