用 MCP 将 AI 智能体连接到 BigCommerce：Stripe 合作未解决的问题

问题：三条路径，没有一条解决 B2B 报价

BigCommerce 选择了与 Shopify 和 HubSpot 不同的路径。Shopify 构建了第一方 Storefront MCP 和 Customer Accounts MCP 服务器，并与 Google 共同开发了 Universal Commerce Protocol。HubSpot 发布了第一方 Remote MCP Server（2026 年 4 月 13 日正式发布），包含 12 个覆盖标准 CRM 对象的工具。BigCommerce 两者都没有做。相反，2025 年 12 月 18 日，BigCommerce 与 Stripe 合作，加入 Stripe 的 Agentic Commerce Suite，该套件基于 Agentic Commerce Protocol (ACP) 构建——一个由 Stripe、OpenAI 和 Meta 共同创建的开放标准，采用 Apache 2.0 许可。

结果是连接 AI 智能体到 BigCommerce 店铺的三条不同路径，每条路径的覆盖范围不同：

BigCommerce 智能体集成的三条路径连接不同的技术栈层级：

路径 1——BigCommerce 文档 MCP 服务器。 BigCommerce 在 https://docs.bigcommerce.com/_mcp/server 暴露了一个 MCP 端点，让 AI 智能体搜索 BigCommerce 开发者文档。它通过从文档中提取信息来回答诸如"BigCommerce checkout API 如何工作"之类的问题。它是一个用于文档的 MCP 服务器，而非用于店铺数据。连接到它的智能体可以学习 BigCommerce API 如何运作，但无法读取任何店铺的产品、客户、订单或库存。这是一个开发者赋能工具，不是店铺集成路径。

路径 2——Stripe 的 Agentic Commerce Suite，基于 ACP。 合作公告这样表述："BigCommerce 商家将能够解锁 AI 驱动的发现和结账流程，同时继续使用现有的目录、订单系统和操作流程。"商家将产品目录连接到 Stripe，选择通过哪些 AI 智能体销售，Stripe 处理发现、结账、支付和欺诈检测。Stripe 的 Agentic Commerce Suite 文章量化了替代成本：没有它，企业面临"每支持一个新 AI 智能体最多 6 个月的集成工作"。ACP 路径用一个可配置的集成替代了这些。

ACP 架构是可组合的：agentic checkout（购物车管理、履约选项、支付处理）、cart 和 feed（产品目录浏览）、通过 Shared Payment Tokens 的委托支付（SPTs——限定于卖家、受时间和金额约束、通过其生命周期可观测）、通过 OAuth 2.0 的委托认证，以及用于生命周期跟踪的订单和 webhooks。Stripe Radar提供针对非人类流量模式调优的欺诈检测。商家保留 merchant-of-record 状态和对客户关系的控制。

这条路径解决了消费者智能体商务问题：购物者向 AI 智能体请求产品，智能体通过 Stripe 的目录 feed 发现它，通过 Stripe Checkout Sessions API 结账，并通过 SPTs 支付。它不解决 B2B 问题。

路径 3——第三方供应商的托管 MCP 服务器。 StackOne 提供一个 BigCommerce MCP 服务器，开箱即用 120 个操作。Truto 通过其 /tools 端点暴露 BigCommerce REST API 能力。开源项目 isaacgounton/bigcommerce-api-mcp 封装了完整的 BigCommerce REST API 表面。这些服务器给智能体提供对产品、客户、订单和库存的类型化工具访问——即 REST API 支持的 CRUD 操作。

问题不在于这些托管服务器做错了什么。问题在于三条路径都没有编码的东西：B2B 语义层——决定哪个价格适用于哪个客户、哪些库存可预留、哪些订单映射到哪些 ERP 记录的业务含义。

ACP 路径对 B2B 未覆盖的内容

ACP 产品 feed 到 Stripe 每个产品携带一个价格——公开目录价格。BigCommerce 实际的 B2B 定价结构存在于 Customer Groups 和 Price Lists 中。Price Lists 允许通过 Price List Assignment API 将变体级价格覆盖分配给特定 Sales Channels 上的特定 Customer Groups。一个运行四个定价层级——企业合同、中市场批量、批发和公开零售——的经销商有四个 Price List Assignments，将四个 Price Lists 映射到四个 Customer Groups，跨越一个或多个渠道。

当代表企业买家采购协调员的 AI 智能体通过 ACP 路径发送请求时，智能体看到公开目录价格。客户有合同权利获得企业层级价格——可能低 20-40%。ACP feed 不携带层级结构。智能体报出错误价格。经销商要么吞掉利润，要么取消并失去销售。

BigCommerce 合作公告承认了这一点：商家"通过 BigCommerce 库存和定价逻辑来告知智能体购物。"这个措辞意味着商家在 BigCommerce 中配置定价逻辑，而 Stripe 应当遵守它——但 ACP feed 架构将目录扁平化为单一价格表面。B2B 层级智能不在 feed 中。

第二个缺口是库存。BigCommerce 的 Catalog Products API 报告库存水平但不预留。一个针对 240 活库存报价 200 件的智能体可能在采购订单到达时已经错了，因为其他三份报价在此期间消耗了同样的库存。RFQ 引擎架构——带 TTL 的原子性可用性预留、取消策略快照、FX 汇率锁定——存在于 ERP 和报价层，不在电商店铺中，也不在 ACP 路径中。

第三个缺口是 ERP 回写。ACP 路径通过 webhooks 将已接受订单交回商家。商家的订单系统——BigCommerce Orders API——接收它。但 BigCommerce 中的订单对象不编码 GL 科目、子公司、税务 nexus 或 NetSuite/Brightpearl 需要正确过账订单的自定义字段。NetSuite MCP 模块分析深入涵盖了这一点：电商订单和 ERP 订单记录之间的语义缺口是哪些 GL 科目、哪个子公司、哪个税务 nexus 以及哪些自定义字段构成有效过账。ACP 路径不桥接该缺口。

托管 MCP 服务器未编码的内容

托管 MCP 服务器（StackOne、Truto、Apideck）解决不同的问题：它们给智能体类型化的 BigCommerce REST API 访问。StackOne 的 120 个操作 覆盖产品、客户、订单、库存和店铺管理。Truto 将 REST API 封装在统一的 /tools 端点后面。这些是真实产品，不是演示——它们让 BigCommerce API 对 AI 智能体可读，无需自定义集成代码。

但类型化 API 访问不等于类型化业务含义。一个暴露 get_products(filters) 的托管 MCP 服务器给智能体查询产品的能力。它不告诉智能体对于这家店，客户组 4（"Enterprise Contract"）在"B2B Portal"渠道上有权获得 Price List 7，且来自该组买家的请求应通过 GET /v3/pricelists/7/records?variant_id={id} 解析，而非通过默认目录价格。托管服务器封装 API 表面。它不编码决定哪个 API 调用意味着什么的业务规则。

这是跨连接器系列出现的相同结构模式。HubSpot 分析记录了 HubSpot 第一方服务器的六个能力缺口——无自定义对象、无可审查写入计划、每连接一个门户、无系统级设计、仅活 API 查询，以及敏感数据约束。Shopify 分析记录了第一方 Storefront MCP 未覆盖的 B2B 路径——客户层级定价、批量 RFQ 报价、针对 NetSuite 的库存预留和跨渠道订单归因。每种情况下，供应商连接器解决了连接问题。自定义 MCP 模块解决了语义层问题。

对于 BigCommerce，供应商根本没有构建连接层 MCP 服务器——它将消费者智能体商务委托给 Stripe，将店铺数据 MCP 表面留给了第三方供应商。语义层缺口是相同的。不同之处在于连接层本身更加碎片化。

认证：对 headless 友好的约束

BigCommerce 的 API 认证使用 X-Auth-Token——一个从店铺管理后台（Store Setup → API Settings）生成的店铺范围 bearer token，或通过 OAuth 应用安装流程在商家安装应用时签发。与 HubSpot 的 OAuth 2.1 with PKCE（需要基于浏览器的同意和一次性 refresh token）不同，BigCommerce API token 除非被撤销否则不过期，且不需要基于浏览器的刷新。这比 HubSpot 第一方 MCP 服务器更适合 headless：一个在凌晨 2 点运行以同步隔夜订单变更的后台智能体可以用静态 X-Auth-Token 认证，无需任何人工介入。

约束是速率限制，不是认证：

API 通过 headers 返回速率限制状态：X-Rate-Limit-Requests-Quota、X-Rate-Limit-Requests-Left、X-Rate-Limit-Time-Reset-Ms。列表端点每页返回 250 条。一个对 Standard 店铺同时发起 30 个并行工具调用的智能体会一次性耗尽 150 请求窗口并在其余调用上收到 429。一个不执行每工具限流的托管 MCP 服务器将该失败作为非结构化错误传给智能体。

自定义 MCP 模块内部执行每工具速率限制——每个工具声明自己的限制，骨干节点将请求限制在 30 秒窗口内，智能体收到一个带 Retry-After（从 X-Rate-Limit-Time-Reset-Ms 派生）的结构化 429，而非崩溃。模块还批量处理列表查询——模块使用过滤查询仅拉取智能体实际需要的记录，而非分页遍历 200 个每页 250 条的请求，保持在速率窗口内。

自定义 MCP 模块提供什么

模块模式遵循 MCP Module Code Standard：每个工具有类型化输入 schema、类型化输出 schema、速率限制、审计日志和错误合约。智能体通过名称和结构化参数调用工具，而非对原始端点的自由格式 API 调用。

对于 BigCommerce，自定义模块填补 ACP 路径和托管 MCP 服务器留开的缺口：

客户组价格解析。 模块暴露 get_tier_price(customer_id, product_id, channel_id, quantity)——一个类型化工具，解析买家的 Customer Group，找到该组在当前渠道的 Price List Assignment，并返回所请求数量的变体级价格。智能体不需要知道客户组 4 映射到 Price List 7。模块编码该映射。智能体调用 get_tier_price 并收到正确的合同价格，而非公开目录价格。

库存可用性预留。 模块封装 BigCommerce 库存水平检查并添加预留层——如果店铺支持则针对 BigCommerce 库存，否则针对上游 ERP（NetSuite、Brightpearl），那里存放着权威库存计数。智能体调用 acquire_availability_hold(product_id, quantity, duration_minutes) 并收到一个带 TTL 的预留 token，与 RFQ 引擎架构一致。报价由预留库存支持，而非可能消失的活库存计数。

带语义映射的 ERP 回写。 模块接受 BigCommerce 订单并将其转换为 ERP 期望的格式——GL 科目、子公司、税务 nexus、自定义字段。智能体调用 create_erp_order(bigcommerce_order_id)，模块处理转换、API 表面选择（SuiteTalk REST、RESTlets、SuiteQL 用于 NetSuite；Brightpearl API 用于 Brightpearl）、认证和审计日志。智能体不构造 OAuth 签名或选择 API 表面。

可审查的写入计划。 模块为多步骤变更起草结构化计划——"从昨天已接受的报价创建 15 个订单，每个以正确的 GL 科目过账到 NetSuite，在 BigCommerce 创建履约任务"——并在执行前路由到人工审核。ACP 路径和托管 MCP 服务器立即执行。模块添加审核门以防止错误批次扭曲 ERP。

限流批量查询。 模块内部执行 BigCommerce 速率限制——每工具限流、批量列表查询，以及一个将目录和订单数据同步到本地存储的管理数据层，用于跨对象分析而无需每次问题都走 API 往返。智能体问"显示过去 30 天内 Enterprise 客户组中没有对应 NetSuite 过账的所有订单"，模块从本地层返回答案，而非 30 分钟的分页 API 调用。

为什么这可以泛化

BigCommerce 模式——一个供应商通过合作而非自建来处理消费者智能体路径，一个封装 REST API 但不编码业务含义的托管 MCP 层，以及一个所有可用表面都不覆盖的 B2B 语义层——是跨电商和 ERP 领域出现的相同结构，只是缺口分布不同：

• Shopify 构建了最完整的第一方智能体表面（Storefront MCP、Customer Accounts MCP、UCP），但 B2B 路径——客户层级定价、批量 RFQ 报价、针对 NetSuite 的库存预留——不在第一方表面中。Shopify 连接器分析涵盖此内容。
• HubSpot 构建了包含 12 个覆盖标准 CRM 对象工具的第一方 MCP 服务器，但自定义对象、可审查写入计划、headless 认证和多门户操作是缺口。HubSpot 连接器分析涵盖此内容。
• NetSuite 有第一方 AI Connector Service 但在自己 FAQ 中警告"AI 可能产生幻觉。始终根据源数据验证结果。"语义缺口是哪些 GL 科目构成收入。NetSuite MCP 模块分析涵盖此内容。

Anthropic 2026 State of AI Agents Report（500+ 技术领导者，Novo Nordisk、Doctolib、L'Oréal、Shopify 的真实实施）将与现有系统的集成为智能体采用的第一大障碍——46% 的组织引用它，高于数据访问（42%）、安全（40%）和模型智能。47% 使用混合 build-and-buy 方法：不完全预构建，不全部自建，而是一个他们用自定义代码扩展的平台。ACP 路径是 BigCommerce 的"买"的一半。托管 MCP 服务器是店铺数据访问的"买"的一半。自定义模块是"建"的一半——使智能体对 B2B 操作有用而非仅消费者结账的语义层。

BigCommerce 与 Stripe 的合作是一个合理的产品决策——Stripe 处理支付基础设施和欺诈检测比大多数电商平台自建做得更好。但合作覆盖了消费者路径。B2B 路径——买家是有协商定价的采购协调员、库存必须被预留而非仅报告、订单必须以正确的 GL 科目和子公司映射到达 ERP——需要与本系列中所有其他连接器相同的自定义模块层。MCP Module Code Standard定义了结构。BigCommerce 连接器是合作路径案例的参考实现——即供应商外包消费者智能体层并将 B2B 语义层留给集成团队的案例。

一个在店铺前端运行 BigCommerce、用 NetSuite 或 Brightpearl 做 ERP、有四个客户组定价层级的 B2B 经销商，获得一个通过 Price List Assignment API 解析买家合同价格的智能体，针对 ERP 库存计数获取原子性可用性预留，在报价时对商业条款进行快照，并以正确的 GL 科目和子公司映射将已接受订单回写到 ERP——每个工具调用都限流、记录日志并路由给人工审核异常。该构建是四步法的 Phase 2-3，通常在 5-8 周内上线。

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