主导航

推荐

开始使用

核心概念

Agents SDK

工具

运行与扩展

评估

实时与音频

模型优化

专用模型

上线

遗留 API

资源

API 控制台

使用实时模型

提示、推理并微调实时语音模型。

gpt-realtime-2 是我们最先进的推理语音模型，专为低延迟语音到语音（speech-to-speech）应用而设计。与早期的实时模型相比，它具备预先推理能力，能更可靠地遵循指令，拥有更大的上下文窗口，并且工具调用也更加精准。

为了充分利用这些改进，设计提示词时应更具意图性。清晰定义助手的职责、决策点、工具调用行为和准则：它应该做什么、什么时候做、以及应该避免什么。

由简入繁。不要在一开始就过度提示。从一个最简提示开始，运行评估，然后仅针对测试中表现不佳的行为添加具体指令。

选择模型

模型使用场景提示重点
gpt-realtime-2

当您需要最强的实时推理、工具使用和指令遵循能力时。

微调推理强度（Reasoning effort）、前导语（Preambles）、工具策略、精确实体捕获和长会话状态。

gpt-realtime-1.5当您需要一个快速、可靠且无需复杂推理的语音到语音模型时。

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

实时 2.0 提示指南

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

Realtime 2 的变化

将 Realtime 2 作为推理型语音智能体进行提示，而不是作为基础语音机器人。

变更点对提示词的意义
推理允许模型在开口说话或调用工具前，先对复杂任务进行内部推理。使用前导语（Preambles）来避免尴尬的沉默或不必要的填充词。
提示精度更重要将“提供帮助”等宽泛的指导替换为清晰的触发条件、执行动作和例外规则：何时行动、做什么、以及何时不行动。
指令冲突代价更高除非确实必要，否则请移除重叠的 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

并非每个用例都需要所有部分。仅添加与您的产品相关的内容。

设置推理强度（Reasoning effort）

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.

示例

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

助手：如果您追求最低成本，选择 Basic。如果您需要团队权限和共享账单，选择 Pro。如果合规性审查或管理员控制很重要，选择 Enterprise。

设计工具行为

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.

高风险示例

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

糟糕的回复

助手：我已经扣款了。

优秀的回复

助手：确认一下，您希望我从存档的卡中扣除 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.

糟糕的回复

助手：出错了。

优秀的回复

助手：我无法找到与 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.

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

处理静默和背景音频

语音智能体默认倾向于响应。在生产环境中，它们经常会听到不应回应的音频，例如静默、背景噪音、等待音乐、电视声或侧面谈话。

当助手应该保持安静并继续倾听时，使用无操作（no-op）等待工具。该工具为模型提供了有效的非语音动作，而不是让它说出“我在这里”或“我没听清”之类的话。

工具设计

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（最终）通道产生最终的用户反馈。当行为取决于它出现的位置时，使用特定于通道的指令。

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

例如，工具调用发生在 commentary 通道中。如果您希望助手在工具使用之前、期间或之后说话，请在与 commentary 通道相关的指令中明确说明。

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

gpt-realtime-2 可以在单次交互中生成多个响应阶段。在 API 输出中，这种区别通过 response.done 事件表示，其中包含一个 phase 值，指示内容是 commentary 还是 final 答案。

您可以使用此字段在应用程序中分别处理每个阶段。例如，commentary 可以作为简短的中间更新播放或显示，而 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.

示例

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

糟糕的回复

助手：我这就查询订单 31。

优秀的回复

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

捕获精确实体

许多实时工作流依赖于精确数值：订单 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、追踪号、账号、确认码等类似标识符是高精度字段。在调用工具前务必确认。

对于数字标识符，逐个数字回读数值。将其读作完整数字可能会掩盖错误。

示例

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

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

示例

助手：明白了。我记录的是 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 可以更强有力地遵循口音指令，但模糊的口音提示可能导致漂移或意外的语言切换。

口音控制提示词在指定以下内容时效果最好：

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

与其说

Sound Australian.

不如说

## 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.

自定义语音

当标准语音无法可靠地满足品牌、口音或角色要求时，请使用 自定义语音 (Custom Voices)。

提示词可以引导口音、节奏和表达，但不能完全替代语音设计。对于需要一致的品牌语音身份或口音保真度的用例，请考虑 自定义语音。

自定义语音仅对通过审核的客户开放。请联系您的客户团队获取访问权限。

在长会话中保持状态

gpt-realtime-2 将实时上下文窗口扩展至 128k token，使其更适合长会话。对于密集的双向对话，128k token 大约相当于 1-2 小时的密集原始音频内容。这会根据工具使用、内部推理、注入记录和其他会话细节而变化。

对于长上下文用例，当模型能分辨哪些信息是当前信息、哪些是背景信息、以及来源冲突时应忽略什么内容时，gpt-realtime-2 表现最佳。不要指望模型能从原始转录或庞大的上下文堆栈中推断来源优先级。请使用结构化数据。

在开始一个包含大量上下文（例如检索到的记录、过往对话历史、策略、摘要、账户笔记或背景文档）的会话时，使用结构化模式。

从早期实时模型迁移

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

  1. 使用 Codex 或强推理模型围绕最新的实时提示指南重新构建提示词。添加指向此提示指南的链接，以确保迁移遵循最佳实践。
  2. 将推理强度设置为 low，而不是默认值。仅针对需要深度规划的工作流增加强度。
  3. 审计工具名称、参数、枚举、JSON 模式和其他设置，以确保它们匹配预期的实现。
  4. 移除过时的示例。为成功路径、歧义、中断、工具调用和后备行为添加简短的示例。
  5. 比较迁移前后的代表性对话。针对现有评估检查回归情况，并记录刻意的行为变更。
  6. 进行最终一致性检查。确认提示词清楚地分开了硬性要求、默认值、工具规则、安全规则和后备行为。
  7. 运行评估，检查代表性失败，并迭代提示词，直到目标行为可靠为止。

后续步骤

© . This website operates independently and is not affiliated with or endorsed by OpenAI, Inc. All brand names, logos, and trademarks are the property of their respective owners.