Load Bearing Empire用Supabase与VAPI自建AI技术栈

将六条完全不同的业务线——房产批发、拆除工程、代客泊车、信用修复、矿产权益和SaaS产品——统一到一套自研AI基础设施上，听起来像是一个疯狂的想法。但Load Bearing Empire做到了，而且他们没有依赖任何一家SaaS厂商。

为什么选择垂直整合而非SaaS拼装

Load Bearing Empire的六条业务线横跨硬件运营（拆除工程需要调度重型设备、代客泊车涉及实时物流）和数字服务（信用修复、SaaS产品），这种混合形态让标准化SaaS方案捉襟见肘。

传统做法是每个业务线单独选型：Twilio负责通信、SendGrid处理邮件、Make.com做自动化编排。问题在于，这些工具之间的数据同步是异步的，延迟从几秒到几分钟不等。对于需要实时调度拆除现场车辆或即时响应信用修复客户咨询的场景，这种延迟不可接受。

他们选择了一条更重的路：用Supabase作为统一数据层（98张表、42个Edge Functions），VAPI驱动26个自主AI代理，Asterisk 18.10 PBX处理电话系统，再加上一个名为JARVIS Brain Router的自研路由层来编排所有业务线的入站工作流。

这个决策的核心逻辑是：当你的业务跨越物理世界和数字世界时，数据同步的实时性比省下来的运维成本更重要。

技术栈拆解：每个组件解决什么问题

Supabase：不只是数据库

98张表和42个Edge Functions的规模说明Supabase在这套架构中承担的角色远超"托管Postgres"。Edge Functions负责处理各业务线的实时事件——比如拆除工程中设备状态的变更、代客泊车中车辆位置的更新——并将这些事件直接写入对应的数据表。

这种设计让所有业务线共享同一套数据基础设施，但又通过表结构隔离各自的业务逻辑。相比为每条业务线部署独立的数据库实例，运维复杂度大幅降低。

Supabase的Edge Functions是基于Deno运行时的无服务器函数，部署在靠近用户的边缘节点上。与传统的中心化云函数相比，边缘执行能显著降低网络延迟，这对于需要实时响应的事件驱动场景（如拆除现场的车辆调度、代客泊车的状态更新）尤为重要。在Load Bearing Empire的架构中，Edge Functions充当了“业务逻辑中间层”：它接收来自VAPI代理、Asterisk电话系统或前端应用的事件，执行业务规则后写入Postgres数据表，或触发其他Edge Functions。42个函数的规模表明，每条业务线的实时事件处理逻辑被拆分为多个细粒度函数，便于独立部署和调试。

VAPI与26个AI代理

26个自主代理覆盖六条业务线的客户交互场景。房产批发需要筛选潜在卖家，信用修复需要引导客户提交争议材料，代客泊车需要确认服务时间和地点——这些场景的对话逻辑差异很大，但底层都跑在VAPI的语音AI框架上。

统一框架的好处是代理之间的知识可以复用。比如信用修复场景中验证客户身份的逻辑，经过调整后可以用到矿产权益业务中。

VAPI（Voice AI Platform Interface）是一类专为语音交互场景设计的AI代理框架，它与传统IVR（交互式语音应答）系统的核心区别在于：传统IVR依赖预设的按键菜单和固定流程树，而VAPI这类框架基于大语言模型驱动对话，能够理解自然语言、动态调整对话路径，并在对话过程中实时调用外部API获取数据或触发业务动作。在Load Bearing Empire的架构中，每个AI代理本质上是一组提示词、工具调用定义和业务规则逻辑的封装，部署在VAPI运行时上。

Asterisk与JARVIS Brain Router

Asterisk 18.10作为开源PBX处理底层电话路由，JARVIS Brain Router则决定每通电话应该由哪个AI代理接管、需要调取哪些数据、以及后续触发什么工作流。这个路由层是整个架构的调度中枢。

Asterisk是一个开源软件PBX（Private Branch Exchange，专用交换机），它用软件替代了传统企业电话系统中的硬件交换机，支持SIP协议、呼叫路由、语音信箱、会议桥接等功能。18.10是其LTS长期支持版本。在AI代理场景中，Asterisk通常承担“最后一公里”的角色：负责接听或拨出电话、建立媒体流通道，然后将音频流交给AI代理处理。JARVIS Brain Router在这条链路之上增加了决策层——它不是简单的呼叫转接规则，而是根据来电号码、时段、业务标签等信息，动态判断应激活哪个AI代理、预加载哪些客户数据、以及对话结束后触发什么下游工作流。这种“PBX+智能路由层”的分工，让底层电话基础设施保持稳定，而业务逻辑的变更只需在路由层调整。

自托管与托管服务的权衡

部署在Vultr上意味着Load Bearing Empire需要自己处理服务器运维、安全补丁和扩容。作为交换，他们获得了对数据流向的完全控制权，以及与Asterisk等自托管组件的深度集成能力。

这种选择有明确的代价。团队需要具备DevOps能力来维护Vultr实例，Supabase的自托管版本也需要定期升级。对于没有技术团队的企业，这条路走不通。

但对于同时运营六条业务线、且业务之间需要实时数据交换的场景，自托管带来的集成灵活性超过了运维负担。

对AI基础设施选型的启示

Load Bearing Empire的案例指向一个趋势：当AI代理从单一场景走向多业务线部署时，基础设施的整合深度比单点工具的先进性更重要。

Twilio、SendGrid这些工具各自都很优秀，但它们的设计假设是"你是众多客户之一"。当你的业务需要跨系统实时协调时，这种假设就变成了瓶颈。

自建栈的门槛在降低——Supabase、VAPI、Asterisk都是开源或开放架构的产品——但整合它们的工作量仍然可观。关键决策点在于：你的业务是否真的需要实时数据同步？如果答案是肯定的，垂直整合的投入就是合理的。