WebMCP 之后，为什么还需要 WebSkill

过去，Agent 操作网页主要依赖截图识别、DOM 定位和模拟点击。它需要像人一样寻找按钮、填写表单，再根据页面变化判断操作是否成功。面对结构复杂、状态繁多的企业应用，这条链路往往缓慢且不稳定。

WebMCP 提供了另一种思路：由网页主动将自身能力注册为结构化 Tool，Agent 可以直接发现并调用这些能力，同时复用当前页面已有的业务状态和前端逻辑。

在当前的 WebMCP 规范草案中，网页可以通过 document.modelContext.registerTool() 注册带有名称、说明、输入 Schema 和执行函数的 Tool。WebMCP 由 W3C Web Machine Learning Community Group 发布，目前仍是一份 Draft Community Group Report，尚未成为正式的 W3C 标准。

但当页面已经可以主动向 Agent 暴露 Tool，一个新的问题很快出现：

有了可以调用的工具，Agent 就能完成真实业务任务了吗？

最近出现的 WebSkill 提案及其 Demo，正试图给出一种回答：在 WebMCP 之上增加一层浏览器侧的 Skill，将任务说明、工具绑定、参数收集和安全约束组织起来。该提案目前仍处于 Draft Proposal 阶段。

本文中的 WebSkill，特指这份浏览器原生提案；Web Skill 则泛指面向 Web 场景的 Skill。

假设一个电商运营平台已经通过 WebMCP 提供了几个 Tool：

它们分别负责查询商品、创建促销活动、设置折扣和提交审批。

运营人员向 Agent 提出的需求可能是：

找出近 30 天销量明显下滑、但库存仍然充足的商品，为它们创建一场限时促销，折扣低于八折时提交审批。

从工具层面看，完成这个需求所需的能力已经具备。但 Agent 真正开始执行以后，仍然要回答一系列问题：

这些问题很难归入某一个 Tool。

queryProducts 只需要描述查询参数和返回结果，submitApproval 只负责发起审批。至于这些工具应该怎样组合、以什么顺序执行、需要遵守哪些业务规则，已经超出了原子工具的职责。

这里需要区分三个概念：

“为当前这批商品创建一次促销活动”是一个具体 Task。

“商品促销活动创建”则可以沉淀为 Skill，其中包含商品筛选、活动配置、折扣计算、审批条件和异常处理等方法。

WebMCP 当前主要提供 Tool 层的能力。Web Skill 继续向上组织这些 Tool，让 Agent 掌握完成一类任务的方法。

一个真实任务从用户提出到最终执行，大致会经过下面这条链路：

沿着这条链路反向推导，一个有用的 Web Skill 至少需要回答四个问题：

Tool 提供动作，Skill 需要提供完成任务的方法。

在促销场景中，这些方法包括商品筛选标准、活动配置流程、折扣规则、审批条件和异常处理方式。它们可能分散在产品文档、运营规范、系统规则和有经验的运营人员脑中。

缺少任务知识时，Agent 即使拥有全部 Tool，仍然需要临场推测调用顺序、筛选条件和完成标准。

通用的 Agent Skills 规范 已经采用了类似的组织方式：使用 SKILL.md 描述任务方法，并按需加载脚本、参考资料和其他资源。Agent 首先读取 Skill 的名称和描述，只有在任务命中后才加载完整指令和相关文件。

Web Skill 需要在此基础上，进一步连接具体页面提供的状态和能力。

Web 应用始终处于变化之中。

同一个“修改促销活动”Skill，在不同环境下可能拥有不同的执行范围：

因此，Web Skill 需要感知当前站点、路由、业务对象、页面状态、用户权限和可用 Tool。

这一点构成了 Web Skill 与普通 Agent Skill 的重要差异：它不仅要掌握任务方法，还要判断这套方法此刻是否适用。

自然语言说明可以告诉 Agent 大致应该怎么做，稳定执行还需要更明确的工具关系：

例如，queryProducts 返回的商品列表要转换成 createPromotion 的活动商品范围；活动创建后返回的 ID，又要传递给折扣设置和审批操作。

工具契约把任务方法与实际执行连接起来，减少模型在运行过程中对关键关系的临场猜测。

Web 是用户正在参与的交互环境。Agent 可以承担大量操作，用户仍然需要保留对关键决定的控制。

在促销场景中：

因此，Web Skill 还需要明确哪些步骤可以自动完成、哪些参数需要补充、哪些结果需要预览，以及哪些操作必须确认。

生成式 UI 可以承载这些交互。具体 UI 形式可以变化，Skill 需要清楚定义 Agent 的自主范围。

WebSkill 希望在浏览器内连接上述能力。

在它设想的架构中：

WebSkill 使用声明式文档描述任务，并采用按需加载机制控制上下文；通过工具绑定限制 Skill 可以调用的 WebMCP Tool；通过参数 Schema 和生成式 UI 处理信息补充与敏感操作确认；同时尝试利用页面生命周期和 Origin 建立作用域与安全边界。

这些设计将原本分散的几部分放进了同一条执行链路：

Skill 由此开始与页面的状态、能力和生命周期发生联系。

这也是 WebSkill 相比通用 Agent Skill 最值得关注的变化。

WebSkill 并不是唯一一条探索路径。

在 WebMCP 仓库中，已经出现了关于 Skills Integration 的讨论。该提案希望让网站提供高于单个 Tool 的工作流上下文，将相关工具、业务知识和执行说明组织成 Skill。

它给出的电商案例很直观：网站已经注册了商品搜索、加入购物车和使用优惠码等 Tool，但 Agent 仍然不知道尺码规则、促销条件、退换货政策，以及搜索前应该向用户询问哪些信息。Tool 描述单个函数，无法独自承担完整工作流和领域知识。

这说明，从 Tool 走向 Skill 并非某一份提案的孤立判断。

通用 Agent Skills 为知识组织和渐进式加载提供了已有经验；WebMCP 解决页面如何暴露结构化 Tool；现在出现的多种 Web Skill 探索，则开始连接两者。

它们的 API 和运行位置可能不同，面对的核心问题却相对一致：

如何把一套可复用的任务方法，绑定到持续变化的 Web 环境中。

过去，页面主要面向用户组织信息和操作。

WebMCP 出现后，页面开始直接向 Agent 表达：

Web Skill 再向前一步，让页面有机会继续表达：

页面由此获得了一个新的角色：

页面可以成为 Agent 获取局部业务能力的入口。

这里的“局部”很重要。

一个页面无需承载整个企业的全部知识和工具，只需要提供与当前场景、业务对象和用户权限相关的能力。

用户进入商品运营页，Agent 获得商品筛选、库存分析和活动配置能力；进入审批页，则加载风险检查、审批规则和提交能力。

页面天然拥有这些局部上下文：

这也意味着，前端资产的建设目标可能继续发生变化。

过去，组件、页面和接口封装主要追求供开发者复用。面向 Agent 的 Web 应用，还需要让这些资产变得可理解、可调用、可组合和可约束。

组件可以表达语义和动作，页面提供业务上下文，Tool 暴露结构化能力，Skill 组织完成任务的方法。

定义单个 Web Skill 只是第一步。当页面、Tool 和 Skill 的数量不断增加，还需要一套系统性的治理能力。

首先是发现与路由。

Agent 如何结合当前页面、用户权限和任务目标筛选 Skill？功能相近的 Skill 如何避免冲突？网站、组织和用户分别提供的 Skill，又应该按照什么优先级使用？

其次是版本与兼容。

页面代码、Tool Schema 和 Skill 文档可能独立升级。Tool 已经变化、Skill 仍然引用旧版本时，任务链路很容易失效。

第三是权限与信任。

网站提供的 Skill 可以指导 Agent 使用页面能力，但不能覆盖 Agent 自身的安全规则和用户目标。WebMCP 社区的 Skills Integration 讨论也将 Skill 的可检查性、域作用域以及与 Agent 系统级约束的关系列为重要问题。

最后是质量验证。

一份 Skill 能被模型读取，并不代表它能稳定完成任务。真正进入生产环境后，还需要用真实任务样本验证：

WebMCP 规范本身已经将提示注入、Tool Poisoning、隐私泄露和同源边界等列为需要持续解决的安全与隐私问题。Skill 又增加了任务指导能力，其来源、权限范围和完整性同样需要治理。

Web Skill 最终能否成为稳定的工程能力，取决于完整的发现、版本、权限、审计和评估体系。

WebMCP 让网页开始主动向 Agent 暴露可执行能力。

WebSkill 则尝试在这些 Tool 之上，补充完成任务所需的方法、上下文和控制边界。

具体的 API、文件格式和浏览器实现还没有定型，但方向已经逐渐清晰：网页正在从等待 Agent 识别和操作的界面，转变为能够主动提供局部业务能力的环境。

这也是 WebSkill 在现阶段最值得关注的地方。