Bolna 对话式语音代理

要解决的问题

传统语音代理开发中，团队需要分别对接电话网络、语音识别（ASR）、大语言模型（LLM）和语音合成（TTS）多个独立系统。每个环节都有自己的SDK、认证方式、延迟特性和错误处理逻辑。把这些组件串成一个端到端可用的语音对话系统，往往意味着大量胶水代码和复杂的本地配置。

技能如何工作

Bolna 通过一个基于 Docker Compose 的编排服务 将这些环节统一封装。核心思路是：把电话接入、ASR、LLM、TTS 各自抽象为可插拔的 provider 层，然后在统一的编排框架下协调它们的调用顺序和数据流转。

关键能力包括：

• 支持 Twilio 和 Plivo 两种电话提供商，覆盖主流 SIP 中继和号码管理方案
• 将 ASR、LLM、TTS 的凭证配置与核心服务解耦，便于切换不同供应商
• 提供 local_setup 容器化方案，把本地开发环境收敛到一套 docker compose 文件中
• 容器启动后即可通过编排接口创建代理并触发外呼

典型工作流：

1. 配置电话提供商账号（Twilio 或 Plivo），获取号码和凭证
2. 在编排服务中注册 ASR/LLM/TTS 提供商凭证
3. 定义代理的对话逻辑和语音参数
4. 通过接口指示代理发起呼叫

适用边界与注意点

• 本技能聚焦于编排层和部署层，不包含对话逻辑设计或提示词工程的最佳实践
• 本地测试电话功能需要 ngrok 等隧道工具，因为 Twilio/Plivo 要求公网可访问的回调地址
• 生产环境需要关注语音流的端到端延迟，ASR 和 TTS 的选择会直接影响对话自然度
• 当前编排方案以 Docker Compose 为主，大规模集群部署需要自行扩展
• 详细 API 文档和高级配置参考 Bolna 官方文档