单次退款限额挡不住智能体累计超退

给 AI 退款工具加上 500 美元上限，为什么还能把一张 1,840 美元的账单退成 2,320 美元？因为它连续退了五次，每次都符合限制。原文讨论的是一个容易被忽略的 Agent 权限问题：单次调用合规，不等于整件事合规。

作者根据九个部署的审查经历，提出把退款额度、订单状态、审批责任和累计频次一起管理，再给 AI 补上返工、账户额度和转人工工具。对接入业务工具的程序员来说，最有价值的是看清：哪些约束可以写进提示词，哪些必须由服务端执行。

每次都没超限，为什么最后还是多退了钱

原文的案例发生在美国中西部一家 HVAC，也就是暖通空调服务公司。他们在 2 月给 AI 配置了 max_refund_amount: 500。到 4 月，一位客户在支付 1,840 美元维修费的 11 天后再次遇到故障，晚上 9:40 联系客服。

客户先要求退诊断费，AI 退了 380 美元；之后围绕配件、人工和同一个问题继续追问，AI 又依次退了 460、500、500、480 美元。19 分钟内，累计退款达到 2,320 美元，全程没有人工参与。

限制确实生效了，只是限制的对象选错了。

单次 API 调用的额度，管不住一笔订单的累计损失。

作者称自己审查过九个部署，包括两家家庭服务企业、一家牙科集团、三家电商品牌，以及 SaaS 公司、连锁健身房和兽医诊所，其中八个存在相同的四类漏洞。作者测得的未授权退款流失，平均占月度退款额的 3.1%；某电商品牌一个月达到 19,400 美元。

这些是作者报告的审查结果，原文没有提供完整样本和计算口径。不过，漏洞的机制很明确：某电商品牌每段退款对话平均调用退款工具 1.7 次，重复调用已经成为日常路径。

另外三个漏洞也与权限有关。第一，「解决问题」没有业务定义，AI 容易把客户停止抱怨当成成功。第二，政策中的「酌情处理」没有指定审批人，例外就变成了自动授权。兽医诊所当月超过 100 美元的退款中，61% 没有原因代码，也没有人工批准，全部归为善意补偿。第三，系统只有 issue_refund，返工、抵扣和减免费用都被压成了现金退款。

退款权限要回答哪些问题

作者建议用权限矩阵替代一个全局数字，同时回答四件事：退多少、满足什么条件、谁批准、多久能退几次。

模板分成四档：band 0 为 0 至 50 美元，要求找到订单并填写 reason_code；band 1 为 50 至 250 美元，要求 paid=true、service_date <= 14d，且是该订单首次退款。band 2 列出 250 至 1,000 美元及 band 1 条件不成立的情形，需要人工点击；band 3 超过 1,000 美元，只能由负责人批准。

金额之外，还要叠加累计限制：每笔订单原则上终身只退一次，人工重置后才能例外；每位客户每 90 天累计不超过 300 美元；所有对话每天累计不超过 2,500 美元。同一订单的部分退款也计入同一次退款。触及每日上限时，冻结退款工具，聊天仍可继续。

自动退款还必须同时通过四道门：支付机构确认付款、交付状态明确、订单没有未关闭的升级处理或投诉争议、退款理由能映射到已知 reason_code。任一道失败就转人工。

这里的关键是把「谁负责」变成记录。作者称，牙科集团加入人工审批档位后，退款量下降 22%，留存没有可测量的下降。

但模板不能直接照抄成条件判断。50 和 250 美元的区间边界重叠，表格与正文对 250 美元起是否一律审批的表述也不够一致；90 天累计 300 美元与高额人工退款之间如何处理例外，原文没有说清。上线前需要先补齐这些定义。

提示词留下证据，服务端守住额度

作者给出的提示词要求：调用 issue_refund 前，在工具的 reason 字段写清付款、交付和首次退款三项核验结果。它解决的是审批依据无法追溯的问题。

Before calling issue_refund, answer these three, in writing,
in the tool call's reason field:

1. PAID?  Verify against the payment provider. What is the
   transaction id and the settled amount?
2. DELIVERED?  What is the delivery/service status, and when
   did it change? If unknown -> escalate, do not refund.
3. FIRST?  Has this order or this customer had a refund in the
   last 90 days? If yes -> escalate, do not refund.

If any answer is missing, the refund does not happen.
Say instead: "Let me get someone who can approve this."

要盯住第一项的 transaction id 和 settled amount：核验来源是支付机构，不能拿客户报出的订单号代替到账证明。

作者称，某电商品牌要求在 reason 中填写交易 ID 后，向未付款订单退款的情况从每月 14 次降到零。此前工具接受任何传入的订单 ID，连客户猜测的编号也能进入流程。

不过，填写字段只能留下核验声明。对 Node 服务端而言，更稳妥的实现是由退款接口查询支付记录、既有退款和累计额度，检查通过后才执行资金操作。否则，AI 写出一个看起来完整的理由，仍可能绕过实际业务约束。

审计字段负责解释，服务端校验负责阻止。

三问提示词也比矩阵更严格：客户近 90 天只要有退款就转人工，矩阵则允许累计到 300 美元。它们可以设计成不同层级的规则，但不能在未解释的情况下同时当作唯一标准。

少退现金，需要给 AI 更多解决办法

作者补充了四个工具：schedule_redo 免费预约返工，apply_credit 发放有效期 12 个月的账户额度，waive_fee 减免诊断、上门或补货费用，escalate_with_summary 带摘要转人工。

客户没有明确指定方案时，建议按返工、账户额度、部分退款、全额退款的顺序提供选择。作者报告，在家庭服务案例中，同时提供账户额度与现金时，38% 的客户选择前者；SaaS 公司调整顺序后，六周内现金退款下降 31%，满意度评分持平。

审计还要检查 AI 是否在花钱结束对话。作者在 SaaS 对话记录中发现，前四条消息内获得退款的客户，30 天内取消服务的可能性是其他相关对话的四倍。但原文没有交代分组和控制变量，这只能说明相关性，不能证明早退款导致流失。

作者建议每周重点看前三项：前四条消息内的退款数、缺少 reason_code 的退款数、同订单第二次退款数。同时记录现金、额度与返工占比、转人工是否完成、退款与重新预约之比，以及每日上限触发次数。

每月再抽查 30 段退款对话，计划花 45 分钟，核对实际到账金额、退款前的触发消息、方案提供顺序、调用次数和审批人。兽医诊所的一次审计用了 38 分钟，找出 90 天内 4,100 美元没有原因代码和审批人的退款。

我的判断

这篇最成立的观点，是把权限从「模型能调用什么」推进到「业务允许发生什么」。订单、客户和时间窗口中的累计状态，不能只靠模型记忆对话来维护。

相较于继续强化提示词，服务端额度校验和具名审批更容易验证，也更容易追责。但作者没有给出对照实验，22%、31% 等改善幅度应当视为部署经验，不能当作一般团队的预期收益。

「每单永远只退一次」也有明显前提。分批交付、分项维修可能需要多次合法退款，更通用的做法是限制累计退款不超过可退余额，再管理例外。原文把订单限制也用于解释跨订单重复索取，这一点并不严谨，后者还需要客户级规则。

返工和账户额度值得提供，但应当用于解决客户问题。原文限定了客户未指定方案时才按顺序推荐，这个边界应保留；现金退款下降，也需要结合投诉、返工完成情况和留存一起判断。

能拿来做什么

• 如果你维护退款接口，先查最近 30 天同订单的第二次退款，再核对累计退款是否超过实际到账金额。这能直接检验现有上限覆盖了什么。
• 如果你用 Node 封装 Agent 工具，把订单状态、累计额度和审批记录放进服务端校验；对并发调用也要保证额度检查与执行之间不会重复放行。
• 如果你负责客服 Agent，补上业务确实能够履约的返工、费用减免和带摘要转人工工具，并记录各方案最终是否完成。
• 如果你负责运营后台，每周展示早期退款、缺少原因代码和重复退款，每月抽查 30 段对话，把接口返回成功与业务处理正确分开验收。