网站以后不只给人看，还要给 AI Agent 用：WebMCP 是什么？

这篇文章写给刚开始关注 AI 前端的人。你不需要先懂协议也不需要先了解 MCP。只要你做过网页、用过 AI 助手就能理解 WebMCP 为什么值得前端开发者关注。先说一个正在发生的变化过去我们做网页默认用户是人。人会看标题、读说明、点按钮、填表单。前端开发者要做的是把信息排清楚把交互做顺把状态反馈做好。比如一个普通的“AI 选题助手”页面用户会这样操作输入公众号定位。选择目标读者。点击“生成选题”。从结果里挑选几个想写的题目。保存到选题池。这套流程没问题因为人能理解页面上的文字也能根据上下文判断下一步该点哪里。但 AI Agent 出现以后一个新问题开始冒出来如果使用网页的不只是人还有 AI Agent 呢AI Agent 可以理解你的目标比如帮我根据这个公众号定位生成 20 个适合下周写的 AI 前端选题并挑出最值得写的 3 个。但问题是Agent 怎么操作网页它可以看截图可以识别按钮也可以模拟点击。但这种方式其实很不稳定。按钮文案改了布局调整了弹窗多了一层Agent 都可能点错。页面对人来说仍然很好用但对 Agent 来说可能像在黑箱里摸索。所以一个新的方向出现了网页能不能主动告诉 AI Agent我能做什么、需要什么参数、执行后会返回什么结果这就是 WebMCP 值得前端开发者关注的原因。WebMCP 是什么先不用被名字吓到。你可以把 WebMCP 理解成一种让网页把自身能力结构化暴露给浏览器内 AI Agent 的方式。换成人话就是以前网页只把按钮、输入框、菜单展示给人。以后网页还可以告诉 Agent我有一个“生成选题”的能力。 你需要给我账号定位、目标读者、内容方向。 我会返回一组选题每个选题包含标题、推荐理由和难度评分。这样Agent 就不用靠猜按钮、读页面、模拟点击来完成任务而是可以更明确地调用网页提供的能力。这有点像我们平时写前端时调用 API。只不过以前是前端页面 - 调用后端 API现在多了一种可能AI Agent - 调用网页暴露出来的能力注意这里不是说网页 UI 不重要了。UI 仍然重要因为人还要使用页面、确认结果、修改内容、决定是否执行关键操作。WebMCP 真正改变的是网页不再只是“给人看的界面”也可以变成“给 AI Agent 调用的工具”。它和普通网页有什么区别我们拿一个简单例子来看。假设你做了一个“公众号选题助手”。普通网页会这样设计一个输入框填写账号定位。一个下拉框选择目标读者。一个按钮生成选题。一个结果列表展示 20 个标题。一个保存按钮保存选中的题目。对人来说这已经足够了。但对 Agent 来说它看到的是一堆视觉元素。它需要先理解哪个输入框填什么。哪个按钮可以点击。点击后会发生什么。哪些结果可以保存。保存之后数据去了哪里。如果页面把这些能力结构化表达出来情况就不一样了。它可以告诉 Agent能力 1generateTopics 作用根据账号定位生成选题 参数 - accountPositioning账号定位 - audience目标读者 - topicDirection内容方向 返回 - topics选题列表能力 2saveTopic 作用保存一个选题到选题池 参数 - topicId选题 ID 返回 - saved是否保存成功这时候Agent 不需要猜“哪个按钮是生成”而是知道这个网页明确提供了generateTopics这个能力。这就是普通网页和 Agent-ready 网页的核心区别类型面向谁主要表达方式Agent 使用难度普通网页人按钮、表单、视觉布局高需要猜Agent-ready 网页人和 AgentUI 结构化能力低更明确为什么这件事和前端有关很多人听到 AI Agent第一反应是这不是后端和大模型的事情吗不完全是。WebMCP 这种方向恰恰和前端有很强关系。因为网页上哪些能力能被 Agent 调用往往不是模型决定的而是产品和前端一起设计出来的。前端开发者过去主要关注页面怎么排版。表单怎么校验。按钮什么时候禁用。请求失败怎么提示。数据怎么展示。以后可能还要多关注几件事页面有哪些动作可以暴露给 Agent。每个动作需要哪些参数。哪些动作执行前必须让用户确认。Agent 调用失败时页面应该怎么反馈。用户如何撤销 Agent 做过的操作。页面状态如何让 Agent 理解。这意味着前端的工作边界会变宽。以前我们设计的是用户如何操作页面以后还要设计Agent 如何理解页面能力 Agent 如何在用户授权下完成任务这不是简单加一个聊天框就能解决的。聊天框只是入口真正有价值的是后面的任务流、状态管理、权限确认和结果呈现。一个通俗类比菜单和后厨如果你觉得 WebMCP 还是抽象可以用餐厅来理解。普通网页像一家餐厅的大厅。人类用户进来之后可以看菜单、叫服务员、点菜、付款。AI Agent 如果只靠视觉去操作网页就像一个不熟悉餐厅的人只能到处看标识、猜哪个窗口能点菜、猜哪个按钮能付款。Agent-ready 网页则像餐厅提供了一份清晰的服务清单可以点菜需要菜名和数量 可以修改订单需要订单号和新内容 可以付款需要用户确认 可以查看进度需要订单号这样 Agent 不用乱猜而是知道每个服务能做什么、需要什么、结果是什么。WebMCP 要解决的就是类似这个问题。它不是让餐厅大厅消失而是让餐厅的服务能力更清楚。同理WebMCP 也不是让网页 UI 消失而是让网页能力更容易被 Agent 理解和调用。用 AI 选题助手举个完整例子现在我们用一个更贴近这个公众号的例子。假设我们正在做一个“AI 公众号选题助手”。它的目标用户是公众号作者。用户输入账号定位。目标读者。近期关注方向。希望生成多少个选题。系统输出选题标题。推荐理由。适合栏目。写作难度。是否适合做系列。普通网页版本可能是这样填写表单 - 点击生成 - 查看选题 - 手动保存 - 复制到文档这已经能用。但如果我们希望它对 AI Agent 也友好就要思考这个网页可以暴露哪些能力。比如generateTopics 根据账号定位生成选题。scoreTopic 评估一个选题是否值得写。saveTopic 把选题保存到选题池。createOutline 把一个选题扩展成文章大纲。exportDraft 把大纲导出为 Markdown 草稿。这样一来用户可以对 Agent 说帮我根据当前账号定位生成 20 个选题筛出最适合本周写的 3 个并为第一个选题生成文章大纲。Agent 就可以按顺序调用generateTopics - scoreTopic - createOutline但这里有一个重要问题不是所有动作都应该让 Agent 自动完成。比如生成选题可以自动执行评分也可以自动执行。但如果要发布文章、删除选题、批量覆盖历史内容就必须让用户确认。这就是前端要设计的边界。哪些能力适合暴露给 Agent不是页面上的所有功能都适合开放给 Agent。一个简单判断方法是低风险、可撤销、可重复的操作可以更容易暴露高风险、不可逆、涉及隐私和付款的操作必须谨慎。可以优先暴露的能力查询。搜索。生成草稿。评分。分类。总结。创建临时内容。导出非敏感内容。需要用户确认的能力发布。删除。付款。邀请成员。修改权限。发送消息。覆盖已有数据。访问敏感信息。不建议轻易暴露的能力读取大量隐私数据。绕过用户确认的支付。自动群发内容。执行不可撤销操作。修改安全配置。这也是为什么 WebMCP 不只是技术问题。它也是产品设计问题、安全问题和用户体验问题。前端开发者真正要补的能力如果 WebMCP 和 Agent-ready Website 变得越来越重要前端开发者要补的不是“再学一个框架”。更重要的是这些能力1. 任务建模能力你要能把页面功能拆成一个个明确动作。比如不要只看到一个按钮生成而要能拆出动作generateTopics 输入账号定位、目标读者、内容方向、数量 输出选题列表、推荐理由、评分 失败输入不足、生成超时、结果为空2. 状态设计能力Agent 调用能力时页面状态必须清楚。比如空状态。输入中。校验失败。生成中。生成成功。生成失败。等待用户确认。已撤销。如果状态混乱Agent 和用户都会困惑。3. 权限和确认设计能力Agent 能做什么不能做什么必须有边界。尤其是涉及发布、删除、付款、权限修改时不能只因为 Agent “理解了用户意图”就直接执行。更稳妥的流程是Agent 准备操作 - 页面展示操作摘要 - 用户确认 - 执行 - 返回结果4. 结构化输出能力AI 应用不能只返回一大段文本。如果结果后续还要被页面、Agent 或其他工具继续使用就应该尽量结构化。例如选题结果不要只返回这里有 10 个选题……而应该返回[{title:网站以后不只给人看还要给 AI Agent 用,column:AI 前端雷达,reason:WebMCP 是新兴方向适合建立差异化,difficulty:medium,seriesPotential:true}]5. 错误处理能力Agent 调用网页能力时一定会遇到失败。比如参数不完整。网络失败。用户没有权限。结果为空。操作需要确认。当前页面状态不允许执行。好的前端不是假设一切都会成功而是把失败设计清楚。WebMCP 不是万能解法讲到这里很容易让人觉得 WebMCP 会解决所有问题。但现实不是这样。WebMCP 更像一个趋势信号网页需要开始考虑 AI Agent 如何理解和使用它。但它不会自动解决所有问题。你仍然要处理用户授权。安全边界。隐私保护。操作确认。错误恢复。浏览器兼容。旧页面迁移。产品是否真的需要 Agent。尤其是最后一点很重要。不是所有网站都需要变成 Agent-ready。如果你的网站只是展示文章、展示作品集、展示品牌信息可能暂时没必要复杂化。但如果你的网站本身是一个工具用户要在里面完成任务比如写文章。管项目。查数据。做报表。处理工单。生成内容。管理知识库。那就值得提前关注。因为这些工具型网站天然适合被 Agent 协助操作。这对前端岗位意味着什么过去几年很多前端开发者都在问AI 会不会让前端变得不重要我更愿意换个角度看AI 会让一部分重复写页面的工作变少但也会让新的前端问题出现。比如Agent 如何理解页面能力。人和 Agent 如何共同完成任务。哪些操作应该自动哪些必须确认。AI 生成结果如何被编辑、保存、回滚。页面如何展示 Agent 的计划和执行过程。前端如何验证 Agent 真的完成了任务。这些问题不是单纯靠后端也不是单纯靠模型能解决的。它们发生在用户、页面、状态、权限、任务流之间。这正是前端开发者熟悉的位置。所以我不认为 AI 会让前端消失。更可能发生的是普通页面实现会变得更便宜但会设计 AI 任务界面的前端会更有价值。新手应该怎么开始关注如果你刚入门不建议一上来就研究所有协议细节。可以按这 4 步理解。第一步先理解“网页能力”打开你常用的一个工具网站问自己这个网站到底能帮用户完成哪些任务不要只看按钮要看动作。比如一个选题工具的能力可能是生成选题。评估选题。保存选题。生成大纲。导出草稿。第二步把动作写成输入和输出每个动作都问 3 个问题它需要什么输入 它会返回什么输出 失败时会发生什么这一步做完你已经比很多只会写 UI 的人更接近 Agent-ready 思维了。第三步区分自动执行和用户确认把动作分成三类可以自动执行 需要用户确认 不应该开放给 Agent这一步决定产品安全边界。第四步用一个小页面练习不要一上来改大项目。可以先做一个很小的页面输入账号定位 - 生成 5 个选题 - 选择 1 个 - 生成大纲然后思考哪些动作可以暴露给 Agent。哪些结果需要结构化。哪些失败要提示用户。哪些操作需要确认。这比单纯看文档更容易理解。一句话总结WebMCP 值得关注不是因为它又多了一个新名词。而是因为它指向了一个更大的变化网页正在从“给人操作的界面”变成“人和 AI Agent 都能使用的任务系统”。对前端开发者来说这意味着新的设计问题哪些能力应该暴露给 Agent哪些操作必须让用户确认页面状态应该如何被 Agent 理解错误、权限、撤销、审计应该怎么设计AI 生成的结果如何进入真实工作流这些问题不会被一个聊天框解决。也正因为如此AI 时代的前端机会可能不在于再做一个聊天 UI而在于重新设计网页和 Agent 协作的方式。如果以前的前端重点是让人更好地使用网页那么接下来一部分前端工作会变成让人和 AI Agent 一起更好地完成任务这就是 WebMCP 对前端最重要的启发。参考资料Chrome WebMCP 文档https://developer.chrome.com/docs/ai/webmcpChrome WebMCP 与 MCP 对比https://developer.chrome.com/docs/ai/webmcp/compare-mcpChrome AI 文档入口https://developer.chrome.com/docs/ai