Agent 支付协议详解：AP2、x402、授权与结算

Agent 支付是 AI Agent 参与商品发现、Checkout、授权、支付执行或售后处理的交易。难点不是教模型调用 Payment API，而是在多个可能超时、重试、结算、履约、退款或进入争议的系统之间，保存可验证的用户意图与有界权限。

两套新兴协议覆盖不同层次。AP2 v0.2 定义 Agent 执行 Checkout 与 Payment 所需的授权证据；x402 v2 定义 Payment Required 交换、验证与结算。生产 Commerce System 仍要负责身份、Catalog/Checkout 事实、Fraud Control、Accounting、Fulfillment、Refund、Privacy 与适用法律。

核心结论

• 分离 Shopping Intent、Checkout State、Payment Authorization、Settlement、Fulfillment 与 Reconciliation。
• 把 Agent 和所有使用 LLM 的 Role 都视为潜在攻击者，关键状态转换必须由确定性代码验证。
• AP2 Mandate 把授权证据绑定到 Checkout 与 Payment State。
• x402 传递 Payment Requirement 与 Payment Authorization，不提供 Client Budget Policy 或完整 Commerce Semantics。
• Human-not-present 支付需要事先签发、范围窄、会过期并绑定 Agent Key 的 Mandate。
• 金额使用整数 Minor/Atomic Unit，并带明确 Currency 或 Asset Identity。
• Timeout 会产生未知结果，重试前必须 Reconcile。

一笔交易包含多种事实

单个 paid=true 无法表达 Agent 购买。至少存在五类独立事实：

争议和会计系统需要关联全部事实。Checkout 过期后 Payment 仍可能完成；Checkout 已接受时 Settlement 仍可能 Pending；付费 API 也可能扣款后未返回资源。模型文字不是任何一层的 System of Record。

AP2 v0.2：授权证据

AP2 v0.2 描述五种 Role：Shopping Agent、Credential Provider、Merchant、Merchant Payment Processor 与 Trusted Surface。一个组织可以同时承担多个 Role，但必须承担每个 Role 的验证责任。

协议定义两类核心 Mandate：

• Checkout Mandate：证明 Shopping Agent 被授权接受某个具体 Checkout。
• Payment Mandate：证明被授权为该 Checkout 付款。

Merchant 会签名 Checkout State。Payment Mandate 通过 Checkout Hash 与之绑定，Receipt 则回链被接受或拒绝的 Mandate。即使某个 Role 使用了 Agent，验证也必须由确定性代码执行。

AP2 区分两种模式：

• Human present：用户审阅并签名 Closed Checkout 与 Payment。
• Human not present：用户先签名 Open Constraint；Agent Key 后续只能签署满足这些约束的 Closed Transaction。

自主模式需要在授权中包含 Agent Public Key Confirmation，并使用尽可能短的 Expiry。Verifier 会让 Closed Transaction 与已披露约束匹配。AP2 v0.2 只说明 Agent-to-Agent Delegation 在概念上可行，但明确把它放在当前规范范围外，因此不能声称 AP2 已提供通用 Sub-delegation。

AP2 是 Commerce Protocol 内的一项安全能力。Catalog Search、Checkout Update、Inventory、Tax、Order API、Fulfillment 与 Refund 都不属于其核心范围。UCP 文档展示了 Checkout State 与 AP2 Mandate 的一种集成方式。

x402 v2：付款要求与结算

x402 v2 定义付费资源的 Transport-independent Type 与 Logic。常见 HTTP 流程是：

1. Client 请求资源；
2. Server 返回 Payment Required 与可接受的 Payment Requirement；
3. Client 签名或取得 Payment Authorization；
4. Server 或 Facilitator 验证；
5. 完成 Settlement；
6. Server 返回资源与 Settlement Response。

核心 Role 是 Client、Resource Server 和可选 Facilitator。v2 分离三层：

• Types：Payment Requirement、Payload、Verify 与 Settlement Response。
• Logic：特定 Scheme/Network 的构造、验证与结算。
• Representation：HTTP、MCP、A2A 或其他协议的 Transport Binding。

x402 明确把 Client-side Budget Management 与 Session Handling 留在 Core Specification 之外。它也不能证明资源有价值、价格正确、交易合法或已经履约。Agent 应用仍需要独立 Purchase Policy。

AP2 与 x402 如何组合

只有保持各层语义，AP2 与 x402 才真正互补：

一种有效架构可以用 AP2 Mandate 证明“授权购买了什么”，再用 x402 传输和结算某种支持的 Payment Method。但这不是自动互操作，必须固定双方版本、定义 Mapping 并覆盖全部失败状态。外围流程若使用 OAuth，还需把委托访问与 Payment Authorization 分开治理。

设计授权信封

自主支付 Policy 应比“Agent 可以花 500 元”更精确：

• Principal 与 Organization；
• Agent Definition 与 Public Key；
• Merchant 或允许的 Merchant Category；
• Product、Quantity、Substitution 与 Delivery Constraint；
• 精确 Currency/Asset 与 Maximum Amount；
• Tax、Fee 与 Exchange Rate 处理；
• Start、Expiry、Recurrence 与 Maximum Uses；
• Geography、Legal 与 Data Processing 限制；
• 是否必须让人审阅 Final Checkout；
• Revocation 与 Exception 行为。

最终 Verifier 必须比较 Canonical Checkout，不能比较模型摘要。Payee、Amount、Item、Quantity、Destination、Currency、Mandate Version 或重要条款改变，都要触发新决策。

Agent 身份与委托授权解释 Principal 与 Actor Identity 如何跨调用链保留；Approval Gate词条说明动作绑定决策与 Replay Protection。

校验金额并绑定 Checkout

金额不能使用浮点数。应保留精确整数 Minor/Atomic Unit，并记录 Currency 或 Asset Identity。应用 Policy 判断前，必须使用协议支持的 Library 完成签名验证。

下面的 Go 示例在密码学验证之后，检查简化 Mandate，并绑定 Agent、Payee、Amount、Currency、Checkout Hash、Operation 与 Expiry。

package main

import (
	"errors"
	"fmt"
	"math/big"
	"time"
)

type Mandate struct {
	AgentID      string
	Payee        string
	Amount       string
	Currency     string
	CheckoutHash string
	OperationID  string
	ExpiresAt    time.Time
}

type Charge struct {
	AgentID      string
	Payee        string
	Amount       string
	Currency     string
	CheckoutHash string
	OperationID  string
}

func validate(m Mandate, c Charge, now time.Time) error {
	if !now.Before(m.ExpiresAt) {
		return errors.New("mandate expired")
	}
	if m.AgentID != c.AgentID || m.Payee != c.Payee ||
		m.Currency != c.Currency || m.CheckoutHash != c.CheckoutHash ||
		m.OperationID != c.OperationID {
		return errors.New("mandate binding mismatch")
	}
	authorized, ok := new(big.Int).SetString(m.Amount, 10)
	if !ok || authorized.Sign() < 0 {
		return errors.New("invalid mandate amount")
	}
	requested, ok := new(big.Int).SetString(c.Amount, 10)
	if !ok || requested.Sign() < 0 || requested.Cmp(authorized) > 0 {
		return errors.New("amount exceeds mandate")
	}
	return nil
}

func main() {
	now := time.Unix(1_800_000_000, 0)
	mandate := Mandate{
		AgentID: "shopping-agent-7", Payee: "merchant-42",
		Amount: "2500", Currency: "USD-cent",
		CheckoutHash: "sha256:abc", OperationID: "purchase-123",
		ExpiresAt: now.Add(time.Minute),
	}
	charge := Charge{
		AgentID: "shopping-agent-7", Payee: "merchant-42",
		Amount: "2499", Currency: "USD-cent",
		CheckoutHash: "sha256:abc", OperationID: "purchase-123",
	}
	fmt.Println(validate(mandate, charge, now))
}

预期输出：

<nil>

生产校验还包括 Issuer、Signature Algorithm、Key Status、Mandate Type/Version、Nonce、Selective Disclosure Proof、Agent Key Binding、Merchant Checkout Signature、Tax/Fee Rule、Fraud Decision、Use Count 与原子消费。

幂等与未知结果

支付系统可能在任何两步之间失败。Dispatch 后 Timeout 不等于扣款失败。所有重试都应沿用稳定 Operation Identity：

created -> authorized -> submitted -> settled
        -> rejected
        -> outcome_unknown -> reconciled_settled
                           -> reconciled_not_settled
        -> fulfilled -> refunded

重试前依次：

1. 按 Operation ID 查询 Merchant Order；
2. 按 Payment Identity 查询 Processor 或 Facilitator；
3. 必要时查询 Payment Network；
4. 比较 Amount、Payee、Checkout Hash 与 Status；
5. 只根据权威证据继续履约、退款或重试。

Agent 不能把“没有响应”推断成“换一个 Nonce 再试”。在底层系统支持的范围内，让 Settlement 与 Fulfillment 都具备幂等语义；无法确认的状态要进入人工运营流程。

威胁模型与隐私

AP2 安全说明明确把 LLM 与 Agent 都当作潜在攻击者。重要攻击包括 Manipulated Checkout、Manipulated Payment、Payment Credential Theft、Malicious Discovery，以及同一 Open Mandate 被多个重叠交易使用。

关键控制包括：

• 把 Payment Authorization 绑定到准确的 Signed Checkout；
• 把自主 Mandate 绑定 Agent Key；
• 用确定性代码验证全部 Constraint；
• 阻止重叠使用，或执行一次性消费；
• 最终校验通过后才释放 Payment Credential；
• 使用带 Salt 的 Selective Disclosure；
• 每个 Role 只共享必要字段；
• 不把 Prompt、推荐文字或 Agent Reasoning 当作支付事实。

还要测试 Currency Confusion、Unicode Merchant Name、Decimal Conversion、过期汇率、Redirect Substitution、Timeout 后 Replay、Partial Settlement、重复履约、Refund Race 与恶意 Discovery Data。

评测完整购买流程

不能只看 Payment Success：

• Authorized Checkout Acceptance Rate；
• 未授权或超预算尝试率；
• Mandate Verify 与 False Rejection；
• Duplicate Charge 与 Duplicate Fulfillment；
• outcome_unknown 比例和 Reconciliation Time；
• Settlement/Fulfillment 不一致；
• Refund Completion 与 Dispute Evidence Retrieval；
• 用户确认率与 Consent Abandonment；
• 单次正确履约的总成本。

模型找到了更便宜商品，但违反数量、交付、隐私或商户限制，仍然是失败。支付协议不能替代任务评测。

常见问题

HTTP 402 本身就是支付协议吗？

不是，它只是 HTTP Status Code。x402 围绕 Payment Required 交换定义 Message Type、Payment Scheme、Verification、Settlement 与 Transport Representation。其他 402 方案可能使用完全不同的 Header、Payload、Network 与 Trust Model。

AP2 必须使用区块链支付吗？

不是。AP2 与 Payment Method 无关，重点是授权证据。x402 v2 当前描述了具体 Scheme 与 Network，但这不意味着 AP2 只能使用这些方式。

模型可以创建或验证 Payment Mandate 吗？

模型可以辅助组装 Candidate Data，但 Signature Verification、Constraint Evaluation、Amount Comparison、Key Binding 和状态转换必须在 LLM 之外的确定性代码中执行。

Agent 买错东西后由谁负责？

Protocol Receipt 可以改善证据，但法律与合同责任取决于参与方、法域、Payment Method、Service Terms 与事实，不能把统一责任结论写进应用逻辑。

开放自主支付前必须测试什么？

覆盖 Checkout 被修改、Mandate 过期或撤销、Agent Key 错误、Payee/Currency 错误、超预算、Replay、并发使用、Settlement 后 Timeout、重复 Fulfillment、Refund、Dispute、恶意 Discovery 与人工升级不可用。

参考资料

• AP2 v0.2 规范
• AP2 安全与隐私
• UCP 与 AP2 集成
• x402 Protocol Specification v2
• A2A Protocol 指南
• AI Agent Tool 安全指南