浏览器里的 AI Agent 过去主要靠“看页面”工作：识别文字、寻找按钮、推断界面状态，再模拟人的点击。CopilotKit 新增的 WebMCP 支持想把这套流程推进一步——网站可以直接告诉 Agent 自己提供哪些工具，以及这些工具该怎样调用。
这意味着，Agent 访问一个网站时，不再只能把它当成一组像素和 DOM 元素。网站原本提供给应用内助手的搜索、查询或操作能力，也可以通过 WebMCP 暴露给兼容的浏览器 Agent。
#一套前端工具，服务两类 Agent
CopilotKit 的核心做法，是复用已有的 useFrontendTool 抽象。开发者为应用内 Copilot 注册前端工具时，可以选择同时开启 WebMCP；同一个工具随后既能被站内助手调用，也能被 ChatGPT Atlas、Comet、Dia 等兼容 WebMCP 的浏览器 Agent 发现和调用。
这避免了两套能力定义长期分叉：一套给自家 Copilot，另一套给外部浏览器 Agent。工具的名称、参数、处理逻辑和生命周期仍由同一处管理，WebMCP 只是增加一个明确的开放入口。
每个工具可以单独选择是否开放。组件挂载时自动注册，卸载时自动注销；在服务端渲染或不支持 WebMCP 的环境中，则保持可控的降级行为。React、Vue、Angular 和 React Native 等框架都可以沿用这套方式。
#注解让 Agent 先判断风险
工具能被发现还不够，Agent 还需要知道调用它会产生什么后果。CopilotKit 支持为 WebMCP 工具添加注解，例如标明某个订单搜索工具只读。这样的元数据可以帮助 Agent 在调用之前区分查询与修改操作，为权限控制、人工确认和安全策略提供依据。
这也是 WebMCP 与纯界面自动化的重要差别。按钮通常只向人表达意图，工具接口则能同时声明参数结构和操作性质。Agent 不必从按钮文案猜测风险，网站也不必把所有能力一股脑开放出去。
#不只是把工具暴露给外部
CopilotKit 同时强调另一半能力：网站仍然可以构建自己的应用内 Agent，并让它调用同一批 WebMCP 工具。这个 Agent 可以在对话中生成自定义界面，保存持续会话，与应用双向同步状态，并在关键步骤中断流程、请求人工批准。
后端也不被锁定在单一框架中。LangGraph、Mastra、CrewAI、Pydantic AI、Google ADK 或自定义后端，都可以接到这套前端交互层上。WebMCP 负责让能力可发现、可调用，CopilotKit 则继续承载会话、界面、状态与人工介入。
#网页正在从界面变成能力目录
这次更新的价值不在于多了一个配置字段，而在于网页与 Agent 的关系开始变化。传统网页把能力包装成人能理解的界面；WebMCP 则让同一套能力同时拥有机器可读的入口。
短期看，它能让浏览器 Agent 少依赖脆弱的页面定位和点击脚本。长期看，网站可能同时维护两层体验：面向人的视觉界面，以及面向 Agent 的结构化工具层。前者负责理解与操作感，后者负责稳定、精确和可治理的执行。