Agent替人打电话：银企直连支付终态确认的语音问询方案探索

声明：本文所述方案及实践测试仅做技术落盘与验证，尚未在真实生产环境中试用，请读者结合自身实际审慎评估。

一、引言

在大型企业集团财务公司的日常结算运营中，银企直连通道已成为资金支付的主流方式。然而，直连通道并非万能，尤其在支付终态确认这一环节，银行端与财务公司端的信息不对称，始终是一个令人头疼的"最后一公里"问题。

尽管行业内外已探索出多种补救手段，但受限于银行系统策略、特殊时点性能、非合作行壁垒等因素，极端场景下仍会出现"钱已扣、账未回、人焦急"的局面。本文将分享我们设计并实践验证的一套基于Agent（智能体）的自助银行客服问询方案，尝试用"语音坐席替代人工拨号"的思路，为上述困境提供一个全新的解耦路径。

二、痛点还原：为什么老问题总是反复出现？

在银企直连模式下，成员单位发起付款后，支付指令由核心系统通过直连通道发往银行。正常情况下，银行会异步返回支付终态（成功/失败），核心系统据此更新业务状态。

但现实远比理想复杂。每天总有少量支付指令卡在银行端——可能是银行内部风控拦截、排队拥堵、系统延迟，或是返回报文丢失。对于生产制造类企业，哪怕一笔原料款或运费迟迟不确定，都可能影响产线排期或货物发运。于是，熟悉的场景反复上演：

1. 成员单位在司库或网银端看到"发送成功，未确认"；

2. 电话催促财务公司结算人员；

3. 结算人员登录核心系统查明细、查流水，发现无终态；

4. 结算人员不得不亲自拨打银行客服热线，人工报出企业账号、金额、流水号等信息；

5. 银行坐席查询后口头告知结果；

6. 结算人员手工在核心系统做"人工确认成功/失败"。

这笔账算下来，单笔查询耗时少则5分钟，多则半小时，且每天都可能零星发生，尤其在月末、季末、年末，银行系统自身压力大，反馈更慢，问题更突出。

三、现有方案的局限性

为了缓解上述矛盾，业内普遍采用了以下三类补充手段，但每个方案都有其"失灵时刻"：

因此，我们需要一种"不依赖银行接口、不受限于网银登录、不增加直连压力"的新方式——语音电话，依然是最高效的兜底手段，但我们要把"人工打电话"变成"机器自动打电话"。

四、Agent自助银行客服问询方案

我们的核心思路是：让Agent代替结算人员，自动拨打银行客服电话，与银行坐席进行语音交互，获取支付状态，形成带原始语音的查询报告，最后由结算人员插KEY批准后自动执行人工确认。

这并非简单的"语音外呼"，而是将语音合成（TTS）、语音识别（ASR）、大语言模型（LLM）理解与决策、流程自动化（RPA/Skill调用）融合为一个闭环智能体。

方案整体流程

整个流程可划分为触发 → 查询 → 语音交互 → 报告生成 → 审批确认五个阶段，具体如下：

┌─────────────────────────────────────────────────────────────────┐ │ 1. 触发 │ │ 成员单位在司库/财务公司网银/财务共享系统中， │ │ 点击"终态查询"按钮（或系统自动检测超时未终态支付指令） │ └──────────────────────────┬──────────────────────────────────────┘ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ 2. Agent查询支付指令 │ │ Agent从核心系统获取该笔支付的全部要素： │ │ 付款账号、收款账号、金额、流水号、交易日期、摘要等 │ └──────────────────────────┬──────────────────────────────────────┘ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ 3. 文本组装为语音（TTS） │ │ Agent将支付要素按银行客服话术模板，生成为自然语音句子， │ │ 例如："您好，我想查询一笔付款是否成功， │ │ 企业账号尾号1234，金额50万元，流水号XXX……" │ └──────────────────────────┬──────────────────────────────────────┘ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ 4. 呼叫银行企业服务电话 发送语音 │ │ Agent通过电话网关自动拨打银行客服热线， │ │ 待坐席接听后，播放合成语音，并开启录音 │ └──────────────────────────┬──────────────────────────────────────┘ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ 5. 银行坐席返回语音 │ │ 坐席口头答复查询结果，Agent全程录音留存 │ └──────────────────────────┬──────────────────────────────────────┘ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ 6. Agent保存语音并识别生成报告 │ │ ASR将坐席答复语音转为文本，LLM提取关键结论（成功/失败/待查）│ │ 生成带原始语音文件、ASR文本、结论摘要的查询报告 │ └──────────────────────────┬──────────────────────────────────────┘ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ 7. Agent分发报告和通知给结算人员 │ │ 通过即时通讯、邮件或系统待办，将报告推送至指定结算人员 │ └──────────────────────────┬──────────────────────────────────────┘ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ 8. 结算人员插USBKEY批准报告 │ │ 结算人员听取录音、核验ASR文本与报告结论，确认无误后， │ │ 插入操作员USBKEY进行电子批准（确保合规与不可抵赖） │ └──────────────────────────┬──────────────────────────────────────┘ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ 9. 管理人员完成传统流程审批（如需） │ │ 按公司内控制度，涉及人工确认的交易仍需上级审批流 │ └──────────────────────────┬──────────────────────────────────────┘ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ 10. Agent根据报告调用Skill完成核心系统的人工确认 │ │ 批准生效后，Agent自动调用核心系统接口或RPA操作， │ │ 将支付指令状态强制置为"成功"或"失败"，并记录报告编号 │ └─────────────────────────────────────────────────────────────────┘

五、安全底座：RLM如何实现"数据与LLM分离"？

任何涉及资金的系统在引入AI能力时，第一个问题永远是：大模型会不会接触到我们的支付账户、客户信息、交易金额？这是财务公司敢不敢用这套方案的底线问题。

在本方案中，LLM承担的工作其实非常有限——它只需要将ASR识别出来的银行坐席答复文本，整理成一份结构清晰的查询报告（如提取"结论是成功还是失败""银行有无备注信息"等）。换句话说，LLM只负责"读懂话术并归纳"，并不需要知道这笔支付具体是谁付给谁、金额多少。

但问题是：要让LLM生成一份合格的报告，它至少要知道报告里该填哪些字段——这些字段的定义，就来自于真实的支付指令数据。如何在"让LLM理解报告结构"和"不让LLM接触真实数据"之间取得平衡？答案就是RLM（可控语言模型）做中间挡板，让LLM生成带占位符的报告模板，再由RLM把真实数据填进去。

具体实现逻辑

本方案的LLM调用只发生在阶段6（生成报告）这一环节。流程如下：

第一步：RLM提取元数据，而非真实数据

当Agent从核心系统获取到一笔支付指令后，并不直接把"付款账号、收款账号、金额、流水号"等真实信息发给LLM。而是先由RLM对这些信息做抽象，提炼出"报告需要包含哪些字段类型"——例如，RLM告知LLM：报告正文中需要预留"交易主体""交易金额""交易时间""查询结论"四个信息位，每个信息位的值是什么类型的文本（如数字、日期、状态词）。

第二步：LLM生成带占位符的报告模板

LLM基于这些字段类型的描述，生成一份结构化的报告文本，其中所有具体的值都用占位符表示。例如，LLM输出的是：

"查询结论：{{CONCLUSION}}。交易主体：{{ENTITY}}，交易金额：{{AMOUNT}}，交易时间：{{DATE}}。银行坐席回复原文：{{ORIGINAL_ASR}}。"

LLM完全不知道{{CONCLUSION}}对应的是"成功"还是"失败"，不知道{{AMOUNT}}是50万还是500万，它只是按照RLM提供的字段清单，组装了一个报告框架。

第三步：RLM填入真实数据，合成最终报告

RLM拿到这个带占位符的模板后，在本地用自己的真实数据逐一替换占位符——结论来自ASR识别结果、金额来自支付指令记录、日期来自系统时间。填完后的完整报告，全程不经过LLM，直接由RLM保存并推送至结算人员。

第四步：语音合成场景的特殊处理

本方案中的TTS语音合成环节同样遵循上述原则。用户在电话里听到的"企业账号尾号1234，金额50万元"，并非LLM生成的句子，而是RLM根据支付要素直接拼接的固定话术模板。LLM在此环节不参与任何文本生成——因为查询话术是预先设定的标准句式，只需要把真实数字填入模板即可，完全不需要LLM的语义理解能力。这样既避免了敏感信息的外流，也降低了TTS前的处理延迟。

三层安全隔离机制

在上述流程基础上，我们还建立了贯穿全程的三层安全机制：

第一层：部署隔离

LLM部署于财务公司自有的可信环境（或私有化大模型），与互联网物理隔离，不记录任何日志。RLM部署于核心业务区，与支付、账务系统直连。两者之间通过API网关通信，网关只传输字段类型描述和占位符模板，真实数据始终留在RLM侧，从不跨过这道边界。

第二层：数据脱敏

任何发往LLM的内容，都只包含字段名称、类型、格式要求等元数据，不包含任何具体的户名、账号、金额数值。LLM的输出也仅限于带占位符的报告框架，不涉及任何真实经营数据。

第三层：即时销毁

LLM完成报告模板生成后，本次会话产生的所有中间数据（字段描述、模板文本等）立即清除，不留缓存。RLM侧保留完整的操作日志，但日志记录的是"哪个编号的支付指令、于何时、调用了哪个版本的报告模板、最终结论是什么"，不记录LLM的原始输入输出，确保日后可审计但不可还原。

效果

这套设计的最终结果是：即便LLM侧发生数据泄露，外界能拿到的顶多是一堆字段类型和占位符模板，看不出任何一笔真实交易。LLM知道"报告该怎么写"，但不知道"钱去了哪里"；RLM掌握所有真实数据，但所有填充行为都在企业内网完成。数据与智能各安其位，互不越界——这是本方案敢于触碰资金业务的安全底线。

六、方案亮点与设计考量

1.零依赖银行侧接口

完全利用银行已有的客服电话通道，无需银行开放额外API或免认证策略，对非合作行同样适用。

2.人机协同，合规兜底

最终的人工确认仍由结算人员插KEY完成，Agent只负责"跑腿"和"整理"，不越权执行，符合财务公司内控与审计要求。

3.原始语音可追溯

每次查询均保留完整通话录音，作为确认依据，避免后续争议时无法举证。

4.智能降噪与语义理解

通过LLM对ASR结果做二次纠偏，能有效处理银行坐席的口音、数字确认、转接等待等复杂对话场景（测试中我们对常见话术做了专项优化）。

5.动态频率控制

Agent本身不依赖轮询，仅按需触发，不会给银行端造成重复呼叫压力，合规且礼貌。

七、实践测试情况

我们在模拟环境中完成了全流程闭环测试，覆盖了：

• 不同银行客服热线（支持DTMF按键导航的自动适配）；

• 多种支付要素组合（含跨境、大额、小额等）；

• 坐席答复的多种语义变体（成功/失败/请稍后再查/查询不到等）；

• 语音质量波动下的ASR容错与人工复核提示。

测试结果显示，Agent平均单笔查询耗时约3～4分钟（含等待接通、话术播放、录音识别、报告生成），相比人工操作效率提升50%以上，且可并发处理多路呼叫（受限于电话网关并发数）。语音识别准确率在安静环境下达到92%，对于识别置信度低于阈值的情况，报告会明确标注"需人工听取录音"的提示，确保准确性。

八、后续规划与挑战

目前方案已落盘技术验证，但距离生产上线仍需解决几个关键点：

• 电话线路合规：需与运营商确认企业外呼通道的资质与号段，避免被标记为骚扰电话；

• 银行客服流程变更应对：部分银行已引入智能语音导航（如"请按1查询…"），Agent需增加按键交互能力；

• 并发与排队处理：若同时触发多笔查询，需设计队列及超时重试策略；

• 成本与效率平衡：通话时长费用、ASR/TTS API调用成本需纳入整体ROI评估。

九、结语

银企直连的"最后一公里"困境，本质是系统间闭环与人工兜底之间的断层。我们选择用Agent去弥合这个断层——不是试图改造银行，而是让机器去适应银行现有的服务方式（电话）。这不仅解放了结算人员的重复劳动，更让成员单位在关键时刻获得了"可感知的响应速度"。

或许未来，当银行全面开放实时支付状态推送时，这套方案会显得"笨拙"。但在当下，它为我们提供了一条低成本、低风险、可落地的应急兜底路径。

技术不必永远追求颠覆，有时，恰到好处的"仿真"就是对业务最大的善意。