网站做完 SEO 还不够：WebMCP 让 Agent 在已登录页面直接调用工具

网站做完 SEO 还不够：WebMCP 让 Agent 在已登录页面直接调用工具

SEO 让搜索引擎理解页面主题，WebMCP 关心 Agent 能在页面上做什么。8 月 26 日发布的社区组草案提出浏览器 JavaScript 接口，网站可注册带说明和输入 schema 的工具。ChatGPT 桌面端内置浏览器把这类能力称为 Site tools，ChatGPT Work 与 Codex 可在支持的页面中发现并调用。

机票页面可以暴露航班搜索，企业后台可以暴露查询订单或创建工单。Agent 继续使用当前页面、登录状态和前端逻辑，无需先部署独立的远程 MCP Server。对内容站而言，它让“被找到”后的比较、填写和操作多了一条机器可读路径。

SEO 描述内容，WebMCP 描述动作

标题、canonical、结构化数据和内链帮助搜索系统理解页面主题，却无法可靠表达一次提交需要哪些字段、哪些选项互斥、成功后返回什么。WebMCP 工具用名称、说明和 JSON Schema 约束输入，并在页面脚本中执行已有功能。Agent 不必靠坐标猜按钮，也不用从视觉布局反推表单关系。

[WebMCP 草案](https://webmachinelearning.github.io/webmcp/)把网页描述为在客户端脚本中实现工具的 MCP Server。它同时支持命令式注册和面向表单的声明式方向，并考虑工具变更、取消执行、权限策略与同源边界。当前文档是 Web Machine Learning Community Group Report，不属于 W3C 正式标准或标准轨道，接口和安全模型仍可能变化。

因此网站不能为了追热点一次性注册大量模糊工具。更稳妥的起点是高频、可撤销、结果清晰的动作，例如读取筛选条件、生成报价草稿或保存未提交表单。工具名称和 schema 要版本化，错误返回要让人看懂，关键操作仍在页面上展示最终对象、金额与影响范围。

WebMCP 与 A2UI 方向相反，可以一起使用

A2UI 让 Agent 向客户端描述应该呈现什么界面，WebMCP 则让现有网页向 Agent 描述可调用的动作。前者从 Agent 输出走向 UI，后者从页面能力走向 Agent。远程 MCP Server 通常运行在后端并可服务多个客户端，WebMCP 工具依附当前文档、浏览器上下文和登录会话，页面卸载后执行与状态处理也不同。

这一区分决定了适用场景。需要长期后台任务、跨渠道调用或稳定服务端 API 时，远程 MCP 与持久会话协议更合适；需要与用户在同一页面协作、复用现有表单和前端校验时，WebMCP 更直接。网站也可以让 WebMCP 工具触发后端任务，再由 Agent 通过页面观察结果，但必须为重复提交、页面刷新和网络中断准备幂等标识。

[OpenAI 的 Agent-ready 网站介绍](https://community.openai.com/t/build-agent-ready-websites-with-chatgpt/1392588)强调 Site tools 可共享已登录会话。登录不等于授权；转账、发布、删除和对外发送仍应单独确认，并保留可见记录。

工具说明会成为新的攻击面

WebMCP 草案把工具投毒、输出注入、意图误导、参数过度收集和跨同源边界列为核心风险。恶意页面可能在工具说明中诱导 Agent 调用其他能力，工具返回也可能夹带新的指令。浏览器和 Agent 需要把工具元数据与结果视为不可信内容，网站则应限制输入长度、减少不必要字段，并为返回值标注不可信来源。

站点运营指标也要重新设计。SEO 关注曝光、点击和落地页，Agent 工具还要观察发现率、调用成功率、取消率、人工确认率和重复执行。日志应关联工具版本、用户授权、输入字段和最终业务结果，但避免记录完整敏感表单。任何会改变外部状态的工具都要提供幂等和撤销路径。

AnyAIS 可为网站 Agent 提供统一模型 API，WebMCP 负责向浏览器暴露页面动作。试点可从一个只读工具和一个可撤销写入工具开始，用不同 Agent 检查说明是否被误解。未来的 Agent 可见性不会取代 SEO，它会成为内容被发现后的第二层入口。