过去 12 个月，AI 商业基础设施领域发生了一场静悄悄的标准战争。三个协议几乎同时出现，每一个都由科技行业最有影响力的公司支持：
UCP（Universal Commerce Protocol）——由 Google 和 Shopify 联合推动。定位于 AI 商业的"发现层"：产品目录查询、库存检查、价格比较、产品详情获取。当一个 AI Agent 帮用户查找"200 美元以下的防水跑鞋"时，UCP 提供标准化的数据接口。
ACP（Agentic Commerce Protocol）——由 OpenAI 主导，Stripe 深度参与。定位于 AI 商业的"执行层"：加入购物车、发起结账、处理支付、确认订单。当 AI Agent 代替用户完成购买时，ACP 提供安全的交易执行管道。
AP2（Agent Payments Protocol）——由 Google 提出。定位于 AI 商业的"授权层"：密码学签名的代理授权、支付权限委托、审计链条。当 AI Agent 需要代替用户花钱时，AP2 提供"我被授权这样做"的密码学证明。
这三个协议正在从三个不同的起点——发现、执行、授权——构建同一个愿景：AI Agent 可以代替人类完成完整的商业交易流程。
三个协议解决了什么，以及没有解决什么
每个协议在自己的领域内是精确的：
- UCP 知道 Agent 查询了哪些产品目录、在哪些过滤条件下
- ACP 知道 Agent 发起了哪些结账、支付状态如何
- AP2 知道 Agent 的授权是否有效、花了多少钱、审计链条是否完整
但它们之间存在一个巨大的证据缺口。
一个典型的 AI 商业路径如下：
- 用户问 AI：「帮我找一双防水跑鞋」
- AI Agent 调用 UCP 查询多个商家的产品目录 → UCP 可观测
- AI 综合信息，向用户推荐三个选项 → Answer 层，协议不可观测
- 用户点击 AI 推荐的链接到达某商家网站 → Visit 层，协议不可观测
- 用户浏览产品页面、对比尺码表 → Commerce 层初段，协议不可观测
- 用户决定购买，AI Agent 发起结账 → ACP 可观测
- AI Agent 请求支付授权 → AP2 可观测
- 订单完成 → ACP/AP2 可观测
问题在步骤 3-5：从 AI 发现到 AI 结账之间的整段人类行为——推荐、到达、浏览、比较——协议完全不可观测。
这不是协议的设计缺陷。协议解决的是机器之间的互操作性问题：如何让 Agent 安全地查询目录、执行交易、验证授权。它们不关心（也不应该关心）人类在网站上做了什么。
但从商业度量的角度看，这段缺口是致命的。
如果你只有 UCP 查询数据和 ACP 交易数据，你知道"AI 查了 100 次目录"和"AI 完成了 3 笔订单"。你不知道从 100 次查询到 3 笔订单之间发生了什么：多少次查询产生了用户可见的推荐？多少次推荐被用户点击？多少次点击产生了有意义的浏览？多少次浏览走到了结账？
没有这些中间层的数据，你无法优化任何东西。你不知道是推荐质量的问题（AI 推荐了错误的产品），还是着陆页体验的问题（用户到了但没有转化），还是价格竞争力的问题（用户对比后选择了竞品）。
AIAA 是证据缺口的解决方案
这就是 AIAA 五层框架存在的原因。AIAA 不试图替代任何协议——它填补协议之间的度量缺口：
阶段 | 协议/框架 | 可观测内容 |
|---|---|---|
AI 发现（目录查询） | UCP | Agent 查询了什么产品、什么条件 |
AI 推荐（应答） | AIAA Answer 层 | AI 是否提及品牌、如何描述、是否推荐 |
Agent 抓取（信息获取） | AIAA Request 层 | Agent 读取了哪些页面、频率和深度 |
用户到达（AI 引荐） | AIAA Visit 层 | 用户从哪个 AI 到达、着陆在哪里、做了什么 |
商业意图行为 | AIAA Commerce 层 | 加购、比较、结账发起 |
AI 结账（交易执行） | ACP | 结账细节、支付状态 |
AI 授权（支付验证） | AP2 | 授权签名、审计链 |
收入归因 | AIAA Attribution 层 | 这笔收入可以追溯到 AI 来源 |
AIAA 的五层——Answer、Request、Visit、Commerce、Attribution——精确填补了从 UCP 的产品查询到 ACP 的交易执行之间的度量真空。
为什么这个缺口重要
在传统电商中，类似的度量链路已经成熟：Google Ads 点击 → 着陆页 → 产品页浏览 → 加购 → 结账 → 订单。每一步都有成熟的追踪工具（GA4、GTM、Shopify 分析、Facebook CAPI）。广告商可以精确地知道 $1 广告费在每一个漏斗环节的效率。
在 AI 商业路径中，这个链路还不存在。协议定义了两端（发现和结账），但中间的度量层——AI 推荐了什么、用户怎么反应、网站上发生了什么——是空白的。
这个空白正在产生现实的商业后果：
- 品牌无法归因 AI 收入。你知道 Shopify 说 AI 订单增长了 13 倍，但你不知道你自己的 AI 归因收入是多少——因为你的分析工具看不到 AI 推荐到达的用户是否完成了购买。
- 无法优化 AI 渠道。传统渠道有清晰的优化杠杆：广告文案、出价策略、着陆页设计、结账流程。AI 渠道的优化杠杆还不清晰——部分原因是你不知道漏斗在哪里泄漏。
- 无法做 AI vs 非 AI 的 ROI 比较。如果你不能度量 AI 渠道每一步的效率，你就不能把它和 Google Ads、Meta Ads、Email 做同等的 ROI 比较。AI 在资源争夺战中会输——不是因为它真的效率低，而是因为它缺乏度量基础设施。
Agentic Commerce 的"商业证据层"
我在这个系列的第一篇中说过：未来的电商是一个 AI 发现、AI 推荐、AI 到达、AI 购物车、AI 交易、AI 归因的商业证据层。
协议（UCP/ACP/AP2）提供了基础管道。但管道不等于度量。高速公路让车可以从 A 到 B，但你还需要交通监控系统来知道有多少车在路上、它们从哪里来、到哪里去、有多少到达了目的地。
AIAA 就是 AI 商业高速公路上的交通监控系统。
协议互操作性的现实
值得注意的是，这三个协议目前还处于早期阶段，互操作性有限：
- UCP 和 ACP 由不同的公司主导（Google/Shopify vs OpenAI/Stripe），数据格式和集成方式不完全兼容
- AP2 目前还是提案阶段，尚未有大规模商业部署
- 没有任何一个协议提供跨协议的统一度量接口
这意味着在可预见的未来，度量 AI 商业影响的工作不会被协议自动解决。你需要一个独立的、跨协议的度量框架。AIAA 的设计就是与协议互补而非依赖：
- 如果你已经接入了 UCP，AIAA 的 Request 和 Visit 层可以补充 UCP 产品查询之后的用户行为数据
- 如果你已经接入了 ACP，AIAA 的 Attribution 层可以把 ACP 的交易数据和 AI 来源会话做 join，产生完整的 AI 归因收入
- 如果你都没有接入，AIAA 仍然可以独立运作——它不依赖任何 Agentic Commerce 协议，它基于你自己的网站日志、Edge 数据和一方追踪
MCP 与度量基础设施的关系
还有一个值得讨论的视角：MCP（Model Context Protocol）和度量基础设施的关系。
MCP 不是商业协议——它是 AI Agent 调用外部工具的通信标准。当 ChatGPT 通过 MCP 连接到你的 Shopify 后台读取产品数据时，它使用的是 MCP 的 tool-calling 接口。Meta Ads MCP 让 Agent 读取广告账户数据，Shopify MCP 让 Agent 读取商品和订单数据。
从度量角度看，MCP tool call 是一个可观测事件。OpenTelemetry GenAI Semantic Conventions 已经定义了 execute_tool 和 invoke_agent 作为标准 trace span。每次 MCP tool call 都可以被记录为：谁在调用、调用了什么工具、输入是什么、输出是什么、是否成功。
这意味着当 Agentic Commerce 协议通过 MCP tool-calling 来执行时，AIAA 的 Request 层可以直接消费 MCP tool call 的 trace 数据。这是 AIAA 和协议层之间最有可能的早期集成路径。
对中国出海企业的启示
对中国出海企业来说，协议战争的核心启示是：不要等协议成熟再开始度量 AI 影响。
协议的成熟——标准统一、广泛采用、互操作性完善——可能需要 2-3 年。但 AI 对你的电商业务的影响已经在发生：Shopify 的 AI 订单增长 13 倍是今天的数据，不是预测。BrightEdge 的 15% Agent 流量是今天的数据。Adobe 的 393% AI 推荐流量增长是今天的数据。
你现在就可以部署 AIAA 的前三层（Answer、Request、Visit），不依赖任何 Agentic Commerce 协议。当协议成熟后，AIAA 的 Commerce 和 Attribution 层可以自然地与协议数据集成。
这就是为什么我们把 AIAA 设计为一个独立但可扩展的框架：
- 独立：它基于你已经拥有的数据（网站日志、Edge 日志、GA4、电商平台数据），不需要 UCP/ACP/AP2 的任何接入
- 可扩展：当协议成熟、你接入了 UCP 产品查询数据或 ACP 交易数据时，AIAA 可以无缝集成这些协议层数据，扩展它的度量深度
系列总结：AIAA 的五个核心论点
回顾这五篇文章，AIAA 的框架可以提炼为五个核心论点：
- 度量动作，不度量 Agent 数量。 Agent 身份不稳定、不可比、不等于商业价值。AIAA 度量有证据支撑的动作。（第 1 篇）
- 分层度量，不混合归因。 AI 曝光、机器请求、人类到达、商业行为和可归因收入是五个独立的事实层。把它们混成一个数字是虚假归因。（第 2 篇）
- 区分真增长和可见度提升。 每次追踪升级都会让 AI 指标跳升。这是观测能力改善，不一定是 AI 增长。可比增长才是真增长。（第 3 篇）
- 升级你的证据基础设施。 GA4 只能看到 AI 活动的冰山一角。Evidence Ladder 从 L0 到 L3，每一级解锁新的观测层。大多数团队应该立即从 L0 升级到 L1.5。（第 4 篇）
- AIAA 是协议和商业证据之间的缺失层。 UCP/ACP/AP2 定义了 AI 商业的管道，但不度量管道中间发生了什么。AIAA 填补这个证据缺口，让你能归因 AI 对收入的真实贡献。（第 5 篇）
下一步行动
如果你是 CEO 或 CMO：把 AIAA 加入你的月度业务审查。让团队开始分层汇报 AI 影响，而不是用一个模糊的"AI 流量"数字。
如果你是增长负责人：本周就部署 L1 一方 JS，两周内部署 L1.5 Edge Lite。你会第一次看到 AI Agent 活动的真实规模。
如果你是数据工程师：开始规划 session-to-order join 的数据管道。这是 Attribution 层的基础，也是最终产生"AI 归因收入"数字的关键。
如果你是 GEO 优化团队：开始 Answer 层的 SOV 采样。了解 AI 在回答用户问题时如何描述你的品牌，比优化一个关键词排名更重要。
AI 不是未来——它今天就在你的服务器日志里。问题是你能不能看到它。
FAQ
Q1: UCP、ACP 和 AP2 之间的关系是什么？
A: 三者是 Agentic Commerce 领域的三个互补协议。UCP（Universal Commerce Protocol，Google/Shopify）负责 AI 发现层——产品查询、目录搜索、价格比较。ACP（Agentic Commerce Protocol，OpenAI/Stripe）负责执行层——结账、支付、订单。AP2（Agent Payments Protocol，Google）负责授权层——密码学签名的代理授权和审计链。它们由不同公司主导，目前互操作性有限。
Q2: AIAA 需要接入这些协议才能工作吗？
A: 不需要。AIAA 是一个独立的度量框架，基于你已有的数据（网站日志、Edge 日志、GA4、电商平台数据）。它不依赖 UCP/ACP/AP2。但当你的业务接入了这些协议后，AIAA 可以集成协议层数据来增强 Commerce 和 Attribution 层的深度。
Q3: "证据缺口"具体指什么？
A: 指从 AI 发现（UCP 产品查询）到 AI 结账（ACP 交易执行）之间的整段用户行为——AI 是否推荐了你的品牌、用户是否因此到达了你的网站、用户在网站上做了什么、这些行为是否导致了购买——完全不被协议覆盖。AIAA 的 Answer、Request、Visit、Commerce 四层精确填补这个缺口。
Q4: 这些协议什么时候会成熟到可以大规模使用？
A: UCP 已经有 Google 和 Shopify 的初步实现。ACP 有 OpenAI 和 Stripe 的支持但仍在早期阶段。AP2 还是提案阶段。完整的协议互操作性和大规模商业部署可能需要 18-36 个月。但你不需要等协议成熟才开始度量 AI 影响——AIAA 现在就可以独立部署。
Q5: Gravity 在 Agentic Commerce 协议生态中的定位是什么？
A: Gravity 不是协议制定者。Gravity 的定位是 AI 商业证据层——通过 CitationGraph 平台提供跨协议、跨平台的 AIAA 度量能力。我们帮品牌回答一个核心问题："AI 为我的业务做了什么？"这个问题的答案不在任何单个协议中，而在协议之间的度量缺口中。
Q6: 如果我现在只做一件事，应该做什么？
A: 部署 L1 一方 JS + L1.5 Edge Lite Bridge。这两步可以在两周内完成，总成本极低，但会让你第一次看到 AI Agent 活动的真实规模。从 L0（GA4 基线）跳到 L1.5，你的 AI 可见度会提升 5-10 倍。这是 ROI 最高的第一步。