如何用 Pink 给 AI 智能体配一个专属钱包和消费限额

要给一个 AI 智能体配上它自己的"钱包"和消费限额,做法是在 Pink 智能体支付(Pink Agentic AI Payments)里为它创建一个智能体:每个智能体拥有自己的密钥、自己的资金库(vault)余额、一个月度预算、一个单笔付款上限,以及一套在发出任何凭证之前就会先检查每一笔付款的规则。智能体只负责提出请求;真正决定一笔付款是放行、转人工,还是拦截的,是 Pink 的服务器,而不是智能体自己。

构成智能体"钱包"的三个对象

Pink 并没有用"钱包"这个词来指代某一个单一对象;一个智能体的支付身份其实由三个相互关联的部分组成,每一部分都有自己真实的字段(已对照实时沙盒及其 OpenAPI 规范确认):

对象 存放的内容 关键字段
智能体(Agent) MCP/REST 调用所认证的身份 id、name、department、status(active/paused),以及它自己的 vault
预算(Budget) 绑定在这个智能体上的金额限制 monthly_budget、spent_this_month、left_this_month、single_payment_cap、company_daily_ceiling、company_spent_today
资金库(Vault) 这个智能体实际支取资金的来源 id、name、purpose、balances(币种到金额的映射)

用那个智能体的密钥调用 GET /v1/budget,会在一次响应里返回以上全部内容,包括资金库的当前余额。一个资金库可以被多个智能体的规则共用,但每个智能体自己的预算和上限是分别独立追踪的。

第一步:创建智能体和它的资金库

在沙盒里,POST /v1/sandbox/workspaces 会根据一个模板(coffee、startup 或 ecommerce)为工作区预置一家公司、一组智能体、一批收款方,以及一套起步规则。在生产环境里,管理员在控制台中创建智能体、为它指派资金库、并发出它的密钥;智能体密钥是智能体侧代码唯一持有的凭证,它无法读取别的智能体的资金库,也拿不到管理员密钥。

第二步:设置预算和单笔付款上限

每个智能体只需设置一次的两个数字:

  • monthly_budget(月度预算)以及用来对照检查的、不断累加的 spent_this_month。
  • single_payment_cap(单笔付款上限),这个智能体一次能动用的最大金额,一旦超过,就必须有一条规则(而不只是这个硬上限本身)来批准。

还有第三个数字,适用于所有智能体加在一起:company_daily_ceiling(公司每日上限),无论是哪个智能体在花,都要对照当天累计的 company_spent_today 检查。这三者都是断路器,会在任何具名规则之前,按这个顺序检查:智能体是否已注册且处于激活状态、月度预算是否还有空间、公司是否仍在每日上限之内、资金库是否有足够余额。

第三步:编写规则

一条规则是一个结构固定的 JSON 对象(来自 Pink 的策略规则参考文档):

{
  "id": "r18",
  "name": "Supplier reorders under $2,000: automatic",
  "agents": ["a_proc"],
  "payee": "approved",
  "min": 0,
  "max": 2000,
  "window": "tx",
  "action": "allow"
}
字段 取值 含义
agents "*" 或一组智能体 id 这条规则适用于哪些智能体
payee any · approved · new · cat:<类别> · 一组收款方 id approved = 在这个智能体的收款方名单上,new = 不在,cat:ads/cat:saas/cat:blocked 等按类别匹配
min / max 数字,美元等值 被测量金额必须落在的闭区间;max: null 表示无上限
window tx · day · month 按单笔、按当天,还是按当月累计来衡量这个智能体的金额
action allow · ask · block 命中后发生什么;ask 需要配套 approvers
approvers {"people": [ids], "n": 1} 或 {"group": id, "n": 2} 具名人员,或某个组内的法定人数
requires / absent 一个标志名 只有请求携带(或不携带)这个标志时,规则才命中
outsideHours [start, end],24 小时制,按工作区本地时区 只在这个时间窗口之外适用这条规则

规则按从上到下的顺序评估,第一条命中的规则生效;不匹配任何规则的请求,默认会被拦截,而不是被放行。

第四步:请求超出规则时会发生什么

调用 pink.request_payment(或 POST /v1/payments)只会返回三种结果之一。在一次真实的沙盒工作区测试中,一笔 900 美元的请求超过了 500 美元的自动放行档,命中了一条 ask 规则,返回:

{
  "decision": "pending_human",
  "hold_id": "pay_935e89f7f4c4",
  "approvers_needed": 1,
  "who": "Luis Ortega (Store manager)",
  "expires_at": "2026-10-12T12:23:27.891Z"
}

同一个智能体的另一笔 420 美元请求,在单笔上限之内,同一次调用就返回了 HTTP 201,附带一个一次性银行转账凭证,锁定在对应的收款方和金额上,发出 15 分钟后过期。只要是 blocked 或仍处于 pending_human 状态的请求,永远不会发出任何凭证。

实例:一个采购智能体的配置

设置项 取值
智能体 a_proc,所属部门"采购"
资金库 Operating,每次请求都实时检查余额
monthly_budget 4,000 美元
single_payment_cap 500 美元(自动放行档)
company_daily_ceiling 6,000 美元,所有智能体共享
规则 r18 已核准收款方,0–2,000 美元,tx 窗口,allow
规则 r19 已核准收款方,2,000–10,000 美元,tx 窗口,ask,审批组 g_supply
类似 r11 的拦截规则 cat:blocked 类收款方(礼品卡、加密货币、类现金)始终 block

在真实的并发压力下,限额是否还站得住

一次针对沙盒的真实测试,从单个智能体并发发出 40 笔 200 美元的付款请求,对照一个 6,000 美元的公司每日上限:恰好 30 笔被放行(合计恰好 6,000 美元),10 笔被拦截,服务器自己的账本记录与这个结果完全一致。另一次测试,在同样的并发压力下检验了单个智能体的月度预算:8 笔请求在预算用尽前被放行,之后的请求全部被拦截。

另一项沙盒测试专门检验了当多个智能体同时撞向同一个共享上限时,这道限额是否依然站得住,而不只是单个智能体的情形。三个智能体(一个采购智能体、一个库存智能体、一个薪酬与账单智能体)分两轮并发发出共 40 笔付款请求,对照同一个 6,000 美元的公司每日上限。第一轮,40 笔中有 27 笔被放行,合计 5,720 美元(加上当天已花掉的 180 美元,合计 5,900 美元,仍低于 6,000 美元的上限);第二轮,40 笔中有 32 笔被放行,合计恰好 6,000 美元。两轮加在一起被拦截的 21 笔请求,每一笔返回的原因都是"Company daily ceiling reached"(已达到公司每日上限),并附带当时的累计总额(例如"$5,900 + $110 > $6,000")。两轮测试中,客户端统计的放行总额都和服务器自己的 company_spent_today 账本完全一致。这只是单次测试会话中观察到的沙盒行为,并不代表底层的检查机制是"原子的"或基于锁实现的,也没有在生产环境中验证过。

当前的限制

以上所有内容都运行在 Pink 的公开沙盒 agentic-sandbox.pinkwallet.com 上:免费、无需注册、仅使用测试资金。使用真实资金库和真实支付通道的生产环境,目前处于早期访问阶段,需通过 pinkwallet.com/agentic/developers/ 的候补名单申请,尚未对所有用户开放。

常见问题

能不能让每个 AI 智能体都有自己独立的消费限额,而不是共用一张公司卡? 可以。在 Pink 里,每个智能体都有自己的 monthly_budget 和 single_payment_cap,与其他智能体的限额独立检查,此外还有一个 company_daily_ceiling,适用于所有智能体加在一起的总额。

Pink 所说的智能体"钱包",具体是什么? 并没有一个单一的"钱包"对象;它由三个相互关联的部分组成:智能体(身份与密钥)、预算(各项限额)、资金库(实际的资金来源和余额)。调用 GET /v1/budget 会把这三者一次性一起返回。

能不能同时设置单笔限额和月度限额? 可以,这是两个独立的字段:single_payment_cap 对应单笔上限,monthly_budget 对应持续累加的月度总额,规则自身的 window 字段(tx、day 或 month)还可以在这两者之上再加一层更细的限额。

如果智能体尝试花超出限额的钱,会怎么样? 请求会在任何规则被评估之前就被拦截;预算、每日上限和资金库余额这几道断路器会先运行。不会发出任何凭证。

如果智能体一次性发出很多请求,限额还能守住吗? 在一次实测中,单个智能体并发发出 40 笔 200 美元的请求,对照一个 6,000 美元的每日上限,结果恰好是 30 笔放行(合计 6,000 美元)、10 笔拦截,与服务器账本完全一致。在另一次测试中,三个不同的智能体一起并发发出 40 笔请求,共用同一个 6,000 美元的上限,两轮测试中所有智能体加在一起的放行总额都恰好落在上限上(或刚好低于上限),每一笔被拦截的请求都明确提到了这个上限。

是否只支持一种货币? 规则可以通过 currency 字段限定为某一种货币(USD、EUR、GBP、HKD、SGD 或 JPY),也可以不限定货币。

相关阅读