Vapi 上线流量拆分：小比例放量验证语音智能体新版本

Vapicon 2026 即将到来。流量拆分功能已上线：去做那个你一直搁置的改动吧。Vapi 团队 • 2026年10月26日 • 5 分钟阅读 分享

如果你已经在语音智能体上构建了一段时间，你心里大概有一份想要做出的改动清单。这可能包括你想精简掉的臃肿提示词、你一直好奇的模型替换，或者你认为会更受客户欢迎却还没尝试过的语音。

这份清单上的大部分内容归根结底都指向一件事：做出改动意味着要把你的全部客户群一次性全部切换到新东西上。在此之前，发布助手的新版本会立即把 100% 的流量发送到新版本。于是团队变得谨慎，然后变得缓慢，最终在事情足够好之后就停止了迭代，把那些本可以让“足够好”变成“出色”的改动留在了身后。

流量拆分改变了你迭代智能体的方式。将 0.1% 的调用发送到新版本，或者 1%，或者 5%，观察会发生什么，然后放心地向前推进或回滚。

我们与 Vapi 的技术团队成员 Peter Gomez 坐下来聊了聊，他参与构建了这一功能。以下是关于它是什么、难在哪里以及下一步走向的对话。

用通俗的话说，什么是流量拆分，它为什么重要？

流量拆分让你可以把呼入和呼出通话流量分配到智能体的不同版本上。

你之前已经可以创建助手的多个版本。问题在于，一旦你发布了新版本，所有流量就会立刻全部转移到新版本上。假设你更改了语音或提示词。你无法可靠地确认这项改动在真实客户身上是否达到了你想要的效果，也无法确认它是否比上一版本表现更好。这一点在 LLM 上最为关键，因为改动带来的结果并非确定性的。在提示词中增加一个关键词，就可能产生你从未预料到的下游影响。

我们在迭代自己的助手时也亲身感受到了这一点。团队会放慢发布节奏，迭代越来越少。一旦助手变得足够好，他们就不再改动它，即使他们知道存在问题。配置变得脆弱，小更新的风险超过了收益。

借助这个版本，你可以先把一小部分流量发送到新版本，在正式切换前观察它的表现。你通过查看指标确认它符合你的标准，然后将其全量推送给 100% 的调用方。这本质上就是为你的助手做金丝雀发布。仿真和评估最多能让你在上线前达到约 90% 的信心。流量拆分则通过真实通话补上剩下的部分，让全部客户群在正式落到新版本之前先得到验证。

在此之前，团队是如何绕过这个问题的？

大家想出了各种办法。有些人运行重复的助手并在它们之间进行路由。有些人通过我们的 GitOps 仓库来做版本管理，这仍然是一种不错的做法。还有些人利用助手请求作为逃生通道，在自己的侧构建路由逻辑。

说实话，这些方案大多比现在内置于平台的功能更复杂、也更不可靠。

最难做对的问题是什么，你们又是如何解决的？

两件事。

首先是安全地修改代码。它位于热路径中，因此每一个进来的调用都会触及它，无论是否使用了该功能。我们把一切都放在功能开关之后，在它到达其他任何人之前做了大量内部测试，并确保它易于回滚。

第二是身份——为了让重复来电者保持在同一个版本上，我们称之为“粘性”的概念。每个人接收和路由通话的方式都不同。真正的技术挑战在于跨电话通话、网络通话、呼入和呼出识别来电者，这样当某人再次来电时，他们尽可能获得同一个版本，而不是不同的版本，从而创造一致的体验。对于有此要求的部署，身份功能可以开启和关闭。

你见过客户用流量拆分来运行哪些用例？

最主要的是安全发布。制作一个新版本，将一小部分流量发送给它，观察，然后向所有人推出。

我们在查看客户数据时发现更有趣的一点是，拆分是临时的。会有那么一个时刻，你对新版本充满信心。人们不会把它调到100%，而是把助手设回“跟随最新版本”，这意味着新版本会直接进入全部流量。拆分、确认、切回、重复。短周期，一次只改一个变量。

这告诉我，客户知道每次变更的风险水平。更换LLM会做拆分。小的提示词调整会直接到100%，他们继续忙自己的事，几小时后再回来确认它运行正常。

团队在开始拆分流量时应该遵循哪些最佳实践？

从两路拆分开始。该功能支持更多路，但我们建议一次两路，这样你能知道是什么在驱动差异。我们也尝试在界面中教这一点。

此外，在很多情况下，你可以让实验保持简短。每次调用都固定到其版本，因此你可以干净地归因结果，而不需要很长的测试窗口。有些变更在流量较低或波动较大的情况下需要一周或更长时间才能读出结果，但许多变更能更快达到统计显著性。

在开始之前，看看你一直以来的构建方式。如果你有重复的助手，或仅为避免全有或全无发布而存在的自定义路由，那就是可以简化的候选对象。

早期用户用它做了哪些你没预料到的事？

我原以为人们会把它当作长期实验工具。相反，他们把它当作一道闸门。

更大的惊喜在于，那些已经在围绕这个问题做工程的人，对采用它的犹豫程度有多高。替换一个虽然笨重但能正常工作的内部解决方案，需要经过深思熟虑的决定。

接下来会走向何方？它又会为整个平台解锁什么？

目前，它解锁了我们希望每个构建者都能拥有的安全发布能力。构建应该是有趣的。你应该能看到像 GPT-Live 这样的新东西，想要尝试它，并且在不破坏生产环境的情况下进行尝试。

从更长远来看，这是基于结果的功能的基础原语。一旦通话被固定到特定版本，自动发布就能与统计实验并行推进。如果你有衡量转接率的结构化输出，就可以告诉 Vapi 仅在转接率保持稳定时才保留某个版本，一旦下降就回滚。虽然我们仍在评估这一功能的未来，但已有积极迹象表明，它将成为未来更高度自动化实验与自动化的基础。

如果你正在基于 Vapi 构建应用，不妨借此机会评估你的智能体，翻出那份你搁置已久的变更清单，把一部分流量导向它们。要了解如何设置你的第一次拆分，请前往文档。分享

目录