作者：Cara Mecozzi、Steve Kaliski。文中测试结果由 Stripe 报告，未经译者独立复现。
为了帮助使用 Stripe 的商家把握 AI Agent 快速增长带来的机会，我们在所有 Stripe Checkout 界面中启用了 WebMCP。与基线相比，token 消耗减少了 42%，工具调用次数减少了 38%。
许多企业，包括 Stripe，都已经搭建了 MCP 服务器，为 Agent 提供程序化接口。不过，使用浏览器仍然是 Agent 与现有服务交互的主要途径之一。传统网站主要面向人类使用者进行优化。要完成结账，Agent 必须理解视觉界面和文档对象模型（DOM），推断页面展示了哪些信息、允许执行哪些操作，再规划并执行这些操作。即使模型在不断进步，网页操作仍然缓慢、迂回，而且消耗大量 token。
我们优化人类的购物体验时，会尽量减少延迟和点击次数；优化 Agent 的购物体验时，也应尽量减少 token 用量和工具调用次数。这是衡量 Agent 效率的两个主要指标：token 反映成本，工具调用反映完成任务所需的操作量，而调用次数过多，也可能意味着 Agent 不知该如何继续。
WebMCP 是一项日益受到关注的新兴标准。我们认为，它很有希望改善 Agent 的结账体验。
这个问题已经不再是假设。Muse、Instinct 和 Grokbot 等 Agent 正在陆续推出并受到欢迎，它们通常配备虚拟机和浏览器。我们已经看到 Stripe 处理的 Agent 交易量在增长，并预计这一趋势会持续下去。
我们决定在 Stripe Checkout 的各类界面中引入对 Agent 友好的 WebMCP。Stripe Checkout 服务于超过 780 万家企业，处理的交易额约占全球 GDP 的 0.45%。我们希望让数百万商家无须更改现有集成，就能接待未来由 Agent 代为购物的消费者，同时提供快速、可靠的消费体验。
在未启用 WebMCP 的基线测试中，这些 Agent 使用 Stripe Checkout 完成一笔交易，平均消耗 180 万个 token、调用工具 38.83 次，耗时超过 2.5 分钟。即便在用户对延迟有一定预期的聊天应用中，这些数字也实在太高了。
本文介绍我们如何实现 WebMCP，以减少 token 消耗和工具调用次数。我们在两件事之间取得了平衡：一方面构建专门的接口来提升 Agent 的表现，另一方面让它与面向人类的界面保持一致，便于维护。
什么是 WebMCP？
WebMCP 是一种浏览器技术，允许网站从客户端向 Agent 暴露 MCP 工具。Agent 不必自行推断该怎样完成任务、怎样操作 DOM，而是可以直接执行 get_order_summary 或 fill_payment_form 等工具。它甚至不一定需要查看页面上的任何 HTML。
上图展示了一个 Stripe Checkout 页面。调用可用工具会使界面发生变化：select_payment_method 会动态更新界面，fill_payment_form 则会填入卡号等支付信息。我们认为，与把全部 HTML 放进 LLM 上下文，再通过元素的 ID 或类名推断按钮位置相比，这种方式会带来很大改善；它也避免了把操作流程硬编码后容易失效的问题。
实现 WebMCP
基线测试中，走到支付环节大约需要调用工具 39 次，每次调用都消耗 token 和时间。因此，我们重点设计能够大幅减少调用次数的工具。在最初的实现中，我们也倾向于不因使用者是人还是 Agent，就为页面背后的业务逻辑另建一套分支。
提供一组工具，可以消除视觉浏览器自动化中的部分歧义。但如果工具太多，Agent 仍然需要判断哪些操作有效。面对过多的工具、无关的参数或无效的操作，Agent 依旧可能难以完成任务。
设想一个结账页面：它支持多种支付方式，地址字段会动态渲染，只有提供了必填信息后，支付按钮才会启用。如果一次性向 Agent 提供所有可能的操作，它的上下文就会包含一些不相关、甚至根本无法使用的工具和参数。
工具描述中的说明可以提供帮助，但这仍然把本不必要的推理负担留给了 Agent：应用自己已经知道这些约束，何必再让 Agent 推断一遍？可以把这个过程想象成修剪树枝，逐步引导 Agent 走向目标结果。
只在可以执行时开放工具
Stripe 的 WebMCP 实现围绕「渐进式工具开放」展开：页面只暴露与当前状态相关的工具和参数。这既能让 Agent 的交互更可靠，也能让人和 Agent 的使用体验保持一致。具体来说，我们希望尽可能减少这样的情况：Agent 按顺序调用了若干可用工具，却最终遇到错误。
例如，在所有字段填完之前，我们不会开放 submit_payment 工具。一个简化的结账流程可能是这样的：
- Agent 查看结账会话和可用的支付方式。
- 选择支付方式后，页面开放表单填写工具，其参数结构与可见字段一致。
- Agent 使用该工具提供所需信息。
- 表单填写完整且通过校验后，页面才开放
submit_payment。
结账状态改变时，可用工具也会随之改变。例如，如果 Agent 将支付方式改为非银行卡支付，我们就会从 fill_payment_form 的参数集合中移除卡号。
这种方式不再预先列出所有可能的操作，而是减少工具调用、提高可靠性，让更多支付能够成功完成。
此外，我们大量复用了前端代码中已有的无障碍设计模式和优化，继续使用共同的基础设施，而不是为 Agent 单独实现另一套结账系统。WebMCP 工具把操作交给面向人类的结账界面所使用的同一套底层实现。我们持续优化人类用户的 Stripe Checkout 体验时，Agent 也能获得所有这些改进带来的好处。如今，人和 Agent 的体验已更加接近，我们也很想知道：优先为 Agent 做出的改进，又能怎样反过来改善人的使用体验？
避免另建一套业务逻辑
我们使用两类 WebMCP API，将工具连接到现有界面：命令式和声明式工具实现。现有界面已经具备处理完整支付流程所需的状态管理和表单。我们不想引入一个「仅供 Agent 使用」的分支，以免两套逻辑逐渐偏离，或给工程师增加维护负担。
通过命令式 API，我们引入了 get_order_summary 这类从现有状态中生成响应的工具，以及 select_payment_method 这类执行明确操作的工具。后者可以更改支付方式，触发现有的状态转换。
对于表单填写，我们使用声明式 API，从已经渲染的 HTML 中生成工具。浏览器可以根据当前可见的表单控件推导输入参数结构，而不需要我们手动维护另一份重复的表单结构定义。这意味着，开发者新增一个表单字段后，它默认就会出现在相应工具中。
使用 Browserbase 等浏览器自动化工具的 Agent，随后就能直接调用这些工具，获取结账信息并完成支付。
评估表现
为了评估 WebMCP 能否在不牺牲可靠性的前提下提高 Agent 的结账效率，我们衡量了结账完成情况、执行时间、工具调用次数和 token 消耗。
我们在一个虚构的户外用品零售网站上，使用 Stripe Checkout 的整页界面，针对六个模型运行了 60 次测试。其中一半使用 WebMCP，另一半使用基线浏览器交互方式。每次测试都要求 Agent 完成相同的端到端任务：访问网站、将商品加入购物车、进入结账流程并完成支付。
所有测试中，Agent 都成功完成了结账。不过，对比结果显示，使用 WebMCP 的 Agent 在三个方面都有显著改善。
使用 WebMCP 的 Agent，token 消耗减少了 42%，完成结账的耗时缩短了 39%，每次运行的工具调用次数减少了 38%。
我们统计的是 Agent 完成任务所消耗的总 token 数，包括输入、输出和缓存 token。Token 用量直接影响 Agent 交易的成本，因此减少 token 可以降低 Agent 大规模处理此类交易的开销。
我们还统计了 Agent 完成结账时执行的操作次数，包括点击、填写表单和调用工具。工具调用更少，意味着 Agent 走了一条更直接的结账路径，减少了试探性的表单交互。
最后，我们测量了从任务开始到结账完成的实际经过时间，涵盖 Agent 访问网址、选择商品、填写结账表单和提交支付的全过程。执行时间缩短后，客户等待 Agent 完成购买的时间减少了 60 秒。
下一步
浏览器与 Agent 的交互规范仍在演进，WebMCP 是其中的一步：界面可以同时服务人和 Agent，而不必为两者分别构建一套体验。随着人们越来越多地通过 Agent 使用互联网，工程师需要思考，如何同时向人类和机器用户传达希望它们执行的操作。
随着 WebMCP 和浏览器 Agent 的发展，我们会继续改进 Checkout 对 Agent 代购的支持，帮助商家服务选择不同购买方式的客户，无论客户是直接操作 Checkout，还是请 Agent 代为完成。
准备好为 Agent 代购构建应用了吗？从 Stripe Checkout 和 WebMCP 开始。
在为 AI Agent 构建产品这件事上，我们对可能性的认识还处于早期。Stripe 还有很多工作要做，涉及基础设施、开发者工具、产品系统和 AI。如果你愿意解决这类问题，我们正在招聘。