# 通过 API 驱动的 AI 电话代理：Call-Center-AI 的 outbound 呼叫工程实践 > 基于 Microsoft Call-Center-AI，利用简单 API 调用发起 AI 代理电话，支持实时语音交互、自定义 claim schema、状态持久化和断线续传，提供落地参数与部署清单。 ## 元数据 - 路径: /posts/2025/11/30/api-driven-ai-phone-agent-call-center-ai/ - 发布时间: 2025-11-30T11:02:48+08:00 - 分类: [ai-systems](/categories/ai-systems/) - 站点: https://blog.hotdry.top ## 正文 在呼叫中心场景中，AI 代理通过 API 直接拨打用户电话，能显著提升自动化响应效率，避免人工调度瓶颈。这种 API 驱动的 outbound calling 方式，让开发者只需一次 HTTP POST，即可配置 bot 身份、任务目标和数据 schema，即刻启动实时语音对话，支持复杂交互如信息采集、问题诊断和后续提醒生成。 核心实现依赖 Azure Communication Services 处理 inbound/outbound 呼叫，结合 Cognitive Services 的实时 STT（Speech-to-Text）和 TTS（Text-to-Speech），前端通过 OpenAI GPT-4o-mini 或 GPT-4o 模型驱动对话逻辑。系统架构为 serverless Container App，支持流式传输：用户语音实时转文本注入 LLM，bot 响应即时合成语音回传，避免传统批处理延迟。repo 中强调，“Send a phone call from AI agent, in an API call”，这使得集成门槛极低，适用于保险理赔、IT 支持等场景。 实际发起呼叫的 API 调用如下，使用 curl POST 到 /call 端点，传入 JSON payload： ```bash data='{ "bot_company": "Contoso", "bot_name": "Amélie", "phone_number": "+11234567890", "task": "Help the customer with their digital workplace. Assistant is working for the IT support department. The objective is to help the customer with their issue and gather information.", "agent_phone_number": "+33612345678", "claim": [ {"name": "hardware_info", "type": "text"}, {"name": "first_seen", "type": "datetime"}, {"name": "building_location", "type": "text"} ] }' curl --header 'Content-Type: application/json' --request POST --url https://your-domain/call --data $data ``` 关键参数解析： - **bot_company & bot_name**：定义代理身份，注入提示模板中，提升对话自然度。 - **phone_number**：目标拨打号码，支持 E.164 格式。 - **task**：英文任务描述，指导 LLM 行为，如“采集理赔信息并生成待办”，覆盖整个通话目标。 - **agent_phone_number**：可选，转接人工 fallback 号码。 - **claim**：数组定义数据 schema，每项包含 name（字段名）、type（text/datetime/email/phone_number），可选 description。bot 会自动验证并填充数据，确保结构化输出。 这种 schema 驱动采集机制是亮点：LLM 不止聊天，还强制提取指定字段，避免信息遗漏。例如 IT 支持场景，采集 hardware_info 和 building_location，后续存入 Cosmos DB，便于 CRM 集成。 实时交互参数需通过 App Configuration 的 feature flags 调优，支持热更新（TTL 60s）： - **answer_hard_timeout_sec=15**：LLM 无响应超时，发送错误提示后重试。 - **answer_soft_timeout_sec=4**：软超时，播放等待音（如音乐+beep）。 - **phone_silence_timeout_sec=20**：用户静默阈值，bot 主动提示。 - **vad_threshold=0.5**（0.1-1）：语音活动检测灵敏度，vad_silence_timeout_ms=500ms，vad_cutoff_timeout_ms=250ms。 - **recognition_retry_max=3**：STT 失败重试上限，recognition_stt_complete_timeout_ms=100ms。 这些参数直接影响用户体验：过低超时易中断，过高增延迟。建议从默认起步，结合 Application Insights 监控 call.answer.latency（用户说完到 bot 回应的端到端时延）和 call.aec.droped（回声消除丢帧）指标迭代。启用 recording_enabled=true 后，录音存 Azure Storage，便于 QA。 状态管理是工程化核心：每轮交互存 Cosmos DB，包括 messages（带 persona/timestamp/action）、claim（填充值）、next（行动如 case_closed + justification）、reminders（带 due_date_time/owner）。通话后，通过 GET /report/{phone_number} 获取 JSON 报告或 HTML 视图，包含 synthesis（short/long 摘要、satisfaction）。支持断线续传：历史上下文从 Redis 缓存和 DB 恢复，确保无缝。 部署清单（Azure 前提：Communication Services + 号码）： 1. 创建资源组（如 cc-ai-rg），Communication Services（同名，system managed identity）。 2. 购买号码（inbound/outbound + voice/SMS）。 3. 配置 config.yaml：填入 endpoint keys（OpenAI、Speech、Search for RAG）、image_version（如 main）。 4. `make deploy name=cc-ai-rg`，自动 Bicep IaC 部署 Container App、Cosmos、Redis 等。 5. 本地开发：`make deploy-bicep deploy-post`，devtunnel 公网暴露，uv run local.py 热重载测试。 6. 监控：Application Insights 追踪 LLM token/latency，OpenLLMetry 语义指标。 风险与限界：POC 阶段，成本估算 1000 通话×10min ≈720 USD/mo（主导 Cosmos RU/s + Speech），生产需 vNET/private endpoint 增支。延迟瓶颈在 LLM TTFT（建议 PTU 或 gpt-4o-mini），无 LLM 框架直接用 OpenAI SDK 自定义工具/重试。优化路径：fine-tune 历史数据、A/B 测试 prompts、RAG 注入领域知识（AI Search index）。 落地此方案，可快速构建 24/7 AI 呼叫中心，API 抽象复杂度，参数化确保可控。通过自定义 prompts（如 tts.hello_tpl 多变体）和 claim schema，适配保险/IT/客服多场景。未来扩展：IVR 菜单、SMS 跟进（Twilio 兼容）。 **资料来源**： - [Microsoft Call-Center-AI GitHub Repo](https://github.com/microsoft/call-center-ai)（主要事实与示例） - 项目 demo 与 architecture 文档。 ## 同分类近期文章 ### [NVIDIA PersonaPlex 双重条件提示工程与全双工架构解析](/posts/2026/04/09/nvidia-personaplex-dual-conditioning-architecture/) - 日期: 2026-04-09T03:04:25+08:00 - 分类: [ai-systems](/categories/ai-systems/) - 摘要: 深入解析 NVIDIA PersonaPlex 的双流架构设计、文本提示与语音提示的双重条件机制，以及如何在单模型中实现实时全双工对话与角色切换。 ### [ai-hedge-fund：多代理AI对冲基金的架构设计与信号聚合机制](/posts/2026/04/09/multi-agent-ai-hedge-fund-architecture/) - 日期: 2026-04-09T01:49:57+08:00 - 分类: [ai-systems](/categories/ai-systems/) - 摘要: 深入解析GitHub Trending项目ai-hedge-fund的多代理架构，探讨19个专业角色分工、信号生成管线与风控自动化的工程实现。 ### [tui-use 框架：让 AI Agent 自动化控制终端交互程序](/posts/2026/04/09/tui-use-ai-agent-terminal-automation/) - 日期: 2026-04-09T01:26:00+08:00 - 分类: [ai-systems](/categories/ai-systems/) - 摘要: 详解 tui-use 框架如何通过 PTY 与 xterm headless 实现 AI agents 对 REPL、数据库 CLI、交互式安装向导等终端程序的自动化控制与集成参数。 ### [tui-use 框架：让 AI Agent 自动化控制终端交互程序](/posts/2026/04/09/tui-use-ai-agent-terminal-automation-framework/) - 日期: 2026-04-09T01:26:00+08:00 - 分类: [ai-systems](/categories/ai-systems/) - 摘要: 详解 tui-use 框架如何通过 PTY 与 xterm headless 实现 AI agents 对 REPL、数据库 CLI、交互式安装向导等终端程序的自动化控制与集成参数。 ### [LiteRT-LM C++ 推理运行时：边缘设备的量化、算子融合与内存管理实践](/posts/2026/04/08/litert-lm-cpp-inference-runtime-quantization-fusion-memory/) - 日期: 2026-04-08T21:52:31+08:00 - 分类: [ai-systems](/categories/ai-systems/) - 摘要: 深入解析 LiteRT-LM 在边缘设备上的 C++ 推理运行时，聚焦量化策略配置、算子融合模式与内存管理的工程化实践参数。