可进入 Beta 的 retrofit 能力面

不用重写产品，也能让 Agent 稳定调用你的真实能力。

面向 AI 产品团队、平台团队与 SaaS 运营方：需要稳定执行，而不是脆弱浏览器自动化。

FastWebMCP 把真实产品里的路由、弹窗、上传、回调与异步任务流程，收敛为 Agent 可以长期依赖的能力边界，而不是要求团队暴露源码或重做产品。

可信度来自真实压力：melogen-web、redol 风格后台流程、GitHub Packages 发布产物，以及可在远端 CI 中消费的模板。

查看交付证明查看 SDK 路径

可发布 SDK 包

core、browser、react、contracts、adapters

默认 adapter 模板

form、dialog、file import、callback、async job、multi-output

桥接执行模式

markup、callback、endpoint

最适合

需要改造现有产品，而不是从零新建 agent app 的团队
需要控制 rollout、telemetry 与 route-level capability mapping 的平台负责人
必须通过 CI/CD、Docker 与远端部署环境交付能力的运营团队

为什么更安全

暴露受限能力边界，而不是放任 Agent 执行原始 DOM 自动化
让 rollout 绑定 route config、bridge 选择与 adapter 边界
通过 GitHub Packages 发布消费，而不是依赖本地 sibling checkout

为什么需要它

官方 MCP 不是最难的部分，改造现有产品才是。

大多数团队已经有成熟产品。真正困难的是：如何把正确的产品能力暴露给 Agent，同时不让关键业务流程退化成脆弱的浏览器编排。

产品现实

浏览器自动化恰恰会在最关键的业务逻辑处失效。

弹窗、文件上传、会话内 mutation、异步生成、支付状态轮询——如果集成面只是“按顺序点击这些选择器”，它就迟早会坏。

FastWebMCP 的答案

在真实产品流程上方暴露能力契约。

FastWebMCP 提供 route-aware runtime、bridge contracts、browser execution helpers 与 adapter templates，让稳定的集成单元从“侥幸可用的 DOM 脚本”变成“受控能力边界”。

核心判断真正可持续的集成面不是“DOM 本身”，而是叠加在真实产品路由与受保护业务流程之上的受限能力契约。

为什么要理解 WebMCP

WebMCP 解释能力接口模型；FastWebMCP 解释如何把它交付进真实产品。

如果你想弄清页面内 tools、后端 MCP 与原始浏览器自动化之间的边界，请直接看独立 WebMCP 页面。

了解 WebMCP

当前 Beta 能力面

这已经是一个 Beta 产品面，而不只是架构草图。

这个仓库之所以可信，是因为它已经覆盖 runtime orchestration、browser execution、React integration、bridge contracts、adapter defaults、release artifacts 与消费接入路径。

一套能力面里包含什么

当团队需要从“理论上 Agent 能不能用”推进到“我们能否安全上线”时，FastWebMCP 的价值才真正显现。

基于路由的 inventory 与配置注入，让能力绑定在产品真实存在的位置
理解 dialog、callback、file 与 polling-heavy job 的 bridge execution helpers
适用于远端 CI/CD 与部署流水线的发布消费路径

@fastwebmcp/core

Runtime + route telemetry

runtime 把产品路由变成可管理的 rollout 面，而不是每个页面一堆临时脚本。

观察 route、注入 config、挂载 adapter，并安全地刷新 telemetry
给平台团队一个统一位置去理解覆盖范围与执行行为

@fastwebmcp/react

给应用团队的 Provider + hooks

React 团队不需要把 runtime 状态手动接到每个页面。provider 层让注册和 ready 状态都更容易管理。

只有在产品上下文 ready 时才注册 tools
复用 hooks，而不是反复重写产品与 agent 之间的 glue code

browser + contracts + adapters

匹配真实 UI 复杂度的 bridge execution

FastWebMCP 开始真正产生价值的地方就在这里：dialog form、file import、callback、async job 与 polling-heavy route 已有默认能力。

支持稳定 markup flow、显式 callback registry 与 endpoint 驱动 job
用复用模板与共享 contract 语义减少一次性站点 glue code

publish + consume

服务真实部署团队的发布路径

如果一个 SDK 只能在 sibling checkout 中工作，它就不算产品。FastWebMCP 已经具备在远端构建环境里发布和消费的路径。

覆盖整套 SDK 的 GitHub Packages 发布工作流
面向 GitHub Actions + Docker BuildKit 的消费模板

执行路径

从产品路由到 Agent-ready capability，只需要四个受控步骤。

交付动作应当贴近真实团队的发布方式：定位 route、选择 bridge 模式、包装成 adapter，然后验证并发布。

011
定位 route
先识别真实产品面：表单、弹窗、上传、异步任务或高价值 mutation 路径。
022
选择 bridge
选择最小稳定执行面：UI 流程用 markup，产品自有客户端逻辑用 callback，受保护任务用 endpoint。
033
包装成 adapter
使用默认模板或自定义 adapter，让能力被稳定契约包裹，而不是暴露原始页面行为。
044
验证并发布
完成 typecheck、test、build 与打包，然后把已发布 SDK 滚入消费应用与远端部署链路。

桥接模型

按执行稳定性选 bridge，而不是按理念选。

真正重要的问题不是哪种 bridge 听起来更优雅，而是哪个 bridge 能为这个产品行为留下最小、最安全的暴露面。

Markup bridge

稳定 UI 流程与 dialog form

当产品已经有稳定表单面时，用 selectors 与 field kinds 拿到最低集成成本。

最适合

管理后台表单、modal 提交、checkbox toggle、file input，以及页面级可预测操作。

不适合

页面逻辑本质上已经是客户端函数或服务端 job，且需要更丰富状态语义。

Feed 创建弹窗与导入表单
简单配置页与审批表单

Callback bridge

受控的客户端能力暴露

当产品已经拥有有意义的客户端函数时，直接暴露该函数，而不是退回 DOM 操作。

最适合

生成任务、上传预处理，以及带产品特定客户端逻辑的能力入口。

不适合

你真正需要的是带 pending/success/failure 状态的受保护服务端 mutation。

客户端持有的生成动作
上传预处理与前端任务启动器

Endpoint bridge

受保护 mutation 与重轮询工作流

当能力本质上是服务端任务或 mutation 时，应暴露持久化状态语义，而不是模拟前端。

最适合

支付、发布、后台 job、报表生成，以及所有长任务生命周期场景。

不适合

流程其实只是一个稳定本地表单，做成 endpoint 反而会过度设计。

支付结果与订单状态轮询
异步内容生成与报表流水线

真实压力

这里最好的产品决策，都来自真实集成压力，而不是抽象图。

这些例子重要，是因为它们逼着 SDK 支持真实产品最 awkward 的边角情况。

复杂生成产品

Melogen 风格生成面

问题

生成类产品不只有一个 submit 按钮。它们会同时出现上传、callback、async job 与多输出交付。

桥接选择

把 callback 与 async job 模式组合起来，让 Agent 面对的是稳定能力边界，而不是隐藏页面编排。

结果

正因为这些流程，SDK 的 callback 与 multi-output 能力被显著加强。

后台 + feed 工作流

Redol 风格后台弹窗与导入

问题

后台工具经常把关键流程藏在 dialog、文件导入与状态页里，这些流程很容易被纯浏览器自动化搞坏。

桥接选择

用 dialog-form、file-import 与 endpoint polling 模式去匹配产品真实行为。

结果

SDK 因此补齐了 dialog opener、file field 与更丰富的 endpoint 状态语义。

Rollout + 部署链路

通过 CI/CD 交付的团队

问题

如果 SDK 只能本地联调，它就不算产品；下游团队往往是在 GitHub Actions 和 Docker 里远端部署。

桥接选择

通过 GitHub Packages 发布 SDK，并用可复现模板在消费侧安装。

结果

FastWebMCP 已经具备可信的 publish-and-consume 路径，而不是依赖 sibling checkout。

开发者入口

先把包职责讲清楚，再让团队决定要不要接。

好的产品页应该快速回答两个问题：哪些包与我的场景相关？从安装到 route-level rollout 的最短路径是什么？

安装核心接入路径

npm install @fastwebmcp/core @fastwebmcp/browser @fastwebmcp/react

启动 runtime

import { createFastWebMCPClient } from '@fastwebmcp/core'
 
void createFastWebMCPClient({
  controlPlaneBaseUrl: 'https://control.example.com',
  siteId: 'site_xxx',
  environment: 'prod',
  apiKey: 'fwmcp_site_xxx_prod_xxx',
  autoObserveRoutes: true,
})

包职责

@fastwebmcp/core

控制面 runtime

负责配置注入、route tracking、adapter 挂载与 telemetry 输出。

@fastwebmcp/browser

浏览器执行层

在产品环境中执行 markup、callback 与 endpoint bridge helpers。

@fastwebmcp/react

面向应用团队的集成层

提供 provider + hooks，让 React 团队更干净地注册 tools 与处理 ready 状态。

@fastwebmcp/adapters

可复用路由模板

提供 dialog form、file import、callback task、async job 与 multi-output 默认模板。

最短路径

1安装 runtime 表面并接通 route-aware client
2选择与真实产品行为匹配的 bridge 模式
3验证、打包，并通过 CI-safe 方式滚入消费应用

@fastwebmcp/core 负责 runtime、route inventory、telemetry 与 adapter dispatch。
当产品需要浏览器 execution helpers 与 Provider/hooks 集成时，再增加 @fastwebmcp/browser 与 @fastwebmcp/react。
对于远端部署，请通过 GitHub Packages 消费已发布包，而不是依赖本地 file: 路径。

为什么现在可信

证明应该是一条交付链，而不是一张假的 dashboard。

信任论证很简单：先证明 package set 能发布，再证明默认 bridge 能覆盖真实场景，再证明消费路径能进入真实部署链路。

交付证明面板

交付链

真实仓库压力变成 package boundary

SDK 被拆成 runtime、browser、React、contracts 与 adapters，不是出于好看，而是因为真实接入压力逼出了这些边界。

Package boundary 变成 release artifact

tarball、大小与 sha 标识证明这些包可以被构建、验证并作为真正的可分发单元交付。

Release artifact 进入可部署消费链路

GitHub Packages 发布与 consumer templates 让 SDK 可以被远端 CI/CD 消费，而不是只能在本地 checkout 中工作。

release 范围内 SDK 包

已验证 build + pack 输出

docs + templates

可部署 docs/templates

发布 + 消费路径

melogen + redol

参考集成模式

melogen + redol 压力测试

这里最强的证明不是虚荣指标，而是一条链：真实产品压力塑造 SDK，SDK 以真实产物发布，而这些产物可以进入真实部署路径。

发布产物

@fastwebmcp/core13.2 kB

b387ac36…8560

@fastwebmcp/browser13.5 kB

8c624a5c…884d

@fastwebmcp/react5.1 kB

48cd348a…586a

@fastwebmcp/bridge-contracts5.3 kB

2e87bf70…b42f

@fastwebmcp/adapters4.9 kB

00a9a081…bdd4

配套资产

覆盖五个 SDK 包的 GitHub Packages 发布工作流
面向 GitHub Actions + Docker BuildKit 安装的消费模板
来自 melogen-web 与 redol.ai 模式的参考桥接支持

可发布 SDK 包

Core、browser、React、bridge-contracts 与 adapters 都能 build、typecheck、test 并打包成产物。

受真实产品压力驱动的 bridge 默认能力

dialog opener、checkbox/file field、callback registry、async job 与自定义 polling state 都已实现并补了单测。

消费侧安装路径

仓库已经包含 GitHub Packages 发布流，以及面向 Docker/GitHub Actions 的消费模板。

评估者会问的问题

先回答真正会影响 rollout 的问题。

好的产品页不是只解释协议词汇，而是提前消除工程负责人、平台团队与产品评估者的疑虑。

接入现有产品会不会很侵入？

目标是受限式 retrofit，而不是产品重写。团队是在需要的 route 上挂 runtime、选 bridge，并暴露能力边界。

怎么在 markup、callback 与 endpoint 之间做选择？

选最小稳定执行面：稳定 UI 流程用 markup；已有产品客户端逻辑就用 callback；受保护或轮询重的 mutation 用 endpoint。

能否通过远端 CI/CD 和 Docker 构建上线？

可以。当前 Beta 已经包含 GitHub Packages 发布流，以及面向 GitHub Actions + Docker BuildKit secret 安装的消费模板。

为什么这个 Beta 不是只有原型价值？

因为 package set、bridge defaults、adapter templates、tests、pack artifacts 与 reference-app-driven 改进都已就位并可验证。

WebMCP 和 FastWebMCP 是什么关系？

WebMCP 是页面级能力模型：网页在共享 UI 上下文中暴露 JavaScript tools。FastWebMCP 则是帮助团队围绕这套模型，把真实路由、bridge、adapter 与发布链路工程化落地的产品与 SDK 层。