用 WebRTC 跑 GPT-Realtime 2.1 模拟审问，这种低延迟的心理博弈感太强了

最近在尝试一套基于 OpenAI gpt-realtime-2.1 构建的 AI 侦探审问系统，最直观的感受是：语音到语音（Speech-to-Speech）的实时交互，在营造“心理博弈”氛围上，确实比传统的文本输入要震撼得多。在这种低延迟的对话模式下，AI 嫌疑人在面对质询时的反应极其自然，完全没有那种“等待生成”的停顿感，这种沉浸感让整个审问过程像是在面对一个真实的、有情绪波动的嫌疑人。

很多 AI 角色扮演类游戏最容易掉进去的坑就是模型太“宽容”。只要玩家稍微引导一下，或者用一些暗示性的词汇，AI 往往会迅速妥协并承认错误，导致整个推演过程缺乏挑战性，像是在走形式。而这个项目最硬核的地方在于，它并没有把所有逻辑都交给一个模型，而是通过 Tool Call（工具调用）机制构建了一套严谨的“指控-审核”工作流。

在具体的审问逻辑中，当你尝试指控某个嫌疑人时，AI 并不是在对话流中直接决定是否认罪，而是会触发一个特定的工具调用。它会将你指控的对象以及你口头陈述的证据清单记录在案。关键的设计在于，系统在后台部署了一个由 gpt-4o-mini 驱动的“法官”角色。这个法官不参与任何对话，它像一个隐形的裁判，只负责在后台审核证据的有效性。

如果你在审问时只是在瞎猜，或者试图用模糊的词汇套话，法官角色会直接判定证据不足。这意味着你必须准确地陈述出案件中的关键事实，虽然表述方式可以灵活，但必须包含实质性的证据支撑才能最终结案。这种“双模型协作”——一个负责扮演、一个负责判定事实——的设计，有效地避免了 AI 随意妥协，极大地提升了逻辑推演的快感。

从技术栈来看，这套方案是典型的现代 AI 应用组合：前端采用 Next.js，数据库选用 MongoDB，而最关键的实时语音传输则通过 WebRTC 协议实现。正是 WebRTC 的加入，才保证了语音流的极低延迟，让“实时对峙”成为可能。

不过，gpt-realtime-2.1 的 Token 消耗确实惊人，在工程化部署时，开发者采取了一些非常务实的限制措施。首先是引入了 Clerk 进行身份验证，通过绑定用户 ID 来严格限制每个人的额度。其次，为了防止有人恶意挂机导致余额瞬间被跑光，系统在部署时特意加入了一个 30 分钟的强制定时器，到时自动切断。

这次体验给我最大的启发是，未来的 AI 交互应用不应该只依赖于单一模型的对话能力。通过将“扮演层”与“判定层”分离，利用一个轻量级模型（如 4o-mini）作为逻辑校验器，可以赋予 AI 更加坚定的性格和更严谨的逻辑闭环。这种工作流对于开发具有强逻辑要求的 AI 游戏或模拟训练系统来说，具有极高的参考价值。