使用 Twilio + Claude API 构建了一个支持人工接管的 WhatsApp AI 代理，一些关键要点

一直在构建一个 WhatsApp 代理系统，该系统能够处理自主 AI 响应，但当潜在客户符合条件时，允许人工操作员接管特定对话。路由逻辑很简单，但我想要讨论的一个关键点是 Twilio 签名验证，因为我看到很多人经常跳过这一步，而这实际上是一个攻击面。流程是：传入的 WhatsApp 消息到达一个公共隧道（开发时可使用 ngrok，生产环境则使用真实服务器），然后进入 FastAPI 端点，在处理任何内容之前，首先要做的就是针对 `X-Twilio-Signature` 头部进行签名验证。如果该检查失败，端点返回 403，并且不会执行任何其他操作。不会调用 AI，不会写入数据库，什么都不会。为什么这很重要：如果你运行的一个代理能够写入数据库并发送出站消息，那么一个未经认证的、处理任意 POST 主体的端点，根据你的代理工具的作用范围，可能会带来远程代码执行风险。签名验证是让你的 Webhook 免受恶意构造的、看似 Twilio 事件的负载攻击的唯一屏障。我看到很多人编写的自主 AI 代理完全忽略了这一部分，所以如果你不想烧光你的 Twilio 余额，真的需要提前设置好这一点。SQLite 模式以电话号码为键存储对话，并将消息追加到线程中。当代理生成响应时，该线程中的最后 N 条消息会作为上下文传递，这样模型就不会在每轮对话中盲目判断。人工/代理模式切换只是对话记录上的一个标志，端点在决定是调用 Claude API 还是跳过等待仪表板的手动输入之前会检查它。困扰我的一点是：当你在 Twilio 中注册 WhatsApp 发送方时，Webhook URL 位于发送方配置上，而不是消息服务配置上。如果你同时使用消息服务 SID 进行多通道路由（将 SMS、WhatsApp、Messenger 整合到一个服务中），请确保你了解哪个 Webhook 优先。根据我的经验，发送方级别的 URL 会覆盖服务级别的 URL，这导致我花了很长时间调试为什么服务级别的 Webhook 更新没有被生效。还有其他人通过 Twilio 在 WhatsApp 渠道上运行人机回环（human-in-the-loop）吗？好奇你们用什么实现模式切换的持久化，是像我一样使用数据库标志，还是使用 Twilio 层的 TaskRouter 之类的功能？