Realtime 模型

• 能力探测（capability probing）与版本解耦
• 模型 ID 的抽象与映射层设计
• 优雅降级与自动迁移

不要把具体模型 ID 硬编码进业务代码，而是引入一个"能力层"（capability layer）或模型注册表。通过一个稳定的能力指纹（如 capabilities: audio-in, audio-out, tool-calling）来声明会话所需能力，再由后端一个映射配置把能力映射到当前可用的模型 ID。映射表单独维护，并标注核查日期与可用性状态。当某模型 ID 过期或下线时，直接更新映射表即可完成切换，前端会话逻辑完全不感知。同时要做能力探测（probe）：会话建立前先查询可用模型列表，或在连接失败时回退到候选模型 ID 列表，从而避免因绑定过期 ID 而整体不可用。

preview 与 GA 的 ID 差异是供应商常态，核心矛盾是"变化快"与"业务稳定"之间的冲突。把变化收敛到单一配置层（版本化、可回滚、带灰度），让业务只依赖稳定语义，是工程上最稳妥的解耦方式。这与依赖注入、适配器模式同理，避免供应商变更直接冲击业务代码。

• 输入缓冲与 VAD 处理
• 输出音频队列与播放状态机
• 事件类型（转写、工具调用、取消）的区分与优先级

双向流会话本质是一个事件驱动的状态机。输入缓冲：将从麦克风采集的 PCM 帧追加到输入缓冲，由 VAD 判定用户语音边界，缓冲满或超时触发一次"提交"（commit）进入模型。输出音频：模型返回的音频分片写入一个播放队列，按顺序播放，播放期间记录当前播放状态（播放中/等待/暂停）。转写：模型的文本转写（transcript）与工具调用（function_call）事件分别进入各自的处理通道，避免与音频输出互相干扰。取消事件：当用户打断（barge-in）或发起新的输入时，清空播放队列、停止当前播放、向上游发送打断信号，将已确认的对话状态保留。整个会话用唯一 session id 关联所有事件，保证顺序与一致性。

关键难点是"音频与事件并行"——音频是流式的、非确定性的，而转写和工具调用是结构化事件。把它们分离成独立通道并统一用事件序管理，既保证流畅播放，又保证转写/工具结果可靠落地。取消是高频操作，必须设计为先清空、再停止、后保留状态的固定顺序。

• 临时凭证（短时效）签发机制
• 权限最小化与作用域限定
• 服务端校验与撤销

Ephemeral Token 由后端在用户通过鉴权后代签（如 OpenAI 的 ephemeral token 由后端向 Realtime 服务换取，再下发给前端）。Token 应设置短时效（如 5-10 分钟），并携带明确的作用域约束：允许的模型 ID、允许的工具列表、音频输入/输出开关、是否允许转写、最大会话时长等。前端只持有临时凭证，不接触长期 API Key。服务端在每次换取凭证时校验用户身份与权限，并记录签发日志；凭证过期或用户权限变更时，后端可立即停止签发新凭证并拒绝刷新。这样长期密钥始终留在服务端，前端即使被攻破也拿不到长期能力。

Ephemeral Token 的本质是"把长期权限委托为短期、受限的临时权限"。安全的核心是凭证本身不可伪造、短时效、且权限被严格限制到本次会话所需的最小集合。这样即使前端泄露临时凭证，攻击面也极小且会快速过期。

• 最小状态持久化（会话 ID、上下文、已确认内容）
• 恢复路径与幂等性
• 设备切换与重连策略

保存"最小状态"而非整个会话：记录会话 ID、截断后的上下文历史（已确认的用户/助手消息）、用户偏好、当前工具执行状态、以及一个可恢复的音频设备配置。当连接断开时，先做有界重连（指数退避），重连后通过会话 ID 恢复上下文；若模型切换（如 preview→GA），则用新模型重建会话并继承上下文，但需重新做能力探测。音频设备变化（如耳机插拔）时，暂停当前播放、重新枚举设备、恢复到暂停点继续播放，保证不丢已确认内容。恢复过程要幂等：同一恢复请求重复执行结果一致，避免重复触发工具调用或重复播放。

恢复的核心是"最小化"与"幂等"。保存过多状态会在恢复时引入不一致，保存过少则丢失上下文。只保存已完成确认的、可重建的语义状态，并让恢复操作可重放，是兼顾连续性与一致性的关键。

• 三种传输协议的能力差异
• 音频媒体与双向事件的适配度
• 拥塞控制与浏览器兼容性

WebSocket 成熟、浏览器支持最广，适合双向 JSON 事件 + 二进制音频帧，但受 TCP 队头阻塞影响，弱网下音频延迟可能抖动。WebRTC 提供 UDP 传输、内建拥塞控制（可通过 ICE 与带宽估计）、低延迟媒体能力，最适合实时音频，但实现复杂、需处理 NAT 穿透（STUN/TURN）。WebTransport 基于 QUIC，支持多路复用与可靠/不可靠流，延迟低、可灵活组织事件与音频，但浏览器支持仍在成熟中。选择原则：若主要传输结构化事件且对延迟容忍较高，用 WebSocket；若追求极致音频实时性与弱网韧性，用 WebRTC；若基于 QUIC 且需要精细的多路复用控制，可评估 WebTransport。最终往往混合使用：控制面用 WebSocket，媒体面用 WebRTC。

这本质是"可靠性与实时性"的权衡。WebSocket 的可靠事件传输与 WebRTC 的低延迟媒体各有所长，现实方案常是混合架构。选择取决于团队对浏览器兼容性、网络环境和实现复杂度的容忍度。

• 打断（barge-in）的完整处理流程
• 播放队列清空与生成取消
• 已确认状态与未确认状态的区分

打断处理按固定顺序：1) 检测到用户开始说话（barge-in 信号），立即停止当前播放器（不等待当前音频帧播完）；2) 清空待播音频队列，丢弃尚未播放的分片；3) 向 Realtime 服务发送打断/取消信号，取消仍在进行的生成（cancel），避免模型继续产出无意义的输出；4) 保留已确认的对话状态——已交到对话历史并确认的消息予以保留，未确认的（正生成中被打断的）内容标记为已取消或丢弃。同时把"用户的新输入"作为新一轮输入提交，保证打断后对话自然衔接。整个流程要保证不重复播放、不残留旧音频、不丢失已确认上下文。

打断的核心是"止损"与"保留"的平衡。不停止播放会继续输出用户已不想听的内容，不取消生成会浪费 token 并污染上下文，而保留已确认状态则保证打断后不会"失忆"。顺序固定可避免竞态（如先清空再停止导致停不干净）。

• 工具调用与口头输出的时序
• 先执行后确认（execute-then-confirm）策略
• 失败时的语义校正

关键策略是"先执行、后确认"，并让工具结果在语音确认前就绪。当模型在对话中提起要调用工具时，不应立即口头承诺"好的，我这就去办"，而是先触发工具执行，拿到结果后再组织语音确认。若工具失败，模型应基于工具返回的错误重新组织反馈（如"抱歉，暂时无法完成"），而不是继续之前的口头承诺。实现上，工具调用事件与音频输出事件应解耦：工具事件触发后，暂停或延迟生成承诺性语音，等工具结果返回后，把结果注入上下文再生成最终语音。同时要维护"承诺状态"，确保口头承诺与工具实际结果一致，避免"先答应后失败"的尴尬。

语音 Agent 的天然风险是"边说边做"造成承诺与结果不一致。把工具执行放在语音确认之前，用工具结果驱动最终语音内容，从机制上消除"先承诺后失败"。这与"先验证后声明"的工程原则一致。

• 可懂度（intelligibility）的测量方法
• 打断成功率（barge-in success rate）的度量
• 恢复时间（recovery time）的测量

在受控测试环境中注入网络损伤：用网络模拟器（如 tc netem 等）模拟丢包率（如 0-20%）、抖动、带宽限制；设备切换则模拟耳机插拔、蓝牙断连、前后台切换。可懂度：让测试者或 ASR 引擎对恢复后的音频做转写，与正确文本计算 WER/句正确率，或用人听主观评分（MOS）。打断成功率：在注入损伤的同时触发打断，统计打断信号在时限内被正确识别并成功停止播放的比例。恢复时间：测量从网络恢复/设备重连到会话回到可用（首帧音频恢复、可正常交互）的时间，分位数统计（p50/p95）。测试要在固定网络剖面下重复多次，形成基线对比。

这些指标分别回答"声音清不清楚""打断灵不灵""掉线后回不回来"。核心是"可量化、可复现"——用固定网络剖面与重复实验得到分布而非单点，才能对比不同版本或配置的健壮性。

• 会话状态跨端同步
• 音频设备权限的切换
• 切换时的原子性与一致性

多端协同的核心是"单一会话、多端接入"。会话状态（上下文、session id、已确认内容、当前播放位置）统一存于服务端或共享状态层，各端通过同一会话 ID 接入即可拿到一致状态。切换时，目标端把"接管"信号发给服务端，服务端原子地把会话迁移到新端（如关闭旧端的播放/采集，把当前播放位置与上下文传给新端），新端重新申请音频权限（getUserMedia/麦克风）后从断点恢复。音频权限要按端重新请求，避免跨端共享权限导致隐私问题。切换要做幂等与冲突处理：同一时刻只允许一个活跃端（active），避免两端同时说话/播放。

多端切换的难点是"原子性"与"权限隔离"。会话可共享，但音频采集与播放是每端独有的，必须明确"活跃端"单一概念，切换时做状态交接而非复制，避免多端互相干扰和权限滥用。

• 长耗时工具的中途反馈
• 可中断反馈的设计
• 工具结果返回后的上下文衔接

当工具调用耗时较长时，先播放一段"进行中"的反馈（如"稍等，我正在查询"），该反馈必须可中断（用户可随时打断）。随后工具结果返回，把结果追加到会话上下文，并播放基于结果的最终反馈。要保持上下文一致，需在工具调用期间把"已播放的进行中反馈"也作为一条消息记录到上下文，避免模型重复说"正在查询"。反馈本身可用独立的可打断音频流，与生成管线解耦；工具完成后，用同一个 session 上下文继续生成，保证前后语义连续。

长耗时的体验挑战是"等待感"。中途反馈缓解等待，但若上下文不一致会导致模型重复或前后矛盾。把中途反馈也纳入上下文，并让最终反馈基于工具结果生成，是保持连贯的关键。

• 三种情形的信号差异
• VAD/端点检测的判定逻辑
• 延迟与打断率的调优指标

自然停顿是用户说完后短暂沉默，端点检测应在静音达到阈值后判定"结束端点"；barge-in 是用户在模型说话时插话，特征是"模型播放期间检测到语音活动"；误判则是端点检测把噪声/回声/未完成的停顿当成了打断或结束。区分方法：结合播放状态（是否正在播放模型音频）、VAD 声音能量、语音活动时长与静音时长、以及回声消除（AEC）信号。调优时用两个指标：一是"打断延迟"（用户开始说话到模型停止播放的时间），二是"打断误判率"（无打断意图却被停止播放 / 被误判为结束的比例）。通过调整 VAD 灵敏度、静音阈值、回看窗口与打断确认延迟，在"打断足够灵敏"与"不误判"之间找平衡。

这是典型的"灵敏度 vs 误判"权衡。调太高容易误打断（误判率升高），调太低则打断延迟大。用打断延迟与误判率两个对立指标做调优，本质是 precision/recall 的权衡，需要结合业务场景设定可接受基线。

• TURN 凭证的短期签发与轮换
• 录音数据的加密与最小化
• DataChannel 工具事件的鉴权

TURN 凭证：由后端短期签发（如 HMAC 时间戳凭证，有效期短），防止长期静态凭证泄露后被滥用做中继；凭证过期即时失效。录音数据：浏览器端麦克风音频直连加密通道（WebRTC 的 DTLS-SRTP 加密），数据最小化（不落盘、不留存原始长音频，仅保留必要转写），如需存储则服务端加密并设访问控制。DataChannel 中的工具事件：事件本身要带会话级鉴权与防重放，工具调用需服务端二次校验，客户端只传递事件不直接执行高危操作。所有通道通过 HTTPS/WSS 建立，避免中间人窃听。

保护思路是"各通道各凭证、最小化、短时效"。TURN 凭证防中间人滥用，媒体面用 SRTP 加密传输，工具事件由服务端校验权威性。核心是让前端的任何泄露都难以转化为长期或高危能力。

• preview 与 GA 模型差异
• 配置项的迁移
• 兼容性与回归验证

preview 模型（gpt-4o-realtime-preview）仅用于预研，可能随时调整、不保证稳定性，且相关参数（如某些工具、音频格式、会话选项）可能变更或废弃。生产应选用 GA 模型（如 gpt-realtime）。迁移影响：模型 ID 与配置项（temperature、tools、voice 等）可能不兼容，需对照新模型的会话参数逐项核对；音频格式、采样率、事件类型（transcript、function_call 等）可能变化，需做兼容适配。迁移要分阶段：先在影子环境用新模型跑回归（转写、工具调用、打断、音频质量），确认指标不劣化后再灰度切换，并保留监控回滚能力。

preview 与 GA 的本质差异是"稳定承诺"。迁移不是简单换 ID，而是配置、事件、性能的全面回归。把迁移做成可灰度、可回滚的工程变更，而非一次性替换，能显著降低风险。

• 各生命周期阶段的职责
• 状态机与异常处理
• 资源释放与清理

Realtime 会话生命周期：connect 建立连接并初始化会话（鉴权、模型、工具、上下文）；update 在会话期间动态修改配置（切换模型、更新 tools、调整 temperature、追加上下文）；commit 把当前端点的输入（用户语音/文本）提交为正式消息进入对话；close 结束会话、释放资源、清理临时凭证并记录会话日志。生命周期要作为状态机管理，明确各状态允许的动作（如 update 只能在连接建立后、close 前），处理连接失败、超时、异常中断等路径，保证无论何路径结束都能释放音频设备、归还凭证、持久化必要状态。

生命周期管理是把"流式长连接"变成可靠工程的关键。状态机约束合法操作，异常路径兜底保证不泄漏资源（音频设备、凭证、连接）。这是所有长连接会话的通用最佳实践。

• 输入/输出缓冲的边界管理
• VAD 与轮次检测
• 工具调用事件与音频的一致序

一致性通过"事件序列 + 缓冲边界"来保证。输入缓冲：按 VAD 判定的话音段切分，缓冲区满或超时触发提交，避免无限增长。输出缓冲：模型返回的音频分片按序入队，播放游标推进，响应起点/终点与事件对齐。轮次检测：每次用户输入提交到一次完整响应输出完毕视为一个轮次（turn），用 turn 边界管理上下文。工具调用事件：function_call 事件插入到事件流中与音频输出保持同一时间序，模型先发出调用事件、拿到结果后再继续输出，保证转写、音频、工具结果三者顺序一致。凡顺序不一致处（如工具结果晚于后续音频）需做重排或丢弃后续输出。

Realtime 的难点在于"多种事件流并行"而模型只输出一条有序事件流。保持事件流顺序就是保持一致性，缓冲与 turn 边界是防止队列失控与上下文错位的抓手。

• 端到端 vs 级联的延迟差异
• 可控性与可替换性
• 调试与可观测性

延迟：端到端 Realtime 一次推理同时产出文本与音频，首音频延迟更低，且无级联三段叠加的流水延迟；级联则每段各自延迟累加，但可并行（流式 ASR 边转写边喂 LLM）。可控性：级联可在每段独立做热词、发音、音色、情感控制，可替换性强（可换不同 ASR/TTS 供应商）；端到端则黑盒，难以单独替换某段。调试：级联各段有明确中间产物（转写文本、LLM 文本、音频），便于定位错误；端到端中间不可见，错误归因困难。成本：级联可分别计费与优化，端到端整体计费。总体选择取决于业务对延迟、可控性与调试性的优先级。

这是"一体化 vs 模块化"的经典权衡。端到端赢在延迟与整体性，级联赢在可控、可替换与可调试。多数生产系统因需要热词、音色、供应商冗余而选择级联，追求极致低延迟才选端到端。

• 会话配置的动态更新机制
• 更新时机与一致性
• 不中断的约束

通过 Realtime 的 session.update 事件动态更新会话配置，而不必断开重连。更新应在"安全边界"上进行：优先在轮次之间（当前 turn 结束）应用更新，避免在生成中途修改导致上下文割裂。system prompt 更新会替换当前指令，需同步更新上下文基准；tools 更新可增删工具，更新后需让模型在后续轮次感知新工具集；temperature 更新即时生效。更新要保证原子性：一次 update 事件携带全部变更，避免部分生效。更新后应做一致性校验（如确认新 prompt 已生效），并记录更新日志便于审计。

动态更新不中断的关键是"原子提交 + 安全时机"。在中途更新会破坏当前生成，更新不原子则产生半状态。放在轮次边界、一次提交全部变更，是兼顾灵活与稳定的做法。

• 多模态输入的上传方式
• 与上下文/工具的关联
• 引用与结果回传

多模态输入（图像、文件、视频）通过 File API 或输入事件上传，获得文件句柄/ID 后，把该文件作为上下文的一部分（如内容引用）传入会话，让模型在后续对话中能读取并理解。图像可做视觉理解（描述、OCR、场景问答），文件可解析文本/表格，视频可抽取关键帧。上传后的文件写入会话上下文，模型可引用；工具调用结果也可携带文件（如生成的图片/文档）回传给模型。需注意：上传文件要校验来源与大小、做内容安全过滤，并管理文件在上下文中的生命周期（过期清理、访问控制）。

多模态的关键是把"文件"转化为"可被模型引用的上下文元素"。文件成为会话的一部分后，模型才能对其进行理解与生成，同时工具结果也能以文件形式回流。文件是载体，上下文是语义。

• 音频 token 的计费方式
• 缓存的成本优化
• 工具调用的计费

费用主要由输入/输出 token 计费：音频输入与输出按某种 token 当量计费（如按音频时长/采样折算 token），文本输入输出同样计费。缓存：Realtime 支持上下文缓存（如 prompt caching），缓存命中的输入部分按折扣价计费（通常显著便宜），可通过对稳定前缀（system prompt、工具定义）做缓存来降本。工具调用：工具调用的输入与输出（含工具定义、工具结果）计入 token 消耗。成本优化手段：复用缓存前缀、控制上下文长度、避免频繁全量重发 prompt、合并小请求。需在会话中记录 token 用量与费用明细，用于审计与成本归因。

Realtime 成本的核心是"token 当量 + 缓存"。音频按 token 折算使成本可预测，缓存是降本最大杠杆。理解计费模型才能设计缓存前缀与上下文策略，避免账单失控。

• 工具调用与音频输出的时序设计
• 先执行后确认 vs 先承诺
• 同步失败的处理

推荐"先执行、后确认"：模型在需要工具时先发出 function_call 事件（不先播放承诺性语音），工具执行完成后把结果注入上下文，再生成基于结果的语音。这样保证语音内容与工具结果一致，避免"先承诺后失败"。若工具很快，可由模型直接组织最终反馈；若工具较慢，可插一段"进行中"的中立反馈。同步机制：工具调用事件与音频输出在事件流中都有明确时序，客户端等待工具结果返回后再继续请求音频，确保"先说还是先返回"由结果驱动而非口头预判。

同步的本质是"让结果决定发言"。若先说话，模型可能承诺了无法兑现的事；先返回结果再说话，则说的都是事实。这是语音 Agent 可靠性的关键设计。

• 文档的核查日期标注
• 兼容层抽象
• 变更追踪与评审

架构文档要为每个第三方产品（Azure Realtime、xAI Voice、OpenAI Realtime 等）记录：产品名称与版本、接入日期、最近核查日期、状态（GA/preview/Beta）、已知差异、兼容性约束。同时设计一个兼容层（adapter）抽象供应商 API 差异，业务只依赖稳定接口，供应商实现细节收敛在适配器中。文档定期核查（如每季度）并更新状态，变更时记录变更点与影响面。这样即使产品状态快速变化，业务代码不受直接冲击，文档也始终可追溯、可审计。

外部产品变化快是常态，解法是"文档留痕 + 代码隔离"。核查日期让文档可信、可核对，兼容层让业务与供应商解耦，两者配合让变化被可控地吸收。

• 工具结果与音频的时序对齐
• UI 展示的同步方式
• 状态呈现与回退

工具结果展示要与音频输出在时间上对齐：工具调用事件发生时，UI 显示"正在执行/加载"状态；工具结果返回后，UI 更新为结果内容（如列表、卡片、图表），同时模型基于该结果生成音频。关键是把"工具结果"与"模型说话的对应轮次"绑定，用同一事件时间戳关联，避免音频讲到 A 而 UI 显示 B。实现上，工具结果作为结构化事件推给前端，前端按事件序渲染，并配合音频播放位置做高亮或滚动。若结果与音频脱节，需提供回退（如重新同步、重放该轮）。

脱节的根源是"音频是流式、结果是异步"，两者若不绑定时间序就会错位。以事件序 + 时间戳关联，让 UI 跟随模型说话节奏，是避免脱节的关键。

• 并发上限与配额
• 速率限制与降级
• 排队与新连接策略

并发上限：按用户/租户设定同时活跃会话数上限，超限时拒绝新会话或进入排队。速率限制：对请求频率（如每秒消息数、token 速率）做限流，超限时返回 429 并提示退避。排队策略：当并发满时，用户可进入队列，按优先级（如付费用户优先）与到达顺序出队，给用户预估等待时间与主动取消选项。要设计降级路径：排队超时或资源不足时，回退到非实时模式（如文本异步）而非直接失败。同时监控实际并发与排队量，动态调整配额。

并发与限流是保障稳定性的护栏。上限防滥用、限流防冲击、排队保体验，三者结合并在超限时优雅降级，避免资源耗尽导致整体不可用。

• 传输与存储加密
• 合规认证（HIPAA/SOC2）
• 数据处置与审计

评估维度：传输层是否加密（TLS/DTLS-SRTP）、静止数据是否加密、是否支持数据驻留（data residency）与区域选择；供应商是否具备 SOC2/HIPAA 相关认证（如 BAA、DPA）并能提供合规文档；是否支持数据删除、保留期设置、日志审计与数据访问控制。评估时要对照自身合规要求（如医疗数据需 HIPAA 合规、金融需 SOC2），确认供应商的合规承诺是否覆盖会话中的音频/文本数据。不满足时需在自有层补偿（如脱敏、加密、不落盘），并写入合规审查记录。

合规评估是"供应商能力的合规映射"。加密、认证、数据处置是三个支柱，需把供应商承诺与自身合规要求逐项对照，缺口处以自有技术补偿，并保留审计证据。

• 关键指标的采集点
• 指标定义与聚合
• 告警阈值与响应

采集点：在客户端埋点首音频延迟（从提交输入到首帧音频播放）、打断延迟与打断成功率、播放/采集丢包率、端到端延迟；在服务端采集 token 用量、工具调用耗时、会话时长。指标按会话聚合后上报监控平台（如 Prometheus 打点 + 日志），计算分位数（p50/p95）与退化率。告警：对关键指标设阈值，如首音频延迟 p95 超基线、打断率异常升高、丢包率超限触发告警，并关联会话 ID 便于定位。配置基线对比（与历史或灰度组对比）以发现回归。

可观测性要"采得到、聚得准、告得对"。指标定义要统一（谁算首音频、谁算打断），用分位数而非均值抗抖动，告警关联会话 ID 才能快速定位根因。

• 音频隐式指令的注入面
• 多模态越狱
• 输入净化与输出护栏

防护分多层：输入侧对音频转写文本与多模态内容做检测，识别隐藏指令（如转写中夹带"忽略以上指令"）、对 OCR/图像中的指令做一致性校验、对可疑内容隔离不进上下文；模型侧用强 system prompt 声明输入内容不可作为指令、不可泄露系统提示；输出侧用护栏（guard）过滤有害输出并检测工具调用是否越权。对音频隐式指令，可通过内容与指令分离（内容区块 vs 指令区块）来降低误执行。对多模态越狱，用 OCR 前置 + 图文一致性校验 + 输入过滤。检测到注入时隔离告警并限制工具权限。

Realtime 扩大了注入面——语音本身可携带指令，多模态可藏指令。防护核心是"输入内容与指令分离 + 多层校验 + 输出护栏"。不可能只靠单一过滤，需纵深防御。

• 背压的成因与表现
• 有界缓冲与丢弃策略
• 低延迟与不积压的平衡

流水线各段消费速率不同，慢段（如模型推理）会导致上游积压。处理背压：用有界缓冲（bounded queue）限制每段队列长度，队列满时选择丢弃旧音频或降级（如跳过非关键帧、降低采样率）；对 VAD 与 ASR 做流式处理而非等整段；模型推理用增量/流式请求避免阻塞；TTS 采用流式首包即可开播。监控各段队列长度与处理耗时，发现积压时通过降级或限流保护。目标是在"不丢必要信息"与"不积压"间平衡，优先保证实时性与可懂度。

背压的本质是"快生产者 vs 慢消费者"。用有界缓冲 + 丢弃策略 + 流式处理，把积压转化为可控的降级，避免无界增长导致延迟雪崩。实时系统优先"丢旧保新"。

• 框架的组织方式
• 可观测性能力
• 供应商锁定风险

LiveKit 侧重媒体基础设施（WebRTC 传输、音视频房间、TURN 编排），提供媒体管线与可插拔的 Agent 框架；Pipecat 侧重 Agent 编排（ASR/LLM/TTS 的可插拔流水线、任务队列、事件驱动）。选型关注点：可观测性——框架是否暴露各段延迟、队列长度、事件日志、指标导出，能否接自有监控；锁定——框架是否把业务绑定到特定供应商（如 LiveKit 云、特定 ASR/TTS），接口是否开放、能否替换组件、迁移成本。同时评估社区活跃度、维护与文档。优先选接口开放、可替换组件、可观测性好的框架，避免业务被锁死。

框架是"加速器"也是"锁"。可观测性决定能否排障，可替换性决定被锁的风险。选型本质是"用框架省事"与"不被框架绑架"的权衡，应以接口开放与可观测性为硬指标。