如何为 AI 智能体设置消费上限（MCP、卡、钱包逐字段说明）
简答：为 AI 智能体（AI agent）设置消费上限，本质上要按顺序做三个决定：（1）上限到底落在哪一层——卡网络、链上钱包、服务商的 API/CLI，还是位于智能体调用的 MCP 工具之前的策略层；（2）它是单笔交易上限、滚动周期总额（按日/周/月），还是两者都要，因为大多数同时支持两者的服务商还会在二者之间强制一条排序规则；（3）超限之后会发生什么——在授权环节直接硬性拒绝，还是转交人工审批。下面列出了每家服务商为此记录的具体字段或参数，包括其单位和实际生效环节，以及配置中最容易出错的地方。
最后更新：2026-09-30。以下事实来自 Agent Spending Controls Crosswalk（CC BY 4.0）——一份我们发布并不断对照各服务商官方文档重新核实的 43 行数据集。本文中的每个证据链接均在 2026-09-30 重新抓取，每条引用均经过机械核对——参见文末链接的核查文件。
第一步：选择上限的生效层级
"消费上限"根据所用支付轨道（rail）的不同，会在不同层级被检查：
- 卡网络，在授权环节。 Stripe Issuing、Privacy.com、Lithic 和 AgentCard 发放的虚拟卡，其上限由卡网络在结算前检查——交易本身不会真正转移资金。它只覆盖卡轨道上的消费：持有独立钱包密钥的智能体不受卡上限约束。Crossmint 的文档明确划出了这条界线："Card limits hold at Visa and Mastercard, wallet limits hold onchain"（卡的限额在 Visa 和 Mastercard 生效，钱包的限额在链上生效）（docs.crossmint.com/agents/overview，访问于 2026-09-30）。
- 链上，通过预编译合约（precompile）。 Tempo 的 Account Keychain 在协议层通过
KeyRestrictions/TokenLimit结构体，对每个密钥执行代币消费上限（tempo.xyz，访问于 2026-09-30）——这是最难绕过的一层，但只作用于该密钥所覆盖的链/代币。 - 服务商 API 或 CLI，服务端。 AP2 的
BudgetEvaluator、Circle 的 agent-wallet CLI，以及 Payman 的仪表盘策略，都在服务商后端检查上限。这一层灵活，但可靠性完全取决于该后端本身——评估器（evaluator）的 bug 可能导致检查悄悄没有执行（参见下文的 AP2 坑点）。 - MCP 工具层，位于执行之前。 在"智能体决定付款"和"调用真正发出"之间插入一次策略检查，与底层轨道无关。Coinbase 的 CDP Agentic Wallet MCP 集成在其钱包 UI 中设置单次调用和单个会话的上限，其 FAQ 指出："Agents respect these limits but can't change them"（智能体会遵守这些限制，但无法修改它们）（docs.cdp.coinbase.com，访问于 2026-09-30）。
这四层没有哪一层绝对更优——它们阻止的是不同的失效模式。实际做法通常是至少叠加两层：以卡或链上的硬性上限作为底线，再叠加一层策略层负责白名单和审批路由。
第二步：设置上限——各服务商的具体字段
这是大多数指南会跳过的部分。以下是各服务商在自家官网记录的具体字段或参数。
| 服务商 | 单笔交易字段 | 周期字段（周期选项） | 单位 | 生效位置 |
|---|---|---|---|---|
| Stripe Issuing | spending_controls[spending_limits][0][interval]=per_authorization |
spending_controls.spending_limits[].amount + .interval（per_authorization 加上基于日期的周期） |
卡币种的最小货币单位 | 卡网络，在授权环节 |
| Privacy.com | spend_limit 配合 spend_limit_duration=TRANSACTION |
spend_limit + spend_limit_duration（ANNUALLY、FOREVER、MONTHLY、TRANSACTION） |
分（cents） | 卡网络，在授权环节 |
| Lithic（卡） | ——（spend_limit_duration=TRANSACTION 是最接近的单笔等价项） |
spend_limit + spend_limit_duration（ANNUALLY、FOREVER、MONTHLY、TRANSACTION） |
分（行业惯例；该页面未重新说明） | 卡网络，在授权环节 |
| Lithic（账户） | —— | 账户级上限（按日、按月、终身） | 该摘录中未说明 | 卡网络，在授权环节 |
| Lithic（Velocity Limit 规则） | —— | limit_amount（周期内最大总消费；另有 limit_count 用于限制交易笔数），作用范围为 CARD 或 ACCOUNT |
分 | 卡网络，在授权环节（Lithic 托管的 Auth Rules 引擎） |
| AgentCard | —— | cards set-limit CLI 命令设置多次使用卡的总限额 |
分 | 服务商 API |
| Coinbase CDP（Agentic Wallet MCP） | "Max per call"（钱包 UI；未记录对应的 API 字段名） | "Max per session"（钱包 UI） | 未说明（文档示例为 0.05 美元/5.00 美元） | MCP/钱包 UI 策略 |
| Circle（Agent Wallets CLI） | 无独立的单笔字段；--daily 是最短的层级 |
--daily / --weekly / --monthly（circle wallet limit set） |
USDC（主单位） | 服务商 CLI，Circle 的钱包后端 |
Tempo（--max-spend CLI 参数） |
--max-spend（每次请求） |
——（在此层仅有单次请求上限） | 未说明（示例以美元表示） | 客户端 CLI |
| Tempo（Account Keychain，协议层） | TokenLimit.amount 配合 period=0 |
TokenLimit.amount 配合以秒为单位的 period（周期性） |
TIP20 代币单位 | 链上，通过 Account Keychain 预编译合约 |
| Payman（Dashboard Policies） | "Per Transaction"——"Maximum amount allowed per single payment"（单笔付款允许的最大金额） | "Daily Limit" / "Monthly Limit" | 未说明（文档中不区分具体币种） | Payman 的策略引擎（"financial firewall"，金融防火墙） |
| Skyfire（KYA-PAY token） | amt claim——"JSON string representing token amount in currency units"（表示以货币单位计的代币金额的 JSON 字符串） |
——（仅有单次代币上限；pay_per_use 下的 mnr 限制的是请求次数而非金额） |
货币单位（非最小单位） | API 服务端，由卖方服务在结算前校验 |
| AP2（Agent Payments Protocol） | amount_range.max——"Maximum allowed amount in minor (cents) unit of currency"（以货币最小单位——分——表示的最大允许金额） |
budget.max——"Maximum amount for the budget"（预算的最大金额） |
amount_range.max：最小单位（分）。budget.max：主单位——参考 SDK 中的 BudgetEvaluator 会在内部将其乘以 100 |
API 服务端（参考 SDK 中的 BudgetEvaluator/AmountRangeEvaluator） |
x402（upto scheme） |
PaymentRequirements 中的 amount——针对计量请求的客户端授权上限 |
——（单次请求上限；未记录滚动周期字段） | 规范文件中未说明 | API 服务端，由 facilitator 在结算时执行 |
有两行刻意没有列出具体字段名：Visa Intelligent Commerce 和 Mastercard Agent Pay 都用营销性语言描述消费上限（"agent permissions and spending limits are defined upfront to bound authority"（智能体权限和消费上限需预先设定以约束其权力）——Mastercard，Wayback 快照，2026-09-18），截至 2026-09-30，均未公开指明具体参数名的 API 参考文档。
在把上面任何内容抄进代码之前，有一个坑值得特别提醒：AP2 的 budget.max 和 amount_range.max 单位并不一致，尽管它们位于同一个 mandate（授权凭证）schema 里。amount_range.max 的 schema 文本直接写明"minor (cents) unit of currency"（货币最小单位——分）；budget.max 的 schema 文本完全没有说明单位，而参考 SDK 的计算方式是 budget_max_cents = int(self.constraint.max * 100)——也就是说 budget.max 必须以主单位填写，恰好与其同级字段的名字所暗示的相反。这是一个已被记录、尚未解决的不一致——参见我们的 AP2 授权凭证坑点一文。
Circle 的排序规则值得直接引用："limits must be monotonic: per-tx ≤ daily ≤ weekly ≤ monthly"（限额必须单调：单笔 ≤ 每日 ≤ 每周 ≤ 每月）（Circle agent-wallet-policy skill，访问于 2026-09-30）——CLI 会拒绝将单笔上限设得高于每日上限。
第三步：加上审批与白名单
硬性上限回答的是"多少"——而不是"谁"或"临界点上会发生什么"。有三家服务商同时记录了这两者：
- Circle 要求人工输入一次性验证码才能上调或重置限额："Setting or resetting limits requires OTP confirmation in an interactive terminal session"（设置或重置限额需要在交互式终端会话中进行 OTP 确认）——智能体本身永远看不到这个验证码。它还记录了收款方白名单和合约黑名单："Set transfer limits, recipient allowlists, and contract blocklists per agent wallet"（为每个智能体钱包设置转账限额、收款方白名单和合约黑名单）（developers.circle.com/agent-stack/agent-wallets，访问于 2026-09-30）。
- Payman 记录了一个独立于日/月上限之外的"Threshold"（审批阈值）控制项："Amount above which manual approval is needed"（超过此金额需要人工审批）（Payman Dashboard Policies，Wayback 快照，2025-11-18）——超出阈值的付款会被转交人工，而不是直接拒绝。
- AP2 把审批内建进了协议本身：用户的"approval signs a Cart Mandate. This is a critical step that creates a secure, unchangeable record of the exact items and price"（批准会签署一份购物车授权凭证（Cart Mandate）。这是关键的一步，它会创建一份关于具体商品和价格的、安全且不可篡改的记录）（Google Cloud，AP2 发布文章，访问于 2026-09-30）。
商户/类别白名单在卡端也有体现：Privacy.com 的卡片 type 枚举包含 MERCHANT_LOCKED 和 SINGLE_USE；Lithic 的 Authorization Rules 包含 MERCHANT_LOCK 规则类型，以及基于商户类别代码（MCC）的 CONDITIONAL_ACTION 规则——"by defining rules based on high-signal attributes like MCC, country, currency, and risk score, you can enforce business-specific authorization logic"（通过基于 MCC、国家、币种和风险评分等高信号属性定义规则，可以执行针对具体业务的授权逻辑）（docs.lithic.com/docs/authorization-rules-v2，访问于 2026-09-30）。Stripe Issuing 把同样的能力体现为 allowed_categories/blocked_categories。
这一切都有一个局限：白名单或审批规则的有效性完全取决于评估它的那一层是否真的在运行。AP2 的参考 SDK 只会对调用方提交的数组中实际存在的约束进行评估——一个被省略的约束不会产生任何违规提示，因为根本没有评估器去检查它。要确认约束在每一次调用中都真正被发送，而不是只在上游配置过一次就以为万事大吉。
第四步：先测试上限，再信任它
无论用的是哪家服务商，在把智能体真正接到实际上限之前，都值得做两项检查：
- 发送一笔略高于上限的交易，确认它被拒绝，而不仅仅是被记录下来。 卡网络和链上执行（Stripe、Privacy.com、Lithic、Tempo 的 Account Keychain）会直接拒绝授权本身。服务商 API 层的执行（AP2、Circle、Payman）则取决于该后端是否在你的智能体实际调用的那条代码路径上真正运行了检查——仪表盘里设置的上限，如果 API 调用绕过了那个策略引擎，是不会起作用的。
- 确认你填的数字对应的到底是哪个单位。 AP2 是有据可查的案例：
amount_range.max是最小单位（分），但budget.max是主单位，评估器会在内部乘以 100——如果把budget.max当成和amount_range.max一样的单位来设置，实际生效的上限会高出 100 倍。要看字段自身文档说明的单位，不要假设它和名字相近的同级字段一致。
当滚动周期上限和单笔上限同时存在时（Circle、Stripe、Privacy.com、Lithic），要测试边界情况：一笔金额恰好等于单笔上限的交易，发生在当日滚动总额已接近日/月上限的那一天——差一错误（off-by-one）或未强制执行的排序规则往往就在这里暴露出来。
坑点
- 在营销层面上，"未记录"很常见。 Coinbase CDP 的 TEE/enclave 执行声明、Visa Intelligent Commerce 和 Mastercard Agent Pay 都只是用文字描述消费上限，没有公开的字段级 schema。博客文章提到"消费上限"，并不等同于 API 参考文档里写明了具体参数。
- x402 的
amount字段在uptoscheme 中是阶段相关的。 同一个 JSON 字段在验证阶段表示"客户端授权的上限"，在结算阶段表示"实际收取的金额"——"the settled amount MUST be less than or equal to the authorized maximum"（结算金额必须小于或等于已授权的上限）（x402uptoscheme 规范，访问于 2026-09-30）。 - x402 的
maxAmountRequired（exactscheme）是资源服务器设定的价格，而不是付款方一侧的预算——交易金额必须等于这个精确值。付款方一侧的上限必须放在客户端或钱包里，而不是这个字段。 - AP2 的单位不一致是一个持续存在、尚未解决的问题，而不是偶发情况——参见第二步和该数据集中的"坑点"部分。
- Circle 的 OTP 要求是刻意把智能体排除在外，而不是 bug：上调限额需要人工在交互式终端上操作，目的就是让智能体无法自行上调自己的上限。
以上内容覆盖的是各服务商在自家参考文档中记录的上限、白名单和审批机制——而不是一个智能体在跨服务商层面总共能花多少钱，那是高于任何单一供应商 API 之上的策略问题。关于这一层，参见我们的消费管控指南和策略模板。
Pink Agentic AI Payments（PinkWallet 出品，早期访问）是 AI 智能体与公司资金之间的审批层：由自然语言规则、每个智能体的预算和人工审批来决定每一笔付款，之后才会签发一次性卡或银行转账。
FAQ
如何为通过 MCP 付款的 AI 智能体设置单智能体消费上限？
不存在统一的 MCP 标准字段——每个接入 MCP 的服务商都记录自己的字段。Coinbase 的 CDP Agentic Wallet MCP 集成在其钱包 UI 中设置了"Max per call"和"Max per session"上限，其文档指出智能体"can't change them"（无法修改它们）。Stripe Issuing、Privacy.com 和 Lithic 也可以接在 MCP 工具之后，但上限本身存在于它们的卡 API 中（spending_controls、spend_limit）——MCP 只是调用接口。
如何给 AI 智能体一个属于它自己的钱包和消费上限？
有三种有据可查的模式：Coinbase 的 CDP Agentic Wallet 为智能体提供一个专属钱包，通过 UI 配置单次调用/单个会话上限。Circle 的 Agent Wallets CLI 通过 circle wallet limit set 发放带有 --daily/--weekly/--monthly USDC 限额的钱包，并强制单调排序规则和修改限额所需的 OTP 验证。Tempo 的 Account Keychain 通过一个作用于智能体访问密钥的 TokenLimit 结构体，在协议层、链上执行限额。
哪些支付 MCP 服务器内置了消费管控功能？ Coinbase 的 CDP Agentic Wallet 直接记录了 MCP 专属的单次调用和单个会话上限。Stripe Issuing、Privacy.com 和 Lithic 记录了坐落在其既有卡级控制之前的 MCP 服务器或 MCP 兼容集成——控制本身位于卡 API 层，MCP 只是调用接口。截至 2026-09-30，我们没有找到任何一个独立于底层卡或钱包 API、纯粹在 MCP 协议层执行上限的服务器。
这些上限是能真正阻止超支，还是只是事后提醒？ 卡网络或链上执行（Stripe、Privacy.com、Lithic、AgentCard、Tempo）会在授权前拒绝交易——这是硬性阻止。服务商 API 或钱包 UI 层的执行（AP2、Circle、Payman、Coinbase CDP）的可靠性完全取决于该具体代码路径是否正是你的智能体所调用的那一条——应直接测试（第四步），不要假设仪表盘里的设置在所有地方都会生效。
延伸阅读
- Agent Spending Controls Crosswalk——本文背后完整的 43 行数据集，CC BY 4.0
- /agentic/learn/ai-agent-spending-controls/——把上限、白名单和审批阈值设计为一个策略层
- /agentic/learn/spending-controls-for-ai-agents/
- /zh/agentic/learn/payment-mcp-servers-compared/
- /agentic/learn/how-ai-agents-pay-through-mcp/
- /agentic/learn/ai-agent-wallet/
- /agentic/learn/virtual-cards-for-ai-agents/
- /agentic/learn/ap2-mandate-gotchas/
- /zh/agentic/learn/ai-agent-spending-policy-template/
本文由 PinkWallet 发布，我们正在打造 Pink Agentic AI Payments（早期访问）。我们在这个领域并不中立，这正是本文每一条事实性陈述都链接到原始来源的原因。
