用 webmcp-bridge 接入 X 和 Gemini

前一阶段，board-webmcp 把一件事跑通了：如果网页原生暴露 WebMCP，那本地 Agent 确实可以把浏览器接进自己的工作流里。更完整的背景，可以看前一篇：从和 AI 一起画架构图开始：WebMCP 与 webmcp-bridge。

但我很快就碰到一个更现实的问题：我不可能等每个网站都先把 WebMCP 做好。

我想做的事情很具体：

• 我想把自己发在 X 上的 thread、长推和 article 重新抓回来，整理进本地知识库里。
• 我也想在写文章时，直接复用自己已有的 Google/Gemini 订阅去配图，而不是为了生图再单独买一套 API。

问题是，X 和 Google 现在都没有原生 WebMCP。

后面的方向也很清楚：有原生 WebMCP 的网站，当然优先走 native；暂时等不到的网站，就先用 adapter 的方式接进来。webmcp-bridge 这一阶段做的，就是这件事。

难点不在网页操作，在浏览器生命周期

很多人会觉得，adapter 的难点在“怎么点按钮、怎么读 DOM、怎么发请求”，但更麻烦的是浏览器会话本身。

像 Google 这种站点，对自动化非常敏感，很容易把登录流程直接拦下来。这个时候只能先拉起一个正常浏览器，让用户自己完成登录，再把这个已登录会话交回给 Agent。

另一个麻烦是 headless 和 headed 之间的切换。真实使用里，你不可能永远只跑一种模式。后台跑、打开可见窗口看状态、做人工确认、临时接管，都会逼着浏览器在两种模式之间来回切。

webmcp-bridge 这一阶段接管的是浏览器会话本身。浏览器不再只是一个静默跑任务的容器，而是可以在后台自动化和前台人工接管之间来回切换。

遇到 Google 或 X 这类登录和验证拦截时，Bridge 会先把真实浏览器窗口拉起来，交给用户完成登录、授权或确认。状态一旦到位，后面的会话会继续被 Agent 复用，流程再滑回自动化执行。这样人处理授权，Agent 处理后续抓取、整理和发布，中间不用再靠临时脚本硬拼。

这套东西开始进入真实工作流

前面这段时间，我已经在用这套 bridge 抓自己发在 X 上的 thread、article，以及收藏夹里的内容，再整理回本地知识库里。

用的过程中，不断打磨细节，比如如何稳定的实现精准翻页连续加载，如何准确的抓取一个 thread 的所有内容，如何下载媒体文件，如何在转换 Markdown 到 X Article 编辑器。很多细碎的工作，需要使用过程中打磨。现在感觉打磨的差不多了。

基本我现在是这样一个工作流，搜索调研可以直接问 Google 和 Grok，配图可以直接走 Gemini，最后再把正文整理成 X article 草稿。这样内容积累、资料查找、配图和发布，开始连成了一条连续工作流，都可以在 Codex/Claude code 中完成，而不是几段彼此断开的工具。

ps: 当前这篇文章就是通过这个工作流发布出来的。

如果你也想试

项目地址：https://github.com/holon-run/webmcp-bridge

如果你也想把现有网站接进 Agent 工作流里，可以先装 uxc、webmcp-bridge 和 webmcp-adapter-creator：

npx -y skills@latest add holon-run/uxc --skill uxc
npx -y skills@latest add holon-run/webmcp-bridge --skill webmcp-bridge --skill webmcp-adapter-creator

底层 runtime 是 @webmcp-bridge/local-mcp。

如果一个网站已经支持原生 WebMCP，就直接走 native；如果还没有，就先用 webmcp-adapter-creator 做 adapter，再交给 webmcp-bridge。这样 Agent 就能通过同一套浏览器 bridge 去访问那个站点了。