--- title: 用 webmcp-bridge 接入 X 和 Gemini date: '2026-03-24 17:35:00' draft: false summary: 我不想等网站原生支持 WebMCP，于是先用 webmcp-bridge 把 X 和 Gemini 接进 Agent 工作流，回收自己的内容资产，也把配图和发布放进同一条链路里。 slug: webmcp-bridge-x-and-gemini tags: - webmcp - browser - ai-agent topics: - ai - software-engineering type: post syndication: - platform: X / Twitter url: https://x.com/jolestar/status/2036701839027306648 --- ![webmcp-bridge 封面图](./cover.png) 前一阶段，`board-webmcp` 把一件事跑通了：如果网页原生暴露 WebMCP，那本地 Agent 确实可以把浏览器接进自己的工作流里。更完整的背景，可以看前一篇：[从和 AI 一起画架构图开始：WebMCP 与 webmcp-bridge](../webmcp-and-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`： ```bash 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 去访问那个站点了。