给AI Agent一个货架：MCP+x402让代理自主购物

一位开发者做了一次真实实验：让AI Agent拥有一个可浏览、可询价、可表达购买意图的二手货架。货架上只有7件来自佛蒙特州旧货店的真实商品，每件都对应eBay上的真实链接。没有登录，没有结账页——这个货架天生就是给机器看的。

为什么二手转售商需要“代理可读”的货架

传统电商的痛点是：人类能看页面，Agent却只能靠爬虫抓取非结构化信息。视频作者指出，转售商真正缺的不是店面，而是Agent无法读懂货架。他给出的解法是用公开JSON目录（catalog）作为唯一事实源，人看见的字段和Agent看见的字段完全一致：ID、标题、价格、品相、照片、eBay真实链接。

目录本身只读，商品一旦售出就从目录中消失。因此它不是一个商店，而是一个实时索引。目录里还包含来源和更新时间，Agent可以据此判断数据新鲜度。没有第二份数据库，没有隐藏价格——人机看到的是同一份数据。

“Agent可读”与传统的“机器可读”并不等同。搜索引擎爬虫能抓取HTML，但页面里混杂着导航、广告、样式和动态渲染内容，字段语义要靠启发式推断；而Agent可读要求的是稳定、带Schema、字段含义明确的结构化数据，最好还能通过工具接口按需查询而非全量抓取。JSON目录恰好满足这些条件：字段名即语义，availability等标志位可直接判断状态，来源与更新时间可评估新鲜度。业界常见的补充做法还包括schema.org的Product/Offer标注、llms.txt以及为Agent单独提供的API或MCP端点。本文选择以公开JSON目录作为唯一事实源，本质上是把“给机器看的数据”和“给人看的数据”解耦又保持同源，避免了为Agent单独维护一套数据导致的漂移问题。

四件套架构：目录、页面、MCP服务与购买意图

货架由四部分组成：公开目录（Public Catalog）、人类页面、给Agent用的MCP服务器、以及x402购买意图。目录是事实源，页面、MCP服务器和支付请求都从它读取。

• 公开目录：JSON格式，每项含ID、标题、价格、品相、照片和eBay链接，availability字段即实时标志。
• 人类页面：把每项渲染成卡片，展示照片、价格、品相，并附两个链接——一个跳eBay，一个触发Agent购买意图。
• MCP服务器：暴露三个工具（搜索、获取单件、购买意图），Agent通过JSON-RPC调用。
• x402购买意图：当Agent表达购买意向时，返回402 Payment Required挑战，包含价格、网络、代币合约和卖家地址。

MCP工具设计：让Agent“问”而不是“爬”

MCP（Model Context Protocol）是Agent请求工具的标准方式。这个货架暴露了三个只读工具（购买意图除外）：

1. search_items：接受文本查询和最高价格，从实时目录返回匹配项。
2. get_item：按ID返回单个商品详情。
3. buy_intent：按ID返回该商品的支付挑战。

Agent不需要解析网页，而是发出类型化请求、获得类型化JSON响应。它可以链式调用：先搜索，再检查，最后表达意图。端点、卡片和Schema全部公开，这正是货架对Agent有用的关键。

MCP（Model Context Protocol）由Anthropic于2024年末提出并开源，目标是给大模型应用提供一套统一的“工具/资源”接入协议，类似AI领域的USB-C接口。它采用客户端-服务器架构，基于JSON-RPC 2.0进行通信，一个MCP Host（如Claude Desktop、IDE插件或自研Agent框架）可以同时连接多个MCP Server。Server端通过声明式的Schema描述自己提供哪些工具（tools）、可读取哪些资源（resources）以及可复用哪些提示模板（prompts），Host端据此自动生成工具调用接口。相比让Agent爬网页再解析HTML，MCP让Agent直接拿到类型化、带Schema的响应，显著降低解析失败率，也让工具能力可以被发现和组合。本文中的货架MCP服务器正是扮演了这样一个Server角色，把目录查询和购买意图封装成标准工具暴露给任意兼容MCP的Agent。

x402购买意图：代理表达，人类成交

据报道，x402-2是一种面向Agent的支付挑战。Agent请求购买时，货架返回402支付要求，挑战中明确价格（以最小单位计）、资产合约和卖家地址。Agent可以支付，协调者（facilitator）验证后，卖家收到一份签名的购买意图。

这里有一条诚实的边界：购买意图只是一个信号，不是结账。eBay仍然完成真实交易，机器不发货、不托管、也不虚构销售。Agent负责“意向”，人类市场负责“成交”。

x402得名于HTTP状态码402“Payment Required”——这个状态码早在HTTP/1.1规范中就被预留，但长期以来几乎没有实际用途。x402协议把它重新激活：当客户端请求一个需要付费的资源时，服务器返回402响应，并在响应头或响应体中携带支付要求（价格、链上网络、代币合约、收款地址、有效期等）。客户端（可以是Agent）据此完成支付，并把支付凭证随重试请求一起提交，服务器或第三方facilitator验证后放行资源。其设计思路是让支付成为HTTP请求的一部分，而不依赖账户登录、订阅或跳转结账页，因此特别适合无头、无人值守的Agent场景。本文中buy_intent工具返回的402挑战就是这一机制的体现，只不过货架把“付款即交付”降级为“付款即表达购买意图”，最终成交仍由eBay完成。

真实世界的摩擦：平台限制与人工关卡

作者没有回避失败。在视频上传素材时，LinkedIn返回413（28MB单请求被拒）；X（推特）被账号确认锁住；Amazon KDP仍有人工身份和税务墙。机器能写书、造书，但创始人必须手动上传。每周的上限是真实存在的：货架上7件在售、2本书在审、没有虚假流量。

这种“机器承认自己做不到什么”的态度，反而让实验更有说服力。货架是小型真实系统，不是增长黑客，也不假装是。

对Agent开发者的启示

这个实验的价值不在7件商品，而在模式：用公开结构化目录解决Agent可读性，用MCP提供类型化工具调用，用x402处理支付意图，同时保留人类市场的最终闭环。如果模式可行，扩大库存只是数据问题，不需要重建系统。

作者表示会用浏览量、点击率和购买意图来衡量，并与YouTube基线对比；打不过基线就停止。对正在构建Agent的开发者来说，这个模式才是重点——Agent负责标记，人类负责购买。