催收语音 Agent 如何设定上线验收门槛

让借款人在电话里答应「周五还钱」，不等于收到了还款。催收语音 Agent 最容易出现的评估偏差，就是把对话推进当成业务完成，再用漂亮的转化率证明可以扩大上线。

作者提出的办法是：先限定试点范围，用统一口径比较 AI 与人工，再把真实结果、安全控制和后台状态一起验收。文章提供了评估思路和测试框架，但所谓「12 场景」只是合成测试提案，并非已经跑出的成绩，而且所给原文缺少具体场景列表。

AI 催收不如人工，证据能支持到哪一步

作者引用了 Choi、Huang、Yang 和 Zhang 的 NBER Working Paper 33669，发表于 2025 年 4 月。研究覆盖一家中国消费金融公司在 2021 年 4 月至 2022 年 12 月进入催收的 2200 万宗逾期贷款案例。

这家公司把本金低于 300 元的新增逾期债务几乎全部交给 AI，较大金额交给人工。研究者利用门槛附近的案例做断点回归，即比较金额接近、却因分配规则进入不同处理路径的账户。此外，部分较大账户被随机分成两组：一半先接受 5 天 AI 电话，再转人工；另一半从开始就由人工处理。

研究报告称，在这一环境中，AI 催收效果弱于人工，向 AI 作出的承诺也更容易落空。人工后续介入，没有消除全部差异。

但长期还款结果有一个不能绕过的口径问题：NBER 摘要写的是，一年后偿还的初始逾期款少了 1%；Yale 摘要则称，一年后 AI 催收回款仍少 5%。作者明确指出，现有摘要不足以解释两者的指标和分母差异，不能取平均，也不能搬到新业务里做预测。

这支持的是一个有限结论：口头承诺不能代替后续还款，AI 的效果需要在具体业务里验证。

研究来自一家公司的生成式 AI 普及前流程，不能直接代表 2026 年语音模型的表现。另一边，Veritus 在 2026 年 10 月 1 日的 Finovate 页面展示了 6 分钟服务电话演示，并声称其 Agent 处理的催收电话中「1 in 5」带来付款，但未公布呼叫量、账户构成、对照组、观察窗口和付款定义。

研究有外推边界，演示有证据缺口，两者不能直接比较。

指标为什么必须从「分配账户」开始算

假设 AI 只统计接通电话，人工却统计所有分配账户，两个转化率从起点就不可比。难接通的账户已经被 AI 的分母排除了。

作者建议，拨号前先写清分析单位、目标人群、处理路径、对照流程和观察窗口。主指标可以是：截至约定日期，所有分配到该路径的合格账户中，完成经核实付款或有记录的非付款解决方案的比例。后者可以包括正确转交争议处理等经批准的结果。

同一人可能收到人工电话、AI 电话和短信，所以「一次电话」未必适合作为分析单位。如果同一人有多个账户，分别随机分组还可能造成处理路径冲突。

采用随机分配时，应按意向治疗分析（intent-to-treat）保留原始分组。电话失败、没有接通、转交人工，都不能成为把账户移出 AI 组的理由，否则最需要计入的失败反而消失了。无法随机化，可以使用匹配或分阶段比较，但要说明仍有哪些混杂因素，不能把观察性差异写成因果结论。

事件也要拆开记录：接通、身份核验、作出承诺、履行承诺、安排付款、付款结算，各是各的。成功转接与人工真正接听并解决，同样不是一个事件。

作者把指标分成三层：真实完成结果、安全控制、运营效率。敏感债务信息泄露给错误对象、有效停止联系要求生效后仍发起外呼、虚构金额或法律后果等事件，应触发独立审查或暂停，不能被较高回款率抵消。控制稳定以后，再比较解决时长、人工投入和每次经核实解决的成本，还要检查工作是否转移给投诉团队。

验收要查后台发生了什么，不能只听录音

作者提出的合成测试套件设计于 2026 年 11 月 4 日，计划包含 12 个场景，不使用真实消费者数据，也不代表客户测试或失败率。所给原文并未展示这 12 个场景的具体内容，因此无法照单复现。

不过，验收方法交代得很清楚：分别检查话术、政策决策、持久化状态、下游动作和审计证据。模型说了「不会再联系」，拨号队列却继续派单，这次验收仍然失败。

测试先断开生产系统，再接入预发布环境的规则和队列，对账本、联系偏好服务注入延迟、重复、不可用和陈旧响应。失败时保留输入、模型与提示词版本、规则版本、工具响应、事件标识、预期与实际状态。提示词、供应商版本、CRM 或拨号器变化后，要重跑相同案例。

下面这段原文测试数据解决的是「请求发出后，结果未知该怎么办」：

{
  "evaluationId": "synthetic-run-2026-11-04-0042",
  "assignment": "ai-first",
  "accountRef": "TEST-ACCT-17",
  "policyVersion": "collections-policy-7",
  "agentVersion": "voice-agent-build-31",
  "eventType": "payment_requested",
  "eventTime": "2026-11-04T10:15:00Z",
  "sourceEventId": "evt-018a",
  "ledgerResult": "unknown",
  "nextAction": "pause_and_reconcile"
}

要看的是 "ledgerResult": "unknown" 与 "nextAction": "pause_and_reconcile"：状态未知时先暂停核对，不能把请求超时解释为付款失败，立即再扣一次。

有副作用的请求，要由后端控制唯一性和执行条件。

作者要求使用幂等键防止重复执行，用关联标识串起整段对话，并由后端校验账户状态、金额限制和政策条件。模型拿到的工具结果应尽量小，只告诉它允许的下一步、安全解释代码和必要的人工转交去向。余额和到账状态应查询权威系统，不能让模型从对话里拼出来。

我的判断

这篇最有用的部分，是把语音 Agent 的评估从「回答得好不好」推到了「动作有没有正确完成」。对涉及付款、联系限制和人工转交的系统，这个方向成立：话术通过，不能替代数据库更新和队列执行通过。

但标题里的「12 场景门禁」比正文可交付的内容更完整。所给版本既没有列出 12 个场景，也没有展开提到的三类上线门禁，结尾还在支付失败案例处截断。它适合用来制定评估方案，尚不能当作现成验收包。

作者也没有提供这套方法相较其他评估方案的对照数据。哪些控制有效、测试覆盖是否足够，仍需要本地验证；「初期适合做有限提醒或预约人工回电」属于作者的实践建议，不能当作已被实验确认的最佳路径。

法律部分尤其不能照抄参数。原文提到美国 CFPB 的 Regulation F 对 7 天超过 7 次电话，或电话交谈后 7 天内再次致电的相关推定，同时强调适用对象、例外和其他约束。这个数字不是普遍可用的呼叫额度，更不是国内业务规则。OECD 于 2024 年修订的 AI Principles 是治理建议，KPMG 的材料则是商业治理框架，都不能充当具体催收流程的合规证明。

能拿来做什么

• 做语音 Agent 的 Node 服务时，把请求、授权、预约、结算建成不同事件；遇到支付超时先查询权威状态，并让后端负责幂等和规则校验。
• 做运营后台时，在转化率旁展示分母、观察窗口、原始分组和人工转交结果，把已预约与已到账分开，退款或退回后同步修正结果。
• 做联调验收时，增加停止联系后队列仍有旧任务、工具超时和重复响应等故障测试，同时查看对话记录与后端事件日志。
• 准备 AI 与人工试点时，提前固定模型、提示词、规则版本和联系安排，约定主指标及暂停条件，避免结果出来后才调整口径。