Voice Agent 和实时转写服务可以监听同一段音频，却承担不同结果。Agent 需要决策和回应，转写服务需要产出有顺序、可归属、可修订的文字记录。把 Transcript 当作对话会话的附带字段，会掩盖时序、排序、质量和成本问题。独立的协议合同能让每类失败可测量，让每个下游消费者的责任清晰。
阅读时间： 约 8 分钟 · 约 2800 字
TL;DR
- 实时音频与流式输出是两个设计决策。OpenAI 对只需文字、不需语音回复的实时场景推荐
gpt-live-transcribe和独立转写会话。 - Transcript delta 属于临时结果，completed event 才是某个已提交音频项的最终文本。
- 不同 Turn 的完成事件可能乱序抵达，需要通过
item_id对齐，不能依赖到达顺序。 - 转写延迟、准确率、修订、成本和降级路径应与 Voice Agent 的响应指标分别管理。
- 一份明确合同应覆盖采集、分段、文本事件、最终化、溯源和下游消费。
共用音频，不等于共用责任
语音系统经常被画成一条直线：
麦克风 → Voice Agent → Transcript → Analytics
这条线隐藏了几条独立链路。音频采集和传输服务于 Turn 检测。转写生成临时文本与最终文本。对话模型可能在最终转写到达之前开始回答。分析、合规、检索和人工复核通常需要通话结束后的稳定文本。
这些消费者对正确性的要求不同。字幕界面追求尽早出现增量文本；合规档案追求稳定的最终记录；路由模型可能只关心少量关键词；语音对话模型可能直接处理音频，也就不应把异步 Transcript 描述成生成回答时的精确输入。
系统边界应沿数据依赖图划分。转写是一项具有独立合同的服务，不是 Voice Agent 对象上的一个字符串字段。
OpenAI 当前 API 明确了哪些边界
OpenAI 的转写总览把已完成录音和实时音频分为两条工作流。文件转写接收有边界的上传。实时转写通过 WebSocket 或 WebRTC 保持连接，用于麦克风、电话或其他连续到达的音频。
实时转写的推荐起点是 gpt-live-transcribe。官方模型页列出的能力包括音频和文本输入、文本输出、Realtime Transcription Endpoint、流式处理、可调节延迟、自由文本 Context、关键词提示和多语言提示。
转写会话使用 type: "transcription"。客户端通过 input_audio_buffer.append 发送音频。在关闭自动 Turn 检测时，通过 input_audio_buffer.commit 提交一个音频 Turn；也可以使用服务端 VAD 自动检测并提交边界。
两个事件定义了文本生命周期：
conversation.item.input_audio_transcription.delta携带新生成的临时文本。conversation.item.input_audio_transcription.completed携带一个已提交 Item 的最终文本。
官方文档明确提示，不同 Turn 的 completed event 不保证按顺序到达。应用必须用 item_id 匹配。
能力缺口也需要写进合同。gpt-live-transcribe 当前不返回词级时间戳、说话人标签和置信度分数。如果产品依赖这些数据，需要使用兼容的文件转写流程或增加应用层降级方案。
把 Transcript 定义成状态机
latest_transcript 这样的字符串无法安全表达生命周期。使用不可变身份和明确状态：
session_open
→ audio_appending
→ turn_committed
→ partial(delta_1 ... delta_n)
→ completed(final_text)
→ downstream_acknowledged
每个状态变化都应可观测。一份最小事件信封可以是：
{
"schema_version": "transcript-event.v1",
"session_id": "ts_019a",
"item_id": "item_003",
"sequence": 17,
"event_type": "transcript.completed",
"source_model": "gpt-live-transcribe",
"audio": {
"format": "audio/pcm",
"sample_rate_hz": 24000
},
"text": "请把订单 AC-42 改到周五。",
"is_final": true,
"received_at": "2026-08-02T02:31:08.441Z"
}
item_id 将临时文本和最终文本绑定到同一个音频项。sequence 负责本地传输或事件日志排序，不能替代服务端 Item 身份。schema_version 防止下游消费者在字段变化后静默出错。模型版本和音频格式使质量回归可以定位。
分开存储临时文本与最终文本
低延迟转写需要在即时性和上下文之间权衡。OpenAI 提供从 minimal 到 xhigh 的 delay 等级。更低的 delay 可能更早发出文本，更高的 delay 为模型提供更多音频上下文，并可能改善词错误率。每个等级没有固定毫秒承诺，需要用真实音频评测。
界面应明确把 delta 显示为临时状态。每个下游系统都要声明是否接受临时文本。搜索预览可以接受，合规归档应等待 completed event。系统不能用最后一个 partial string 静默覆盖最终记录。
每个 Item 至少保存：
- 当前临时文本；
- 最终文本和完成时间；
- 修订次数或 delta 历史保留策略；
- 模型与配置版本；
- 音频引用或保留状态；
- 下游确认与处理错误。
这也构成产品的修订政策。界面可以回改之前的文字；分析只消费 final item；告警系统可以自行决定延迟是否足以让它基于 partial 行动。
分开 Turn 边界与文本完成时间
Turn Detection 决定音频单元在哪里结束。转写模型决定何时有足够证据输出文字。对话模型决定何时开始回应。这三个时钟可能不同。
手动 Commit 由应用控制边界，VAD 由服务端检测并提交边界。无论使用哪种方式，都要记录边界来源和配置。否则，由静音阈值导致的延迟会被误诊成模型速度问题。
Turn 不能按事件到达顺序拼接。合同应把每个 delta 和 completed event 映射到 item_id，再把 Item 映射到本地 Turn。如果 Voice Agent 在最终转写到达之前已经生成回答，就应记录这个事实。最终 Transcript 是稍后出现的观测证据，不应被包装成先前回答的完整因果解释。
给转写单独设置 SLO
Voice Agent 仪表盘常常只显示端到端响应延迟。这个数字无法定位转写问题。应分段测量：
| 指标 | 暴露的问题 |
|---|---|
| 音频接收空洞与丢块 | 采集或传输失败 |
| Commit 到首个 Delta 的延迟 | 实时字幕响应速度 |
| Commit 到 Completed 的延迟 | 稳定文本可用时间 |
| 修订距离 | Partial 文本变化幅度 |
| 领域词错误率 | 产品名、ID、药品、缩写 |
| 空文本、截断和严重延迟率 | 平均 WER 隐藏的失败 |
| 完成事件乱序率 | 对齐与状态管理压力 |
| 每音频分钟和 Final Item 成本 | 容量经济性 |
| 下游确认延迟 | 分析或存储瓶颈 |
测试集要覆盖真实麦克风、电话编码、口音、背景噪声、语言切换、长会话、打断、数字、日期、货币、邮箱地址和领域词汇。干净的合成音频只能提供很弱的生产基线。
OpenAI 支持 prompt、keywords 和 languages 三种转写 Context。它们分别描述录音场景、提示可能出现的字面术语、列出预期语言。关键词属于提示，不是强制输出。每次 Eval 需要同时记录这些输入的版本，因为它们会改变系统行为。
按消费者选择架构
独立转写会话
适合实时字幕、会议记录、通话分析，以及只需要文字而不需要语音回复的工作流。它提供最清楚的责任边界。
Voice Agent 加独立 Transcript 链路
用一套音频采集同时服务语音交互和独立转写合同，后者负责可观测性、分析与归档。系统需要处理同步和重复音频传输，收益是对话行为和转写质量可以分别演进。
Voice Agent 自带异步输入转写
如果 Transcript 只用于显示或调试，这种方式可能已经足够。合同需要说明它可能晚于回答生成开始时间，无法作为模型决策的完整因果轨迹。
满足消费者需求的最小架构通常最好。关键在于语义明确，而不是服务数量更多。
上线验收清单
发布前至少验证：
- 每个音频 Item 有稳定身份，并且最终只接受一份 Final Record。
- Delta 与 Completed 在乱序交付和重连场景中仍能正确对齐。
- 重复 Commit 和事件重放具有幂等性。
- Partial 文本始终显示临时状态，无法静默进入最终档案。
- 时间戳、说话人和置信度等缺失能力有明确降级路径。
- 每种目标语言和真实音频条件都有质量阈值。
- 音频和文本分别执行保留、脱敏与访问控制。
- 转写指标能与回答生成、下游分析分开统计。
完成这些验收后，Transcript 才是一份可供其他系统信任的产品接口，而不是语音栈内部偶然生成的字符串。
FAQ
流式转写等于实时音频吗？
两者是不同决策。已完成文件在处理时也可以流式输出文本。音频连续到达或需要持久连接时，才需要 Realtime。
Voice Agent 应等待最终转写再回答吗？
取决于架构和用例。Speech-to-Speech Agent 可以在异步转写完成前回答。依赖 Transcript 做业务决策的系统，需要另行定义 Readiness Rule。
如何处理乱序的转写事件？
使用服务端 item_id 关联事件，为每个 Item 保存状态机，并让最终化操作具备幂等性。不要用到达顺序推断 Turn 身份。
GPT Live Transcribe 提供说话人和时间戳吗？
当前官方文档说明，它不提供词级时间戳、说话人标签和置信度分数。需要这些能力时，使用兼容的文件转写流程或应用层降级方案。
应该选择哪个延迟等级？
先定义产品对首个文本和最终文本的目标，再用代表性音频评测。delay 等级本身不承诺固定毫秒数。
参考资料
- OpenAI：GPT Live Transcribe 模型
- OpenAI：Realtime Transcription 指南
- OpenAI：Transcription 工作流总览
- OpenAI：Realtime 与音频总览
- 站内关联：OpenAI 低延迟语音 AI 架构
- 站内关联：语音 Agent 的闭环分析系统
下一步先写事件合同，再选择仪表盘。Item 身份、临时状态、最终化和缺失能力一旦显式化，延迟与质量就会从模糊体验问题变成可控的工程问题。