学习如何在 MongoDB Atlas 上构建不可变的授权分类帐本,为代理商业创建信任层,并为问责制提供 ACID 一致性保证。
行业: 零售
产品: MongoDB Atlas
合作伙伴: Google Cloud
解决方案概述
AI 代理通过自动管理从产品发现到最终结账的任务,从而改变了数字商业。然而,当 AI 代理代客户发起支付时,它会打破传统商业的核心假设,并创造信任危机。
现有的支付系统无法验证代理的权限、验证客户的真实意图或定义清晰的事务问责制。这会产生主要挑战:
授权:验证客户数是否授权代理进行特定采购。
真实性:验证代理的请求准确反映客户的真实意图,没有错误或幻觉。
责任:确定事务失败时的责任方 — 客户数、代理的开发者、商户还是发卡机构。
解决这些挑战需要所有参与者(包括客户、商家和金融机构)都可以信任的共享标准。
与 AP2 建立信任
Google 的 代理支付协议 (AP2) 提供一个开放、安全和可互操作的协议,为商家、金融机构和日常客户构建可信的生态系统。
图 1。信任层
AP2 通过可验证数字凭证 (VDC)——代理创建和交换的防篡改、经过密码签名的 JSON 负载来确保事务安全。AP2 将这些 VDC 分为三个核心任务:
意图授权:概述客户的要求,并定义 AI 代理可以代表客户进行采购的条件。
购物车授权:提供由商家和客户数签名的数字收据,以授权人工存在购买。
付款授权:创建与支付网络直接共享的可见性层,以安全地指示 AI 代理的参与。
VDC 充当永久数字合同。代理使用密码签名这些负载以捕获客户数意图。此过程为购物体验的每个步骤创建不可抵赖的 Atlas 审核追踪。
图 2。每个步骤都有可验证的证明的合同对话
图 3。用户界面中的意图可视化,展示每个意图在对话中的表示方式
借助 MongoDB Atlas 确保责任制
为了使这些加密 VDC 保持可信,系统必须将其存储在安全、可验证的环境中。Mandate Ledger Service 充当AI代理和数据库之间的保护性中间件。这个中间件的背后是MongoDB Atlas。
Atlas 提供企业级安全,支持防篡改的 Atlas 审核追踪。构建此架构以创建不可变的信任层,即授权分类账本服务,以扩展安全的代理商业。
设想一位客户数请求 AI 助手购买新智能手机。购物代理自主与商家协商,以找到最优惠的交易。授权分类帐本服务通过将每个请求、批准和结账步骤打包成经密码签名的 JSON 授权,记录整个过程。MongoDB Atlas 将每个授权存储为不可变的文档。此过程将简单的聊天转变为永久的、不可抵赖的意图证明。
此解决方案展示了如何在使用 AP2 协议的架构上构建 Mandate Ledger Service。
参考架构
AP2 使用基于角色的架构,旨在提供安全和清晰的事务责任制。此生态系统中的每个参与者都承担着不同的责任,以简化集成并保护客户数隐私。
图 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 审核追踪。
图 6. Dataflow
要将事务从意图转移到付款,AP2 代理将完成以下事务序列:
捕获客户的意图。购物代理将客户数的请求(例如“跑步鞋”的自然语言说明)转换为结构化的意图授权。意图授权捕获目标商家、可退款要求、购物车确认偏好和到期窗口。购物代理使用 EdDSA 代表客户签署授权,并以
signed状态和锁定其内容的版本哈希将其发送给商家代理。存储意向授权。商家代理通过授权分类帐本服务将意向授权写入 Atlas。分类帐本服务验证请求,应用 RBAC,并且不可变地添加记录。
创建购物车任务。商户代理构建购物车报价,其中包含完整的产品详细信息:商品名称、价格、货币、接受的付款方式和有效期。然后,商户代理通过 Mandate Ledger Service 将其存储在Atlas中,其中记录接收
proposed状态和版本哈希以确保完整性。向客户提供购物车。商家代理将提议的购物车授权返回给购物代理,购物代理将可用的产品选项呈现给客户。
接受购物车授权。客户选择一个选项。购物代理使用硬件支持的设备密钥代表客户共同签署购物车授权,并将接受的授权发送回商家代理。
会签并确定购物车授权。商家代理将其加密签名添加到已接受的购物车中,并将完全双签的购物车授权存储在 Atlas 中,以
signed状态锁定已协定的术语。创建付款授权。购物代理向凭证提供商查询以检索相应的付款令牌。购物代理会代客户创建并签署付款授权书,并将其发送给商家代理。凭证提供商从不返回完整的信用卡号码,这可确保购物代理不会访问原始数据。
存储付款授权书。商家代理通过授权书分类帐本服务将签署的付款授权书写入 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
IntentMandate 文档以结构化数据的形式捕获客户数的购买意图。此数据包括自然语言说明、目标商家、特定 SKUs、可退款要求和到期窗口:
"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_id 和 entity_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 密钥:安全代理身份识别
api_keys 集合管理 API 密钥,以安全识别代理。使用此集合存储调用服务的每个代理相关的密钥。
Atlas 审核日志:操作轨迹
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 用于前端应用程序
步骤
安装分类帐本服务
克隆 存储库 并安装授权分类帐服务:
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 . 在
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 启动服务:
uvicorn src.main:app --reload --port 5000 运行使用 Docker 的服务:
docker build -t mandate-ledger . docker run --rm \ -p 5000:5000 \ --env-file .env \ mandate-ledger
配置后端
/backend 服务与授权分类账服务交互,并将新授权推送到分类账中。此服务是使用 AP2 + A2A 示例从 Google 的 AP2 存储库 改编而来的。
在
/backend中创建.env文件。将MANDATE_LEDGER_API_KEY设置为在步骤 2 中生成的mlsk_merchant_key值:GOOGLE_API_KEY= MANDATE_LEDGER_SERVICE_URL=http://localhost:5000 MANDATE_LEDGER_API_KEY= 对于 Vertex AI,请将第一行更换为:
GOOGLE_GENAI_USE_VERTEXAI=true GOOGLE_CLOUD_PROJECT=your-project-id GOOGLE_CLOUD_LOCATION=us-central1 构建并运行后端容器:
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 后端 API 在 http://localhost:8000 上启动,并自动启动以下 AP2 代理:
助手端口购物代理(集成到主后端)
8000
商家代理
8001
凭证提供商代理
8002
商家支付处理器代理
8003
审核代理
8004
配置前端
前端是与 /backend 服务交互的 Next.js 应用程序。
复制示例
.env文件并设置后端和助手终结点:cd frontend cp EXAMPLE.env .env.local 使用您的值更新
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 安装依赖项并运行前端:
npm install npm run dev 要将前端作为容器运行,请使用根 Dockerfile。
在聊天用户界面中启用建议回复
聊天界面通过外部助理微服务生成建议回复。要启用此功能,请在开始演示之前设置并运行助理微服务。如果没有此服务,应用程序将加载,但不会生成建议回复。
运行演示
在不同的终端中启动所有三个服务,然后在 http://localhost:8080 处打开应用。
后端 API 仍可在 http://localhost:8000 处获得。
有关导航应用程序的完整说明,请参阅用户指南。
关键要点
在代理商业中建立信任。通过将 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