Hume EVI 的巧思：让 AI 先听语气，再开口

Hume EVI 最值得拆的地方，不是它给语音助手加了一个「情绪识别」卖点。EVI 把语音里的节奏、音色、停顿和情绪表达变成对话系统的一部分：什么时候该回答、用什么语气回答、用户插话时要不要停，都不再只靠文字转写稿判断。Hume 的产品页把 EVI 定义为能理解并回应人类情绪的 voice-first AI，官方文档进一步说明，EVI 会测量用户语音里细微的 vocal modulations，并用 speech-language model 指导语言和语音生成。12

这件事听起来很自然，实际很反常识。很多语音 AI 产品把语音当成输入格式：先转成文字，再交给大模型回答，最后把文字读出来。Hume EVI 的判断是，语音不是文字的外壳，语音本身带着交互信息。用户说「没事」时是平静、烦躁、敷衍还是忍着火，文字一样，产品该给出的下一步并不一样。

传统聊天产品最稳定的输入对象是 text message。语音助手如果只是把音频转写成 text message，就会丢掉一大块上下文：用户是不是还想继续说，用户是不是不确定，用户是在开玩笑还是认真抱怨。

EVI 的第一个设计选择，是把这块上下文显式接进对话。官方文档写到，EVI 会处理 speech 的 tune、rhythm 和 timbre，这些信息会帮助它判断何时说话，并生成更合适的语气。功能表里也写得很具体：ASR 会返回完整 transcript，并把 Hume 的 expression measures 绑定到每个句子；EVI 的 prosody model 会对用户语音的 tune、rhythm、timbre 做 streaming measurements。2

更关键的是，这些测量不是藏在后台报告里。Prompting 文档说明，EVI 会实时分析用户的 vocal expressions，并把它们翻成文本指标；系统会检测 48 种表达，按置信度排序，把前三个表达附加到每条用户消息后面。文档给的示例是把用户文本后面接上类似「very happy」「quite anxious」「moderately amused」这样的表达标记，让 LLM 能知道用户怎么说了这句话，而不只是说了什么。3

这个设计的巧思，在于它没有把「情绪」做成一个旁边展示的仪表盘。仪表盘只能让开发者或客服主管事后看见用户状态，不能直接改变下一轮对话。EVI 把表达测量塞回 message 层，等于给每句话多加了一组交互参数：用户的话本身是一层，语气又是一层。

这也解释了为什么 Hume 会强调 end-of-turn detection。文档说，EVI 会用用户的 tone of voice 判断回复时机，官方称这是快速回应而不打断用户的瓶颈。2 这句话在产品设计上很重。语音界面的难点不是让模型更快吐字，而是避免在用户还没说完时插嘴；插错一次，用户对「它懂不懂我」的信任会掉得很快。

代价也很明确。情绪被产品化后，隐私和可解释性不能再被当成附属设置。Hume 的隐私文档写到，EVI API 默认会启用数据保留，用户可以开启 zero data retention 来关闭聊天历史或录音存储；但关闭后，resume chats 和 chat history 等能力也会受影响。4 这就是情绪语音产品的真实边界：你想要跨会话记住上下文，就要面对记录什么、保留多久、谁能访问的问题。

第二个设计点，是 EVI 没有只把自己包装成一个更有感情的声音。Hume 把实时语音对话拆成一组可配置的产品对象：voice、system prompt、language model、tools、turn detection、interruption、timeouts、webhooks。配置文档说明，EVI Config 是一组可复用的配置，会在 chat session 开始时应用；Configs、Prompts 和 Tools 都有版本，方便迭代和回滚。5

这让 EVI 的定位更像一套语音交互层，而不是单个助手。产品页写到，开发者可以使用 Claude、GPT、Gemini、Grok、Kimi K2、Llama 等模型，并在不改变集成的情况下切换模型；同页还写到，开发者可以从 expressive voices 里选择、从样本克隆声音，或用自然语言描述设计新声音。1 换句话说，EVI 把「想什么」和「怎么说」拆开了：LLM 负责内容，语音层负责听感、节奏和表达。

这种拆分有一个直接好处：开发者可以把语音体验调成产品的一部分，而不是调成模型的副产品。Prompting 文档明确区分了 prompt 能做什么和不能做什么。Prompt 可以指导语言生成、回应风格、对话流程和情绪语气，但不能改变声音的基础特征，比如口音、性别或 speaker identity；想改变这些，需要用 voice customization。3 这条边界很产品化：语气可以被 prompt 影响，声音身份要通过 voice 对象管理。

中断机制更能看出这个设计的细节。产品页说 EVI 支持 interruptibility，用户可以像真实对话一样随时打断。1 音频文档则把这件事拆得更细：EVI 音频是 streamed，不是预录文件；客户端要把返回的 audio segments 放入播放队列；当收到 user_interruption 或 user_message 事件时，客户端应该停止当前播放并清空队列。6

这比「支持打断」四个字更重要。语音产品里，模型停止生成不等于用户听到的声音停止。如果客户端还在播放已经收到的音频片段，用户会觉得助手还在自顾自说话。Hume 把这层写进实现指南，说明它把中断当成端到端体验，而不是 API 事件名。

Chat history 也是同一套对象化思路。Hume 文档把历史记录分成 Chats 和 Chat Groups：Chats 是一次 WebSocket 连接里的会话，Chat Groups 用来把相关 Chats 连起来；Chat events 里会记录 USER_MESSAGE、USER_INTERRUPTION、AGENT_MESSAGE、FUNCTION_CALL、PAUSE_ONSET、RESUME_ONSET 等事件。文档还说明，开发者可以从 USER_MESSAGE 和 AGENT_MESSAGE 重建 transcript，也可以从 USER_MESSAGE 的 emotion_features 提取情绪分数。7

这套事件模型把语音对话从「一段录音」变成了可审查的交互日志。Coconote 的案例能说明它为什么有用：Hume 案例页写到，Coconote 用 EVI 支持 voice chat，让学生用自然语音询问 lecture content，获得引用具体 notes 的解释，并进行 quiz-style conversations。该案例还提到，EVI 的 end-of-turn detection、emotionally aware responses 和 chat history 能力支撑了这个学习场景。8 对学习产品来说，用户不是只要一个答案，而是要一段能被继续追问、回看和调整节奏的对话。

Hume EVI 给 AI 产品的启发，不是所有产品都该去识别情绪。更稳的原则是：当输入本身带有大量非文字信号时，产品不要急着把它压扁成文本。

语音里有停顿、犹豫、打断和音量变化；画布里有拖拽顺序、缩放和选区；代码编辑器里有光标位置、撤销动作和错误提示。这些都不是内容本身，却会改变 AI 下一步应该怎么做。好的 AI 产品会把这些信号变成可被系统使用的对象，而不是把它们留在界面边缘。

EVI 的另一个可迁移点，是把魔法拆成可配置边界。声音、模型、工具、中断、历史、隐私保留策略，各自有自己的开关和代价。用户或开发者不一定要看见每个底层参数，但产品需要有这些对象，否则「自然对话」就会变成一团很难调试的黑箱。

Hume EVI 最有意思的地方也在这里。Hume EVI 没有把语音 AI 做成一张更会说话的嘴，而是先承认语音对话是一套脆弱的轮次系统：要听出语气，要知道什么时候接话，也要在用户插话时立刻闭嘴。语音助手越像人，越不能只追求会说；很多时候，它先要学会停。