披着大衣的三个机器人并非全渠道

最有趣的一点是，我们一直在默默运行着一种架构，而行业其他参与者才刚刚意识到它的存在。一位竞争对手最近推出了实时短信摄入功能。媒体报道得如痴如醉。所有人都为之疯狂。如此创新。革命性。颠覆行业。而我？我看着我们的代码库，心想：“短信摄入？哇。这都 2025 年了。” 以下是我们实际构建的，并且已在生产环境中运行了大半年之久的系统。在语音通话中途，Elba 会向来电者发送一条包含短链接的短信。来电者在手机上填写表单。结构化数据通过 RPC 返回到正在进行的通话中。工作流接收到干净的 JSON 数据。语音通话从未暂停。代理从未丢失会话状态。来电者在继续通话的同时提交了表单，而代理则在同一个对话轮次中对此做出了响应。 这并非所谓的短信摄入。这是在同一活动会话内部实现的双向渠道桥接。在通话期间发送短信并非新鲜事。将结构化数据实时回传至活动会话，且不会在任一方丢失状态——这才是其他竞争对手尚未交付的功能。而且，这一功能建立在更为基础的核心之上。 大多数所谓的“全渠道 AI”不过是披着大衣的三个机器人。一个语音代理、一个 WhatsApp 机器人、一个网页聊天插件，它们都指向同一行 CRM 数据，并称之为统一系统。但它们各自拥有独立的提示词、独立的配置、独立的版本历史以及各自的故障模式。 Elba 只有一个代理。一个工作流。一个记忆层。语音、WhatsApp、短信、电子邮件和网页聊天都通过相同的执行引擎运行。不是副本。不是同步的版本。无论对话来自哪个渠道，都是同一个代理、同一套逻辑、同一段记忆。 部署是原子的——每个渠道都在同一事务中切换到新的工作流版本。没有偏差。不会出现“WhatsApp 机器人是否获得了更新”这类事故。只有一条审计线索。当受监管的企业客户询问在过去六个月内，他们的 AI 在各个渠道和各个会话中究竟对顾客说了什么时，我们能够提供唯一且清晰的答案。 而竞争对手们则宣布实现了短信摄入功能，并将其称为突破。