人类制定策略下的代理支付
代理支付是指由软件而非结账页面前的人发起的支付。AI 代理持有凭证，自行判断应当发生一笔购买，并亲自完成转账：支付发票、续订服务、预订包机，全程无需人类点下最后那个按钮。它的区别就在于发起者。人点击购买，只是前面多了个聊天机器人的普通银行卡支付；而代理支付是软件在资金真正流动的那一刻，自己决策、自己授权、自己结算。这个品类的所有难点都源于这一点：花钱的不是人，它不会像人在向陌生人汇款前那样疲惫、起疑或紧张。
所以，真正有意思的问题从来不是代理会不会花钱，它们早就可以了。问题在于，谁来制定它们花钱所依据的规则，这些规则是由平台强制执行，还是仅仅由代理自己承诺遵守。
失败模式显而易见，这正是关键所在
给代理一个可用的支付凭证却不设上限，你就造出了一起尚未发生的电汇欺诈事件。出错的方式并不离奇。网页中隐藏的提示注入，指使代理向攻击者付款。格式错误的工具描述，把一笔正常采购指向了错误的收款方。重试循环因为始终收不到成功信号，把同一笔扣款尝试了一千次。这些都不需要高明的对手，它们只是自主软件的寻常 bug，只不过输出的是从你账户里流出去的钱。
最容易想到的补救办法，是让代理更谨慎：更好的系统提示词，更严厉的指令，一个在花钱问题上推理更深的模型。但这等于把控制放在了系统里最不可信的地方，即代理自身的推理，而这恰恰是可以被说服绕开的东西。代理能够争辩过去的预算，就不是预算。控制必须放在代理够不到的地方，也就是完全处于代理之外。
策略才是产品，而不是提示词
这套约束模型是一份由平台在资金流动之前强制执行的策略，而不是在代理做出决定之后。每个代理都有单笔上限和每日限额，在我们的演示策略中是每笔 €150.00、每日 €500.00，此外还有每月 €6,000.00 的总上限。这些是平台检查的硬性边界，而不是代理自己信守的承诺。演示中的差旅机器人试图以 €640.00 预订包机时，付款当场被拒：超出上限，一分钱也没有转出。一个每天都表现完美的代理，同样不可能超出当月额度。
预算规定花多少，白名单规定付给谁。代理只能向你事先指定的商户付款。演示中的 Ops Agent 只认得四家，它向一家不在名单上的供应商发起的 €180.00 付款，被以“未列入名单”为由拒绝。两者合在一起划出一个框：这么多钱，只能付给这些收款方。在框内，代理全速运行，无需请示；而这个框，归人类所有。
问题从来不是 AI 代理会不会花钱，而是它花钱所依据的规则由谁来写。答案应当始终是人，事先写好，白纸黑字。
红线之上，由人决定
有些决定太重大，不能交给一个框来处理。因此策略设有一个阈值：超过该金额，必须由人批准，付款才能放行。演示中这条线设在 €100.00。当 Ops Agent 标记出 Nord Logistics 的 #088 号发票时，金额为 €120.00，远在 €500.00 的每日预算之内，但高于审批线，它没有付款，而是暂停下来，把提案摆到一个人面前并等待。一句话回复即可放行；付款以参考号 9F21-0716 结算，并于 09:41 写入审计日志。线以下，代理自行行动；线以上，先由人回答。
审批不是一个转瞬即逝的勾选框。它会记录是谁批准的、在哪台设备上、何时批准，并附带签名：App 内批准，手机密钥，09:41:12。日后有人问起这笔付款为何发生，答案是一个具名的人和一个时间戳，而不是一句含糊其辞。
终止开关，以及不可被悄悄篡改的日志
即便边界设置得再好，代理也会出问题，策略也可能被证明有误。有两项控制来应对。第一项是终止开关：一键即可暂停某个代理，并立即停止它可能发起的所有付款。密钥保持有效，因此其他功能不受影响，代理只是在人类重新启用之前无法花钱，其待处理的提案也原地冻结，而不会消失。在演示的代理群中，差旅机器人处于暂停状态，已支出 €0.00，队列完好无损。
第二项是仅追加的审计日志。每一项决策都有据可查：智能体尝试了什么、哪项策略检查通过或未通过、谁批准了什么，直至密钥轮换。一条记录即可还原整笔支付——决策 DEC-4471 呈现了请求、每项策略检查及其结果（白名单通过、限额通过、阈值触发升级审批）、人工签名，以及已结算金额及其通道和参考号。每条记录都带有自身哈希、前一条记录的哈希以及它在链中的位置（演示中为 #4,471），因此修改任何字段，都会使其后的所有记录失效。日志可连同哈希一起导出为 JSON：它属于你，可以直接交给审计方，而不是由我们保管。
结算求稳，创新留给授权
人们很容易想把智能体支付从头到尾都做成新的——新的通道、新的工具、新的资金流转方式。请克制这种冲动。真正全新的部分是授权：智能体如何证明自己有权支付、依据谁的策略、经过何种批准。支付一旦通过这道关口，就应当在多年来平淡稳定的通道上完成结算。在演示中，一笔获批的 €120.00 支付提案会变成一笔普通的 SEPA 贷记转账，批准数分钟后经 SEPA Instant 结算，在下游与个人发起的支付毫无区别。银行并不知道、也不在意这笔支付是由智能体发起的。
这种划分是有意为之。平淡的通道可预测，在支付机制允许的情况下可撤销，并且你将打交道的每一位财务人员和审计人员都了然于心。把创新放在策略上，把支付放在成熟的通道上，意味着风险高、变化快的部分由你完全掌控，而与他人银行打交道的部分无需任何人重新学习。智能体使用的是支付产品家族其余部分共用的同一个核心（详见 /products/pay），而不是为机器人另造的平行世界。
协议格局尚未定型——请据此构建
智能体应当如何向商户出示自己的身份和授权，目前仍无定论。多种方案在竞争：智能体如何证明身份、获准购买什么，以及商户如何在收款前核验这些信息。尚无赢家，今天把全部筹码押在任何一个方案上都为时过早。稳妥的做法是把授权协议设计成可替换的，并让其背后的一切保持稳定：前端的传输格式变了，策略引擎、审计模型和结算通道都不必改变。
实际做法就是保持一个小而平淡的集成面。智能体通过 MCP 接入 mcp.protocore.io/agents；任何支持该协议的框架都可以持有钱包。接口刻意保持精简——提出支付、接收决策——因为有价值的逻辑在平台上，而不在提示词里。等到业界就智能体如何向商户自证身份达成一致时，变化的只是前端，其背后的围墙原地不动。
定位
智能体支付并非押注自主软件可以无限制地花钱，恰恰相反：它押注的是软件终将花钱，所以限制最好真实、外置且清晰可读。预算和白名单划定边界，阈值把大额决策交给人，紧急开关可以叫停一切，仅追加的日志让每笔支付事后都能还原。/products/agents 的产品页使用这里的演示数据完整走了一遍流程——创建智能体、设置策略、看着一笔支付升级审批并完成结算——而 /products/pay 就是这些支付所运行的核心。自主性是真的，缰绳也是真的，而且握在人的手里。