教程
WebMCP 实战：让网站从“给人点”变成“给 Agent 调”
WebMCP 正在把“Agent 操作网页”从视觉自动化升级成结构化调用。这个实验性开放标准允许网站主动暴露 Tool，让 Agent 知道“查询订单”“增加购物车商品”“切换页面状态”到底需要什么参数和返回什么结果，而不是继续依赖截图识别、DOM 猜测和模拟点击。Chrome 已提供 Imperative API 和 Declarative API，Chrome 149 进入 Origin Trial；OpenAI 在 8 月 25 日启动 10 天 WebMCP Challenge，ChatGPT 的 in-app browser 可以直接测试 WebMCP 网站。对于电商、SaaS、内部 Portal 和内容网站来说，WebMCP 代表一个新问题：未来网页除了 SEO 和 Human UX，还需要设计 Agent UX。
# WebMCP 实战：让网站从“给人点”变成“给 Agent 调”
## 文章摘要
WebMCP 正在把“Agent 操作网页”从视觉自动化升级成结构化调用。这个实验性开放标准允许网站主动暴露 Tool，让 Agent 知道“查询订单”“增加购物车商品”“切换页面状态”到底需要什么参数和返回什么结果，而不是继续依赖截图识别、DOM 猜测和模拟点击。Chrome 已提供 Imperative API 和 Declarative API，Chrome 149 进入 Origin Trial；OpenAI 在 8 月 25 日启动 10 天 WebMCP Challenge，ChatGPT 的 in-app browser 可以直接测试 WebMCP 网站。对于电商、SaaS、内部 Portal 和内容网站来说，WebMCP 代表一个新问题：未来网页除了 SEO 和 Human UX，还需要设计 Agent UX。
---
今天很多 Browser Agent 操作网页的方式仍然像机器人模仿人类。
例如：
```text
截图
↓
识别按钮
↓
点击
↓
等待
↓
找输入框
↓
填写
↓
点击提交
```
这种方式最大的问题是：
> Agent 在猜 UI。
页面改一个按钮文案，自动化可能就崩。
A/B Test 改 DOM，也可能崩。
WebMCP 提出的是另一条路线：
> 网站直接告诉 Agent，它能做什么。
## 一、WebMCP 是什么？
WebMCP 是一个实验性 Web Standard Proposal。
网页可以暴露结构化工具：
```text
get_order_status
add_to_cart
search_products
create_draft
update_profile
```
每个工具有 Name、Description、Input Schema 和 Execute Function。
Agent 不再需要猜哪个按钮代表“查询订单”。
## 二、为什么这比 DOM 自动化可靠？
传统 Browser Automation：
```text
DOM
↓
Selector
↓
Click
```
WebMCP：
```text
Semantic Tool
↓
Structured Arguments
↓
Function
```
区别在于机器使用的是业务语义，而不是视觉结构。
前端可以重新设计，只要 Tool Contract 不变，Agent 仍然可以工作。
## 三、WebMCP 会替代 API 吗？
不会。
API 仍然适合 Server-to-Server、批处理和后台集成。
WebMCP 更特殊的地方是：
> Agent 和用户共享同一个网页、登录态和当前上下文。
例如用户已经登录电商网站，Agent 可以基于当前页面帮助处理任务，而不需要另外申请一套开发者 API Key。
## 四、两种 API
Chrome 当前提供两种思路。
### Declarative API
通过 HTML Form Annotation 暴露 Tool。
适合表单、搜索和简单提交。
### Imperative API
使用 JavaScript 的 `document.modelContext` 注册复杂工具。
适合状态管理、API 调用、页面导航和业务逻辑。
## 五、一个最小工具长什么样？
Chrome 当前文档的核心写法是：
```javascript
await document.modelContext.registerTool({
name: "get_order_status",
description: "Search orders in a timeframe",
inputSchema: {
type: "object",
properties: {
timeframe: {
type: "string",
enum: ["today", "yesterday", "last_7_days"]
}
},
required: ["timeframe"]
},
execute: async ({ timeframe }) => {
return await fetchOrderStatus(timeframe);
}
});
```
Agent 能看到 Tool Name、Tool Description 和参数 Schema，然后用结构化参数调用。
## 六、为什么必须写好 Description？
Agent 会根据 Tool Name、Description 和 Schema 判断什么时候调用。
所以 `action1 / do something` 几乎等于没设计。
更好的描述应该明确它返回什么，以及它不能做什么。
这和 MCP Tool Design 非常相似。
## 七、Tool Schema 应该尽可能限制参数
不要只给一个宽泛的 query string 再让后端自己猜。
尽量使用 enum、required 等约束。
参数越明确，Agent 越少产生奇怪调用。
## 八、读取工具和写入工具一定要区分
`get_order_status` 是 Read。
`cancel_order` 是 Write。
Write Tool 必须更谨慎，至少应该有：
- 用户确认；
- 权限校验；
- CSRF / Session 验证；
- Idempotency；
- Audit。
不能因为 Agent 从网页调用，就绕过原有业务安全。
## 九、WebMCP 不应该直接信任 Agent 参数
Agent 发出某个 order_id 后，后端仍然必须验证当前用户是否拥有该订单、当前状态是否允许、是否需要二次确认。
WebMCP 只是新的交互入口，不是新的授权系统。
## 十、同源限制为什么重要？
Chrome 当前默认 `getTools()` 只返回调用文档及同源 Frame 注册的 Tool。
Cross-Origin Tool 默认不可见。
如果需要跨域：
1. Hosting Origin 必须显式暴露；
2. Consumer 必须显式声明 `fromOrigins`；
3. 只能使用 Secure Origin。
这体现了一个合理原则：Tool 不应该因为被嵌进 iframe 就自动暴露。
## 十一、Cross-Origin iframe 还需要 Permissions Policy
例如：
```html
```
同时 Tool Registration 还要配置 `exposedTo`。
也就是双方都同意。
## 十二、Agent 怎样发现 Tool？
网页可以调用：
```javascript
const tools = await document.modelContext.getTools();
```
也可以通过 `document.modelContext.executeTool(...)` 手动执行。
对于 Browser Agent 来说，浏览器本身会负责发现这些结构化能力。
## 十三、WebMCP 为什么和 MCP 不一样？
名字很像，但作用层不同。
### MCP
```text
Agent Client
↓
Remote / Local MCP Server
```
### WebMCP
```text
Browser Agent
↓
Current Web Page
```
可以理解成：
```text
MCP = Tool Server Protocol
WebMCP = Web Page Tool Interface
```
两者可能共同存在。
## 十四、WebMCP 最适合哪些场景？
### 电商
```text
search_products
compare_products
add_to_cart
check_order
```
### SaaS
```text
create_project
assign_task
generate_report
```
### 旅游
```text
search_room
select_date
build_itinerary
```
### 数据工具
```text
filter_dataset
run_query
create_chart
```
### 内容系统
```text
search_article
create_draft
add_comment
```
## 十五、不适合把什么直接暴露？
- 管理员后台高风险动作；
- 未经确认的支付；
- 大规模数据导出；
- 任意 SQL；
- 任意 Shell。
WebMCP 不应该成为 Browser Agent 的 Root 权限接口。
## 十六、网站需要开始考虑 Agent UX
过去网站只设计 Human UX：页面、按钮、文案、表单。
未来可能增加 Agent UX：Tool Name、Description、Schema、Error、Confirmation 和 Permission。
一个对人很好理解的按钮，例如“再买一次”，对 Agent 则更适合变成明确的 `repeat_previous_order` Tool。
## 十七、Agent SEO 可能变成 Agent Capability
SEO 的目标是搜索引擎看得懂。
WebMCP 的目标是 Agent 能做事。
未来网站竞争可能不只是“Agent 能不能读我的站”，还包括“Agent 能不能在我的站上完成用户任务”。
## 十八、OpenAI 为什么现在办 WebMCP Challenge？
OpenAI 在 8 月 25 日开启了一个 10 天 WebMCP Challenge。
参与者可以新建 WebMCP App，或给已有网站增加 WebMCP。
官方给出的例子包括 3D Modeling、Collaborative Writing、Crossword、Travel Planning 和 Data Exploration。
这说明 WebMCP 的目标不是做一个隐藏 API，而是让人和 Agent 一起使用同一个交互应用。
## 十九、怎么测试？
OpenAI 表示 ChatGPT in-app browser 已支持 WebMCP 测试。
Chrome 则可以使用实验 Flag 或加入 Origin Trial。
Chrome 文档目前说明从 Chrome 149 开始进入 Origin Trial。
因此当前正确状态仍然是：
> 实验性 / 早期。
不要写成所有浏览器已经原生支持 WebMCP。
## 二十、现有网站应该怎么开始？
推荐不要一开始暴露几十个 Tool。
先选 3 个高价值动作，而且先全部 Read-only。
例如电商可以从 `search_products`、`get_product_detail`、`check_order_status` 开始。
验证 Agent 调用正确率、参数错误、用户完成率、延迟和安全事件，再逐步增加 Write。
## 二十一、上线前检查
### Tool Contract
名称和描述是否明确？
### Schema
参数是否足够约束？
### Authorization
是否复用当前登录用户权限？
### Confirmation
高风险 Write 是否要求确认？
### Idempotency
重复调用会不会执行两次？
### Error
Agent 能否理解失败原因？
### Audit
有没有记录 Tool Call？
## 最终判断
WebMCP 真正重要的地方在于：
> 它承认 Agent 已经成为网站的新用户类型。
过去 Agent 只能看页面、猜 UI、模拟人点击。
未来网站可以暴露语义 Tool，让 Agent 结构化调用，并与人共用同一产品。
这不是传统 API 的简单替代。
它更像是在网页 UI 之上再增加一层 Machine-usable Interaction Layer。
现在仍然是早期实验阶段。
但如果 Browser Agent 继续快速增长，网站是否 Agent-ready 可能会像今天的 Mobile-friendly、SEO-friendly 和 Accessible 一样，逐渐成为产品基础要求。
想继续了解 WebMCP、Browser Agent、MCP 和 Agentic Web，可以访问 **智元选**：https://www.zyentorpicks.com/。