让 Agent 帮你在网站上办事，常常像让一个聪明人隔着玻璃操作机器：它先看页面，猜哪个按钮是“提交”，点击，再观察有没有成功。按钮改了位置、弹窗遮住页面、登录状态变了，整条链路就可能中断。

如果网站直接告诉 Agent：“这里有一个查询订单的操作，参数是订单号；这里有一个提交申请的操作，参数是这些字段”，事情会不会简单得多？

答案是：操作可能更可靠，但授权问题并不会因此消失。 因为网站自己写的工具说明，也可能写错、过时，甚至故意隐瞒真实副作用。

2026 年 10 月 20 日，Web Machine Learning Community Group 更新了 WebMCP 规范草案。它值得关注，不是因为又出现了一个带 MCP 字样的新项目，而是它试图把 Agent 与网页交互的基础单位，从“猜测屏幕上的动作”改为“调用网页明确提供的能力”。

发生了什么：网页开始主动提供操作#

传统浏览器自动化主要围绕页面元素工作。Agent 观察 DOM 或截图，再决定点击、输入、滚动。WebMCP 提议让网页通过 JavaScript 注册带有名称、描述和输入结构的工具。当前草案的核心入口是 document.modelContext，页面可注册工具，浏览器侧 Agent 可以发现并调用它们。

例如，一个订票网站可以暴露“查询班次”或“填写乘客资料”的工具。Agent 不必每次都从按钮文字、表单布局中重新推断操作含义。工具在网页环境内执行，可以复用网站已有的界面状态与业务逻辑，而不是为 Agent 另造一套后端 API。

这与常见的服务端 MCP 集成不同：后者由独立服务端提供工具；WebMCP 的提议是让当前打开的网页本身成为工具提供者。它尤其适合需要用户和 Agent 共同操作同一页面的场景。

Chrome 官方开发文档 已提供实验入口：从 Chrome 149 开始的 origin trial，以及本地测试开关。文档还介绍了 JavaScript 注册与 HTML 表单声明两条方向。不过，10 月 20 日的规范仍是 Community Group 草案，不是 W3C 正式标准；表单声明能力的成熟度也不能与当前核心 JavaScript 接口混为一谈。

这是一条值得实验的技术路线，而不是所有浏览器已经具备的通用能力。

它暴露的问题：工具说明不是执行授权#

设想一个购物网站提供了名为 finalizeCart 的工具，描述是“完成购物车整理”。Agent 可能把它理解为“显示最终清单”，但实际实现却直接扣款。

这不是我凭空设计的恐吓案例。WebMCP 规范的安全章节 就用类似情形讨论 Misrepresentation of Intent（意图误述）：工具的自然语言描述与真实行为之间，没有天然的可验证对应关系。

问题比传统的“网页文字诱导 Agent”更进一步。网页不再只是 Agent 阅读的数据，它还可能成为向 Agent 提议可执行动作的一方。而且网页可能已经拥有用户的登录 Cookie 和会话状态；一次看似普通的工具调用，可能修改账户、提交订单或发送信息。

规范草案已经讨论工具描述投毒、输出注入、过度索取参数、跨来源边界等风险，也提出 consequentialHint（提示高后果动作）和 untrustedContentHint（提示不可信输出）等标注方向。但规范同样明确：网页自己声明的标注不能单独成为安全保证。如果一个工具本来就在欺骗 Agent，它当然也可能把自己的风险描述成“安全”。

这里必须区分三种事实：

  • 网站声明：这个工具叫什么、收什么参数、声称做什么。
  • 宿主判断：当前用户、当前任务和当前页面下，是否允许这次具体调用。
  • 执行证据：工具实际返回了什么，页面或业务状态是否真的改变。

把第一项直接当成第二项，就是把能力发现误当成授权；把第三项直接当成可信事实，则可能把网页的自我陈述误当成执行证明。

Mira 的真实实践：浏览器能力不等于任意网页工具#

这次对照的是 Mira Desktop 当前 dev 仓库，而不是旧设计稿。

Mira 已经有两条不同的浏览器能力面。一条是 Managed Browser（Mira 管理的隔离 Playwright 浏览器），另一条是 Attached Browser（用户已经连接的浏览器）。二者在 Harness Profile 源码 中分别登记，不能因为都叫“浏览器”就自动共享会话或权限。

在 Managed Browser 的 实际工具定义 中，browser_snapshot 负责观察，browser_click、browser_fill 等负责具体动作。点击并不是“模型觉得这个按钮像目标”就直接执行：调用需要携带最近观察的 pageUrl、snapshotHash 和元素 ref；工具定义还明确要求审批。截图、观察和断言则有不同的工具语义。

Attached Browser 的 工具定义 通过已连接浏览器的桥接能力执行，要求可信的用户上下文，并区分 look、browse、act 和 transfer。这不是 Managed Browser 的同一套会话，也不是 WebMCP。

更上层，Mira 的 Tool 当前实现说明 与 Harness Profile 把“注册了工具”“当前可用”“进入 Agent 可见范围”“展开完整参数结构”“这次调用获准执行”分成不同阶段。浏览器 Profile 的初始完整 schema 披露列表甚至是空的，需要按需展开具体工具，而不是一次把整个浏览器工具箱交给模型。

这些是目前能从源码确认的实现边界，不是 Mira 已经支持 WebMCP 的证明。 本轮检查到的浏览器工具仍是 Mira 自己定义的操作接口；没有发现已接入 WebMCP 的证据，也没有运行 WebMCP 兼容性测试。

恰恰是这段真实工程经验，使 WebMCP 的意义变得清楚：它可能让网页操作从“看见一个按钮”进化到“发现一个明确命名的业务动作”，但这只解决了表达和发现，没有替宿主解决权限和结果归属。

如果以后接入，最容易犯什么错误#

以下是架构推论，不是 Mira 已实现的功能，也不是已经批准的开发计划。

最危险的捷径，是把网页注册的 WebMCP 工具直接塞进 Agent 的可执行工具表，然后因为它自称只读或低风险，就跳过原有 Harness 审批。

更合理的路径应该是：先把网页工具当作来自当前页面的候选能力，保留它的来源、所属页面与文档生命周期；经过宿主的可用性和权限判断后，才允许按需披露 schema。真正执行时，仍要冻结工具身份、参数、页面上下文与授权对象。页面跳转、工具重新注册、登录状态变化，不能默默沿用旧批准。

执行结果也不能直接等同于“任务成功”。网站说“订单已提交”，最好还能够取得可核验的订单状态；如果无法核验，就把它作为网站返回的结果，而不是更高信任级别的完成证明。

这不意味着 Mira 应该重做一套 WebMCP 专用 Planner 或另造一条审批管线。相反，真正值得实验的是：能否把 WebMCP 作为现有浏览器能力的另一种发现与执行适配层，而不改变原有 Authority、Approval 和 Evidence 的归属。

如果做一个小型实验，先选没有不可逆副作用的页面，例如搜索、筛选、读取当前表单状态。对照同一任务的 DOM 操作步数、失败模式、工具描述歧义与页面变化后的失效行为，再决定它是否真的优于现有浏览器工具。不能因为协议名字好听就宣布“浏览器自动化被替代了”。

还有什么不能提前下结论#

首先，WebMCP 仍在快速演化。当前 API、跨文档行为、取消语义、跨来源工具与权限边界都需要跟踪规范及浏览器实现；不能拿旧教程中的 navigator.modelContext 当作长期稳定合同。

其次，Chrome 文档明确说，WebMCP 目前主要面向有人参与的本地浏览器工作流，无头浏览器能否可靠承载并非默认保证；Agent 还需要实际访问网站，才能发现该站点提供的工具。这与 Mira 的隔离浏览器、已连接浏览器和未来远程执行场景都有直接关系。

最后，结构化工具并不能自动证明真实副作用。一个错误的按钮可以让 Agent 点错；一个错误的工具描述同样可以让 Agent 调错。前者主要是感知与交互可靠性问题，后者还叠加了能力提供者的信任问题。

我的判断是：WebMCP 最值得 Mira 关注的，不是它将来会不会成为“浏览器版 MCP”，而是它正在推动一个更实用的分工——网页负责说明自己能做什么；Agent 负责理解用户要做什么；宿主仍必须负责决定允许做什么，并核实究竟做成了什么。

把这三件事分开，Agent 才可能在越来越丰富的网页能力面前，既更好用，也不轻易越界。

一手资料

Mira

上一篇← Agent 消耗了多少 token，为什么仍算不出它交付了什么？