从声学信号到工具阻断：实时语音安全决策门的系统设计

从声学信号到工具阻断：实时语音安全决策门的系统设计

摘要：工具调用获得人工批准或签名票据，并不等于它在真正提交时仍然有效。本文把 PROPOSE、AUTHORIZE、COMMIT 拆开，用 SDK Guardrail 覆盖矩阵、结构化确认、权威授权状态、一次性 jti 消费、业务幂等与 outbox，建立一条可撤销且能暴露远端未知终态的实时语音提交链。

关键词：实时语音 Agent、工具调用安全、可撤销授权、TOCTOU、幂等、Outbox

开篇：让生成模型"更加注意语气"不是控制系统

当实时语音代理可以转账、结束关怀工单、修改账户或代表用户确认承诺时，Prompt 不应承担最后一道授权责任。研究已经展示：模型可能正确描述"用户听起来害怕"，却仍然执行字面授权；显式提醒在不同模型和场景间也不稳定。原始研究

工程目标不是让模型给每段声音贴情绪标签，而是建立一个证据有限、动作分级、结果可审计的安全决策门。

核心结论

1. 声学信号应被视为风险证据，而不是用户意图的确定真相。
2. 生成模型负责提出候选解释，策略引擎负责决定工具权限；两者必须解耦。
3. 动作风险越高，越不能仅依赖单一声学分类器或自由文本推理。
4. "二次确认"必须是结构化协议，而不是再问一遍同样的问题。
5. 系统必须记录风险判定何时形成，否则低首音延迟可能掩盖迟到的安全决策。

一、决策门的输入不是一个情绪标签

建议把输入拆成六组信号：

信号组	例子	可信边界
文字语义	金额、收款人、否定、授权词	受 ASR 错误影响
副语言	恐惧、哭泣、犹豫、讽刺概率	不能直接等同真实心理状态
会话上下文	前后矛盾、重复撤回、第三人插话	可能被截断或污染
身份与设备	新设备、说话人变化、认证状态	依赖独立身份系统
司法辖区	用户所在地、服务地区、数据驻留、工具许可范围	必须由合规配置或权威服务判定，不能由模型猜测
工具风险	金额、不可逆性、数据敏感性	应由业务方明确配置

一个典型结构化输入如下：

{
  "intent": "wire_transfer",
  "entities": {"amount": 8400, "currency": "USD", "payee": "new"},
  "semantic_risk": 0.72,
  "prosody": {
    "fear": 0.81,
    "hesitation": 0.67,
    "sarcasm": 0.04,
    "quality": 0.74
  },
  "context": {
    "contradiction_count": 2,
    "third_party_voice": true,
    "recent_correction": true
  },
  "auth": {"speaker_verified": false, "device_trust": "low"},
  "jurisdiction": {
    "user_region": "verified_region_code",
    "service_region": "deployment_region_code",
    "tool_permitted": true,
    "policy_version": "jurisdiction-2026-07"
  },
  "tool": {"risk_tier": 4, "reversible": false}
}

这些字段应带版本和来源。fear=0.81 没有模型版本、音频质量和阈值版本，就无法审计。

二、动作分级比"安全/不安全"二元分类更实用

主体认证、参数 Schema、额度、幂等、限流等通用工具门禁仍由既有工具网关负责，本文不重复展开。Prosody 决策门只增加一层：当文字授权与声学、说话人或环境证据冲突时，是否降低权限、改变确认条件或停止提交。系统必须区分"模型提出工具调用""策略签发授权""工具服务执行"三件事；生成模型产生了函数参数，不等于后端已经获得执行权。策略输出保持有限状态：

ALLOW
ALLOW_WITH_NOTICE
CLARIFY
REAUTHENTICATE
REQUIRE_EXPLICIT_CONFIRMATION
ESCALATE_TO_HUMAN
BLOCK

动作映射取决于工具风险，而不是追求一个全局情绪阈值。声学信号单独存在时通常不应触发永久封禁或医疗判断；它更适合把 ALLOW 降为 CLARIFY、REAUTHENTICATE 或人工升级。

运行链路固定为：实时音频与会话状态分别进入语义解析、副语言检测、说话人与环境检测；这些信号与业务工具风险目录汇入策略服务。策略服务只输出有限动作：允许、澄清、再认证、显式确认、人工升级或阻断，并把判定写入审计记录。

三、规则、模型与校准如何组合

单纯规则无法覆盖语言变化，单纯模型无法提供确定边界。推荐三层组合：

1. 硬规则：司法辖区不允许、工具未获当地许可、数据驻留不满足要求、未通过强认证或参数越界时直接拒绝；不得让生成模型解释后绕过。
2. 校准风险模型：融合文本、声学和上下文，输出风险区间而非情绪真值。
3. 生成模型解释：生成面向用户的澄清语言，并为人工坐席总结证据，不直接覆盖硬规则。

以下仅用于说明决策顺序，阈值是非生产占位值，不是上线建议：

# NON-PRODUCTION PSEUDOCODE: thresholds are illustrative placeholders.
if not jurisdiction.tool_permitted or not jurisdiction.data_residency_satisfied:
    return BLOCK
if tool.risk_tier >= 4 and not auth.strong_verified:
    return REAUTHENTICATE

risk = calibrated_model.predict(features)

if tool.irreversible and risk.lower_bound >= 0.70:
    return BLOCK
if risk.upper_bound >= 0.70 or features.audio_quality < 0.50:
    return REQUIRE_EXPLICIT_CONFIRMATION
if tool.risk_tier >= 3 and risk.mean >= 0.45:
    return ESCALATE_TO_HUMAN
return ALLOW

这里使用区间而不是单点，是为了把模型不确定性纳入策略。生产阈值必须在目标司法辖区、语言、设备、说话人群体和工具风险分层上校准，基于成本矩阵、保留测试集和置信区间选择，并由业务、合规与安全负责人批准；示例中的 0.70、0.50、0.45 不得直接复制上线。

上线后还要持续监测校准误差、漏放/误拦截、输入分布和分层差异。模型、Prompt、音频前端、设备结构或用户群变化都可能造成漂移；超过预设漂移或性能门限时，应降级到更保守策略，停止自动放行相关高风险工具，并触发重新标注、再校准和版本回滚。阈值版本与监控窗口必须进入审计记录。

四、二次确认必须改变证据条件

无效确认通常是："你确定吗？"用户在受胁迫或误解状态下仍会说"确定"。有效确认至少改变一项条件：

• 使用明确、非诱导的复述："你正在把 8,400 美元转给首次收款人 X，转账不可撤销。"
• 要求用户重新说出关键实体，而不是回答"是/否"。
• 切换到已验证设备或第二因子。
• 在检测到第三人声音时建议转到私密环境。
• 对高后果动作加入冷静期或人工回拨。

确认流程本身也要评测完成率、重复次数、误拦截和攻击绕过率，不能只记录"问过确认"。

五、流式系统中的时间顺序

实时架构的危险来自并行：TTS 可能在风险模型完成前开始输出，工具调用也可能被 LLM 流式产生。安全设计应设置提交屏障：

音频流入 ───────────────┐
语义增量解析 ───────────┤
副语言增量检测 ─────────┤→ provisional risk
结束点检测 ─────────────┘
                         ↓
                 final policy barrier
                         ↓
              TTS 承诺 / 工具提交

低风险闲聊可以先流式回复；涉及支付、账户、健康升级或外部消息时，系统必须等到 final policy barrier。可以先播放中性占位音，如"我正在核对信息"，但不能先承诺"已为你完成"。

截至 2026-09-02，OpenAI Agents SDK 的 Realtime 路径已经支持工具执行前的人工审批和函数工具输入 Guardrail；官方文档同时明确，审批前检查需要显式配置，且执行前仍会再次检查。但这条 Guardrail 管线只覆盖以 function_tool 创建的函数工具：handoff 走独立管线，Hosted tools、Computer/Shell/ApplyPatch/LocalShell 等内置执行工具不走同一路径，Agent.as_tool() 也不直接暴露相同的工具 Guardrail 选项。因此不能把一次 SDK 配置理解为全局安全边界。高风险能力必须统一路由到受控业务工具网关和授权服务；无法进入该路径的工具应禁用、降权或另设等价提交门。

建议记录：

• audio_end_at
• prosody_signal_ready_at
• semantic_parse_ready_at
• policy_final_at
• tool_commit_at
• first_audio_out_at

核心 SLO 不是把所有步骤压到最短，而是在风险场景中保证 tool_commit_at >= policy_final_at，并限制决策门的 P95 延迟。

六、工具接口需要显式携带风险上下文

策略决定和工具执行必须是两步。BLOCK、CLARIFY、REAUTHENTICATE 或 ESCALATE_TO_HUMAN 不得生成、排队或发送任何业务执行请求；系统只写入独立审计事件并返回相应交互动作，业务参数不能借"被阻断请求"的形式进入工具服务。

只有 ALLOW 或满足既定条件的 ALLOW_WITH_NOTICE 才能产生执行请求。请求必须携带短期、最小权限的授权票据，至少绑定主体、工具、规范化参数摘要、证据快照摘要、策略版本、受众、签发/失效时间和唯一标识：

{
  "tool": "create_wire_transfer",
  "arguments": {"amount": 8400, "payee_id": "p_912"},
  "authorization": {
    "policy_decision_id": "pd_7fa2",
    "decision": "ALLOW",
    "sub": "user_2841",
    "tool": "create_wire_transfer",
    "arguments_sha256": "sha256:canonical-arguments-digest",
    "evidence_sha256": "sha256:policy-input-snapshot-digest",
    "policy_version": "voice-risk-policy-2026-07-14",
    "aud": "payments-tool-service",
    "iat": 1784000063,
    "exp": 1784000123,
    "jti": "authz_01J..."
  },
  "idempotency_key": "voice-session-42-turn-8-transfer"
}

票据必须由受信任的策略服务签发。自包含签名只证明票据未被篡改，不能证明它此刻尚未撤销；因此高风险工具即使收到完整签名票据，也必须在造成外部副作用的最后提交点，使用 policy_decision_id/jti 向权威授权状态存储联机查询。工具服务同时核对 sub、工具名、规范化参数摘要、证据摘要、策略版本、aud、iat 和 exp；任何字段不匹配、过期、签名无效、状态不是 ACTIVE 或查询不到的请求都应拒绝。

还要处理"批准后、提交前"发生变化的 TOCTOU 问题。用户改口、收款人或金额变化、认证状态变化、出现新的第三人声音，都会使旧票据失效。策略服务应对权威状态执行条件更新 ACTIVE → REVOKED，基于新快照重新判定；工具服务不能把"曾经 ALLOW"解释成会话内永久授权。

提交路径必须把三件事做成一个线性化操作：确认 jti 仍为 ACTIVE、将它原子更新为 CONSUMED、占用业务幂等键。可以使用同一数据库事务中的条件更新与唯一键，也可以在事务中写入 outbox，由唯一消费成功的 worker 调用外部系统。并发的两个相同 jti 只能有一个把状态从 ACTIVE 改为 CONSUMED；撤销与消费竞争时，也只能由一个条件更新胜出，另一个观察到终态后失败关闭。REVOKED、CONSUMED 与 EXPIRED 是互斥终态，胜出顺序、业务幂等键和外部副作用引用都要进入审计记录。

如果支付、短信等外部系统无法与授权状态处于同一事务，outbox 只能保证本地"授权消费 + 待执行事件"原子化，不能让远端副作用与本地状态天然原子。此时必须把同一幂等键传给远端，记录 DISPATCHING/SUCCEEDED/FAILED_UNKNOWN，对超时执行查询、重试或人工补偿，并公开承认仍有远端不可判定窗口；短期签名票据本身不能消除这类 TOCTOU。

这样即使生成模型绕过前端提示，也无法自行构造有效授权。策略记录只保存必要摘要和哈希，原始音频按最短保留原则处理。OpenAI Agents SDK 的官方 tracing 文档提示，生成、函数调用和音频 Span 可能包含敏感内容，音频捕获需要显式关闭；这说明"有 Trace"不等于"可以无边界保存 Trace"。

七、回归评测

上线前至少覆盖：

• 同文字、不同语气的成对样本；
• 同语气、不同风险工具；
• 音频质量下降和背景说话人；
• Prompt 注入要求忽略安全信号；
• 用户在确认阶段改口；
• 授权签发后、工具提交前用户改口或关键参数变化，旧票据必须失效；
• 网络重试导致重复工具调用；
• 模型版本或分类器阈值升级；
• 司法辖区、服务许可或数据驻留规则变化；
• 票据主体、工具、参数摘要、aud 不匹配，以及过期或重复 jti；
• 两个相同 jti 并发提交，只允许一个 ACTIVE → CONSUMED 并产生一次 outbox/业务幂等占位；
• ACTIVE → REVOKED 与 ACTIVE → CONSUMED 并发竞争，断言只有一个终态胜出，外部副作用与胜出状态一致；
• 正常用户的误拦截与无障碍影响。

生产事故应回流为最小化、去标识化或经明确授权的回归样本，而不是只在工单中记录。假名化只能降低关联风险，不能自动把个人数据变成匿名数据；具体流程可与 Agent trace 数据飞轮共用：trace、failure taxonomy、human correction、sanitization、regression eval。

风险与限制

声学推断会触及隐私、公平和可解释性。声音可以暴露健康、年龄、身份或情绪线索，任何长期存储都需要明确目的和保留期。模型也可能对口音、性别表达、残障或神经多样性产生差异化误报。策略门的目标应是"在不确定时采用可逆、可确认流程"，而不是秘密推断用户人格或心理状态。

结论

可靠的实时语音安全不是一句 Prompt，而是一条可撤销的提交链：多源信号进入校准风险模型，风险与工具损失共同决定有限动作，结构化确认改变证据条件，短期票据冻结这次授权的主体、参数和证据，工具服务在提交前重新验签并拒绝失效状态。声学信号只是一条证据；真正的安全来自它能否在正确时刻约束不可逆动作。

参考资料

• Real-Time Voice AI Hears but Does Not Listen，arXiv:2606.26083v1，2026-06-24，原始论文，一手来源，访问日期：2026-09-02。
• Realtime Agents Guide --- Tools, approvals, handoffs, and guardrails，OpenAI Agents SDK 官方文档，访问日期：2026-09-02。
• Guardrails --- OpenAI Agents SDK，OpenAI Agents SDK 官方文档，访问日期：2026-09-02。
• Tracing --- OpenAI Agents SDK，OpenAI Agents SDK 官方文档，访问日期：2026-09-02。
• Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile，NIST AI 600-1，2024-07，访问日期：2026-09-02。
• NISTIR 8053: De-Identification of Personal Information，NIST，2015-10，标准/指南，一手来源，访问日期：2026-07-14。
• NIST Privacy Framework，NIST，持续更新；访问于 2026-07-14，隐私风险框架，一手来源，访问日期：2026-07-14。
• Pseudonymisation，UK Information Commissioner's Office，监管指南，访问日期：2026-09-02。

资料检索截止日期：2026-09-02。SDK 能力与默认行为可能变化；阈值、票据字段和状态机属于作者提出的工程方案，不是论文、NIST 或 SDK 官方给出的生产标准答案。