WebMCP 二期：付完款之后，只问卡在哪

在上一篇文章中，我们探讨了如何利用 WebMCP 将商城的商品浏览与下单能力封装为当前浏览器标签页的原生工具。文章发布后，本站进一步落地了 Chrome Origin Trial 的首屏下发机制，并在收银台、个人账户与订单详情等核心页面，补齐了三枚只读状态工具。

工具清单虽然扩充了，但在整个二期设计中，真正让我们理清架构思路的并不是“多接几枚工具”，而是对页内 Agent 交互边界的重新审视：页内工具应当仅作为当前页面状态的只读投影，资金流动与敏感凭据的交付，必须始终保留在用户的直接掌控之下。

本文记录的是爱买 AI 的工程实践与建议，并非 Chrome 官方教程。底层行为与标准草案以 Chrome WebMCP 为准，核验日期为 2026-09-12（覆盖 Chrome Origin Trial 149 至 156 周期）。

付完款之后，用户真正需要的是状态确认

在第一期实现商品页的 create_order 之后，很多开发者的第一直觉往往是把流程全盘自动化：既然 Agent 能帮用户发起订单，那付款之后，是不是顺理成章应该再加一个 copy_delivery 工具把卡密提取出来，或者让 Agent 代替用户去 /order-query 页面填写查询密码查单？

我们很快意识到，这种所谓的“完整闭环”其实是一个危险的技术陷阱。将卡密、激活码或兑换凭据以纯文本格式经由工具返回值输出给大语言模型，本质上是在大模型的对话上下文中留下了一份未受保护的敏感数据副本。

站在买家的视角，当他扫码或转账完成之后，真正令他焦虑并需要即时解答的问题其实只有两个：

1. 钱到底付成功了没有？
2. 拿到的卡密究竟显示在哪里？

因此，第二期工具链只提供纯粹的只读状态查询，而不做任何凭据代提：

• 收银台页面：get_checkout_order
• 个人账户页：list_my_orders
• 订单详情页：get_order

这三枚工具返回的快照对象中，均会携带一条根据当前状态推导出的结构化「下一步」引导。例如告知用户“支付已确认，发货信息在本页，请自行复制”，引导用户亲眼确认并自行复制卡密。至于通用的公开查单页（/order-query）、网站首页以及商品详情页，则坚决不挂载此类订单状态工具。

这种边界划分并非业务层的凭空设定，浏览器底层的安全机制也在贯彻同样的逻辑。以文章页的 copy_rule_block 工具为例：在现代浏览器的安全策略下，向操作系统剪贴板写入数据必须依赖真实的用户交互手势（例如由物理点击触发）。如果开发者试图直接在 Chrome DevTools 的 Application → WebMCP 面板中手工调用 copy_rule_block 的 Execute 按钮，由于脱离了宿主页面的真实手势上下文，工具会明确返回：复制 lib/webmcp.js 失败，请在页面上点击「复制规则」。这一提示并非程序执行故障，而恰恰印证了底层安全防线：没有用户的主动点击，任何脚本或 Agent 都不应暗中篡改剪贴板。

工具是当前页状态的投影，而非另一套开放 API

与常规的后端 REST API 或桌面环境下的 MCP Server 截然不同，WebMCP 状态工具不接受任意外部传入的 orderId 去跨页面检索数据库。

Agent 若要获知某笔订单的进展，前提必须是伴随用户导航至对应的 URL；工具的 execute 函数仅负责读取当前页面已经加载并渲染到前端的状态（State / Ref）。此时，用户当前所注视的浏览器标签页构成了天然的授权边界：用户在屏幕上看到了什么，Agent 才能获知什么。对话上下文中绝不会凭空冒出用户未曾亲见的数据字段。

export function 列出我的订单(订单列表, status, 选项 = {}) {
  const 页错误 = 账户页错误(选项)
  if (页错误) return 页错误
  const 筛选 = 筛选账户订单(订单列表, status)
  if (筛选?.错误) return 筛选
  return { 订单: 筛选.map((订单) => 订单状态快照(订单, { ...选项, surface: 'account' })) }
}

// 选项.未登录 → { 错误: '请先登录后再查看订单。' }
// execute 仅读取页面已加载好的订单列表，严禁在工具内发起新的 orders 查询。

上面的代码展示了本站 list_my_orders 的核心实现思路。工具首先校验当前页面的认证与加载状态；当用户正常登录且数据就绪后，仅对页面当前已呈现的订单数组执行筛选与格式化转换。

与此同时，这种“状态投影”必须具备完整的生命周期鲁棒性。无论页面处于全屏骨架屏加载中、认证失效态，还是因订单超时失效而呈现的错误视图，页面都应当保持对应工具的挂载注册，而不是在异常时悄然将工具卸载注销：

• 个人账户页在骨架加载或未登录时，持续暴露 list_my_orders；
• 收银台在加载、订单失效、无权访问或游客支付完成展示页时，始终挂载 get_checkout_order；
• 订单详情页在对应异常态下，始终暴露 get_order。

如果在加载或异常分支中移除了工具，Agent 就会误判当前页面完全不支持 WebMCP，进而退化为不可控的行为模式。

为什么未登录状态下仍要挂载 list_my_orders？

初看之下，一个直觉的疑问是：既然用户尚未登录，账户页无法获取任何有效订单，为什么不直接隐藏该工具，等用户登录后再注册？

实践表明，这并不是一个疏漏，而是保障 Agent 行为可预测的关键设计。如果未登录时工具列表完全为空，Agent 面临无工具可用的境地，大语言模型往往会启动降级机制，尝试利用浏览器自动化手段强行扒取（Scrape）页面的 DOM 节点，从而带来难以预测的误读甚至误点击。

相反，在未登录状态下依然显式注册该工具，当 Agent 尝试调用时，工具会立即返回标准的错误对象结构：{ 错误: '请先登录后再查看订单。' }。工具不会代为弹窗，也不会越权代填表单，但清晰的错误语义能让 Agent 准确理解当前障碍，并自然地引导用户完成身份认证。

| 场景维度 | 未登录访问 /account | 登录后访问 /account | |---|---|---| | 工具是否注册呈现 | 是（保持注册） | 是（保持注册） | | 工具执行返回值 | { 错误: '请先登录后再查看订单。' } | 当前页面已加载的订单快照列表 | | 是否自动触发登录弹窗 | 否（保持页面纯净） | — |

这也引申出只读工具与副作用工具的重要权衡：对于标注了 readOnlyHint: true 的三枚订单状态工具，在任何安全会话中均可放手让 Agent 调用；而对于具备业务副作用的 create_order，虽然我们通过 consequentialHint: true 告知浏览器在执行前必须提示用户确认，但这仅是一层交互层面的提示，而非业务开关。在已有登录态的生产会话中，一旦确认调用即会真实触发锁库存并产生待付款单。因此，验证业务时必须严格区分只读窥探与实际写操作的边界。

厘清调用方：页内 Agent 与 IDE Coding Agent 的本质区别

在讨论 WebMCP 时，许多开发者容易将它与 Cursor 等 IDE Harness 内置的 MCP 机制混为一谈。

必须明确：页内 WebMCP Agent 并不是在 IDE 里辅助编码的 Coding Agent。截至 2026-09-11 的一手核验结果：

• 已实测支持调用的环境：ChatGPT 桌面版内置浏览器的 Site tools（适用于 Work / Codex 工作区下的 GPT-5.6 Sol 或 Terra 模型；Luna、Enterprise 及 Edu 许可除外）；以及 Chrome 官方提供的 Model Context Tool Inspector 调试扩展（默认对接 gemini-3-flash-preview）。
• 尚未验证支持的环境：Gemini in Chrome、Dia 浏览器、Claude for Chrome 以及各类 IDE 的侧栏聊天窗口。如果将 IDE（如 Cursor）宣称为页内工具的直接调用方，用户在实际操作中必然会产生“工具无法调通”的困惑。Cursor 依赖的是操作本地工程与远端服务的标准 MCP Server，它无法也不应该读取用户在 aimaiai.cc 浏览器标签中的用户凭证。

此外，不同宿主对工具的发现机制也是各自独立的：

• Chrome 原生环境依赖标准协议。站方通过 HTTP 响应头 Origin-Trial 以及 HTML 内的 <meta http-equiv="origin-trial" /> 下发 NEXT_PUBLIC_WEBMCP_ORIGIN_TRIAL_TOKEN，使得 Chrome 149–156 客户端无需手动开启调试 flag 即可激活 document.modelContext。
• 而 ChatGPT 桌面版内置浏览器使用的是其自研的 WebMCP 接入通道，它根本不需要、也不会读取站方的 Chrome Origin Trial 令牌。

在开发调试阶段，开发者无需猜测工具是否生效。直接打开 Chrome 开发者工具的 Application → WebMCP 专属面板，即可完整查看当前页面已注册的工具清单、输入参数架构（JSON Schema）与执行日志。

页面表现优于数据库原始字段

在设计工具输出的数据契约时，另一个常见的工程误区是直接将数据库中的 orders 行记录原始字段（如 orders.status）全盘暴露。

在真实的电商业务中，前后端状态的流转往往存在异步间隙。例如：用户完成链上 USDT 转账或扫码支付后，Webhook 确认正在排队，数据库中的行状态依然是 pending，但前端页面依据即时握手状态已经向用户展示为“已付款、正在确认”。

WebMCP 工具服务的是正在与用户并肩注视屏幕的 Agent。如果此时工具简单粗暴地将底层数据库的 pending 抛给模型，Agent 就会对用户说“您尚未付款”，从而与用户眼前清晰展示的“已支付”发生严重的同屏冲突，彻底摧毁用户信任。

因此，工具返回的字段文案必须与当前页面呈现的文本严格保持同频：

1. 订单展示状态与支付状态必须复用前端页面已有的展示字典，而不是暴露生硬的数据库枚举；
2. 「下一步」决策树必须严格按照风险梯度从高到低执行第一命中策略（退款处理中 → 超时已失效 → 人工/链上核对中 → 正常待付款），绝不能因底层存在待付标识就提前误判；
3. 对于加密货币等支付方式，必须结合完整的支付渠道族系（例如本站中 OKX 与标准 USDT 遵循相同的链上核对流水）进行综合研判，严禁依赖粗糙的名称正则（如 /usdt/i）进行臆断。

这种对语义严谨性的要求同样体现在安全防护层面。在对工具返回值进行防泄漏自动化扫描时，下一步 字段中通常包含“不会返回卡密”这一提示句——它是一句面向模型的否定式安全边界说明，返回结构中既没有名为 卡密 的字段，更不包含任何真实密钥正文。如果在编写安全断言测试时将宽泛的“卡密”字样粗暴地加入敏感模式黑名单，就会发生将防护提示误判为数据泄漏的假阳性。安全扫描必须检查具体的值与数据特征，而不是把正常的安全提示话题当成漏洞。

不要交给工具的事

正如我们在上一期文章中所强调的那样，第二期扩展依然坚持克制的设计边界：

• 严禁让工具代为发起转账支付、伪造已付凭据，或代填游客订单表单；
• 严禁将卡密明文、账号密码、查询凭据或商家收款信息置于工具返回值中；
• 严禁提供跨页面的任意订单探测接口，也不将 WebMCP 视为替代全站 API 的唯一通道。

将页内工具收敛为透明、确定且仅反映当前页现实的辅助投影，让 Agent 专注解读页面状态，而将资金授权与核心凭据始终交由用户亲手确认，正是构建安全可靠的 WebMCP 应用的核心哲学。

参考资料

• 用 WebMCP 把商城和下单做成当前页工具，爱买 AI 实践一期，核验日期 2026-09-11。
• WebMCP，Chrome for Developers，核验日期 2026-09-12。
• Imperative API，含 registerTool、annotations 与 AbortSignal 规范，核验日期 2026-09-12。
• Debug WebMCP tools，Chrome DevTools Application → WebMCP 面板指南，核验日期 2026-09-12。
• WebMCP Explainer，W3C WebML Community Group 标准草案，核验日期 2026-09-12。