WebMCP 是什么：为什么它可能改变 Browser Agent 使用网站的方式
Browser Agent 过去最大的问题，是它经常像一个视力不错但不太懂规矩的人：看屏幕、猜按钮、读 DOM、点页面，然后希望自己没理解错。这个方法能做 demo，也能做一些低风险任务，但一到复杂表单、后台系统、支付、权限、动态页面，它就很容易变得脆弱。
WebMCP 之所以值得看，是因为它把问题换了一个方向：不只是让 agent 更会点页面，而是让网站主动暴露更结构化的工具和交互信息。简单说，Browser Agent 不一定非要猜页面上哪个按钮是什么意思，网站可以用更明确的方式告诉 agent：这里有哪些能力、参数是什么、哪些动作需要确认。
WebMCP 和 MCP 有什么区别
先别把 WebMCP 和普通 MCP 混在一起。可以先看这张表：
| 概念 | 位置 | 解决什么问题 | 典型场景 |
|---|---|---|---|
| MCP | AI 系统和外部工具 / 数据之间 | 让模型调用工具、读数据、接服务 | GitHub、文件、数据库、搜索 |
| Playwright MCP | Agent 和浏览器自动化之间 | 让 Agent 打开页面、点击、截图、验证 | UI 测试、本地页面检查 |
| WebMCP | 网站和浏览器内 Agent 之间 | 让网页暴露结构化工具和表单能力 | 搜索、筛选、表单、购买前草稿 |
| NLWeb 等方向 | 网站内容和自然语言查询之间 | 让网站变成可问、可查、可被 agent 访问的端点 | 商品、内容库、地点、FAQ |
WebMCP 的重点不是“又一个 server”，而是浏览器和网页本身开始为 agent 提供更清楚的接口。这可能会改变 Browser Agent 的使用方式。
为什么它可能重要
现在很多 Browser Agent 的失败不是因为模型太笨，而是因为网页没有为 agent 准备明确接口。人类看到一个按钮，可以结合上下文理解它；agent 看到 DOM、文字、截图，却可能不知道这个按钮会不会提交、有没有副作用、点击后会发生什么。
WebMCP 类似是在说：既然 agent 会来用网页，那网页能不能别让它只靠猜？能不能把一些能力结构化暴露出来？
比如一个电商页面可以暴露：
- 搜索商品
- 过滤价格区间
- 读取库存
- 生成购物车草稿
- 停在下单前确认
一个 SaaS 后台可以暴露：
- 查询用户状态
- 读取最近任务
- 生成配置草稿
- 导出报表
- 禁止直接删除、付款、发布
这比让 agent 在页面里乱点要稳定得多。
哪些网站最值得先关注 WebMCP
不是所有网站都需要第一时间适配。优先级应该看动作密度和结构化程度。
| 网站类型 | 是否值得关注 | 理由 |
|---|---|---|
| 搜索 / 筛选型网站 | 高 | agent 经常需要查找、过滤、排序 |
| SaaS 后台 | 高 | 有大量重复操作，但风险要控制 |
| 电商 / 预订 | 中高 | 商品、价格、库存、草稿有结构化价值 |
| 内容站 / blog | 中 | 先做好 schema、RSS、sitemap 可能更重要 |
| 纯展示页 | 低 | 可交互动作少，WebMCP 收益有限 |
如果你的网站只有文章，先把结构化数据、站内搜索、RSS、sitemap、canonical、FAQ 做好，未必要马上追 WebMCP。如果你的网站有很多表单、筛选、计算、后台操作，那 WebMCP 这类标准就值得提前观察。
第一批适配不要碰高风险动作
WebMCP 最容易被误用的地方，是一上来就想让 agent 完成整个交易或后台操作。更稳的做法是从 read-only 和 draft-only 开始。
| 动作类型 | 是否适合第一批 | 示例 |
|---|---|---|
| 读取信息 | 适合 | 查价格、查状态、查库存 |
| 生成草稿 | 适合 | 填表但不提交、生成配置建议 |
| 导出低风险数据 | 视情况 | 导出公开报表或个人数据 |
| 修改设置 | 暂缓 | 改权限、改计费、改生产配置 |
| 不可逆动作 | 不适合 | 删除、付款、发布、邀请用户 |
这和上一批 Browser Agent 的判断是一致的：先观察，再草稿，再低风险操作，最后才讨论高风险动作。
WebMCP 对内容和 SEO 的提醒
WebMCP 不是 SEO 技巧，但它提醒了一个趋势：网站要越来越适合机器理解和调用。过去我们说结构化数据，主要是让搜索引擎理解内容；现在 agent 时代，结构化能力还会延伸到交互动作。
对 RadarAI 这类站来说，短期更该做的是：
- sitemap 保持新鲜
- 文章标题具体
- 页面有清楚摘要和表格
- 来源入口可追溯
- 内容能被 AI crawler 和搜索引擎稳定理解
对 SaaS 和工具站来说，还要进一步想：
- 哪些动作可以被 agent 安全调用
- 哪些动作必须人工确认
- 哪些参数需要清楚 schema
- 哪些结果需要可复盘日志
WebMCP 不是替代这些基础，而是把这些基础往交互层推进。
我会怎么追这个方向
我会把 WebMCP 放进一个“agent tool standards” watchlist，和这些东西一起看：
| 方向 | 看什么 |
|---|---|
| Chrome / WebMCP | API 形态、origin trial、浏览器支持 |
| Model Context Protocol | server 生态、工具调用协议、官方示例 |
| Playwright MCP | agent 如何可靠操作浏览器 |
| NLWeb | 网站如何变成可问、可查、可被 agent 使用的端点 |
| Agent frameworks | LangGraph、ADK、OpenAI Agents SDK 是否支持相关模式 |
这个方向还在变化，不适合写成“马上全站重构”。但它非常值得提前跟，因为它可能改变 Browser Agent 和网站之间的关系。
最后一句话
WebMCP 重要的地方，不是让 agent 更像人去点按钮，而是让网站不再假装 agent 只是普通人类用户。未来更可靠的 Browser Agent，很可能不是靠更聪明地猜页面，而是靠网站暴露更清楚的结构化能力。
所以现在最实用的动作不是立刻押注，而是建 watchlist，选一个低风险页面做实验，持续观察 Chrome、MCP、Playwright MCP 和 NLWeb 这几条线怎么收敛。
一个具体例子：如果 RadarAI 要做 WebMCP，会先暴露什么
拿 RadarAI 这种内容和工具混合站举例，第一批不应该暴露发布、编辑、删除、用户数据这类能力，而应该暴露低风险查询能力。比如：
| 能力 | 是否适合第一批 | 原因 |
|---|---|---|
| 查询最新 AI 文章 | 适合 | 只读，能帮助 agent 找来源 |
| 查询某个主题的文章簇 | 适合 | 结构清楚，适合问答和引用 |
| 获取某篇文章的摘要和来源 | 适合 | 对 AI crawler 和 agent 都有用 |
| 生成内容草稿 | 暂缓 | 容易和发布流程混在一起 |
| 发布文章 | 不适合 | 高风险，必须人工控制 |
| 修改 sitemap 或 DB | 不适合 | 运维风险太高 |
这个例子说明了 WebMCP 的正确打开方式：不是把所有网站能力都给 agent，而是先挑最安全、最结构化、最能减少猜测的能力。
WebMCP 和现有结构化数据怎么配合
很多人会误以为 WebMCP 出现以后，schema、RSS、sitemap、API 就不重要了。其实正好相反。WebMCP 更像交互层，底层仍然需要内容层和发现层稳定。
我会按四层理解：
HTML / semantic structure：页面本身要清楚schema / RSS / sitemap：搜索和 agent 能发现内容API / feed / search endpoint：机器能稳定获取数据WebMCP / action tools：agent 能调用受控动作
如果前两层很乱，第四层只会把混乱放大。一个标题不清、来源不明、URL 不稳定的网站，就算加了 WebMCP，也不会突然变成好用的 agent interface。
网站团队现在可以做的准备清单
即使 WebMCP 还在变化，网站团队现在也可以做准备：
| 准备项 | 目的 |
|---|---|
| 清理标题和摘要 | 让 agent 知道页面解决什么问题 |
| 保持 sitemap 新鲜 | 让新内容能被发现 |
| 给关键内容加来源入口 | 让回答可追溯 |
| 把高风险动作列出来 | 提前决定哪些永远不开放 |
| 把低风险查询能力列出来 | 作为未来 WebMCP 实验候选 |
| 记录 agent 访问日志 | 看机器用户真实需求 |
这张清单比“马上做 WebMCP”更实际。标准还在变，但网站是否适合 agent 使用，很多基础工作今天就能做。
判断一个 WebMCP 新闻值不值得跟
我会把 WebMCP 新闻分三档：
| 分类 | 判断标准 | 动作 |
|---|---|---|
| act | 浏览器支持、API 形态或官方示例有明确变化 | 更新 watchlist，评估小实验 |
| watch | 社区讨论、demo、框架集成苗头 | 记录来源，等官方进展 |
| skip | 只有概念包装，没有文档或代码 | 不进入 backlog |
这样可以避免被新词带着跑。WebMCP 值得看，但不值得每一条讨论都立刻行动。真正有价值的，是官方文档、浏览器实现、框架集成和真实网站案例。