我现在在出站呼叫API中主要关注的是那些枯燥的失败情况

最近我一直在研究一些出站呼叫API/ AI电话代理项目，我开始觉得演示可能是最没用的部分。每个语音代理演示看起来都差不多：代理呼叫商家，然后人接听，代理提问，可能有个不错的文字记录出现，看起来很酷！但这并没有告诉我多少关于我是否真的会把它放进自动化工作流的信息。而且，在文档的某个角落，可能有些对我来说更有用的东西……并发性、重试行为、语音信箱时会发生什么、录音保存多久、API是否区分错误请求和电话故障、API密钥应该放在哪里等等。看到这些项目在YC W26中出现后，我最终阅读了voygr和placeCall的文档，那部分实际上让我继续读下去。较少的是“AI可以呼叫商家”这点，更多的是围绕它的操作状态。例如，如果你在构建商业呼叫自动化，文字记录可能不应该悄悄地成为你的永久数据库。如果呼叫是在检查供应商报价或预订可用性，我宁愿在我的系统中保留：标准化结果、来源/证据引用、呼叫状态、时间戳，然后将提供商的文字记录/音频视为临时证据。队列处理也是如此。PlaceCall在呼叫进行时保留积分，有并发限制，并为速率限制、积分不足、无效任务数据等提供不同的失败类型。这比一个通用的call_failed = true更有用。对于一个真正的语音代理API，我可能希望状态更接近于：queued、dialing、ivr、on_hold、human_answered、needs_input、completed、failed，然后根据不同失败原因采用不同的重试逻辑。IVR/保持处理也是如此。这就是这些系统让我感兴趣的地方。呼叫一个号码很容易。但要应对电话树、接待员、转接、保持音乐、模糊回答，并仍然返回结构化的呼叫结果，这才是实际的系统问题。所以显然placecall是我一直在研究的一个项目，但我很好奇其他人是如何评估出站呼叫API的，想讨论一下，在信任AI电话代理进行实际供应商呼叫、库存检查、预订或本地商业工作流之前，你们会检查哪些枯燥的字段/失败模式？