北京
先说一句要紧的：下面这些内容来自大约一个月前跑的那套开发，更新的模型版本表现可能已经不一样了——这个领域跑得快，大家都知道。所以把它当成一份快照，不是结论。
教科书式的回答是：语音智能体就是一套系统，听人说、把话送进大语言模型去理解、再把回复合成语音播出来，全程实时。技术上没错，但也是那种让人想直接关掉页面的句子。
实际发生的是另一回事。我们做的东西是在客户打来电话时接起电话。来电的人可能想要账户对账单，可能想了解某只基金方案是做什么的，也可能想设置一个 SIP——也就是每月定投计划。如果你没听过这个词，没关系，试用期间打进来的大多数人也没听过。
大部分工作其实都围绕时间：智能体什么时候开口、什么时候停下、第一个字出来得有多快。聊天机器人回一句话花三秒没人介意；在电话里，两秒的沉默就已经很长了。来电的人会以为线路断了，或者自己又开口说起来。
三部分与两条路线
不管选什么模型，每个语音智能体都有三部分：来电音频先经过输入，再到“大脑”，最后到输出，然后回到来电者。
多模态模型把这三部分塞进一个模型里；级联方案则为每一部分单独用一项服务。两条路线我们都试过。两种都能跑通，选哪条要看具体的使用场景。
语音智能体是一台状态机
状态机就是一套系统，任何时刻都处在一个已知状态，特定事件把它推到另一个状态。一通电话很符合这个模型：某一刻智能体在问候来电者，下一刻在弄清对方要什么，再下一刻在收集 PAN，或者在等 OTP，或者结束通话。
如果把所有规则都塞进一个大提示词里，大模型会忘掉其中一些。把通话拆成状态之后，每个状态拿到一段短提示词，以及它自己需要的工具。严格的规则写进代码里，模型没法跳过。
同一时刻只有一个智能体在说话。接待智能体整通电话都保持在线，一次只接入一条流程。
提示词缓存与系统提示词长度
大模型在每一轮都要读完整段系统提示词和完整的工具列表。每个 token 都要被处理，每个 token 都要计费。我们的提示词很长，每条流程都背着一摞规则，而在语音智能体里，延迟不是锦上添花的东西，它就是全部——回复一慢，这通电话就死了。所以提示词优化在语音智能体里分量很重。
提示词缓存能消掉大部分痛苦。把系统提示词和工具列表标记为可缓存，下一轮服务商就跳过重复处理，只读新消息。我们还会把历史记录里的最后一条消息标成缓存点，这样对话本身随着增长也被缓存下来。
来自我们链路追踪的数字：在 Haiku 4.5 上，74% 的输入 token 来自缓存；在 Sonnet 4.6 上是 83%。这是很大一块你根本不用付费的处理量。
陷阱在这里。每个模型对可缓存块都有自己的最小尺寸要求。Haiku 4.5 要求 4,096 个 token，Sonnet 4.6 要求 1,024 个。我们的接待提示词停在 1,925 个 token，在 Sonnet 上没问题，对 Haiku 来说根本不可见。一换模型，接待智能体就完全不再缓存了。没有警告，没有报错，只是延迟和成本悄悄往上跳，直到有人去看才发现。
任何时候做模型切换，都打开 API 响应去读缓存数字。别假设昨天能用的今天还能用。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
