指令配置与使用说明

1. 概览

语音机器人在与客户对话时，除了输出自然语言回复外，还可以在模型返回内容中嵌入指令，以触发系统执行对应动作。对实施人员来说，可以先把这些指令理解成四类配置工具:

• 井号指令：通过 #...# 的形式触发流程类动作，让通话从当前智能体节点跳出，进入语音导航中对应指令节点连接的后续 IVR 节点。
• DTMF 指令：通过 DTMF{...} 或 DTMF_INTERRUPT{...} 的形式触发按键采集，适合验证码、单号、密码等需要客户手动按键输入的场景。
• variable 指令：通过 variable{...} 的形式提取变量，并传递给后续 IVR 节点使用。
• EXT_CMD 指令：通过 EXT_CMD{key:value;key:value} 的形式向状态机传递扩展控制参数，适合控制一轮播音是否允许被打断、播音保护时长等状态机侧逻辑。

这些指令的共同点是: 都由智能体在模型输出阶段直接返回，由系统识别并自动执行。不同点在于，它们解决的问题不同: 有的负责让流程跳出智能体并进入下一个 IVR 节点，有的负责在当前对话中采集按键信息，有的负责把识别结果写入变量，供后续节点继续使用。

---

2. 使用方式总览

在实际配置时，建议按以下顺序理解和使用指令：

• 先明确要解决的是流程跳转、辅助动作执行，还是变量传递。
• 再在智能体提示词中约束模型在满足条件时输出正确指令。
• 若该指令依赖节点侧能力，例如转人工、变量提取或后续直呼，还需同步完成呼叫中心或 IVR 节点配置。
• 上线前务必在真实联调环境中验证指令是否被正确识别、是否会被 TTS 播报、以及后续动作链路是否可达。

实施顺序

按“先配置智能体，再配置语音导航节点，最后检查 IVR 连线”的顺序实施，最不容易漏项：

1. 配置智能体：在智能体提示词中明确触发条件、输出格式和限制条件，让模型在需要时稳定返回目标指令。
2. 配置语音导航智能体节点：根据指令类型，在语音导航的智能体节点中补齐变量、预置动作等节点级配置。不是所有指令都需要这一步，但井号指令和 variable 指令通常都离不开节点配置。
3. 配置语音导航 IVR 连线：凡是会让流程跳出当前智能体节点的指令，都必须在画布上补齐下一跳；否则即使模型输出了指令，流程也可能无法继续执行。
4. 完成联调验收：同时检查四件事: 模型有没有按约定输出、TTS 有没有把指令播出来、节点动作有没有生效、后续节点有没有拿到正确结果。

配置矩阵

---

3. 井号指令

井号指令采用 #...# 的语义化格式，适合处理“当前这轮对话已经不该继续留在智能体里了”的场景。系统识别到井号指令后，会跳出当前智能体节点，进入语音导航中与该指令对应的 IVR 节点，并继续执行这个节点连接的下一个 IVR 节点。

例如，智能体输出 #转人工# 后，流程不会继续停留在当前智能体里，而是会进入 #转人工# 对应的节点，再沿着该节点连线进入后续节点，例如呼转座席、排队队列或其他人工服务流程。

配置方式

井号指令通常需要同时完成三部分配置，缺一不可：

• 智能体提示词配置：在满足条件时，要求模型在回复末尾输出对应的井号指令。
• 语音导航智能体节点配置：在智能体节点中确认预置动作标识与模型输出一致。
• IVR 连线配置：在语音导航中提前配置好该指令对应的下一跳，确保流程跳出智能体后有明确去向。

完整配置流程

第一步：配置智能体

在智能体搭建页面的提示词中，建议至少在主流程或全局语境中写清三件事：

• 什么情况下触发井号指令，例如客户要求转人工、对话正常结束、客户明确拒绝等。
• 触发后必须输出什么内容，例如 #转人工#、#挂机#。
• 井号指令必须放在句末，且 # 前不要再加额外标点，避免系统识别失败。

可参考这样的约束方式：

• 当用户要求人工客服时，回复“好的，请您稍等#转人工#”。
• 当对话结束需要挂机时，回复“再见#挂机#”。
• 如果项目使用自定义标识，例如 #转人工客服#，则智能体、节点和连线三处都必须统一为同一写法。

第二步：配置语音导航智能体节点

进入 语音导航-智能体节点 后，重点检查 预置动作：

• 挂机、转人工通常属于预置能力，动作本身一般无需重新开发，但节点侧必须保证和智能体输出的标识一一对应。
• 对于转人工类动作，建议同步确认该下一跳是否需要开启转人工意图统计，以便后续在报表中识别是否真正发生了转人工。
• 如果使用的是自定义井号标识，也要确保节点侧存在同名动作或同名下一跳配置。

第三步：配置语音导航 IVR 连线

保存智能体节点后，画布上会出现与井号指令对应的下一跳出口。此时要继续完成连线：

• #转人工# 一般连接到人工队列、人工节点或其他人工承接链路。
• #挂机# 一般连接到挂断节点；如果还需要先播放一段固定录音，也可以先连到播放节点，再从播放节点结束通话。
• 自定义井号指令则应连接到对应的业务分支节点。

这里有一个高频问题：如果只配了提示词，没有配置 IVR 下一跳，模型虽然会输出井号指令，但流程跳出智能体后可能直接挂断，或者停在错误链路上。

第四步：联调验收

井号指令上线前，至少验证以下项目：

• 模型是否稳定输出了正确的井号指令。
• 指令本身是否没有被 TTS 播报给客户。
• 智能体节点是否真的触发了对应的预置动作。
• IVR 画布上的下一跳是否真的进入了目标节点，而不是停在空连线或错误节点。

建议遵循以下做法：

• 井号指令放在一句回复的结尾，避免插入到句中。
• 指令前的自然语言会正常播报，指令本身不应被播报给客户。
• 指令写法需与 IVR 侧配置保持一致，否则流程可能无法跳到预期节点。
• 联调时不要只测“模型有没有输出指令”，还要检查“输出后有没有真的跳到连线后的 IVR 节点”。

挂机指令

挂机指令适合在通话已经没有继续必要时使用。它的价值不只是“结束通话”，更重要的是让流程从智能体节点跳出，进入挂断相关的 IVR 节点或直接结束当前链路。

常见写法

• #挂机#
• 部分项目中也可能使用 #挂断#，实际应以呼叫中心中配置的预置动作标识为准。

作用

• 结束已完成的通话，避免无意义等待或占线。
• 在客户明确拒绝、无继续沟通价值时做礼貌收尾。

配置方式

1. 在智能体提示词中约束模型：当满足结束通话条件时，在回复末尾输出挂机指令，并要求 #挂机# 前不要再加额外标点。
2. 在 语音导航-智能体节点-预置动作 中确认已使用“挂机/挂断”对应的预置动作标识。
3. 保存节点后，在 IVR 画布上把 #挂机# 对应的下一跳连接到挂断节点；如需先播报固定录音，可先连播放节点，再结束通话。
4. 联调时确认机器人礼貌结束语会正常播报，但 #挂机# 本身不会被播报。

示例

不好意思打扰您了，再见#挂机#

使用场景

• 回访结束，客户已完成评价或确认，不需要再继续追问。
• 外呼营销中客户明确拒绝，且无需再进入人工处理。
• 通知类场景中，核心信息已播报完成，希望礼貌收尾后结束通话。

建议做法

• 建议将挂机指令放在句末，且不要在指令前继续追加多余标点，以免影响识别。
• 若项目已统一使用 #挂断#，则应在提示词、预置动作和文档中保持一致，不建议混用。

转人工指令

转人工指令适合在机器人已经无法继续高效承接时使用。它的核心作用不是单纯输出一句“为您转人工”，而是让流程从当前智能体节点跳出，进入 #转人工# 对应的 IVR 节点，再沿着该节点的连线进入人工座席、人工队列或其他人工承接流程。

常见写法

• #转人工#

作用

• 承接复杂诉求、投诉、强异议等超出机器人能力范围的问题。
• 在客户强烈要求人工客服时及时转接，减少流失与负面体验。

配置方式

1. 在智能体提示词中约束模型：当用户表达转人工意图，或命中某些兜底条件时，在回复末尾输出 #转人工#。
2. 在 语音导航-智能体节点-预置动作 中确认转人工属于已启用的预置动作，并保证节点中的动作标识与模型输出完全一致。
3. 如项目需要统计真实转人工，可同步开启转人工意图相关配置，避免后续报表难以区分“说了转人工”和“真的转到了人工”。
4. 保存节点后，在 IVR 画布上把 #转人工# 的下一跳连接到正确的人工队列、人工节点或人工承接流程；如果不连线，动作触发后可能直接挂断。
5. 联调时除验证模型输出外，还要实际检查人工链路是否可达、是否进入了正确队列。

示例

好的，请您稍等，我这边为您转接人工客服#转人工#

使用场景

• 客户主动要求“转人工”“找客服”“找专员”。
• 机器人多轮澄清后仍无法解决问题，继续停留在智能体里只会拉长对话。
• 涉及投诉、退款、异常处理等需要人工介入的场景。

建议做法

• 转人工前建议增加一小段安抚性播报，提升体验。
• 上线前务必确认 #转人工# 连线后的目标已经配置完成，否则模型虽然输出了指令，流程也可能跳不进真正的人工承接链路。
• 如需做报表统计，建议同步开启转人工意图或相关标记能力。

---

4. DTMF 指令

DTMF 指令用于在通话过程中触发按键采集。它适合处理语音机器人不便直接通过自然语言完成的信息收集，例如验证码、物流单号、手机号、证件号或密码输入等。

与井号指令不同，DTMF 指令不会让流程跳出当前智能体节点，而是在当前对话链路中触发一次按键采集动作。按键采集完成后，系统会将结果以文本形式返回给模型，继续后续对话。

配置方式

DTMF 指令通常通过智能体提示词配置，节点侧一般无需额外开启独立功能开关。可按以下顺序配置：

1. 配置智能体：在提示词中告诉模型，当需要客户通过电话键盘输入信息时，输出指定格式的 DTMF{...} 指令，并明确每种场景对应的参数。
2. 检查语音导航智能体节点：该功能默认可用，通常不需要在节点上额外开启独立开关，也不需要新增预置动作。
3. 确认 IVR 连线：DTMF 不会让流程跳出当前智能体节点，因此一般不需要新增 IVR 连线。收号完成后，结果会直接作为文本消息返回给当前对话。
4. 完成联调：验证收号成功、收号失败、超时重播、客户按 # 提前结束、加密显示等完整链路。

DTMF 指令

DTMF 指令用于发起标准的按键采集。

格式

DTMF{位数|超时时间|超时提示音|重播次数|是否加密}

示例

DTMF{6|5|您没有按啊，可以再按一次吗|2|0}

参数说明

作用

• 让客户通过电话键盘直接输入结构化信息。
• 减少口述数字时 ASR 识别不准的问题。
• 在敏感信息场景中，通过加密能力保护客户隐私。

执行规则

• 用户按 # 键可提前结束收号，不必等到达到指定位数。
• 当按键达到指定位数时，系统会自动结束收号。
• 收号成功后，系统会将按键内容作为文本消息回传给模型。
• 若开启加密，日志和记录中的按键内容会按密文展示。

使用场景

• 输入短信验证码、防伪码、物流单号。
• 输入会员号、手机号后几位、证件号片段。
• 输入密码、授权码等不适合直接口述的敏感内容。

建议做法

• 若业务要求客户输入敏感信息，建议默认开启加密。
• 超时提示音尽量简短直接，例如“没有收到您的按键，请再输入一次”。
• 首次联调建议先用位数较少、流程简单的测试样例验证整条链路。

DTMF_INTERRUPT 指令

DTMF_INTERRUPT 指令与 DTMF 的参数规则一致，但支持在收号过程中被用户语音打断。它更适合对话连续性要求较高的场景，即客户在按键时如果突然开口，系统可以根据打断判定结果决定是继续收号，还是退出收号并回到常规对话。

格式

DTMF_INTERRUPT{位数|超时时间|超时提示音|重播次数|是否加密}

作用

• 在保留按键采集能力的同时，让客户仍可通过说话打断流程。
• 避免客户“边想边说”时被完全锁死在收号状态中。

使用场景

• 客户可能一边听指引、一边尝试输入，但又可能随时发问的场景。
• 收号过程较长，客户容易中途确认“我输错了怎么办”“这个是按哪几个数字”的场景。

与 DTMF 的区别

• DTMF 更适合流程稳定、希望客户专注完成输入的场景。
• DTMF_INTERRUPT 更适合强调交互自然度，希望客户说话后仍能立即回到常规对话的场景。

建议做法

• 若业务更看重输入过程的稳定性，优先使用 DTMF。
• 若业务更看重自然交互体验，且允许客户中途打断，优先使用 DTMF_INTERRUPT。
• 上线前建议重点验证“先说话后按键”“先按键后说话”“超时播报时插话”等边界场景。

---

5. variable 指令

variable 指令用于在对话中提取结构化变量，并将其传递给后续 IVR 节点或动作节点使用。它适合解决“模型已经识别出某个业务结果，但后续流程还需要继续使用这个结果”的问题。

例如，机器人已经和客户确认了所属门店、目标城市、业务类型或热线号码，这些信息如果只停留在自然语言回复里，后续节点无法直接消费；使用 variable 指令后，系统即可将这些信息写入变量，并在下一个节点中继续引用。

配置方式

variable 指令通常需要同时完成三部分配置：

• 提示词配置：告诉模型在满足条件时按固定格式输出变量。
• 节点配置：在智能体节点中开启变量提取能力，并填写变量名称。
• 后续节点配置：在直呼、分流、查询等后续节点中引用该变量。

完整配置流程

第一步：配置智能体

在智能体提示词中，除了告诉模型“要提取什么变量”，还要明确“什么时候输出变量、变量名是什么、输出格式是什么”。建议同时写清：

• 触发条件，例如“当客户已确认广场名称时，返回广场变量”。
• 固定格式，例如 variable{name:mall_name;content:上海五角场万达广场}。
• 变量名必须与节点侧配置完全一致。

第二步：配置语音导航智能体节点

进入 语音导航-智能体节点-变量 后，按以下顺序配置：

1. 打开变量提取能力。
2. 新增变量，并填写变量名称。
3. 变量名必须与模型返回的 name 完全一致，只有一致时系统才会把该值写入 IVR 变量。
4. 如当前节点还需要把已有变量传给智能体，也要同步检查节点中的变量映射是否正确。

第三步：配置后续 IVR 节点或连线

variable 指令本身不会单独生成一个新的跳转出口，但它的价值在于让后续节点可以直接消费该变量。因此，实施时还要继续检查后续链路：

• 如果下一步是直呼节点，可将直拨值直接设置为该变量。
• 如果下一步是分流、查询或其他业务节点，也应确认这些节点引用的变量名与提取结果一致。
• 如果变量值为中文，在某些后续节点中可能需要先做解码，例如 {URIDECODE(${number})}。

第四步：联调验收

variable 指令至少要验证三件事：

• 模型返回消息中确实携带了变量结构。
• TTS 没有把 variable{...} 这段结构直接播报出来。
• 后续节点已经成功拿到变量值，而不是空值或错误值。

格式

variable{name:变量名;content:变量值}

示例

variable{name:mall_name;content:上海五角场万达广场}

作用

• 将对话中识别到的业务结果转成结构化变量。
• 让后续节点直接使用这些结果，而不必重新让客户描述一次。
• 支持复杂分流、精准直呼、个性化查询等后续动作。

使用场景

• 客户确认要咨询的是哪一个城市、门店、广场或校区，后续要按该结果直呼对应热线。
• 机器人收集到报修内容、预约日期、业务类型后，需要传递给后续流程节点。
• 机器人识别出某个分类结果，后续要根据该结果走不同分支。

配置要点

• name 和 content 中的分隔符应使用英文冒号 : 与英文分号 ;。
• 节点侧配置的变量名称需与模型返回的变量名称保持一致，否则系统可能不会写入变量。
• 后续节点若直接消费中文变量值，部分情况下可能需要做解码处理。
• 变量内容属于结构化结果，不应直接播报给客户。

建议做法

• 变量名尽量使用业务可读、便于后续维护的命名方式，例如 mall_name、city、service_type。
• 一次只提取当前流程真正需要的变量，避免让模型输出过多无关字段。
• 联调时应同时检查三项结果：模型是否正确输出变量、TTS 是否未播报变量结构、后续节点是否成功取值。

---

6. EXT_CMD 指令

如果您把 variable 理解成“把结构化结果写给呼叫中心底层变量”的工具，那么 EXT_CMD 更适合理解成“把扩展控制参数写给状态机做逻辑判断”的工具。它的核心用途不是传业务字段，也不是发起收号，而是让模型在输出文本时顺带告诉状态机：这一轮播音能不能被打断、需要保护多久。

当前 EXT_CMD 已明确支持的 key 主要围绕“播音打断控制”展开，因此它常见于模型生成开场白、工具调用提示音、普通模型回复文本，以及带有 #转人工# 的播报话术等场景。

格式

EXT_CMD 的写法与 variable 很像，都是 KV 结构：

EXT_CMD{key1:val1;key2:val2}

格式说明

• 必须以 EXT_CMD{ 作为前缀，以 } 作为后缀。
• 必须按照 KV 形式设置参数。
• K 和 V 之间可使用中文冒号 ： 或英文冒号 :。
• 多个 KV 之间可使用中文分号 ； 或英文分号 ;。

EXT_CMD 和 variable 的区别

两者虽然长得像，但用途不同：

• variable：把结构化变量写给呼叫中心底层变量，供后续节点、连线或业务字段继续使用。
• EXT_CMD：把扩展控制参数写给状态机，供状态机做逻辑判断。

这里要特别注意一个限制：只有程序逻辑中已经硬编码支持的 key，EXT_CMD 才会真正生效。 模型即使输出了未被支持的 key，状态机也不会按它执行。

生效范围

EXT_CMD 当前只对模型输出的文本生效，不能直接控制模型输出中的其他动作或事件。

例如：

请按键输入您的验证码。DTMF{||||}，按井号结束。EXT_CMD{interrupt:true}

其中：

• EXT_CMD{interrupt:true} 控制的是“请按键输入您的验证码，按井号结束”这一轮文本播音是否允许被打断。
• 当这段文本播音结束、系统进入 DTMF 按键采集动作后，这条 EXT_CMD 会随即失效。

当前已支持的 key

interrupt

• false：这一轮模型输出的文本播音不允许被打断。
• true：这一轮模型输出的文本播音允许被打断。

play_protect

• 单位是毫秒，从开始播音时开始计算。
• 在 interrupt=false 的场景下不会生效。
• 取值范围按 value <= 30000 处理：
• <= 0 表示播音保护不生效。
• > 30000 按 30000 处理。

推荐写法

常见写法例如：

• EXT_CMD{interrupt:true}
• EXT_CMD{interrupt:false}
• EXT_CMD{interrupt:true;play_protect:4000}

如果项目对流式输出的时序比较敏感，建议让模型尽量尽早输出 EXT_CMD，否则在流式识别到该指令之前，已播出的前半段文本仍按默认规则处理。

场景一：作用于普通模型输出

这是 EXT_CMD 最基础的使用场景。

• interrupt=true：属于默认可打断场景，一般无需特别说明。
• interrupt=false：表示这一轮模型输出文本在播放期间不允许被打断。

需要注意流式识别的时序：

• 对普通模型输出，EXT_CMD 是在流式返回过程中被识别的。
• 如果识别到 EXT_CMD 时，这轮播音已经开始了 1s，那么：
• 0-1s 仍允许被打断，因为这时扩展指令尚未被识别到。
• 1s-播音结束 按 EXT_CMD 的控制逻辑生效。

play_protect 作用于普通模型输出

当 play_protect=4000，且状态机识别到 EXT_CMD 时已经播了 1s，实际效果是：

• 0-1s：允许被打断，因为此时扩展指令尚未生效。
• 1-4s：不允许被打断。

场景二：作用于工具调用提示音

interrupt 也可作用于工具调用提示音。

• interrupt=true：工具调用提示音允许被打断，属于默认场景。
• interrupt=false：工具调用提示音播放期间不允许被打断。

其生效和失效时点要单独理解：

• 生效：模型流式输出返回工具调用事件、同时开始播放提示音时生效。
• 失效：最晚不会超过以下两个时间点中的较晚者：
• 工具调用事件之后，模型持续输出并返回第一个文本断句的时间点。
• 工具调用提示音播音结束的时间点。

场景三：作用于开场白

模型生成开场白只是 EXT_CMD 的一个使用场景，不应被理解成独立于 EXT_CMD 之外的新指令体系。

在 语音导航-智能体节点-对话启动 中，开场白有两种模式：

• 固定开场白：开场白内容由节点页面直接配置。
• 模型生成开场白：开场白内容由模型生成，节点页主要负责选择模式和配置公共开关。

其中，下面两个配置仍然在节点页面生效：

• 接通延时播报：控制接通后何时发起首个开场白请求。
• 开场白优先播报：控制系统是否优先保障开场白作为首轮播报内容。

interrupt 作用于开场白

• interrupt=true：属于默认可打断场景，一般无需单独强调。
• interrupt=false：表示开场白在播放期间不允许被打断。

生效逻辑如下：

• 固定开场白：从播音开始到播音结束，都不允许打断。
• 模型开场白：从识别到这条 EXT_CMD 开始，直到播音结束，都不允许打断。

也就是说，对模型开场白仍然要考虑流式识别时序。在 EXT_CMD 被识别之前，已播出的部分仍按默认规则处理。

play_protect 作用于开场白

• 固定开场白：从播音开始到 play_protect 计时结束期间，不允许被打断。
• 模型开场白：从识别到这条 EXT_CMD 开始生效，但它生效的保护区间仍按“从播音开始到 play_protect 结束”来计算。

例如，当模型开场白配置 play_protect=4000，但识别到 EXT_CMD 时已经播了 1s，实际效果是：

• 0-1s：允许被打断，因为扩展指令尚未被识别到。
• 1-4s：不允许被打断。

场景四：作用于 #转人工# 播报文本

这里有一个历史兼容点需要单独说明。

过去针对呼入机器人，对出现 #转人工# 的对话做过硬编码处理，默认这一轮播音不允许被打断；但这不符合外呼机器人的默认需求，因此状态机会根据业务标识做区分：

• 呼入机器人：默认仍不允许被打断。
• 外呼机器人：默认允许被打断。

如果需要覆盖默认行为，可在 #转人工# 后追加 EXT_CMD：

• 呼入机器人需要允许打断：
• 正在为您转接人工服务#转人工#，请稍等。EXT_CMD{interrupt:true}
• 外呼机器人需要禁止打断：
• 正在为您转接人工服务#转人工#，请稍等。EXT_CMD{interrupt:false}

这里有一个高频注意事项：不要把 #转人工# 放在句首，否则流程会立即转人工，后面的播报文本无法按预期执行。

配置建议

在实际配置 EXT_CMD 时，建议按“提示词约束 -> 场景核对 -> 联调验证”的顺序实施：

• 提示词约束：明确什么场景需要输出 EXT_CMD，输出哪些 key，参数值应该是什么。
• 场景核对：先确认当前控制的是普通模型输出、工具调用提示音、开场白，还是带 #转人工# 的播报文本。
• 联调验证：重点验证指令是否被系统识别、是否未被 TTS 播报、以及打断行为是否与预期一致。

建议重点检查以下边界情况：

• EXT_CMD 写在过后位置，导致前半句已按默认规则播出。
• play_protect 取值超范围，实际被裁剪或不生效。
• 带 #转人工# 的话术放在句首，导致流程立即跳走。
• 误把 EXT_CMD 当作业务变量写入，或误以为它能控制 DTMF / #转人工# 这类动作本身。

7. 配置建议

为了让指令能力既稳定又自然，建议在实施过程中遵循以下原则：

• 先明确目标，再选指令类型：要结束流程时使用井号指令；要收号时使用 DTMF / DTMF_INTERRUPT；要传递结构化结果时使用 variable；要控制状态机侧的播音逻辑时使用 EXT_CMD。
• 提示词必须写清触发条件：不要只告诉模型“可以用这个指令”，而要明确“在什么情况下必须输出该指令”。
• 动作链路要前后联调：很多指令本身只是触发器，真正能否落地，还取决于预置动作、下一跳、变量引用或状态机是否支持对应 key。
• 重点验证边界场景：例如转人工失败、收号超时、变量名不一致、开场白被意外跳过、EXT_CMD 生效时点晚于预期等，都应在上线前提前压测。
• 文档和配置口径保持一致：如果项目使用 #挂机#，就不要在提示词中写 #挂断#；如果变量名使用 mall_name，节点和后续引用中也应保持一致。

通过合理使用这些指令，企业可以在保持语音交互自然流畅的同时，更精准地控制通话流程、收集结构化信息，并与后续业务链路高效联动。