网络的新语言:Google 的 Web MCP 如何让每个网站都为智能体做好准备

多年来,网络是为人类的眼睛而构建的。点击这里,滚动那里,填写这个表单。每一个设计决策——颜色、布局、交互元素——都是为坐在屏幕前的人优化的。

但有些事情正在发生变化。智能体正在进入网络,而大多数网站还没有为它们做好准备。


问题:智能体在“盲目浏览”

想象一下,你拥有一个电商网站,并希望 AI 智能体能够使用它——搜索商品、添加到购物车、完成购买。在一个数百万智能体代表用户浏览网页并执行操作的未来,你的网站是否对这些智能体友好,可能决定你的业务成败。

今天,你有两个选择,但都不理想。

第一个是构建你自己的 MCP 服务器,并希望所有智能体都恰好安装了它。这几乎不可能发生。没有任何一个网站重要到可以被预加载进每个智能体的工具集中,成为永久组件。

第二个选择是依赖智能体的浏览器操作能力——让它截图、解析原始 HTML,然后自己判断该点击什么。这种方式正在变好,但从根本上说它是“非确定性的”。智能体需要在为人类设计的大量 HTML 代码中摸索:导航栏、广告位、Cookie 提示、动态内容。信息噪声大、速度慢,而且容易失败。智能体可能错过按钮、误读字段,或者直接放弃。

在 AI 智能体成为网页内容主要使用者的时代,一个难以被智能体导航的网站,终将被抛在后面。


解决方案:嵌入页面内部的 MCP

Google 的答案是 Web MCP —— 一种将 MCP 工具直接嵌入网站的方法,使得任何使用兼容浏览器的智能体在浏览页面时,都能自动发现当前页面可用的操作。

核心理念非常优雅。与其让智能体反向解析页面 HTML 来猜测能做什么,不如让页面主动告诉它。当智能体访问你的电商首页时,它会看到:search_productsget_categoriesapply_filters。当它进入商品详情页时,会看到:add_to_cartget_similar_products。不需要翻译层。不需要猜测。只有干净、结构化、确定性的操作——根据页面上下文逐页加载。

这正是 Web MCP 真正令人兴奋的关键点:工具不会预加载到智能体的全局上下文中,而是在智能体浏览时“当场发现”。正确的工具出现在正确的页面,当不再相关时自动消失。


两种构建方式

Web MCP 支持两种实现方式,取决于你的网站构建方式。

声明式:适用于静态 HTML

对于简单的静态页面,方法非常直接。你只需要在现有的表单元素上添加一些 HTML 属性——tool-nametool-description,以及每个输入字段的 tool-param-description。仅此而已。

当使用支持 Web MCP 的浏览器的智能体访问页面时,它会自动看到一个完整的 MCP 工具,包括名称、描述和输入结构——全部来自你添加的属性。不需要服务器,不需要 API,不需要额外基础设施。

你甚至可以监听智能体的操作。当智能体填写表单时,会触发一个特殊的 agent.invoked 事件,你可以返回结构化反馈——确认成功、返回错误,或者触发自定义 UI 元素,例如在提交前显示“请确认”的提示框。智能体获得标准的工具响应;人类用户也可以在最终提交前进行确认。

命令式:适用于动态应用

对于 React 或 Next.js 应用,命令式方式提供完全的编程控制。新版 Chrome 浏览器暴露了两个新的 navigator 函数——navigator.registerToolnavigator.unregisterTool,允许你将 MCP 工具绑定到特定组件。

模式很清晰:定义工具结构(名称、描述、输入结构、输出结构、处理函数),在组件挂载时注册工具,在组件卸载时取消注册。结果是一个实时、具备上下文感知能力的工具注册表,会随着用户或智能体的导航自动更新。

在一个演示的看板应用中,效果立刻显现。让智能体“为三个人准备晚餐制定所有任务计划,并将每一列作为一个类别”,它会实时创建列并填充卡片,自主完成,零错误。每个操作都通过类型化的 MCP 工具调用完成。没有猜测。没有幻觉。


一种新的上下文智能模式

Web MCP 不只是浏览器功能。它代表了一种新的架构模式,介于两种各有明显限制的方法之间。

传统 MCP 功能强大,但成本高:所有工具结构一开始就加载到智能体的上下文窗口中,无论是否需要。对于拥有数十个工具的智能体来说,这种开销非常大。

“技能”方法更轻量——初始只加载标题和描述,需要时再获取完整细节——但它牺牲了 MCP 在工具调用中提供的严格类型安全性。

Web MCP 在两者之间找到了平衡。工具根据上下文加载,由智能体所在位置触发,而不是预先配置。智能体在需要时拥有完整的结构保证,不需要时则不占用上下文成本。

这种“上下文驱动”的 MCP 模式——在正确时刻呈现正确工具,由任务和上下文驱动而非静态配置——很可能是更广泛智能体生态系统的发展方向。


开始使用

今天想要试验 Web MCP,你需要:

  1. Chrome Beta(需要最新版本)
  2. chrome://flags 中启用 Web MCP flag
  3. 安装 Model Context Protocol Tool Inspector Chrome 扩展

之后,无论是为静态页面添加声明式 HTML 属性,还是在动态应用中调用 navigator.registerTool,都可以轻松设置并在本地测试。

网络最初是为人类而建。Web MCP 正在开始让它也能被智能体理解。

Read more

【PHP】如何将ThinkPHP 5部署到windows服务器的IIS里,和PHP版本又是一个怎么样的关系,三分钟教程搞定部署

【PHP】如何将ThinkPHP 5部署到windows服务器的IIS里,和PHP版本又是一个怎么样的关系,三分钟教程搞定部署

🌹欢迎来到《小5讲堂》🌹 🌹这是《PHP》系列文章,每篇文章将以博主理解的角度展开讲解。🌹 🌹温馨提示:博主能力有限,理解水平有限,若有不对之处望指正!🌹 目录 * 前言 * 代码分析 * 数据库 * php版本 * ThinkPHP * 版本兼容 * PHP安装 * 下载地址 * PHP CGI * 解压 * 配置 * 设置路径 * 设置扩展 * 其他设置 * PHP部署 * 添加角色 * 处理程序映射 * 增加默认文件 * PHP运行 * 常见报错 * 绿色版本 * 文件结构 * 一键启动 * 停止服务 * 卸载服务 * 测试链接 * 设置账号 * 文章推荐 前言 博主今天抽空帮朋友部署一个PHP网站,平时接触php的机会很少,之前也写过一篇文章 介绍如果在IIS在部署PHP。 博主通过会看那篇文章发现,后续的版本有点不一样了,所以,再次写篇文章记录下。 代码分析

Flutter 组件 censor_it 适配鸿蒙 HarmonyOS 实战:离线内容净化墙,构建端侧敏感词过滤与合规性治理架构

Flutter 组件 censor_it 适配鸿蒙 HarmonyOS 实战:离线内容净化墙,构建端侧敏感词过滤与合规性治理架构

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 组件 censor_it 适配鸿蒙 HarmonyOS 实战:离线内容净化墙,构建端侧敏感词过滤与合规性治理架构 前言 在鸿蒙(OpenHarmony)生态迈向内容社交、即时通讯及 UGC(用户生成内容)全场景覆盖的背景下,如何确保信息的合规性、在端侧拦截违规内容,已成为提升应用生态安全性与用户粘性的“风控红线”。在鸿蒙设备这类强调分布式隐私与绿色上网环境的终端上,如果内容过滤完全依赖云端接口,不仅会由于由于网络往返导致明显的交互滞后,更会由于由于频繁的 API 调用增加额外的运营成本。 我们需要一种能够在端侧执行高速扫描、支持动态字典更新且具备算法透明性的字符过滤引擎。 censor_it 为 Flutter 开发者引入了轻量级的敏感词过滤方案。它通过高效的字符串匹配算法,自动将预设的敏感源转化为可定制的和谐占位符。在适配到鸿蒙 HarmonyOS 流程中,这一组件能够作为鸿蒙应用内容发布的“安检门”,通过在前置环节对文本执行离线脱敏处理

OpenClaw.ai:Agentic AI 时代的“SpringFramework”时刻

—— 关于下一代智能体基础设施架构、生态演进与企业级可行性的系统性研究报告 第一章 历史的镜像:从软件危机到 Agentic AI 的基础设施真空 1.1 J2EE 的黄昏与 Spring 的黎明:关于复杂性的辩证法 要理解“Spring Framework 时刻”的深刻含义,我们必须将目光投向 21 世纪初的 Java 企业级开发领域。彼时,J2EE(Java 2 Platform, Enterprise Edition)虽然承诺了分布式计算的宏大愿景,但其实现方式——特别是 EJB(Enterprise JavaBeans)——却陷入了过度设计的泥潭。开发者被迫编写大量的 XML 配置文件,继承复杂的接口,不仅难以进行单元测试,且组件之间的耦合度极高。这种“重量级”框架导致的开发效率低下,被称为“J2EE

Flutter for OpenHarmony:Flutter 三方库 postgrest — 鸿蒙端直接访问 PostgreSQL 数据库的极速连接器

Flutter for OpenHarmony:Flutter 三方库 postgrest — 鸿蒙端直接访问 PostgreSQL 数据库的极速连接器

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net 前言 在开发 Flutter for OpenHarmony 应用时,传统的“端-接口-数据库”模式往往显得过于沉重。 如果只是为了实现基础的增删改查,却需要编写大量的后端 API 逻辑、处理复杂的 SQL 拼写以及繁琐的 JSON 打包,这不仅增加了开发成本,也导致系统在面对业务变动时极其脆弱。 postgrest 正是解决这一痛点的利器。它是专门为 PostgREST(一个能将 PostgreSQL 数据库直接转换为 RESTful API 的高性能网关)打造的 Dart 客户端驱动。通过它,开发者可以在鸿蒙端以类似于编写 SQL 的语义,直接完成对云端数据库的高级检索与操作。 今天,我们将深入探讨如何利用该库在鸿蒙平台上实现“零接口开发”的数据交互体验。 一、原理解析 / 概念介绍