> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # 语音代理开发：将提示视为状态机 - URL: https://www.hubwiz.com/blog/build-voice-agents-treat-prompts-like-state-machines/ - Published: 2025-12-28T03:23:40.000Z - Updated: 2025-12-28T03:23:40.000Z - Description: 本文介绍如何通过将提示视为有限状态机（FSM）解决实时语音API的提示遵循问题。 - Author: admin - Tags: AGENT, STATE MACHINE, #Import 2026-10-14 14:41 实时语音LLM对于自然的对话非常棒，但存在权衡：如果坚持严格的确定性（精确脚本），就会失去流畅性；如果放任不管，就可能产生不可预测或不合规的回复。 实用的中间路径是将你的对话提示和流程设计为显式的FSM风格规范：简短的NLG模板 + 类型实体 + 验证器 + 小的、显式的状态转换 + 边界情况处理程序。这将LLM变成语言层，而一个简单的策略（FSM）则作为可靠的控制平面。 本文面向产品经理、工程师和设计师，他们正在构建语音代理（电话机器人、通话中的助手、演示流程），希望以一种实用且非技术的方式让实时LLM语音代理遵循所需的脚本，同时不会破坏自然性。 快速、通俗易懂的背景知识： - 实时语音LLM（流式音频输入→流式音频输出）让你可以与用户进行低延迟的双向口语对话。这使得交互感觉真实——而且错误会立即被听到。 - LLM是概率性的：它们生成合理的语言，但不能保证精确的句子。模型设置或环境的微小变化可能会改变输出。 - FSM很简单：可以想象成一个简短步骤的地图（状态）。每个状态说明了基于前一个回复（条件）代理应该说什么（动作）、它需要从用户那里收集什么，以及哪些用户回复会将其带入下一步。结合简短的模板和验证器，这是可读、可测试和可预测的。 ![](https://www.hubwiz.com/blog/content/images/2025/12/image-377.png) 问题的三句话总结： 1. 有些步骤必须逐字执行，出于法律/合规原因或完成业务操作。 2. LLM有时会偏离精确措辞或在中断后选择错误分支。 3. 团队花费太多时间手动迭代提示以使其“稳定”——这很慢且脆弱。 ## 1、提示即FSM 创建一个简短、人类可读的“对话规范”，包含： a) 状态（简短的命名步骤） 每个状态指定： - 代理说什么（简短模板，1-2句话）。 - 它需要捕捉什么（例如，会议时间、同意与否）。 - 哪些用户意图会带你进入哪个下一个状态（例如，用户给出时间 → 确认；用户说不感兴趣 → 结束）。 b) 实体（类型槽位） 你收集的信息片段（日期时间、语言、布尔值）。定义友好的口语格式和标准机器格式（例如，“星期四，6月5日下午3点IST” vs ISO日期时间）。 c) 验证器和规范化器 简单规则说明“这看起来像有效的会议时间”或“这太模糊了，再问一次”。 d) NLG模板 代理说话的简短、标记模板。将模板标记为严格用于合规关键文本，或在允许改述时标记为软。 e) 边界情况处理程序 快速行为用于语言切换、中断、模糊回答或退出。 f) 接受标准 成功对话的简单检查清单（例如，“会议时间已捕获并确认”）。 ``` # example_fsm_spec.yaml domain: "appointment_booking_voice_agent" meta: description: "适用于实时音频中简短预订对话的初学者友好型FSM规范。" base_language: "en-US" supported_languages: ["en-US", "hi-IN", "mr-IN", "te-IN", "kn-IN"] voice_profiles: ["neutral_male", "neutral_female"] entities: - name: customer_name type: string required: false spoken_format: "{{ customer_name }}" - name: language_preference type: string required: true value: "en-US" allowed_values: ["en-US", "hi-IN", "mr-IN", "te-IN", "kn-IN"] - name: meeting_time type: datetime required: false canonical_format: "ISO-8601" spoken_format: "Thursday, June 5 at 3 PM IST" - name: consent_call type: boolean required: true default: true validators: - name: time_parser description: "检测明确的时间并标记模糊的时间。" pattern: "(?i)(tomorrow|today|\\b\\d{1,2}(:\\d{2})?\\s?(am|pm)?\\b)" rule: "如果明确时间 -> 规范化为ISO；如果模糊 -> 标记为'vague_time'。" intents: - id: greet examples: ["Hi", "Hello", "Namaste"] - id: ask_info examples: ["What is this about?", "Explain", "Tell me more"] - id: provide_time examples: ["Tomorrow 3pm", "Thursday at 3 PM", "5 PM"] - id: vague_time examples: ["Tomorrow", "Sometime next week", "Later"] - id: not_interested examples: ["Not interested", "No thanks", "Stop"] - id: language_switch_request examples: ["Can we speak in Hindi?", "Telugu please", "Marathi bolu?"] - id: interruption examples: ["Wait", "Hold on", "Stop"] nlg: opening: description: "允许说话 + 目的" strictness: soft base_template: "Hi{{#if customer_name}} {{ customer_name }}{{/if}}, quick call to see if now is a good time for a 2-minute info session. Is now okay?" info_outline: description: "简短价值 + 询问可用性" strictness: soft base_template: "We help streamline scheduling and support. Would a short follow-up help? What time works for you?" time_request: description: "当模糊时重新请求具体时间" strictness: strict base_template: "Could you tell me a specific date and time for a quick follow-up (for example: Thursday at 3 PM)?" confirm_time: description: "确认捕获的时间并结束" strictness: strict base_template: "Great — locking in {{ meeting_time }}. I’ll send a reminder. Thanks!" language_ack: description: "承认并切换语言" strictness: soft base_template: "Sure — I will speak in {{ language }} from now on." policy: initial: S0_opening states: S0_opening: say: nlg.opening capture: [] on: ask_info: S1_info not_interested: say: nlg.not_interested_close end: closed language_switch_request: say: nlg.language_ack action: update_entity(language_preference) then: S0_opening S1_info: say: nlg.info_outline capture: [] on: provide_time: S2_confirm vague_time: say: nlg.time_request then: S1_info not_interested: say: nlg.not_interested_close end: closed S2_confirm: say: nlg.confirm_time capture: [meeting_time] end: booked edge_cases: - id: follow_up_missing_time trigger_intent: provide_time behavior: "如果解析的时间是模糊的，再次请求nlg.time_request。" - id: language_switch trigger_intent: language_switch_request behavior: "更新language_preference并重新用翻译后的最后代理提示说话；从相同状态继续。" - id: user_interrupt trigger_intent: interruption behavior: "短暂承认（1个token）并重新评估意图；在澄清之前不要继续状态转换。" scenarios: - id: happy_path_booking steps: - { bot: nlg.opening, expect: ask_info } - { bot: nlg.info_outline, expect: provide_time } - { bot: nlg.confirm_time } - id: language_switch_example steps: - { bot: nlg.opening, context: { language_preference: "en-US" } } - { user: "Hindi mein baat kar sakte hain?" } - { edge_case: language_switch -> update language_preference: "hi-IN" } - { bot: nlg.language_ack (translated) + re-issue nlg.opening translated } acceptance_criteria: - "打开状态说明目的并请求权限。" - "以标准形式捕获会议时间并在口语形式中确认。" - "立即尊重不感兴趣并礼貌结束。" - "如果用户给出模糊答案，则提示具体时间。" - "在请求时立即更新language_preference并将其用于后续输出。" ``` ## 2、结束语 这里描述的方法在你需要确定性时效果最好——例如，合规性、预订或对话中精确措辞和可预测流程重要的情况。 如果你的目标是让模型自由思考并更自然地回应，那么这种FSM风格的提示不是你想要的。在这种情况下，要利用LLM的概率特性，允许更高的变化性，并专注于优先考虑参与度而非严格遵守的对话设计。 --- 原文链接：[The Secret to Reliable Voice Agents: Treat Prompts Like State Machines](https://medium.com/@manavisrani07/the-secret-to-reliable-voice-agents-treat-prompts-like-state-machines-2323a616affa?ref=hubwiz.com) 汇智网翻译整理，转载请标明出处