企业官网建设流程全解析

Dograh电话转接（Transfer Call）实战：AI与人工无缝协作的呼叫中心架构

【免费下载链接】dograhOpen source voice AI platform. Self-hosted alternative to Vapi and Retell. On Prem, BYOK across Speech to Speech or LLM/STT/TTS, with a visual workflow builder, MCP native and telephony support.项目地址: https://gitcode.com/GitHub_Trending/do/dograh

Dograh 是一款开源、可自托管的 AI 语音平台（Vapi / Retell 的自部署替代方案），其Transfer Call 电话转接工具让 AI 语音代理在通话中把真实电话无缝转给人工坐席、部门队列或 SIP 端点，是实现"AI 处理常规问题、人工接手复杂问题"人机协作呼叫中心架构的核心能力。本文将用最少配置带你跑通三种转接模式。

📞 为什么呼叫中心需要"AI + 人工"电话转接

在真实呼叫中心中，来电往往是混合的：70% 的咨询（查账单、问营业时间）AI 能独立解决，剩下 30%（投诉升级、大客户续费）必须交给真人。

电话转接工具的价值就在于：由 LLM 在对话中自主判断"什么时候该转人工"，并调用转接工具完成移交。整个流程对通话双方几乎无感——

1. AI 代理判断需要人工介入，调用 Transfer Call 工具
2. Dograh 解析出转接目的地（号码 / SIP 端点）
3. 播放一句预转接提示语（如"正在为您转接人工客服"）
4. 通过电话供应商（Twilio / Telnyx / Asterisk ARI）拨打目的地
5. 主叫方听到保持音乐
6. 目的地接通后桥接双方，AI 退出通话

⚠️ 注意：电话转接仅支持 Twilio、Telnyx、Asterisk ARI 三种电话供应商的电话通话，Web 网页通话暂不支持。

🧭 三种目的地模式：从简单到智能

每个 Transfer Call 工具必须选择一种目的地来源，复杂度按需递增：

模式一：静态 / 模板（Static / Template）

转接目标事先已知，最简单的方案：

• 固定 E.164 号码，如+1234567890
• SIP 端点，如PJSIP/sales-queue（仅 Asterisk ARI）
• 上下文模板变量，如{{initial_context.transfer_destination}}，通话开始前就指定去向

适合"固定投诉热线"、"固定技术支持线"这类场景，5 分钟就能配好。

模式二：上下文映射（Context Mapping）

当 AI 在通话中收集到的变量应决定转接方向时，用它最顺手。你可以添加多条有序规则，Dograh 从上到下逐条匹配（忽略大小写和首尾空格），命中第一条规则即生效。

规则示例：

字段不带前缀时（如department），Dograh 优先读取gathered_context.department（通话中提取到的值），缺失时回落到initial_context.department。所有规则都不匹配时使用可选的 fallback 目的地；若连 fallback 也没配，转接会在拨号前失败，AI 可以继续通话而不会挂断客户——这是很贴心的降级设计。

模式三：动态 HTTP 解析器（Dynamic HTTP Resolver）

当转接目标必须在对话过程中由你的业务系统决定时（按区域路由、按客户等级路由、查 CRM 找对应客户经理），用动态解析器。

调用时序：

1. Dograh 向你的 HTTPS 端点发POST，请求体是扁平 JSON，由两部分组成：
   • LLM 参数：AI 从对话中提取的值，如billing_issue_type、requested_department
   • 预设参数：Dograh 从上下文模板注入的值，如{{initial_context.account_id}}（同名键时预设参数优先）
2. 你的端点返回：

{ "transfer_context": { "destination": "+18005550199", "custom_message": "正在为您转接企业账单团队，请稍候。" } }

3. Dograh 播放custom_message（若未返回则播放你配置的通用预转接提示），然后开始拨号

关键细节：Dograh不会把完整通话记录发给你的解析器，只发你声明过的参数——既省流量也保护隐私。解析器超时、返回非法 JSON 或缺少destination时，转接优雅失败，AI 继续接待来电者。相关实现见 transfer_resolver.py。

🔌 实战：把企业客户的账单电话转给专门团队

下面是一套"生产级"配置思路，参考官方示例 call-transfer.mdx：

1. 在节点提示词中写清转接时机，例如"当客户明确表示是账单争议或退款请求时，调用 Transfer Call 工具"
2. LLM 参数声明billing_issue_type（必填，描述写清楚可取值：invoice_dispute/payment_failed/refund_request）和requested_department（选填）
3. 预设参数注入account_id、plan（来自initial_context）
4. Resolver URL指向你的路由服务，你的后端根据plan == enterprise决定转接企业账单组还是普通账单组
5. 配置Resolver Wait Message（如"请稍等，我正在为您寻找合适的团队"），避免等待期间冷场

把工具挂载到工作流节点后即可保存：


路由完成后，你可以在 Agent Runs 的通话记录里完整回看 AI 转接前后的每一句话和工具调用，方便复盘与质检：

🏢 进阶：对接 VICIdial 等呼叫中心系统

如果你的企业已有 VICIdial 呼叫中心，Dograh 通过 Asterisk ARI 接入后，Transfer Call 的上下文映射可以直接路由到VICIdial in-group（如sales），并支持source回落到来电原始组。此外还能在转接/挂断前把 AI 收集到的变量（如extracted_variables.customer_state）写回 VICIdial 的 lead 字段，实现"AI 处理的线索和人工处理的线索进同一套报表"。完整步骤见 VICIdial 集成文档。

转接事件在电话侧的协议定义位于 transfer_event_protocol.py，前端配置界面见 TransferCallToolConfig.tsx。

✅ 配置清单与排错速查

最佳实践

• 解析器延迟控制在 2–3 秒内，超过就配上等待话术
• 上下文映射规则最具体的放最上面，fallback 只在"任何未匹配值都安全"时才配
• LLM 参数描述写明确，AI 才知道该提取什么
• 上线前同时测试转接成功和解析器失败两条路径
• 路由依赖账户数据时，把逻辑放在你的后端，别硬编码号码

常见问题

🎯 小结

Transfer Call 工具把"AI 何时转人工"的判断交给 LLM，把"转给谁"的策略交给三种目的地模式，把"转接后"的数据回流交给 PBX 集成——三层解耦正是 AI 与人工无缝协作的呼叫中心架构关键。对于新手，建议从静态转接跑通第一通测试电话，再逐步升级到上下文映射和动态解析器。

延伸阅读

• Call Transfer 官方文档
• 工具系统总览
• VICIdial 集成指南
• End Call 工具文档

【免费下载链接】dograhOpen source voice AI platform. Self-hosted alternative to Vapi and Retell. On Prem, BYOK across Speech to Speech or LLM/STT/TTS, with a visual workflow builder, MCP native and telephony support.项目地址: https://gitcode.com/GitHub_Trending/do/dograh