拆解 GPT-Live：跟 OpenAI 最新的全双工方案比，我们的数字员工差在哪
OpenAI 刚刚发布了 GPT-Live-1 的 API，这是目前公开信息最完整的一个"全双工语音模型"参考案例。（信息来源主要是 Desh Raj 对 GPT-Live 的公开拆解分析，很多细节是他基于 API 文档、定价和第三方评测反推出来的，不是 OpenAI 官方公布的，本文里凡是推测性的内容都会说明。）趁着这个机会，我们试图把它的架构做一些拆解，强行跟事半AI数字员工系统逐项摆在一起看看——不是"我们像不像"，不是我们对标，而是具体到每一层设计，谁的取舍是什么，我们还有哪些需要学习的地方。
GPT-Live-1 到底是什么
GPT-LIVE和大家熟悉的 GPT-Realtime 不是一回事。GPT-Realtime 是单一模型包办对话、推理、工具调用；GPT-Live-1 只负责"交互"这一件事——听和说同时进行，不发轮次结束事件，音频流进流出，模型自己决定什么时候该说话。真正的推理和工具调用被"委托"给一个后端模型（官方给的实例是 GPT-6 Astra），或者客户自己的业务系统。
这个拆分本身就是本文要谈的核心：当"交互"和"思考"被拆成两个角色之后，各自怎么设计，代价和收益分别是什么。
逐项对比
1. 整体架构：三种范式
| | GPT-Realtime | GPT-Live-1 | 事半AI数字员工 | |---|---|---|---| | 听说是否同一模型 | 是（单模型包办一切） | 是（前端模型专职听说） | 否（STT/LLM/TTS 三段式流水线） | | 推理归谁管 | 同一个模型 | 委托给后端模型（异步） | 编排层（Director+Rhythm+Plugin）决策，主 LLM 生成 | | 轮次判断怎么来 | 模型自带 | 模型自带（训练进前端） | 外挂的独立轮次检测模型 |
我们走的是第三条路：STT 把语音转成文字，一层认知编排（认知状态追踪 + 战略目标 Director + 对话节奏 Rhythm + 并行插件）决定这轮该说什么、什么语气，主 LLM 负责真正生成这句话，TTS 念出来。跟 GPT-Live-1 比，我们没有"一个模型同时听说"这个能力，依赖编排层拼接出来。
2. 决策如何喂给对话：三通道注入 vs 多优先级装配
GPT-Live 后端计算结束之后，通过三条固定通道将结果交回前端：instructions.append（行为指令，比如"别再纠结这个问题了"）、commentary.append（要说的具体内容）、thinking.append（内部推理上下文，不说出来）。每条最多 500 token，强制克制。
我们做了同一件事，但形态不同：Director、StyleMapper、插件、记忆、Rhythm 各自产出带优先级标记的 hint（[GOAL]/[EMOTION]/[CONSTRAINT]/[STYLE]/[CONTEXT]），由一个统一的装配器分类、按认知状态动态剪枝、拼成 Markdown 注入 system message。剪枝规则跟"500 token 硬上限"这种一刀切不一样，是按情境动态收紧的——比如耐心值很低、情况紧急的时候，会直接清空上下文类 hint、语气类 hint 只留一条，逼模型说重点。本质目标一致（别让模型收到互相矛盾的一堆提示），实现思路不同：OPENAI是协议层约束，事半AI是状态驱动的动态约束。
3. 委托 payload：只传"变化了什么" vs 我们每轮全量上下文
这个差异我们还在权衡。GPT-Live 委托给后端时，payload 里没有完整的任务描述，只有元数据，官方描述是"委托对象只包含元数据，而不是任务文本"，后端要自己从用户/agent 的转写差异里推断任务是什么。这么做省 token、省延迟，代价是后端每次都要做一次"猜任务"的推理。
事半AI恰恰相反：Director 每轮将完整的 CallMission 进度、已收集信息、对话历史都通过 prompt 注入给主 LLM，信息是全量、显式传递的，不需要模型"猜"。这个选择在我们的业务场景是合理的——外呼业务对准确性要求高，猜错代价大——但确实意味着我们每轮的 payload 比"只传变化量"这种设计更重。这是一个优化方向，如果可以，会很大提高我们的语音响应延迟。
4. 垫场机制：一句 filler vs 四层降级
GPT-Live 委托后端异步处理时，前端会先垫一句"我看一下啊"。我们这块做得更细致一点：FlashFiller 插件有四层降级——语义意图匹配（0.88阈值）→ 快速小模型现生成（限10 token/0.3s）→ 场景兜底词池 → 通用词池，命中优先级从上到下。同时跟主 LLM 是竞速关系（Race Mode）：谁先算完谁上，插件赢了就垫场再等 LLM，LLM 赢了插件任务直接取消。这块我们的实现路径比公开信息里描述的 GPT-Live 更复杂，倒不一定是谁更"先进"，只是我们这边需要处理的 provider 更多、延迟场景更碎，逼出来的方案更分层。
5. 轮次判断：练进模型 vs 外挂可切换引擎——这是最大的结构性差距
GPT-Live-1 不需要独立的"这句话说完了没"模块，因为听和说是同一个模型端到端训练出来的，官方文档写"虽非回合制模型，但天然支持轮次检测"，训练时用特殊标记标注用户开始/结束发言的时刻。
我们现在的轮次检测是外挂在 STT-LLM-TTS 流水线上的一个独立模型，跟生成回复的主 LLM 完全脱钩，甚至可以按环境切换不同引擎（音频端到端模型、中文专用文本模型等各有取舍）。这个差距短期内补不了的——训练一个端到端全双工语音模型不是我们现在的技术路线可以做到的，但也带来一个好处：轮次检测模型可以独立于业务 LLM 迭代，不需要等一个大模型整体重训才能拿到更好的判断效果，代价是我们要自己维护"外挂模型跟整条流水线怎么配合"这层工程复杂度，而且这层复杂度是真实存在的——换一次轮次检测模型，怎么验证它没有带来"话赶话""提前打断"这类副作用，本身就是一套需要持续打磨的工程问题，我们最近也正在这条线上做验证。
6. 语气与音色控制
GPT-Live 只有 12 种固定声音，音色不能改，但可以通过 prompt 控制语速、语气、停顿这些"怎么说"的维度。事半AI逻辑几乎一样——TTS 声音本体是预设的，能调的是语速/音量/停顿这些参数，再加上 StyleMapper 根据认知状态动态生成语气 overlay（比如耐心值低的时候"禁止修饰，单刀直入"）。这块算是殊途同归，两边都认定"声音身份"和"说话方式"是分开控制的两件事。
7. 状态记忆：过程轨迹 vs 状态快照
GPT-Live 维护一条"推理轨迹"——后端每次 thinking.append 的内容会跟用户音频、用户文本、agent 文本、agent 音频一起，作为持续存在的上下文流。这更像是"发生过什么推理"的过程记录，依赖模型自己去理解这条自然语言轨迹。
我们是另一种解法：认知状态（情绪、紧迫度、信任度、耐心值等约 15 个维度）是结构化的数值状态，纯规则更新（EMA 平滑 + 迟滞保护 + 保守负反馈，不调用模型，<10ms），每轮基于新输入增量更新，不是一条不断变长的轨迹。这两种方式各有取舍：他们的方式更灵活、能表达任意复杂的推理过程，但依赖模型自己去"读"这条轨迹；我们的方式更可控、可解释、成本几乎为零，但维度是提前设计好的，表达不了设计之外的状态。
8. 延迟结构：0.8 秒告诉我们什么
GPT-Live-1 在 Full-Duplex-Bench 上的轮次响应延迟是 0.8 秒，比纯流式模型（Moshi 0.25s、PersonaPlex 小于 0.2s）慢不少。只要架构里有"委托给后端做真推理"这一步，延迟就一定要付出代价，就算是 OpenAI 目前最好的商业化方案也一样，纯流式模型延迟低是因为它压根没有"委托"这个动作、所有能力都在同一个模型的同一次前向传播里。我们在延迟上花的大量精力，本质上是在同一类架构约束下打磨。
9. 评测方法论：事半AI需要补齐的一块
OpenAI 公开的评测手册用了三层测试框架：CRAWL（合成语音单轮请求，只测推理对不对）、WALK（真实录音+注入噪声/8kHz/丢包，只测对真实音频的鲁棒性）、RUN（两个模型互相对讲，专测重叠、打断这类只有真实全双工场景才会出现的行为）。
对照我们自己：CRAWL 我们有（离线重播引擎，能从快照恢复认知状态、纯文本重跑对话逻辑）。WALK 和 RUN 这两层我们目前是缺的——没有一套"标准化录音+注入噪声/丢包"的回归测试，也没有"模拟对抗性来电人"去专门测打断/重叠行为的自动化手段。现在改动轮次检测、打断处理这类参数，主要还是靠上线后看真实通话数据反推效果。这是接下来准备补的方向。
接下来我们会持续改进的地方
- 补齐WALK 层：搭一套标准录音 + 噪声/丢包注入的回归测试，把"这次改动会不会让 STT/轮次检测变差"这件事从"上线后看数据"提前到"上线前跑一遍"。
- 补齐RUN 层：实现轻量的"模拟刁钻来电人"对抗测试，专测打断/重叠这类全双工场景特有的行为。
- 持续跟进轮次检测模型的行业进展——"同一个模型同时理解语义和声学特征"这个方向正在成熟。
- 委托 payload 的"只传变化量"思路能不能借鉴到我们自己编排层的 token 成本优化上。