真正的问题不是画图，而是本地 Agent 怎么触达浏览器
先看一个具体的 demo。基于 Excalidraw 搭建了一个在线白板，人可以在页面里拖动、编辑、选中元素；AI 也可以在同一块画布里读取内容、添加节点、连线、调整布局。关键区别在于：这不是 AI 吐出一张静态图片，而是人和 AI 在同一个浏览器会话里协作编辑。
一旦做到这一步，问题自然就转变了——从"怎么画图"变成"本地 Agent 怎么调用浏览器页面里的能力"。
WebMCP：浏览器侧的 MCP
如果你了解 MCP（Model Context Protocol），知道它解决的是"如何给模型暴露工具"，那 WebMCP 就是这件事在浏览器端的延伸。
核心接口是 navigator.modelContext。一个网站如果支持 WebMCP，就可以通过这个接口直接向 AI 暴露自己的能力。AI 不需要去分析页面 DOM 布局、模拟鼠标点击，而是直接调用页面声明好的结构化接口。
但这里有个微妙的地方值得注意：WebMCP 官方目前的设计方向，更偏向于"让浏览器内的 Agent 去调用网页能力"——比如浏览器内建的 AI、浏览器扩展等。它并没有天然解决另一个场景：我本地跑着的 Claude Code 或 Codex，怎么用上浏览器里暴露出来的这些能力？
中间差了一层桥。
webmcp-bridge：把调用路径桥接回本地
webmcp-bridge 做的事情很直接——把本地 Agent 和浏览器里的 WebMCP 能力连起来。
它的调用路径是：
local-mcp -> Playwright -> browser navigator.modelContext
拆开来看：
- 本地 Agent 调用一个标准的 stdio MCP server（即
local-mcp） local-mcp通过 Playwright 驱动浏览器页面- 如果页面支持原生 WebMCP，直接调用
navigator.modelContext - 如果页面还没支持 WebMCP，走 shim/adapter 做兜底
这里有一个设计原则值得关注：native-first, shim fallback。也就是说，网站已经支持 WebMCP 就走原生路径，还没支持就补一层适配器。这样做的好处是什么？等 WebMCP 真正普及之后，bridge 不会变成历史包袱；而在当下，它又能让大量还没支持 WebMCP 的网站先接入。
用 uxc 统一调用
在实际使用中，uxc 扮演的是统一调用层的角色。它把浏览器桥接路径固化成稳定的命令，本地 Agent 不需要记一长串启动参数，也不需要把一堆 MCP 配置塞进上下文。
具体来说，可以创建两个 link：一个负责 headless 调用（board-webmcp-cli），另一个把同一个会话打开给人看（board-webmcp-ui）。这一步也可以交给 skill 自动完成。
之后的协作模式就很清晰了：人打开浏览器看着画布，AI 在同一个会话里增删节点、加边、调布局。这和"AI 生成一张图然后扔给你"完全是两回事——它更接近 Google Docs 那种多人协作编辑的体验。
这条路如果走通，意味着什么
这个项目真正想验证的，不只是 AI 能不能操作网页。更深层的问题是：WebMCP 能不能成为浏览器应用和本地 AI 之间一层自然的接口？
如果这条路成立，意味着：
- 网站在浏览器里声明自己的能力
- 本地 Agent 通过标准 MCP 协议调用
- 原生支持优先，适配器兜底
- 人和 AI 在同一个网页会话里实时协作
现在很多场景下，要让 AI 操作网页，还得靠脚本模拟点击、接口逆向工程、手动搬运状态。如果 WebMCP 这个标准能铺开，这些脏活累活都会大幅简化。
对于独立开发者来说，这里有一个值得思考的方向：你正在开发的 Web 应用，是不是也可以通过 navigator.modelContext 暴露能力，让用户的本地 AI 直接调用？当"AI 可操作性"变成网页的标配属性时，最先支持它的产品，会不会获得一种新的竞争优势？