English
主导航

推荐

入门

核心概念

Apps SDK

工具

运行与扩展

评估

实时与音频

模型优化

专业模型

正式上线

旧版 API

资源

API 仪表板

使用实时模型

提示、推理与调优实时语音模型。

gpt-realtime-2 是我们专为实现低延迟端到端语音应用而打造的最先进推理语音模型。与早期的实时模型相比，它能够在开口前进行思考，更可靠地遵循指令，支持更大的上下文窗口，并以更高的精度调用工具。

为了充分利用这些优势，您在设计提示词时需要更具意图性。明确定义助手的职责、决策点、工具调用行为和防护边界：它该做什么、何时做，以及应避免什么。

从简单开始。不要一开始就过度提示。从最精简的提示词起步，运行评估，然后仅针对测试中未达预期的行为添加指令。

选择模型

模型适用场景提示词侧重点
gpt-realtime-2

您需要最强大的实时推理、工具调用及指令遵循能力。

调优推理力度、前言、工具策略、精确实体捕获以及长会话状态。

gpt-realtime-1.5您需要一个快速、可靠的非推理端到端语音模型。

遵循核心实时提示词结构，并针对延迟敏感行为进行测试。

Realtime 2.0 提示词指南

使用 gpt-realtime-2 当语音助手需要更强的推理能力、工具选择、精确实体处理或长会话状态时。请从 reasoning.effort: “low”, 测试默认前导行为，并在执行写入操作前设定明确的确认边界。

Realtime 2 的变更

将 Realtime 2 作为推理语音助手进行提示，而不是基础的语音机器人。

变更对提示词的影响
推理允许模型在说话或调用工具前，针对复杂任务进行内部推理。利用前言来避免尴尬的沉默或不必要的填充词。
提示词的精确度更为重要将“提供帮助”等宽泛的指导替换为明确的触发条件、动作和异常规则：何时行动、做什么以及何时不做。
指令冲突的代价更高移除重叠的 always, never, only，且 must 规则，除非它们确实是必需的。当规则存在冲突时，定义优先级。
工具行为更具可控性明确指定助手应何时立即行动、询问缺失信息、确认高精度细节、失败后重试或向上升级。
前言是首要行为模型可能会在较长的推理或工具调用流程前，播报简短的更新。控制前言应在何时出现、应有多简短，以及何时应跳过。
扩展的上下文窗口gpt-realtime-2 将实时上下文窗口从 32k 扩展到了 128k 个 token，使其更适合长会话和更庞大的系统提示词。

前言并非隐藏的思维链。它们是简短的语音更新，例如“我现在就去查询那个订单”。不要要求模型透露其内部推理过程。

推荐的提示词结构

使用简短、带标签的段落。模型应当能够快速找到相关指令。

# Role and Objective

# Personality and Tone

# Language

# Reasoning

# Message Channels

# Preambles

# Verbosity

# Tools

# Unclear Audio

# Entity Capture

# Long Context Behavior

# Escalation

并非每个用例都需要所有段落。请添加与你的产品相关的段落。

设置推理力度

gpt-realtime-2 可以在延迟与深度推理之间进行权衡。使用足以满足工作流所需智能水平的最低推理等级。

起始项 low 适用于大多数生产环境的语音代理。请根据任务复杂度、对延迟的容忍度以及失败成本进行上调或下调。

力度适用场景示例
minimal最看重最低延迟，且任务简单。智能家居指令、计时器、简单的日程查询。
low需要快速响应以及基本的推理能力。客户支持、订单查询、简单的政策问题。
medium助手必须通过多步骤任务进行推理。技术支持、故障诊断、复杂路由。
high更深度的推理能显著提高成功率。高精度工作流、升级决策、具有约束条件的任务。
xhigh最大程度的推理值得付出额外的延迟和成本。复杂规划、关键分诊、高风险工具编排。

除了 API 设置外，还需引导模型了解何时推理以及推理的程度。

## Reasoning

- For direct answers, simple lookups, and short confirmations, respond quickly and do not reason.
- For multi-step tasks, tool decisions, troubleshooting, or escalation, reason before acting.
- Do not perform extended reasoning when the user's audio is unclear; ask for clarification instead.

有目的地使用前导语

前导语是简短的口头更新，让语音代理在推理、查找信息或调用工具时仍保持响应感。运用得当，能让用户确信助手正在处理；运用不当，则会成为废话并增加体感延迟。

gpt-realtime-2 默认生成前导语。请先测试默认行为。如果它与你的产品体验不符，请明确对其进行调整。

Preamble generation and playback timeline

## Preambles

Use short preambles only when they help the user understand that work is happening.

### When to use a preamble

Use a preamble when:

- you are about to call a tool that may take noticeable time;
- you need to reason through a multi-step request;
- you are checking records, availability, account state, or policy details;
- you are preparing an escalation or handoff;
- silence would make the assistant feel unresponsive.

When a preamble is needed, output it immediately before substantive reasoning or tool use.

### When to not use a preamble

Do not use a preamble when:

- the answer is direct and can be given immediately;
- the user is only confirming, correcting, or declining something;
- the audio is unclear and you need clarification;
- the latest audio is silence, background noise, hold music, TV audio, or side conversation;
- the tool call is lightweight and the user would not benefit from an update.

### Preamble style

When using a preamble:

- keep it natural, calm, and concise;
- vary the wording across turns;
- describe the action, not the internal reasoning;
- avoid filler.

Avoid phrases like:

- "Let me think..."
- "Hmm..."
- "One moment while I process that..."
- "I am now going to access the tool..."

### Preamble length

Use one short sentence.

Do not exceed two short sentences unless the user needs an explanation before a high-impact action.

### Prefer

- "I'll check that order now."
- "I'll look up your appointment details."
- "I'll verify that before we make any changes."
- "I'll check the policy and then give you the next step."
- "I'll pull that up so we can make sure it's the right account."

### Avoid

- "Let me think about that for a second."
- "Please wait while I process your request."
- "I'm going to use my tools now."
- "Interesting question. I will reason through this carefully."

控制回复长度

gpt-realtime-2 当提示词针对每种任务类型明确规定了所需细节的详略程度时，模型能最好地遵循长度指导。与其告诉模型“简洁”，不如在上下文中定义简洁的具体含义：直接回答、工具结果、故障排查、对比说明和问题升级可能各自需要不同的回复长度。

## Verbosity

- Direct answers: Use 1-2 short sentences.
- Clarifying questions: Ask one question at a time.
- Tool results: Summarize the result first, then give only the next useful action.
- Product or option comparisons: Include key differences, tradeoffs, and who each option fits.
- Troubleshooting: Give one step at a time unless the user asks for the full procedure.
- Escalations: Briefly explain why escalation is needed and what will happen next.

Example:

用户：我应该选择哪个计划？

助手：如果你想追求最低成本，请选择基础版。如果你需要团队权限和共享账单，请选择专业版。如果合规审查或管理控制对你很重要，请选择企业版。

设计工具行为

gpt-realtime-2 在工具调用方面表现更出色，但工具行为仍取决于提示词和工具规范的设计。如果提示词没有界定何时行动、提问、确认或恢复，助手可能会过早调用工具、提出不必要的问题或重复失败的调用。

设置工具调用积极性

对于只读、低风险的操作，高积极性效果良好。当工具用于修改数据、触发外部影响或依赖精确标识符时，低积极性更合适。

工具类型默认行为
只读、低风险的查询在意图和必填字段明确时调用。
使用精确标识符的只读操作在查询前确认标识符。
用户可见的沟通在发送前起草或总结。
账户变更在调用前确认。
购买、取消、支付在调用前确认金额、目标和后果。
不可逆或高影响的操作明确确认并在适当时提供升级处理。

当您混合使用读写操作时，请使用此平衡的默认设置。根据您的用例进行调整。

## Tools

Use only the tools explicitly provided in the current tool list. Do not invent, assume, simulate, or rename tools.

For read-only tools:

- Call the tool when the user's intent is clear and all required fields are available.
- Do not ask for confirmation unless the lookup depends on a high-precision identifier or there is meaningful risk of using the wrong record.
- Ask a clarification question only if a required field is missing, ambiguous, or conflicting.

For write tools or external actions:

- Summarize the intended action before calling the tool.
- Include the key consequence, such as what will be changed, sent, canceled, ordered, or charged.
- Ask for confirmation.
- Do not call the tool until the user clearly confirms.

For exact identifiers:

- Treat order IDs, tracking numbers, account numbers, confirmation codes, phone numbers, and email addresses as high precision.
- Normalize only when the field type is clear.
- Confirm the final value before account-specific lookups, validation, or write actions.

After tool calls:

- Only say an action was completed after the tool call succeeds.
- If the tool fails, explain the failure briefly, avoid raw errors, and give the user a clear next step.

高风险示例：

用户：用我的卡支付剩余余额。

Bad:

助手：我已经刷了您的卡。

Good:

助手：确认一下，您希望我从档案中的信用卡扣除 248.16 美元的剩余余额。是否继续？

从工具故障中恢复

工具故障是对话的一部分。良好的恢复机制应解释发生了什么，并为用户提供明确的后续步骤。

不要同等对待所有故障。恢复行为应取决于工具类型、故障模式和用户影响。某些故障应在重试时静默处理。其他故障则需要要求用户澄清、更正标识符、确认新操作或选择替代路径。

## Tool Failures

If a tool call fails:

1. Briefly explain what failed in user-friendly language.
2. Do not blame the user or expose raw tool errors.
3. If the failure may be due to an exact identifier, read back the value used and ask the user to correct it.
4. If the failure may be temporary, offer to retry once.
5. If the same failure happens repeatedly, offer an alternate path or escalation.

Do not repeatedly call the same tool with the same arguments after failure.

Do not ask for a different identifier until you have first checked whether the captured value was correct.

Bad:

助手：出了点问题。

Good:

助手：我找不到与 O-R-D-3-1-2-5-B-2-3 匹配的记录。其中有哪部分我听错了吗？

保持工具可用性同步

实时模型乐于助人。如果提示词中提到了实际不可用的工具，或者工具列表与提示词不匹配，模型可能会捏造工具名称或假装已完成操作。

例如，如果提示词引用了 lookup_order, 但提供的工具名为 search_orders, 模型可能会调用错误的名称或模拟该操作。

## Tool Availability

Use only the tools that are explicitly provided in the current tool list.

Do not invent, assume, or simulate tools. If a tool is mentioned in the instructions but is not present in the tool list, treat it as unavailable.

If the user requests an action that requires an unavailable tool:

1. Do not pretend to complete the action.
2. Briefly explain that the tool is not available.
3. Offer the closest supported next step.

Only say an action was completed after the relevant tool call succeeds.

使用附录中的提示词审计元提示词来检查生产提示词是否存在矛盾、缺失的工具和脆弱的指令。

处理静音和背景音频

语音助手默认会进行响应。在生产环境中，它们经常会听到不应得到口头回应的音频，例如静音、背景噪音、等待音乐、电视音频或旁人的对话。

当助手应保持安静并继续聆听时，请使用无操作等待工具。该工具为模型提供了一种有效的非语音操作，而不是让它说出“我还在”或“我没听清”之类的话。

工具设计：

1
2
3
4
5
6
7
8
9
{
  "name": "wait_for_user",
  "description": "Call this when the latest audio does not need a spoken response, such as silence, background noise, hold music, TV audio, side conversation, or speech not addressed to the assistant. This tool helps end the turn without a spoken reply.",
  "parameters": {
    "type": "object",
    "properties": {},
    "required": []
  }
}

将其与提示词指令配对使用：

## Handling Silence and Background Noise

If the latest audio is silence, background noise, hold music, TV audio, side conversation, or speech not addressed to you, call `wait_for_user`.

Do not respond conversationally after calling this tool.

Do not say "I'm here," "I didn't catch that," "Take your time," or "Let me know when you're ready."

Resume normal responses only when the user clearly addresses you or asks for help.

将此用于非面向助手的音频，而非用于不明确的用户请求。如果用户明确是在对助手说话，但内容难以理解，请要求其澄清。

有目的地使用消息通道

gpt-realtime-2 可以在评论通道中产生用户可见的中间消息，并在最终通道中产生面向用户的最终响应。当行为取决于出现的位置时，请使用特定于通道的指令。

通道用户可见？用途
commentary是前言和工具调用。
final是面向用户的最终消息。

例如，工具调用在评论通道中进行。如果您希望助手在工具使用之前、期间或之后说些什么，请相对于评论通道指定该行为。

Before calling tools in the commentary channel, briefly tell the user what you are doing.

gpt-realtime-2 可以在单轮对话中发出多个响应阶段。在 API 输出中，这种区别由 response.done 事件表示，该事件包含一个 phase 值，用于指示内容是评论还是最终答案。

您可以使用此字段在应用程序中对每个阶段进行不同的处理。例如，评论可以作为简短的中间更新播放或显示，而 final_answer 则可保留用于助手的完整响应。

response.output[0].phase: "commentary"
response.output[1].phase: "final_answer"

处理不清晰的音频

模型应仅在其能有把握理解的音频上采取行动。如果音频不清晰，模型应提出简短的澄清问题，而不是猜测。

不要让模型推断缺失的单词、调用工具、捕获实体、生成前言，或花费隐藏的推理时间试图重建用户可能说过的话。

## Unclear Audio

- Only respond to clear audio or text.
- If the user's audio is not clear, ask for clarification using a short English phrase such as "Sorry, could you repeat that clearly?"
- Don't repeat the same unclear-audio clarification twice.
- Treat audio as unclear if it is ambiguous, noisy, silent, unintelligible, partially cut off, or if you are unsure of the exact words the user said.
- Do not guess what the user meant from unclear audio.
- Do not reason when the audio is unclear.
- Do not provide a preamble or call tools in the commentary channel when the audio is unclear.

Example:

用户音频：“查询订单三一-” [中断]

Bad:

助手：我现在查询订单 31。

Good:

助手：我只听到了订单号的一部分。您能逐个数字重复一遍吗？

捕获精确实体

许多实时工作流依赖于精确值：订单 ID、追踪号码、电子邮件地址、确认码、账号、理赔号、工单 ID、支持参考号和电话号码。

语音使这变得困难。用户说话很快，以不同方式组合数字，拼出部分值，使用填充词，在说话中途自我纠正，或者发音相似的字符。一个错误的数字就可能导致查询失败或检索到错误的账户。

保守地捕获实体。一次收集一个值，仅对明确的部分进行规范化处理，在调用工具前确认高精度值，并使每一次更正都能恢复。

每次收集一个实体

当工作流需要多个值时，请一次收集一个。这可以防止字段混淆，特别是在语音对话中。

## Entity Collection Order

Collect required values one at a time.

- Ask for only the next missing value.
- Do not ask for multiple values in the same turn.
- Before asking, check whether the value was already provided earlier in the conversation or the session.
- If a possible value already exists, confirm it with the user before using it.

Example:

"I see tracking number ABC-54321 from earlier. Should I use that one, or do you have a different tracking number?"

Do not call tools until the current value has been collected, validated, and confirmed.

处理拼读的字符

当用户逐个字母拼读 ID、代码、姓名或电子邮件地址时使用此功能。输入的是口语形式，而不是最终值。

## Spelled-Out Characters

When a user dictates an ID, code, or email character by character, treat the spoken sequence as one compact value. Preserve explicitly spoken separators like dash, dot, underscore, slash, or plus; otherwise do not add spaces or separators.

Examples:

- "A B C one two three" -> "ABC123"
- "B C dash nine eight seven" -> "BC-987"
- "J O H N at example dot com" -> "john@example.com"

Do not insert spaces between spelled-out characters unless the user explicitly says the value contains spaces.

谨慎规范化口述数字

对于数字标识符，用户可能会逐个念出数字、对数字进行分组或使用自然数短语。如果字段期望一个连续的数字值，请将清晰的口述数字转换为数字形式。

## Spoken Number Handling

Convert spoken numbers into digits when collecting numeric identifiers.

Examples:

- "one two three four" -> "1234"
- "one twenty three" -> "123"
- "one nineteen" -> "119"
- "ninety nine eleven" -> "9911"
- "nine thousand nine hundred eleven" -> "9911"

If multiple interpretations are plausible, ask the user to clarify before using the value.

Example:

"I heard either 119 or 1-19. Could you repeat the number digit by digit?"

在工具调用前确认确切的标识符

订单 ID、追踪号码、账号、理赔号、确认码及类似标识符属于高精度字段。在将它们用于工具调用之前，请先进行确认。

对于数字标识符，请逐位复述该值。将值作为完整数字读出可能会掩盖错误。

Example:

助手：确认一下，我听到的是 8… 3… 5… 2… 1。对吗？

如果用户更正了一个字符或数字，请在调用工具前重复完整更正后的值。

Example:

助手：好的。我记下的是 8… 3… 5… 7… 1。对吗？

## Exact Identifier Confirmation

Before calling tools with high-precision identifiers:

- Confirm the final normalized value with the user.
- Read numeric identifiers back digit by digit.
- Do not use guessed, partial, or ambiguous values.
- If the user corrects the value, repeat the full corrected value before calling the tool.

逐个字符确认电子邮件

电子邮件地址是重要的信息。点、连字符、下划线、重复的字母以及发音相似的名称可能会导致账号查询失败，或将邮件发送到错误的地址。

请用户拼读电子邮件地址：

助手：您能逐个字符拼读一下电子邮件地址吗？这样我可以确保准确无误。

复述时，请确认准确的最终地址：

助手：确认一下，是 c-h-e-n at example dot com，对吗？

## Email Confirmation

Email addresses must be captured exactly.

If the user says the email naturally without spelling it out, ask them to repeat it character by character.

Example:

"Could you spell the email address character by character so I can make sure I have it exactly right?"

When reading an email back, confirm the exact final email address.

Example:

"Just to confirm, that is c-h-e-n at example dot com, right?"

实体收集工作流

避免字面指令陷阱

gpt-realtime-2 比早期的实时模型更严格地遵循指令。在旧模型上运行良好的提示词可能需要进行微调。

使用精确的语言。模型可能会优先考虑指令的字面措辞，而不是您期望的更广泛的行为。宽泛或僵化的规则可能会以令人意外的方式主导助手的行为，尤其是当多条规则重叠时。

谨慎使用约束词，例如 must, only, never，且 always。仅在确实需要该行为时使用它们，而不是作为一般的强调手段。过度使用硬性约束会使助手变得死板、过于谨慎，或无法处理合理的例外情况。

优先使用精确的范围：

For write actions that modify user data, ask for confirmation before calling the tool.

避免宽泛的范围：

Always ask for confirmation before doing anything.

宽泛的版本可能会在无害的只读查询（例如检查订单状态、检索可用性或读取账户信息）之前导致不必要的确认。

字面解释示例

通用提示建议：

  • 优先使用明确的指令，而非隐含的意图。
  • 除非行为确实需要严格限制，否则避免使用不必要的约束词。
  • 尽量减少相互矛盾的指导。
  • 谨慎处理分层或相互竞争的优先级指令。
  • 逐步测试提示词。微小的措辞变化可能会产生巨大的行为差异。
  • 从早期的实时模型迁移时，预计某些提示词需要进行重构才能获得最佳效果。

分别控制语言和口音

语言和口音应该分开控制。

用户的口音与其预期的语言并不相同。用户可能会带印度、西班牙、法国或普通话口音说英语，并且依然期望得到英语回复。

避免使用过于宽泛的语言指令，例如：

Mirror the user.
Respond naturally in the user's language.
Switch languages when appropriate.
Sound local.
Adapt to the user's accent.

这些指令过于宽泛。模型可能会将口音、语气词、附和词或个别外语词汇误解为需要切换语言的信号。

英语语言策略

## Language

English is the default response language.

- Do not infer language from accent alone.
- Ignore short filler sounds, backchannels, and isolated foreign words for language detection.
- Only switch languages if the user explicitly asks or provides a substantive utterance in another language.
- If language confidence is low, ask a short clarification instead of guessing.
- Keep preambles, spoken bridges, tool-related messages, and final answers in the same language.
- Accent adaptation must not change the response language.

多语言策略

## Language

Default to English unless the user clearly uses another language.

Switch languages only when:

- the user explicitly asks to use another language;
- the user provides a substantive utterance in another language. A substantive utterance means the user gives a complete request, question, or correction in another language, not just a greeting, name, address, filler word, or borrowed phrase.

Do not switch languages based on:

- accent;
- pronunciation;
- filler words;
- short backchannels;
- names;
- addresses;
- isolated foreign words.

If uncertain, ask:

"Would you like me to continue in English or [LANGUAGE]?"

口音控制

gpt-realtime-2 可以更强地遵循口音指令，但模糊的口音提示可能会导致漂移或非预期的语言切换。

口音控制提示在明确指定以下内容时效果最佳：

  • the target accent;
  • 哪些特征应保持稳定；
  • 预期的语速、重音和韵律；
  • 口音适应是否应影响语言选择。

而不是：

Sound Australian.

Use:

## Accent

Speak English with a light Australian accent.

- Keep the accent stable from the first word to the last.
- Use natural Australian vowel shaping, but keep speech easy to understand.
- Do not exaggerate the accent.
- Do not change response language based on the user's accent.

自定义语音

使用 自定义声音 当标准声音无法可靠地满足品牌、口音或角色要求时。

提示可以引导口音、语速和表达方式，但无法完全替代声音设计。对于需要一致的品牌声音标识或口音保真度的用例，请考虑 自定义声音.

自定义语音仅面向获批客户开放。请联系您的客户团队获取访问权限。

在长会话中维持状态

gpt-realtime-2 将实时上下文窗口从 32k 扩展到了 128k 个 token，使其更适合长会话。对于密集的双向对话，128k 个 token 大致可视为约 1-2 小时的密集原始音频上下文。具体情况会因工具调用、内部推理、注入的记录以及其他会话细节而异。

For long-context use cases, gpt-realtime-2 当能够区分哪些信息是最新的、哪些是背景信息，以及在来源冲突时应该忽略哪些信息时，其表现最佳。不要依赖模型从原始转录或大型上下文转储中推断来源优先级。请使用结构化的方式。

在开启包含大量上下文（例如检索到的记录、先前的对话历史、策略、摘要、客户备注或背景文档）的会话时，请使用结构化的模式。

从早期的实时模型迁移

从早期的实时模型迁移时，请将提示词视为一个行为层面，而不仅仅是需要移植的文本。

  1. 使用 Codex 或强大的推理模型，按照最新的 Realtime 提示指南重构提示词。包含指向此提示指南的链接，以便在最佳实践的基础上进行迁移。
  2. 将推理努力设置为 low 而非默认值。仅在有需要更深层次规划的工作流中才提高该值。
  3. 审查工具名称、参数、枚举、JSON schemas 及其他设置，确保它们与预期的实现相匹配。
  4. 移除过时的示例。为正常路径、歧义情况、中断、工具调用和回退行为添加简短的示例。
  5. 在迁移前后比较具有代表性的对话。根据现有的评估检查是否存在性能退化，并记录有意为之的行为变更。
  6. 进行最终的统一性检查。确认提示词清晰地划分了硬性要求、默认值、工具规则、安全规则和回退行为。
  7. 运行评估，检查具有代表性的失败案例，并迭代提示词，直到目标行为稳定可靠。

后续步骤