很多 Voice Agent 选型讨论一上来就问“哪家声音更自然”。这个问题太靠后了。真正决定 SaaS 还是自研的，通常是团队能否承担媒体链路、数据留存、故障恢复和供应商替换，而不是 Demo 里那几句回答听起来像不像真人。

我的建议是先把“业务要交付什么”和“团队愿意长期维护什么”分开。小团队要在几周内验证电话客服闭环，托管平台通常更省启动成本；如果团队需要掌握电话媒体、端点检测、模型路由和数据平面，且有持续运维能力，自研或混合方案才有意义。两者之间没有一张永久有效的排行榜。

本文用一个无厂商分数的决策矩阵，拆解国际 Voice Agent 平台公开文档中常见的能力边界，再判断中文客服落地时应该把哪些能力留在平台、哪些能力收回自己的服务层。文中的代码只验证选择逻辑，不包含价格、性能或厂商效果结论。

目录

• 先定义交付结果，而不是先选模型
• SaaS 和自研分别把什么交给谁
• 国际平台公开能力能说明什么
• 中文客服最容易低估的四个成本
• 一个不打分的决策矩阵
• 三种架构什么时候适用
• 如何做八周内的验证
• 参考资料和事实边界

先定义交付结果，而不是先选模型

选型输入最好先写成一张交付清单：

交付问题	要求写清什么
先服务谁	入站客服、销售外呼、售后回访还是内部助手
通过什么线路	PSTN、SIP、浏览器 WebRTC 或已有呼叫中心
要保存什么	音频、转写、工具调用、工单状态、审计日志的留存边界
失败如何处理	超时、转人工、重试、回调丢失和人工补偿
哪些动作可自动化	查询、预约、改址、退款、关闭工单分别需要什么权限
何时算成功	任务完成、字段确认、人工接管还是数据回流完成

如果这些问题还没有答案，直接比较模型自然度只会把不确定性推迟到上线之后。

SaaS 和自研分别把什么交给谁

托管 SaaS 通常把电话接入、会话编排、模型连接、扩缩容和部分观测能力交给平台，团队可以更快验证业务话术和工具调用。代价是平台边界、数据位置、故障处置和供应商 API 变更需要纳入合同和架构评审。

自研并不等于“自己训练一个模型”。更常见的是自己负责会话服务、媒体接入、模型适配器、策略状态、工具权限、数据平面和部署；ASR、LLM、TTS 仍可能来自不同供应商。它换来的是更强的控制力，但也把连接断开、队列堆积、P95 延迟、重试和灰度回滚都变成自己的责任。

混合架构往往更容易渐进：先使用托管通话基础设施，把 CRM、RAG、策略状态和审计留在自己的服务层；等真实故障样本足够多，再决定是否替换媒体或模型层。混合不自动更便宜，它只是把替换点提前设计出来。

国际平台公开能力能说明什么

公开文档只能证明平台提供了某种接口或抽象，不能证明它在你的中文电话样本上一定达到某个延迟或成功率。

例如，Vapi 文档公开了自定义工具、Webhook、API 请求和电话助手等能力；这说明它适合把业务动作接到自己的 API，但仍需验证中文字段确认、重试和 CRM 审计如何落地。LiveKit Agents 文档公开了代码化 Agent、工具、Agent Server、工作流和多模型接入；这说明它给开发团队更大的编排空间，同时也意味着部署、观测和媒体链路需要更强的工程能力。

这些资料适合用来确认能力边界，不适合作为“更适合中文客服”的直接结论。选型时要把官方能力、自己的电话样本和合同/合规约束放在同一张评审表中。

中文客服最容易低估的四个成本

第一是字段确认。手机号、订单号、金额和地址在电话窄带、方言和口音环境下都可能被 ASR 误写。无论使用 SaaS 还是自研，都需要数字规整、回读确认和错误纠正。

第二是人工交接。中文客服的投诉、身份争议和赔付请求不能只靠“transfer call”按钮解决，还要带上已确认字段、失败原因、用户原话摘要和当前策略状态。

第三是延迟归因。平台给出的某个响应时间，通常不能替代自己的 t0-t8 埋点。分句、TTS 首包、播放队列和网络抖动仍可能造成用户体感慢。

第四是数据边界。录音、转写、CRM 字段和调试日志的留存方式可能不同。平台能力再完整，也不能替业务方回答数据驻留、租户隔离、删除、审计和供应商退出问题。

一个不打分的决策矩阵

不建议一开始给平台打 95 分、给自研打 80 分。先把需求转换成可验证条件：

from examples.decision_matrix import Requirements, decide

requirements = Requirements(
    time_to_first_call="weeks",
    custom_media_pipeline=False,
    strict_data_residency=True,
    telephony_control="low",
    ops_capacity="small",
    provider_swap_required=False,
    audit_requirement="strict",
)

decision = decide(requirements)
print(decision.choice)
print(decision.reasons)
print(decision.gates)

矩阵只做三件事：识别小团队的启动约束、识别需要媒体或数据控制权的需求、把数据驻留和审计列为闸门而不是厂商加分项。它不会替你选择具体供应商，也不会用假设价格计算投资回报。

三种架构什么时候适用

先用 SaaS 验证闭环

适合目标是几周内跑通入站客服、预约、简单查询，团队暂时没有媒体和平台运维能力的情况。上线前仍要做中文号码、地址、打断、转人工和 CRM 回流测试。

自研会话和数据平面

适合已有实时音频、服务编排、观测和安全团队，并且需要自定义状态机、模型路由、数据留存或供应商替换的情况。不要把“能写 Python”误认为“能运维实时系统”。

混合架构

适合想先利用托管媒体和电话接入、同时把业务策略、RAG、CRM 和审计掌握在自己手里的团队。接口边界要先统一：ASR event、turn state、tool call、handoff 和 feedback 不能直接绑定某一家 SDK 的对象。

如何做八周内的验证

可以把验证分成四个阶段：

1. 第 1 周：固定中文客服样本，定义字段、风险和转人工条件。
2. 第 2～3 周：用同一批录音和电话脚本验证 ASR、TTS、打断与工具调用。
3. 第 4～5 周：验证 CRM、RAG、人工交接、日志和数据删除路径。
4. 第 6～8 周：在受控流量下观察 P95 延迟、字段错误率、重复解释率、转人工完整率和故障恢复。

每阶段只改变一个主要变量。不要同时换平台、模型、Prompt 和电话线路，否则最后无法归因。

项目测试命令：

python3 -m unittest discover -v

5 项测试只验证矩阵的选择逻辑和数据闸门；它不代表任何平台性能。

参考资料和事实边界

• Vapi：Tools
• Vapi：Introduction
• LiveKit Agents：Introduction
• LiveKit Agents：Tool definition and use

买 SaaS 还是自研，不是一次性技术偏好投票，而是对交付节奏、控制权和长期运维责任的取舍。先把可验证条件写出来，平台和架构才有比较的基础。