前言：为什么前端开发者需要关注 Agentic Web
过去十年，前端开发的演进路径是清晰的：jQuery 时代、框架时代、SPA 时代、SSR 时代。每次范式转移都有可预期的坐标轴——性能、开发者体验、用户体验。但在 Google I/O 2026 上，一个新的坐标轴突然变得无法忽视：AI Agent 如何使用你的网站。
这不是科幻场景。Chrome DevTools MCP 已经有 39K+ GitHub stars，LY Corporation 接入后人工分析工作量减少了 96-98%。WebMCP 从提案到 Chrome 149 Origin Trial 只用了不到一年。Google 和 Microsoft 罕见地在这件事上联手推进 W3C 标准化。信号的强度和速度都告诉我们这不是「可能会发生」的事——这是正在发生的事。
Agentic Web 的核心命题是：网站不再只是给人看的，网站要给 AI Agent 提供可操作的接口。这意味着我们过去积累的大量前端工程实践需要重新审视：交互模式、状态管理、甚至 HTML 语义都会直接影响 Agent 对产品的理解能力和操作能力。
这篇文章不是入门科普。如果你对 WebMCP、Agent 协议栈这些概念已经有基础认知，可以直接跳到感兴趣的章节。如果你是第一次接触，建议按顺序读——因为这些技术之间的关系比任何一个独立的技术点都重要。
WebMCP：让网站从"可读"变成"可执行"
问题背景
在 WebMCP 出现之前，AI Agent 访问网站的路径非常受限：要么用 Browser Use 类的截图 + 视觉模型方案，昂贵且不稳定；要么靠爬虫抓取 DOM，丢失所有运行时状态（登录态、购物车、用户偏好）。Agent 能「看到」你的网站，但无法真正「使用」它——它不知道你当前登录的是哪个账号，不知道你购物车里有什么，更无法替你完成「把商品加入购物车」这个有副作用的操作。
WebMCP 的出现解决了一个根本问题：让浏览器本身成为 Agent 的工具箱，而不是让 Agent 自己去操作浏览器。这是一个思路上的根本转变。
工作原理
WebMCP 的架构设计非常务实：浏览器充当通信桥梁，Agent 通过浏览器代理访问实时会话数据、Cookie、DOM 元素，并且继承浏览器已有的认证状态。Agent 调用的是网站主动暴露的工具，而不是暴力解析页面。
核心 API 只有两个：
// 注册工具
navigator.modelContext.registerTool(tool, options);
// 注销工具
navigator.modelContext.unregisterTool(name);
registerTool 接收一个工具定义对象，包含名称、描述、输入 schema 和执行函数。工具注册后，当前的浏览器会话就变成了一个可被 Agent 调用的工具集。
需要注意的是，WebMCP 不是无头调用——它绑定活动标签页，你无法在后台静默执行所有操作。这既是安全边界，也是产品设计的隐含约束：推荐模式是一组小型、专注的工具（产品搜索、愿望清单、订单历史），而不是单一的"帮我做所有事"大工具。这种设计哲学和 Unix 的工具集理念一脉相承——做一件事，做好它。
代码示例
原生 API 调用：
// 注册一个待办事项添加工具
await navigator.modelContext.registerTool({
name: 'add_todo',
description: 'Add a new todo item to the task list',
inputSchema: {
type: 'object',
properties: {
title: { type: 'string', description: 'The todo item title' },
done: { type: 'boolean', description: 'Mark as completed', default: false }
},
required: ['title'],
},
execute: async (args) => {
// 这里可以调用你的后端 API、写入 IndexedDB、更新本地状态
const todo = { id: Date.now(), title: args.title, done: args.done ?? false };
return { id: todo.id, status: 'added' };
},
});
实际项目中推荐使用 @web-ai-sdk/webmcp 配合 TypeScript 和 Zod 获得完整的类型安全：
import { defineTool } from "@web-ai-sdk/webmcp";
import { z } from "zod";
// 联系我们表单工具 - destructive: true 表示会发送邮件，有副作用
const sendEmail = defineTool({
name: "send_contact_email",
description: "Send a contact email on behalf of the visitor.",
destructive: true,
input: z.object({
name: z.string().min(1, "Name is required"),
email: z.string().email("Invalid email address"),
subject: z.string().min(1, "Subject is required"),
message: z.string().min(1, "Message is required"),
}),
execute: async ({ name, email, subject, message }) => {
// 调用邮件服务 API
return { success: true, messageId: crypto.randomUUID() };
},
});
// 工具集合
export const mySiteTools = [sendEmail];
destructive: true 这个标记很有意义——它告诉 Agent 这个工具会产生副作用（发送邮件、扣款、删除数据），Agent 在调用前需要用户确认。这不是可选的装饰字段，而是产品安全设计的核心部分。
效果与落地节奏
Chrome 149 已经开启 Origin Trial，预期 2026 年中后期获得广泛支持。Microsoft Edge 与 Google Chrome 联合推进，W3C 标准化流程正在进行中。现在是评估和实验的最佳时间窗口。
一个典型的落地场景：电商网站的「查看订单历史」功能。传统做法是 Agent 截图解析订单页面，提取信息容易出错。WebMCP 方案是注册一个 get_order_history 工具，Agent 直接调用获取结构化数据，准确率接近 100%，响应延迟从秒级降到毫秒级。
新 Web API 速览：不是所有变化都叫 WebMCP
Agentic Web 不只有一个主角。I/O 2026 同时发布了一系列浏览器 API，它们共同构成了 Agent 友好 web 的基础设施层。挑几个对前端开发者有直接影响的：
Prompt API
Chrome 148 稳定版已发布。新增了 temperature 和 topK 采样参数，支持多模态输入和可靠 JSON 输出。对前端而言，这意味着可以直接在浏览器中集成 AI 推理能力，而不需要依赖外部 API：
const session = await window.ai.createTextSession();
const stream = session.promptStreaming('Summarize this article', {
context: articleText,
temperature: 0.7,
topK: 40,
});
for await (const chunk of stream) {
outputElement.textContent += chunk;
}
这不是玩具 API——Gemini Nano 已经在 Chrome 148+ 中可用，支持摘要、翻译、写作辅助。Gemma 197M 是轻量级本地模型，「Nano Banana」项目甚至支持本地图像生成。浏览器正在变成一个本地 AI 运行平台。
Soft Navigations API
Chrome 147 Final Trial。SPA 开发者苦 Core Web Vitals 测量久矣——传统 CWV 只测量初始页面加载，SPA 的客户端路由从未被正确追踪。Soft Navigations API 首次为 SPA 带来了完整的 CWV 测量能力：
// 自动检测：pushState + DOM 变更 + URL 变更
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
if (entry.entryType === 'soft-navigation') {
console.log('Soft nav detected:', entry.name);
// 测量 LCP、INP、CLS 等指标
}
}
});
observer.observe({ type: 'soft-navigation', buffered: true });
这对 Agentic Web 有直接影响：Agent 在执行多步骤任务时（搜索 → 筛选 → 详情页），SPA 的性能指标终于可以被准确测量和优化。
Declarative Partial Updates
Chrome 148 测试版。这个 API 让 fetch 响应可以直接管道式传入 DOM，无需 JavaScript 中间层处理：
<template for="item" id="product-card">
<article class="product">
<h3>{title}</h3>
<p>{description}</p>
</article>
</template>
<script>
const stream = fetch('/api/products').body;
document.querySelector('#product-list').populate(stream);
</script>
对于 Agent 场景，这意味着 Agent 可以直接「观察」数据流的变化，而不需要理解前端的状态管理逻辑。数据从后端到 DOM 的路径越短，Agent 理解它的成本越低。
HTML-in-Canvas
这是一个看起来最「炫」但落地最远的技术：将真实 DOM 元素直接集成到 WebGL/WebGPU Canvas，构建沉浸式 3D 体验，同时保持可搜索、可访问和原生可翻译能力。对大多数前端项目来说，这还不是需要跟进的技术，但它是 Agentic Web 追求「人机界面融合」愿景的技术注脚。
A2UI 协议：AI Agent 怎么"说 UI 语言"
问题背景
WebMCP 解决了「Agent 如何调用网站工具」的问题，但另一个问题紧随而来：Agent 的输出结果如何呈现给用户？
传统架构中，Agent 返回的是文本或结构化数据，前端负责渲染 UI。但这里有一个根本的不匹配：Agent 生成的是「意图描述」，而传统前端需要的是「确定性的 UI 状态」。Agent 说「显示一个日期选择器，让用户选择时间」，前端收到这条消息后需要自己决定用哪个组件、如何布局、如何处理交互——这层翻译工作往往比 Agent 的推理本身还复杂。
A2UI（Agent-to-User Interface）协议解决的就是这个问题：让 AI Agent 直接用声明式 JSON 描述 UI 布局和组件，前端渲染引擎负责将 JSON 映射到实际 UI。
协议设计
A2UI 是一个纯数据格式规范，不是可执行代码。它定义了一套标准化的组件语义——Text、DateTimeInput、Button、List 等——Agent 生成的是组件树的结构化描述，而不是 HTML/CSS 字符串。
{
"surfaceUpdate": {
"surfaceId": "main",
"components": [
{
"id": "header",
"component": {
"Text": {
"text": { "literalString": "预订餐厅桌位" },
"usageHint": "h1"
}
}
},
{
"id": "date_input",
"component": {
"DateTimeInput": {
"label": { "literalString": "选择日期和时间" },
"value": { "path": "/reservation/datetime" },
"enableDate": true,
"enableTime": true
}
}
},
{
"id": "confirm_button",
"component": {
"Button": {
"label": { "literalString": "确认预订" },
"onPress": { "action": "submit_reservation" }
}
}
}
]
}
}
几个值得注意的设计决策：
可信组件库（Catalog） 。A2UI 不允许 Agent 发明新的 UI 模式，所有组件必须来自预定义的可信组件库。这既保证了安全性（没有 XSS、代码注入风险），也保证了可用性（Agent 生成的 UI 不会长得离谱）。
跨框架可移植。JSON 描述与具体框架无关，Vue/React/Svelte 都可以实现自己的 A2UI 渲染器。你的产品用 Vue 实现，不妨碍 Agent 用 A2UI 描述它需要的 UI。
流式生成。A2UI 支持流式输出，Agent 可以边推理边输出组件描述，用户看到 UI 逐个出现——这是「实时思考过程展示」这个新 UI 形态的数据基础。
与现有协议栈的关系
A2UI 处于协议栈的最顶层（UI 描述层），它的下方还有：
- AG-UI：Agent 与前端的实时交互传输层
- WebMCP：浏览器层，Agent 与网站的交互
- MCP/A2A：后端层，Agent 间协作和工具调用
┌─────────────────────────────────────┐
│ A2UI（UI 描述层） │ ← Agent 如何"说 UI 语言"
├─────────────────────────────────────┤
│ AG-UI（通信传输层） │ ← Agent 与前端的实时交互
├─────────────────────────────────────┤
│ WebMCP（浏览器层） │ ← Agent 与网站的交互
├─────────────────────────────────────┤
│ MCP/A2A（后端层） │ ← Agent 间协作、工具调用
└─────────────────────────────────────┘
理解这个分层非常重要。WebMCP 解决的是「Agent 能做什么」的问题，A2UI 解决的是「Agent 的结果怎么看」的问题。两者缺一不可，共同构成 Agentic Web 的双轮驱动。
语义 HTML 的复仇：Agentic Web 对前端开发模式的影响
被忽视的基础设施
WebMCP 和 A2UI 是 I/O 2026 的明星技术，但有一个影响更深远但容易被忽视的变化：语义 HTML 的价值在 Agentic Web 时代被重新定价了。
过去十年，前端社区对语义 HTML 的态度是「知道重要，但优先级不高」。带 onClick 的 <div> 和 <button> 在人眼看来没有任何区别，浏览器渲染结果完全一致。大多数团队选择用 <div> 加上 role="button" 来实现按钮，因为「反正用户点得动就行」。
但 AI Agent 不是人眼。Agent 解析页面的方式和你写爬虫时解析页面的方式没有本质区别——它需要理解页面结构才能导航。一个 <div role="button"> 告诉 Agent 的是「这可能是个交互元素，不确定」；一个 <button> 告诉 Agent 的是「这是一个明确的操作触发点」。
Agent 友好页面的实质差异
这不是玄学，这是可量化的工程差异。以下是几个具体的对比：
表单提交。Agent 需要提交表单时，<form action="/api/submit" method="POST"> 提供了明确的操作目标和 HTTP 方法推断。<div> 嵌套加上一堆事件监听器让 Agent 只能去猜「这个区域里的哪个点击会触发提交」。
导航结构。<nav> 标签内的链接是明确的导航入口，<div class="nav-links"> 需要 Agent 自己判断「哪些是导航、哪些是装饰、哪些是内容」。
内容分区。<article>、<aside>、<main> 这些标签为 Agent 提供了页面内容的语义分区，Agent 可以直接定位到「主要内容」而不是猜测哪个 div 块是主要内容。
可访问性（a11y）与 Agent 可读性的同构。语义 HTML、可访问 ARIA 标签、键盘焦点管理——这些传统上被视为「可访问性友好」的设计实践，在 Agentic Web 时代变成了「Agent 友好」的设计实践。两者的本质需求是一样的：让非人类实体能够理解页面的结构和意图。
旧债与新账
可以预见的是，大多数存量 Web 产品在 Agentic Web 评估中会暴露大量的「技术债务」——div-soup 结构、内联样式、缺失的语义标签。这些产品在传统前端指标上可能表现不差，但在 Agent 能否高效操作它们这件事上会得低分。
这不是说我们要推翻重写。而是说在 Agentic Web 时代，新增功能和代码重构时需要多一个评估维度：这个改动是让 Agent 更容易理解还是更难？
传统前端 vs Agentic Web 前端：范式转移的实感
Agentic Web 不是一个新框架，它是一个新的交互范式。用表格来对比可能太教科书了，直接说几个核心差异：
交互模式变了。传统前端是「用户点击 → 即时响应 → 状态更新 → UI 渲染」的确定性链路。Agentic Web 前端是「用户指令 → Agent 推理 → 流式返回 → 动态 UI 生成」的不确定性链路。你写的代码不再直接响应用户行为，而是响应 Agent 的意图输出。
状态管理的逻辑变了。传统状态管理（Pinia、Zustand、Redux）解决的是「状态如何组织和更新」的问题。Agentic Web 的状态一部分来自用户操作，一部分来自 Agent 的推理结果。Agent 输出的状态可能是非确定性的——同一个任务，Agent 每次的推理路径可能不同，产生的副作用也不同。这要求我们对「状态一致性」有完全不同的理解。
错误处理的思路变了。传统前端的错误处理是防御性的：已知错误类型 → 已知处理方式 → 用户提示。Agent 的行为空间是开放的，它可能用完全意想不到的方式调用你的工具，产生你从未考虑过的副作用。这要求我们重新设计工具的边界——每个工具的职责要足够小，副作用要足够可预期。
UI 反馈的形态变了。传统前端用加载动画表示「请等待」。Agentic Web 前端需要展示 Agent 的「思考过程」——流式输出、逐步推理、中间状态可见。这不是简单的 loading 组件，而是全新的 UI 叙事模式。
开发者行动指南：短期/中期/长期准备
理论讲完了，该说怎么干了。按照时间维度分三个阶段：
短期（1-3 个月）
了解 WebMCP 规范和 API。阅读 W3C 提案文档，在 Chrome 146+ 中启用实验性标志（chrome://flags#model-context-protocol），亲手跑通一个工具注册和调用的完整流程。看文档一万字不如动手十分钟。
尝试 MCP-B polyfill。对于还不支持 WebMCP 的环境，MCP-B 提供了 polyfill 方案，可以提前熟悉工具定义和注册的工作流。
评估网站的工具注册潜力。不是所有功能都值得注册为工具。优先级判断标准：高频操作（减少重复点击）、结构化数据查询（订单、账户信息）、有副作用的操作（需要 Agent 有明确意图才能安全执行）。不要过度设计——一个专注的工具胜过五个半吊子的工具。
部署 Modern Web Guidance。Google 提供了专家审核的编码指导，100+ 场景覆盖，帮助你的代码对 AI Agent 更加友好。这是投入产出比最高的基础设施投入。
中期（3-6 个月）
设计核心业务工具的 WebMCP Schema。基于短期评估的结果，为你的核心业务功能设计工具定义。这包括：工具命名规范（namespace_feature_action 格式）、输入输出的 schema 设计、错误处理的约定。好的工具设计是 API 设计能力的延伸，这件事值得投入时间。
集成 Chrome DevTools MCP。如果你在构建前端开发工具或调试基础设施，这是高价值投入。如果你的产品需要 Agent 辅助调试能力，这也是加分项。
探索 A2UI 协议。目前协议仍在快速演进中，但理解它的设计思路（声明式组件描述 + 可信组件库 + 流式生成）可以帮助你提前思考 Agent 输出结果如何融入你的产品 UI。
评估 Prompt API 的应用场景。Gemini Nano 已经在浏览器中可用，本地推理能力不再需要云端 API。适合的场景：用户隐私敏感的摘要需求、低延迟的本地翻译、需要离线可用的 AI 功能。
长期（6-12 个月）
构建 Agent 友好的产品体验。这不是技术问题，是产品设计问题。你需要回答：你的用户会在什么场景下想要一个 Agent 来操作你的产品？Agent 和用户的分工边界在哪里？工具的设计如何平衡「操作便利性」和「安全边界」？
参与 W3C WebMCP 标准化讨论。WebMCP 仍处于 W3C 孵化阶段，规范会发生变化。如果你有实际的落地经验，参与标准讨论的声音可以帮助协议向更实用的方向演进。标准的制定者往往是最早落地的人。
重新审视前端架构的可 Agent 化程度。从状态管理到路由设计，从 HTML 语义到 API 设计——Agentic Web 会是一个持续的反光镜，照出你现有架构中哪些地方在「凑合」。这是一个架构升级的契机，不只是技术跟进。
写在最后
Agentic Web 不是一个「会不会来」的问题，而是一个「什么时候成为主要交互模式」的问题。WebMCP 在一年内从提案到 Chrome 149 Origin Trial，Chrome DevTools MCP 在发布后迅速获得 39K stars，Google 和 Microsoft 罕见地在浏览器层面达成共识——这些信号指向同一个结论：基础设施的到位速度比大多数人的预期快。
作为前端开发者，我们面对的不是一个新框架的选型问题，而是一个关于「前端开发的职责边界在哪里」的根本性问题。当 AI Agent 开始成为用户和网站之间的中间层，前端代码的消费者从「人」变成了「人 + Agent」，我们需要重新思考从 HTML 语义到状态管理的每一个决策。
好消息是，这不是一个需要推翻重来的局面。语义 HTML、组件化、工具化 API 设计——这些我们已经在践行的工程实践，在 Agentic Web 时代会获得更大的战略价值。欠下的技术债需要还，但方向是对的。
真正的问题不是「要不要跟进 Agentic Web」，而是「我的产品在哪一步引入 Agent 的能力最自然、最有价值」。这个问题没有标准答案，但它值得每一个前端团队认真思考——不是在将来，而是在现在。
本文由AI辅助整理
