网页的下一个用户不是人：从“给人看”到“给人+Agent 共同消费”

网页正在经历一次角色转换。过去二十年，HTML 的唯一消费者是浏览器里的人；从今天起，每一次页面请求背后，可能站着一个正在替人做决策的 Agent。这个变化催生了三条并行的技术路线，也暴露出一个至今没人解决的核心命题：站点为什么要为机器适配？

三条线：浏览器侧、服务端侧、抓取侧

第一条线，W3C WebMCP（浏览器侧）。 由 Google 与 Microsoft 联合推动、在 W3C WebML 社区组孵化的 WebMCP，核心思路是让网页通过 navigator.modelContext 主动向浏览器内的 Agent 暴露结构化工具（Tool），把交互从“截图+DOM 猜测”的视觉层，抬升到带有名称、描述和 JSON Schema 的语义层。Chrome 146 起提供早期预览，Chrome 149 进入 Origin Trial，Angular 等框架也开始提供封装。

但它的边界非常清晰，且短期内难以突破：

• 仍是社区组交付物，不在 W3C 标准轨道上，接口仍在演进；
• 目前仅 Chromium 系实现，跨浏览器一致性尚未形成；
• 需要站点主动适配（声明式的表单注解或命令式的 JS 注册），不改造就毫无收益；
• 受同源隔离与 Permissions Policy 约束，且工具生命周期绑定标签页——关页即失效，无头调用不支持。这意味着后台批处理、定时巡检这类纯 Agent 场景，WebMCP 根本覆盖不到。

换句话说，WebMCP 解决的是“人在环中、Agent 帮人填表”的最后半米，而不是“Agent 自主消费网站能力”的主干道。

第二条线，服务端 MCP / A2A。 这是目前真正能跑通生产的路径。MCP 2026-07-28 规范转向无状态、带缓存策略与确定性排序，工具列表终于可以安全缓存；A2A 则靠 /.well-known/agent.json 的 Agent Card 做发现与能力声明。这条线的特点是：不依赖浏览器、不依赖用户登录态、可鉴权、可计费、可审计——恰好补上了 WebMCP 缺失的那一半。

第三条线，agent meta 标签与抓取策略。 robots.txt 里的 Agent 标识、页面级的元数据与内容标注、面向检索摘要的结构化输出，属于成本最低的一档适配。它给不了“可调用能力”，但决定了 Agent 能不能找到你、敢不敢引用你。这是入场券，不是护城河。

卡点不在技术，在归因

WebMCP 的技术价值没有争议：把 Agent 从概率性的界面猜测，拉回确定性的结构化契约，token 消耗、延迟与失败率都会显著下降。但它绕开了一个更硬的商业问题：站点投入适配的 ROI 是什么？

对人提供服务时，归因链条是现成的——PV、UV、加购、下单，归因模型跑了二十年。对 Agent 则几乎空白：一个 Agent 替你比价、下单、改签，这笔转化记在谁头上？站点拿得到佣金，还是只被当成免费的 DOM 数据源？如果调用发生在浏览器内、复用用户登录态、流量入口却是某个大模型的助手，那么电商、SaaS、OTA 的投放团队没有任何理由为一个“无法计入 KPI 的渠道”排期。

这个逻辑反过来也成立：只有当 Agent 流量能被计费、分成或计入转化时，大规模适配才会发生。 值得注意的信号是，变现层已经在协议之外自发长出来了——MCP 网关按请求数与流量计费、聚合广场按工具调用抽成、x402/HTTP 402 与 MPP 这类 Agent 微支付方案开始接入商户端。协议本身免费，但插口两边的集线器都在收租。这固然引发争议，却也证明了一件事：“Agent 流量可计量”这件事，工程上已经可行，缺的只是行业公认的归因口径。

现阶段最务实的做法：先做好四件事

与其等浏览器标准成熟，不如先把服务端这一侧做成“Agent 一等公民”。成本不高，收益立刻可见：

1. 给 Agent 一套可读的 HTTP 接口。 保持 RESTful 或 RPC 风格均可，关键是幂等、错误码稳定、分页与增量同步机制明确。Agent 最怕的是语义漂移——同一个字段这周叫 status，下周变成 state。

2. 明确的鉴权。 区分人用 Token 与 Agent 用凭证，支持短期凭证与工作负载身份，避免让 Agent 长期持有用户的高权限 Cookie。WebMCP 的优势是天然复用登录态，而服务端的代价则是必须重新设计信任边界。

3. 明确的速率限制与配额。 这是最容易被低估的一项。人的点击有物理上限，Agent 没有。不加限流，一次错误的重试循环就能打穿你的库存或账单。建议按 Agent 身份做分级配额，并对写操作设置更紧的阈值。

4. 一份给 Agent 看的文档。 不是给人看的营销式 API 文档，而是机器可直接消费的 OpenAPI 描述 + Agent Card + 一份“如何调用我”的纯文本指引（放在 /.well-known/ 下）。写清楚：你能做什么、参数约束、副作用、失败怎么重试、什么操作需要人工确认。这份文档的质量，基本等于你的服务在 Agent 生态里的可发现性与可信度。

这四件事做完，你已经覆盖了纯 Agent 场景、无头调用、跨域编排与可计费链路。等到浏览器侧标准尘埃落定，再补一层 WebMCP 的声明式注解，不过是几小时的工作量——而且届时你大概率会发现，核心业务逻辑早就在服务端 MCP 里跑熟了。

网页从“给人看”走向“给人和 Agent 共同消费”

技术路线已经清晰，商业路线还在摸索。决定这场迁移速度的，大概率不是哪个 API 先成为标准，而是第一套被行业接受的 Agent 流量归因与分账规则何时落地。在那之前，把接口、鉴权、限流和机器可读文档做好，是唯一一件稳赚不赔的事。