OpenAI 语音智能体

语音智能体让用户通过与应用讲话来提问并完成任务。关键设计是语音如何连接推理与工具：独立后端配合连续对话、单个语音模型，或由你逐阶段控制的流水线。

选择合适架构

构建全双工语音智能体

GPT-Live 能同时聆听与说话，这称为全双工。Live 模型处理语音交互，将推理与工具使用委派给独立后端，用户可在后端工作期间继续说话。

可以保留现有文本工作流的业务逻辑和工具，把 GPT-Live 作为语音界面。委派模式决定谁运行后端、提供后端对话上下文：

• 客户端委派：连接自行选择后端模型与提供商的智能体或工作流，由应用运行工作并返回结果。
• Responses 委派：选择 OpenAI 托管 Responses 模型推理和使用工具。GPT-Live 提供上下文并管理模型调用，应用仍执行自定义函数。

两种模式都由应用控制权限与业务记录。讲话行为放在 Live 提示词，业务规则放在后端提示词。

从 GPT-Live 入门开始，后端设置见委派与工具，说话行为见语音模型提示词。

构建语音到语音智能体

Realtime API 的 RealtimeAgent 和 RealtimeSession 提供以浏览器为起点的方案。会话处理音频轮次、工具、打断与任务移交。完整入门示例现位于 Realtime API 快速开始。

构建串联语音工作流

需要检查或转换语音识别、智能体与语音生成之间的文字时，采用串联路径，由应用管理三个阶段：

1. 语音转文字。
2. 智能体工作流。
3. 文字转语音。

运行串联语音流水线：

来源示例 1（python）：

程序文字译释48：你是乐于助人的语音助手。

程序文字译释138：获取给定城市的天气。

程序文字译释139：{city}天气晴朗。

程序文字译释140：已收到音频字节。

## [中文] 保留原例中客户端、输入和返回值的处理顺序；本段需结合所在小节的连接前提使用，未通过真实API调用验证。
import asyncio
import numpy as np

from agents import Agent, function_tool
from agents.voice import AudioInput, SingleAgentVoiceWorkflow, VoicePipeline


@function_tool
def get_weather(city: str) -> str:
    """Get the weather for a given city."""
    return f"The weather in {city} is sunny."


agent = Agent(
    name="Assistant",
    instructions="You are a helpful voice assistant.",
    model="gpt-6-astra",
    tools=[get_weather],
)


async def main() -> None:
    pipeline = VoicePipeline(workflow=SingleAgentVoiceWorkflow(agent))
    audio_input = AudioInput(buffer=np.zeros(24000 * 3, dtype=np.int16))
    result = await pipeline.run(audio_input)
    async for event in result.stream():
        if event.type == "voice_stream_event_audio":
            print("Received audio bytes", event.data.nbytes)


if __name__ == "__main__":
    asyncio.run(main())

各阶段都需要可见或可替换时采用此方案。例如，先保存转录，在文本智能体回答前做政策检查，调用内部系统，直到工作流形成获准答案后才生成语音。

评估语音智能体

同时测试对话与任务结果。例如，预约助手既要聆听确认，也要检查正确预约已保存。

1. 选择有代表性的场景，明确预期结果、工具调用和权限。
2. 保存验证各结果所需的音频、事件、工具结果和应用状态。区分评估运行本身失败，与评估有效运行但智能体未完成任务。
3. 重复场景，比较任务完成、可听回应延迟、打断与不必要静音。比较改动时保持来电者、模型配置、工具与传输一致。

GPT-Live 应独立测量：

• 任务与工具结果：检查意图保留、被委派工作、工具参数、权限和最终应用状态，确认口头确认与已完成动作一致。
• 对话时序：测量可听回应时序、不必要静音、重叠和被打断后的让话，包括后端工作期间的纠正。
• 语音与语言：测试口音、噪声、语言切换、姓名和数字的输入识别；输出可懂度与语言选择单独评估。
• 会话可靠性：连接失败、音频丢失、超时、未完整结束的会话，与任务得分分开追踪。

按 Crawl、Walk、Run 三阶段增加复杂性：

1. Crawl（起步）：用合成语音做可控单轮请求，固定生成音频、应用上下文和预期结果，便于重复比较。
2. Walk（进阶）：回放代表性真人单轮录音，测试声音、麦克风、停顿与声学环境的影响。
3. Run（完整对话）：使用独立模拟来电者做连续多轮对话，测试对话与后端工作重叠时的澄清、需求变更、打断与恢复。

在自动评分之外，加入人工聆听，评估发音、自然度及对话节奏是否适宜。

GPT-Live 评估框架见语音智能体评估 Cookbook；Realtime 框架和完整示例见 OpenAI Cookbook 的 Realtime 评估指南。

测量延迟

测量来电者等待有用口头答案的时间。另行追踪后端耗时定位延迟，并在相似通话中比较中位数和第95百分位。

比较前端模型时，固定来电者、录音、后端模型、提示词、传输、音频节奏和评分器。

GPT-Live 记录应用能观察的阶段：收到委派、后端请求开始、首个有用结果、工具开始和结束、结果提交、音频到达、客户端播放。客户端委派可直接观察后端请求；Responses 委派暴露嵌套响应事件及应用运行的自定义工具。

用这些时间定位连接设置、模型工作、工具、缓冲或播放的延迟。“我正在查询”等确认语，应与用户真正需要的答案分别测量。

一次更改一个因素，重复相同场景。检查更快回应是否影响任务成功、工具正确性或打断。见降低后端延迟。

语音智能体仍使用相同核心构件

语音界面改变传输与音频循环，但核心工作流决策不变：

• 需要外部能力时，使用工具。
• 需要流式处理、续接或持久状态时，参阅运行智能体。
• 工作流在专家间分支时，参阅编排与任务移交。
• 需要安全检查或批准时，参阅防护规则与人工审核。
• 需要 MCP 能力或检查语音工作流行为时，参阅集成与可观测性。

实际做法是先选音频架构，再像设计文本智能体一样设计其余工作流。

后续步骤

• 音频与语音概览：选择合适的实时或音频指南。
• 管理对话：使用 Realtime 会话生命周期与事件模型。
• WebRTC 连接：将浏览器与移动端音频连接到 Realtime 会话。
• Realtime 提示词指南：调整推理、开场说明、工具、实体采集与语音行为。