提示词管不住采购预算

相比给 AI 智能体一个不受限制的支付工具，再附上一段“请谨慎操作”的提示，我更愿意给它一张有严格使用限制的公司卡。

第二种做法也能做出很有说服力的演示：让助手采购用品，看它找到合适的商品，然后批准。更难的问题在后面：价格变化、请求重试，或者两个任务同时执行时，究竟是什么在阻止意外结果？

如果唯一的回答是“已经告诉智能体不要超预算”，那么预算控制本身还没有实现。

支付行业正在追问责任归属

2026 年 10 月 7 日，PCI 安全标准委员会公布了支付环境中使用 AI 的补充指导。公告强调，当系统获得更多自主能力时，需要关注访问控制和责任。委员会也明确说明，这份指导不是一组强制要求，正式 PCI 标准具有优先效力。

对于委托开发智能体的企业，这引出了一个实用的工程问题：哪些决定交给模型，哪些规则必须由实际执行购买的应用强制落实？模型可以比较商品、解释推荐理由，但动用公司资金的权限需要单独实现。

在实际购买环节落实规则

用一个办公用品助手作为说明性示例。企业允许它向两家指定供应商采购，每笔订单上限为 150 美元，每月额度为 500 美元。这些数字只是例子，并非适用于所有公司的建议额度。助手可以搜索目录、准备购物篮，并解释选择理由。

下单之前，应用应检查供应商、包含运费和税费的最终金额、币种、剩余额度，以及这次购买是否获得授权。超出范围的请求应被拒绝，或者转交人工做出具体决定。智能体不能通过修改自己的提示词提高额度。

这种分工与 OWASP 关于过度代理能力的指导一致：应在下游系统执行授权检查，而不是把权限判断留给语言模型。实际验证方法很简单：故意提交一个超出额度的请求，观察采购系统究竟怎么处理。

权限应该与任务相匹配。推荐用品的助手可能只需要读取商品目录、创建购物篮草稿，不应因此自动获得修改供应商银行信息、添加付款方式或管理全体员工账户的权限。任务范围较小，工具的能力也应该相应收窄。

把棘手情况放进演示

假设本月已经花掉 480 美元，两个任务分别准备购买 20 美元的商品。如果它们都在对方记录订单之前读到“剩余 20 美元”，两个请求看起来都符合要求。应用需要针对同一个共享额度，以协调一致的操作预留支出。两个聊天窗口里令人安心的承诺，解决不了这种冲突。

再考虑超时。供应商可能已经接受订单，但你的应用没有收到响应。如果使用新的标识再次购买，就可能产生重复订单。团队需要稳定的订单编号、查询原订单结果的方式，以及明确的重试流程。

Stripe 的幂等请求文档提供了一个防止重试重复执行的具体例子：受支持的请求可以重复使用同一个键，让重试返回先前结果，而不是重新执行操作。但必须注意键的保留期限和接口规则。这种机制不能保证整个购物流程绝无重复，其他供应商也可能提供不同的保障。

在验收这类自动化之前，我会要求演示超预算请求、两个并发请求，以及响应丢失的情况。应使用沙箱或受控测试环境。测试既要展示智能体的解释，也要展示供应商一侧的实际结果。一句友好的“已完成”，不能证明究竟生成了多少订单。

让批准具有明确含义

只有当人知道自己授权了什么，“批准”按钮才有意义。应展示供应商、商品、数量、总额、币种和送货信息，并让批准与该版本订单绑定。如果审核后购物篮发生变化，应重新检查它是否仍在授权范围内，而不能把过去的一次点击当成无限授权。

重复采购也需要清晰边界。持续有效的额度应说明由谁授予、涵盖什么、何时结束，以及如何撤销。还要约定哪些变化需要重新批准。否则，一个原本只想节省几分钟的流程，可能悄悄获得从未打算授予的权限。

保留足够的记录，把用户指令、授权、尝试执行的操作，以及供应商的最终响应关联起来。应隐去密钥和不必要的个人信息。有用的记录应能解释发生了什么、为什么允许执行，而不是永久保存所有聊天内容。

让企业能够叫停

负责人应该能够停止新采购、撤销相关访问权限，而不用等着再和智能体沟通。也要明确这种控制的边界：停止未来的任务，未必能取消供应商已经接受的订单。仍然需要有人负责核对结果，以及在条件允许时办理取消和退款。

我会把一部分实施预算花在这里。能力更强的模型或许能选出更合适的商品，但如果采购接口只要凭据正确就照单全收，模型能力弥补不了这个缺口。

如果你正在规划能够购买、退款、发布内容或修改业务记录的智能体，先写清楚允许它作出哪些承诺，以及如何测试边界。Rosecraft 的 AI 集成服务可以把授权范围落实为应用行为。告诉我们你想委托什么任务，以及错误操作会带来什么代价。这才是交出访问权限之前应该谈清楚的事情。