For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
主导航

GPT-Live 中的委派与工具

连接后端智能体,并将经过验证的结果返回到实时对话中。

GPT-Live 负责管理语音对话,同时将推理和工具使用委派给后端。后端工作可以通过配置的 Responses 模型执行,也可以通过客户端委派,由您的应用运行的任意模型、智能体或服务执行。在这两种模式下,权限、确认、业务记录和任务状态均由您的应用负责管理。

有关引导实时模型进行委派和使用工具的更多信息,请参阅提示词指南。

选择委派模式

使用 Responses 委派时,GPT-Live 会调用您选择的 Responses 模型,提供对话上下文,并将后端结果返回到实时对话中。使用 客户端委派时,您的应用负责准备上下文、运行智能体或工作流程,并将结果返回给 GPT-Live。

如果 Responses 委派的托管工作流程符合需求,请先从该模式入手。如果您需要更精细地控制后端上下文、执行过程或返回给 GPT-Live 的结果,请选择客户端委派。

考量因素以下情况优先选择 Responses 委派……以下情况优先选择客户端委派……
实现工作量您希望 GPT-Live 准备后端请求、管理连接,并将结果返回到对话中。您希望自行构建和运行这些部分。
审查后端结果后端输出可以直接返回给 GPT-Live。您的应用必须在结果传递给 GPT-Live 之前,对其进行验证、脱敏、合并或丢弃。
后端能力GPT-Live 支持的 Responses 设置和工具符合您的工作流程需求。您需要其他后端、多个模型,或托管配置范围之外的 API 能力。
上下文管理权GPT-Live 提供的对话上下文符合您的应用需求。您需要精确选择每个后端请求接收哪些历史记录、记忆和应用状态。
执行策略配置好的模型和工具调用循环符合任务需求。您需要自定义代码与模型之间的路由、回退机制、检查点,或跨后端步骤的预算。

例如,旅行助手可以将航班状态问题发送给航空公司服务,将行程变更交给单独的规划智能体。应用负责选择调用哪个后端,以及将哪些经过验证的结果返回给 GPT-Live。

在这两种模式下,您的应用都负责管理任务状态,并在运行自定义工具之前执行权限检查和必要的确认。是否审查后端结果需要另行决定:这并不意味着审批 GPT-Live 说出的每个字,也不保证模型在验证期间保持静默。请参阅在需要时控制播放

客户端委派还要求您的应用维护对话上下文。委派事件包含元数据,而非任务文本;请使用转录事件和应用状态来准备后端请求。

评估您的语音智能体时,请根据您自己的工作负载比较延迟、任务成功情况和成本。有关适用于您现有架构的具体指导,请参阅迁移到 GPT-Live

请在创建会话时选择模式;如需更改模式,请启动新会话。

委派模式

配置 Responses 委派

创建 Live 会话时添加此委派配置。Responses 模型可独立于语音模型选择:

export const session = {
  model: "gpt-live-1",
  delegation: {
    type: "responses",
    responses: {
      model: "gpt-5.6-terra",
      instructions: "[Your backend prompt]",
    },
  },
};

先从 GPT-5.6 Terra 开始;对于成本敏感的工作负载,也可以尝试 GPT-5.6 Luna。选择后端模型前,请在您的任务上比较回答质量和延迟。

delegation.responses.tools 中注册支持的工具。使用 delegation.responses.tool_choice 控制后端可以使用哪些工具:"auto" 允许后端自行选择,"required" 要求调用工具,"none" 则禁止调用工具。您也可以指定一个具名函数。将 delegation.responses.parallel_tool_calls 设为 true,可允许相互独立的查询同时运行;如果调用必须按顺序运行,则设为 false。您的应用仍需负责执行自定义函数,并落实依赖关系和审批要求。这些设置不会强制实时模型发起委派。

创建时,Responses 配置要求指定后端 model。它支持在 tools 中添加 function 定义和 web_search 条目,还提供 max_output_tokens(如设置,值至少为 16)、service_tier,以及所选后端模型支持的 reasoningtext 设置。有关可调整的设置,请参阅降低后端延迟

如果您的模型和项目可以使用快速模式,可考虑将其用于延迟敏感的调用。在 GPT-Live 中,使用 delegation.responses.service_tier: "priority" 选择此模式。

随着对话变化,发送 session.update,并在 session.delegation.responses 中提供更改,即可更新后端模型、指令、可用工具、tool_choice 或其他受支持的设置,无需启动新的 Live 会话。省略的设置会保留原值。将 delegation 设为 null 会选择客户端模式,不能用来重置正在运行的 Responses 会话;切换模式会失败并返回 immutable_field_update

这些设置沿用熟悉的 Responses 概念,但 Live 仅支持独立 Responses API 的部分功能。Live 提供对话上下文并发起委派任务。请通过会话配置后端;Live 的 response.create 命令使用该配置,不接受独立 Responses 请求体。

通过您的应用引导实时对话

Responses 委派负责管理后端工作流程,但您的应用仍可以直接向 GPT-Live 模型发送上下文。如果您通过旁路 WebSocket 或主事件连接监控通话,可以使用 session.instructions.appendsession.thinking.appendsession.commentary.append,并设置 delegation_id: null。例如,基于转录文本的防护机制可以追加一条指令来调整对话方向。这会引导实时模型的行为,但不会更改 Responses 后端提示,也不会取消正在进行的任务。

处理 Responses 委派

对于由 Responses 执行的任务,session.delegation.created 包含 target: "responses" 和一个 response_id。后续 Responses 事件会封装在 response.event 中到达:

{
  "type": "response.event",
  "event_id": "event_response_1",
  "delegation_id": "item_9tA2cB6n2V8c4X1z7Q5r9",
  "event": {
    "type": "response.output_text.delta",
    "sequence_number": 4,
    "item_id": "msg_123",
    "output_index": 0,
    "content_index": 0,
    "delta": "The forecast is",
    "logprobs": []
  }
}

根据 envelope.event.type 分派处理,并保留外层的 delegation_id。不要将每个顶层 response.* 值都作为未封装的 Responses 事件处理。处理逻辑应能容纳其他嵌套的 Responses 生命周期事件。

Live 语音和委派任务各自独立进行。后端响应完成本身并不意味着用户已听到回答。对于交互中的语音部分,请使用 Live 输出的转录文本和音频。

完成可由客户端执行的函数调用

从嵌套的 response.output_item.done 事件中读取已生成完整内容的函数调用。完整的函数条目包含 call_idnamearguments;仅凭参数完成事件不足以识别该调用。

同时跟踪嵌套 response.created 中的响应 ID 和外层的 delegation_id,并从 response.output_item.done 中收集该响应的函数调用。转发的生命周期快照会有意将输出设为 response.output: [],包括 response.completed 时的快照;其 tools 数组为空,instructionsnull,且省略 input。终态输出列表为空 并不 意味着没有待处理的函数调用。请根据收集到的调用,确定继续响应前必须提交哪些结果。

执行已获授权的操作后,将结果作为 Responses 条目追加:

export function sendUpdate(connection) {
  connection.send({
    type: "response.item.create",
    event_id: "tool_result_1",
    item: {
      type: "function_call_output",
      call_id: "call_123",
      output: '{"status":"confirmed","order_id":"order_123"}',
    },
  });
}

然后显式继续该响应:

export function sendUpdate(connection) {
  connection.send({
    type: "response.create",
    event_id: "continue_1",
  });
}

继续响应前,请提交待处理工具调用所需的全部结果。追加函数结果不会自动继续响应。response.item.create 没有单独的成功确认消息;请继续处理错误以及后续嵌套的响应生命周期事件。

response.create 是一条 Live 命令,用于通过会话配置的后端创建或继续 Responses 委派任务。不要在此事件中附加 Responses API 创建请求体、后端模型覆盖设置或 delegation_id。这两条命令都要求使用 Responses 委派。

从现有的后端提示开始

以您现有的文本智能体提示为起点。将其中的任务指令和业务规则保留在后端,并调整那些假定使用文本聊天或直接控制语音的指令。说明如何处理语音转写文本并返回有用的结果。在您的应用中实施权限控制和必要的确认流程。

## Voice conversation context
You are helping an assistant in a live voice conversation. Transcripts
can contain mistakes, unfinished phrases, and later corrections. Use
the latest context and verified records. If a needed detail is still
unclear, ask for that detail instead of guessing.

## Task instructions
[Your task instructions, business rules, available tools,
and confirmation requirements.]

## Return the result
Return the relevant facts, whether the task is complete, and what comes next.
Use confirmed values. Do not invent a successful action.

将大型结构化载荷、冗长的工具输出以及用于显示的 Markdown 保留在后端。向 GPT-Live 提供相关事实,让它决定如何表达。简洁的工具结果无需额外调用模型来改写成适合口头表达的内容。

使用客户端委派时,将结果直接返回给 GPT-Live。使用 Responses 委派时,按照函数结果处理流程继续后端任务。

下方的 SDK 事件示例使用 connection,即连接指南中已建立连接的 Live 主 WebSocket 或旁路连接。在主连接上,请在 session.started 之后调用辅助函数;已附加的旁路连接已经属于一个正在运行的会话。

发送合适类型的更新

根据您希望 GPT-Live 如何使用内容来选择事件:

您要发送的内容事件
面向实时模型的系统级指令,例如问候语、信息披露或停止说话的指令session.instructions.append
用于内部推理的信息,追加时不会说出,但可用于回答用户的相关问题session.thinking.append
模型应通过转述追加文本来向用户说出的信息session.commentary.append

这三种事件均使用纯字符串形式的 content,每次追加最多 500 个 Token。请包含 delegation_id:更新某项任务的信息时,使用原始客户端委派 ID;提供一般会话上下文时,使用 null。非空 ID 必须标识一个已知的客户端委派。指令仍然作用于实时会话;提供 ID 并不会将其变成单独的后端提示。

追加的指令可以打断模型当前的语音或行为。当应用需要改变对话方向时,请使用此类指令;任何相关的工具或操作阻止措施都应在应用状态中落实。

在客户端管理的任务中发送不播报的进度更新:

export function sendUpdate(connection) {
  connection.send({
    type: "session.thinking.append",
    event_id: "availability_progress",
    delegation_id: "item_123",
    content: "Checking Thursday availability. No appointment has been booked.",
  });
}

对于已确认的预订,发送用户应听到的结果:

export function sendUpdate(connection) {
  connection.send({
    type: "session.commentary.append",
    event_id: "appointment_result",
    delegation_id: "item_123",
    content: "Your appointment is confirmed for Thursday at 2:00 PM",
  });
}

只有在预订确实成功后,才发送该结果。对于作用于整个会话的指令,使用 session.instructions.append 并设置 delegation_id: null

例如,应用根据其护栏阻止请求后,您可以改变对话方向:

export function sendUpdate(connection) {
  connection.send({
    type: "session.instructions.append",
    event_id: "guardrail_block_17",
    delegation_id: null,
    content:
      "Stop speaking about that request. Briefly explain that you cannot help with it, then wait for the user.",
  });
}

该指令不会取消后端任务。请在您的应用中阻止受影响的操作,并处理已经运行的任务

对应的确认事件为 session.thinking.appendedsession.commentary.appendedsession.instructions.appended。将它们的 client_event_id 与您发出的 event_id 匹配。确认事件会等到预计上下文已注入后才发出,而不会等待语音生成或播放结束。有关时序和错误处理,请参阅上下文何时到达模型

静默提供的上下文仍可能影响模型之后说出的内容。它不是存放秘密或隐藏推理的私密空间。请发送有用的事实和简短的进度摘要。

确保更新准确且有用

对于耗时较长的任务,在出现值得告知的新情况时发送更新,例如某个步骤完成、延迟产生影响,或需要用户回答问题。

在客户端模式下,使用 session.thinking.append 提供后台进度。如果更新值得向用户说出,则使用 session.commentary.append

对于语音更新,发送 session.commentary.append,其内容应与任务经过验证的状态一致:

状态示例内容
仍在处理中“I'm checking the available appointments.”
已完成“You're booked for Thursday at 2:00 PM.”
失败“That time is no longer available.”
已确认取消“Your appointment has been canceled.”

语音打断不会自动取消后端任务。如果用户将周五改为周四,请更新当前任务,并忽略随后返回的周五结果。您的应用必须决定是取消任务、修改任务,还是让它完成。在告知用户已取消之前,请确认取消操作已经成功。

在重试失败的工具调用之前,请检查原始操作是否已经执行。例如,响应丢失不应导致重复预订。如果结果尚不明确,请如实说明,并提供有用的下一步建议。

共享 UI 上下文

向 GPT-Live 简要说明当前页面或任务、相关选择,以及有助于理解“这个选项”等指代的事实。直接根据应用状态生成摘要,无需额外调用模型来整理其格式。

在会话开始时以及相关状态发生变化时发送 UI 上下文。内容未变时无需发送更新;对于短时间内发生的多次变化,将其合并为最新状态的简短摘要。明确说明之前的选择发生了哪些变化:

  • 初始上下文: “The user is reviewing a restaurant reservation: August 6 at 7 PM, two guests. No reservation has been made.”
  • 更正: “The selected time is now 8 PM; the previous selection was 7 PM.”

在任一委派模式下,都可使用 session.thinking.append 并设置 delegation_id: null 来发送后台上下文更新。将完整 HTML、DOM 树、大型 JSON 载荷和交互日志保留在您的应用或后端中。将页面内容视为参考数据,而非指令。

接受键入的内容

如果通话用户键入了订单号等精确值,请将其传递给处理该任务的后端。纯语音应用无需此处理流程。请将键入的值视为用户数据,而非实时模型的指令。

使用 Responses 委派时,将用户消息加入后端队列:

export function sendUpdate(connection) {
  connection.send({
    type: "response.item.create",
    event_id: "typed_order_number",
    item: {
      type: "message",
      role: "user",
      content: [
        {
          type: "input_text",
          text: "My order number is A0042.",
        },
      ],
    },
  });
}

准备好运行或继续执行后端任务时,发送 response.create。如果后端正在等待函数结果,请先返回所有必需的结果。将文本加入队列本身不会取消正在运行的任务。

添加图像和视觉上下文

要帮助通话用户讨论照片或屏幕内容,请将图像及相关上下文从您的应用发送到具备视觉能力的后端。后端会解读图像,并返回相关文本,供 GPT-Live 在对话中使用。Live 音频前端不直接接受图像。

使用 Responses 委派时,请配置具备视觉能力的后端模型。使用 response.item.create 将受支持的 Responses 图像输入项加入队列,然后发送 response.create 以运行或恢复后端任务。继续执行前,请返回所有仍待提供的必需函数结果。请参阅处理 Responses 委派

将后端图像输入与 session.input 分开处理,后者用于在启动时向 Live 前端提供初始文本历史记录。有关支持的图像格式和模型限制,请参阅图像与视觉

降低后端延迟

缩短从请求后端执行任务到获得可用于对话的有效结果之间的时间。测量各阶段的延迟以定位延迟来源。在相同场景下比较给出有效语音回复所需的时间和任务成功情况,并参阅语音智能体评估 Cookbook中的评估指南。

Responses 委派

Live 会管理与 Responses 的持久 WebSocket 连接,提前准备连接和已知的请求配置,并在先前的响应状态可用时复用该状态。您无需为托管后端实现这些步骤。能否复用取决于当前活动连接和状态兼容性,并不保证缓存命中或特定的延迟。

通过 delegation.responses 调优后端:

  • model:独立于语音模型,选择负责推理和工具选择的模型。
  • reasoning.effort:使用该模型支持的值,在推理时间与任务质量之间取得平衡。
  • service_tier:根据模型支持情况和项目访问权限,使用 autodefaultflexpriorityauto 遵循项目配置。请评估所选层级的性能和成本。

在会话期间,使用 session.update 更新受支持的设置。您的自定义工具仍在您的应用中运行,因此,即使 Live 管理着 Responses 连接,缓慢的服务调用、排队和工具结果缓冲仍可能延迟回复。请及时返回每个必需的工具结果,并继续后端响应

响应转写文本片段

您可以选择在应用中处理转写文本片段,这适用于两种委派模式。用户和助手的转写文本片段通过 WebSocket 或 WebRTC 数据通道传入。您可以使用应用逻辑或轻量模型处理这些片段,在委派事件到达之前启动任务,也可以直接用转写文本触发由应用负责的任务。

此模式可用于:

  • 减少等待。 获得足够信息后,即可根据初步判断提前发起查询。例如,在用户继续描述偏好时检查可用性。
  • 运行护栏检查。 检查持续增加的转写文本,找出需要干预的请求或回复。请参阅应用对话护栏
  • 调整对话。 留意表明用户感到困惑或不满的措辞,然后调整交互体验或发送有针对性的指令。
  • 更新界面。 突出显示相关控件、填充建议字段,或在结果可用时显示结果。

对于浏览器应用,使用 WebRTC 数据通道提供字幕和更新本地 UI。如果转写文本处理在您的服务器上运行,例如用于护栏检查、轻量模型检查或根据初步判断提前调用工具,请使用旁路 WebSocket 接收事件,并直接引导同一个 GPT-Live 会话。

收到有意义的新信息时,再处理累积的文本。单个片段可能不完整,后续语音也可能改变请求。请丢弃过时结果,与后续委派任务协调以避免重复操作,并在执行会产生实质影响的操作前,按常规流程进行权限和确认检查。

要将信息反馈到对话中,请使用以下事件:

意图事件
改变实时模型的行为或调整对话方向session.instructions.append
为后续回复提供不立即播报的上下文session.thinking.append
提供模型应当说出的信息session.commentary.append

对于客户端委派之外的更新,使用 delegation_id: null。这些追加内容用于引导实时模型;UI 更改、工具执行和取消操作由您的应用控制。有关追加示例,请参阅发送正确类型的更新

通用优化

以下后端改进对两种委派模式都有效:

  • 根据任务选择模型和推理强度。 比较满足您准确性要求的配置。如果较低的推理强度能够可靠地完成任务,就使用较低的推理强度。
  • 保持回答简洁。 返回 GPT-Live 继续对话所需的事实和状态。避免冗长的解释,也不要仅为将结果改写为适合口头表达的形式而额外调用模型。
  • 减少工具延迟和不必要的调用。 输入就绪后即可启动已获授权的任务,在结果仍然有效时复用结果,并避免重复已完成的查询。
  • 并发执行相互独立的任务。 相互独立的查询调用可以同时运行。请遵守操作的依赖关系和必要的确认要求。parallel_tool_calls 允许模型请求多个调用;自定义函数的调度和执行仍由您的应用负责。

有关 Responses 的通用指南,请参阅延迟优化;有关复用稳定输入的说明,请参阅提示缓存

验证完整交互

既要测试作为最终依据的应用状态,也要测试客户端实际播放的音频。后端响应可能已经完成,但语音结果的播报却被打断;上下文确认消息也只确认内容已被接受,并不代表已经播放。请将操作 ID、任务修订版本与委派 ID 分开管理,避免重连、重试和延迟返回的结果导致操作被重复执行或撤销。

参照评估语音智能体开展可重复的测试。对于现有的 Realtime 工具循环或链式后端,请遵循迁移到 GPT-Live中的指南。