Join the WebMCP origin trial

Chrome 149 开始提供 WebMCP origin trial 之后，网页和代理之间的关系会变得更直接：页面不再只把 DOM 和可见文案摆出来给机器猜，控件自己也可以声明用途、状态和可执行边界。这个变化看起来像一次 API 试用，实际更像把“界面意图”从隐含信息抬到显式协议里。

WebMCP 这类东西的价值，不在于给网页再加一层术语，而在于把代理最怕的那部分不确定性收紧。一个按钮到底是提交、切换、确认，还是只是打开一个弹层；一个输入框到底是日期、搜索词，还是需要特殊格式的预约时间，这些信息以前主要靠文本、结构和上下文推断。推断能跑起来，但一旦页面复杂，代理就会开始把“看起来像”当成“就是”。

对人来说，这种误读通常只是一次点错。对代理来说，误读会变成稳定的错误路径。它会继续沿着错误理解执行，直到碰到校验、回退或副作用，才暴露出前面那一步已经跑偏。WebMCP 把这层语义显式化之后，代理不必把页面当成一张纯视觉地图来猜，网页也能把关键交互面的职责说清楚。

这件事最适合落在那些本来就很难被纯 HTML 文案讲明白的界面上，比如日历、预订、权限申请、设置面板，或者一堆看起来都像普通输入框、实际却承担不同业务含义的页面。只靠 label 和 placeholder 时，代理经常要绕着页面反复试探；一旦页面能声明“这里是日期选择”“这里是确认动作”“这里的状态只能按这个方向变化”，集成成本会直接降一截。

但 origin trial 也把另一个问题一起摆了出来：这层语义要维护。页面结构会改，按钮文案会改，业务状态会改，代理真正依赖的那层意图如果没有和组件一起更新，很快就会漂移。到那时，最危险的状态不是“完全不能用”，而是“还能跑，只是偶尔跑错，而且错得很自然”。

所以 WebMCP 更像一份给网页自己的契约，而不是给代理贴的提示卡。它要求前端把交互边界写进实现里，写进测试里，写进回归检查里。只要这层契约还停留在演示阶段，代理能理解的只是一次成功案例；等它进到真实页面，真正需要处理的就变成版本兼容、降级路径和声明失效后的兜底。

我更愿意把这次 origin trial 看成一个方向信号。浏览器开始认真考虑代理怎么读懂网页，这意味着前端不只是在给人排版，也在给机器定义动作。页面越复杂，这层定义就越值钱；页面越频繁改动，这层定义的维护成本也越显眼。WebMCP 这类能力最后留下来的，不会是一个新名词，而是前端和代理之间终于有了一种能持续对齐的说法。