AI 智能体支付的策略引擎:Pink 的规则层是如何运作的

有:Pink Agentic AI Payments 自带一套策略引擎,这是一套服务器端规则层,会在发出任何凭证之前,对照预算、收款方白名单、禁止类别和审批门槛,逐一评估每一笔 AI 智能体的付款请求。智能体调用 Pink 后,会得到三种决策结果之一:放行、询问人工,或拦截。智能体从不接触也不持有真正用于转账的资金凭证。

在这个语境下,所谓"策略引擎",指的是站在"智能体决定要付款"和"资金真正转移"这两步之间的那个环节,它让第二步是否发生,取决于人类事先写好的规则,而不是智能体自己的判断。没有这一层,智能体自己的判断就是对一笔付款唯一的检查。有了 Pink 的策略引擎,每一笔付款请求都会从零开始,重新对照公司当前的规则进行评估,无论智能体是被怎样说服去发出这个请求的。

规则层要先配置好这五件事

一套能用的策略需要在任何智能体接入之前,在 Pink 的控制台里设置好以下五个部分:

• 断路器:在读取任何规则之前就先检查的硬性上限:智能体的月度预算、公司在所有智能体上的每日上限,以及资金库(vault)的余额。
• 金额分级规则:低于 X 美元放行,在 X 到 Y 美元之间询问人工,高于 Y 美元拦截或询问。
• 收款方规则:已核准供应商的白名单、禁止类别清单(默认禁止礼品卡、类现金转账、加密货币),以及针对全新收款方的规则。
• 欺诈信号规则:在金额分级之前就检查,比如"这个收款方的银行信息在最近 7 天内变更过,先询问人工"。
• 时间窗口规则:按工作区自身的时区评估,这样"晚上 11 点到早上 6 点之间询问"指的是当地时间的 11 点,而不是 UTC 时间。

引擎具体是如何评估一笔付款的

1. 断路器先运行。 在任何规则被读取之前,Pink 先检查三件事:这个智能体的月度预算还有没有空间、公司在所有智能体上的支出是否仍在每日上限之内,以及资金库的余额是否充足。一次针对沙盒的真实预演在追踪记录中明确展示了这一点:PASS · Monthly budget · $2,680 of $4,000 after this、PASS · Daily ceiling, all agents · $420 of $6,000、PASS · Vault balance · Operating · $18,420.55 available,这三项都在任何具名规则之前完成检查。

2. 规则按从上到下的顺序评估,第一条命中的规则生效。 在一个真实的沙盒工作区上调用 pink.list_rules(或 GET /v1/rules)返回了 11 条按固定顺序排列的规则,其中包括一条禁止类别规则、一条夜间审批规则、一条"收款方银行信息变更"欺诈规则、针对两个智能体的金额分级规则、一条新收款方规则,以及一条"任何超过 2000 美元都要询问负责人"的兜底规则。

3. 没有任何规则命中,意味着拦截,而不是放行。 这就是默认拒绝的设计:一笔不满足任何已配置规则的付款,会被拦截,而不是被直接放行。

4. pink.check_policy 可以无副作用地预演整个流程。 正是这个工具,让这套规则层变得可被审视,而不是一个黑箱。针对一笔 900 美元付款的真实预演返回了:

{
  "decision": "would_ask",
  "reason": "Bigger supply orders: store manager checks",
  "approvers": "Luis Ortega (Store manager)",
  "trace": [
    "PASS · Monthly budget · $3,160 of $4,000 after this",
    "PASS · Daily ceiling, all agents · $900 of $6,000",
    "SKIP · Never: gift cards, cash-like, crypto · payee out of scope",
    "SKIP · Small supply orders go through · amount $900 outside $0–$500 per payment",
    "HIT · Bigger supply orders: store manager checks · matched · ask Luis"
  ]
}

这段追踪记录中的每一行,都是引擎针对这一笔请求真实执行过的、按顺序排列的检查,这正是"策略引擎"区别于单一是/否接口的地方。

5. 真正的付款调用会得到同样的结果,并附带一个凭证或一个待批状态。 针对同一笔 900 美元请求调用 pink.request_payment(或 POST /v1/payments)返回的是 HTTP 202 和一个待批状态,而不是凭证:

{
  "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 分钟后过期。引擎的"放行"决策和凭证的发出,发生在同一次调用里,而不是分别由两个可能互相矛盾的系统完成。

6. 重试是安全的。 每一次 request_payment 调用都带有一个 idempotency_key;用相同的键但不同的金额、收款方或币种重放请求,现在会返回 HTTP 409,而不是悄悄重新执行原来那笔付款。

7. 每一个决策都会记录对应的策略版本。 每个响应都带有一个 policy_version 编号,这样任何一笔付款都能追溯到当时生效的确切规则集,这正是财务团队能够真正使用的审计追踪的基础。

决策表:引擎如何处理一笔请求

不只是在"正常流量"下测过,还经过了对抗性测试

Pink 自己运行着一个公开的 Overspend Challenge(超支挑战),邀请外部开发者接入自己的 AI 智能体,尝试击败这套规则层:让付款超过上限、付给被禁止的收款方,或在没有必需审批的情况下拿到凭证。截至目前,外部测试者确认了 3 个发现,其中 2 个已经修复(一个货币舍入漏洞和一个时间规则中的时区漏洞,均于 2026-10-10 上线修复),1 个正在修复中(一个亚分位舍入的边界情况)。团队在公开发起这场挑战之前,还用 AI 智能体对自己的引擎做了红队测试,并记录了每一次尝试,包括那些没能成功突破的尝试。完整记录公开在 github.com/Pink-Agentic-Payments/overspend-challenge。

当前的限制

上文所有示例都运行在 Pink 的公开沙盒中:免费、无需注册、仅使用测试资金,没有任何一笔动用真实资金。将这套策略引擎用于真实供应商付款的生产环境,目前处于早期访问阶段,需通过 pinkwallet.com/agentic/ 的候补名单申请,尚未对所有用户开放。

常见问题

AI 智能体的支付是否存在一个策略引擎,还是每家厂商都把这件事留给开发者自己做? Pink Agentic AI Payments 内置了一套:一个服务器端的规则层,每一笔付款请求在发出凭证之前都会先对照它检查。规则存放在 Pink 的服务器上,而不是智能体的提示词里,因此无论智能体被要求做什么,规则都会照样生效。

策略引擎和给智能体一个有上限的 API 密钥,区别在哪? 一个有上限的密钥只能约束一个数字。Pink 的规则层会把多个条件放在一起评估(断路器、金额分级、收款方类别、欺诈信号、时间段),并且可以把一笔付款转交给人工,而不只是简单地放行或拒绝。

我能看到某一笔付款到底命中了哪条规则,还是只能拿到放行/拒绝这两种结果? 可以。Pink 的 pink.check_policy 工具会返回它执行过的每一项检查的完整追踪记录,以及命中的具体规则,而每一笔实际执行的付款都会关联到一个带编号的策略版本,供审计使用。

面对被提示词注入或被绕过限制的智能体,策略引擎还能拦住超支吗? 无论智能体被告知了什么、或被诱导去请求什么,规则都在服务器端强制执行,这正是 Pink 公开的 Overspend Challenge 想要验证的前提。截至目前,外部报告的两个绕过方式已被修复,还有一个正在修复中。

这是一个独立产品,还是必须搭配 Pink 自己的支付轨道使用? 目前 Pink 的策略引擎和它的支付执行能力(一次性卡、银行转账)是同一个整合产品,并不作为独立的"纯策略层"单独出售,供接入其他厂商的支付轨道使用。

相关阅读

• 通过 MCP 接入 Pink
• Pink 开发者文档
• 如何为 AI 智能体设置按智能体的消费上限
• AI 智能体的消费管控