JEV AI 可以为 Asterisk 语音智能体增加专门的决策层：先判断来电者这一轮表达的含义，让简单回答走经过验证的简短路径，再把困难情况交给 Qwen。 应用可以执行哪些操作，仍由状态机决定。
在构建自己的 AI IVR 智能体中，我们连接了电话系统、语音识别、受限的 LLM 解释器和确定性的对话流程。本文继续设计下一步改进：先咨询 Jev，减少普通轮次调用较大语言模型的次数。
例如，“请重复”、选择已知类别或要求人工服务，都需要范围明确的判断和适当回应。包含多个字段及更正的句子则需要更复杂的理解。让两条路径各负其责，是这次改进的出发点。
本文是计划中改进的实现蓝图，使用虚构、与具体行业无关的事件示例。它不是 Jev 已完成生产部署的报告，也不是 Jev 延迟基准测试。
JEV AI 是什么，为什么放在 LLM 前面？
TypeSafe 于 2026 年 9 月 15 日推出 Jev，将其定位为面向结构化决策的 System One 模型。它接收上下文和带类型的问题，而非生成开放式对话回复，因此适合参与 AI 智能体内部的路径选择。TypeSafe 公告。
在这个 IVR 中，“位于 LLM 上层”是指 Jev 帮助选择解释路径。它不管理权限、不执行后台业务操作，也不编写随意播报的内容。应用代码把模型结果与当前对话状态结合起来。
三种问题原语对应不同任务：choice 从预先声明的选项中选择，noul 估计命题为真的概率，score 按已定义的量表评估。本方案主要使用前两种。TypeSafe 简介。
带类型的输出限制了答案形式，但模型依然可能选错类别。因此，应用必须保留验证、歧义选项、澄清和人工服务。
从 LLM 解释器升级为混合式 Asterisk 语音智能体
原设计把识别后的文本和上下文交给受限解释器。新设计增加一次决策，并把原解释器保留为回退路径。
| 组件 | 在拟议集成中的职责 |
|---|---|
| Asterisk | 呼叫信令、媒体传输、播放和转接机制 |
| 语音活动检测与 ASR | 划定发言片段并生成转写文本 |
| Jev | 根据当前上下文回答范围明确的判断问题 |
| 策略与状态机 | 验证结果、选择下一问题并强制确认 |
| Pi 与 Qwen LLM | 解释混合字段、复杂指代和复杂更正 |
| 预生成音频与 TTS | 播放已审核的固定提示或已验证的动态文本 |
| 后台适配器 | 执行明确获准的读取，或准备测试请求 |
图 1：拟议架构。两条决策路径都进入同一验证层。按键由代码按照当前菜单解释。图中标签为英语。
明确要求人工服务时，可以不等待大模型，直接进入转接流程。简单的类别选择可以推进到下一个缺失字段。如果用户说“事件涉及设备 A，其实是设备 B，从昨天开始”，Qwen 仍有价值。
潜在收益是普通轮次减少大模型调用。不过，新增决策请求本身也有成本，尤其在需要回退时。是否改善整体体验，必须结合两条路径测量。
把来电者真正听到的问题交给 Jev
只有转写文本并不够。“二”可能选择菜单的第二项，也可能是编号的一部分。“是”可能确认摘要，也可能表示还要办理另一件事。
构造紧凑的状态对象，包含原始转写、当前状态（INTENT、COLLECT、CONFIRM、MORE 或 HELP）、实际开始播放的问题、提供的选项、待填写字段和相关已验证数据。对话版本号和尝试次数由代码维护。如果查询使用年份，应在通话开始时按应用配置的时区固定。
还应记录播放进度：摘要开始播放，并不能证明用户已经听到足够内容来确认。更正或打断必须使过时的确认机会失效。
TypeSafe 支持文本状态，包括结构化 JSON；本设计不会把原始电话音频交给 Jev。文档也提醒，非英语准确率需要特别关注。必须评估来电者的实际语言，包括西班牙语，而不能假设英语结果自动适用。State 文档。
每轮只选择与当前状态有关的问题：
| 问题 | 建议原语 | 代码如何使用 |
|---|---|---|
| 继续、重复、要求人工还是结束？ | choice |
选择对话控制路径 |
| 新事件、状态查询还是其他请求？ | choice |
选择支持的业务流程 |
| 选择了哪个已提供类别？ | choice |
按当前菜单验证 |
| 是否更正了之前的字段？ | noul |
撤销确认并检查更改 |
| 是否混合了多个字段？ | noul |
考虑交给 Qwen 提取 |
| 是否明确需要立即人工处理？ | noul |
应用升级策略 |
类别问题要包含明确的未知或歧义结果。各问题独立评估同一输入，不应依赖同一请求中另一个问题的答案。随后由代码组合结果。Choice 文档。
“是或否”的答案不能提取任意文本。对于单一、直接的描述，代码可以在确认其回答待填字段后保留原始转写。拆分多个字段或解释复杂更正，则交给较大的解释器。
为每轮选择路径，同时保留应用控制权
图 2：拟议的路由策略。证据矛盾时澄清或回退；所有路径都必须符合当前对话版本。图中标签为英语。
拟议优先级是人工请求或明确风险信号、取消、重复，然后才是字段收集和更正。歧义或矛盾结果不得悄悄填入字段。
初始调优候选值为：普通类别选择的首选概率至少 0.90，且比第二选项高至少 0.25；明确判为超出服务范围时使用 0.95；通过 noul 标记明确风险、送交人工复核时使用 0.80。这些是初始策略，不是 Jev 的实测保证。较低的风险阈值优先推动人工复核，并不诊断紧急情况或替代应急流程。
Choice 的概率与 confidence 是不同字段。TypeSafe 将 confidence 描述为由概率分布计算的统计量，而不是独立测得的正确率。Noul 返回 noul 概率，没有单独的 confidence 字段。Confidence 与 Noul。
故障路径也需要限制：建议 Jev 请求最多等待一秒，本轮内不重试，最多执行一次回退解释。超时、服务错误或无效响应时，回到原解释器。其初始 20 秒上限是需要评估的最大等待限制，不是自然对话的目标延迟。
两条路径应输出相同的内部意图与字段契约。必须验证后才能推进状态机。Jev 客户端应与 Pi 的对话接口分离，并核实实际供应商协议；本地兼容网关的聊天接口并不自动等于 Jev 原生 API。
对话体验会怎样改变？
以下是通用事件服务的虚构示例，不是录音或真实请求。
| 来电者说 | 预期行为 |
|---|---|
| “我要报告一个设备事件。” | 选择支持的报告流程，询问缺失信息 |
| 在设备菜单后说“设备 B” | 验证已提供的选项，进入下一字段 |
| “请重复。” | 重播当前问题，不记为字段回答错误 |
| “是，但应该是设备 C。” | 更正使确认失效，重新读出摘要 |
| “能让我和工作人员通话吗？” | 播放提示，启动配置好的人工路径 |
| 噪声或无关回答 | 澄清待填字段；三次失败后提供人工帮助 |
提供帮助后，等待用户请求或有效按键。只有对应菜单生效时，数字才选择菜单项。明确要求人工服务的用户，无须先耗尽澄清次数。
在确认阶段，“是”只对当前摘要有效，且不能存在待处理更正，并须有足够播放证据。在 MORE 状态，同一个词表示还想办理其他任务，应询问具体事项，并使用全新的任务数据。
原型的完成提示仍需准确：“测试请求已准备好，尚未提交。”真实集成必须核实后台结果后才能宣告成功。查询状态同样需要授权；知道一个编号并不能独立证明访问权限。
同时改善语音循环，而不只优化模型路由
图 3：概念性语音生命周期，并非实测时间轴。800 ms 表示从开始处理算起的拟议等待提示触发点。图中标签为英语。
提前生成问候、菜单、澄清问题和转接提示。使用经过验证的数据构造动态摘要，在通话期间合成。包含来电者数据的动态音频应保留在该通话隔离的内存里，而非共享提示目录。
从开始处理起，安排在 800 毫秒时播放简短等待提示。如果回答提前就绪，取消提示；如果最终音频在提示播放期间就绪，停止提示，开始有用的回答。提示不得延迟已经获准的查询。等待音乐只用于真实后台查询，不应覆盖每次模型推理。
语音打断必须停止排队音频，并使旧工作失效。Asterisk 的 FLUSH_MEDIA 可以清除排队媒体，但应用仍要为模型回复和生成音频维护取消信号与版本检查。Asterisk WebSocket 文档。
挂断时取消任务与计时器；字段改变时拒绝旧版本结果。转接时，应区分目的端应答、桥接完成与真人接听：自动队列欢迎语并不证明有人接听。
如何引入改进并测量结果
定义三个明确模式：off 保留原解释器；shadow 收集决策用于评估，但原路径继续控制对话；enforce 允许经过验证的决策选择简短路径，同时保留回退。问题、阈值和音频目录应与代码一起版本化，只在需要时创建较重的解释器。
测试更正、歧义菜单选择、混合请求、模型不可用、无效结果、静音、打断、迟到回复和挂断。加入来电语言中的口述数字、按键，以及“是，但……”之类表达。功能完成与转写质量要分别报告。
在宣称 AI 电话智能体更快前，测量以下项目：
| 测量 | 意义 |
|---|---|
| 发言结束到第一段有用回答真正可听见 | 捕捉来电者实际等待 |
| ASR、决策、回退、后台和 TTS 耗时 | 定位瓶颈，而非归咎于某个模型 |
| 简短路径覆盖率和错误率 | 判断何时能安全跳过大模型 |
| 回退频率和回退总耗时 | 暴露新增决策步骤的成本 |
| 更正、无效确认和转接结果 | 检查对话是否正确 |
| 取消、超时和负载下的分布 | 检查成功单轮演示之外的行为 |
上一篇文章分别测量了语音识别与解释，这些数据不能证明 Jev 架构的速度。我们也不会把其他决策模型的测量重新命名为 Jev 结果。应固定 Jev 版本，使用相同语料并记录服务条件，然后再通过真实电话重复测试。失败和取消的工作也必须报告。
实现 JEV 集成的实用任务说明
下面的任务说明适合已有可用 ASR、Qwen 和 TTS 服务的智能体：
在现有受限解释器之前增加 Jev 决策客户端。
保留当前状态机对对话和操作的控制权。
示例与测试使用虚构的通用事件。
用转写、当前状态、已播放问题、选项、待填字段、已验证数据
以及对话版本构造状态。根据状态选择独立的 Choice/Noul 问题。
核实供应商 API，不假定兼容 chat completions。
验证全部结果，提供明确的未知结果及按类别可调阈值。
概率不等于授权。复杂或不确定输入最多进行一次回退解释。
决策期限为 1 秒，同一轮内不重试决策请求。
保留更正、当前摘要确认、依上下文解释 DTMF、取消、挂断清理
和人工服务。固定提示用预生成音频，动态回复使用验证后的文本
和 TTS。800 ms 等待提示必须可取消，且不能阻塞流程。
增加 off、shadow、enforce 模式。记录路径和耗时元数据，默认
不记录来电者文本或音频。测试两条路径、故障和旧版本结果，
准确报告执行过的测试。测试准备与获准的真实后台写入应分开。有价值的交付物是适配器与可测试的路由策略，而不是用更长的提示把电话控制权交给模型。
决策层能否本地运行？KEV 与 Qwen
如果希望自行部署，Kev 是独立的开源类 Jev 决策模型家族，基于 Qwen3.5。仓库提供模型、训练代码和服务说明，包括 0.8B、4B 和 9B 版本。Kev 不是换了名字的 Jev，API 相似也不证明准确率、校准或延迟相同。
本设计可迁移的部分是应用契约：结构化决策经过相同的验证与状态机边界。本地替代方案仍需独立进行多语言评估、硬件规划和供应商适配，并核实许可证及所选模型的部署条款。
JEV AI 与 Asterisk 常见问题
Jev 会替代 AI IVR 中的 Qwen 吗？
本设计让 Jev 处理范围明确的路由判断，Qwen 继续解释复杂表达，应用决定使用哪条路径。
Jev 会直接听电话或生成语音吗？
本集成在 ASR 之后把文本交给 Jev。预生成提示及独立 TTS 服务生成语音，Asterisk 负责传输和播放。
每个电话都会更快吗？
目前没有证据。简单轮次可能避免大模型请求，但回退路径会增加决策步骤。ASR、后台和音频的延迟仍然重要。
哪些控制必须留在模型之外？
授权、当前摘要确认、后台执行、通话隔离，以及取消和转接规则。新版本应让这些边界更容易测试，同时让常见对话更顺畅。