BotOf Tech — 技术与植物养护笔记

今年 5 月我们曾介绍 WebMCP 的方向：网站把结构化操作暴露给浏览器 Agent，Agent 不必再靠截图、坐标和猜按钮完成任务。到 8 月，这个方向已经从概念走向可实际体验的产品路径。Chrome 发布了面向开发者的构建指南；OpenAI 的 ChatGPT 内置浏览器则把实现称为 Site tools，ChatGPT Work 与 Codex 可以在访问页面时发现并调用。

真正的变化不是“浏览器自动化更快”，而是网站多了一层正式接口：同一个已登录页面同时服务人和 Agent，工具继承页面当前状态与会话，调用又能被浏览器检查、确认和记录。

WebMCP 解决的是像素自动化的脆弱性

传统 browser agent 大致执行这条链：读取可访问性树或截图，推断按钮含义，点击坐标，等待页面变化，再猜操作是否成功。布局调整、同名按钮、虚拟列表、遮罩层和异步状态都可能让它失效。

WebMCP 把其中最不可靠的一段替换为有类型的调用：网站声明工具名称、说明、JSON 输入模式、注解和执行函数；Agent 选择工具并提供结构化参数；浏览器在调用前执行安全检查，页面再调用已有业务逻辑。

这不会消灭可视化操作。没有合适工具时，Agent 仍可使用普通浏览能力；工具执行后也可检查页面变化。更合理的架构是：结构化工具负责确定性动作，页面负责共享上下文与人工复核，视觉操作负责尚未结构化的长尾。

Site tools 与 MCP 不是同一层

OpenAI 官方文档给出了清楚边界：MCP 把 AI 应用连接到本地或远程服务器，工具可以脱离网页独立工作；WebMCP 则由当前网站在 Agent 访问时提供预定义工具，不要求用户另装 MCP Server。

维度	WebMCP / Site tools	MCP Server
生命周期	依附当前顶层页面，导航或关闭后可能失效	独立于页面连接存在
身份上下文	复用当前页面与登录会话	由连接器或服务器单独授权
共享界面	用户与 Agent 观察同一画布、表单或仪表盘	可完全后台化
适合任务	页面内查找、编辑、建议、筛选与确认	跨系统搜索、批处理、长期后台任务
部署成本	网站前端注册并复用现有逻辑	维护独立协议服务、凭证与连接

一个产品可以同时支持两者。例如文档编辑器用 WebMCP 在当前文档中“定位章节、建议修改、留下评论”，用 MCP 在后台跨文档检索与批量归档。关键是不要把同一个高风险写操作复制成两套互不一致的权限模型。

一个工具契约至少包含六件事

官方示例通过 document.modelContext.registerTool 注册只读工具，并用 readOnlyHint 表达读操作。生产工具不能只写一个好听的 description，还需要：

稳定名称与明确结果：按业务动作命名，不按按钮文案命名；
严格输入模式：拒绝未声明字段，约束枚举、长度、格式和范围；
权限语义：区分只读、可逆写入、不可逆写入与外部通信；
幂等键与版本：重试不能重复扣款、发布或创建记录；
结构化错误：区分参数错误、权限不足、状态冲突、限流与服务故障；
可审计结果：返回资源 ID、版本、影响范围和下一步，而不是一句“成功”。

await document.modelContext.registerTool({
  name: "preview_schedule_change",
  description: "预览排期变化，不提交修改。",
  inputSchema: {
    type: "object",
    properties: {
      itemId: { type: "string", minLength: 1 },
      targetDate: { type: "string", format: "date" }
    },
    required: ["itemId", "targetDate"],
    additionalProperties: false
  },
  annotations: { readOnlyHint: true },
  execute: async (args) => previewScheduleChange(args)
});

更安全的写入流程不是直接暴露 publish，而是拆成 prepare、review、commit：第一步计算 diff 和风险，第二步让人确认，第三步携带短期 commit token 提交。这样权限边界由系统执行，而不是靠 Agent 自觉。

最大风险：工具定义本身也是不可信输入

OpenAI 文档明确提醒：网站提供的工具名、工具说明和结果都是不可信内容。某个工具声称“只读”并不能证明它真的只读，页面中的指令也不能授权 Agent 分享无关信息或执行敏感动作。

生产威胁模型至少包括：

恶意页面用诱导描述要求 Agent 泄露其他标签页或会话数据；
工具在执行时做出比名称更大的副作用；
页面被 XSS 控制后替换工具注册；
Agent 混淆同名工具、过期页面状态或 iframe 来源；
重试造成重复购买、重复发送或权限漂移；
工具结果夹带 prompt injection，影响后续决策。

浏览器的来源绑定、安全审查和高风险确认能降低风险，但不能替代网站自己的授权。服务端仍应验证用户身份、资源权限、CSRF/会话状态、业务前置条件和幂等键；审计日志应关联用户、页面 origin、工具版本、参数摘要、确认记录、结果和资源变更。

当前实现边界必须写进兼容矩阵

截至本文发布时，OpenAI 文档说明 Site tools 仍有明确限制：ChatGPT 内置浏览器只支持 WebMCP API 的一个子集；HTML 表单属性定义的声明式 API 尚不可用；iframe 内注册的工具不会被发现，包含同源 iframe；应在顶层页面用 JavaScript 注册。模型和工作区可用性也受当前发布状态影响。

这意味着团队不能看到“标准提案”就假设所有浏览器已经一致实现。至少维护三层兼容矩阵：规范定义了什么、目标浏览器实现了什么、当前 Agent 产品实际启用了什么。工具注册失败时，页面的人类交互必须保持完整，不能让 WebMCP 成为核心功能唯一入口。

渐进式改造路线

最适合的第一个工具不是最炫的，而是高频、已有后端权限、参数明确、可只读验证的操作，例如读取图表数据、按日期筛选、定位文档章节。上线前用真实任务检查：

工具选择准确率与参数校验失败率；
相比像素操作减少的步骤和耗时；
用户确认被触发的比例是否合理；
重试是否幂等，失败能否恢复；
页面导航后旧工具是否立即失效；
审计记录能否重建每一次副作用。

只有这些通过后，再开放建议编辑、草稿更新等可逆写入，最后才考虑支付、发送、删除和改权限等高后果动作。

我的判断

WebMCP 的长期价值不是给现有 UI 再贴一层 AI，而是促使网站把业务能力整理成清晰、可验证、可授权的契约。做得好，Agent 不再猜测像素，用户仍在同一页面看到状态与变化；做得差，它会把网页里的模糊权限和副作用放大成自动化风险。

Agent-ready Web 的基础仍是可访问性、稳定业务逻辑、最小权限、可恢复写入和完整审计。WebMCP 只是让这些工程质量第一次直接决定网站能否被智能体可靠使用。

WebMCP 从提案走向可用：网站如何为 Agent 提供生产级工具契约