网站声明它能做什么，应用问是谁在问
本文引证来源 · WebMCP，草案社区组报告，2026 年 10 月 16 日，由 W3C 网络机器学习社区组发布；编辑为 Brandon Walderman（Microsoft）、Khushal Sagar（Google）、Dominic Farolino（Google）——一手源，英文原文照录 · 拒绝清单及其理由：2026 年 10 月 14 日豆包手机助手《屏幕自动化操作声明协议》（SAEP）拒绝操作清单，由 中国经济网与 中国妇女网于 2026 年 10 月 15 日报道，分析引自《中国新闻周刊》——中文二手报道，原文照录并已标注 · 10 月 28 日 W3C breakout 会议「Integrating WebMCP into WebExtensions」据 W3C 会议日程注明。
同一周之内，同一场战争的两条战线同时打开——而它们争的是同一个缺失的东西。网络这一侧，一个 W3C 社区组发布了规范，让网页能用 JavaScript 声明自己允许智能体对它做什么；手机这一侧，一款智能体助手公布了一份清单，150 多款应用拒绝让智能体代替用户操作它们。一条战线问的是这个网页能为智能体做什么；另一条问的是到底是谁在按这些按钮。两个问题都在场，两个都还没有标准答案。
1. WebMCP 是什么——按草案自己的话
这份文档日期是 2026 年 10 月 16 日，身份是草案社区组报告，由 W3C 网络机器学习社区组发布，编辑为 Brandon Walderman（Microsoft）、Khushal Sagar（Google）与 Dominic Farolino（Google）。摘要只有一句：“The WebMCP API enables web applications to provide JavaScript-based tools to AI agents.”（WebMCP API 让网页应用能够向 AI 智能体提供基于 JavaScript 的工具。）状态一节同样精炼，而且值得照录，因为它最常被省略：“This specification was published by the Web Machine Learning Community Group. It is not a W3C Standard nor is it on the W3C Standards Track.”（本规范由网络机器学习社区组发布。它不是 W3C 标准，也不在 W3C 标准轨道上。）
导言用一句会被引用很多年的话解释了机制：“Web pages that use WebMCP can be thought of as Model Context Protocol [MCP] servers that implement tools in client-side script instead of on the backend.”（使用 WebMCP 的网页，可以想成是把工具实现在客户端脚本里、而非后端上的 MCP server。）具体做法是：页面调用 document.modelContext.registerTool()，给出名称、自然语言描述、输入的 JSON schema 与执行回调；浏览器智能体通过一次观察取得这些工具的视图；而草案坦率地承认线缆格式不是它要管的事——“Despite the name of this API (i.e., WebMCP), this specification does not prescribe the format in which tools are exposed to the browser agent.” 草案还给出三个可选标注：readOnlyHint、untrustedContentHint 与 consequentialHint，其中最后一个被描述为一个信号，“that the tool performs a consequential action, such as booking a flight or transferring money”（表明该工具会执行后果重大的动作，例如订机票、转账）。W3C 会议日程上另有 2026 年 10 月 28 日的一场 breakout 会议，标题为「Integrating WebMCP into WebExtensions」。
2. 规范内部的那句让步
这才是这份草案对我们而言比任何新闻稿都重要的原因。在第 6.3.2 节「意图的失实陈述」里，编辑们把问题写得毫不婉转：“There is no guarantee that a WebMCP tool's declared intent matches its actual behavior.”（无法保证一个 WebMCP 工具声明的意图与它的实际行为相符。）再往下一行，是那句该贴在每个智能体团队墙上的话：“This creates a fundamental trust gap: agents rely on natural language descriptions to decide whether to invoke a tool and whether to prompt the user for permission, but cannot verify the tool's actual effects before execution.”（这造成了一个根本性的信任缺口：智能体依据自然语言描述来决定是否调用一个工具、是否提示用户授权，却无法在执行前核验该工具的实际效果。）
草案接着列出它称之为「当前缺口」的几条，那四条读起来就像第二根柱子的规格书：“No verification mechanism: Agent implementers cannot verify that tool implementations match their descriptions”（没有验证机制：智能体实现者无法核验工具实现与其描述是否相符）；“Semantic ambiguity: Natural language descriptions are subjective and open to interpretation”（语义含混：自然语言描述主观且可有多种解读）；“No behavioral contracts: Unlike typed APIs, tool behaviors cannot be statically analyzed or verified”（没有行为契约：与带类型的 API 不同，工具的行为无法被静态分析与验证）；以及那句点明了行业实际姿态的——“Agent trust assumptions: Agents must assume good faith from site developers.”（智能体的信任假设：智能体只能假定站点开发者的善意。）草案所假定的基线让利害变得具体：“Identity inheritance: Agents are able to inherit user identity and authentication context from the browser. When an agent visits a website, it carries the user's logged-in credentials and session state.”（身份继承：智能体能够从浏览器继承用户身份与鉴权上下文。当智能体访问一个网站时，它带着用户已登录的凭据与会话状态。）也就是说，被调用的那个工具，是「以你的身份」被调用的。
3. 另一条战线：151 款说了不的应用
草案发布两天前的 2026 年 10 月 14 日，国内一款手机智能体助手公布了其拒绝清单的最新版本。各家报道口径一致：该助手的《屏幕自动化操作声明协议》（SAEP）走完 30 天公示期，同时公布了声明拒绝的应用清单。中国经济网给出的数字是 151 款，其他报道表述为「150 余款」；报道中的构成是腾讯系 65 款、阿里巴巴系 23 款、快手系 14 款、美团系 11 款、其余独立应用 34 款，点名包括微信、QQ、淘宝、支付宝、美团、快手、拼多多、小红书、WPS、DeepSeek、Kimi，以及多家银行与运营商的应用。
这份清单有两点值得从噪音里分出来。第一，被拒绝的东西很窄：拒绝的是图形界面智能体读屏并模拟点击、滑动来代用户操作应用——人自己打开使用这些应用，一切照常。第二，也正是与本文相关的那一点：给出的理由并不单纯是保护主义。《中国新闻周刊》的报道引述了一位工程师的说明：该助手通过屏幕自动化方式操作应用，并未获得应用方的明确授权，而「App 无法确认操作者究竟是手机持有者本人还是豆包智能体,抑或是被木马、黑客控制的智能体。一旦出现风险,责任很难界定」。同一批报道中的另一处分析说得更直白：头部平台拒绝的不是技术本身，而是「被绕过」。
4. 两个方案在这一周的位置
把两条战线放在一起，这个缺口的形状就不再抽象了。浏览器侧，页面拿到了一套声明能力的词汇，而且用得很好；它没有拿到的是一套确立「哪个智能体在调用」、并在执行那一刻重新核验声明的方式。手机侧，应用被要求接受一次无法归属的触摸，而它只能用唯一可用的方式回答——不。两边都在等同一两行。
RTTP（rttp://）回答在哪与何时——第一行。在我们的方案里，调用者的名字不是在描述字段里声明出来的，而是算出来的：SHA-256(canonical_authority)[:16]，是它所代表的那个权威的函数。自然语言写下的声明可以被改写，注册表里的名字可以被先到者占据，而派生出来的名字无法被扭向一个它不是由之算出的权威。这正是浏览器这条战线在问「哪个智能体调用了」时所缺的性质，而它是算术，不是政策。
IQA（iqa://）回答是否——第二行，也正是 WebMCP 草案列为「没有验证机制」的那一行。证明信封以 Ed25519 签名承载陈述；standing 是 120 秒租约加四态（ghost、probation、radiant、genesis），于是事实有保质期、会被重新核验，而不是被无限期地信任；畸形输入 fail-closed；验证是本地算术，这才让离线三测——断网、生存、解释——有意义。放到手机这条战线上，这就是「应用收到一次触摸」与「应用收到一份可自行核验的、关于谁在代表谁行事的签名陈述」之间的差别。
该给的肯定要给：consequentialHint 的方向是对的。一个提示「此动作后果重大」的信号，是这个行业必须开始的那场对话的开头。但提示是当事业者自己作出的陈述，不是证据——草案自己的缺口清单就是这么写的。对这一周最诚实的总结是：声明能力的那一侧，与拒绝被操控的那一侧，都正确地指向了同一个缺席。
网络正在学会声明自己能做什么。手机正在学会要求「谁在问」的证据。两条战线，一周之内，同一个缺失层——而这一周，两边各自用自己的词汇、相隔四天，把这块缺失说了出来。这不是巧合，是同一行在要求被填上。