应用实践｜从“说得快”到“把事办完”：qwen-audio-agent 的客服实践

假设客户接通电话后，只说了一句：“帮我取消之前买的无线耳机。”

对客户来说，这只是一个目标，不需要知道订单该怎么查、退款资格如何判断，也不需要把后台系统要求的每一步拆成指令。接下来的业务步骤，应该由客服 Agent 主动推进，并在需要时向客户补充询问或请求确认。

先看这段实际演示。

在这句话之后，系统依次完成了这些工作：

视频中，客户第一次说错了身份证后六位，系统允许客户自然纠正；核验成功后查到订单 W1082334，计算出 899 元原路退款。直到客户明确回答“可以”，系统才真正取消订单，并依据提交结果告知退款预计 3 到 7 个工作日到账。

在采用预设对话流程的客服系统中，开发者会配置需要收集的信息，以及不同条件下的流转路径。这是一种可行的实现方式；对于预设路径之外的诉求，需要另外设计相应的处理方式。

这个客服示例采用了另一种组织方式：对话怎么推进、下一步查询什么、该调用哪些工具，由 Agent 根据当前上下文和工具结果动态决定；身份、资格、金额、库存等业务约束，则由业务服务（Service）和规则校验机制（Policy guard）进行确定性校验。

回到这通取消耳机订单的电话。客户听到的是一位语音客服，系统内部则由 Realtime 前台和后台 Agent 协作完成办理。

前台负责与客户交流、核验身份和查询订单；找到需要取消的订单后，再把办理目标交给后台 Agent。后台继续检查取消资格、计算退款、生成预览，并在获得授权后完成提交。前台负责把需要补充的信息、确认内容和办理结果传达给客户。

这种分工首先要解决两个问题：前台交给后台时，不能丢掉客户刚刚说过的话；后台真正修改业务数据时，也不能把客户对 A 订单的“可以”用到 B 订单上。

保证前后台交接顺畅

新版还把“真正去执行”变成了前台的硬要求。面对明确的状态变更、退款、补偿、权益或人工转接请求，一轮交互结束时，必须进入以下四种情况之一：

• 已通过前台工具完整执行；

• 已将任务委派给后台；

• 已依据业务规则（Policy）明确拒绝；

• 已向客户追问一项确实缺失的必要信息。

系统不能只解释一遍规则、承诺稍后处理，然后停在那里。

交接任务，也要交接必要的上下文

这里需要澄清一个容易混淆的边界：A2A 协议本身支持 Task 内的消息历史和上下文连续性，但不会自动把新 Task 创建之前、发生在语音前台的整段对话带给后台 Agent。早期实现主要依赖一段任务目标说明（objective）完成交接，客户已经确认的目标、限制条件和精确编号可能在自然语言压缩中丢失，后台因此容易重复询问、选错对象或漏掉条件，任务成功率也会随交接质量波动。

在这通电话里，前台通过 spawn_thinking 创建 A2A Task，把取消耳机订单的目标交给后台。每个任务不仅获得明确的 objective，还会带上最近最多十轮客户与客服对话，让后台能够理解客户的纠正，以及最终确认的目标。

对话历史只是帮助后台理解“客户刚才在说什么”，不是可信的工具日志。objective 仍然要写清楚客户目标、选择、关键编号和前台已经查到的业务事实。

除了对话和目标说明，交接时还会附上一份结构化查询记录，并限制记录数量和长度。与当前目标相关、并且已经成功完成的前台只读调用，会把精确查询参数自动附在任务后面。例如前台查询过的订单编号，就可以原样传给后台，减少自然语言转述时遗漏或改错字符的风险。

这份记录只证明“前台曾经用这些参数完成过查询”，不代表身份、授权或当前业务状态；查询返回内容默认也不会整段回放。后台写入之前，仍然必须重新读取最新状态并按 Policy 判断。

任务需要补充信息或客户批准时，后台不会结束任务再新开一轮，而是通过 A2A 的input_required（需要补充信息）或 auth_required（需要授权）状态挂起。前台继续与客户交流，再把答复交回同一个 Task，后台从原来的执行位置恢复。

对于客户而言，这仍然是一通连续的电话。

分工不同，但共用同一份业务状态

前台和后台分别看到不同的 MCP 工具面：

• 前台工具面是白名单子集，主要包含核验、只读查询和转人工；

• 后台工具面包含需要批准的写操作和组合任务。

但两个工具面最终调用的是同一个 Service、同一个 executor 和同一份业务状态。金额、库存、资格和订单状态不由模型各算一遍，避免前台说一套、后台执行另一套。

视频中，客户听到订单和 899 元退款预览后回答“可以”。系统需要确保，这次确认只用于刚刚展示的那笔取消操作。

为此，写操作采用两段式执行：先生成预览，获得确认后再提交。

先预览，再提交

第一段只预览，不写入。 后台调用取消工具后，业务服务检查订单状态和规定，计算退款金额、去向和预计到账时间。此时真实订单仍然没有变化。

返回预览时，executor 会同时保存工具名、原始参数、Task 上下文和一次性批准令牌，并发出 auth_required。客户只能听到可读的业务预览，内部令牌和执行指令不会进入确认话术，也不会交给模型自行拼装。

第二段获得确认，再提交。 前台把客户的决定交回同一个 A2A Task。只有明确的 accept（接受） 才会触发 executor 提交之前保存的原操作；decline（拒绝）、cancel（取消）、超时或重复使用令牌都会终止写入。客户如果改变了目标商品或退款方式，就需要重新生成预览并获得确认。

令牌按 Task 隔离，五分钟有效，一次性消费，并绑定操作、对象、参数、版本和原始业务状态。这样，一次“同意”不能被拿去批准另一笔订单，也不能在订单已经变化后继续执行旧报价。

客户已经同意过的方案，如何交给后台

新版还处理了另一种常见情况：客户在任务委派之前，已经对前台给出的具体方案明确表示同意。Gateway 会把“客服刚才提出的方案 + 客户紧接着的答复”作为有界授权证据，通过 A2A metadata 交给后台。

这并不意味着后台可以跳过检查。每一笔写操作仍然先生成自己的精确预览，再由语义授权器判断它是否完全落在客户已经同意的方案内。一次批准可以覆盖同一个已披露结果所必需的多步写入，但不能增加新的费用、目标、商品、乘客、日期或偏好；只要范围扩大，系统就会再次向客户确认。

模型负责理解客户表达，真正的授权边界则由运行时保存和校验。

执行到哪一步，就说明到哪一步

提交之后，前台还要依据工具返回的真实结果向客户说明进展。在这个例子里，“退款已发起”和“预计 3 到 7 个工作日到账”必须明确区分，不能把正在处理的退款说成已经到账。对于包含多个修改的请求，后台也要先检查这些操作是否互相冲突，必要时让客户选择可执行的方案。‍

前面的交接、授权和人工接管机制，最终呈现在客户侧和管理侧两个视角中。

客户侧：一通始终在线的语音服务

客户从这里发起语音通话。页面展示实时对话、核验状态、订单或预订数据以及工具调用审计；测试者可以重置当前客户或换一位客户，避免上一通会话的身份、任务和批准泄漏到下一通。

Policy 缺失、金额超权限或客户明确要求人工时，系统会把转接原因、客户状态和已经完成的步骤一起交给人工座席，让人工接手后不必从头再问。当前实现是本地状态交接，用于展示完整上下文，不是外部呼叫中心集成。

管理侧：修改 Policy 和业务数据

为了方便体验和验证不同客服场景，管理侧可以修改 Policy、决策表、处理流程、前后台工具归属和演示数据库。例如，可以调整退款条件、金额权限或订单状态，再从客户侧重新发起一通电话，观察 Agent 的判断和执行结果如何变化。

不同配置的生效时机有所区别：

• 决策表：在下一次工具调用时生效；

• 流程：在下一个后台任务中生效；

• Gateway 可用工具的变化：需要重启对应领域。

每次修改都可以查看字段差异，并保留备份和审计记录。

在两个视角背后，每个领域实际运行五个进程：客户端（Client）、网关（Gateway）、后台 Agent（A2A Agent）、业务服务（Service）和人工坐席端（Desk）；规则管理控制台（Policy Console）独立运行，不占通话关键路径。

从取消订单，到退票改签

前面围绕取消耳机订单介绍的交接、预览、确认和执行机制，也用于其他业务。客服示例目前包含零售和航空两个领域，共用同一套运行时和业务骨架。

更换领域配置，会同时切换客服人设、前台工具面、Policy 检索源、决策表、流程提示和示例数据库。体验者可以在管理侧调整对应领域的规则和数据，再到客户侧提出“帮我退货”或“帮我改签”，观察同一套机制如何完成不同任务。

对比三条执行路径

Demo 展示了一个具体案例，评测要回答的是：换成不同订单、不同限制和不同用户表达，这套系统还能不能稳定完成任务。

因此，我们基于 50 条公开的航空客服任务，构造了三条可比较的执行路径：

• Realtime only：Qwen Audio 3.0 Realtime Plus 直接完成对话和工具调用；

• Customer Service Harness：Realtime 前台持续交流，复杂任务通过 Gateway 和 A2A 交给 Qwen3.8-Max 后台，再经过 MCP 与批准链路执行；

• Max baseline：Qwen3.8-Max 直接处理识别文本和业务工具，不经过前后台委派链路。

任务覆盖改签、取消、航班异常处理、行李、补偿，以及需要拒绝、协商或转人工的情况。

同时检查业务结果与沟通要求

每条任务都从一份隔离的初始数据库开始，同时给出完整 Airline Policy、原始 Function Calling schema、目标数据库状态和对话断言。

对话结束后，评测器会重放实际工具调用，检查最终数据库是否达到目标状态，再判断沟通中的必要要求是否满足。执行步骤不必与参考轨迹完全相同，只要结果等价即可，

对于拒绝、隐私保护或转人工任务，则检查数据库是否保持不变、是否留下正确的转接记录，以及 Agent 有没有按 Policy 向客户说明。只有这些条件同时满足，任务才算完成。

接入完整的音频链路

评测增加了中英文合成音频输入。用户模拟器先生成发言，再由 qwen3-tts-flash 合成语音，以流式 PCM 输入被测系统。

• Realtime only 直接接收合成音频；

• Harness 走真实 Gateway 音频链路，再完成前后台委派、批准和业务执行；

• Max baseline 也先经过同一个 Realtime ASR 边界，只把识别文本交给 Qwen3.8-Max，避免给纯文本基线使用“无识别误差”的原始文本。

英文和中文各包含 50 条任务，均使用 Qwen3.8-Flash 作为用户模拟器和对话断言评判模型（judge），并发为 8，单任务时长上限为 500 秒。两种语言使用相同的工具 schema、Policy、终态目标和任务覆盖；中文集只对对话、身份信息和城市进行本地化，并采用更适合语音识别的确认号。

在合成音频输入下，Harness 相比 Realtime only，英文任务完成率从 62% 提升到 76%，中文从 48% 提升到 80%。这个结果更接近语音客服的真实链路：用户输入先经过 TTS 音频和 ASR，再进入对话、委派与业务执行。

这仍然不是对真人通话的完整评测。合成音频可以稳定复现协议和识别问题，但不包含麦克风噪声、回声、自然停顿、打断和真人语音差异。文本与音频结果也分别统计，不能混成一个分数。这组实验借鉴EVA-Bench-mix 的 Airline 任务并适配到 tau2 风格的对话与终态评分协议，不是官方榜单成绩。

从取消订单到退票改签，这次实践关注的是同一个问题：如何在持续的语音交流中，把客户的目标转化为可执行、可确认、可核验的业务结果。前台保持交流，后台推进任务，业务规则与授权机制约束执行，共同支撑客服 Agent 从“回应诉求”走向“完成办理”。

 往期推荐 

 Recommend 

                            

记得关注