用 GPT-Live-1 给智能体接全双工语音：两种委托模式怎么选、怎么接

按官方入门文档的路径建立一条 Live 会话，验证音频输入输出与转写都正常。这一步不加任何后端逻辑：

验证清单：
□ 能听到模型说话（TTS 输出正常）
□ 模型能听到你说话，且转写与你说的一致
□ 打断测试：它说话时你插话，它会让位
□ 转写里能拿到结构化的事件流

Live 把「语音层怎么把活交给后端」分成两种模式，对应两种架构：

判断标准很简单：委托之前要不要经过你的业务逻辑？要，就用 Client 委托——比如先查权限、先做意图分类、要在多个内部服务之间路由。不需要，Responses 委托的链路更短、延迟更低。

Responses 委托的核心是把一个 OpenAI 后端配置挂到 Live 会话上，语音层自动为该后端准备请求并回传结果：

会话配置要点：
1. 在 Live 会话参数中指定 Responses 后端
   （模型、指令、可用工具随会话一并声明）
2. 用户开口 → Live 准备请求 → 后端执行 →
   结果回传 → Live 继续对话
3. 后端工具照常定义：web_search、
   function tools、MCP 均可用

这是 Client 委托最容易踩的坑，官方文档专门强调：委托事件携带的是元数据，不是现成的任务载荷。你要自己从转写事件与应用状态拼出真正的后端请求。

正确姿势：
1. 监听委托事件，拿到的是「发生了委托」这件事
   与相关元数据
2. 从转写事件 + 你的应用状态组装后端请求
   （用户说了什么、此前会话决定了什么、
    当前订单上下文是什么）
3. 后端执行自己的 Agent / 服务，带校验地返回结果
4. 把结果交回语音层，让它用人话播报

错误姿势：
  把委托事件直接当命令转发给后端
  → 后端拿到的是空壳元数据，什么都干不了

语音链路的失效方式和文本链路完全不同，官方入门指南给出的对照结构点出了三处要专门测的地方：

三个测点要在真实设备上测：开发机上用模拟音频跑通的打断逻辑，换到带底噪的耳机麦克风上可能完全变形——回声消除、半双工硬件、蓝牙延迟都会影响全双工行为。建议准备一套贴近真实用户环境的录音回放用例，每次改打断策略后回归一遍，并把每次的表现记进评测表，语义层面的退化往往是从这里先露头的。

成本结构：
  语音层    $0.05/分钟，按秒计费（10 分钟 = $0.50）
  后端模型  按所选模型 API 价，每次委托都计费
  工具执行  按工具标准价（含 OpenAI 托管工具）

监控建议：
1. 把「语音分钟数」与「委托次数」分开埋点
2. 单通电话的总成本 = 语音 + Σ每次委托的模型与工具费
3. 关注委托失败重试——重试的模型费照付

单通电话成本演算（假设）：
  通话时长 8 分钟
    → 语音层：8 × $0.05 = $0.40
  委托 3 次
    → 后端模型：3 × 单次委托 token 费（按所选模型价）
    → 工具执行：3 × 工具单价（含 OpenAI 托管工具按标准价）
  估算口径：语音层可精确预付，
           后端部分按历史会话的平均委托次数 × 平均单次费用
           预留缓冲，重试率高的场景缓冲至少翻倍

语音让交互门槛降低了，也让「说错话」的成本变高了。上线后先小流量灰度，重点盯动作类话术的准确率，再逐步放开。