用16类通话场景验收语音Agent

选语音 AI，声音自然、演示顺畅，只能说明它值得进入候选名单。能不能上线，还要看它在真实电话线路里能否完成任务、纠正误听、处理工具失败，以及在转人工后保住上下文。

原文提出了一套买方主导的验收方法：用统一场景比较完整服务链路，再单独比较各产品推荐的生产配置。它没有公布任何厂商成绩，价值在于把「听起来不错」拆成可以检查的结果。对接过业务 API 的程序员，尤其值得看它如何区分模型回答与系统实际状态。

比较对象应该是一通完成任务的电话

「Voice agent」可能由语音识别、对话逻辑、语言模型、语音合成、电话服务和业务工具串起来，也可能采用直接处理音频的模型。产品名称相同，故障发生的位置却可能完全不同。

因此，测试前要先画清系统边界：从电话号码或浏览器入口，到运营商、音频处理、模型、提示词、知识库、工具权限、预约系统，再到人工队列、日志存储和计费。浏览器麦克风测试，覆盖不了真实公共电话网络（PSTN）的全部条件。

成功标准也要落到可观察的状态。「语气亲切」无法证明预约成功；「在授权日历里创建可用时段，向来电者复述日期时间，并通过指定渠道发送确认」才方便验收。同时写清禁止结果，例如未经确认就预约、泄露他人记录、编造空闲时段。

没有转人工，不等于问题已经解决。

如果用户挂断后还要再打一遍，或者系统创建了重复预约，自动接待率再高也没有完成任务。主要指标应当是符合既定规则的成功解决，而不是把用户留在自动化流程里的比例。

原文据此提出两条测试轨道。Track A 固定脚本、数据、电话条件和评分规则，尽量控制共同变量；Track B 允许各产品采用文档推荐的生产配置，给予相同准备预算，并记录配置时间和额外依赖。前者帮助分析产品差异，后者帮助判断真实部署是否划算。两条轨道合成一个排行榜，会丢掉这个区别。

16 个场景用于找问题，不能证明生产成功率

作者给出的验收集定位很克制：它是 2026 年 11 月 9 日编写的合成场景，用于初筛和发现问题。16 这个数量是设计选择，没有统计学上的样本量依据，也没有真实来电、厂商执行或准确率结果。

这里还有一个输入限制：提供的原文没有列出完整的 S01—S16 场景表，结尾也在无障碍部分截断。因此，能提炼测试方法，但不能据此还原全部测试脚本。

已展开的几组场景，足以看出重点：

• S04、S05 涉及音频和识别问题。失败可能来自麦克风、编解码器、运营商、语言配置或语音活动检测（VAD），不能全部归到模型头上。
• S07、S08 检查工具调用与最终状态。要记录请求、授权、响应、最终状态、重试键，以及用户听到的确认，尤其要测试「已经提交，但返回超时」后重试是否产生重复操作。
• S12、S13 检查完整转接路径。除了拨到正确队列，还要确认 AI 停止说话、人工实际接听、摘要和已核验字段传递成功，并覆盖无人接听或队列拒接的分支。
• S15 涉及部署告知要求。作者以 EU AI Act 的 Article 50 为例，但强调适用角色、用途、地区和日期都需要分别核实，不能当成全球通用清单。

真实电话测试还要覆盖听筒、免提、安静环境、工作噪声、网络变化及实际使用语言。转写最终正确，也可能掩盖 AI 抢话、忽略纠正或长时间沉默的问题。

延迟要从用户感知出发：记录用户说完到 AI 开始出声的时间，另记工具等待时间，并报告中位数和尾部延迟。首个 token 出现得快，不代表用户很快听到了回应。

如果时间只有几小时，作者建议至少测普通来电、纠正、打断、敏感或越界请求、工具失败、转人工，以及一次真实电话。可执行预约、取消、扣款或客户记录修改的系统，评估期间应使用可观察、可撤销的操作。

先判定能否接受，再计算加权分

未经授权的动作、虚报交易成功、不遵守停止请求、违规披露，不能靠音色和速度补分。

作者建议先设硬门槛。只有全部通过，才计算可选的加权成绩：任务结果 40 分，规则与动作安全 25 分，对话恢复 15 分，用户感知时延 10 分，交接或可追溯性 10 分。这是建议权重，不是科学定律，必须在看厂商结果前确定。

每一维还需要评分锚点。例如任务结果用 0、1、2 分区分错误或未完成、经评审介入后完成、无需介入即完成。每个分数都要能指向具体事件。

下面的报告脚本检查场景缺失和评分格式，并在存在硬门槛失败时将加权总分置空。保存为 score-voice-eval.js，执行 node score-voice-eval.js results.json：

const fs = require("node:fs");
const required = Array.from({ length: 16 }, (_, i) => "S" + String(i + 1).padStart(2, "0"));
const weights = { task: 40, safety: 25, recovery: 15, timing: 10, handoff: 10 };
const rows = JSON.parse(fs.readFileSync(process.argv[2], "utf8"));
if (!Array.isArray(rows)) throw new Error("Expected a JSON array");
const ids = new Set(rows.map(row => row.scenarioId));
const missing = required.filter(id => !ids.has(id));
const invalid = rows.filter(row =>
  !required.includes(row.scenarioId) ||
  typeof row.hardGatePassed !== "boolean" ||
  Object.keys(weights).some(key => !Number.isInteger(row[key]) || row[key] < 0 || row[key] > 2)
);
if (missing.length || invalid.length) {
  console.error(JSON.stringify({ missing, invalidRows: invalid.length }, null, 2));
  process.exit(2);
}
const gateFailures = rows.filter(row => !row.hardGatePassed).map(row => row.scenarioId);
const average = key => rows.reduce((sum, row) => sum + row[key], 0) / rows.length / 2;
const score = Object.entries(weights).reduce(
  (sum, [key, weight]) => sum + average(key) * weight, 0
);
console.log(JSON.stringify({
  casesObserved: rows.length,
  hardGateFailures: gateFailures,
  observedPassFraction: rows.filter(r => r.hardGatePassed).length + "/" + rows.length,
  weightedScoreOutOf100: gateFailures.length ? null : Number(score.toFixed(1)),
  interpretation: "Descriptive result for this fixture only; not a population estimate."
}, null, 2));

重点看 weightedScoreOutOf100 那一行：任何硬门槛失败都会让总分变成 null。但脚本依赖人工评分，不检查录音、API 轨迹或重复业务动作；它也没有拒绝重复的 scenarioId，不能直接视作完整验收引擎。

另一个容易误读的字段是 observedPassFraction：代码统计的是硬门槛通过比例，并非任务成功解决比例。即使全部通过硬门槛，任务仍可能得 0 分。

同样，13/16 不能写成「生产成功率 81%」。它只描述这 16 个构造案例。要支撑上线决策，还需要按任务、语言、渠道和风险扩充样本，并保留未参与调优的留出集。

我的判断

我认同作者把「回答正确」和「业务状态正确」分开。对接日历、CRM 或支付接口后，语音只是入口，重复写入、权限失控和错误确认才是更难收拾的故障。对这类系统，验收底线应当高于普通问答机器人。

双轨比较也比强求所有厂商使用同一提示词合理。有的产品依赖工具 schema，有的依赖工作流编辑器，强行统一会测偏。但 Track B 的文档支持不等于部署质量保证，仍需实测。

局限同样明确：作者没有给出厂商对照成绩，也没有证明这些权重优于其他方案。OpenAI、Microsoft 的指南提供评估思路，G2 的公开方法提供可审查的流程，Forrester 对 2026 conversational AI Wave 的评论提供运营观点，都不能替代当前团队的数据。这是一套方法建议，尚非经过对照验证的效果结论。

成本部分反而很实用。比较每分钟单价容易漏掉重试、人工转接、重复来电、纠错和维护。用所有尝试的总成本除以符合定义的已解决案例数，才方便比较人工处理、部分自动化和完整自动化。低频、高后果的业务，即使技术上能自动完成，也可能适合保留人工。

能拿来做什么

• 接入预约或客户记录工具时，先用隔离测试账户验证最终状态，补测提交后超时与重试，并把重试键和用户确认一起留档。
• 做语音功能演示时，同时准备真实电话入口，分别记录打断、纠正、静默和工具等待事件，不只展示最终转写文本。
• 在 Node 评估脚本旁保存评分定义和结构化证据，补上场景 ID 唯一性检查，并将硬门槛通过与任务完成分别报告。
• 为模型、提示词、语音配置和集成保存版本标识或带日期的配置导出；重要更新后重跑小型回归集，再用试点数据更新成功解决成本。