一、为什么AI电话机器人不能只测并发量？

AI电话机器人的高并发验收，需要回答三个问题：系统能否承载目标数量的通话，客户说完后机器人能否及时响应，以及机器人能否在持续负载下正确完成业务任务。

这三个问题分别对应通信承载、实时语音交互和业务执行。通信层负责呼叫接入、话务调度与媒体传输；语音交互层涉及语音识别、话轮检测、模型推理和语音合成；业务执行层负责信息采集、系统调用、工单创建和结果确认。任何一个环节出现瓶颈，都可能影响最终服务效果。

例如，SIP信令压测显示系统能够建立目标数量的呼叫，并不代表AI语音处理也能保持稳定的响应速度。机器人能够正常回答，也不代表高负载下的工单创建和业务状态更新都能成功。

SIPp可以用于模拟SIP呼叫、测试呼叫建立速率和测量信令响应时间。但其官方性能测试文档明确指出，计时精度受到定时器配置和系统调度负载影响。因此，通信压测结果需要结合测试工具自身的运行状态解读，SIP信令测试也不能替代完整的AI语音交互和业务任务测试。[1]

建议将验收划分为三个层次：

测试层次	核心问题	主要验收指标
通信承载	目标并发下能否正常建立和维持通话	呼叫建立失败率、异常掉话率、线路切换时间、告警响应
实时语音交互	机器人能否及时响应并正确处理打断	响应延迟、超时率、打断检测延迟、播报停止延迟、正确接续率
业务任务执行	机器人能否完成预期任务	任务完成率、独立解决率、工具调用成功率、参数正确率、转人工率

三个层次需要分别验证，最后在相同的目标负载下联合测试，才能判断系统能否在高并发条件下持续提供服务。

二、如何搭建可复现的高并发测试环境？

高并发测试首先要明确负载条件，并确保每次测试都能追溯到具体的呼叫、语音交互和业务任务。

1. 明确并发量、呼叫速率和通话时长

并发通话数、呼叫建立速率和总呼叫量是三个不同的指标。

• 并发通话数： 同一时刻正在进行的通话数量。

• 呼叫建立速率（CPS）： 单位时间内成功建立的呼叫数量。如果统计的是发起请求数，应单独记录，不能与成功建立数混用。

• 总呼叫量： 测试期间发起或成功建立的呼叫总数，需要明确统计口径。

• 通话时长分布： 不同通话的持续时间会影响连接占用、语音处理和业务接口的累计负载。

假设目标是同时维持100路通话，就需要说明如何建立并维持这100路连接。如果业务高峰还要求每秒建立多路新呼叫，则应额外设置CPS目标。

只写“模拟100路并发”不足以描述测试负载。正式测试前，还应确定目标并发、CPS、通话时长分布、测试持续时间和允许的失败率。

1. 测试环境需要覆盖哪些组件？

组件	需要记录的内容	主要作用
呼叫发生器	工具、主机配置、呼叫脚本、负载分布	生成可控的测试呼叫
SIP与通信链路	SBC、PBX、线路、媒体传输方式	验证呼叫建立与音频传输
AI语音处理链路	ASR、话轮检测、模型、TTS配置	观察语音处理与生成延迟
业务接口	接口响应时间、超时与重试规则	验证查询、预约、建单等操作
监控与日志	时间戳、会话ID、请求ID、错误日志	关联问题发生的时间和执行环节

压测工具本身也可能成为瓶颈。测试前应检查CPU、网络带宽、连接数及媒体处理能力，确认呼叫发生器能够提供目标负载。必要时使用多台发生器分担流量，并记录工具自身的资源使用情况。

通信系统、AI服务和业务接口如果部署在不同环境中，还应统一时间基准并记录时钟偏差，避免直接比较无法对齐的时间戳。

1. 采用阶梯加压，逐步识别性能边界

建议按照以下顺序开展测试：

1. 基线测试： 使用单路或少量并发，确认业务流程正确并记录基础延迟。

2. 阶梯加压： 逐步提高并发量，观察响应延迟、错误率和资源使用情况。

3. 目标负载测试： 在预期业务并发下持续运行，检查系统稳定性与任务结果。

4. 峰值测试： 模拟集中来电或短时突增，观察排队、超时和失败情况。

5. 容量边界测试： 在明确的资源与安全边界内继续加压，识别性能开始退化的区间。

6. 回归测试： 修复问题后重复相同用例，验证优化是否有效。

每个阶段都应记录实际并发量、CPS、通话时长分布、有效测试数、失败数和资源使用情况。具体负载梯度与持续时间应由项目目标决定，不能将某个固定并发数当作所有电话机器人的通用验收标准。

三、通信承载层怎么测？从呼叫建立到线路切换

通信承载层需要验证呼叫能否建立、已建立的通话能否正常维持，以及主线路出现故障后系统能否按照预设策略恢复服务。合力亿捷智能呼叫中心的公开产品资料涉及号码与线路资源、话务管理、SIP/AXB监控及容灾；产品页面还介绍了实时话务监控和异常预警能力。[4][5]

这些产品能力可以转化为以下测试项目，但是否达到项目要求，需要通过实际测试确认。

1. 呼叫建立失败率：什么情况算接通成功？

呼叫建立测试应使用有效的测试号码和可控的接听端，并提前约定成功建立通话的判定条件。

对于普通电话呼叫，建议至少检查：

• 呼叫是否到达预期的被叫端；

• 信令是否完成约定的接通流程；

• 双向媒体是否可用；

• 是否出现超时、信令错误或单通等异常。

仅收到振铃或接通信令，不一定代表媒体链路正常。因此，通信承载验收可以将“成功建立通话”和“成功建立双向媒体”分别记录，避免将媒体故障隐藏在呼叫成功率中。

在受控测试环境中，可以使用自动应答的测试端点，确保测试呼叫具备明确的接通预期。

呼叫建立失败率（%）= 系统或通信链路导致的建立失败次数 ÷ 有效呼叫尝试总数 × 100%

这里的有效呼叫尝试，是指测试号码有效、呼叫符合预设规则且预期可以建立的测试请求。无效号码、被叫忙、被叫未应答、用户拒接及合规规则主动拦截等情况，应分别记录，不能全部归为系统故障。

同时应保留失败原因分类，例如信令拒绝、线路不可用、建立超时和媒体建立失败。只看总失败率，无法判断故障究竟发生在哪个环节。

验收判据： 在约定的CPS和目标并发下，系统侧呼叫建立失败率应满足项目SLA；媒体可用率也应达到项目规定的要求。具体阈值需要在测试前确定。

1. 异常掉话率：如何区分正常挂断和异常中断？

呼叫建立成功后，还需要验证通话是否能够持续到预期结束。

测试前应为每个场景定义正常结束条件，例如客户完成对话后主动挂断、脚本执行到指定终点，或者业务流程按规则结束通话。

以下情况可以纳入异常掉话排查：

• 通话在预期结束前意外断开；

• 系统或线路异常释放通话；

• 媒体传输中断，导致通话虽然未释放但无法继续正常交互；

• 目标负载下出现非预期的连接丢失。

异常掉话率（%）= 非预期中断的已建立通话数 ÷ 已建立的有效通话总数 × 100%

分母应采用已成功建立的有效通话，而不是所有呼叫尝试。正常挂断、测试脚本预期结束和客户按场景主动终止等情况，不应计入异常掉话数。

对于媒体中断，还应单独统计，避免只检查SIP会话是否仍然存在。测试报告应同时保留异常发生时间、通话ID、释放原因、媒体状态和当时的并发负载。

验收判据： 在目标并发和持续时间下，异常掉话率应低于项目约定上限；媒体异常也应满足预先设定的恢复或失败条件。

1. 线路切换：如何证明备用线路真正生效？

产品具备线路冗余或容灾能力，不代表故障发生后一定能够在指定时间内恢复业务。线路切换必须通过受控故障测试验证。

建议在获准的测试环境中执行以下步骤：

1. 确认主线路、备用线路、路由规则和监控策略均已配置。

2. 记录测试开始时的正常呼叫建立情况。

3. 通过关闭测试线路、模拟网关不可用或其他获准方式触发主路径故障。

4. 记录系统发现故障、触发切换、选择备用路径和首次成功建立新呼叫的时间。

5. 持续发起测试呼叫，确认备用路径可用，且没有出现路由循环或持续失败。

6. 恢复主线路，按项目策略验证是否需要自动回切，以及回切过程是否引入新的异常。

建议至少记录以下时间点：

时间点	记录内容
T0	主路径故障被触发的时间
T1	系统检测到故障的时间
T2	系统开始使用备用路径的时间
T3	通过备用路径成功建立首通测试呼叫的时间

从故障触发到备用路径恢复新呼叫的时间，可按 T3 − T0 计算；故障检测耗时可按 T1 − T0 计算。还应记录切换期间的呼叫失败数和媒体异常。

验收判据： 备用路径应在项目约定时限内恢复新呼叫建立；切换过程中不得出现非预期路由循环，切换失败应能被监控发现并记录。

在途通话是否能够保持，需要单独测试，并依据系统架构和项目要求判定。不能仅凭新呼叫已恢复，就认定切换期间的所有在途通话都没有中断。

1. 异常告警：系统发现故障后，能否完成处置？

告警测试不仅要验证系统是否生成告警，还要检查告警是否送达、是否有人确认，以及未确认时是否按规则升级。

建议选择呼叫建立失败率超限、排队时间过长、线路不可用等可控场景，执行以下步骤：

1. 预先配置告警阈值、通知渠道、责任人和升级规则。

2. 在测试环境中触发约定异常。

3. 记录异常发生时间、告警生成时间和告警送达时间。

4. 由指定人员确认告警，并记录确认时间与处理结果。

5. 模拟告警未被确认的情况，检查系统是否按预设规则升级通知。

6. 恢复正常后，确认告警状态是否更新，相关事件是否留有记录。

验收判据： 告警应在项目规定时限内生成并送达指定接收人；责任人应在约定时间内确认；未确认告警应按规则升级。具体告警阈值、确认时限和升级时限应在项目启动时确定。

合力亿捷智能呼叫中心的公开资料介绍了实时话务监控及排队、异常指标预警等能力。[4] 企业可以围绕这些能力设计告警测试，验证实际部署中的告警规则、通知链路和处置流程，而不能将产品具备告警能力直接视为告警链路已经通过验收。

四、响应延迟怎么测？为什么平均值不够？

响应延迟反映客户说完话后，需要等待多久才能听到机器人回应。测试时应区分端到端响应延迟和内部处理耗时，并同时观察长尾延迟与超时情况。

1. 明确端到端响应延迟的起止点

建议将一次响应的时间线定义为：

用户语音结束 ↓ 系统判定话轮结束 ↓ 语音识别与意图处理 ↓ 模型推理 / 必要的业务工具调用 ↓ 语音合成与音频传输 ↓ 机器人首段有效语音到达播放端

端到端响应延迟定义为：用户语音结束时间至机器人首段有效语音到达播放端的时间差。

OpenAI的语音Agent技术指南建议测量用户等待有效语音回答的时间，并将后端处理耗时与整体响应延迟分开观察，以定位连接、模型处理、工具调用、缓冲或播放环节造成的延迟。[2]

测试时建议分别记录用户语音结束、系统判停、模型请求、工具调用、首段音频生成和实际播放等时间点。用户语音结束与系统判定话轮结束之间的差值，可以用于分析话轮检测是否引入额外等待。

还应区分两类时间：

• 首段音频延迟： 从用户语音结束到机器人开始播放声音的时间。

• 有效答案延迟： 从用户语音结束到机器人开始提供解决当前问题所需的实质性回答的时间。

例如，机器人很快说出“我帮您查询”，但随后等待数秒才返回订单状态。这次交互的首段音频延迟较短，有效答案延迟却可能较长。两者应分别统计。

如果测试环境只能测量服务端生成音频的时间，就应将指标标记为服务端响应延迟，不能直接等同于用户实际听到回应的时间。

1. 同时统计P50、P95、P99和超时率

平均值容易掩盖少数严重延迟的请求。建议至少报告以下指标：

指标	说明	用途
P50	50%的有效样本响应延迟不超过该值	观察典型表现
P95	95%的有效样本响应延迟不超过该值	观察大多数请求的响应情况
P99	99%的有效样本响应延迟不超过该值	识别长尾延迟
超时率	超过规定时限的有效请求比例	衡量未能及时响应的情况
响应成功率	在规定时限内产生有效响应的请求比例	衡量及时响应能力

OpenAI的语音Agent技术指南建议比较中位数和P95；本文进一步建议在对长尾延迟要求较高的场景中增加P99，作为项目验收的补充指标。[2]

计算时必须明确样本范围。超时、未响应和无效测试应分别记录，不能只对成功请求计算分位数，再忽略没有响应的请求。

例如，如果项目要求首段有效语音在指定时限内到达，那么超时请求即使最终完成回答，也应计入超时统计。响应延迟分位数应与响应成功率、超时率一起解读。

1. 结合电话Agent运营指标，区分监控与专项测试

合力亿捷电话Agent的公开产品资料介绍了语音交互、流式响应、业务流程执行，以及自主服务率、满意度、转人工率等运营指标。[5] 相关产品资料还列出了任务完成率、独立解决率、接通率和客户意向率等电话侧运营指标，并介绍了通话过程与执行结果追踪能力。[6]

这些指标适合分析服务结果和运营效果，但不能直接替代专项性能测试。例如，接通率反映呼叫接通情况，不能单独说明机器人开始回答的速度；任务完成率也不能推导出P95或P99响应延迟。

测试前应确认现有监控、日志和测试工具能够提供哪些时间戳。缺少分阶段时间戳时，再通过测试环境补充采集。不能将在线客服Agent的在线会话数、并发用户数、平均响应时间和会话时长等监控项，直接当作电话Agent原生提供的监控指标。

五、打断处理怎么测？停止播报不等于处理正确

电话对话具有实时性。客户可能在机器人播报时插话、补充信息、纠正之前的回答，也可能只是简单地说“嗯”“好的”。

打断测试需要同时验证话轮切换和后续任务正确性。机器人停止播放旧内容，只能说明播报发生了中断，不能证明系统已经正确理解客户的新指令。

1. 分别测量打断检测、播报停止和正确接续

建议采用三个独立指标。

打断检测延迟： 从用户开始有效插话，到系统检测到需要切换话轮的时间差。

播报停止延迟： 从用户开始有效插话，到机器人旧播报在实际播放端停止的时间差。测试时应考虑音频缓冲和电话链路延迟。

打断后正确接续率： 在有效打断用例中，机器人正确理解新指令、保留有效上下文并完成预期后续动作的比例。

打断后正确接续率的计算方法为：

打断后正确接续率（%）= 通过的有效打断用例数 ÷ 已执行的有效打断用例数 × 100%

OpenAI的语音Agent评估指南将响应延迟、交互中断和任务完成作为不同的评估维度，说明语音交互表现与任务执行结果需要分别检查。[3]

每个打断用例都应预先规定允许的停止时间、预期理解结果和禁止动作。涉及预约或建单时，还要核对最终业务记录，防止机器人停止播报后仍执行已经被客户修改的旧指令。

1. 建立覆盖真实通话的打断用例

测试场景	输入行为	预期结果
中途停止	用户说“先停一下”	在规定时限内停止旧播报
修改信息	用户把预约日期从周三改成周四	后续操作使用新日期
补充信息	用户插话补充订单号	保留已有字段并处理新增信息
连续插话	用户连续追问和修正	正确区分新诉求与原任务
简单附和	用户说“嗯”“对”	不因简单附和频繁误切话轮
背景噪声	通话中出现其他人说话	尽量避免把无关声音识别成有效指令

每个场景应在基线负载、目标并发和峰值负载下重复测试，并记录测试次数、有效样本数、失败原因和实际时间戳。还应单独统计误打断率，避免系统为了更快响应而频繁误判客户已经说完。

合力亿捷电话Agent的公开资料介绍了多轮语音交互、语音打断和流式响应等能力。[4][5] 这些能力可以转化为上述测试用例；具体打断延迟和正确接续率仍需通过项目测试验证。

六、任务完成率怎么计算？必须核对真实业务结果

任务完成率是判断AI电话机器人能否在高并发下持续交付业务结果的关键指标。

一次通话即使正常接通、对话流畅、工具调用成功，也可能因为参数错误、业务规则不满足或最终状态未更新而失败。因此，任务验收必须以预先定义的业务结果为依据。

1. 先定义每类任务的完成条件

以电话报修为例，验收条件可以包括：

1. 正确理解报修意图。

2. 采集创建工单所需的必要信息。

3. 正确调用工单接口。

4. 确认工单创建成功，且客户、设备和故障信息正确。

5. 向客户准确告知处理结果。

如果机器人调用接口失败，却仍然告诉客户“报修已完成”，这次任务不能判定为成功。

如果任务要求信息不足时追问，或者达到风险条件时转人工，那么按预设规则正确追问或转接，也可以算该场景通过。是否成功应依据事先定义的业务目标，而不是要求每通电话都必须由AI独立办结。

OpenAI的语音Agent评估指南强调，任务评估应检查实际对话行为、工具活动和预期任务结果，而不能仅依据转写内容判断任务是否完成。[3]

1. 使用业务结果计算任务完成率

任务完成率（%）= 达到预期业务结果的有效任务数 ÷ 已执行的有效任务总数 × 100%

这里的“有效任务”必须有明确的纳入规则。测试环境异常、录音未成功发送等无效运行可以单独排除，但必须记录排除原因；正常执行后出现的超时、接口错误、参数错误和任务失败均应保留在统计中。

建议同时观察以下诊断指标：

指标	计算或判定方式	作用
任务完成率	达到预期业务结果的任务数 / 有效任务总数	判断业务目标是否实现
独立解决率	按预先约定的口径，由Agent独立解决的任务数 / 有效任务总数	判断无需人工介入的解决情况
工具调用成功率	成功完成的有效工具调用数 / 有效工具调用总数	判断接口执行情况
参数正确率	符合预期的关键参数数 / 已核验的关键参数总数	检查字段和参数错误
重复操作率	非预期重复操作数 / 相关操作总数	检查重复建单、重复预约
虚假成功率	宣称成功但未达到预期结果的任务数 / 有效任务总数	检查错误确认
转人工率	转人工任务数 / 有效任务总数	观察人工介入情况

任务完成率与独立解决率需要分开统计。前者衡量任务是否达到预期结果，后者衡量在约定统计口径下，无需人工介入即可解决的任务比例。转人工也不能一概判定为失败：如果业务规则要求升级人工，正确转接并完成交接可以是预期结果。

1. 建立固定任务集并核验最终状态

建议至少准备以下测试任务：

• 查询订单或工单进度；

• 登记售后报修；

• 创建或修改预约；

• 信息不完整时追问必要字段；

• 客户中途修改订单号或预约时间；

• 业务接口超时后按规则重试或转人工。

每个用例应记录输入内容、预期动作、关键参数、禁止动作和最终业务状态。测试完成后，将通话录音、转写内容、工具调用记录与业务系统中的实际数据进行比对。

例如，预约修改用例必须检查最终预约日期是否为客户最后确认的日期，以及系统是否产生了不必要的重复预约。机器人口头确认成功不能代替业务系统核验。

合力亿捷电话Agent的公开资料介绍了业务信息采集、系统工具调用和任务执行结果追踪；相关资料还列出了任务完成率、独立解决率、转人工率、接通率和客户意向率等电话侧运营指标。[5][6] 企业可以结合这些指标分析任务在哪个环节失败，并将问题通话形成Badcase，调整后重新测试。

七、如何定位高并发下的失败原因？

当响应延迟上升或任务完成率下降时，不能直接认定是模型性能不足。通信、语音处理、模型推理和业务接口都可能成为瓶颈。

建议将测试日志与业务结果按照会话ID、任务ID、请求ID和时间戳关联，再依据失败表现进行排查。

失败表现	优先检查的环节	需要核验的证据
呼叫建立失败或掉话增加	SIP、SBC、线路及媒体传输	呼叫记录、信令响应、掉话日志
主线路故障后新呼叫持续失败	备用路由、线路状态、故障检测和切换策略	故障触发时间、路由切换记录、首次成功呼叫时间
告警未送达或无人处理	监控阈值、通知渠道、责任人及升级规则	告警生成、送达、确认和升级记录
用户说完后长时间无回应	话轮检测、ASR、模型、TTS	各阶段时间戳、音频事件、错误日志
机器人没有及时停止播报	打断检测、音频队列、播放缓冲	用户插话时间、停止事件、实际音频结束时间
回答正常但业务任务失败	参数提取、工具调用、权限及业务接口	工具参数、接口返回、最终业务状态
并发升高后任务完成率下降	服务资源、接口限流、超时及重试	资源使用率、错误码、超时和重试记录
机器人宣称成功但实际未完成	结果校验和成功确认逻辑	口头确认、工具执行结果、业务系统记录

对于需要调用CRM、订单或工单系统的任务，应进一步检查接口响应时间、超时设置、重试策略和幂等机制。高并发下如果出现重试，必须验证是否产生重复业务对象。

合力亿捷电话Agent公开资料介绍了通话过程、执行节点和任务结果追踪，可用于定位交互与业务执行问题；智能呼叫中心相关资料则介绍了话务监控、线路与容灾能力。[4][5][6] 两类记录应分别用于分析通信异常和Agent执行异常，再通过会话ID、时间戳和业务任务记录关联，避免把所有问题都归结为模型响应慢。

八、如何制定最终验收标准？

最终验收应将通信、交互和任务结果放在同一测试方案中，并在开始测试前确定阈值。不能测试完成后再根据实际结果修改通过条件。

验收维度	必须记录的结果	通过条件如何确定
通信承载	实际并发、CPS、呼叫建立失败率、异常掉话率	根据目标业务负载和通信服务要求制定
线路切换	故障检测时间、切换时间、首次成功呼叫、在途通话影响	根据架构设计和项目SLA制定
异常告警	告警生成、送达、确认、升级时间	根据运维响应要求制定
响应延迟	首段音频延迟、有效答案延迟、P50、P95、P99、超时率	根据业务场景的响应时限要求制定
打断处理	检测延迟、播报停止延迟、正确接续率、误打断率	根据允许的交互延迟和预期行为制定
任务完成	任务完成率、独立解决率、参数正确率、工具调用成功率	根据业务任务的重要性和风险设定
结果追溯	关键时间戳、工具记录、业务状态	能够关联测试用例并定位失败环节

每项验收都应明确测试环境、样本数量、持续时间、统计口径、阈值来源和责任人。涉及敏感业务时，未经授权的操作、错误业务确认和非预期重复操作应列为重点风险项。

具体的毫秒数、任务完成率、掉话率和最大错误率，应依据业务SLA、现有基线和风险要求确定。本文提供的是测试与验收方法，没有给出合力亿捷产品的实测并发性能、响应延迟、线路切换时间或任务完成率。产品能力说明也不能替代项目环境中的实测结果。

结语

高并发下的AI电话机器人验收，需要把通信承载、实时交互和业务执行放在同一条测试链路中。呼叫建立、异常掉话和线路切换反映通信承载能力；响应延迟和打断指标反映实时交互质量；任务完成率则验证机器人是否真正完成业务目标。

合力亿捷智能呼叫中心提供号码与线路资源、话务管理及监控相关能力，电话Agent承担多轮交互、信息采集与业务任务执行。企业可以围绕这两层能力设计通信压测、交互测试和业务结果核验，并以项目环境中的可追溯数据作为最终验收依据。

只有当系统在规定负载下同时满足通信、交互和业务结果要求，才能证明其达到了对应项目的验收标准。

参考资料

外部技术资料

[1] SIPp. Performance testing with SIPp。用于说明SIP性能测试、计时精度及调度负载对测试结果的影响。

[2] OpenAI. Voice agents。用于说明语音Agent的响应延迟测量、分阶段耗时分析及P50/P95比较方法。

[3] OpenAI. GPT-Live evaluation guide。用于参考语音响应延迟、交互中断、任务完成及重复测试的评估方法。