OpenAI Realtime 模型提示词

选择正在使用的 Realtime 模型。GPT-Live 的提示词见 GPT-Live 提示词。

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，冲突时明确优先级。
工具行为更可控	指定何时立即行动、补问信息、确认高精度细节、失败重试或升级处理。
开场说明成为明确行为	可在较长推理或工具流程前播报简短更新，应规定时机、长度和省略条件。
上下文扩大	从 32k 扩展到 128k，更适合长会话与较大的系统提示词。

开场说明不是隐藏思维链，而是“我现在查一下这个订单”等简短可听更新。不要要求披露私有推理。

推荐提示词结构

使用简短、带标签的部分，使模型快速找到相关指令。

来源示例 1（text）：

本例中文译文与说明：

角色与目标；个性与语气；语言；推理；消息通道；开场说明；详细程度；工具；不清楚的音频；实体采集；长上下文行为；升级处理。

## 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 设置外，也要引导何时推理、推理多少。

来源示例 2（text）：

本例中文译文与说明：

推理：
- 直接回答、简单查询和简短确认要快速回应，不做推理。
- 多步任务、工具决策、故障排查或升级处理，应先推理再行动。
- 音频不清楚时，不长时间推测用户说了什么，而应澄清。

## 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 默认生成开场说明。先测试默认行为，不符合体验要求时再明确调整。

来源示例 3（text）：

本例中文译文与说明：

开场说明：仅在有助用户理解正在工作时使用简短说明。

何时使用：即将调用耗时明显的工具；需推理多步请求；检查记录、可用性、账户状态或政策；准备升级或转交；静音会显得没响应。需要时，紧接实质推理或工具使用之前立即说出。

何时不用：可以立即直接回答；用户只在确认、纠正或拒绝；音频不清楚需澄清；最新音频是静音、背景噪声、等待音乐、电视或旁人对话；工具很轻量，更新对用户没有帮助。

风格：自然、平静、简洁；跨轮次变化措辞；描述动作而非内部推理；避免填充语。不说“让我想想”“嗯”“等我处理一下”“我现在要访问工具”等。

长度：一个短句。除高影响操作前用户需要解释外，不超过两个短句。

推荐：“我现在查这个订单。”“我查一下预约详情。”“修改前我先核实。”“我检查政策后给你下一步。”“我调出记录，确保是正确账户。”

避免：“让我想一会儿。”“请等待处理请求。”“我现在用工具。”“问题有意思，我会仔细推理。”

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

控制回复长度

按任务类型规定详细程度，比笼统“简洁”更有效。直接回答、工具结果、故障排查、比较和升级处理可能各需不同长度。

来源示例 4（text）：

本例中文译文与说明：

详细程度：
- 直接答案用1–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。

设计工具行为

模型工具调用更强，但仍取决于提示词和工具说明。未规定行动、提问、确认及恢复时机，可能导致过早调用、不必要提问或反复失败调用。

设置工具调用积极程度

只读、低风险操作适合较积极；修改数据、产生外部影响或依赖精确标识的操作应更谨慎。

工具类型	默认行为
只读低风险查询	意图和必需字段明确后调用。
依赖精确标识的只读查询	查询前确认标识。
用户可见通信	发送前起草或概述。
账户变更	调用前确认。
购买、取消、支付	确认金额、对象和后果。
不可逆或高影响操作	明确确认，适当时提供升级处理。

读写混合场景可从以下平衡默认规则开始，再按用途调整：

来源示例 5（text）：

本例中文译文与说明：

工具：仅使用当前列表明确提供的工具，不编造、假定、模拟或改名。

只读工具：意图明确且必需字段齐全时调用。除依赖高精度标识或有明显查错记录风险外，不要求确认。仅在必填值缺失、含糊或冲突时澄清。

写入工具或外部动作：调用前概述意图与关键后果，包括更改、发送、取消、下单或扣款内容。请求确认，明确确认前不得调用。

精确标识：订单号、运单号、账号、确认码、电话和邮箱均按高精度处理。字段类型明确后才规范化；账户专属查询、验证或写入前确认最终值。

调用后：只有工具成功才说动作已完成。失败时简短说明，不暴露原始错误，并给明确下一步。

## 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，可以继续吗？”

从工具失败中恢复

失败属于对话的一部分。应解释发生了什么，并给明确下一步。

不要对所有失败采用同一方式。按工具类型、失败形式和用户影响选择静默重试、澄清、纠正标识、确认新操作或其他路径。

来源示例 6（text）：

本例中文译文与说明：

工具失败：
1. 用用户容易理解的语言简短说明失败。
2. 不责怪用户，不暴露原始工具错误。
3. 可能与精确标识有关时，回读使用的值，请用户纠正。
4. 可能是临时故障时，提议重试一次。
5. 同样错误重复发生时，提供其他路径或升级。

失败后不要用相同参数反复调用同一工具。先核对采集值是否正确，再要求换标识。

## 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，就可能错调或模拟动作。

来源示例 7（text）：

本例中文译文与说明：

工具可用性：只使用列表明确提供的工具，不编造、假定或模拟。指令提到而列表没有的工具视为不可用。
用户请求依赖不可用工具时：不假装完成；简短说明工具不可用；提供最接近的受支持下一步。
仅在对应调用成功后才说动作完成。

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

可用附录的提示词审查元提示，检查矛盾、缺失工具和脆弱规则。

处理静音与背景音

语音智能体通常倾向回复，但生产中常听到不应回应的静音、噪声、等待音乐、电视或旁人交谈。

需要安静聆听时，提供一个不执行操作的等待工具，让模型有合理的非讲话动作，而不是说“我在”或“没听清”。

工具设计：

来源示例 8（json）：

本例中文译文与说明：

wait_for_user 工具说明：最新音频为静音、背景噪声、等待音乐、电视、旁人交谈或非对助手的讲话，不需要口头回复时调用。它让当前轮次在不讲话的情况下结束。参数是无属性、无必填字段的对象。

{
  "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": []
  }
}

配合提示词：

来源示例 9（text）：

本例中文译文与说明：

处理静音与背景噪声：若最新音频为静音、噪声、等待音乐、电视、旁人交谈或非对你讲话，调用 wait_for_user，之后不再作对话回复。
不要说“我在”“没听清”“慢慢来”“准备好再告诉我”。只有用户明确叫你或求助时恢复正常回答。

## 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 的关系。

来源示例 10（text）：

本例中文译文与说明：

在 commentary 通道调用工具之前，简短告诉用户正在做什么。

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

模型一轮可产生多个响应阶段。API 的 response.done 包含 phase，表明内容是 commentary 还是最终答案。应用可分别处理：中间说明简短播放或显示，final_answer 用作完整回复。

来源示例 11（text）：

本例中文译文与说明：

第一个输出项的 phase 为 commentary，表示中间说明；第二个为 final_answer，表示最终答案。字段值保留原样。

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

响应阶段示例

用户提示：

“我卡在这道 AP 生物题上了：[QUESTION]。”

精简 API 响应：

来源示例 12（json）：

本例中文译文与说明：

commentary 中的语音转录：“先聚焦酶的形状与结合方式，这是关键概念。”final_answer 中的语音转录：“高温下活性位点会发生什么变化？”

{
  "type": "response.done",
  "response": {
    "output": [
      {
        "phase": "commentary",
        "content": [
          {
            "type": "output_audio",
            "transcript": "Let's zero in on the enzyme's shape and binding, since that's the key idea here."
          }
        ]
      },
      {
        "phase": "final_answer",
        "content": [
          {
            "type": "output_audio",
            "transcript": "What changes at the active site at high temperature?"
          }
        ]
      }
    ]
  }
}

处理不清楚的音频

只对能确信理解的音频采取动作。听不清时简短澄清，不要猜测。

不要让模型补出缺失词、调用工具、采集实体、生成开场说明，或耗费隐藏推理重建用户可能说的话。

来源示例 13（text）：

本例中文译文与说明：

不清楚的音频：
- 仅回应清晰音频或文字。
- 听不清时，用简短英语澄清，如“抱歉，可以清楚地再说一遍吗？”
- 不连续两次重复相同澄清句。
- 有歧义、噪声、静音、无法理解、部分截断，或无法确定准确词语时，均视为不清楚。
- 不猜意思，不进行推理，不在 commentary 生成说明或调用工具。

## 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”，而应说“我只听到部分订单号，请逐位再说一遍”。

精确采集实体

订单号、运单号、邮箱、确认码、账号、理赔号、工单、支持编号、电话等工作流依赖精确值。

用户可能说得快、用不同方式分组数字、只拼一部分、夹杂填充词、中途纠正，或说出相似发音字符。错一位就可能查不到或查到别人的账户。

保守采集，一次一个值；仅规范化清楚的部分，高精度值调用前确认，每次纠正都可恢复。

一次收集一个实体

多个值逐个收集，避免语音中不同字段混在一起。

来源示例 14（text）：

本例中文译文与说明：

实体收集顺序：一次一个必需值。只问下一个缺失值，同轮不问多个。提问前检查对话或会话前面是否已提供；如有候选值，先确认再用。
例如：“前面有运单号 ABC-54321，使用它，还是另一个？”
当前值收集、验证和确认之前不调用工具。

## 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、代码、姓名或邮箱。口语形式是输入，不是最终值。

来源示例 15（text）：

本例中文译文与说明：

逐字拼读：用户逐字符读 ID、代码或邮箱时，视为一个紧凑值。保留明确说出的横杠、点、下划线、斜杠、加号，否则不自行加空格或分隔。
“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。
除非用户明确说包含空格，否则字符间不加空格。

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

谨慎规范化口语数字

用户可能逐位、分组或以自然数词说数字。字段要求连续数字时，把明确的数字表达转换成数字串。

来源示例 16（text）：

本例中文译文与说明：

口语数字：采集数字标识时转换为数字。
“one two three four” → 1234；“one twenty three” → 123；“one nineteen” → 119；“ninety nine eleven” → 9911；“nine thousand nine hundred eleven” → 9911。
存在多种合理解释时先澄清，例如：“我听到119或1-19，请逐位再说一次。”

## 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?"

调用工具前确认精确标识

订单号、运单号、账号、理赔号、确认码等高精度字段均应先确认。

数字标识逐位回读，不要读成一个完整数值而掩盖错误。例如：“确认一下，我听到的是8……3……5……2……1，对吗？”

用户纠正一位后，调用前再次完整回读，例如：“收到，现在是8……3……5……7……1，对吗？”

来源示例 17（text）：

本例中文译文与说明：

精确标识确认：调用前向用户确认最终规范化值；数字逐位回读；不使用猜测、不完整或歧义值。纠正后，调用前完整复述更正值。

## 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，对吗？”

来源示例 18（text）：

本例中文译文与说明：

邮箱确认：必须准确采集。用户自然说出但未拼读时，请逐字符再说一遍，例如“请逐字符拼一下邮箱，以便确保准确”。回读时确认完整最终地址，例如“确认是 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?"

实体收集工作流

实体收集工作流示例

任务要求所有工具调用前取得精确值时，使用完整流程：

来源示例 19（text）：

本例中文译文与说明：

实体收集流程：订单号、运单号、确认码、账号、理赔号、工单、支持编号、邮箱、电话等精确值，任何工具使用前先采集确认。

1. 收集下一个必需值：一次只问一个缺失值，不在同轮问多个精确值；先检查是否已在对话或会话提供。
2. 只规范化明确部分：将清楚的数字或字母拼读变成预期格式，保留明确分隔符；不猜测、推断、修补或补齐不清楚字符；多种解释时复问。
3. 确认最终值：使用前回读；数字逐位；邮箱需要精确时逐字符；等待明确确认。
4. 确认后再调用：不以猜测、部分、歧义或未确认值运行查询、账户、消息、付款、预订或更新工具。
5. 安全处理纠正：更新被纠正部分，完整回读并再次确认；全部最终值确认前不用于工具。

示例：用户“我的订单号是 ORD-3125B23。”助手“确认 O-R-D 横杠3-1-2-5-B-2-3，对吗？”
用户“83521，其实第四位是7。”助手“现在是8……3……5……7……1，对吗？”
用户“邮箱 chen@example.com。”助手“请逐字符拼一下，确保准确。”
绝不用猜测、不完整、歧义或未确认的精确值调用工具。

## Entity Collection Workflow

When a workflow requires an exact value, collect and confirm it before using it in any tool call.

Exact values include order IDs, tracking numbers, confirmation codes, account numbers, claim numbers, ticket IDs, support references, email addresses, phone numbers, and similar identifiers.

Follow this workflow:

1. Collect the next required value.

- Ask for only one missing value at a time.
- Do not ask for multiple exact values in the same turn.
- Before asking, check whether the value was already provided earlier in the conversation or session.

2. Normalize only what is clear.

- Convert clearly spoken digits or spelled-out characters into the expected format.
- Preserve explicit separators such as dashes, dots, underscores, slashes, and plus signs.
- Do not guess, infer, repair, or fill in unclear characters.
- If the value could be interpreted in more than one way, ask the user to repeat or clarify it.

3. Confirm the final value.

- Read back the normalized value before using it.
- For numeric identifiers, confirm digit by digit.
- For email addresses, confirm character by character when precision matters.
- Wait for a clear confirmation from the user.

4. Call the tool only after confirmation.

- Do not call lookup, account, messaging, payment, booking, or update tools with guessed, partial, ambiguous, or unconfirmed values.

5. Recover safely from corrections.

- If the user corrects any part of the value, update the value, repeat the full corrected value, and ask for confirmation again.
- Do not use the corrected value in a tool call until the user confirms the full final value.

Examples:

User: My order ID is ORD-3125B23.

Assistant: Just to confirm, I heard O-R-D dash 3-1-2-5-B-2-3. Is that right?

User: It is 83521 - actually, the fourth digit is 7.

Assistant: Got it. I have 8... 3... 5... 7... 1. Is that correct?

User: My email is chen@example.com.

Assistant: Could you spell that email address character by character so I can make sure I have it exactly right?

Never call tools with guessed, partial, ambiguous, or unconfirmed exact values.

避免字面指令陷阱

gpt-realtime-2 比较早模型更按字面遵循指令，因此原提示词可能需要调整。

应使用精确语言。模型可能优先执行字面措辞，而非开发者希望的较宽行为。宽泛或僵硬规则，尤其多条重叠时，可能意外主导全部行为。

must、only、never、always 仅用于真正必需的行为，不当作普遍强调。过多硬约束会让助手僵化、过度谨慎或无法处理合理例外。

推荐精确范围：

来源示例 20（text）：

本例中文译文与说明：

会修改用户数据的写入操作，在调用工具之前请求确认。

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

避免宽泛范围：

来源示例 21（text）：

本例中文译文与说明：

做任何事之前始终请求确认。

Always ask for confirmation before doing anything.

宽泛版本可能让订单状态、可用性或账户读取等无害只读查询也反复确认。

字面理解示例

字面理解陷阱示例

以下提示词过窄：

来源示例 22（text）：

本例中文译文与说明：

收到确认码后原样复述，等待明确的“是”。

When a confirmation code is provided, repeat it verbatim and wait for a clear yes.

用户说：“我的订单号是 ORD-3125B23。”模型可能不应用规则，因为用户给的是订单号而非确认码。开发者意图明确，但规则范围太窄。

更妥当的改写：

来源示例 23（text）：

本例中文译文与说明：

用户提供精确标识，包括确认码、订单号、工单号、重置 PIN、理赔号、运单号或账号时，先复述采集值，等确认后再用于工具。

When the user provides an exact identifier, including confirmation codes, order IDs, ticket IDs, reset PINs, claim numbers, tracking numbers, or account numbers, repeat the captured value and wait for confirmation before using it in a tool call.

一般建议：

• 明确写出指令，避免只暗示意图。
• 非真正要求僵硬行为时，减少约束词。
• 尽量消除矛盾。
• 谨慎使用多层或竞争优先级。
• 增量测试，少量改词可能大幅改变行为。
• 从早期模型迁移时，预计部分提示词需重组。

分别控制语言与口音

语言与口音是两回事。用户可能带印地语、西班牙语、法语或普通话口音讲英语，仍希望用英语回答。

避免以下宽泛语言要求：

来源示例 24（text）：

本例中文译文与说明：

模仿用户；自然地用用户语言回答；适当切换语言；听起来像本地人；适应用户口音。

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

否则模型可能因口音、填充词、聆听回应或孤立外语词而切换语言。

英语语言策略

来源示例 25（text）：

本例中文译文与说明：

语言：默认英语。不仅凭口音推断语言；检测时忽略短填充声、聆听反馈和孤立外语词。仅在用户明确要求，或以另一语言说出实质内容时切换。判断不确定时简短澄清，不猜测。开场、衔接、工具消息及最终答案保持同一语言，口音适配不能改变回复语言。

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

多语言策略

来源示例 26（text）：

本例中文译文与说明：

语言：除非用户明确使用另一语言，默认英语。
仅在用户明确要求，或以另一语言提出完整请求、问题或纠正时切换；仅问候、姓名、地址、填充词或借用短语不算实质表达。
不因口音、发音、填充词、短反馈、姓名、地址或孤立外语词换语言。不确定时问：“继续用英语还是 [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]?"

口音控制

模型更能遵循口音要求，但模糊描述可能导致漂移或意外换语言。

最好明确目标口音、应稳定的特征、节奏重音与韵律，以及口音适配是否影响语言选择。

不要只写：

来源示例 27（text）：

本例中文译文与说明：

听起来像澳大利亚人。

Sound Australian.

改用：

来源示例 28（text）：

本例中文译文与说明：

口音：用轻微澳大利亚口音说英语。从头到尾稳定，自然使用澳式元音但保持易懂，不夸大口音，也不因用户口音更换回复语言。

## 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。密集双向语音中，128k 可粗略理解为约1–2小时的原始音频上下文容量，实际受工具、内部推理、注入记录和其他细节影响。这不代表连接时长限制相应改变。

长上下文应明确哪些是当前信息、背景信息，以及来源冲突时忽略什么。不要指望模型从原始转录或大量上下文堆叠中推断优先级，应使用结构。

启动时需要大量检索记录、历史、政策、摘要、账户备注或背景文档，可使用结构化模式。

长会话上下文模板示例

来源示例 29（text）：

本例中文译文与说明：

上下文：
当前状态：当前任务[current task]；最新已知值[current value]；下一安全步骤[what the assistant should do next]。
权威来源：事实或记录[fact or record]；来源[工具结果/现行政策/已验证记录]；状态为当前；获取于[日期时间/本轮]。
历史或背景来源：旧事实[older fact or record]；来源[此前对话/旧记录/摘要]；状态为过时或背景；与当前来源冲突时不得用于当前决策。
相关政策或规则：[决策规则或约束]。
其他上下文：[可能有用但不具权威性的背景]。

## Context

### Current State

- **Current task:** [current task]
- **Latest known state:** [current value]
- **Next safe step:** [what the assistant should do next]

### Authoritative Sources

- **Fact or record:** [fact or record]
- **Source:** [tool result / active policy / verified record]
- **Status:** current
- **Retrieved:** [date/time or this turn]

### Historical or Background Sources

- **Older fact or record:** [older fact or record]
- **Source:** [prior conversation / older record / summary]
- **Status:** stale or background
- **Note:** Do not use for current decisions if it conflicts with a current source.

### Relevant Policy or Rules

- [decision rule or constraint]

### Other Context

- [potentially useful but non-authoritative background]

从早期实时模型迁移

把提示词视为行为接口，而非简单搬运文字：

1. 用 Codex 或强推理模型，依据当前指南重组提示词，并提供本指南链接作为依据。
2. 推理强度设为 low，而非沿用默认；仅需更深规划时提高。
3. 审查工具名、参数、枚举、JSON 结构及其他设置与实现一致。
4. 移除过时例子，补正常路径、歧义、打断、工具调用和回退的短例。
5. 迁移前后比较代表性对话，用现有评估检查回归并记录有意变化。
6. 最终检查硬性要求、默认行为、工具规则、安全与回退清楚分开。
7. 运行评估、检查失败并迭代，直到目标行为可靠。

Realtime 1.5 提示词指南

gpt-realtime-1.5 是 Realtime API 语音到语音模型，同样适用 gpt-realtime 提示词指导。

语音到语音系统让语音成为核心 AI 界面。模型支持稳健、实用、可规模化处理关键工作流的实时智能体。

相比早期预览模型，它的指令遵循、工具可靠性和声音质量更好，整体更顺畅，使串联应用迁移为真正实时体验更可行，降低延迟并让回复更自然有表现力。

实时模型有些提示技巧并不直接适用于文本模型。以下从提示词骨架开始，逐部分说明技巧、可复用模式和可适配示例。

一般建议

• 持续迭代：小改词就可能决定效果。例如将听不清指令中的 inaudible 改为 unintelligible，改善了噪声输入处理。
• 要点优于长段落：清晰短列表通常表现更好。
• 用例子引导：模型会紧密跟随示例短语。
• 保持精确：歧义和冲突会像 GPT-5 一样降低表现。
• 控制语言：出现意外切换时固定目标语言。
• 减少重复：增加表达多样性规则，减少机械措辞。
• 用大写强调：突出关键规则，便于遵循。
• 把非文本规则写成自然语言：例如把 IF x > 3 THEN ESCALATE 改为 IF MORE THAN THREE FAILURES THEN ESCALATE（超过三次失败就升级处理）。

提示词结构

结构有助模型理解上下文、跨轮次一致，也便于定位问题和修改。

• 作用：系统提示词分成清晰、有标签的部分，每部分只聚焦一件事。
• 适配：添加合规、品牌政策等领域部分；没有发音问题时可移除参考发音等不需要的部分。

示例：

来源示例 30（text）：

本例中文译文与说明：

角色与目标：你是谁，成功是什么。
个性与语气：应保持的声音与风格。
上下文：检索内容与相关信息。
参考发音：难读词的发音指导。
工具：名称、使用规则和开场说明。
指令与规则：可做、不可做及方法。
对话流程：状态、目标与转换。
安全与升级：回退与转交逻辑。

## Role & Objective        — who you are and what “success” means
## Personality & Tone      — the voice and style to maintain
## Context                 — retrieved context, relevant info
## Reference Pronunciations — phonetic guides for tricky words
## Tools                   — names, usage rules, and preambles
## Instructions / Rules    — do’s, don’ts, and approach
## Conversation Flow       — states, goals, and transitions
## Safety & Escalation     — fallback and handoff logic

角色与目标

定义智能体是谁、什么算完成。两个身份示例展示明确角色后模型如何紧密遵循。

• 何时使用：模型没体现预期人格、角色或任务范围。
• 作用：固定语音智能体身份，使回复以角色描述为条件。
• 适配：按用途修改角色。

示例：特定口音

来源示例 31（text）：

本例中文译文与说明：

角色与目标：你是说魁北克法语的客服机器人，任务是回答用户问题。

## Role & Objective
You are a Quebecois French-speaking customer service bot. Your task is to answer the user's question.

早期实时预览模型：

打开原始音频

gpt-realtime-1.5：

打开原始音频

示例：扮演角色

来源示例 32（text）：

本例中文译文与说明：

角色与目标：你是充满活力的游戏节目主持人，引导来电者猜1到100的秘密数字，赢取1,000,000美元。

## Role & Objective
You are a high-energy game-show host guiding the caller to guess a secret number from 1 to 100 to win 1,000,000$.

早期实时预览模型：

打开原始音频

gpt-realtime-1.5：

打开原始音频

gpt-realtime-1.5 能比早期预览更可靠地表现指定角色。

个性与语气

模型能较好遵循特定个性或语气要求，可按场景调整声音体验与表达。

• 何时使用：回复平淡、冗长或轮次间不一致。
• 作用：设定声音、简洁度和节奏，让回复自然一致。
• 适配：调整亲切、正式与默认长度。受监管领域偏向中性准确，按需增加子部分。

示例

来源示例 33（text）：

本例中文译文与说明：

个性：友好、平静、容易接近的专业客服助手。语气：温暖、简洁、自信，不奉承。长度：每轮2–3句话。

## Personality & Tone
## Personality
- Friendly, calm and approachable expert customer service assistant.

## Tone
- Warm, concise, confident, never fawning.

## Length
2–3 sentences per turn.

示例：多种情绪

来源示例 34（text）：

本例中文译文与说明：

个性与语气：回答开头非常开心，中途转为悲伤，结尾变得非常愤怒。

## Personality & Tone
- Start your response very happy
- Midway, change to sad
- At the end change your mood to very angry

gpt-realtime-1.5 示例：

打开原始音频

模型能遵循复杂指令，在同一音频回复中切换三种情绪。

语速指令

Realtime API 的 speed 改变播放速率，不改变模型组织语音的方式。真正想让讲话更快，需要节奏指令。

• 何时使用：仅调播放速度不能满足更快说话风格。
• 作用：独立于播放速度调整简洁度与韵律。
• 适配：按场景改变速度指令。

示例

来源示例 35（text）：

本例中文译文与说明：

个性：友好、平静、容易接近的专业客服助手。语气：温暖、简洁、自信，不奉承。每轮2–3句话。节奏：快速表达但不显匆忙；不改变内容，只加快同一答案的讲话速度。

## Personality & Tone
## Personality
- Friendly, calm and approachable expert customer service assistant.

## Tone
- Warm, concise, confident, never fawning.

## Length
- 2–3 sentences per turn.

## Pacing
- Deliver your audio response fast, but do not sound rushed.
- Do not modify the content of your response, only increase speaking speed for the same response.

早期实时预览模型：

打开原始音频

gpt-realtime-1.5：

打开原始音频

明确节奏可让模型明显说得更快，又不显过于匆忙。

语言约束

语言约束有助在噪声、多语言等条件下持续使用预期语言。

• 何时使用：防止意外切换。
• 作用：将输出固定为选定语言。
• 适配：将“英语”换成目标语言，或增加更复杂规则。

示例：固定一种语言

来源示例 36（text）：

本例中文译文与说明：

个性：友好、平静、容易接近的专业客服助手；温暖、简洁、自信，不奉承；每轮2–3句话。语言：只用英语，用户要求也不以其他语言回答；用户讲别的语言时，礼貌说明仅提供英语支持。

## Personality & Tone
## Personality
- Friendly, calm and approachable expert customer service assistant.

## Tone
- Warm, concise, confident, never fawning.

## Length
- 2–3 sentences per turn.

## Language
- The conversation will be only in English.
- Do not respond in any other language even if the user asks.
- If the user speaks another language, politely explain that support is limited to English.

应用指令后的模型回复：

示例：教语言

来源示例 37（text）：

本例中文译文与说明：

角色与目标：你是友好、知识丰富的法语语音老师，通过有趣对话和清晰解释提升用户法语口语与听力；平衡沉浸式法语练习与辅助英语指导，确保理解和进步。
个性与语气：友好、平静、容易接近的专业客服助手；温暖、简洁、自信，不奉承；每轮2–3句话。
语言：语法、词汇和文化背景用英语解释；练习、举例及对话使用法语。

## Role & Objective
- You are a friendly, knowledgeable voice tutor for French learners.
- Your goal is to help the user improve their French speaking and listening skills through engaging conversation and clear explanations.
- Balance immersive French practice with supportive English guidance to ensure understanding and progress.

## Personality & Tone
## Personality
- Friendly, calm and approachable expert customer service assistant.

## Tone
- Warm, concise, confident, never fawning.

## Length
- 2–3 sentences per turn.

## Language
### Explanations
Use English when explaining grammar, vocabulary, or cultural context.

### Conversation
Speak in French when conducting practice, giving examples, or engaging in dialogue.

应用指令后的模型回复：

模型可按自定义指令在语言间切换。

减少重复

模型紧随示例可保持品牌风格，但过度复用会显得机械。重复规则在保留清晰度和品牌声音的同时增加多样性。

• 何时使用：跨轮次或会话重复相同开头、填充语或句型。
• 作用：鼓励近义词和其他句式，保留必要术语。
• 适配：调节严格程度，例如 N 轮内不复用同一开头；将法律、合规、品牌必需措辞列为例外，一致性重要时允许固定表达。

示例

来源示例 38（text）：

本例中文译文与说明：

个性：友好、平静、容易接近的专业客服助手；温暖、简洁、自信，不奉承；每轮2–3句话。只说英语，用户要求也不换语言；用户说其他语言时礼貌说明只支持英语。多样性：同一句话不说两次，变化回复，避免机械。

## Personality & Tone
## Personality
- Friendly, calm and approachable expert customer service assistant.

## Tone
- Warm, concise, confident, never fawning.

## Length
- 2–3 sentences per turn.

## Language
- The conversation will be only in English.
- Do not respond in any other language even if the user asks.
- If the user speaks another language, politely explain that support is limited to English.

## Variety
- Do not repeat the same sentence twice.
- Vary your responses so they don't sound robotic.

应用前，模型反复使用 Got it（收到）：

应用后：

回复与确认更有变化，不再机械重复。

参考发音

确保重要词语、数字、姓名和术语发音准确。

• 何时使用：品牌、术语或地点经常读错。
• 作用：用发音提示提高信任与清晰度。
• 适配：保持短清单，发现错误后更新。

示例

来源示例 39（text）：

本例中文译文与说明：

参考发音：SQL 读“sequel”；PostgreSQL 读“post-gress”；Kyiv 读“KEE-iv”；Huawei 读“HWAH-way”。

## Reference Pronunciations
When voicing these words, use the respective pronunciations:
- Pronounce “SQL” as “sequel.”
- Pronounce “PostgreSQL” as “post-gress.”
- Pronounce “Kyiv” as “KEE-iv.”
- Pronounce "Huawei" as “HWAH-way”

早期实时预览模型：

打开原始音频

gpt-realtime-1.5：

打开原始音频

参考发音指令可使模型将 SQL 读作“sequel”。

字母数字发音

语音回读电话、信用卡或订单号可能合并字符。明确逐字符确认可以避免误听，改善合成清晰度。

• 何时使用：难以采集或回读电话、卡号、双因素验证码、订单号、序列号、地址、房号或混合字符。
• 作用：一次说一个字符，加分隔并确认，纠正后再确认。可选字母发音消歧，如“A as in Alpha”。

示例：通用指令部分

来源示例 40（text）：

本例中文译文与说明：

指令：读数字或代码时逐字符说，中间加连字符，例如4-1-5。严格重复提供的数字，不遗漏任何位。

## Instructions/Rules
- When reading numbers or codes, speak each character separately, separated by hyphens (e.g., 4-1-5).
- Repeat EXACTLY the provided number; do not omit any digits.

如果采用对话流程策略，可指定哪些状态需要应用字母数字发音规则。

示例：对话状态中的指令

示例取自 openai-realtime-agents 的身份验证流程。

来源示例 41（txt）：

本例中文译文与说明：

状态3_get_and_verify_phone：请求电话并回读验证。
指令：礼貌询问电话；取得后逐位回读并问是否正确；被纠正后再次确认。
示例：“为访问账户，还需要一些信息，可以提供电话号码吗？”“你说的是0-2-1-5-5-5-1-2-3-4，对吗？”“你说的是4-5-6-7-8-9-0-1-2-3，对吗？”
电话确认后转入4_authentication_DOB。

{
    "id": "3_get_and_verify_phone",
    "description": "Request phone number and verify by repeating it back.",
    "instructions": [
      "Politely request the user’s phone number.",
      "Once provided, confirm it by repeating each digit and ask if it’s correct.",
      "If the user corrects you, confirm AGAIN to make sure you understand.",
    ],
    "examples": [
      "I'll need some more information to access your account if that's okay. May I have your phone number, please?",
      "You said 0-2-1-5-5-5-1-2-3-4, correct?",
      "You said 4-5-6-7-8-9-0-1-2-3, correct?"
    ],
    "transitions": [{
      "next_step": "4_authentication_DOB",
      "condition": "Once phone number is confirmed"
    }]
}

应用前：“好的，号码是55119765423，还需要其他帮助吗？”

应用后：“好的，号码是5-5-1-1-1-9-7-6-5-4-2-3，还需要其他帮助吗？”

指令

本部分说明如何让模型完成任务、应用最佳实践并修复问题。推荐使用类似 GPT-4.1 提示词指南的模式。

指令遵循

与 GPT-4.1、GPT-5 一样，冲突、歧义或不清晰指令会降低 gpt-realtime-1.5 表现。

• 何时使用：输出偏离规则、跳过阶段或误用工具。
• 作用：发布前用大语言模型识别歧义、冲突和缺失定义。

指令质量提示词（可用于 ChatGPT 或 API）

配合 GPT-5 使用以下提示，定位需要修复的部分：

来源示例 42（text）：

本例中文译文与说明：

角色与目标：你是提示词审查专家，检查用户提供的大语言模型提示词，发现以下弱点。
指令：检查措辞能否多解；是否有未定义的类别、术语或概念；指令是否冲突、缺失、模糊或不完整；是否暗中假定未说明能力。
不得列出：自己新增的指令、工具调用或外部信息，因为你不知道究竟缺什么工具；不确定的问题。
输出：Issues——编号列出问题，附短引文；Improvements——编号给出应改的原行和改法；Revised Prompt——将全部改进以最小、精准改动应用到原提示词后的版本。

## Role & Objective
You are a **Prompt-Critique Expert**.
Examine a user-supplied LLM prompt and surface any weaknesses following the instructions below.


## Instructions
Review the prompt that is meant for an LLM to follow and identify the following issues:
- Ambiguity: Could any wording be interpreted in more than one way?
- Lacking Definitions: Are there any class labels, terms, or concepts that are not defined that might be misinterpreted by an LLM?
- Conflicting, missing, or vague instructions: Are directions incomplete or contradictory?
- Unstated assumptions: Does the prompt assume the model has to be able to do something that is not explicitly stated?


## Do **NOT** list issues of the following types:
- Invent new instructions, tool calls, or external information. You do not know what tools need to be added that are missing.
- Issues that you are unsure about.


## Output Format
"""
## Issues
- Numbered list; include brief quote snippets.

## Improvements
- Numbered list; provide the revised lines you would change and how you would change them.

## Revised Prompt
- Revised prompt where you have applied all your improvements surgically with minimal edits to the original prompt
"""

提示词优化元提示（可用于 ChatGPT 或 API）

提供当前提示词及观察到的具体失败，模型会建议强化约束、减少问题的修订版本。

来源示例 43（text）：

本例中文译文与说明：

这是当前提示词：
[BEGIN OF CURRENT PROMPT]
{CURRENT_PROMPT}
[END OF CURRENT PROMPT]
但观察到以下问题：
[BEGIN OF ISSUE]
{ISSUE}
[END OF ISSUE]
请给出几个提示词变体，让模型更清楚理解约束并缓解问题。

Here's my current prompt to an LLM:
[BEGIN OF CURRENT PROMPT]
{CURRENT_PROMPT}
[END OF CURRENT PROMPT]

But I see this issue happening from the LLM:
[BEGIN OF ISSUE]
{ISSUE}
[END OF ISSUE]
Can you provide some variants of the prompt so that the model can better understand the constraints to alleviate the issue?

无音频或不清楚的音频

模型有时会以为听到了什么并尝试回答。可添加自定义指令规定听不清时的行为，按用途选择澄清或重复上一个问题。

• 何时使用：噪声、部分词语或静音触发了不必要回复。
• 作用：避免无根据响应，合理澄清。
• 适配：选择澄清或复问。

示例：咳嗽与不清楚的音频

来源示例 44（text）：

本例中文译文与说明：

不清楚的音频：听不清时仍用用户正在说的语言回应；只对清晰音频或文字作答。输入含糊、有背景噪声、静音、无法理解，或未完整听见、理解时，用 {preferred_language} 的短语澄清。

## Instructions/Rules
...


## Unclear audio
- Always respond in the same language the user is speaking in, if unintelligible.
- Only respond to clear audio or text.
- If the user's audio is not clear (e.g. ambiguous input/background noise/silent/unintelligible) or if you did not fully hear or understand the user, ask for clarification using {preferred_language} phrases.

gpt-realtime-1.5 示例：

打开原始音频

原示例中，讲话者大声咳嗽且音频不清楚，模型随后要求澄清。

背景音乐或声音

生成语音时，模型可能意外产生背景音乐、哼唱、节奏噪声或类似声音的伪影，影响清晰度、分散注意并降低专业感。以下指令可避免或减少这些现象。

• 何时使用：观察到不需要的音乐或音效。
• 作用：引导避免这些伪影。
• 适配：明确抑制实际遇到的声音模式。

示例

来源示例 45（text）：

本例中文译文与说明：

回复中不包含任何音效或拟声表达。

## Instructions/Rules
...
- Do not include any sound effects or onomatopoeic expressions in your responses.

工具

明确何时调用或不调用、收集哪些参数、运行时说什么，以及如何处理错误或部分结果。

工具选择

模型紧密遵循指令，但提示词提到未在工具列表提供的工具等能力冲突会导致不良回复。

• 何时使用：提示词引用实际不可用工具。
• 作用：审查工具与系统提示词保持一致。

示例

来源示例 46（text）：

本例中文译文与说明：

工具部分声明 lookup_account(email_or_phone) 与 check_outage(address)，其余省略号表示未展开的定义，不是完整实现。

## Tools
## lookup_account(email_or_phone)
...


## check_outage(address)
...

必须提供相同工具，且描述不能互相矛盾：

来源示例 47（json）：

本例中文译文与说明：

lookup_account：用邮箱或电话检索客户账户，支持身份验证及账户专属操作。check_outage：检查服务地址的网络故障，适用时返回状态与预计恢复时间。参数部分省略，原块不是完整JSON。

[
{
    "name": "lookup_account",
    "description": "Retrieve a customer account using either an email or phone number to enable verification and account-specific actions.",
    "parameters": {
      ...
  },
{
    "name": "check_outage",
    "description": "Check for network outages affecting a given service address and return status and ETA if applicable.",
    "parameters": {
      ...
  }
]

工具调用前的简短说明

某些场景希望模型调用工具时同时说一句话，以改善体验并掩盖等待感。示例短语可按场景改写。

• 何时使用：用户需要在调用发生时立即收到确认。
• 作用：工具调用前增加简短一致的说明。

示例

来源示例 48（text）：

本例中文译文与说明：

任何工具调用前先说一句简短说明，例如“我现在检查”，随后立即调用工具。

## Tools
- Before any tool call, say one short line like “I’m checking that now.” Then call the tool immediately.

应用后的回复：

模型调用工具的同时，会说“我正在检查”。

工具调用说明与示例短语

想更精确控制同时说出的内容，可在工具描述加入示例短语。

示例

来源示例 49（python）：

本例中文译文与说明：

lookup_account：按邮箱或电话取客户账户，以验证并处理账户操作。说明示例：“为安全起见，我用已保存邮箱调出账户。”“现在按{email}查账户。”“我正获取关联{phone}的账户以验证访问。”“稍等，正在打开账户详情。”参数为email、phone，不接受额外属性。
check_outage：检查给定服务地址的网络故障，适用时返回状态和预计恢复时间。说明示例：“现在检查{service_address}是否故障。”“我查看你所在区域的网络状态。”“我检查是否有影响该地址的活动故障。”“稍等，核实服务状态和已公布恢复时间。”service_address必填，不接受额外属性。

## [中文] 按原代码构造或处理这些事件：function、object、string；保留请求与服务端确认的区别。
tools = [
    {
        "type": "function",
        "name": "lookup_account",
        "description": """Retrieve a customer account using either an email or phone number to enable verification and account-specific actions.

Preamble sample phrases:
- For security, I’ll pull up your account using the email on file.
- Let me look up your account by {email} now.
- I’m fetching the account linked to {phone} to verify access.
- One moment—I’m opening your account details.""",
        "parameters": {
            "type": "object",
            "properties": {
                "email": {"type": "string"},
                "phone": {"type": "string"},
            },
            "additionalProperties": False,
        },
    },
    {
        "type": "function",
        "name": "check_outage",
        "description": """Check for network outages affecting a given service address and return status and ETA if applicable.

Preamble sample phrases:
- I’ll check for any outages at {service_address} right now.
- Let me look up network status for your area.
- I’m checking whether there’s an active outage impacting your address.
- One sec—verifying service status and any posted ETA.""",
        "parameters": {
            "type": "object",
            "properties": {
                "service_address": {"type": "string"},
            },
            "required": ["service_address"],
            "additionalProperties": False,
        },
    },
]

无需确认的工具调用

某些场景中，模型在显而易见的工具调用前反复请求确认，会降低主动性和体验。

• 何时使用：不必要的工具前确认。
• 作用：移除多余确认循环。

示例

来源示例 50（text）：

本例中文译文与说明：

调用工具时不要求用户确认，主动执行。

## Tools
- When calling a tool, do not ask for any user confirmation. Be proactive

应用后：

模型没有生成语音，直接调用对应工具。

如果调用太积极，可弱化措辞，例如将“proactive”等强词换得温和一些，引导较稳健的行为。

工具调用表现

场景和工具数量增加时，必须明确每个工具何时用、何时不用。清晰规则既提升准确性，也帮助选择正确时机。

• 何时使用：工具表现不佳，需要明确规则减少误用。
• 作用：增加使用与避免条件，也可说明顺序，例如 A 之后允许 B 或 C。

示例

来源示例 51（text）：

本例中文译文与说明：

调用任何工具时，必须同时回复告知用户。
lookup_account：验证身份或查看套餐、故障标记时使用；用户明确匿名且只问一般问题时不用。
check_outage：连接故障或网速慢时使用；纯账单问题不用。
refund_credit：过去7天已确认故障超过240分钟时使用；故障未确认先走Diagnose→check_outage。
schedule_technician：重启后仍反复失败且outage=false时使用；outage=true时不预约，而给状态及预计恢复时间。
escalate_to_human：严重沮丧、辱骂骚扰、反复失败、超过50美元账单争议，或用户要求升级时使用。

## Tools
- When you call any tools, you must output at the same time a response letting the user know that you are calling the tool.

## lookup_account(email_or_phone)
Use when: verifying identity or viewing plan/outage flags.
Do NOT use when: the user is clearly anonymous and only asks general questions.


## check_outage(address)
Use when: user reports connectivity issues or slow speeds.
Do NOT use when: question is billing-only.


## refund_credit(account_id, minutes)
Use when: confirmed outage > 240 minutes in the past 7 days.
Do NOT use when: outage is unconfirmed; route to Diagnose → check_outage first.


## schedule_technician(account_id, window)
Use when: repeated failures after reboot and outage status = false.
Do NOT use when: outage status = true (send status + ETA instead).


## escalate_to_human(account_id, reason)
Use when: user seems very frustrated, abuse/harassment, repeated failures, billing disputes >$50, or user requests escalation.

工具可能不可预测地失败时，增加明确失败处理指令，使回复自然得体。

工具级行为

可针对特定工具调整，而非套用全局规则。例如读取工具主动调用，写入工具要求明确确认。

• 何时使用：全局主动性、确认或开场说明不适合每个工具。
• 作用：逐工具定义立即调用、先确认或先说说明。

示例

来源示例 52（text）：

本例中文译文与说明：

工具级规则：PROACTIVE不先确认也不播报；CONFIRMATION FIRST总是先确认；PREAMBLES先说一句“我现在检查”等短句，随后立即调用。

lookup_account——PROACTIVE：验证身份或访问账单时使用；第二次询问后仍拒绝表明身份则不用。
check_outage——PREAMBLES：连接失败或速度低于10 Mbps时使用；纯账单或速度高于10 Mbps时不用；任一情况成立则告知无法协助并挂断。
refund_credit——CONFIRMATION FIRST：过去7天已确认故障超过240分钟时抵扣60分钟；未确认故障不用。确认：“可以为此次故障提供抵扣，要继续吗？”
schedule_technician——CONFIRMATION FIRST：重启和线路检查失败且outage=false时使用。时段为美国东部10am–12pm或2pm–4pm。确认：“可以安排技术人员上门，要帮你预约吗？”
escalate_to_human——PREAMBLES：骚扰、威胁、自伤、反复失败、超过50美元争议、用户沮丧或要求升级时使用。说明：“我为你连接能进一步协助的高级客服。”

## TOOLS
- For the tools marked PROACTIVE: do not ask for confirmation from the user and do not output a preamble.
- For the tools marked as CONFIRMATION FIRST: always ask for confirmation to the user.
- For the tools marked as PREAMBLES: Before any tool call, say one short line like “I’m checking that now.” Then call the tool immediately.


## lookup_account(email_or_phone) — PROACTIVE
Use when: verifying identity or accessing billing.
Do NOT use when: caller refuses to identify after second request.


## check_outage(address) — PREAMBLES
Use when: caller reports failed connection or speed lower than 10 Mbps.
Do NOT use when: purely billing OR when internet speed is above 10 Mbps.
If either condition applies, inform the customer you cannot assist and hang up.


## refund_credit(account_id, minutes) — CONFIRMATION FIRST
Use when: confirmed outage > 240 minutes in the past 7 days (credit 60 minutes).
Do NOT use when: outage unconfirmed.
Confirmation phrase: “I can issue a credit for this outage—would you like me to go ahead?”


## schedule_technician(account_id, window) — CONFIRMATION FIRST
Use when: reboot + line checks fail AND outage=false.
Windows: “10am–12pm ET” or “2pm–4pm ET”.
Confirmation phrase: “I can schedule a technician to visit—should I book that for you?”


## escalate_to_human(account_id, reason) — PREAMBLES
Use when: harassment, threats, self-harm, repeated failure, billing disputes > $50, caller is frustrated, or caller requests escalation.
Preamble: “Let me connect you to a senior agent who can assist further.”

工具输出格式

需逐字复述的长字符串等输出，可能与模型熟悉的数据分布差异较大。训练中常见的是带具名字段的 JSON；工具只返回原始字符串，再另要求“原样重复”，更容易被改写、截断或混入开场说明。

实用修正是让输出采用正常工具结果的结构，并以机器可识别方式明确逐字要求。

• 何时使用：多句指令、转交资料、ID或链接、政策摘要、多步流程等长或复杂内容发生截断、改述、字段丢失、重排或混入说明。
• 作用：用小型 JSON 封装，如 response_text 配合 require_repeat_verbatim、format 或 content_type，明确预期呈现行为。
• 适配：结构保持最小稳定。在工具指令和定义旁都明确说明，例如 require_repeat_verbatim 为真时只输出 response_text，不得添加、遗漏或重排。

示例

示例：原始字符串，更容易出错

工具返回：

来源示例 53（text）：

本例中文译文与说明：

刚发送了带验证链接的邮件，请打开并点击“Confirm（确认）”。

I just sent you an email with the verification link. Please open it and click “Confirm”.

模型可能将其改述成“我已发送验证链接”、漏掉最后一句，或额外说“还有什么需要帮助的吗？”

示例：JSON 封装，更常见且更可靠

工具返回：

来源示例 54（json）：

本例中文译文与说明：

response_text：“刚发送了带验证链接的邮件，请打开并点击Confirm。”require_repeat_verbatim=true要求原样复述该文本。

{
  "response_text": "I just sent you an email with the verification link. Please open it and click “Confirm”.",
  "require_repeat_verbatim": true
}

该结构类似正常工具结果，更便于模型识别权威内容 response_text、理解 require_repeat_verbatim 约束，并在不截断、不加说明的情况下复现输出。

改述监督工具：回应者与思考者架构

许多语音系统中，实时模型负责说话，较强文本模型负责规划、政策查询和标准流程。文本回答未必适合朗读，回应者应先改为适合音频的表达再生成语音。

• 何时使用：收到思考者结果后，口头表达机械、冗长或别扭。
• 作用：明确要求短、自然、优先适合说话的改述。
• 适配：调整措辞、开头和长度以符合产品。

示例

来源示例 55（text）：

本例中文译文与说明：

监督工具：getNextResponseFromSupervisor(relevantContextFromLastUserMessage: string)。
调用条件：允许清单外请求；任何事实、政策、账户或流程问题；可能需要内部查询或系统更改的动作。
不调用：简单问候闲聊；重复或澄清；为稍后监督工具收集参数，包括账户帮助的phone_number（getUserAccountInfo）、门店查询的zip_code（findNearestStore）、政策查询的topic或keyword（lookupPolicyDocument）。

使用规则：先说中性短语再立即调用，可用“稍等”“我查一下”“等一下”“给我一点时间”“我看看”“我了解一下”，不得暗示成功或失败。不要提“Supervisor”。相关上下文是最新消息的一行摘要，无显著信息用空字符串。工具返回后按下列改述规则回复。

改述：以简短、主动的口语开头衔接答案，如“谢谢等待”“刚查好了”“已调出资料”。最多两句；结构为开头+一句主旨+最多三个要点+简短确认或选项，如“和预期一致吗？”“要比较选项吗？”
数字适合朗读：$45.20自然读金额；电话按3-3-4分组；地址逐位读数字；日期时间清楚读，例如8月12日、下午3点半。

## Tools
## Supervisor Tool
Name: getNextResponseFromSupervisor(relevantContextFromLastUserMessage: string)


When to call:
- Any request outside the allow list.
- Any factual, policy, account, or process question.
- Any action that might require internal lookups or system changes.


When not to call:
- Simple greetings and basic chitchat.
- Requests to repeat or clarify.
- Collecting parameters for later Supervisor use:
  - phone_number for account help (getUserAccountInfo)
  - zip_code for store lookup (findNearestStore)
  - topic or keyword for policy lookup (lookupPolicyDocument)


Usage rules and preamble:
1) Say a neutral filler phrase to the user, then immediately call the tool. Approved fillers: “One moment.”, “Let me check.”, “Just a second.”, “Give me a moment.”, “Let me see.”, “Let me look into that.” Fillers must not imply success or failure.
2) Do not mention the “Supervisor” when responding with filler phrase.
3) relevantContextFromLastUserMessage is a one-line summary of the latest user message; use an empty string if nothing salient.
4) After the tool returns, apply Rephrase Supervisor and send your reply.


### Rephrase Supervisor
- Start with a brief conversational opener using active language, then flow into the answer (for example: “Thanks for waiting—”, “Just finished checking that.”, “I’ve got that pulled up now.”).
- Keep it short: no more than 2 sentences.
- Use this template: opener + one-sentence gist + up to 3 key details + a quick confirmation or choice (for example: “Does that match what you expected?”, “Want me to review options?”).
- Read numbers for speech: money naturally (“$45.20” → “forty-five dollars and twenty cents”), phone numbers 3-3-4, addresses with individual digits, dates/times plainly (“August twelfth”, “three-thirty p.m.”).

没有改述规则：“你的信用卡余额为正，32,323,232 AUD。”

有规则后：“刚查好了，你的信用卡有三千二百三十二万三千二百三十二澳元的贷方余额。最近一次付款在8月1日处理，和你预期一致吗？”

常用工具

gpt-realtime-1.5 接受过常用工具训练。需要相似行为时，名称、签名和描述尽量接近示例，以提高可靠性、接近熟悉分布。

示例

来源示例 56（text）：

本例中文译文与说明：

answer(question: string)：客户问自己无法回答的问题或要求执行操作时调用。
escalate_to_human()：客户要求升级、找其他人或表达对此通话不满时调用。
finish_session()：客户表示已完成或不愿继续时调用；有歧义先确认。

## answer(question: string)
Description: Call this when the customer asks a question that you don't have an answer to or asks to perform an action.


## escalate_to_human()
Description: Call this when a customer asks for escalation, or to talk to someone else, or expresses dissatisfaction with the call.


## finish_session()
Description: Call this when a customer says they're done with the session or doesn't want to continue. If it's ambiguous, confirm with the customer before calling.

对话流程

把对话划成清晰、目标明确的阶段，说明目的、指令及转向下一阶段的具体退出条件，避免停滞、跳步或过早推进，使问候到解决保持条理。

按状态组织也便于识别错误与迭代。

• 何时使用：对话混乱、未达目标就停滞，或难以完成任务。
• 作用：按目标、指令与退出条件划阶段。
• 适配：按流程重命名，调整行为，Exit when 保持具体简明。

示例

来源示例 57（text）：

本例中文译文与说明：

对话流程：
1. 问候：表明是NorthLoop Internet Support，简短开场并邀请说明目标，确认对方是Northloop客户。对方确认客户身份并说明目标或症状后进入探索。
2. 探索：用一个针对问题区分账单和连接。连接问题收服务地址，账单或账户收邮箱/电话。意图和对应字段清楚后退出。
3. 验证：有邮箱或电话就调用lookup_account。失败可尝试另一标识一次，否则给通用指导，需账户动作时提议升级。取得账户ID后退出。
4. 诊断：连接问题调用check_outage。outage=true跳过本地步骤，带故障信息进入解决；false则指导简短重启和接线检查，每步确认结果。根因明确后退出。
5. 解决：过去7天故障确认超过240分钟，用refund_credit(account_id,60)。outage=false且基础检查后仍不行，提供美国东部10am–12pm或2pm–4pm，调用schedule_technician。若本地修复成功，简短说明结果和下一步。修复/抵扣/预约已执行且客户知悉后退出。
6. 确认与结束：复述结果和稳定等待时间或技术人员预计到达等下一步，邀请最后问题，无则礼貌结束。客户拒绝更多帮助后退出。

## Conversation Flow
## 1) Greeting
Goal: Set tone and invite the reason for calling.
How to respond:
- Identify as NorthLoop Internet Support.
- Keep the opener brief and invite the caller’s goal.
- Confirm that customer is a Northloop customer
Exit to Discovery: Caller states they are a Northloop customer and mentions an initial goal or symptom.


## 2) Discover
Goal: Classify the issue and capture minimal details.
How to respond:
- Determine billing vs connectivity with one targeted question.
- For connectivity: collect the service address.
- For billing/account: collect email or phone used on the account.
Exit when: Intent and address (for connectivity) or email/phone (for billing) are known.


## 3) Verify
Goal: Confirm identity and retrieve the account.
How to respond:
- Once you have email or phone, call lookup_account(email_or_phone).
- If lookup fails, try the alternate identifier once; otherwise proceed with general guidance or offer escalation if account actions are required.
Exit when: Account ID is returned.


## 4) Diagnose
Goal: Decide outage vs local issue.
How to respond:
- For connectivity, call check_outage(address).
- If outage=true, skip local steps; move to Resolve with outage context.
- If outage=false, guide a short reboot/cabling check; confirm each step’s result before continuing.
Exit when: Root cause known.


## 5) Resolve
Goal: Apply fix, credit, or appointment.
How to respond:
- If confirmed outage > 240 minutes in the last 7 days, call refund_credit(account_id, 60).
- If outage=false and issue persists after basic checks, offer “10am–12pm ET” or “2pm–4pm ET” and call schedule_technician(account_id, chosen window).
- If the local fix worked, state the result and next steps briefly.
Exit when: A fix/credit/appointment has been applied and acknowledged by the caller.


## 6) Confirm/Close
Goal: Confirm outcome and end cleanly.
How to respond:
- Restate the result and any next step (e.g., stabilization window or tech ETA).
- Invite final questions; close politely if none.
Exit when: Caller declines more help.

示例短语

示例是风格、长度和语气的锚点，不必将模型锁死在单一句子。

• 何时使用：缺少品牌风格或表达不一致。
• 作用：给模型可变化的自然简短示例。
• 适配：替换为品牌适合措辞，保留“不必始终照用”的提醒。

示例

来源示例 58（text）：

本例中文译文与说明：

示例短语仅供灵感，不应始终照用，要变化表达。
确认：“正在处理。”“稍等。”“好问题。”
澄清：“选A还是B？”“截止时间是？”
衔接：“简短计划如下。”“我们简单处理。”
简短共情：“这让人烦恼，我们来解决。”
结束：“结束前还有其他事吗？”“下次也乐意帮忙。”

## Sample Phrases
- Below are sample examples that you should use for inspiration. DO NOT ALWAYS USE THESE EXAMPLES, VARY YOUR RESPONSES.

Acknowledgements: “On it.” “One moment.” “Good question.”
Clarifiers: “Do you want A or B?” “What’s the deadline?”
Bridges: “Here’s the quick plan.” “Let’s keep it simple.”
Empathy (brief): “That’s frustrating—let’s fix it.”
Closers: “Anything else before we wrap?” “Happy to help next time.”

如果总是复述示例而变机械，可加入表达多样性约束，官方观察其可改善问题。

对话流程与示例短语

在各状态添加示例，是展示良好回答形式的实用模式。

示例

来源示例 59（text）：

本例中文译文与说明：

对话流程与短语：示例不能始终重复，应变化表达。
1. 问候：表明NorthLoop Internet Support，简短邀请说明目标；用户提出初始目标或症状后退出。示例：“感谢致电，今天需要什么帮助？”“这里是NorthLoop支持，服务发生什么情况？”“你好，说说需要帮助的事。”
2. 探索：一个针对问题区分账单或连接；连接收地址，账单收邮箱/电话；意图与字段齐全后退出。示例：“关于账单还是网速？”“连接用的地址是？”“账户邮箱或电话是什么？”
3. 验证：有邮箱/电话后调用lookup_account；失败再尝试另一标识一次，否则给一般指导或为账户操作升级；返回账户ID后退出。示例：“谢谢，正查账户。”“没查到的话，另一个联系方式是邮箱还是电话？”“找到账户了，我处理。”
4. 诊断：连接问题调用check_outage；true跳过本地排查，false引导重启/接线并逐步确认；根因明确后退出。示例：“正检查区域故障。”“没有报告故障，试着快速重启调制解调器。”“网络指示灯常亮还是闪烁？”
5. 解决：过去7天确认故障超过240分钟，refund_credit(account_id,60)；无故障且基础排查后仍不行，提供美国东部10am–12pm或2pm–4pm并预约；本地修好则说明结果。修复/抵扣/预约执行并获客户知悉后退出。示例：“故障持续较久，现加60分钟账单抵扣。”“无故障，预约技术员可选上述两时段。”“抵扣已生效，下期账单可见。”
6. 确认结束：复述结果及下一步，问最后问题，无则礼貌结束；用户不再需帮助后退出。示例：“已全部处理：[抵扣/预约/恢复服务]。”“几分钟内网速应稳定。”“技术员时段为美国东部10am–12pm。”

## Conversation Flow
## 1) Greeting
Goal: Set tone and invite the reason for calling.
How to respond:
- Identify as NorthLoop Internet Support.
- Keep the opener brief and invite the caller’s goal.
Sample phrases (do not always repeat the same phrases, vary your responses):
- “Thanks for calling NorthLoop Internet—how can I help today?”
- “You’ve reached NorthLoop Support. What’s going on with your service?”
- “Hi there—tell me what you’d like help with.”
Exit when: Caller states an initial goal or symptom.


## 2) Discover
Goal: Classify the issue and capture minimal details.
How to respond:
- Determine billing vs connectivity with one targeted question.
- For connectivity: collect the service address.
- For billing/account: collect email or phone used on the account.
Sample phrases (do not always repeat the same phrases, vary your responses):
- “Is this about your bill or your internet speed?”
- “What address are you using for the connection?”
- “What’s the email or phone number on the account?”
Exit when: Intent and address (for connectivity) or email/phone (for billing) are known.


## 3) Verify
Goal: Confirm identity and retrieve the account.
How to respond:
- Once you have email or phone, call lookup_account(email_or_phone).
- If lookup fails, try the alternate identifier once; otherwise proceed with general guidance or offer escalation if account actions are required.
Sample phrases:
- “Thanks—looking up your account now.”
- “If that doesn’t pull up, what’s the other contact—email or phone?”
- “Found your account. I’ll take care of this.”
Exit when: Account ID is returned.


## 4) Diagnose
Goal: Decide outage vs local issue.
How to respond:
- For connectivity, call check_outage(address).
- If outage=true, skip local steps; move to Resolve with outage context.
- If outage=false, guide a short reboot/cabling check; confirm each step’s result before continuing.
Sample phrases (do not always repeat the same phrases, vary your responses):
- “I’m running a quick outage check for your area.”
- “No outage reported—let’s try a fast modem reboot.”
- “Please confirm the modem lights: is the internet light solid or blinking?”
Exit when: Root cause known.


## 5) Resolve
Goal: Apply fix, credit, or appointment.
How to respond:
- If confirmed outage > 240 minutes in the last 7 days, call refund_credit(account_id, 60).
- If outage=false and issue persists after basic checks, offer “10am–12pm ET” or “2pm–4pm ET” and call schedule_technician(account_id, chosen window).
- If the local fix worked, state the result and next steps briefly.
Sample phrases (do not always repeat the same phrases, vary your responses):
- “There’s been an extended outage—adding a 60-minute bill credit now.”
- “No outage—let’s book a technician. I can do 10am–12pm ET or 2pm–4pm ET.”
- “Credit applied—you’ll see it on your next bill.”
Exit when: A fix/credit/appointment has been applied and acknowledged by the caller.


## 6) Confirm/Close
Goal: Confirm outcome and end cleanly.
How to respond:
- Restate the result and any next step (e.g., stabilization window or tech ETA).
- Invite final questions; close politely if none.
Sample phrases (do not always repeat the same phrases, vary your responses):
- “We’re all set: [credit applied / appointment booked / service restored].”
- “You should see stable speeds within a few minutes.”
- “Your technician window is 10am–12pm ET.”
Exit when: Caller declines more help.

高级对话流程

复杂场景需要可扩展结构，同时平衡可维护性和简单性。过多僵硬状态会加重负担、降低表现并让对话机械。

应以结构化而灵活的状态减少模型感知复杂性，让它保持专注与响应。常用模式：

1. 把对话流程表示为状态机。
2. 通过 session.update 动态更改流程。

状态机式对话流程

用 JSON 编码状态和转换，方便检查覆盖、边界情况及变更。作为代码可版本管理、比较与扩展，并精细控制转换时机和方式。

示例

来源示例 60（json）：

本例中文译文与说明：

对话状态JSON示意（含标题、省略号和尾随逗号，不能直接作完整JSON解析）：
1_greeting：热情问候，表明Snowy Peak Boards并提供帮助，提前说明账户相关协助需验证。示例：“你好，这里是Snowy Peak Boards，感谢联系，今天能帮什么？”问候后转2_get_first_name；用户已给名字则转3_get_and_verify_phone。
2_get_first_name：只问名字，礼貌说“请问怎么称呼？”，不验证或拼读；已取得或已提供名字则转3_get_and_verify_phone。
3_get_and_verify_phone：礼貌问电话，逐位复述并确认，纠正后再次确认。示例：“访问账户还需一些信息，可以给电话吗？”“0-2-1-5-5-5-1-2-3-4，对吗？”“4-5-6-7-8-9-0-1-2-3，对吗？”确认后转4_authentication_DOB。其余状态省略。

## Conversation States
[
  {
    "id": "1_greeting",
    "description": "Begin each conversation with a warm, friendly greeting, identifying the service and offering help.",
    "instructions": [
        "Use the company name 'Snowy Peak Boards' and provide a warm welcome.",
        "Let them know upfront that for any account-specific assistance, you’ll need some verification details."
    ],
    "examples": [
      "Hello, this is Snowy Peak Boards. Thanks for reaching out! How can I help you today?"
    ],
    "transitions": [{
      "next_step": "2_get_first_name",
      "condition": "Once greeting is complete."
    }, {
      "next_step": "3_get_and_verify_phone",
      "condition": "If the user provides their first name."
    }]
  },
  {
    "id": "2_get_first_name",
    "description": "Ask for the user’s name (first name only).",
    "instructions": [
      "Politely ask, 'Who do I have the pleasure of speaking with?'",
      "Do NOT verify or spell back the name; just accept it."
    ],
    "examples": [
      "Who do I have the pleasure of speaking with?"
    ],
    "transitions": [{
      "next_step": "3_get_and_verify_phone",
      "condition": "Once name is obtained, OR name is already provided."
    }]
  },
  {
    "id": "3_get_and_verify_phone",
    "description": "Request phone number and verify by repeating it back.",
    "instructions": [
      "Politely request the user’s phone number.",
      "Once provided, confirm it by repeating each digit and ask if it’s correct.",
      "If the user corrects you, confirm AGAIN to make sure you understand.",
    ],
    "examples": [
      "I'll need some more information to access your account if that's okay. May I have your phone number, please?",
      "You said 0-2-1-5-5-5-1-2-3-4, correct?",
      "You said 4-5-6-7-8-9-0-1-2-3, correct?"
    ],
    "transitions": [{
      "next_step": "4_authentication_DOB",
      "condition": "Once phone number is confirmed"
    }]
  },
...

动态对话流程

根据当前状态实时更新系统提示词和工具，不一次暴露全部规则，只给活动阶段相关内容。达到结束条件后，用 session.update 替换下一阶段的提示词和工具。

这减少不必要上下文干扰，使复杂任务更易处理。

示例

来源示例 61（python）：

本例中文译文与说明：

允许状态：verify→resolve，resolve为终态（无后续状态）。状态工具set_conversation_state说明：切换对话阶段，当前为{current}；只能到{readable}，退出条件满足后才调用。
verify仅提供lookup_account，说明“按邮箱或电话取账户”，email_or_phone必填。resolve提供schedule_technician，说明“预约技术员上门”，account_id与window必填，时段枚举为10-12 ET、14-16 ET。
verify指令：验证身份以访问账户，问邮箱或电话，逐位回读如4-1-5并确认；返回账户ID后，调用set_conversation_state(next_state="resolve")。
resolve指令：通过预约技术员修复问题；提供美国东部10–12或2–4，预订用户选定时段；预约确认后礼貌结束。
build_session_update返回Realtime session.update载荷，包含当前阶段指令、业务工具与状态切换工具。

## [中文] 按原代码构造或处理这些事件：function、object、string、session.update、realtime；保留请求与服务端确认的区别。
from typing import Literal

State = Literal["verify", "resolve"]

## Allowed transitions
TRANSITIONS: dict[State, list[State]] = {
    "verify": ["resolve"],
    "resolve": [],  # terminal
}


def build_state_change_tool(current: State) -> dict:
    allowed = TRANSITIONS[current]
    readable = ", ".join(allowed) if allowed else "no further states (terminal)"
    return {
        "type": "function",
        "name": "set_conversation_state",
        "description": (
            f"Switch the conversation phase. Current: '{current}'. "
            f"You may switch only to: {readable}. "
            "Call this AFTER exit criteria are satisfied."
        ),
        "parameters": {
            "type": "object",
            "properties": {"next_state": {"type": "string", "enum": allowed}},
            "required": ["next_state"],
        },
    }


## Minimal business tools per state
TOOLS_BY_STATE: dict[State, list[dict]] = {
    "verify": [
        {
            "type": "function",
            "name": "lookup_account",
            "description": "Fetch account by email or phone.",
            "parameters": {
                "type": "object",
                "properties": {"email_or_phone": {"type": "string"}},
                "required": ["email_or_phone"],
            },
        }
    ],
    "resolve": [
        {
            "type": "function",
            "name": "schedule_technician",
            "description": "Book a technician visit.",
            "parameters": {
                "type": "object",
                "properties": {
                    "account_id": {"type": "string"},
                    "window": {"type": "string", "enum": ["10-12 ET", "14-16 ET"]},
                },
                "required": ["account_id", "window"],
            },
        }
    ],
}

## Short, phase-specific instructions
INSTRUCTIONS_BY_STATE: dict[State, str] = {
    "verify": (
        "# Role & Objective\n"
        "Verify identity to access the account.\n\n"
        "# Conversation (Verify)\n"
        "- Ask for the email or phone on the account.\n"
        "- Read back digits one-by-one (e.g., '4-1-5… Is that correct?').\n"
        "Exit when: Account ID is returned.\n"
        'When exit is satisfied: call set_conversation_state(next_state="resolve").'
    ),
    "resolve": (
        "# Role & Objective\n"
        "Apply a fix by booking a technician.\n\n"
        "# Conversation (Resolve)\n"
        "- Offer two windows: '10–12 ET' or '2–4 ET'.\n"
        "- Book the chosen window.\n"
        "Exit when: Appointment is confirmed.\n"
        "When exit is satisfied: end the call politely."
    ),
}


def build_session_update(state: State) -> dict:
    """Return the JSON payload for a Realtime `session.update` event."""
    return {
        "type": "session.update",
        "session": {
            "type": "realtime",
            "instructions": INSTRUCTIONS_BY_STATE[state],
            "tools": TOOLS_BY_STATE[state] + [build_state_change_tool(state)],
        },
    }

安全与升级处理

语音智能体通常需要可靠的人工转接途径。应按应用修改何时升级的指令。

• 何时使用：模型难以判断转人工或回退时机。
• 作用：定义快速可靠的升级及所需措辞。
• 适配：设定自己的阈值与话术。

示例

来源示例 62（text）：

本例中文译文与说明：

安全与升级：以下情况不再额外排错，直接升级：自伤、威胁、骚扰等安全风险；明确要求人工；严重不满、反复投诉或脏话；同任务工具失败2次，或连续3次无匹配/无输入；超范围或受限请求，如实时新闻、财务/法律/医疗建议。
调用escalate_to_human的同时，必须说：“谢谢耐心等待，正在为你连接专员。”随后调用工具。
例子：“这是第三次重置失败，直接给我找个人。”“我非常沮丧！”

## Safety & Escalation
When to escalate (no extra troubleshooting):
- Safety risk (self-harm, threats, harassment)
- User explicitly asks for a human
- Severe dissatisfaction (e.g., “extremely frustrated,” repeated complaints, profanity)
- **2** failed tool attempts on the same task **or** **3** consecutive no-match/no-input events
- Out-of-scope or restricted (e.g., real-time news, financial/legal/medical advice)

What to say at the same time as calling the escalate_to_human tool (MANDATORY):
- “Thanks for your patience—I’m connecting you with a specialist now.”
- Then call the tool: `escalate_to_human`

Examples that would require escalation:
- “This is the third time the reset didn’t work. Just get me a person.”
- “I am extremely frustrated!”

第一幅展示 gpt-4o-realtime-preview-2025-06-03：

第二幅展示 gpt-realtime-1.5：

后者更可靠地遵循指令并转交人工。

后续步骤

GPT-Live：

• 阅读委派与工具，了解后端提示词及应用负责的上下文。
• 通过 WebRTC 或 WebSockets 连接，电话接入见 SIP。
• 从对话质量和已验证任务结果两方面评估语音智能体。

Realtime：

• 阅读较早的 Realtime 提示词指南获取更多 1.5 示例。
• 用 Realtime 评估指南测试代表性行为。
• 通过 WebRTC、WebSockets 或 SIP 连接。
• 了解会话生命周期，复核 Realtime 费用。