在 AI 驱动的呼叫中心系统中，电话代理需要处理复杂的用户交互，包括实时对话、意图识别和上下文维护。传统的无状态设计往往导致信息丢失，尤其在跨会话场景下，用户体验受损。设计持久状态机是关键解决方案，它能跟踪对话历史、用户意图和上下文，确保代理在断线后无缝恢复，并在多轮交互中提供个性化响应。使用 Azure Cosmos DB 作为后端存储，可以实现低延迟的检索和更新，支持高并发呼叫场景。
Azure Cosmos DB 是一种全球分布的 NoSQL 数据库，专为高性能应用设计，提供个位数毫秒的读写延迟和自动缩放能力。在 call-center-ai 项目中，它被用于存储对话数据，包括消息列表、claim（用户意图数据）、reminders（提醒事项）和 synthesis（对话摘要）。例如，项目架构显示，应用通过 Cosmos DB 保存实时流式对话，支持断线续传和历史引用。这确保了代理能基于过去交互 fine-tune LLM，提升响应准确性。Microsoft 文档强调，Cosmos DB 的代理内存模式将每个会话轮次作为文档存储，使用 threadId 作为分区键，实现高效的会话内查询，避免跨分区开销，从而维持低延迟。
证据表明，这种设计在实际部署中有效。call-center-ai 的演示显示，存储的 JSON 结构包含 created_at、action、content 和 persona 等字段，允许代理检索最近 N 轮对话作为上下文输入 LLM。同时，claim schema（如 incident_description、policy_number）持久化用户意图，确保代理在后续呼叫中直接引用，避免重复询问。文档中提到的向量搜索功能进一步增强了语义检索，例如通过嵌入匹配历史语句，实现 RAG（检索增强生成），让代理处理敏感数据时更智能。项目报告端点（如 /report/[phone_number]）证明了跨会话持久性，用户可查看完整历史和待办事项。
要落地这种持久状态机，需要关注几个关键参数和配置。首先，分区策略：选择 /threadId 或 /phone_number 作为分区键，确保同一会话数据本地化。推荐使用复合分区键如 ["/tenantId", "/threadId"] 支持多租户隔离，避免热分区问题。其次，吞吐量配置：初始 RU/s 设置为 1000-5000，根据呼叫峰值自动缩放。无服务器模式适合变负载场景，按需付费降低成本。索引策略：启用自动索引所有属性，但针对频繁查询字段（如 messages.content）配置范围索引，优化查询 RU 消耗。数据模型：每个文档代表一轮交互，包含 id（唯一）、threadId、turnIndex（递增计数器，用于排序最新 N 轮）、messages（数组）和 next（状态机下一步行动）。更新操作使用乐观并发控制，结合 ETag 防止冲突。
可落地清单包括：
- 初始化容器：创建容器时指定分区键 /threadId，索引策略为一致性索引，TTL 为 30 天（短期内存）或永久（长期内存）。
- 写入对话：每轮交互后，原子更新文档的 messages 数组，使用 Cosmos DB SDK 的 ReplaceAsync 方法，确保低延迟（<10ms）。
- 检索上下文：查询最新 10 轮，使用 ORDER BY c.turnIndex DESC LIMIT 10，结合 WHERE c.threadId = @threadId 过滤。
- 意图跟踪：在 claim 对象中定义 schema（如 type: datetime 的 incident_datetime），验证输入格式后持久化。
- 跨会话恢复：新会话启动时，查询历史 synthesis 和 reminders，注入 LLM 提示中。
- 监控点：集成 Application Insights，跟踪 RU 消耗、延迟和错误率；设置警报当 RU > 80% 时自动缩放。
- 回滚策略：使用 Cosmos DB 的变更馈送监听器检测失败更新，回滚到上一个版本；备份策略为连续备份，支持点-in-time 恢复。
此外，安全考虑不可忽视。启用 Azure AD 身份验证和角色-based 访问控制（RBAC），限制代理仅读写特定容器。数据加密使用客户管理的密钥（CMK），符合 GDPR 等隐私法规。对于低延迟优化，选择最近区域部署，并使用会话一致性级别平衡可用性和正确性。
这种设计不仅提升了 AI 电话代理的鲁棒性，还降低了运营成本。在 call-center-ai 项目中，结合 Azure Communication Services 和 OpenAI，实现 24/7 客户支持，处理保险理赔等复杂场景。未来，可扩展到多代理协作，使用 Cosmos DB 的图 API 建模代理间状态转移。
资料来源：