8个AI Agent并发：Supabase Edge Functions与VAPI实战

为什么语音多Agent需要不同的架构思路

构建一个能同时处理8个AI语音Agent的生产系统，和搭一个Demo完全是两回事。Quiet Hours Valet Command Center 团队最近公开了他们的架构：前端部署在 Vercel，后端用 Supabase Edge Functions 承载 8 个自动化工作流，语音层通过 Asterisk PBX 对接 VAPI 完成编排。整套系统没有一台专用服务器，全部跑在无服务器函数上。

这个选择背后有一个关键判断：语音 Agent 的负载是突发且并发的，传统常驻服务器在空闲时浪费资源，在峰值时又容易成为瓶颈。Edge Functions 的按需执行模型恰好匹配这种模式——每个 webhook 事件触发一次函数执行，响应完即释放。但要让 8 个 Agent 在同一个项目里互不干扰地共享状态，光靠函数本身不够，他们用了一张 8 个表的 Postgres schema 来管理 Agent 状态。

边缘函数承载语音编排的实际约束

Edge Functions 的好处是冷启动快、天然分布式、和 Supabase 的 Postgres 与认证体系无缝衔接。但把语音编排放上去，团队必须处理几个现实问题。

第一是 webhook 的幂等性。VAPI 在语音通话过程中会推送大量事件——通话开始、转写片段、工具调用、挂断——同一个事件可能因为网络重试而重复到达。Edge Function 没有持久进程来去重，所以每个事件的处理逻辑必须自带幂等键，通常落在 Postgres 的唯一约束上。

第二是 Agent 之间的状态隔离。8 个 Agent 各自维护对话上下文、当前任务、工具调用历史，8 张表的分工正是为此：一张管会话生命周期，一张管转写记录，一张管工具调用结果，等等。这种拆法让每个函数的读写范围明确，减少了并发写冲突。

据原文描述，团队把路由逻辑也放在了 Edge Function 层：根据来电号码或 webhook 元数据决定把事件分发给哪个 Agent 的处理流程。这相当于在无服务器函数里做了一层轻量消息路由。

Webhook 幂等性是指同一事件因网络重试或重复推送而多次到达时，系统只处理一次、最终状态一致的能力。在无服务器架构中，函数实例随事件创建和销毁，没有常驻内存可以做去重缓存，因此团队通常把幂等键（如事件 ID 或业务主键）写入数据库唯一约束，让 Postgres 在插入时拒绝重复记录。VAPI 等语音平台在通话生命周期中会密集推送事件，幂等设计不到位会导致重复扣费、重复执行工具调用等生产事故，这也是语音 Agent 上云时必须优先验证的环节。

Asterisk 与 VAPI 的分工边界

语音栈的组成本身值得拆解。Asterisk PBX 负责传统电话网络的接入和信令，VAPI 负责语音 AI 的编排——语音识别、大模型推理、语音合成、打断处理。两者之间的边界是：Asterisk 管“电话怎么进来”，VAPI 管“对话怎么进行”。

这种分层的好处是电话侧的能力（号码、呼转、IVR）不需要在 AI 层重新实现，而 AI 层的迭代也不会影响电话接入的稳定性。对于需要接真实 PSTN 电话的语音产品，这是一个务实的组合。代价是两套系统之间的延迟叠加需要在端到端体验里被验证，原文没有给出具体的延迟数据。

Asterisk 是开源的 PBX（Private Branch Exchange，专用交换机）软件，负责 SIP 信令、PSTN 网关对接、号码管理、呼叫路由与 IVR 等传统电话能力。VAPI 则是面向语音 AI 的编排平台，封装了 ASR（语音识别）、LLM 推理、TTS（语音合成）以及打断（barge-in）处理。两者组合的典型模式是：Asterisk 把来电转成媒体流并桥接到 VAPI 的会话接口，VAPI 返回合成语音再经 Asterisk 回传给用户。理解这一分层有助于判断延迟来源——信令建立、媒体转码、AI 推理各占一段，端到端体验需要分段测量。

对搭建语音AI产品的启示

这套架构最值得借鉴的地方不是某个具体工具，而是“无服务器 + 外部状态存储”的组合思路。语音 Agent 的会话是有状态的，但函数是无状态的，把状态外置到 Postgres 让两者能够配合。8 个 Agent 并发听起来不多，但语音场景下每个会话都涉及持续的事件流，实际的事件吞吐远高于 Agent 数量本身。

如果你在做类似的垂直整合语音产品，可以优先验证三件事：webhook 幂等机制是否可靠、Agent 状态表的分工是否清晰、PBX 与语音编排层之间的延迟是否可接受。这三点决定了系统能不能从 Demo 走到生产。

原文没有披露成本数据、具体延迟指标或 8 个 Agent 各自的业务场景，这些是评估该架构完整度时缺失的信息。

无状态函数 + 外部状态存储是 Serverless 架构处理有状态业务的通用范式。函数本身不保存会话，所有上下文（对话历史、任务进度、工具调用结果）持久化到 Postgres 等外部存储，函数每次执行时按需读取和写回。这种模式的好处是水平扩展不受实例粘性限制，缺点是每次交互都多一次数据库往返，且并发写同一会话时需要行锁或乐观并发控制。语音场景下事件流密集，状态表的读写热点和冲突处理策略会直接影响系统的稳定性与延迟表现。