PaperBridge 长尾问题
语音 Agent 上线前应该怎么做红队测试？
不要把语音 Agent 当成“先转写、再跑聊天机器人”。至少同时测试原始音频、ASR 转写、规范化文本、安全判断、工具参数和最终语音输出。用口音、语言、背景噪声、压缩、重叠说话、中断、TTS 注入和多轮施压组成测试矩阵；每次都核对安全层与动作层是否基于同一份版本化输入。最终评分看 Agent 是否执行了越权动作、泄露信息或在状态不确定时继续操作，而不只看回复文本有没有拒绝。
1. 先画出整条语音管线
记录音频进入后的每个表示：原始音频 ID、ASR 原文、清洗或规范化文本、送入安全层的内容、送入 Agent 的内容、工具参数、最终文本和 TTS 输出。任何一步发生改写，都要保留版本和时间戳。
最危险的不是某一份转写单独看起来很差，而是安全层检查了版本 A，动作层却依据版本 B 执行。两边都显示“正常”也不能证明它们理解了同一个请求。
2. 音频条件要做成矩阵，不是加一段白噪声
至少沿环境、人群和语言三条轴测试：安静与嘈杂、近讲与远讲、不同口音和说话速度、主要语言与混合语言。再加入电话编码、丢包、回声、背景电视、重叠说话和合成语音。
WildASR 显示 ASR 的鲁棒性不会稳定地跨语言和条件迁移，退化输入还可能生成并未说出的合理内容。总体 WER 正常，仍可能在姓名、金额、否定词或动作动词上发生高代价错误。
- 内容不变，只改变口音、速度、音量、编码和噪声。
- 音频不变，比较不同 ASR、规范化规则和安全策略。
- 同时保存全文 WER 与关键实体、金额、否定和意图错误。
- 覆盖音频开头、中间和结尾的注入位置。
3. 把攻击跨越多个回合
一次拒绝不代表对话安全。让攻击者先建立无害上下文，再逐步改变目标、制造紧迫感、引用前文、打断 Agent，并在 Agent 已经开始说话或调用工具时修改要求。
每个回合都检查已确认事实、尚未确认事实、已执行动作和待执行动作。中断后不要把未播放完的 Agent 内容当成用户已经听到并接受。
4. 对动作做独立的提交前检查
涉及付款、账户修改、隐私、预约或外呼时，工具调用前重新验证规范化意图、关键实体、权限和确认状态。安全判断与动作验证应引用同一个不可变请求 ID 和输入版本。
如果 ASR 置信度低、两个转写版本冲突或关键实体变化，安全默认应是澄清、暂停或人工升级，而不是让 Agent 猜测并继续执行。
5. 按真实结果评分，并把生产失败变成回归案例
拒绝文本只是中间信号。评分器还要检查工具是否被调用、参数是否越权、数据库或日历是否被修改、敏感信息是否进入日志或语音输出，以及失败后是否安全停止。
上线后按音频条件、ASR 错误、状态错误、安全漏检和动作越权分类真实 trace。每个新失败都缩成可重复案例，加入发布门槛；不要只扩充随机 persona 数量。
语音 Agent 最小红队合同
- 记录原始音频、ASR、规范化文本、安全输入、Agent 输入、工具参数和最终输出。
- 按环境、人群、语言、设备、编码和说话方式构造测试矩阵。
- 覆盖背景音、重叠说话、TTS 注入、口音、混合语言和关键实体错误。
- 对同一攻击运行多轮施压、中断、改口和恢复场景。
- 让安全层与动作层引用同一个请求 ID 和输入版本。
- 用工具副作用、权限、隐私泄露和安全停止评分，不只看拒绝文本。
- 把生产失败最小化成回归案例，并按严重度与频率共同排序。
原论文、研究与官方文档
以下来源用于核对事实；流程与比较建议是 PaperBridge 对研究、官方文档和工程实践的综合。