我如何判断我的商店是否已支持代理结账？

这两个请求

它们都不需要密钥、沙盒或合作伙伴协议，并且都可以安全地在你的生产店面上运行——它们读取一个发现文档并列出功能。没有创建任何东西，也没有下任何订单。

在客户实际输入的域名上运行它们。这个细节比听起来更重要：你的客户域名上的无头前端可能不会代理你的商务后端提供的路径，因此检查后端主机可能会告诉你与代理访问你的品牌域名时所发现的相反的信息。

• GET https://yourdomain.com/.well-known/ucp — 一个JSON配置文件意味着发现功能已上线。
• 向该配置文件命名的MCP端点发送一个 JSON-RPC tools/list 请求 — 响应会列出代理可以调用的商务工具。
• 读取两者的 content-type。返回 text/html 的 200 响应是你的包罗万象页面，而不是文档。

诚实地解读结果

成功的发现响应并不能证明代理可以从你这里购买。在我们测试的每个商店中，列出工具是开放的，但调用它们需要调用代理提供其可解析的身份——因此，匿名脚本会遭到拒绝，即使真正的代理不会。

404 也同样不能证明不存在。它告诉你今天在该主机上的该路径没有提供任何内容。我们检查的几家商店与那70家回应的商店运行相同的商务平台，但仍然返回404，这表明问题出在前端而不是平台。

这项检查确实解决了值得解决的问题：你的公司里是否在没有人决定它应该存在的情况下，这个界面就已经存在了。

如果答案是肯定的，该怎么办

将其视为一个未经发布就已上线的实时渠道。其背后的运营假设与任何其他销售渠道的假设相同，但这些假设都没有针对此渠道进行过审查。

第一周值得提出的问题并不光鲜亮丽，并且都可以在内部得到解答。

• 库存是否足够准确，以便一台在提交前不会重新检查的机器进行报价？
• 哪些支付方式已注册，有没有人考虑到代理而选择了它们？
• 谁来处理一个没有人浏览过的订单的退款或支持请求？
• 你的分析系统是否能区分这些订单，还是它们未经标记地落入现有类别中？

/llms.txt 文件没有告诉你什么

从 llms.txt 审计这一点很诱人，因为它是大家都在谈论的文件。它是一个糟糕的代理。在回应发现请求的70家商店中，有12家发布了从未提及端点的 llms.txt 文件，其中7家根本没有提供 llms.txt 文件。

因此，一家商店可以完全支持代理交易，并且在 llms.txt 审计中得分为零。直接检查发现路径。