语音 Agent 如何明确表达未知信息

语音客服最危险的回答，往往听起来很正常：营业时间没写，它说朝九晚五；保险信息没查到，它说可以报销。电话里没有来源链接，客户很容易把一句流畅的回答当成商家的承诺。

作者用九份客户语音 Agent 的导出配置，复盘了这类问题。他的结论是：减少幻觉，先把未知、禁答、工具失败和配置冲突处理清楚。其中两处看似模型胡编的错误，根源就在他们自己写的提示词里。

不知道的事实，也要明确写进提示词

作者为美国客户搭建语音 Agent，使用 Retell、n8n 和 GoHighLevel。他追查过的生产问题大多落在四类：编价格、编可预约时间、编业务政策，以及自信回答医疗症状、法律等业务范围外的问题。

这些问题有一个共同起点：模型没有拿到答案，却继续生成了一个像答案的句子。

在代码里，字段不存在可能返回 undefined，甚至抛出异常；在提示词里，缺失信息通常不会自动中止回答。当地商家常见的营业时间，可能就成了模型补全的素材。

作者在 HVAC，也就是暖通空调业务 Agent 的配置里，明确规定了营业时间未知时的行为：

- Business hours: Not publicly listed - never quote specific hours. Just offer to schedule.

要看的是后半句：它既禁止报具体时间，也给出了下一步动作。水处理 Agent 使用同样的规则；牙科和屋顶维修 Agent 则逐日列出真实营业时间。

业务事实可以未知，但未知时怎么回答不能留白。

作者的检查方式很朴素：列出客户会问的营业时间、价格、保险、融资、服务区域和员工信息，每项要么有准确值，要么明确写出「不能说什么，以及改做什么」。这类似数据结构里区分字段缺失与字段存在但值为 null，只是还要多定义一步交互行为。

禁答规则也遵循这个思路。律师事务所不能提供法律建议，人身伤害律所还不能报赔偿金额或风险代理收费比例；信用修复和债务协商业务不能给保证；屋顶维修不能保证保险理赔获批。

但只有「NEVER」还不够。CallSetter 销售 Agent 的价格规则，把替代回答放在同一处：

### Pricing Lock
NEVER mention specific prices. Always say: "Pricing is customized based on your volume and will be covered on the demo."

要注意 Always say：它让模型有一句获准使用的回答。HVAC、牙科和屋顶维修 Agent 也会先表达不愿猜测，再引导到诊断上门、免费咨询或免费估价。这里的「免费」必须来自各自业务配置，不能跨行业照搬。

作者也承认，禁答清单只能覆盖提前想到的问题。它是第一层约束，无法穷举所有未知情况。

实时事实交给工具，工具没结果也要有出口

营业时间可能长期稳定，可预约时段、当天日程、工单状态却随时变化。作者不把这些事实写成提示词里的固定描述，而是在客户询问时调用 get_slots_from_ghl 或 checkCalendar。

工具应返回数据，例如 {"available": false, "next_slot": "Thursday 10:00"}。相比一段描述本周安排的自然语言，明确字段更容易让模型按结果回答，也减少自行扩写的空间。

他们的预约提示词要求「始终给出恰好两个具体时间」，目的是让 Agent 读出工具返回的选项。但这条规则也有适用条件：工具必须确实返回足够的可用时段。原文没有展示不足两个时段时的完整处理逻辑，不能为了凑齐两个而补造答案。

更容易出问题的是空结果和调用失败。作者发现，很多虚构预约时间的案例，都发生在工具没有返回内容之后：数据链路断了，模型却替它接上了一句听起来合理的话。

因此，工具成功、没有可用结果、调用失败，都需要各自的回答路径。原文还提到，作者曾在每个工具上发现两分钟超时；具体故障处理放在另一篇文章中，这里没有展开，不能据此判断失败路径已经完善。

对开发者来说，关键不只是「接了工具」。还要确认工具没有提供事实时，Agent 会明确收口，而不是继续猜。

先查提示词里的旧配置，再怀疑模型

这篇最有价值的部分，是作者对自己配置的反查。

牙科 Agent 的提示词里，8:30 出现了九次，分布在 Context、规则、暂不预约时的话术和示例对话中；屋顶维修 Agent 的营业时间则出现了十次。

这种重复很容易制造冲突。诊所修改周五营业时间时，维护者可能只改 Context，漏掉示例。模型随后读出了旧时间，通话记录看起来就像一次幻觉。

但它可能只是照着过期配置回答。

另一处更直接：牙科 Agent 的费用话术里出现了「inspection is free」。牙科没有这里所说的屋顶检查，这句话是从共享模板复制过来的。作者还提到，之前曾遇到 HVAC Agent 监听牙科品牌 Invisalign 的残留配置。

错误甚至存活到了另一份更新后的牙科提示词里。不过，作者没有重新导出线上 Agent 核验，因此他没有声称真实客户听到过这句话。这里应区分两件事：导出文件里存在错误已经确认，线上是否触发仍未确认。

一条业务事实只维护一份，示例引用它，不要再抄一份。

这也是作者建议「怪模型之前先 grep 提示词」的原因。业务事实应当像配置一样维护；把经常变化的事实放进 fine-tuning，同样会增加更新和排查的负担。

限制发挥之后，还要专门测试它会不会乱答

九个 Agent 都运行在 gpt-4.1 上，但最初只有一份导出配置显式设置了 model_temperature，值为 0；修正后的 HVAC 导出又增加了一份，其余使用平台默认值。

作者因此把主动设置温度加入配置检查清单。接待工作通常不需要太多措辞创意，但原文没有给出调整前后的幻觉率对照，不能把温度设为 0 当作事实正确性的保证。

结构也会影响模型的发挥空间。九个 Agent 都采用单提示词，长度约为 2,400 到 4,400 个英文单词。对于固定的信息采集流程，作者认为 conversation flow 能减少偏离流程的机会，但这里同样没有给出两种方案的量化比较。

测试则要主动离开正常预约路径：询问未配置服务的价格、已经被占用的时段、不支持的保险或付款计划、不存在的员工，以及医疗、法律、安全问题。还要在回答中途打断并换问题，或者只问一句没有上下文的「开了吗」。

通过标准很具体：要么回答有事实依据，要么使用获准的兜底话术。作者强调这些测试应该写成脚本，方便复现。

上线后，他们会标记提到价格、政策或日期的通话，每周阅读标记记录并抽样检查。作者称，每个客户每周花十五分钟，就能在客户发现之前找出多数问题；这是他的运维经验，原文没有提供统计口径或漏检率。他们开发的 VoiceDash 则让客户能够自行查看通话和转录记录。

我的判断

我赞同作者把排查顺序前移到业务配置。提示词包含过期时间、串行业话术时，换模型并不会自动消除矛盾。先消除重复事实、明确未知状态，通常更容易定位问题。

但这些做法主要是提示词层面的约束，执行仍依赖模型。结构化工具返回比自然语言更清楚，却不能单独保证模型只引用返回值；低温度可以减少回答变化，也不能让缺失事实凭空变得可靠。

对于价格和预约这类容易形成业务承诺的输出，可以进一步由程序校验金额、日期和可选时段，必要时直接使用固定模板。代价是交互灵活性下降，也需要额外维护分支。这是工程上的取舍，原文没有做方案对照。

还要看到样本范围：九份客户配置足以暴露具体问题，却不足以证明整套方法在一般团队里能降低多少幻觉。文章最可信的贡献，是展示了真实配置缺陷和排查方法；效果幅度仍属于经验之谈。

能拿来做什么

• 给现有客服或预约 Agent 补一张业务事实表，逐项标明准确值、未知状态和获准的替代回答，优先覆盖价格、营业时间、保险与付款政策。
• 在 Node 工具接口中区分成功、无结果和失败，并让提示词对应这三种状态；预约工具没有返回时段时，禁止继续生成具体时间。
• 修改业务配置时，用 grep 或编辑器全局搜索检查同一事实是否散落在规则与示例里，同时清理共享模板中的行业专用词。
• 把未配置价格、已占用时段、陌生员工、打断和模糊提问写成固定测试脚本，上线后定期抽查涉及价格、政策和日期的通话记录。