架构

智能体商务架构：一个 MCP 能力层，四个 AI 渠道

作者：IdeaBosque最后更新：2026年10月3日

Key takeaways

四个 AI 接入渠道（自有门户、OpenAI ACP、Meta Muse 和外部 A2A 智能体）可以共用一个 MCP 能力层，而不必为同一套商务逻辑做四次独立的重复实现。
决策规则只有一句：仅当外部协议与 MCP 不同时，才增加协议适配器。 OpenAI 的 Agentic Commerce Protocol 需要 ACP→MCP 适配器；已经支持 MCP 的连接器则不需要。
Magento / Adobe Commerce 仍是权威的系统记录源：ACP、MCP 和 A2A 都不会复制它的定价、库存、税务或订单逻辑，而是调用它。
写入类工具在工具边界按影响程度进行管控：catalog.search_products 这类读取操作可自由通行，而 order.submit 和 payment.authorize 这类敏感写入则需要人工审批和幂等性保障。

把商品目录接入 ChatGPT、Meta Muse 以及合作企业的智能体，朴素的设计会把定价、库存和结账逻辑**重复实现四次，每个平台一次。**每个 AI 入口使用的协议都不同：OpenAI 推出了 Agentic Commerce Protocol（ACP，与 Stripe 共同开发），智能体通过 Model Context Protocol（MCP）调用工具，并通过 A2A 相互委派任务。惯性思维是为每个平台各建一套集成栈，而这种惯性正是代价高昂的错误。

本文给出一种与供应商无关的智能体商务架构：**南向是一个企业级 MCP 能力层，北向是多个 AI 接入渠道。**文中以 Magento / Adobe Commerce 作为商务系统记录源的实例，但该模式适用于任何 ERP、OMS 或商品目录。核心结论是一条决策规则：仅当外部平台的协议必须转换为 MCP 时才增加适配器。它能准确告诉你集成代码应该放在哪里，更有价值的是，哪里不该放。

陷阱：四个平台，四次重复实现

每个 AI 商务入口需要的底层操作都相同：搜索商品目录、查询库存、获取价格、创建购物车、提交订单。朴素的架构会让每个入口带着各自的逻辑直接接入商务平台：

自有网站 → 定制的 Magento 调用
OpenAI / ChatGPT → 另一套 Magento 调用
Meta Muse → 又一套 Magento 调用
合作伙伴智能体 → 再一套

这时，一次定价规则变更、一个新的税务辖区或一次库存预留修复，都要在四个地方修改并测试。业务逻辑被复制了，而副本会逐渐偏离。这与让点对点集成在任何规模下都代价高昂的连接器蔓延是同一个问题，只不过对象从 SaaS 端点换成了 AI 渠道。

解决办法是把四套南向实现合并为一套。所有渠道都访问同一个企业能力层，它通过 MCP 暴露，由规范化商务服务支撑，最终以 Magento 作为商品、定价、库存、购物车、税务和订单的唯一事实来源。Magento 继续掌管商务逻辑，AI 渠道只是调用它。

决策规则：仅在协议不匹配时才加适配器

对架构而言，各渠道只有一处关键差异：**它们使用什么协议。**仅此一点就决定了某个渠道是需要转换适配器，还是可以直接接入 MCP。这三种协议并不相互竞争，它们回答的是不同的问题：

技术	它是什么	它回答什么问题
HTTP / REST / JSON	传输方式、API 风格和数据格式	字节如何传输
ACP	AI 商务互操作（OpenAI + Stripe）	AI 商务平台与商家如何完成交易
MCP	智能体/应用与工具之间的互操作	智能体或应用可以调用哪些工具
A2A	智能体之间的互操作	一个智能体如何把工作委派给另一个智能体

ACP 与 MCP 解决的是不同的问题，因此确实需要一个 ACP 适配器：它把 ACP 的商务语义（结账会话、订单状态、数据源格式）转换为 MCP 工具调用。A2A 同样有别：外部智能体通过 A2A 委派任务，由网关路由到你的 Agent Core，再由 Agent Core 调用 MCP。但如果某个平台的连接器模型本身就使用 MCP，则完全不需要适配器，它可以直接访问能力层。

这正是反直觉之处。直觉是"新的 AI 平台就要新的适配器"，而这条规则恰恰相反：**仅当平台协议不是 MCP 时，才构建适配器。**于是四个渠道最终归结为四条接入路径，而不是四套集成：

自有门户 → Agent Core → MCP
OpenAI / ChatGPT → ACP → ACP 适配器 → MCP
Meta Muse → Muse 连接器 → MCP （无需适配器，连接器本身使用 MCP）
外部智能体 → A2A → A2A 网关 → Agent Core → MCP

一切都汇聚到 MCP。这种汇聚就是整个设计：

整体架构一览：

MCP Commerce Server 是可复用的边界

能力层是一个 MCP 服务器，对外暴露一组小而稳定的商务工具：catalog.search_products、pricing.get_price、inventory.check、cart.create、cart.add_item、order.submit、order.get_status。所有渠道使用同一组工具。自有门户的 Agent Core、ACP 适配器、Muse 连接器，以及通过 A2A 到达的外部智能体，都调用同一个 catalog.search_products，没有谁各自实现一遍商品搜索。

关键在于，MCP 是能力接口，而不是业务数据模型。工具背后是规范化商务服务（一个与协议无关的 Product、Variant、Price、Inventory、Cart、Order 模型），以及把该规范化模型映射到 Adobe Commerce API 的 Magento 适配器。当 OpenAI 的商品数据源格式或 ACP 的结账模式变化时，只有 ACP 适配器需要改动；当 Magento 的 API 变化时，只有 Magento 适配器需要改动。中间的工具保持稳定。这与受治理的 MCP 模块遵循同样的结构纪律：类型化的工具、稳定的契约，以及被隔离在边缘的供应商特有行为。

工具按影响程度分类，治理就体现在这种分类上。读取操作（catalog.search、pricing.get、inventory.check）风险较低，可自由通行。写入操作（cart.add_item）会改变状态，但可以撤销。敏感写入（order.submit、payment.authorize、refund.create）涉及资金流动或产生义务，需要人工审批、用于防止重复下单的幂等键以及审计日志，并在工具边界强制执行，无论由哪个渠道发起调用。连接器自身的治理层（身份认证、用户权限、人工审批关卡）位于 MCP 服务器之前，而不是取代它。

为什么 Meta Muse 不需要适配器，而 ACP 需要

两个外部 AI 平台的对比，最能说明这条决策规则。OpenAI 的 ACP 与 MCP 是不同的协议，所以 ACP 路径带有一个适配器，把 ACP 的商务语义转换为 MCP 工具调用。相比之下，如果连接器模型将集成以 MCP 端点的形式提交，就可以直接使用能力层：治理边界是连接器的审核与权限模型，但无需再构建或维护第二个转换层。若"因为 Muse 是另一个平台"而再加一个，只会产生没有实际作用的集成债务。

同样的检验适用于未来的每一个 AI 入口。只需问一个问题：*这个平台能直接使用 MCP 吗？*如果能，它就接入现有服务器并复用所有工具；如果不能，就恰好增加一个协议适配器，别无其他。这样，四个渠道（以及第五个、第六个）的成本都能保持在低位。

超越商务：同一个能力层成为企业智能体平台

商务只是 MCP 的一个领域。同一个 Agent Core 可以调用 Commerce MCP 服务器、CRM MCP 服务器和 ERP MCP 服务器，在一个计划中跨 Commerce 与 CRM 完成诸如*"找出与该客户过往购买兼容、500 美元以内、有库存的商品，并准备一份推荐"*这样的请求。对于外部委派，A2A（在第一年就超过了 150 家组织）允许合作企业的采购智能体委派你的销售智能体，由后者调用你的 MCP 层，而无需让合作方直接访问内部系统。商务架构与更宽泛的 MCP + A2A 企业技术栈，是不同范围下的同一种架构。

一个典型的实施案例

一家使用 Adobe Commerce 的中型商家希望在没有平台团队的情况下，能在 ChatGPT 和 Meta Muse 中销售商品。我们先构建了规范化商务服务和 Magento 适配器，暴露了六个 MCP 商务工具，并让自有门户的 Agent Core 基于这些工具运行。接着是 OpenAI：一个 ACP 适配器加上商品数据源转换器，底层完全复用同一组工具。Meta Muse 是所有渠道中成本最低的：我们为现有的 MCP Commerce Server 编写了文档（端点、身份认证、工具、读写分类、敏感写入审批），并提交连接器审核，没有编写任何专有适配器。一个能力层；每增加一个渠道，只是多一条接入路径，而不是一次重建。