连接器

当市场向智能体开放：Amazon Seller Central 的 AI 插件与卖方运营层

作者：IdeaBosque最后更新：2026年9月22日

关键要点

2026 年 9 月 23 日，Amazon 向外部 AI 智能体开放了其 Seller Central 的卖方 API 表面——这是一个面向 Amazon Quick 与 Anthropic Claude 的美区测试版 Selling Partner 插件，覆盖库存、价格、商品列表与销售分析。
90% 的 Amazon 销售合作伙伴已经在使用第三方 AI 工具，而卖家接受 Seller Assistant 建议的比例超过 90%——Amazon 是在追随自己的卖家，进入一种早已存在的智能体中介工作流。
Amazon 选择的是插件路径，而非开放协议——UCP、ACP、AP2 与 x402 仍是买方标准，接入哪些助手由 Amazon 决定，而且在公告发布前几天，它刚把 Meta 的 Muse 购物智能体挡在自家商城之外。
权限模型就是评估对象：范围受控的数据类型、逐操作的人工审批、完整的审计轨迹——卖家选择插件可以触及哪些数据，并在每项操作执行之前予以批准。
插件连接的是 Amazon 的数据与助手——而不是卖家自己的技术栈——一家运行着 NetSuite、BigCommerce 或 ShipStation 的 B2B 卖家，仍需要自己的智能体模块层来处理分层定价、多渠道库存与订单回写。

今年跟踪的每一项智能体商务标准——UCP、ACP、AP2、x402、Checkout MCP——描述的都是买方：智能体如何发现商品、协商价格、完成结账并支付。（我们在面向 AI 智能体的商务协议一文中梳理过这套技术栈。）2026 年 9 月 23 日，Amazon 在其 Accelerate 卖家大会上打开了交易的另一侧。一个新的 Selling Partner 插件将这个最大市场的卖方运营——库存、价格、商品列表与销售分析——在美区测试版中放进 Amazon Quick 与 Anthropic 的 Claude。这种吸引力是可以度量的：90% 的 Amazon 销售合作伙伴已经在用第三方 AI 工具打理部分业务，而这些卖家支付给 Amazon 的费用在 2026 年第二季度带来了 468 亿美元收入——超过 AWS 的营收，正如 GeekWire 在报道中指出的那样。

本文梳理这个插件真正开放了什么、Amazon 为何选择智能体插件路径而非开放协议、权限模型治理了什么，以及它没有解决什么——因为 B2B 卖家的运营并不会止步于市场边界。智能体在 Amazon 上调整的价格，必须与 NetSuite 中的分层价格对账。它刚刚改动的库存水平，必须与 BigCommerce 和仓库保持一致。市场产生的订单，仍然要进入 ERP。插件是市场对智能体运营给出的答案。而集成中卖家这一侧，仍有待构建。

Amazon 实际发布了什么

9 月 23 日发布了三样东西，值得把它们分开来看，因为它们的评估侧重点各不相同。

Seller Assistant，升级版。 Seller Central 内置的 AI 助手如今具备对每位卖家定价模式、库存周期与增长目标的持久记忆，并运行在搭载 Claude 模型的 Amazon Bedrock 上。Amazon 称其已推出至超过 90% 的销售合作伙伴，活跃用户达数十万，且卖家接受其建议的比例超过 90%。最后一个数字比记忆功能更重要：Seller Central 内部一个建议被多数人接受的推荐引擎，正是该插件所要延伸的行为基线。

Seller Assistant 工作流。 持续运行的自动化流程，在获得许可的前提下监控条件并采取行动——"只要我的前 10 款产品中任何一款评分跌破 4 星，就提醒我并起草一份应对方案"，或者"监控我最畅销的品类、寻找竞争空档；一旦发现，就调整我的定价并刷新商品列表"。卖家以自然语言设置护栏，并选择工作流是仅呈现建议还是执行操作。每项操作都会连同完整的审计轨迹一起记录在案。

Selling Partner 插件。 全新的表面。该插件将卖家的商品列表信息、实时绩效指标、库存水平与销售分析连接到外部智能体——发布时为 Amazon Quick，测试版中为 Claude——而外部智能体可以像 Seller Assistant 在 Seller Central 内部那样对该账户执行操作。Amazon 表示，接入 Claude 大约需要 60 秒且无需编码，并可与卖家既有的财务和供应商数据连接并存。

Amazon 自己的副总裁给出的表述正是战略层面的头条："我们的愿景是，他们再也不必登录 Seller Central，"全球销售合作伙伴体验副总裁 Mary Beth Westmoreland 在 GeekWire 的访谈中表示，"我们只需要把它带到他们工作的地方。"

为什么是插件路径，而不是协议路径

买方协议在设计上是开放的：UCP 拥有公开规范和共同开发方，ACP 托管在 GitHub 上，任何商户都可以暴露一个端点。卖方的开放则是相反的形态。Amazon 为它选定的助手发布插件——首先是自家的 Quick，然后是 Anthropic 的 Claude（Amazon 已向这家公司投资数十亿美元，其模型也已经在驱动 Seller Assistant）——并表示后续会有更多集成，而且其构建方式"足够模块化，让我们得以继续发布插件"。公告中没有任何内容描述其他平台可以实现的规范。

背景让这种对比更加鲜明。在 Accelerate 召开前几天，Amazon 把 Meta 的消费级购物智能体 Muse 挡在了自家商城之外——Amazon 表明的立场是，外部智能体必须亮明身份并遵守其所在网站的规则（GeekWire）。在卖方一侧，Amazon 同时扮演着主机、规则制定者和插件发布者。卖方智能体表面存在于 Amazon 说它存在的地方。

对卖家而言，这不是置身事外的理由，而是以评估能力时同样的严谨去评估条款的理由——因为这个表面可以被拥有市场的对手方扩展、重新定价或收窄。卖家费用已经是 FTC 针对 Amazon 的反垄断案件的诉由，该案定于 2027 年 3 月开庭审理（GeekWire）；卖家工具的经济性并不是一个中立的背景。

下图将这个插件与买方协议栈，以及它所施加的权限关卡放在了一起。

权限模型治理了什么

Amazon 自己的安全描述已经精确到可以评估：插件交互受到"对其可访问内容的清晰边界、操作的人工审批以及完整的审计轨迹"的保护。在实践中，这就是四道关卡。

数据范围。 卖家选择插件可以触及哪些类型的数据——商品列表、库存、销售分析、绩效指标。范围按数据类型划分，由卖家选定。

意图可见性。 在 Quick 中，围绕插件构建的智能体——定价智能体、商品列表智能体、补货智能体——会在行动之前展示它们打算做什么。

人工审批。 操作在执行之前需要获得卖家的批准，这与 Seller Assistant 工作流已经采用的模式一致：仅建议，或经批准后执行。

审计轨迹。 每项操作都有记录。Amazon 还表示，它看不到卖家助手中的其他业务数据——即卖家保存在 Claude 里的财务与供应商连接。这是 Amazon 关于自身执行情况的陈述，而非一个可以独立验证的属性；应当据此来看待。

这与自定义 MCP 模块所实施的是同一套控制模式：范围受控的工具、类型化的参数、写入操作上的人工关卡、经得起审计的日志。区别则不利于卖家的可见性。用你自己的模块，范围是团队读得懂的代码。用第一方插件，范围由市场定义，卖家只能信任供应商的执行。两者都没有错——但它们是不同的信任决策，而后者值得获得安全团队审视任何第三方集成时同等程度的评审。

缺口：插件连接的是 Amazon 的数据，而非卖家的技术栈

60 秒的连接把 Amazon 绑定到助手。对于 B2B 卖家实际运营所在的那些系统，它什么都没做。

定价。 插件可以在卖家护栏内调整 Amazon 价格。但它无法在调整之前查看 NetSuite 中的客户分层价目表、CPQ 中的合同条款或利润率下限。对于 Amazon 渠道必须与直销 B2B 定价对账的卖家而言，支配这次调整的定价逻辑位于插件的触及范围之外。

库存。 它看得到 Amazon 的库存水平。多渠道库存——同一个 SKU 在 BigCommerce、在 Brightpearl 仓库、被分配给一次 ShipStation 发货——是插件不去触及的另一个同步问题。

订单与回写。 市场订单仍然需要校验、税费与配送逻辑以及 ERP 录入。这正是订单管理层——一家每周处理 1,800 笔订单、拥有 380 名员工的分销商，正是凭借跨 NetSuite、BigCommerce 与 ShipStation 的类型化模式校验，把 12% 的录入错误率降到了 2% 以下。

首选助手的模式是把双刃剑。 Amazon 的宣传是，卖家已经在"现有的财务与供应商数据连接"之旁运行 Claude。一旦 Amazon 的数据进入同一个助手，卖家就会要求它把 Amazon 定价与 ERP 成本对账、把市场库存与仓库库存对账。这种跨系统推理恰恰是插件没有提供的那种集成——而卖家自己的智能体层正是让它安全的原因：每个系统都有受治理的模块，智能体可以读写什么都有明确的句柄，审计轨迹则落进业务本来就在审计的系统。

启用测试版之前要评估什么

四个问题，按顺序：

插件能写什么，而不只是读？ 价格改动、商品列表编辑与库存调整属于不同的风险类别。Amazon 的工作流区分仅建议与经批准后执行——在开启之前，把每个工作流映射到正确的类别。
审批落在哪里？ 逐操作、逐工作流，还是逐会话。定价智能体上的逐操作审批，与整个会话范围内的一次性授权是两种不同的运营模式。
审计轨迹记录什么，又能流向哪里？ 如果你的审计人员读的是 NetSuite 或合规数仓，这条轨迹就必须抵达你的审计人员已经在读的系统。
卖家这一侧需要什么？ 你的哪些系统必须看到智能体做了什么——ERP、店面、仓库——以及这些数据如何流转？这就是由你负责的集成。

卖方运营层如今是一个智能体表面。Amazon 已经用一款插件和一个权限模型走完了自己的一步；中端 B2B 卖家真正拥有的部分，是这个插件没有连接的一切。

代表性构建案例

一家中端 B2B 卖家在运营 Amazon 的同时，也运营着自己的 BigCommerce 店面和 NetSuite，而其运营团队无法把某一个渠道的智能体所做的事情与其他系统认为的情况对上账。构建从一份系统清单（Selling Partner 插件覆盖哪些表面，NetSuite 和 BigCommerce 各自暴露什么）、一张工作流图（定价调整、库存同步、订单接入）和一个固定范围开始：合适之处用第一方插件，NetSuite 和 BigCommerce 用自定义 MCP 模块，外加一套编排策略——限定写入范围、对超过阈值的调价要求逐操作审批，并让每一项智能体操作都落入 ERP 与合规工作流都能读取的审计日志。第一个集成流程——在 Amazon 上调价、查询 NetSuite 分层价目表并把决策轨迹回写——将在 5 到 8 周内上线。

请求一个范围明确的构建。一周 Discovery。你获得一份系统清单、一张工作流图和一个固定范围——无论你是否与我们合作构建。

想为您的系统构建这个吗？

这里的每份文档都来自真实的生产工作。如果您有目标系统和工作流想法，我们可以在一周内确定范围。

申请定制开发

为期一周的发现阶段。您会拿到系统清单、工作流地图和固定范围——无论您最终是否与我们合作开发。