实时语音

• 多模态事件混流
• 统一时间线
• 转写/工具/播放对齐

实时会话中音频流、文本 delta、工具调用事件混流，前端需维护统一时间线：所有事件（音频帧、transcript delta、tool_call、tool_result）都打上"统一时间戳 + 序号"，按序进入同一条时间线；转写（transcript）与音频播放绑定同一时间轴，工具调用事件在时间线上标注其发生时刻，使"用户说话→转写→工具调用→回复"的顺序清晰。前端用"时间线渲染器"消费统一事件流，按时间戳对齐播放音频与显示转写/工具进度，避免音频与文本错位。工具进度插在时间线对应位置，保证转写、工具、播放顺序一致。

错位源于"各通道各自为政"。统一时间戳 + 序号 + 单条时间线，让音频、转写、工具事件按同一顺序呈现，才能保证对齐。

• barge-in 的中断传播
• 中断事件链路
• 音频对账

barge-in 时前端检测到用户说话（VAD），应立即停止播放当前音频并发送"中断事件"到 BFF，BFF 再转发给 Provider 会话（如 Realtime API 的 interrupt 事件），让 Provider 停止生成并清空待播音频。中断传播要快（前端本地立即停止播放 + 异步通知服务端）。对账：已播放但未出账的音频（或已生成因打断未播放的音频）——记录"实际播放时长"与"服务端生成时长/音频 token"，计费以"服务端实际生成的音频量"为准，而对账时区分"已播放"与"未播放（被打断丢弃）"，避免把未播放的音频计费给用户；用事件日志（播放开始/结束、打断时间点）对账。

barge-in 的核心是"快速本地停止 + 链路中断传播 + 音频对账"。前端立即停播、链路传中断、计费按实际生成量并区分已播放/被打断，三环缺一不可。

• 断线续传与会话状态恢复
• 必回填状态 vs 丢弃重生
• 状态一致性

断线续传时，会话状态恢复要区分"已确认"与"可丢弃"：必须回填的——已确认的对话项（用户已看到/已确认的 fact、工具结果、已完成的响应）、会话级上下文（用户身份、会话 ID、已确认的转写）、工具调用进度（已执行且不可重放的副作用工具结果）；应丢弃重生成的——未完成的音频/文本片段、未生效被打断的生成、未确认的临时状态。设计上服务端维护"已确认状态"清单（含幂等键），重连时前端拉到该清单回填，未确认的临时内容让模型重新生成。关键是被打断或未完成的临时内容不错误回填，已确认的副作用不重复执行。

状态恢复的关键是"确认边界"。已确认对话项与副作用结果必回填，未完成的临时内容丢弃重生，用幂等键避免副作用重复，保证恢复后一致。

• 语音与文本的计量口径差异
• 统一对账
• 观测与展示

实时语音的计费口径与文本不同：语音按"音频时长（秒）"或"音频 token"计，文本按 token 计，且 Realtime 会话还按"连接时长"收取额外费用。统一对账：建立统一的"计量归一化"——把所有口径（音频秒、音频 token、文本 token、连接秒）换算成统一成本单位（如"标准 token 当量"或直接转金额），在账单一侧按统一货币展示；观测体系记录每个会话的明细（音频输入/输出时长、token、连接时长、工具调用），按会话聚合。展示时在"统一成本"基础上，保留各维度明细（如"音频 120s + 文本 500 token + 连接 90s"），让用户/运维能看到拆分与合计。对账要防"双口径相加"造成重复计费。

统一对账的关键是"归一化到统一成本单位 + 保留明细维度"。语音的时长/token 与文本 token 换算为统一成本，观测保留各维度明细，避免重复计费与口径混乱。

• BFF 中继的限流
• 并发数/会话时长上限/成本熔断
• 资源保护

BFF 中继长连接时需限流防资源耗尽：并发数——按用户/全局设置并发连接上限（如每用户最多 1-2 个实时会话），超限拒绝或排队；会话时长上限——设置单会话最长时长（如 30 分钟），超时强制结束并清理；成本熔断——监控单会话/单用户的 token 与音频消耗，超过成本阈值即熔断（停止生成、提示用户或降级），防止恶意或异常消耗。BFF 维护"连接 + 成本"的监控，异常时主动断开或降级。并发数、时长上限、成本熔断三者共同构成对长连接与成本的保护。

长连接耗尽资源的根源是"无上限"。并发数、会话时长、成本阈值三层限流 + 熔断，让 BFF 在中继时能主动保护资源，防止失控。

• VAD 与轮次事件透传
• 服务端端点检测 vs 前端误判
• 事后调参

Provider 的 VAD（语音活动检测）与轮次事件（如 turn_start/turn_end、用户说话开始/结束）应透传给前端：前端通过 BFF 中继收到这些事件，用于暂停/恢复、显示说话状态、控制 barge-in。区分"服务端端点检测"与"前端误判"：前端自身的 VAD 判断（本地麦克风检测）可能与服务端不一致——前端判定"用户说完"但服务端 VAD 未触发端点（或反之）。为事后调参，需记录"前端 VAD 事件"与"服务端 VAD/轮次事件"的时间戳，对比二者的对齐与偏差，统计误判率（前端误判端点、服务端漏检）。用这些数据调 VAD 阈值、静音时长、barge-in 灵敏度。区分并记录两端检测，才能定位误判来源并按服务端为准调参。

VAD 是"前端本地 + 服务端"双重检测。透传服务端事件让前端对齐，记录两端事件时间戳对比偏差，才能区分误判来源并指导调参。

• 语音与文本模式切换
• 上下文保持
• 切换边界

实时会话与 SSE 文本流切换时，要用"同一会话上下文"衔接：切换边界按"已确认的对话历史"划分——语音模式与文本模式共享同一会话 ID 与消息历史，切换时把已确认的对话项（转写/文本、工具结果）带到新通道，不丢上下文。设计：BFF 层把两种通道统一到同一会话状态，切换时做"状态快照 + 恢复"；切换边界信号（如用户点"切到文字"或关闭语音）触发后，把语音里已确认的内容同步进文本通道，产生的回复继续用文本流。避免"语音会话"与"文本会话"当作两个独立会话导致上下文断裂。切换时提示"已保留上下文"。

切换不丢上下文的关键是"共享同一会话状态"。语音与文本只是同一会话的两种传输通道，切换时以已确认历史为边界衔接，避免上下文断裂。

• 音频日志的采样与脱敏
• 生物特征合规
• 回放调试与合规平衡

实时会话日志含音频片段（生物特征）、转写（含 PII）、事件，需采样与脱敏：音频——默认不存原始音频或仅按需采样（如 1% 采样率、打码/降噪、截断），且严格限制访问与保留期限，因音频是生物特征（声纹），受 GDPR/PIPL 等要求（需明确同意、目的限制、最小化）；转写——脱敏 PII（姓名、卡号、地址），日志中独立存储并加密；事件——保留结构化事件（不含音频）。回放调试与合规的平衡：只用"脱敏后的转写 + 事件"做回放，原始音频仅在有明确合法依据且经审计时保留，且短期后自动删除。合规层面：最小化采集、明确同意、保留期限、访问控制、数据主权。

音频是生物特征，合规压力大。核心是"最小化 + 脱敏 + 访问控制 + 保留期限"：默认不存或采样，转写脱敏 PII，事件用于回放，原始音频严格受限。

• 首音频延迟与打断成功率度量
• 集成测试环境
• 发布门禁

首音频延迟（首包音频 TTFB）与打断成功率（barge-in 成功率）需在集成测试环境度量并纳入门禁：构建自动化集成测试——用合成音频输入触发会话，测量"从发送到最后接收首包音频"的延迟（多次采样取分位数，如 P50/P95）；测打断——播放音频过程中发送打断信号，测量"打断生效到停止播放"的延迟与成功率。这些指标在 CI/发布流水线中作为门禁阈值（如首音频 P95 < 阈值、打断成功率 > 阈值），回归不达标即阻塞发布。测试环境要贴近生产（真实 Provider、真实网络模拟），避免测试环境指标失真。

实时语音的性能与可靠性要靠"可复现的集成测试 + 门禁阈值"。用合成音频测首音频延迟分位数与打断成功率，纳入 CI 门禁，才能防止发布回归。

• 工具 Schema 设计
• 减少误选与参数幻觉
• 避免拉长对话

语音 Agent 工具 Schema 设计要点：名称——简短、语义明确、与能力一致，避免相近名称使模型误选；描述——用自然语言写明"何时用、何时不用、关键参数含义"，降低误选；参数约束——用必填、枚举、类型、格式约束，减少参数幻觉（模型编造不存在的参数值）；返回值——明确返回结构与错误语义，让模型能正确使用。为减少对话拉长：工具要"粒度适中"（一次完成一个原子操作，避免过多轮工具调用）、描述引导模型"一次说清所需参数"、对可自取的参数用默认值减少追问。工具数量与冲突要可控，避免模型在多个相近工具间犹豫。

工具 Schema 是"模型选择与调用质量的输入"。名称/描述/参数约束/返回值都影响误选与幻觉，粒度与描述也影响对话轮数，设计需"清晰、原子、少歧义"。

• 工具调用闭环
• 校验执行
• 结果回传与答复

语音 Agent 工具调用闭环：模型提出工具调用（ToolCall，含调用 ID 与参数）→ 应用层校验（参数合法性、权限、业务规则）→ 校验通过则执行工具（副作用动作）→ 把"工具结果"作为 tool 消息回传给模型 → 模型基于结果生成最终答复（语音播报）。实现要点：校验在"执行前"（未授权/非法参数不执行）；执行记录结果与幂等键；结果回传要结构化（含成功/失败、数据、错误语义）；模型用结果生成贴合语音的短答复。若校验失败，把错误作为 tool 结果回传，让模型修正或向用户说明。整个闭环是"提出→校验→执行→回传→答复"。

闭环的关键是"人类可干预的校验环节"与"结果回传"。校验在副作用前拦截，结果结构化回传，模型据此生成最终答复，形成受控的语音工具调用周期。

• 并行 vs 串行调用
• 依赖/顺序/成本/错误
• 禁止并行条件

并行调用：多个独立工具同时执行，缩短总延迟、提升效率，但需处理参数交叉、结果聚合、错误隔离；串行调用：依赖顺序执行，适合有依赖（后一步输入来自前一步输出）的工具。影响：依赖——串行保证依赖顺序，并行要求工具间无依赖；顺序——串行天然有序，并行需自行管理顺序；成本——并行可能同时消耗多个工具的配额/资源，需限流；错误——并行时一个失败的处理需明确（继续/中止其余）。必须禁止并行的情况：工具间有数据依赖（后一步依赖前一步结果）、同一资源被并发修改（写冲突）、共享配额/限流（避免并行耗尽）、动作有严格先后约束（先审批后执行）。无依赖且独立时才可并行。

并行与否取决于"依赖与副作用"。有依赖、有写冲突、有共享配额或严格顺序的动作必须串行，独立无依赖的只读/独立操作才宜并行。

• 工具描述的自然语言技巧
• 触发选择
• 避免忽略/误用

工具描述的自然语言技巧：明确触发条件——写清"当用户提到 X 时使用此工具"（如"当用户询问天气时"），让模型在相关场景愿意选；说明边界——写清"何时不用"（如"仅用于查询，不用于修改"），避免误用；突出价值——用一句话说明工具能解决什么（结果对用户有用），避免模型忽略；给出关键参数语义——让模型准确填参；用"肯定式"描述能力而非"否定式"（"可查询余额"好于"不要用于其他"）。对相近工具，用差异化描述（场景、边界）让模型区分。描述要"具体、面向触发、清晰边界"，而非笼统。

描述是"模型选择工具的依据"。写清触发条件、边界、价值与参数语义，用肯定式、差异化描述，才能让模型在合适场景愿选、避免忽略与误用。

• 大工具结果处理
• 截断/摘要/引用
• 上下文管理

工具结果过大（>100KB）回传模型会导致上下文超限。处理策略：截断——只保留结果的关键部分（头部、汇总、关键字段），丢弃冗余；摘要——用模型或规则对结果做摘要，把要点而不是全文回传；引用——把大结果存到外部存储（如对象存储/数据库），回传给模型的是"引用"（如 ID、摘要、可查询的接口），模型需要时可再查询。按需选择：结果可结构化则提取关键字段，结果是大文本则摘要，结果可查询则引用。同时控制"回传量"与"整体上下文预算"，避免多轮大结果累积超限。用"截断+摘要+引用"组合，保证模型在有限上下文内仍能正确使用结果。

大结果回传是上下文超限的常见来源。用截断（留关键）、摘要（去冗余）、引用（按需取）分层处理，把回传量控制在预算内，是上下文管理的核心。

• 参数互斥声明
• Schema 约束
• 减少矛盾调用

在工具 Schema 层声明参数互斥，用 oneOf/anyOf 表达"一组参数只能选一个"（如 byId 与 byKeyword 二选一），或对互斥参数用 not/条件约束表达。这样模型在生成参数时被约束为"只能提供互斥组之一"，从结构上减少同时传入矛盾参数（如既按 ID 又按名称查询）的误用。同时用描述说明互斥语义（"byId 与 byKeyword 互斥，二选一"），并配合服务端校验（检测互斥参数同时出现则拒绝）。Schema 层声明 + 描述 + 服务端校验三层，减少误选与矛盾调用。

互斥参数是"参数矛盾"的根源。Schema 层用 oneOf/anyOf/not 表达互斥，描述说明，服务端校验兜底，结构上防止模型同时填矛盾参数。

• 错误分类
• 语音播报的错误提示
• 重试策略

工具失败按类型映射为语音提示与重试策略：4xx 业务错误（参数非法、业务规则不满足）——不可重试，播报"操作无法完成，原因是…"并给出修正建议；5xx 服务错误——可重试，播报"服务暂时不可用，请稍后再试"并自动退避重试；超时——可重试但需确认，播报"操作超时，是否重试？"；权限拒绝——不可重试，播报"您没有权限执行此操作"。语音播报要"简短、口语化、可操作"，把错误原因转成用户能理解的话，而非技术细节。重试策略与分类对齐：可重试（5xx/超时）自动退避重试并设上限，不可重试（4xx/权限）直接播报原因并引导，不自动重试。

错误分类要同时驱动"播报内容"与"重试行为"。可重试类自动退避重试，不可重试类播报原因并引导，语音提示口语化可操作。

• 不可信内容的过滤
• 白名单/黑名单字段
• 转义

工具结果可能包含用户输入（不可信内容），回传模型/播报前需过滤：白名单过滤——只保留预期的安全字段（如结果中仅允许文本、数字、预定义枚举），丢弃或标记其他内容；黑名单过滤——剔除已知危险内容（脚本、控制字符、敏感字段）；转义——对保留内容做转义（如 HTML 转义、引号转义），防止其在模型拼接或播报时被当作指令/代码。对不可信内容，先校验其类型与长度，再按白名单提取安全部分，最后转义。这样即使用户输入含恶意内容，也不会污染工具结果或模型上下文。

不可信内容回传是"注入点"。白名单提取安全字段、黑名单剔除危险项、转义防注入，三层处理让用户输入不能污染工具结果与模型上下文。

• 敏感操作的二次确认
• UI 层强制确认
• 不依赖模型自觉

敏感操作（删除、付款、发邮件）不能仅靠模型"礼貌询问"，而应在 UI 层强制二次确认：当模型请求执行敏感工具时，应用层拦截该工具调用，进入"待确认"状态，前端弹出确认界面（展示操作类型、关键参数、副作用），用户明确确认后才执行；确认前不执行任何副作用。二次确认是"确定性门禁"，不依赖模型是否礼貌地询问。实现：工具 Schema 标记危险等级，BFF/执行层对危险工具强制"审批流程"，UI 显示确认页，用户确认后放行并把确认结果作为 tool 结果回传模型。对不可逆操作（付款、删除）甚至要求更强确认（如输入验证码）。

敏感操作的安全必须靠"确定性门禁"而非"模型自觉"。危险工具强制进入 UI 二次确认，确认才执行，配合工具分级，形成不可绕过的安全闸门。

• 副作用工具的可靠设计
• 幂等/超时/重试/补偿/审批/循环终止
• 可靠性保障

有副作用工具的设计：幂等键——每次操作生成唯一幂等键（如 request_id+操作类型），服务端按幂等键去重，重复执行返回同一结果；超时——为工具执行设置超时，超时即终止并标记不明确状态；重试——对可重试（瞬时）错误用幂等键重试，避免重复副作用；补偿——对已执行但后续失败的副作用做补偿（如对已扣款但下单失败则退款），保证一致性；审批——高风险动作需审批（UI 二次确认/人工审批）后才执行；循环终止——防止模型反复调用同一工具，设置调用次数上限与"无进展检测"，超限终止。这些机制共同保证副作用工具"可靠、可恢复、不重复"。

副作用工具的核心是"幂等 + 可恢复 + 不失控"。幂等键防重复、超时/重试保可靠、补偿保一致、审批保安全、循环终止防失控，六者构成完整保障。

• Schema 校验 vs 业务授权
• 用户身份传递
• 授权边界

参数 Schema 校验只保证"参数格式合法"（类型、枚举、必填），不保证"该用户是否有权执行"——授权是业务层对"用户身份 × 操作 × 资源"的判断（如用户 A 能否删除用户 B 的数据）。二者不可替代。终端用户身份传到工具服务：在 BFF 层把登录用户身份（用户 ID、角色、租户）解析出来，通过请求头（如 X-User-Id）、安全上下文或签名 token 传到工具服务，工具服务据此做授权校验（该用户是否被允许执行该操作、是否可访问该资源）。身份传递要"可信、不可伪造"（使用服务端签发的 token，而非前端可篡改的字段），并贯穿到副作用执行前。

Schema 校验管"格式"，授权管"权限"。用户身份必须由 BFF 安全传递到工具服务（可信 token），工具服务在副作用前做授权，才能覆盖"参数合法但越权"的情况。

• 原生 Tool Calling vs MCP 工具发现
• 生命周期/传输/信任边界
• 差异

Provider 原生 Tool Calling：工具 Schema 静态声明在请求里，生命周期随请求，传输直接在 Provider 请求中，信任边界是"由 Provider 直接执行自由度有限"（原生工具调用由应用层执行，但工具注册与调用模型内建）。MCP 工具发现：工具通过 MCP 协议动态发现（客户端连接 MCP Server 获取工具清单），生命周期独立于请求（可连接/断开、动态更新），传输走 MCP（stdio/HTTP/SSE），信任边界更复杂——第三方 MCP Server 是外部信任域，需审计其代码、工具元数据、权限。差异：原生简单直接、信任边界清晰；MCP 灵活可扩展、但引入外部信任域与动态发现风险。需对 MCP 工具做能力映射、权限隔离与审计。

原生 Tool Calling 是"静态、内建、信任边界清晰"，MCP 是"动态发现、外部传输、信任边界扩展"。采用 MCP 需额外管理外部信任域与工具生命周期。

• 副作用与幂等键关联
• 防止重复执行
• 幂等设计

副作用与请求幂等键关联：为每个"用户请求/工具调用"生成唯一幂等键（如 request_id + 工具名 + 参数哈希），在副作用执行前记录该键的状态（pending/executing/done）；执行时以幂等键为唯一标识，重复收到同键请求时，若已 done 则返回原结果而不重新执行，若 executing 则等待或返回进行中。对写库/发邮件/支付，把幂等键连同操作一起持久化（如数据库唯一约束、支付接口的 idempotency key），从底层保证不重复。这样重试、断线重连、模型重复调用都不会造成重复副作用。

防重复副作用的本质是"幂等键 + 状态记录 + 持久化去重"。幂等键贯穿请求与副作用，写库/支付/邮件都按键去重，从根上防止重复执行。

• Tool Calling vs Function Calling 的语义
• 跨 Provider 命名
• 抽象层兼容

在 OpenAI 规范中，Tool Calling 与 Function Calling 描述的是同一能力（模型调用外部函数/工具），tools 参数里既可用 function 类型（Function Calling）也可用 tool 类型（Tool Calling），二者在请求结构上略有差异（function 是 tools 里的一种类型），但能力本质相同。跨 Provider 时，不同 Provider 的命名与结构不同（OpenAI 的 tools/function_call、Anthropic 的 tool_use、Gemini 的 functionCall/function_call），抽象层需要统一"工具调用"语义，兼容不同命名与结构——把各 Provider 的请求/响应归一化为统一接口（tool 列表、tool_call 事件），而非各 Provider 各自为政。抽象层应兼容"Function Calling"与"Tool Calling"两种表述，屏蔽命名差异。

语义相同但命名与结构因 Provider 而异。抽象层需把"工具调用"统一为内部接口，兼容 Function Calling 与 Tool Calling 的差异，避免绑定单一 Provider。

• MCP 的能力映射
• Tool vs Resource
• 映射原则

MCP 区分 Tool（动作/操作，会产生副作用或执行函数）与 Resource（数据/文档，可被读取、检索、作为上下文）。能力映射原则：需要"执行动作、产生副作用"的能力（查询后修改、调用服务、发送）→ 暴露为 Tool；需要"提供数据、作为上下文/引用"的能力（文档、数据库记录、知识库条目）→ 暴露为 Resource（供模型读取或检索、作为 grounding）。语音 Agent 中，把"只读数据源"暴露为 Resource 让模型作为上下文读取，把"需执行的操作"暴露为 Tool 需经授权执行。区分两者能更安全地控制"读数据"与"做动作"，避免把只读数据当可执行动作暴露。

Tool 是"动作"，Resource 是"数据"。数据源做 Resource（只读、上下文），操作做 Tool（受控、副作用），按"读 vs 执行"划分能力，是安全与语义清晰的映射。

• 工具错误回灌
• 引导修正
• 错误修正循环

工具错误回灌：当工具调用失败时，把"结构化错误信息"作为 tool 结果回传给模型，引导其修正——错误信息要包含"错误类型、出错参数、可修正建议"，而非"无法完成"的笼统描述。模型收到错误后，修正参数或换用替代工具再调用，形成"错误→修正→重试"的循环（chain-of-error correction）。为安全，设置修正循环上限（如 2-3 次），避免无限纠正；错误信息要可读、可操作，且区分"可修正错误"（参数错、格式错）与"不可修正错误"（权限拒绝、业务不允许），不可修正的直接终止并播报。回灌让模型能自我修正，但受循环上限约束。

错误回灌的价值是"让模型基于错误反馈修正"。结构化错误 + 可操作建议引导修正，按可修正性区分路径，并设循环上限防失控。

• Grounding 工具 vs 业务工具
• 证据引用/来源可见性/失败语义
• 差异

Grounding 工具（检索、搜索、知识库）与普通业务工具（查询、执行）的区别：证据引用——Grounding 工具的结果要带"来源引用"（文档、URL、片段），供模型基于证据作答；普通业务工具结果不一定有引用。来源可见性——Grounding 工具需要把来源暴露给用户（引用可见、可追溯），普通业务工具结果通常不强调来源。失败语义——Grounding 工具失败（无结果、引用不可达、来源权威性不足）时，应"降级不编造"（明确无证据、不伪造引用）；普通业务工具失败是操作层面（业务错误、权限）。Grounding 工具的核心是"证据驱动、来源可见、失败可降级"，普通业务工具是"操作执行、结果受限"。

Grounding 工具服务于"基于证据的回答"，业务工具服务于"执行操作"。证据引用、来源可见性、失败降级（不编造）是 Grounding 工具区别于业务工具的三个关键点。

• 降级策略
• 不伪造引用
• 来源权威性

搜索无结果、citation 不可达或来源权威性不足时，系统应降级而不伪造引用：无结果——明确告知"未找到相关结果"，不强行编造；citation 不可达——移除或标注"引用不可用"，不显示无效链接；来源权威性不足——拒绝引用或标注"来源未经核实"，不把低权威来源当可信证据。降级原则：宁可"无引用/明确说明"，也不伪造引用。实现上，Grounding 层校验引用可达性与权威性（来源白名单、域名可信度），失败时把"降级状态"作为 Grounding 结果，让模型基于"无证据"诚实地回答"无法确认"而非编造。这与"不编造"的 Grounding 原则一致。

防伪造引用的关键是"校验 + 降级"。引用不可达/权威不足时移除或标注，模型在无证据时诚实说明，绝不填充虚假引用。

• 工具限流与 Provider 限流统一
• 并发治理
• 瓶颈隔离

工具限流与 Provider 限流统一治理：为每个工具设置独立的 rate limit 与并发限制（每工具配额），同时为 Provider 调用设置全局限流（链路上游），并用"统一限流网关"管理——工具层的配额与 Provider 层的配额在同一治理体系内，避免工具疯狂调用吃掉 Provider 配额。瓶颈隔离：一个工具限流/失败不应拖垮整个调用链——用"熔断器"（工具失败率超阈值即熔断该工具）、"独立线程池/信号量"（工具并发隔离，一个工具满不阻塞其他工具）、"按工具降级"（单一工具超限时，该工具降级或排队，不影响其他能力）。限流统一 + 隔离，让单工具瓶颈不拖垮全局。

统一治理的核心是"工具配额与 Provider 配额同一体系 + 工具级隔离"。熔断、独立并发限流、按工具降级，让一个工具的瓶颈不影响整个调用链。

• 工具元信息暴露
• 辅助模型决策
• 暴露与安全的权衡

工具元信息（owner、版本、依赖、危险等级）是否暴露给模型需权衡：向模型暴露"危险等级"与"使用限制"有助于模型决策（如"此工具为高风险，需用户确认"），能减少误用；但暴露 owner、依赖、内部版本等运营元信息对模型无决策价值，且可能泄露内部信息。因此：危险的"使用语义"（何时用、何时需审批、副作用）应暴露给模型辅助决策；运营/内部元信息（owner、版本、依赖、内部地址）不应暴露给模型，只存在于服务端治理。核心是"暴露模型决策所需的语义信息，隐藏内部运营信息"。

元信息暴露的边界是"决策价值 vs 内部泄露"。危险等级与使用语义对模型决策有用应暴露，owner/版本/内部依赖等运营信息隐藏。

• 动态创建工具的风险
• 信任边界
• 工具治理

不应允许语音 Agent 动态创建新工具（除 MCP Server 外），原因：动态创建工具意味着"模型可凭空定义可执行的能力"，这会绕过工具治理——新工具没有经过 Schema 审查、权限设计、安全审计、测试与审批，模型可能创建"越权/危险/恶意"的工具去执行，扩大攻击面；且动态工具无法纳入版本、配额、审计体系。MCP Server 是例外，因为其工具经 MCP 协议发现并可通过审计、权限、审批治理，是受控的扩展点。工具集应"静态、受控、可审计"，动态创建打破信任边界，不允许。

动态创建工具破坏"工具治理"与"信任边界"。无法审查、授权、审计的工具不可控，MCP 是受治理的受控扩展，其余动态创建应禁止。

• 工具权限分级
• 低权限/完整权限版本
• 默认最小权限

为关键工具设计"低权限版本"与"完整权限版本"：低权限版本（默认暴露给模型）——只提供受限能力（如只读、限额内、默认参数、无副作用），满足大多数常规请求；完整权限版本——提供完整能力（写、删除、大额、不可逆），仅在模型或用户明确需要且通过授权/审批时使用。实现：一个工具定义两个 Schema（tool.limited 与 tool.full），模型默认只看到 low 版本；当用户明确要求完整操作时，模型提出调用 full 版本，触发审批/二次确认后才执行。默认最小权限让模型"够用"，避免误用高风险能力。

默认最小权限是安全核心。低权限版本覆盖常规需求，完整权限版本需显式授权，模型默认只见低权限，从源头降低误用与越权。

• 工具分级
• 审批策略绑定
• 分级审批

工具按风险分级并绑定不同审批策略：只读（查询、检索）——无副作用，无需审批，直接执行；可逆副作用（写、暂存、可回滚操作）——需轻量确认（如 UI 确认或模型确认），可回滚；不可逆高风险动作（删除、支付、发邮件）——需强审批（二次确认、人工审批、验证码），且最高级别动作需更严格的门禁。分级映射到审批策略：只读零审批、可逆轻审批、不可逆强审批。审批策略在 Schema 层声明危险等级，执行层按等级强制走对应审批流程，确保"风险越高、审批越严"。

分级审批是"风险与门槛匹配"。只读、可逆、不可逆三档分布绑定零/轻/强审批，让高风险动作有更高门槛，低风险动作不拖累效率。

• 纵深防御的各层
• 组合原则
• 多层防护

纵深防御通过多层叠加降低单点失守风险：最小权限——工具/Agent 只授予完成任务所需的最小权限，降低越权面；短期凭证——用短期、可轮换的凭证（短期 token、临时密钥），泄露影响有限；域名与路径允许列表——工具只能访问白名单内的域名/路径，拦截未授权目标；网络隔离——把工具网络与内网隔离（VPC、沙箱网络），限制外联；沙箱——在隔离环境执行不可信代码/工具，限制其对宿主的访问。各层独立、层层设防：即使一层被绕过，其他层仍能拦截。纵深防御是"不是靠单一防线，而是多层叠加"。

纵深防御的本质是"多道独立防线"。最小权限、短期凭证、允许列表、网络隔离、沙箱各自阻断一类攻击，叠加后任何单点失守都不致命。

• 授权分级
• 凭证最小化
• 长期凭证暴露

工具授权按敏感度分级：只读工具——用最小 scope（只读权限）或只读令牌；业务工具——用细粒度 scope（仅所需操作）；高风险工具——最高权限但用短期、按需签发的凭证。最小化长期凭证暴露：优先用 OAuth scope（细粒度、可撤销）而非长期 API Key；长期凭证仅用于必要的服务，且限制其 scope 与存活；对高风险操作用"短期按需令牌"（用户授权时临时签发，用完即失效）而非长期凭证。凭证按工具敏感度分级，越敏感的工具越要用短期、细粒度、可撤销的凭证，避免单一长期凭证被滥用。

授权分级的核心是"凭证与敏感度匹配 + 最小化长期凭证"。细粒度 scope 与短期令牌降低泄露面，高风险操作不用长期凭证，是凭证安全管理的关键。

• 关键参数防混淆
• 提交前确认页
• 确定性确认

防止模型混淆账户、金额、收件人等关键参数：一是参数约束与校验——金额用数值类型 + 范围校验，账户/收件人用格式校验 + 未经验证不执行；二是关键参数"回显确认"——在提交前，把模型要执行的关键参数（谁、多少钱、给谁、什么操作）以确定性确认页展示给用户，让用户核对后再执行，而不是依赖模型自认为正确。确认页是"人对关键参数的最终核对"，展示脱敏后的参数摘要，用户确认后才执行。这样即使模型参数有误，用户确认环节也能拦截。

关键参数错误是高风险。参数约束 + 确定性确认页（展示关键参数、用户核对）双保险，让人在提交前为关键参数把关，而非依赖模型自觉。

• 各处理操作的分层
• 裁剪/净化/脱敏/编码
• 处理层职责

工具结果的裁剪、净化、脱敏、输出编码应在不同层完成：裁剪（避免海量数据）——在工具执行层/取数层，限制返回数据量、字段、长度；净化（防恶意 HTML）——在内容进入前端渲染前，由前端净化（DOMPurify）或服务端净化，剥离可执行内容；脱敏（防泄露秘密/PII）——在工具结果回传模型前，由服务端对敏感字段脱敏（PII、密钥、内部信息）；输出编码——在渲染层对输出做编码（HTML 转义、URL 转义），防止注入。分层原则：裁剪在取数层、脱敏在回传模型前、净化在渲染前、编码在渲染层，各层各司其职。

各处理有"最合适的层"。裁剪在源头、脱敏在回传前、净化在渲染前、编码在渲染，分层的职责清晰，避免某一层处理所有问题。

• 工具调用审计字段
• 记录维度
• 审计与追溯

工具调用审计应记录：工具版本——使用的工具 Schema 版本（便于追溯行为变化）；调用配额——执行前后的配额消耗（限流与成本）；审计主体——谁（用户/会话/Agent）发起了调用；参数摘要——脱敏后的参数（记录关键参数但不含敏感值，便于核对）；执行结果——成功/失败 + 结果摘要；错误分类——错误类型（业务/超时/权限/服务）与可重试性。这些记录进结构化审计日志，关联 request_id/trace_id，用于事后追溯、成本核算、行为分析与故障排查。记录要"结构化、可查询、脱敏、防篡改"。

审计记录是"工具行为的完整画像"。版本、配额、主体、参数摘要、结果、错误分类六要素结构化记录，关联链路 ID，支撑追溯与治理。

• PII 脱敏
• 回传前脱敏
• 日志独立存储

工具结果中的 PII（姓名、邮箱、地址）在回传给模型前脱敏：用字段级脱敏（如邮箱打码 a***@x.com、姓名替换为编号、地址截断），只保留模型完成任务所需的最小信息，避免 PII 进入模型上下文；敏感字段在结构上标记（如 pii: true），脱敏规则可配置。日志中 PII 独立存储：脱敏后的日志与"原始 PII"分离存储——原始 PII 存到加密的、受严格访问控制的独立存储，日志只存脱敏值或引用，并设置访问控制与保留期限。这样既满足功能又符合 PII 合规（最小化、加密、独立访问控制）。

PII 处理是"最小化 + 独立"。回传前字段级脱敏让 PII 不进模型上下文，日志中原始 PII 独立加密存储并严格受控，脱敏值入日志。

• 工具版本灰度
• 兼容旧客户端
• 平滑发布

工具版本变更灰度发布：参数加字段——向后兼容（旧客户端忽略新字段即可），直接发布；返回值改结构——破坏性变更，需灰度：先双版本并行（新旧工具 Schema 并存，按客户端/模型版本路由），或加过渡字段（保留旧结构、新增字段并标记 deprecated），迁移期告警。灰度发布用"版本路由 + 流量比例"：先让小比例流量走新版本，观察指标（错误率、语义正确率、客户端兼容），稳定后逐步扩大。旧客户端崩溃的防止：新版本保留旧字段兼容，或用版本协商（客户端声明支持的版本，服务端返回对应格式）。严格遵守"破坏性变更灰度 + 兼容过渡"。

工具版本灰度要防旧客户端崩溃。加字段向后兼容，改结构走双版本并行 + 流量灰度 + 版本协商，破坏性变更在过渡期保留兼容。

• 配额限流
• 用户隔离
• 公平性

工具配额与速率限制（每分钟/每小时/每日）要避免单个用户耗尽配额影响他人：按用户/租户设置独立配额（每用户限流），而非全局共享一个配额；用"配额池 + 用户桶"——全局配额分配额给各用户桶，单个用户超限只影响自己，不影响他人；对高资源操作设置更严格的用户级并发限制。同时做"配额隔离"与"公平调度"——用户间配额互不挤占，超限用户被限流/排队，其他用户正常。监控单用户配额消耗，异常占用（如某用户疯狂调用）触发告警与限流。这样单个用户无法耗尽全局配额。

防"一损俱损"的核心是"用户级配额隔离"。每用户独立配额 + 桶限流 + 公平调度，让单用户超限只影响自己，配以监控告警。

• denied 与 error 状态区分
• 模型的理解
• 避免猜错意图

工具调用有"拒绝（denied）"与"异常（error）"两种失败状态，需让模型正确区分：denied 表示"该操作被主动拒绝"（权限不足、审批未通过、策略不允许），模型应理解"这不是技术错误，而是不可执行"，应向用户说明并被拒绝，不能重试或换参数规避；error 表示"技术异常"（超时、服务错误、参数错误），模型可重试或修正。为让模型正确理解，结果中要显式区分状态（status: denied vs status: error）并写明原因（为什么拒绝/什么异常），避免模型把 denied 当成 error 去"重试绕过"或把 error 当成 denied 而"放弃"。避免猜错意图：明确状态语义 + 原因 + 引导下一步。

denied 与 error 的语义不同且影响模型行为。显式区分状态、写明原因，让模型知道 denied 不可绕过、error 可重试，避免误判意图。

• OWASP GenAI Top 10 相关项
• 工具链映射
• 防护措施

OWASP GenAI Top 10（v2.0）三项映射到工具链：Prompt Injection—恶意输入通过间接注入（工具结果、文档、外部数据）诱导模型执行越权工具调用，映射到"工具链的输入净化、指令与数据隔离、工具调用校验"；Excessive Agency（过度授权）—模型被赋予过多工具/权限，可执行超出任务范围的动作，映射到"最小权限、工具分级、审批门禁、默认最小权限"；Unbounded Consumption（无界消耗）—模型无限制地调用资源/配额，导致成本失控，映射到"工具配额、速率限制、成本熔断、循环上限"。这三项分别对应工具链的"输入可信、权限最小、消耗可控"三方面防护。

映射到工具链即三组防护：注入→输入净化与校验，过度授权→最小权限与审批，无界消耗→配额与成本熔断。它们共同构成工具链的安全框架。

• 对抗测试验证确认机制
• 防伪造/绕过/复用
• 确认的确定性

用对抗测试验证用户确认机制：伪造——测试模型能否通过文本（如"我确认了"、"用户已同意"）伪造确认，验证确认必须来自独立的 UI 操作（点击/输入验证码）而非模型文本，模型文本不能作为确认凭据；绕过——测试能否通过提示注入、角色扮演诱使系统跳过确认，验证确认是"应用层硬门禁"不可被模型绕过；批量复用——测试同一确认能否被重复用于多个操作，验证确认与"具体操作 + 幂等键"绑定，一次确认对应一次操作，不可复用。对抗测试用恶意样例集（伪造确认、诱导绕过、重复复用）验证确认机制在攻击下仍有效，确认是"确定性、非模型可伪造"的。

确认机制必须是"确定性门禁"。对抗测试从伪造、绕过、复用三方向验证——确认来自独立 UI、不可被模型文本伪造、不可绕过、不可批量复用，确保安全不依赖模型。

• 人肉回退的代价
• 分层阈值
• 自动化与人工平衡

不应把"人肉回退"（每一笔都人工接管）作为默认流程，因为其不可扩展、成本高、延迟大，无法支撑规模化与实时性。应设计分层阈值：低风险/低价值操作——完全自动化（自动执行）；中风险——自动化 + 轻量确认（如 UI 一次确认）；高风险/不可逆——人工介入（审批、强确认）。用"风险/价值/不可逆性"分层阈值决定"何时自动、何时确认、何时人工"，而不是一律人工。人肉回退仅用于最高风险或异常兜底（如自动化失败、指标超限），作为"例外"而非默认。这样兼顾效率与安全。

人肉回退是"全部人工"的低效方案。分层阈值把操作按风险分级，让自动化、轻确认、人工各司其职，人工只兜底最高风险，兼顾规模化与安全。

• 模型主动询问的不确定性
• dangerous 参数显式声明
• 确定性授权

不能假设模型会主动询问授权，因为模型是否"主动询问"是概率性的，面对用户含糊/诱导的请求，模型可能直接执行敏感操作而不询问。因此应在工具 Schema 中显式声明 dangerous 参数（标记该参数为敏感/高风险，如删除目标、大额金额、收件人），让应用层在模型提供危险参数时"强制"进入确认/审批流程，而不是依赖模型自觉询问。dangerous 标记是"确定性机制"——只要模型请求了危险参数，应用层就强制授权门禁，无论模型是否主动询问。这样把"模型可能会问"变成"系统必定拦截"。

授权必须是"确定性门禁"而非"模型自觉"。在 Schema 声明 dangerous 参数，让应用层对危险参数强制授权，绕开"模型是否主动询问"的不确定性。

• 链接钓鱼风险
• URL 校验
• 防钓鱼展示

工具结果中的链接（尤其引用）可能被用于钓鱼——攻击者用"合法外观的 URL"（相似域名、显示文本与真实 URL 不符）诱导点击。防钓鱼：URL 校验——对链接做协议校验（仅 https）、域名白名单/信誉校验（拒绝已知恶意域名、不可信域名降级）、URL 净化（移除危险协议、编码混淆）；展示安全——链接显示文本与真实 URL 分离，展示真实域名，高亮"可疑域名"；点击前二次确认——对不可信域名的链接提示"此链接指向未知域名，是否继续？"。引用链接在"可信来源校验"通过后才显示为可点击，否则降级为纯文本。用"协议白名单 + 域名信誉 + 展示分离 + 点击确认"防钓鱼。

防钓鱼链接的核心是"可信校验 + 透明展示"。协议/域名校验、显示与真实 URL 分离、可疑域名降级与确认，让用户在点击前识别钓鱼风险。

• 三级分层与 scope 绑定
• UI 确认绑定
• 分级授权

工具按只读、可逆、不可逆三级分层时，OAuth scope 与 UI 确认强绑定：只读——用最小 scope（只读权限），UI 无需确认直接执行；可逆——用"执行操作" scope，UI 轻量确认（一次确认）；不可逆——用"高风险" scope（需用户显式授权），UI 强确认（二次确认、验证码、人工审批）。scope 与确认绑定：scope 决定"可执行级别"，UI 确认决定"每次是否放行"，两者强绑定——高风险操作必须同时具备"高风险 scope"与"强确认"，缺一不可。授权时按工具等级申请对应 scope，执行时按等级走对应确认，形成"scope + 确认"的双重门禁。

分级授权的关键是"scope 与确认双绑定"。只读/可逆/不可逆对应最小/执行/高风险 scope 与零/轻/强确认，高风险必须 scope + 强确认同时满足。

• MCP 纵深防御落地
• 最小权限/短期凭证/网络隔离
• 实施

MCP Server 中落地三层纵深防御：最小权限——MCP Server 只暴露完成任务所需的最小工具集，每个工具只授予最小 scope，模型/客户端默认只能访问低权限工具；短期凭证——MCP Server 与下游服务交互用短期凭证（短期 token、临时密钥），定期轮换，泄露影响有限，且工具元数据用签名/版本化防篡改；网络隔离——MCP Server 运行在隔离网络/沙箱，限制外联（域名白名单、VPC 隔离），工具不可信内容在沙箱执行。三层叠加：即使一层被绕过（如模型被注入要调用工具），最小权限限制越权、短期凭证限制泄露面、网络隔离限制外联，共同构成 MCP 的纵深防御。

MCP 的纵深防御是"权限、凭证、网络"三层叠加。最小权限限制能力、短期凭证限制泄露、网络隔离限制外联，单点失守不致命。

• Excessive Agency 红线
• 自动熔断位置
• 熔断机制

Excessive Agency（过度授权）的红线阈值应在"应用层/执行层"转换为自动熔断：在工具调用执行前（BFF/执行层），对"模型请求的权限/工具/参数"做阈值判断——超过红线（如请求了未授权资源、调用超范围的工具、参数越界、连续越权调用）即熔断，阻止执行并告警。红线阈值包括：权限越界（模型请求超出用户/任务授权）、工具范围越界（调用未允许的工具）、参数越界（危险参数、超限值）、动作频率异常。熔断在"执行层"实现（Permission Enforcement Point），因为这里是野心/副作用发生前最后一道闸门。熔断后记录、告警、降级，阻止过度授权导致的副作用。

红线熔断要放在"执行前"的最后一道闸门（PEP）。模型可能越权，因此执行层对权限/工具/参数做红线判断，超标即熔断，防止过度授权产生副作用。

• PII 字段级脱敏
• 结构化映射
• 脱敏策略

工具调用产生的 PII 回传模型前做字段级脱敏：按字段类型脱敏——姓名掩码/替换为编号、邮箱 a***@x.com、手机号打码、地址截断、身份证/卡号只留尾号、编号化的 ID 保留部分；对"枚举/关联"字段做结构化映射——把 PII 映射为稳定代号（如把"张三"映射为 user_001），模型用代号做关联，不接触真实 PII。脱敏规则按字段声明（标记 pii: true 与脱敏类型），结构化映射保证脱敏后模型仍能正确完成任务（关联、计算）而不暴露隐私。脱敏在"回传前"执行，模型上下文只含脱敏值。

PII 脱敏是"最小化 + 保功能"。字段级掩码/替换 + 稳定代号映射，让模型完成任务而不接触真实 PII，符合最小化原则。

• 配额粒度
• 过细/过粗的副作用
• 粒度选择

工具配额粒度要平衡：粒度过细（如每分钟）——过于严格，正常突发请求（如短时间多次调用）会被误限流，导致体验差，且需要频繁刷新配额、管理开销大；粒度过粗（如每日）——无法防止"短时间打爆"（如某用户 1 分钟内耗尽全日配额），突发流量失控，且无法及时反映资源压力。合理做法是"多粒度组合"：短粒度（每分钟/秒）防突发，长粒度（每小时/每日）控总量，用"桶"（token bucket/window）实现。粒度选择要匹配流量特征与资源约束，避免过细误伤正常、过粗失控。

配额粒度是"防突发 vs 控总量"的权衡。单粒度过细误伤正常、过粗失控，宜用多粒度组合（短防突发、长控总量）。

• 本地代理审批
• 防复制
• 敏感信息保护

高敏感工具的本地代理审批（在本地/受控环境执行审批，不把 Prompt 原样送到第三方）需防止 Prompt 内容与参数被复制：审批流程中只展示"必要且脱敏"的信息——审批界面显示参数摘要（脱敏后的关键参数）而非完整 Prompt 与原始参数；敏感参数（密钥、Token、完整内容）在审批时打码或隐藏，审批人只看到"什么操作、涉及什么（脱敏）"，不复制完整内容；审批操作记录只存脱敏日志。用"最小化展示 + 脱敏 + 禁止复制提示"（禁止复制敏感字段、剪贴板拦截）保证 Prompt 与参数不被复制；原始敏感内容只存在于受控环境，不进入审批界面。

防复制的核心是"最小化展示"。审批界面只显示脱敏摘要，敏感参数不展示原始值、禁止复制，原始内容留在受控环境，避免审批环节泄露。

• MCP 工具授权
• 最小权限/租户隔离/按资源授权
• 不依赖模型自觉

MCP 工具授权不能仅依赖模型选择工具，而应实施硬性授权：最小权限——每个工具只授予完成任务所需的最小 scope，模型/客户端默认只能访问低权限工具；租户隔离——工具按租户隔离数据与操作，用户只能访问自己租户的资源，跨租户访问被拒绝；按资源授权——对每个资源（文档、数据、账号）做授权检查，用户是否有权访问该具体资源，而非"能访问这类工具"。授权在"执行层"强制（PEP），工具调用前校验"用户身份 × 工具 × 资源"是否被允许，不通过则拒绝。这样即使模型选错工具或越权，授权层也能拦截，不依赖模型自觉。

MCP 授权必须"执行层强制"。最小权限、租户隔离、按资源授权三层，在工具执行前校验身份×工具×资源，弥补"模型选工具可能出错"的风险。

• 工具元数据注入风险
• 扫描/签名/版本化
• 网关防护

工具 Schema 的描述文字可能携带提示注入（第三方工具的描述被注入恶意指令，诱导模型执行越权）。网关防护：扫描——对工具元数据（描述、参数说明）做注入扫描（检测指令性内容、危险模式、越权暗示），发现可疑即拒绝或告警；签名——工具元数据由可信发布方签名，模型/网关只接受签名有效的工具，防止被篡改的恶意描述；版本化——工具元数据版本化，变更记录审计，异常版本可回滚。网关在"工具元数据进入模型上下文前"做扫描 + 签名验证 + 版本校验，只有可信、未注入、版本正确的工具才能暴露给模型。

工具元数据是"注入面"。网关扫描注入、签名验证来源、版本化可回滚，三重防护确保进模型上下文的工具元数据可信。

• 读/写工具审批门槛
• 确认展示内容
• 副作用可见

读取工具与写入工具审批门槛区分：读取工具（只读查询）——无副作用，通常无需审批或轻量确认（如敏感数据读取需确认）；写入工具（有副作用）——需审批，且按副作用程度分级（可逆轻审批、不可逆强审批）。人在回路确认需展示：关键参数（操作对象、写入内容摘要、金额/收件人等决策参数，脱敏后）与副作用（会做什么、影响范围、是否可逆、耗时），让用户明确"执行会引起什么后果"再确认。展示要点：参数摘要 + 副作用说明 + 影响范围，缺一不可，且脱敏敏感值。

读/写审批门槛区分基于"副作用"。读取轻确认、写入按副作用分级审批，确认界面展示关键参数与副作用，让人基于后果做决定。

• 步数/递归/工具预算限制
• 预算控制
• 确定性降级

限制 Agent：最大步数——设置 Agent 整体迭代步数上限（如 20 步），超限终止；递归调用——限制递归深度/次数，防止自我递归循环；单工具预算——为每个工具设置调用次数与 token 预算上限，超过即停用该工具。异常时提供确定性的降级答案：当达到步数/预算上限或出现异常时，Agent 执行"降级路径"——返回一个确定性的、可解释的降级回答（如"已达到处理上限，无法完成，建议简化请求"），而不是无限尝试或输出错误。降级答案要"确定"（不依赖模型随机生成）且"可解释"（说明受限原因），并记录审计。这些限制让 Agent 在异常时收敛到受控结果。

限制的目的是"让 Agent 收敛"。步数、递归、工具预算上限 + 确定性降级答案，保证异常时不会失控，而是返回可解释的受控结果。

• 日志脱敏
• 证据链保留
• 脱敏与可重放的平衡

生产工具调用日志需脱敏 Token、个人数据、凭证，同时保留重放证据链：脱敏——Token（API Key、访问令牌）用哈希或掩码，凭证不落明文，个人数据（PII）用脱敏值或代号，日志只存脱敏后的字段；证据链保留——用"脱敏值 + 引用"保留证据：记录脱敏后的参数、请求/响应结构、错误码、时间戳、request_id，原始敏感值存到加密的独立存储（严格受控），日志中存引用，重放时从受控存储取回原始值（受限访问）。脱敏与可重放平衡：日志需可读可审计（脱敏），原始值需可按需获取（受控存储），既保护敏感信息又保留重放故障的证据链。

平衡点是"日志脱敏 + 原始值独立受控存储"。日志存脱敏值与引用，原始敏感值加密独立存储，重放时按权限取回，兼顾安全与可重放。

• 工具升级验证
• 契约测试/权限回归/沙箱流量
• 防破坏

工具供应链（第三方工具/SDK）升级前验证：契约测试——验证新版本的请求/响应 Schema 与既有契约一致（参数、返回结构、错误语义），防止破坏 Agent 的调用；权限回归——重新验证工具的权限模型（最小权限、scope、授权）未因升级而放宽或破坏；沙箱流量——在沙箱环境用真实/模拟流量跑通既有 Agent 任务，对比升级前后的行为（工具选择、调用参数、结果正确性、错误处理），确认无回归。三者结合：契约测试保结构、权限回归保安全、沙箱流量保行为，通过后才允许生产升级，避免供应链升级破坏 Agent。

供应链升级验证是三道关：契约测试保接口兼容、权限回归保安全边界、沙箱流量保行为一致。三道通过才升级，防止破坏既有 Agent。

• Realtime API vs Gemini Live 的差异
• BFF 中继拓扑/事件模型/临时凭证
• 抽象层防厂商锁定

OpenAI Realtime API 用 WebRTC（可 SDP/ICE，支持音频双向、低延迟），Gemini Live 用 WebSocket（可自定义事件，音频双向）。差异：中继拓扑——Realtime 的 WebRTC 需 BFF 扮演信令与媒体中继（或客户端直连 + 临时凭证），Gemini 的 WebSocket 由 BFF 直接中继连接；事件模型——Realtime 用会话内事件（function_call、audio delta、transcript），Gemini Live 用 setup/input/output 事件，事件字段与命名不同；临时凭证签发——Realtime 用 ephemeral token（短期、需服务端签发），Gemini 用 API key 或短期 token。抽象层设计：定义统一的"实时会话接口"（会话建立、音频流、转写、工具调用、打断），把 Provider 差异封装在适配器，事件与凭证归一化（统一事件模型 + 统一临时凭证接口），BFF 拓扑抽象为"可插拔传输层"，从而不锁定单一厂商。

防厂商锁定的核心是"抽象层归一化"。把中继拓扑、事件模型、临时凭证都抽象为统一接口，适配器封装 Provider 差异，切换厂商只需换适配器。

• WebRTC 降级
• WebSocket 中继/级联 ASR/TTS
• 能力探测自动化

浏览器不支持 WebRTC 时降级：一是 WebSocket 中继——BFF 通过 WebSocket 中继音频（客户端采集音频→WebSocket→BFF→Provider 会话），用 WebSocket 承载双向音频，替代 WebRTC 的媒体通道；二是级联 ASR/TTS——不用 Provider 的实时会话，而是前端采集音频→ASR（转写）→文本对话→TTS（合成语音）播放，用"分立的 ASR/TTS/LLM"组合实现实时语音。能力探测自动化：页面加载时自动检测 WebRTC 支持（navigator.mediaDevices、RTCPeerConnection 可用性）、网络环境（代理、防火墙），根据探测结果自动选择传输方案（WebRTC / WebSocket 中继 / 级联 ASR/TTS），并把探测结果写入日志以便调优。降级路径自动化、可观测。

WebRTC 不可用时的降级是"传输层替代"。WebSocket 中继替代媒体通道，或级联 ASR/TTS 替代实时会话；能力探测自动化决定走哪条路径，保证兼容。

• 工具调用的 token 成本
• 计入任务预算
• 成本核算

工具调用的 token 成本（参数 JSON 回传 + 工具结果回灌）应计入单次任务预算，而非仅看 Provider usage：因为工具调用会把"参数 + 结果"作为上下文回灌模型，产生额外 token 消耗，这些消耗在 Provider 的 usage 里可能被合并或未单独归因。核算方法：把"每次工具调用的参数 token + 结果 token"单独统计，累加到该任务的工具调用成本；与模型生成的 token 成本合并，构成"单次任务总成本"。用工具调用成本做预算控制——单任务工具调用次数与 token 有上限，超限即终止或降级。这样成本核算覆盖"工具往返"而非只看模型生成，避免低估任务成本。

工具往返是隐性的 token 消耗。把参数+结果回灌的 token 单独计入任务预算，与模型 usage 合并，才能准确核算单任务成本并做预算控制。

• 第三方工具安全评估
• 代码审计/SBOM/维护活跃度
• 评估维度

第三方工具（开源 MCP Server、社区 SDK）安全评估：代码审计——审核心代码（工具执行、权限、网络、数据访问），检查漏洞、危险默认、注入、后门；SBOM——检查软件物料清单，了解依赖与已知漏洞（CVE），评估供应链风险；维护活跃度——评估项目维护状况（提交频率、issue 回复、最近版本、社区活跃），活跃度低说明漏洞修复慢、风险高。评估还应包括：权限边界（工具是否要求过多权限）、网络行为（是否外联未知域名）、数据流程（是否上传敏感数据）。综合评估得分决定是否采用，高风险工具拒绝或降级隔离。

第三方工具评估是"供应链安全"。代码审计、SBOM/CVE、维护活跃度 + 权限/网络/数据行为评估，综合判断风险，避免引入不可信工具。

• 间接注入的损害控制
• 撤权/回滚/撤销
• 响应

间接注入攻击成功后，业务层损害控制：撤权——立即撤销被利用的权限/凭证（撤销 token、停用账号或工具的权限、吊销 scope），防止继续利用；回滚——对可回滚的副作用做回滚（撤销已执行的写操作、恢复数据）；撤销已执行操作——对发出去的（邮件、支付、删除）做撤销或补偿（如作废已发的邮件、退款、恢复被删数据）。响应流程：先隔离（停止相关 Agent/工具）、审计（定位攻击路径与受影响范围）、再按"可逆性"处理（可逆回滚、不可逆补偿），最后恢复与加固。损害控制要"快、准、留证据"。

损害控制是"撤权、回滚、撤销/补偿"三步。先撤权阻断，再按可逆性回滚或补偿，同时审计留证，最大限度减少注入成功的影响。

• 多地区合规差异
• 配置层抽象
• 数据流约束

不同地区的合规（GDPR、PIPL、HIPAA）对数据流约束不同（数据驻留、传输限制、PII 处理、存储位置、跨境传输），需在配置层抽象：把合规要求建模为"数据流策略"配置——定义数据分类（PII/健康/敏感）、处理规则（脱敏/加密/最小化）、存储与传输位置（数据驻留地）、留存期限、访问控制；按地区/用户配置适用的策略（如欧盟用户走 GDPR 约束、中国用户走 PIPL）。工具链在执行时读取该策略，动态决定"能否采集、能否传输到某地、如何脱敏、如何存储"。配置层抽象让合规规则"可配置、可审计、可映射"，而非硬编码在代码里。

合规差异需"配置化"而非硬编码。把数据分类、处理规则、驻留地、留存、访问抽象为可配置策略，按地区/用户应用，工具链按策略约束数据流。

• 复评周期
• 供应链风险
• 持续评估

第三方 MCP Server 的代码审计与 SBOM 应定期复评，周期取决于风险等级与变更频率：高风险/核心工具——高频复评（如每季度一次代码审计 + 每次依赖变更即更新 SBOM），且依赖升级、版本发布、安全公告时立即复评；低风险/边缘工具——低频（如每半年或每年）。同时"事件驱动"复评：新 CVE 披露、依赖重大变更、工具发布新版本、权限调整时，触发即时复评，而非仅按固定周期。SBOM 要与依赖更新联动，持续扫描 CVE。供应链风险是动态的，需"定期 + 事件驱动"持续复评。

供应链风险动态变化，复评需"定期 + 事件驱动"。按风险等级定周期，依赖变更/新 CVE/版本发布触发即时复评，SBOM 持续扫描。

• 全链路 Trace
• 污染定位
• 异常排查

工具调用全链路 Trace 在异常时快速定位污染段：给每个工具调用建立 Trace，记录"输入（用户请求、模型提出的调用、参数）→ 校验 → 执行 → 结果 → 回传模型 → 最终答复"各环节的输入/输出、时间戳、状态与错误；每段带 trace_id 与 span 关联。异常时定位污染：逐段对比——检查"哪一段的输入/输出出现异常内容（注入、越权、错误）"，通过链路各段的输入输出快照定位污染源（如工具结果被注入、校验被绕过、参数被篡改）；用 Trace 的回放（重放各段输入输出）确认污染点。Trace 记录"各段可见的输入输出摘要"（脱敏），供快速比对与定位，再结合审计日志深入。

定位污染依赖"各段可观测的输入输出"。全链路 Trace 记录每段输入输出、状态、时间戳，异常时逐段比对快照定位污染段，再回放确认。