摘要

  • W3C 战略议题 560 仍处于开放状态，将 WebMCP 视为本轮章程的实质性变更，并把完善工作的预计结束时间标为未知。
  • 开放的拉取请求 829 拟加入浏览器原生代理集成、命令式 JavaScript 工具注册和基于 HTML 表单的声明式路径；WebMCP 被列为暂定交付物。
  • 补丁没有修改章程中点名的协调清单，但战略议题本身要求 HTML、ARIA、TAG、SING 和隐私参与者评审。
  • WebKit 记录为反对，Mozilla 为中立，APA 不支持当前报告，安全威胁建模仍在进行；这些都不是 W3C 的最终决定。
  • 在顾问委员会评审前，应公布一张“范围—责任人”协调矩阵，区分所有权、依赖、咨询和横向评审，同时不把任何评审者自动变成否决者。

这份差异稿改变的是授权边界

首先必须把状态说准。战略议题 560 于 2026 年 6 月 9 日创建，目前仍开放，预计何时结束完善工作尚不明确。拉取请求 829 同样未合并，头部只有当天的一次提交。由此能够确认的是“有人提出扩大范围”，而不是“章程已经批准”“WebMCP 已被采纳”或“浏览器标准已经进入实施”。

但提案并不轻微。现行 Web Machine Learning 章程围绕机器学习推理展开：低层 WebNN API、平台加速器访问，以及可能的模型加载。补丁把单数的 Web API 改成复数，并加入“浏览器中的原生 AI 代理集成”，随后展开两条新的能力路径。

命令式路径允许网页把 JavaScript 函数注册、更新或移除为结构化工具，并提供说明和类似模式定义的输入。声明式路径则让标准 HTML 元素，特别是表单，附带可供代理发现操作的标注。文本还涉及浏览器中介、同源边界、用户授权，以及代理对页面功能的直接调用。

这让一个原本以推理接口为核心的工作组同时触及浏览器执行、HTML 创作模型、无障碍语义和代理安全边界。把 WebMCP 标成“暂定”保留了后续门槛：孵化进展、多家实现者的兴趣，以及工作组共识。它并没有让这次授权扩张变成普通措辞修订。

协调清单仍停在旧范围

拉取请求改了范围和暂定交付物，却没有改“额外技术协调”部分。公开草案沿用原有名单：Web Machine Learning Community Group、GPU for the Web Working Group、WebAssembly Community Group、WebRTC Working Group 和 Technical Architecture Group；W3C 外部则列出 ECMA TC39。

章程也有一段总括性要求，规定对无障碍、国际化、隐私、安全和架构进行横向评审。这一点不能忽略，它说明提案没有宣称可以绕过评审。然而，“必须接受横向评审”与“点名一个依赖关系”解决的是两类问题。

横向评审者检查跨领域要求是否得到处理。依赖条目则应说明：哪一层由另一个组织维护、哪个交付物会影响该层、双方通过何种机制沟通。共同所有者、规范维护者、受咨询工作组和横向评审者的权力并不相同。只要方案直接映射 HTML 表单，又会影响 ARIA 或无障碍树，这些角色就应被分开记录。

战略议题已经知道需要哪些参与者：HTML、ARIA、TAG、Security Interest Group 和 Privacy。公开评论也证明沟通不是空白。真正的缺口在于，评审网络尚未被转化为拟议章程中的责任和通信结构。

四类公开意见不能合成一个“社区态度”

WebKit 的记录是反对。其说明认为 WebMCP 可能形成一套平行的代理界面，有些缺口应在共享的 HTML 与无障碍语义中解决，并质疑由 Machine Learning 场域决定这些层如何演进。Apple 代表后来在章程拉取请求中表示，如果补丁合并，预计会提出正式异议，同时愿意讨论其他 W3C 场域。这是一项严肃反对，但它不是否决权，也不是对章程的处置结果。

Mozilla 的状态是中立。它认为这种抽象可能有价值，同时保留对风险、命名、生态边界以及命令式和声明式设计的疑问。8 月下旬的讨论仍在继续。中立不等于实现支持，也不能被改写成反对；它表示问题尚未关闭。

Accessible Platform Architectures 工作组 8 月 27 日的意见更具体。参与者承认该方向可能为实验性辅助技术，特别是认知无障碍带来机会，但明确表示不支持当前 Community Group 报告。他们要求用户能看见工具的发现过程，能够审查、批准、取消和撤销代理行为，并强调 WebMCP 信息不应替代无障碍树。评论还警告人类可见能力与代理可见能力发生分叉，认为声明式方向的起点较好，但仍应保持实验性质。

安全记录处在另一个阶段。Security Interest Group 7 月会议纪要讨论站点、浏览器、代理和用户之间的信任边界，涉及工具内容、跨源暴露、用户可见性和工具生命周期。纪要描述的是迭代中的威胁模型，既不是安全背书，也不是安全否决。

反对、中立、有条件的不支持和仍在分析，是四种不同的制度状态。把它们压成一个“社区共识分数”，恰好会抹去章程完善阶段最需要保存的证据。

W3C Process 要求依赖关系和异议处置

W3C Process 要求工作组章程定义范围与交付物，识别与其他组织相互依赖的关系；当其他组织依赖本组交付物时，还应注明沟通机制。进入顾问委员会评审前，广泛评审必须完成，针对章程草案提出的问题必须得到正式回应，解决方案要进入意见处置记录，持续异议需要醒目标注。

这些规则并不意味着每个受影响的工作组都自动成为共同所有者，更不意味着每个横向评审者都拥有单方面否决权。协调表不应成为隐藏的否决表。它只需让三个问题可核查：谁拥有受影响的层，冲突通过什么渠道上报，最后由谁作出归责明确的处置。

范围扩张时，这种准确性更重要。若新增的 Recommendation 路线交付物超出现有交付物范围，便属于重大章程变更，需要顾问委员会评审。与此同时，现行章程有效至 2027 年 4 月 30 日，仍是 Web Machine Learning 工作的实际授权。开放补丁不会提前产生一项新授权。

用矩阵记录责任，而不是预判场域

可以在章程差异稿旁放置一张公开、版本化的矩阵。每一行记录：章程版本与不可变提交、拟议规范界面、受影响的平台层、拟授予工作组的权限、点名的依赖方或维护方，以及该组织究竟是共同所有者、依赖方、联络方、受咨询方还是横向评审方。随后再列出公开通信渠道、评审请求与回复、未解决异议及理由、采纳或转移触发条件、专利政策与文档成熟度状态、下一责任人和核验日期。

针对声明式表单的一行，可以指明 HTML 层及相关规范维护者，而不假设他们都要共同编辑 WebMCP。无障碍的一行可以把 ARIA 或无障碍树的所有权与 APA 的横向评审职责分开。安全的一行应写“威胁建模进行中”，而不是画一枚绿色对勾。浏览器厂商立场也应与工作组共识和 W3C 批准分别保存。

这张矩阵不会替 W3C 决定 WebMCP 应留在 Web Machine Learning、转入新工作组、由多个场域协作，还是继续留在 Community Group。它只是阻止这些选择被藏在一个笼统的“协调”词汇里。

Heng Lu 的最小初始规范原则提供了制度边界：共同记录只承担协调所需的最小连接，未来决策仍留给拥有相应层的参与者。应用在这里，目标不是把代理 Web 的所有问题集中到一个工作组，而是避免一个章程因未写明边界而静默继承相邻层的权力。

证据没有证明什么

协调名单没有点名某个工作组，并不能证明私下会议或非正式沟通从未发生。Apple 的反对不等于 W3C 拒绝提案。Mozilla 的中立不等于实现者已经达成共识。APA 的意见没有否定所有可能的代理 Web 设计，安全纪要也没有证明 WebMCP 一定不安全。

现有材料同样无法证明采用、互操作或部署。WebMCP 文档仍是 Community Group 报告；章程补丁仍开放。孵化报告、暂定章程项目、工作组正式采用、Working Draft 和 Recommendation 是不同状态，不能压缩成一条已经启动的标准化直线。

可确认的治理事实很窄：一项开放补丁拟让一个工作组探索明确涉及 HTML 和浏览器代理的规范界面，却保留了旧机器学习范围下的点名协调清单。公开评审已经让相关参与者与悬而未决的问题可见。下一步应在范围变成正式授权之前，把这些参与者连接到明确角色和可追溯处置。

来源

  1. W3C Strategy — Web Machine Learning 章程议题 560
  2. W3C charter-drafts — 拉取请求 829
  3. W3C charter-drafts — WebMCP 范围提交
  4. W3C — Web Machine Learning 章程公开草案
  5. W3C Process — 章程内容要求
  6. W3C — 现行 Web Machine Learning 章程
  7. WebKit — WebMCP 标准立场
  8. Mozilla — WebMCP 标准立场
  9. WebMCP 议题 65 — APA 无障碍评审
  10. W3C Security Interest Group — WebMCP 威胁模型会议纪要
  11. Web Machine Learning Community Group — WebMCP 报告
  12. Heng Lu — 最小初始规范、未来决策本地化与自愿采用