爬虫时代的终结：什么将成为 Agentic Commerce 的底层基础设施

Pivota 工程团队

AI Agent 不再只是一个聊天接口，而正在变成自主的商业行为体。

它们搜索、比价、推荐——并且越来越多地尝试替用户完成购买。

Amazon 起诉 Perplexity 的事件，已经非常直白地传递出一个信号：

未来的 Agentic Commerce，无法继续依赖抓取网页和浏览器模拟来支撑。

随着各大平台不断收紧条款、加大法律和风控力度，

那条“靠爬虫抓页面 + 用浏览器模拟用户操作”的老路，正在迅速走到尽头。

如果想让 Agents 真正规模化参与商业循环，它们必须拥有：

• 干净、授权、实时的商家数据层
• 可验证的 Agent 身份与权限层
• 为机器设计的原生支付与结算链路

这篇文章会解释：为什么旧式“爬虫 + 自动化脚本”模式正在崩塌，

以及 MCP、ACP、AP2 如何共同构成下一代 Agent Commerce 的技术基础，

同时 Pivota 又如何作为这套体系的清算层存在。

⸻

1. 爬虫 + 浏览器自动化：已无法支撑 Agent 的未来

在过去很长一段时间里，开发者主要依赖：

• 爬虫抓取 HTML、解析 DOM 树
• 伪装会话、拼接 cookie
• 使用 headless 浏览器模拟用户点击
• 反向分析平台内部接口和下单流程

当流量规模有限时，这套方法“勉强可用”。

但一旦 Agent 走向主流，平台立即面临系统性风险：

• 机器人伪装真实用户
• 未授权的账号访问与操作
• 无法验证合法性的自动化下单
• 大规模抓取给生产系统带来压力
• 脏数据、过期信息导致取消订单与欺诈风险

平台方面给出的信号其实很明确：

• ❌ 爬虫极易失效
• ❌ 数据陈旧且不一致
• ❌ 浏览器自动化无法被平台真正信任
• ❌ Bot 规模越大，合规与法律风险越高
• ❌ 商家失去对流量、归因与交易行为的可见性

这些特征，都不可能成为机器驱动商业网络的基础。

如果我们希望在未来出现 “百万级 Agent × 百万级商家”的网络，就必须从一层干净、稳定、具契约性的接口开始，而不是靠易碎的模拟脚本“假装自己是用户”。

⸻

2. Agent 需要干净的商家数据层 —— MCP

Agent 不需要的是网页上的 HTML 碎片，

它真正需要的是结构化、标准化、实时更新的商业数据。

这就是为什么 Pivota 采用 MCP（Merchant Commerce Protocol） 作为 Agentic Commerce 的数据层。

MCP 提供：

• 干净、结构化的商品目录
• 标准化的价格与库存信号
• 商家元数据（配送、退货、政策等）
• 通过授权与限流来访问数据，而不是靠“偷抓页面”
• 无需解析 DOM、无需维护脆弱的选择器、没有“猜出来的字段”

示例 —— 获取商品数据

GET https://api.pivota.cc/mcp/v1/products?q=headphones

返回：

{
  "items": [
    {
      "id": "sku_88372",
      "title": "Sony WH-1000XM5",
      "price": { "amount": 29900, "currency": "USD" },
      "inventory": 12,
      "merchant_id": "m_3241"
    }
  ]
}

这不是从网页上“扒”出来再拼凑的结果，

而是 由商家确认、具备契约约束力的真实数据源。

MCP 为 Agent 提供了一套完整、可靠、干净的商家数据体系，

你可以在其之上构建排序、推荐、比价与决策逻辑，而不用担心谁又改了前端页面。

⸻

3. Agent 需要可验证的身份与权限层 —— ACP

商业问题不仅是 “我能不能看到这些商品？”

更关键的是：“你是谁？你代表谁？你能做什么？”

Agent 必须能够证明：

• 自己的身份是谁
• 当前代表的是哪位用户
• 当前拥有哪些权限与操作范围
• 商家应该如何归因、计算佣金和审计行为

这就是 ACP（Agent Commerce Protocol） 的职责。

ACP 能够保证：

• ✔ Agent 身份可验证
• ✔ 用户授权与权限范围可追溯
• ✔ 下单意图具备签名与可验证性
• ✔ 佣金、费用、渠道归因清晰可计算

示例 —— 创建订单意图（order intent）

POST https://api.pivota.cc/acp/v1/order-intents

{
  "agent_id": "agent_9231",
  "user_id": "user_4182",
  "items": [{ "sku": "sku_88372", "quantity": 1 }],
  "permissions_token": "perm_87af218...",
  "callback_url": "https://myagent.com/callback"
}

这是浏览器模拟永远做不到的：

一条 从 Agent 到用户再到商家都可验证、可审计的身份与意图链路，

让平台和商家可以放心地在大规模 Agent 流量下继续运营。

⸻

4. Agent 需要原生支付链路 —— AP2

真正的 Agent 经济，不能建立在“在网页上帮你点一下结算按钮”之上。

面向 Agent 的支付必须是：

• 可编程
• 高可靠
• 可审计
• 适配跨境与多币种
• 关注结算与对账
• 从设计之初就考虑合规

这就是 AP2（Agent Payment Protocol）——为 Agentic Commerce 设计的支付与结算层。

AP2 支持：

• 各类银行卡支付
• ACH / SEPA / Open Banking 等银行通道
• 稳定币（Stablecoin）结算
• 可编程的钱包体系
• 托管、退款、争议、风控等 API

示例 —— 执行支付

POST https://api.pivota.cc/ap2/v1/pay

{
  "intent_id": "intent_55892",
  "source_wallet": "wallet_agent_0021",
  "payment_method": "ach",
  "merchant_id": "m_3241"
}

最终得到的是一条 可信的机器对机器（M2M）结算链路。

不再依赖“headless 浏览器有没有顺利点到那个按钮”，

而是通过一套为机器交易设计的一等公民支付协议，原生支持退款、争议、对账与监管要求。

⸻

5. 技术架构：Agent ↔ Pivota ↔ 商家

在规模足够大时，你无法承受 m 个 Agent × n 个商家 的两两对接成本。

你需要的是一个可以统一规范数据、身份与支付的清算层。

Pivota 在架构上大致长这样：

                 ┌─────────────────────────────────────────┐
                 │            AI Agents (m)                │
                 │  - shopping agents                      │
                 │  - procurement bots                     │
                 │  - arbitrage engines                    │
                 └─────────────────────────────────────────┘
                                  │
                          1. 数据发现 (MCP)
                                  ▼
                 ┌─────────────────────────────────────────┐
                 │           PIVOTA MCP Layer              │
                 │  - 商品/目录 API                        │
                 │  - 价格与库存标准化                     │
                 └─────────────────────────────────────────┘
                                  │
                       2. 身份与权限 (ACP)
                                  ▼
                 ┌─────────────────────────────────────────┐
                 │           PIVOTA ACP Layer              │
                 │  - Agent 身份                           │
                 │  - 订单意图签名                         │
                 │  - 分佣与归因                           │
                 └─────────────────────────────────────────┘
                                  │
                         3. 支付结算 (AP2)
                                  ▼
                 ┌─────────────────────────────────────────┐
                 │            PIVOTA AP2 Layer             │
                 │  - 银行通道                             │
                 │  - 卡组织通道                           │
                 │  - 稳定币通道                           │
                 └─────────────────────────────────────────┘
                                  │
                                  ▼
                 ┌─────────────────────────────────────────┐
                 │            Merchants (n)                │
                 └─────────────────────────────────────────┘

通过这种方式，我们把原本的 m × n 对接问题，

压缩成 Agent 只需接一次 Pivota + 商家只需接一次 Pivota：

• Agent 一次集成，接入整个商家网络
• 商家一次集成，接入整个 Agent 网络
• 中间的数据、身份、支付复杂度，都由 MCP / ACP / AP2 承担

⸻

6. Pivota 的定位：Agentic Commerce 的清算层

随着平台对爬虫和浏览器自动化的限制越来越严格，

基于“抓页面 + 模拟点击”的时代正在走向终结。

未来的 Agent Economy，需要建立在完全不同的一套基础设施之上：

• 干净、可靠、可授权的商家数据层（MCP）
• 可验证的 Agent 身份与权限层（ACP）
• 为机器设计、可编程的全球支付与结算层（AP2）
• 一个统一的 清算与结算层，来真正解决 m × n 的对接复杂度

这正是 Pivota 所在的位置。

Pivota 是 Agent 时代的 商业与支付清算层，

通过 MCP / ACP / AP2 将千万级 AI Agents 与千万级商家连接起来。

我们不是：

• marketplace，
• 爬虫服务，
• 也不是浏览器自动化脚本。

我们是一层 协议与基础设施底座，

为 Agentic Commerce 构建那套完整、可靠、干净的商家数据与支付链路，

为 Agent 的变现与大规模商业化，打开一条真正可持续的路径。