当 AI 智能体代你销售：将 Shopify 连接到 B2B 技术栈

问题：智能体能购买，但你的 B2B 技术栈无法报价

一个通过 ChatGPT 或 Google 的 Gemini 购物的消费者现在可以发现产品、加入购物车并结账，无需打开浏览器标签页。Shopify 的 agentic commerce 文章 报告称，2026 年第一季度，AI 驱动的 Shopify 商店流量同比增长 8 倍，AI 驱动搜索带来的订单增长近 13 倍。新买家通过 AI 渠道下单的速率几乎是其他渠道的两倍。Shopify 的企业数据 进一步指出：AI 引荐的购物者转化率高出近 50%，平均订单价值比自然搜索流量高 14%。

对于消费品牌来说，这是顺风。对于在前端运行 Shopify 或 BigCommerce、在后端运行 NetSuite 或 Brightpearl 的中端市场 B2B 分销商来说，这是一个不同的问题。AI 智能体另一端的买家不是消费者——而是一家公司的采购协调员，该公司已谈判了 Shopify 目录中不存在的定价层级、信用条款和批量折扣。AI 智能体看到的是公开价格。客户在合同上享有不同价格的权利。当智能体以公开价格结账时，分销商要么吞掉利润，要么取消订单并失去销售。

第二个问题是库存。B2B 报价不是冲动消费——它需要经过审批，有时长达数天。Shopify 的实时库存是准确的，但不可预留。一个针对 240 的实时计数报价 200 单位的智能体，可能在采购订单到达时就已经错了，因为在此期间另外三份报价消耗了相同的库存。处理这个问题的 RFQ 引擎模式——带 TTL 的原子性可用性预留、取消策略快照、FX 汇率锁定——存在于 ERP 和报价层中，而非电商店面。

第三个问题是归因。Polar Analytics 的 2026 Shopify AI 评测 直接点名：「每个工具给自己的作业打分，因此归因收入加起来超过了商店实际赚到的。」当 ChatGPT、Google AI Mode、Copilot 和商家自己的店面都声称同一订单时，收入数据就不再可信。对于需要向董事会报告渠道组合的财务团队来说，不可归因的收入是一个报告问题，而非营销虚荣问题。

第一方表面覆盖什么，不覆盖什么

Shopify 在第一方 AI 智能体方面所做的工作比任何其他电商平台都多。Storefront MCP server 通过 Model Context Protocol 暴露产品发现、购物车管理、商店信息和订单管理。Customer Accounts MCP server 处理订单跟踪和退货。Universal Commerce Protocol (UCP) 与 Google 共同开发，并得到 Amazon、American Express、Etsy、Mastercard、Meta、Microsoft、Salesforce、Stripe、Target、Walmart 和 Visa 的支持，定义了 AI 智能体如何跨任何平台和任何支付处理方与商家交易。Google 在 Google I/O 2026（2026 年 5 月 19 日）推出了 Universal Cart，建立在超过 600 亿商品列表的 Shopping Graph 之上，配有 Agent Payments Protocol (AP2)，让智能体在用户指定的支出和品牌护栏内支付。

第一方表面解决了消费路径：购物者向 AI 智能体要一个产品，智能体在 Shopify Catalog 中找到它，加入购物车，并通过 Shopify Checkout 结账。商家仍为记录商家。合格产品无需自定义集成——Shopify Catalog 自动将结构化数据联合到 AI 平台。

第一方表面没有解决的是 B2B 路径。Storefront MCP server 暴露公开目录数据。它不暴露客户分层定价、谈判的合同费率、批量数量层级或账户特定的信用条款。它不预留库存——它报告可用性。它不将已接受的订单以正确的 GL 编码、子公司和税务 nexus 写回 NetSuite。它不生成采购团队可附加到采购订单的报价文档。它不产生映射哪个 AI 渠道发起了订单以及哪些工具调用执行了结账的审计轨迹。

这与 NetSuite MCP 模块分析 中出现的相同结构模式：供应商的第一方连接器解决了连接问题。它没有解决语义层问题——数据所说的与业务所意指的之间的差距。对于 NetSuite，语义差距是哪些 GL 科目构成收入。对于 Shopify B2B，语义差距是在哪些条款下哪个价格适用于哪个客户的哪个数量。

智能体编排的 B2B 解决方案

生产模式是一个位于 AI 智能体和完整 B2B 技术栈之间的自定义 MCP 模块——前端 Shopify，后端 NetSuite 或 Brightpearl，中间是供应商目录图，RFQ 引擎处理报价和预留。第一方 Storefront MCP 处理产品发现和购物车机制。自定义模块处理店面不知道的商业逻辑。

考虑一个向三个客户分段销售工业组件的分销商：具有谈判合同定价的 enterprise 账户、具有批量层级的 mid-market 账户，以及以公开目录价格购买的交易型买家。一个代表 enterprise 买家采购协调员的 AI 智能体发送了 500 个某组件的请求。智能体看到的不是公开价格——它看到的是一个起点。自定义模块拦截请求并做四件第一方表面做不到的事：

第一，解析客户身份和分段。智能体携带账户标识符（而非信用卡），模块查找该账户和产品的谈判价格层级。智能体报的价格是合同价格，而非目录价格。RFQ 引擎架构 通过从供应商项目批次加载并按数量阈值过滤的基于分段的定价层级来处理此问题。

第二，获取可用性预留。模块针对 NetSuite 库存计数调用 RFQ 引擎的 acquire_availability_hold 操作，原子性地扣减可用产能并返回带 TTL 的预留令牌。报价现在由真实预留库存支持——而非可能在买家批准前消失的实时计数。如果买家在窗口内接受，预留确认无需第二次扣减。如果 TTL 过期，产能恢复，下一份报价可以使用。

第三，快照商业条款。取消策略、FX 汇率（如果买家货币与供应商不同）以及任何限时促销在报价时冻结。如果供应商在谈判中途收紧取消条款，报价携带的是发出时生效的条款。否则会随之而来的争议不会发生。

第四，通过正确的 API 表面将已接受订单写回 NetSuite——SuiteTalk REST 用于订单记录，RESTlet 用于自定义验证，SuiteQL 用于任何需要连接的读取——同时遵守并发限制，内部计算 OAuth 签名，并为每次工具调用记录审计日志条目。智能体从不构造 OAuth 签名或选择 API 表面。它调用 create_order，模块处理其余。

人类保持在环中的位置：模块将低置信度定价解析、低于利润护栏的订单以及任何来自新账户的请求在报价发出前路由给人工审核。guardrail_price_per_uom 字段标记任何折扣使价格低于批次成本的报价。智能体提议，人类批准例外，审计日志显示谁批准了什么以及何时。

结果

可衡量的改进是具体的。报价时间从数天降至数分钟，因为智能体在一次过程中解析产品、价格和可用性，而非跨 Shopify、定价电子表格和 NetSuite 进行三次手动查找。可用性预留消除了过度承诺问题——报价要么由预留库存支持，要么不予发出。基于分段的定价消除了当合同客户因智能体不知道合同存在而被以公开价格报价时发生的利润侵蚀。审计日志产生一份渠道归因记录，将订单与发起的 AI 平台、执行它的工具调用以及修改它的人工审批关联起来——Polar Analytics 所识别的「每个工具给自己的作业打分」的归因问题在模块层解决，而非通过信任任何单一平台的自我报告功劳。

Shopify 报告的来自 AI 渠道 13 倍的同比增长订单不是 B2B 分销商可以坐视不理的浪潮。捕获它的分销商是那些其智能体层知道消费结账与 B2B 报价之间区别的——并拥有使后者成为可能的模块模式。

---

一个在店面运行 Shopify、用 NetSuite 做 ERP 并有三个供应商目录的分销商获得一个智能体，它接收来自 AI 购物渠道的请求，解析客户的谈判价格层级，针对 NetSuite 库存获取原子性可用性预留，快照取消和 FX 条款，并通过正确的 API 表面将已接受订单写回 NetSuite——每次工具调用都被记录，每个例外都被路由给人工审核。该构建是四步方法的第 2-3 阶段，通常在 5-8 周内上线。

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