为什么我们为 AI 应用重建了自己的 messaging stack

Source: Dev.to

AI 应用改变了消息的使用方式

传统的消息平台是为人类驱动的通信设计的。一个用户一次发送一条消息。定价、API 和工具都是围绕这一假设演进的。

AI 应用并不是这样工作的。

对话是由代理和工作流自动生成、路由、重试和管理的。一次用户交互可能触发多个后台消息、重试、分类或后续操作。消息成为执行图的一部分，而不是单一动作。

大多数 CPaaS 堆栈并未为这种模型设计，尤其是当定价与每条消息的使用量挂钩且提供商碎片化时。

定价首先失效

一旦涉及 AI 代理，每条消息的定价很快就变得不可预测。消息不再是价值的代理。它们中的许多是内部的、瞬时的，或属于自动化逻辑的一部分。

真正重要的是系统实际为多少用户提供服务，以及为发送这些消息所需的底层运营商成本。

这就是我们放弃单纯的消息计数，改为围绕 MAU（月活跃用户）并结合透明的运营商直通费用来重构定价的原因。这种模型更符合 AI 应用的扩展方式，也让成本更易于理解和预测。

自动化需要快速访问渠道

当你用 AI 自动化通信时，通常不在乎具体的提供商或设置步骤。你只想使用用户已经在使用的渠道。

在很多情况下，这意味着 WhatsApp 或 SMS，而这需要一个电话号码。获取该号码应当快速、简单且可预期。等待数天、与外部供应商打交道或在碎片化的仪表盘中摸索，都会打断开发流程，拖慢实验速度。

我们将电话号码的供应做成平台的一级功能。开发者可以获取 API 密钥、申请号码，并在几分钟内开始发送消息。一切默认协同工作，使团队能够专注于构建 AI 工作流，而不是搭建基础设施。

重构开发者体验

现代开发者工作流期望干净的抽象、强类型和可预测的行为。消息 API，尤其是 WhatsApp，往往碎片化、不一致且难以推理。

我们从零开始重建了开发者体验，提供现代 SDK 和更简洁的原语。目标是屏蔽提供商特有的怪癖，暴露出一个一致的接口，自然融入 AI 驱动的系统。

我们不是把 AI 工作流适配到传统 CPaaS 的限制上，而是围绕当下 AI 应用的实际构建方式来设计消息层。

这带来了什么

重建整套系统让迭代更快、架构更简洁，消息不再成为瓶颈。团队可以专注于代理、工作流和产品逻辑，而不是应付定价惊喜和提供商管理。

这项工作最终形成了 Zavu，一个为 AI 应用和现代通信 SaaS 设计的统一消息 API。

你可以在 了解更多信息，并在 查看文档。

如果你正在构建 AI 驱动的产品，且在 CPaaS 的复杂性、定价或开发者体验上遇到困扰，欢迎告诉我们你的痛点。