用AI栈整合六大业务：Supabase与VAPI自托管实战

为什么一个工程师要同时运行六种业务？

房地产批发、拆除服务、代客泊车、信用修复、矿产权益、SaaS——这六个看似毫不相干的业务，同时存在于一家名为 Load Bearing Empire 的公司旗下。创始人面临的现实问题是：传统 SaaS 堆栈在跨业务协同场景下迅速变得昂贵且笨重。

据该团队在技术博客中披露，此前他们依赖 Twilio、SendGrid 和 Make.com 进行通信、邮件与自动化，每月的 SaaS 开销超过 8000 美元，且集成延迟在跨业务调用时经常突破可接受阈值。更关键的是，数据被锁死在多个供应商的孤岛中，无法形成统一的业务逻辑层。

这促使他们做出一个果断决定：彻底拆除现有 SaaS 工具链，转向自托管 AI 栈。

自托管 AI 栈的核心架构

Supabase：单一事实来源

整套系统的数据层建立在一个 Supabase 实例之上，项目 ID 为 whxtjboruayowkqyjvcq。该实例包含 98 张数据表，覆盖六个业务线的所有实体关系，并运行着 42 个 Edge Functions 来处理业务逻辑。

这种“单实例多租户”的设计意味着：房地产批发中的卖家线索，可以直接触发信用修复业务的跟进流程；代客泊车客户的支付记录，也能实时同步到 SaaS 产品的订阅管理模块。跨业务逻辑不再需要第三方自动化平台来粘合，而是通过数据库内部的关系和函数完成。

Supabase 是一个开源的后端即服务（BaaS）平台，常被描述为“开源版 Firebase”。它的核心能力是基于 PostgreSQL 构建托管数据库，并在此基础上提供身份认证、自动生成 API、实时订阅、对象存储以及 Edge Functions（基于 Deno 的轻量无服务器函数）。与 Firebase 的封闭数据模型不同，Supabase 直接暴露标准 SQL 与关系模型，开发者可以写原生 SQL、使用外键、触发器和存储过程，也可以自托管整套服务。文中的“单实例多租户”正依赖这种关系型数据库能力：所有业务表都在同一 PostgreSQL 实例中，可以自由 JOIN、共享 RLS 策略与外键约束，从而让跨业务数据天然连通，而不必依赖外部自动化平台做同步。

VAPI 多智能体编排：26 个专用代理

语音交互层选用了 VAPI 的多智能体编排能力。团队部署了 26 个专用 AI 代理，分别对应不同运营流程。例如，拆除业务需要处理现场照片与报价，信用修复业务需要解析信用报告争议项——这些代理各自拥有独立的提示词、工具集和知识库，但共享同一个 Supabase 后端。

代理之间的通信不经过外部消息队列，而是直接读写 Supabase 中的共享状态表，从而将集成延迟压缩到 100 毫秒以下。

VAPI 是一个面向语音 AI 应用的编排平台，它把语音识别（STT）、大语言模型推理、语音合成（TTS）以及电话网络接入组合成端到端的语音代理管线。开发者可以为每个代理配置独立的提示词、工具调用（function calling）和知识库，再通过电话或 Web 接入。VAPI 的“多智能体编排”指多个代理可以分工协作：一个接听电话、一个检索知识、一个执行任务，再通过 SIP 或 API 把通话转交给更合适的代理。文中选择 VAPI 的关键在于它能通过 SIP 协议与自建 Asterisk PBX 对接，同时允许代理读写同一个后端数据库，从而避免把状态放在外部消息队列里。

Asterisk 18.10 PBX + Vultr：通信底座自建

为了完全摆脱 Twilio 的按分钟计费模式，团队在 Vultr 云服务器上自建了 Asterisk 18.10 PBX。这提供了 SIP 中继、通话录音、IVR 等基础电信能力，同时将通话数据直接写入自托管数据库。

VAPI 代理通过 SIP 协议与 Asterisk 对接，实现 AI 语音交互与传统电话网络的桥接。这套方案虽然增加了初期配置复杂度，但彻底消除了按量计费的通信成本。

Asterisk 是最知名的开源 PBX（私有分支交换机）软件，能让普通服务器扮演传统电话交换机的角色。它支持 SIP 中继、IVR、通话录音、会议、队列等能力，并可通过拨号计划（dialplan）和 AGI/ARI 接口与外部程序交互。自建 Asterisk 意味着你要自行承担电信运营商的角色：需要配置 SIP 中继供应商（话务落地）、处理 NAT/防火墙、管理编解码器和安全策略，还要保证服务的高可用。作为交换，你不再按分钟向 Twilio 这类 CPaaS 付费，所有通话数据也能直接写入自己的数据库。文中把 Asterisk 部署在 Vultr 上，属于典型的“IaaS + 开源电信软件”组合，适合通话量大、需要 AI 实时介入且对数据主权敏感的场景。

JARVIS Brain Router：跨业务逻辑中枢

最关键的组件是名为 JARVIS Brain Router 的自定义路由层。它负责根据来电号码、客户 ID 或业务标签，将请求分发到正确的 VAPI 代理，并在必要时串联多个代理完成跨业务工作流。

例如，一个矿产权益咨询电话可能先由权益评估代理处理，若客户同时是房地产批发线索，则路由层会自动创建跨业务任务。这种逻辑在 Make.com 时代需要大量 webhook 和条件分支，现在收敛为一个轻量路由服务。

成本对比：自托管到底省了多少？

团队给出的最直观数据是：每月消除 8000 美元以上的 SaaS 开销。这包括 Twilio 通信费、SendGrid 邮件费、Make.com 自动化订阅，以及此前为应对规模增长而购买的多个中台工具。

自托管侧的固定成本主要是 Vultr 服务器费用和 Supabase 自托管实例的运维投入。对于同时运行六个收入流的业务体量，这笔账显然划算。

更重要的是延迟指标：集成延迟从原先跨 SaaS 调用的数百毫秒甚至秒级，降至 百毫秒以内。对于语音交互场景，这直接决定了对话的自然程度。

传统初创技术栈为何在规模下失效

这篇文章的隐含论点是：以 SaaS 为中心的技术栈在跨业务复杂度上升时，边际成本急剧增加。

Twilio 和 SendGrid 按用量计费，当六个业务共享客户触达时，用量叠加迅速；Make.com 按操作次数收费，跨业务自动化场景下操作数成倍增长；更致命的是，每个 SaaS 工具都有自己的数据模型，跨工具关联需要额外开发。

自托管方案把这些成本内部化：通信走自己的 PBX，邮件走自建 SMTP，自动化逻辑写在 Supabase Edge Functions 和 JARVIS 路由里。从 Day One 就由一个工程师操作六条收入流，这本身就是对传统“先堆 SaaS 再优化”思路的否定。

Twilio、SendGrid、Make.com 这类 SaaS 的定价模型通常按使用量线性甚至阶梯式收费，例如 Twilio 按通话分钟加号码月租计费，SendGrid 按邮件发送量分级，Make.com 按“操作次数”收费。在单一业务线时，这种模式简单且可预测；但当六条业务线共享同一批客户触达时，通话分钟、邮件条数和自动化操作数会成倍叠加，账单增长往往快于收入增长。更隐蔽的成本是数据孤岛：每个 SaaS 维护自己的客户模型和 ID 体系，跨工具关联需要额外的同步任务或中间表，而这些“胶水代码”本身也需要开发和维护。自托管把这些变动成本转化为固定资产投入（服务器、运维时间），在业务量大且高度多元时更具经济性。

对 AI 原生基础设施的启示

Load Bearing Empire 的案例展示了“垂直整合 AI 栈”的一种极致形态：数据层自托管（Supabase）、语音层自建（Asterisk）、智能体层用 VAPI 编排、逻辑层用自定义路由串联。

这套架构并不适合所有团队——它要求创始人具备相当的后端与电信工程能力。但对于那些业务线多元、跨业务逻辑密集、且对延迟和成本敏感的运营型公司，这种“拆掉 SaaS，自建中枢”的路径提供了一个可参考的样板。

核心经验可以归纳为：统一数据层是跨业务 AI 自动化的前提，而自托管通信是消除按量计费焦虑的关键一步。