对于 AI 代理:可在 https://www.mongodb.com/zh-cn/docs/llms.txt 获取文档索引—通过在任何 URL 路径后添加 .md 可获取所有页面的 Markdown 版本。
Docs 菜单

MongoDB 上可信任代理商业的授权分类账本

学习如何在 MongoDB Atlas 上构建不可变的授权分类帐本,为代理商业创建信任层,并为问责制提供 ACID 一致性保证。

使用案例: 人工智能支付

行业: 零售

产品: MongoDB Atlas

合作伙伴: Google Cloud

AI 代理通过自动管理从产品发现到最终结账的任务,从而改变了数字商业。然而,当 AI 代理代客户发起支付时,它会打破传统商业的核心假设,并创造信任危机。

现有的支付系统无法验证代理的权限、验证客户的真实意图或定义清晰的事务问责制。这会产生主要挑战:

  • 授权:验证客户数是否授权代理进行特定采购。

  • 真实性:验证代理的请求准确反映客户的真实意图,没有错误或幻觉。

  • 责任:确定事务失败时的责任方 — 客户数、代理的开发者、商户还是发卡机构。

解决这些挑战需要所有参与者(包括客户、商家和金融机构)都可以信任的共享标准。

Google 的 代理支付协议 (AP2) 提供一个开放、安全和可互操作的协议,为商家、金融机构和日常客户构建可信的生态系统。

信任层

图 1。信任层

AP2 通过可验证数字凭证 (VDC)——代理创建和交换的防篡改、经过密码签名的 JSON 负载来确保事务安全。AP2 将这些 VDC 分为三个核心任务:

  • 意图授权:概述客户的要求,并定义 AI 代理可以代表客户进行采购的条件。

  • 购物车授权:提供由商家和客户数签名的数字收据,以授权人工存在购买。

  • 付款授权:创建与支付网络直接共享的可见性层,以安全地指示 AI 代理的参与。

VDC 充当永久数字合同。代理使用密码签名这些负载以捕获客户数意图。此过程为购物体验的每个步骤创建不可抵赖的 Atlas 审核追踪。

在每个步骤都有可验证证明的合同对话

图 2。每个步骤都有可验证的证明的合同对话

用户界面中的意图可视化,显示每个意图在对话中的表示方式

图 3。用户界面中的意图可视化,展示每个意图在对话中的表示方式

为了使这些加密 VDC 保持可信,系统必须将其存储在安全、可验证的环境中。Mandate Ledger Service 充当AI代理和数据库之间的保护性中间件。这个中间件的背后是MongoDB Atlas。

Atlas 提供企业级安全,支持防篡改的 Atlas 审核追踪。构建此架构以创建不可变的信任层,即授权分类账本服务,以扩展安全的代理商业。

设想一位客户数请求 AI 助手购买新智能手机。购物代理自主与商家协商,以找到最优惠的交易。授权分类帐本服务通过将每个请求、批准和结账步骤打包成经密码签名的 JSON 授权,记录整个过程。MongoDB Atlas 将每个授权存储为不可变的文档。此过程将简单的聊天转变为永久的、不可抵赖的意图证明。

此解决方案展示了如何在使用 AP2 协议的架构上构建 Mandate Ledger Service。

AP2 使用基于角色的架构,旨在提供安全和清晰的事务责任制。此生态系统中的每个参与者都承担着不同的责任,以简化集成并保护客户数隐私。

MongoDB Mandate Ledger Service 架构

图 4。MongoDB Mandate Ledger Service 架构

查看在此体系结构中定义的关键角色:

  • 客户数:与购物代理直接交互,以启动产品发现和购买请求。

  • 购物代理:与客户数直接交互,以发现产品、协商购物车并签署授权书。

  • 商户代理:代表卖家展示库存、协商报价并签署授权书以保证订单履行。

  • 凭证提供商:安全托管客户数的付款方式,并为事务选择合适的付款令牌。

  • 商家支付处理器:直接构建并路由事务授权消息到支付网络和发卡方。

  • 审计代理:在事务后检查不可变的Atlas 审核追踪,以使用只读访问来验证付款和签名。

  • 授权分类账服务:作为 AI 代理和 MongoDB Atlas 之间的保护中间件,可将经过密码签名的授权原生存储为 JSON 文档。MongoDB Atlas 提供服务核心、不可变的分类账。

该解决方案使用多代理架构,其中代理使用 代理到代理 (A2A) 协议进行通信。AP2 还支持 通用商业协议 (UCP)来执行事务。

授权分类账本服务充当保护中间件,将商家代理连接到数据库。使用 FastAPI 或 gRPC 构建此服务。

授权分类账本服务详细架构

图 5。任务分类帐本服务详细架构

通过三个独立的安全层处理所有代理请求:

  • 身份验证层:验证 API 密钥以安全识别代理。它通过代理类型应用基于角色的访问控制 (RBAC),以实施严格的代理权限。

  • 业务逻辑层:执行核心请求验证和并发控制。它实施幂等性以进行安全网络重试,并支持严格的授权不可变性。

  • 数据访问层:使用 MongoDB 客户端和优化索引来执行数据库操作。此层将 _id 字段定义为不可变的,并通过模式验证阻止所有更新和删除操作。

每个 AP2 事务都会通过一系列结构化的加密签名授权进行。每个步骤都会在 MongoDB Atlas 中产生一个不可变的记录,从意图到付款创建完整的 Atlas 审核追踪。

Dataflow

图 6. Dataflow

要将事务从意图转移到付款,AP2 代理将完成以下事务序列:

  1. 捕获客户的意图。购物代理将客户数的请求(例如“跑步鞋”的自然语言说明)转换为结构化的意图授权。意图授权捕获目标商家、可退款要求、购物车确认偏好和到期窗口。购物代理使用 EdDSA 代表客户签署授权,并以 signed 状态和锁定其内容的版本哈希将其发送给商家代理。

  2. 存储意向授权。商家代理通过授权分类帐本服务将意向授权写入 Atlas。分类帐本服务验证请求,应用 RBAC,并且不可变地添加记录。

  3. 创建购物车任务。商户代理构建购物车报价,其中包含完整的产品详细信息:商品名称、价格、货币、接受的付款方式和有效期。然后,商户代理通过 Mandate Ledger Service 将其存储在Atlas中,其中记录接收 proposed 状态和版本哈希以确保完整性。

  4. 向客户提供购物车。商家代理将提议的购物车授权返回给购物代理,购物代理将可用的产品选项呈现给客户。

  5. 接受购物车授权。客户选择一个选项。购物代理使用硬件支持的设备密钥代表客户共同签署购物车授权,并将接受的授权发送回商家代理。

  6. 会签并确定购物车授权。商家代理将其加密签名添加到已接受的购物车中,并将完全双签的购物车授权存储在 Atlas 中,以 signed 状态锁定已协定的术语。

  7. 创建付款授权。购物代理向凭证提供商查询以检索相应的付款令牌。购物代理会代客户创建并签署付款授权书,并将其发送给商家代理。凭证提供商从不返回完整的信用卡号码,这可确保购物代理不会访问原始数据。

  8. 存储付款授权书。商家代理通过授权书分类帐本服务将签署的付款授权书写入 Atlas。分类帐本服务将此授权书直接共享给金融机构,以标记 AI 代理的参与,付款处理器使用此授权书将授权路由到付款网络。

代理无法修改或删除现有记录。MongoDB Atlas 实施只附加写入,因此完整的授权链(意图、购物车和支付)在任何时候都会保持完整,并可由审计代理独立验证。

使用五个核心集合构建 MongoDB 数据库,以支持电商扩展:

  • mandate_ledger: 安全存储不可变的授权版本。

  • payments:存储超简付款完成记录。

  • api_keys:管理 API 密钥以安全识别代理。

  • audit_log: 维护完整的操作 Atlas 审核追踪。

  • idempotency_records: 缓存请求数据以去重复操作。

mandate_ledger 集合在单个集合中存储所有三种授权类型。使用 entity_type 字段在查询时区分它们,这样就无需每种授权类型进行连接或分离集合。

所有文档共享同一个常见的信封结构:

{
"entity_id": "IntentMandate_955181ea-11c3-4379-92c4-3e27c5f278d3",
"entity_type": "IntentMandate",
"version": 1,
"status": "signed",
"transaction_id": "txn_fca7db66-c769-4206-b891-7140af37f8f4",
"user_id": "hunter-d53910cf-b9e2-4876-8668-8251c990e203",
"created_by_agent": "merchant_agent_dev",
"created_by_agent_type": "merchant-agent",
"current_version_hash": "4a822a01468a27dfd...",
"signatures": [...],
"mandate_data": { ... }
}

mandate_data 字段携带类型特定的负载,其中每个授权类型都存储不同的数据结构:

IntentMandate 文档以结构化数据的形式捕获客户数的购买意图。此数据包括自然语言说明、目标商家、特定 SKUs、可退款要求和到期窗口:

IntentMandate document
"mandate_data": {
"natural_language_description": "cheapest french press coffee maker",
"merchants": [],
"skus": [],
"requires_refundability": true,
"user_cart_confirmation_required": true,
"intent_expiry": "2026-04-18T20:00:03.651746+00:00"
}

购物代理在将此文档发送给商家代理之前使用 EdDSA 对其进行签名。文档以 "status": "signed" 有效负载和锁定其内容的 current_version_hash 值进入分类帐。

CartMandate 文档包含完整的商业报价,包括带有价格和货币的行项、运费、税金、接受的付款方式和购物车过期窗口:

CartMandate 文档
"mandate_data": {
"contents": {
"payment_request": {
"method_data": [{ "supported_methods": "CARD", "data": { "network": ["mastercard", "paypal", "amex"] }}],
"details": {
"display_items": [
{ "label": "Standard Laptop", "amount": { "currency": "USD", "value": 1203.50 }, "refund_period": 30 },
{ "label": "Shipping", "amount": { "currency": "USD", "value": 2.00 }},
{ "label": "Tax", "amount": { "currency": "USD", "value": 1.50 }}
],
"total": { "label": "Total", "amount": { "currency": "USD", "value": 1203.50 }}
}
},
"shipping_address": { "recipient": "Bugs Bunny", "address_line": ["123 Main St"], "city": "Sample City", "country": "US" },
"cart_expiry": "2026-04-17T20:29:05.197984+00:00"
},
"merchant_authorization": "eyJhbGciOiJSUzI1NiIs..."
}

此文档以 "status": "proposed" 指定进入分类账本。当客户接受报价时,购物代理会共同签署。商家代理会向分类账本写入一个具有相同 transaction_id、增加的 version"status": "signed" 字段的新文档。在数组中包含两个签名使得约定的术语具有双边约束力:

"signatures": [
{ "signer_type": "shopping-agent", "algorithm": "EdDSA", "signed_at": "2026-04-17T19:59:49Z" },
{ "signer_type": "merchant-agent", "algorithm": "JWT", "signed_at": "2026-04-17T19:59:50Z" }
]

PaymentMandate 文档将已同意的购物车绑定到从凭证提供商检索的特定支付令牌,并包括付款人的运输和联系详细信息:

PaymentMandate 文档
"mandate_data": {
"payment_mandate_contents": {
"payment_details_total": { "label": "Total", "amount": { "currency": "USD", "value": 1203.50 }},
"payment_response": {
"method_name": "CARD",
"details": { "token": { "value": "fake_payment_credential_token_5" }},
"shipping_address": { "recipient": "Bugs Bunny", "address_line": ["123 Main St"], "city": "Sample City" },
"payer_email": "bugsbunny@gmail.com"
},
"merchant_agent": "Generic Merchant",
"timestamp": "2026-04-17T20:00:22.603453+00:00"
},
"user_authorization": "fake_cart_mandate_hash_cart_fb1b4c86..._fake_payment_mandate_hash_812843b2..."
}

user_authorization 哈希以密码方式将此 PaymentMandate 链接到已接受的 CartMandate,这可防止付款令牌在另一个事务中被重放。

transaction_identity_type 字段上创建索引,以在单个查询中检索任何事务的完整授权链。

payments 集合存储每个已完成事务的一个文档。此集合应用 扩展参考模式。

每个文档不会嵌入完整的授权内容,而是仅存储每个授权的授权 ID 和授权签名。这种设计可以使付款记录变得小而快速可读,同时在需要完整的 Atlas 审核追踪时,保留指向 mandate_ledger 集合中完整数据的直接指针。

{
"payment_id": "pay_123c25ac-7b56-4e45-8dd1-30cdcda944c7",
"transaction_id": "txn_6fbab918-2b5d-4ddd-89d8-fdb96e5648d9",
"user_id": "hunter-263b752e-92be-4001-ab9d-38847811c663",
"intent_mandate": { "mandate_id": "IntentMandate_41bbeacf-...", "signature": "0x_shopping_agent_sig_...", "timestamp": "2026-04-15T19:50:57Z" },
"cart_mandate": { "mandate_id": "CartMandate_c0e8f369-...", "signature": "eyJhbGciOiJSUzI1NiIs...", "timestamp": "2026-04-15T19:52:07Z" },
"payment_mandate": { "mandate_id": "PaymentMandate_33c39b8c-...", "signature": "fake_cart_mandate_hash_...", "timestamp": "2026-04-15T19:53:53Z" },
"amount": 28,
"currency": "USD",
"status": "SUCCESS",
"payment_method_type": "CARD",
"merchant_agent": "merchant_agent_dev",
"payment_processor_agent": "payment_processor",
"processed_at": "2026-04-15T19:54:14Z"
}

此设计有意使文档保持较小。完整的术语、行项和加密证明位于 mandate_ledger 集合中。付款记录仅用于确认事务已完成并提供重新构建完整 Atlas 审核链所需的三个指针。当需要完整追踪时,使用 transaction_id 字段在两个集合中进行连接。

api_keys 集合管理 API 密钥,以安全识别代理。使用此集合存储调用服务的每个代理相关的密钥。

audit_log 集合存储所有 API 操作,以便合规和调试。使用此集合记录服务级事件,例如授权创建、访问尝试和验证结果。此方法可防止扩展不可变的授权分类帐本本身。添加 TTL 索引,以在 90 天后自动删除记录。这可保留有用的操作追踪,同时使集合保持在界限内。

该集合包括以下关键字段:

  • event_type: 标识操作类型,例如 mandate.created

  • entity_id: 引用相关授权。

  • actor_agent_id: 捕获执行操作的代理。

  • event_timestamp: 记录事件发生的时间,并支持 TTL 策略。

  • expires_at: 定义 MongoDB 自动删除记录的时间。

idempotency_records 集合存储幂等密钥以防止重复操作。使用此集合保留客户端提供的密钥、发出请求的代理和为该操作创建的分类账本条目。添加 TTL 索引以在 24 小时后自动删除记录。

该集合包括以下关键字段:

  • idempotency_key: 存储客户端提供的唯一密钥,并要求索引。

  • agent_id: 标识发出请求的代理。

  • ledger_entry_id: 引用为原始请求创建的授权。

  • expires_at: 定义 MongoDB 自动删除记录的时间。

开始之前,请确保安装和配置以下内容:

  • MongoDB Atlas 或自管理 MongoDB 7.0 或更高版本

  • Python 3.13 (版本 3.13.x)

  • uv 用于依赖管理

  • Google API 密钥 或 Vertex AI 访问

  • Docker 将服务作为容器运行

  • Node.js 和 npm 用于前端应用程序

1
  1. 克隆 存储库 并安装授权分类帐服务:

    git clone https://github.com/mongodb-industry-solutions/retail-agent-shopping-ap2-ucp.git
    cd retail-agent-shopping-ap2-ucp/mandate_ledger_service
    python3.13 -m venv .venv
    source .venv/bin/activate
    pip install -e .
  2. mandate_ledger_service/ 目录中创建 .env 文件:

    MONGODB_URI= # Your connection string
    MONGODB_DATABASE=mandate_ledger
    SERVICE_NAME=mandate-ledger-service
    ENVIRONMENT=development
    # Bootstrap Auth (dev only — set to false after Step 2)
    BOOTSTRAP_ADMIN_KEY=**** # Generate: openssl rand -hex 32
    ENABLE_BOOTSTRAP_AUTH=true
    ALLOWED_CORS_ORIGINS=*
    DEFAULT_RATE_LIMIT_PER_MINUTE=60
  3. 启动服务:

    uvicorn src.main:app --reload --port 5000
  4. 运行使用 Docker 的服务:

    docker build -t mandate-ledger .
    docker run --rm \
    -p 5000:5000 \
    --env-file .env \
    mandate-ledger
2
  1. 打开一个新终端并运行:

    cd mandate_ledger_service
    source .venv/bin/activate
    PYTHONPATH=. python3 scripts/setup_agent_keys.py
  2. 从输出中复制 商家代理API密钥。在您的 .env 文件中设置 ENABLE_BOOTSTRAP_AUTH=false,并重新启动服务。

生产注意:使用 Google Secret 经理 或 AWS Secrets 经理 等密钥经理并实现密钥轮换。

3

/backend 服务与授权分类账服务交互,并将新授权推送到分类账中。此服务是使用 AP2 + A2A 示例从 Google 的 AP2 存储库 改编而来的。

  1. /backend中创建.env文件。将 MANDATE_LEDGER_API_KEY 设置为在步骤 2 中生成的 mlsk_merchant_key 值:

    GOOGLE_API_KEY=
    MANDATE_LEDGER_SERVICE_URL=http://localhost:5000
    MANDATE_LEDGER_API_KEY=
  2. 对于 Vertex AI,请将第一行更换为:

    GOOGLE_GENAI_USE_VERTEXAI=true
    GOOGLE_CLOUD_PROJECT=your-project-id
    GOOGLE_CLOUD_LOCATION=us-central1
  3. 构建并运行后端容器:

    docker build -f backend/Dockerfile -t retail-backend ./backend
    docker run --rm \
    -p 8000:8000 \
    -p 8001:8001 \
    -p 8002:8002 \
    -p 8003:8003 \
    -p 8004:8004 \
    --env-file backend/.env \
    retail-backend
  4. 后端 API 在 http://localhost:8000 上启动,并自动启动以下 AP2 代理:

    助手
    端口

    购物代理(集成到主后端)

    8000

    商家代理

    8001

    凭证提供商代理

    8002

    商家支付处理器代理

    8003

    审核代理

    8004

4

前端是与 /backend 服务交互的 Next.js 应用程序。

  1. 复制示例 .env 文件并设置后端和助手终结点:

    cd frontend
    cp EXAMPLE.env .env.local
  2. 使用您的值更新 frontend/.env.local

    MONGODB_URI=<your-mongodb-string>
    MONGODB_DATABASE=<your-database-name>
    NEXT_PUBLIC_BACKEND_ENDPOINT=http://localhost:8000
    ASSISTANT_ENDPOINT=http://localhost:3333
  3. 安装依赖项并运行前端:

    npm install
    npm run dev
  4. 要将前端作为容器运行,请使用根 Dockerfile。

在聊天用户界面中启用建议回复

聊天界面通过外部助理微服务生成建议回复。要启用此功能,请在开始演示之前设置并运行助理微服务。如果没有此服务,应用程序将加载,但不会生成建议回复。

5
  1. 在不同的终端中启动所有三个服务,然后在 http://localhost:8080 处打开应用。

  2. 后端 API 仍可在 http://localhost:8000 处获得。

  3. 有关导航应用程序的完整说明,请参阅用户指南

在代理商业中建立信任。通过将 AI 事务固定到客户数意图的确定性、不可抵赖的证明来克服信任危机:

  • 确保事务不可变性:在授权分类账本服务中实施只能添加规则,以创建防篡改的 Atlas 审核追踪。

  • 保留加密签名:使用 MongoDB document model 原生存储深度嵌套的 JSON 授权书,与代理生成的授权书完全一致。

  • 控制代理访问:实现基于角色的访问控制,以确保 AI 代理仅根据其特定角色执行经授权的操作。

  • 防止重复收费:在服务层中实施幂等性密钥,以安全处理网络重试,而不会对客户数重复收费。

  • Angelica Guemes, MongoDB

  • Florencia Arin, MongoDB

  • Sakshi Garg, MongoDB

  • Genevive Broadhead、MongoDB

  • Antonio Membrides, MongoDB

  • Daniel Jamir, MongoDB