语音催款 Agent 拨号前应先校验账务

语音 AI 打电话提醒逾期账单，最先该优化的不是话术，而是拨号资格：客户可能刚付款，账本尚未更新；也可能已经提出争议、拒绝联系，任务队列却还留着旧记录。模型再会聊天，也补不上这些事实。

作者提出的方案是：拨号前重新核对账户，条件不全就停止；通话后先核实结果，再决定下一步。文章提供的是合成验收案例和示例代码，没有真实业务测试。对接过任务队列、支付回调或 AI 工具调用的程序员，值得看的是它如何把「允许执行」变成一道可验证的边界。

队列里的账单，只能触发复查，不能直接授权拨号

导出的提醒名单通常包含账单编号、电话、金额和到期日。但从名单生成到实际拨号之间，账户可能已经变化。付款处理中、贷项通知单抵扣、联系人变更，都可能让原来的任务失效。

作者要求在拨号前读取当前账户快照，包括版本、未结余额、币种、结算状态、争议状态、联系人身份、渠道权限、停止原因和过期时间。缺少字段时，系统应明确返回未知，不能补一个方便继续执行的默认值。

队列记录是复查账户的入口，当前可信状态才是执行依据。

如果排队时是 v7，读取时已变成 v8，不能覆盖旧金额后照常执行。系统要重新计算资格，并保留两个版本供审计。余额变化未必永久禁止联系，但旧话术和旧金额已经不能直接复用。

下面的判定式把「能否尝试」和「说什么」拆开，前者由业务规则决定：

eligible = fresh(snapshot)
        AND open_balance(snapshot) > 0
        AND settlement(snapshot) == "confirmed_open"
        AND dispute(snapshot) == "none"
        AND contact(snapshot) == "verified"
        AND permission(snapshot, intended_channel) == "allowed"
        AND stop_reasons(snapshot) == []
        AND attempt_budget_remaining(snapshot)

要看的是这些条件之间全部使用 AND。任何输入缺失、过期、冲突或不在允许范围内，都应拒绝拨号。作者称之为 fail-closed：无法证明可以执行，就先停下来。

模型仍然可以解释联系原因、回答限定范围的问题、识别异常并转交处理，但不能从对话里猜余额，也不能把客户说的「昨天付过了」直接写成到账事实。

超时以后，先查发生了什么，再决定是否重试

文章把每次操作分成三个状态：未开始、进行中、结果已确认。超时只能说明调用方暂时不知道结果，不能证明操作没发生。

这个区别直接影响重试。拨号接口收到请求后，响应可能丢失；结果写入已经成功，HTTP 请求也可能超时。此时重新创建任务，两个 worker 就可能对同一账户重复拨号。

作者建议，为一次逻辑提醒生成独立的 attempt ID，贯穿队列、拨号器、事件流和结果写入。同一次写入重试应复用幂等键；下游不支持幂等时，需要协调器先预占操作，再核对丢失的确认。

资格检查通过，也不等于抢到了执行权。生产系统必须用事务或等效机制领取尝试资格，否则两个 worker 都可能读到「剩余次数为 1」。

通话结果同样不能只存一段模型总结。作者建议使用受约束的枚举，区分争议、付款承诺、错误联系人、退出联系、无人接听、技术失败、未知，以及人工转接待确认和已确认。

客户表达先作为有来源的候选变更记录，再进入业务核对流程。例如，付款承诺可以申请暂停跟进，却不能生成银行收款记录；退出联系也要等停止状态写入成功后，才能向客户确认处理完成。

人工转接尤其容易被做成假成功。transfer requested、transfer ringing、transfer accepted 和 transfer failed 应分别记录。RFC 5589 讨论 SIP 转接信令，但业务上的成功标准仍需团队定义：有人接收、客户仍在线、必要上下文已经到位。

14 个案例是验收设计，不是上线效果

作者在 2026 年 11 月 10 日设计了 14 个合成案例，覆盖付款、争议、联系人、权限、重试、转接和结果变化。这里的 14 不是客户数，也不是实拨电话数。所给原文没有展示完整的 14 行矩阵，只特别指出第 13 项容易遗漏：请求转接不等于人工接听。

Python 示例另有 8 个确定性案例，包括正常账户、版本变化、付款待处理、争议、联系人未验证、停止联系、次数耗尽和字段缺失。基础数据使用 v7、12500 最小货币单位、EUR，剩余尝试次数为 1；到期时间为 2030-01-01T00:00:00Z，测试时钟固定在 2026 年 11 月 10 日。

示例允许的币种是 EUR、CHF、GBP、USD，这只是教学用白名单。代码不请求网络、不拨号，也没有覆盖授权存储、并发锁、签名校验、审计、隐私控制和集成测试，不能直接当生产组件使用。

文章引用的供应商页面宣称降低 40%，并给出第 14 天 40% 的解决比例，但未公开样本、对照、分母、排除项和测量方法，不能据此判断效果。

另一项入站电信语音 AI 现场实验，则报告了过渡期服务时长和人工协助需求增加，同时投诉持续减少。它不能证明外呼账单提醒有效，却提醒团队：完成通话数之外，还要记录未解决异常和人工处理分钟数。

我的判断

我认同作者把确定性业务规则放在模型前面。Prompt 适合约束表达，账户版本、授权状态和尝试次数则需要由系统执行。把这些判断交给模型，后续很难解释某次拨号为何被放行。

但方案依赖上游基础设施：可信版本从哪里来，权限由谁维护，退出状态如何同步，异常队列由谁接手。如果这些问题没有答案，增加一个路由服务也无法自动补齐事实。

权限模型的拆分也有价值：联系人身份、渠道资格、消息用途资格、停止状态应分别存储。号码验证成功，并不代表允许为任意目的联系。文章讨论了法国 CNIL 和英国 CMA 的材料，但两者适用范围不同，不能直接移植为国内团队的许可规则。

这份材料能支持验收要求，不能支持回款效果或节省人力的承诺。

作者没有提供与人工审核、普通数字提醒或其他路由方案的对照数据。对于无法可靠核对账户的团队，保留人工审核队列，是原文明确认可的选择。所给文本结尾也已截断，不能替作者补出后续结论。

能拿来做什么

• 在 Node 任务消费者调用拨号接口前，增加一次权威快照读取，比较队列版本与当前版本，记录放行或停止的具体原因，并用事务领取尝试资格。
• 给提醒任务建立贯穿全链路的 attempt ID，先用两个 worker 竞争同一幂等键，再模拟预占后、拨号中、挂机后和结果写入后的超时，检查是否重复执行。
• 在前端运营台分别展示「转接请求中」「人工已接听」「结果待核对」，并为待处理项展示负责人和期限，让界面状态对应真实业务事件。
• 试点时同时统计重复联系、未解决异常和人工处理分钟数；先在模拟器或受控测试环境验证，再判断是否具备真实拨号条件。