AG-UI 与 WebMCP 的边界及协作方式

AG-UI 和 WebMCP 都在谈 Agent、工具和网页，但它们解决的是两个方向的问题：前者把你开发的 Agent 接到你的界面，后者把网页能力开放给用户带来的 Agent。选型先看「Agent 归谁管」，比先比较工具调用格式更有效。

原文真正有用的地方，是把事件流、浏览器工具和运行时能力分开讲清了。对于正在做站内 AI 助手，或考虑让网站被浏览器 Agent 操作的前端团队，这能避免接错协议，也能看清两者共用业务代码时的边界。

先问 Agent 归谁管，再决定接哪条线

AG-UI 是把 Agent 工作过程传到用户界面的开放协议。前端发起一次运行，后端持续返回有类型的事件，界面据此展示聊天、工具调用、审批卡片或地图。

连接两端都由你负责：一端可以是 LangGraph、Strands Agent 或 Mastra 工作流，另一端是你的产品界面。

下面这段服务端发送事件（SSE）展示了它如何传递一次运行的过程：

data: {"type":"RUN_STARTED","threadId":"t_1","runId":"r_1"}
data: {"type":"TEXT_MESSAGE_START","messageId":"m_1","role":"assistant"}
data: {"type":"TEXT_MESSAGE_CONTENT","messageId":"m_1","delta":"Checking flights"}
data: {"type":"TOOL_CALL_START","toolCallId":"c_1","toolCallName":"searchFlights"}
...
data: {"type":"RUN_FINISHED","threadId":"t_1","runId":"r_1"}

重点看 type：前端收到的是有明确用途的事件，不能把整条流都当成聊天文本追加。RUN_STARTED、RUN_FINISHED 标记运行边界；TEXT_MESSAGE_START、TEXT_MESSAGE_CONTENT、TEXT_MESSAGE_END 组织流式回复；TOOL_CALL_START、TOOL_CALL_ARGS、TOOL_CALL_END 描述工具调用；STATE_SNAPSHOT、STATE_DELTA 则同步完整状态与增量变化。

WebMCP 的方向相反。网页注册自己能执行的工具，由浏览器内置 Agent、扩展或用户带来的其他 Agent 调用。页面提供能力，却可能根本看不到用户与 Agent 的对话。

判断两者的第一问，是谁负责提供和运行 Agent。

你做站内助手，AG-UI 对应的是助手与界面的连接；你想让用户自己的 Agent 使用网站，WebMCP 对应的是网站能力的入口。两者可以出现在同一个应用里。

都能执行前端工具，为什么还不能互相替代

混淆来自一个事实：两者都能让工具在浏览器页面中执行。

AG-UI 支持前端工具。前端启动运行时，可以把工具定义与消息一起提交；Agent 决定调用后，通过 TOOL_CALL_* 事件把调用传回来，前端执行，再在下一次运行时回传结果。这仍然发生在你的应用承载的会话里。

WebMCP 则由页面主动注册工具。下面的示例把「按 SKU 加入购物车」开放给浏览器 Agent：

if ('modelContext' in document) {
  document.modelContext.registerTool({
    name: 'add_to_cart',
    description: 'Add a product to the shopping cart by SKU.',
    inputSchema: {
      type: 'object',
      properties: {
        sku: { type: 'string' },
        quantity: { type: 'number', minimum: 1 },
      },
      required: ['sku'],
    },
    annotations: { consequentialHint: true },
    async execute({ sku, quantity = 1 }) {
      await cart.add(sku, quantity);
      return `Added ${quantity} of ${sku}. Cart has ${cart.count()} items.`;
    },
  });
}

要关注开头的能力检测，以及 execute 的执行位置：回调就在页面里运行，可以使用当前用户已有的会话、Cookie 和应用状态。

作者把 AG-UI 前端工具近似看作「私有」，把 WebMCP 工具近似看作「公开」。这个类比强调的是调用方的可控程度，并不代表 WebMCP 没有访问控制。原文明确提到，它还有来源控制和 Permissions Policy 门槛。

工具定义相似，也给了业务复用的空间。名称、描述、输入 JSON Schema 和执行函数可以集中维护，再分别接入两个入口。AG-UI 工具定义使用的 parameters，可以映射到 WebMCP 定义里的 inputSchema。

但定义复用不等于协议自动打通。原文的共用示例只演示了定义映射与 WebMCP 注册，没有完整展示 AG-UI 的事件处理、函数分发和结果回传。这些仍需由应用或客户端库承接。

WebMCP 的入口便利，也带来了调用边界

按原文描述，WebMCP 正由 W3C Web Machine Learning Community Group 孵化，编辑来自 Microsoft 和 Google，处于 Community Group 报告草案阶段；Chrome 正通过 origin trial 试验。它还不是正式标准，这也是作者建议不要把关键业务路径押在上面的原因。

API 的变化已经体现在教程差异里：早期材料使用 navigator.modelContext，原文所依据的草案使用 document.modelContext。读到这里应记住的是能力检测和版本核对，而不是把文章里的接口位置当成永久保证。

Chrome 还试验了声明式写法：给现有 <form> 添加 toolname、tooldescription 属性，由浏览器根据表单字段构建工具。原文提醒，这部分尚未进入规范性正文，应按实验能力对待。

另一个边界是输入。WebMCP 调用者不由网站团队控制，用户的 Agent 还可能读取其他标签页内容，受到提示注入影响。因此，原文建议收窄输入、按不可信数据处理参数，并为花钱、发消息等操作标记 consequentialHint。

这个标记表达操作后果，不能据此推导出鉴权、确认和业务校验已经完成。原文也没有提供这样的保证。

统一前端协议，为什么还要保留专用适配器

Threadplane 的选择说明了协议抽象的收益和上限。

它是面向自有 Agent 的 UI 库，因此使用 AG-UI。作者称，@threadplane/ag-ui 可以连接遵守协议的后端，包括 CrewAI、Mastra、Microsoft Agent Framework、AG2、Pydantic AI、AWS Strands，以及通过 AG-UI 接入的 LangGraph。

他们表示已用真实运行时验证兼容性，但给出的正文没有测试矩阵、覆盖范围或失败案例。这支持「团队做过验证」的转述，还不足以让读者独立判断所有兼容细节。

Threadplane 同时维护 @threadplane/langgraph，通过 LangGraph JavaScript SDK 直连 LangGraph Platform。原因是线程历史、检查点和时间旅行超出了 AG-UI 的定义范围，专用适配器才能暴露 history() 等线程能力。

两个适配器都输出同一个 Agent 契约，所以组件仍然可以写成 <chat [agent]="agent" />。代价是维护第二套适配器，收益是界面不用跟着连接方式变化。

我的判断

作者最有说服力的判断，是先划清产品责任：AG-UI 解决自有 Agent 的界面连接，WebMCP 解决网页向外部 Agent 提供能力。它比笼统地比较「谁更支持工具」更适合选型。

不过，「谁拥有 Agent」只是第一轮筛选。进入实现，还要看状态恢复、权限和运行成本。采用 AG-UI，团队依然要承担 Agent 基础设施、模型费用和后端部署；事件流本身不会补齐运行时的全部能力。

与直接绑定运行时 SDK 相比，统一协议有利于隔离前端依赖，专用 SDK 则更容易接触运行时特有功能。Threadplane 的双适配器是一个具体取舍，原文没有给维护成本或迁移收益的对照数据，不能直接认定它适合所有团队。

WebMCP 能减少 Agent 依靠 DOM 猜操作的需求，这个方向合理。但原文没有成功率、延迟或可靠性的对比实验，也没有证明它已经可以替代现有浏览器自动化方案。

能拿来做什么

• 做站内 AI 助手时，先列出聊天、工具进度、审批和共享状态分别需要什么事件，再评估 AG-UI 能覆盖多少；涉及历史恢复时，单独核对运行时接口。
• 为已有网页试验 WebMCP 时，先选边界清晰的单个能力，保留能力检测和原有操作入口，并核对所用浏览器与草案的接口差异。
• 同时服务站内助手和外部 Agent 时，把业务函数与工具定义集中维护，再分别连接两个入口；不要把展示事件、执行逻辑和权限判断混在一起。
• 复用购物车这类工具时，检查所有入口是否执行同样的参数校验与权限判断，把 consequentialHint 当作后果提示，避免把它当成完整的执行保护。