REST 的消亡：WebSockets 将成为 AI 代理的新标准

想象一下，AI co-pilot 不仅仅是一个聊天机器人，它还具有语音功能，能够倾听、理解并立即做出响应，为您的应用程序创造自然的交互体验。随着 AI 和大型语言模型（LLM）进一步融入我们的工作流程，我们正在从被动的请求/响应交流演变为高度动态、语音驱动、实时响应的交互。

多年来，REST 一直是客户端与服务器通信的首选协议，可为各种应用提供结构化、可靠的数据。然而，其请求-响应模型难以满足实时交互所需的连续双向通信。

这种限制为基于 WebSocket 的 API 铺平了道路，使下一代 AI co-pilot 的创建成为可能，从而提供跨界面的流畅语音驱动体验。

在本文中，我们将深入探讨 WebSockets 如何实现超越传统聊天机器人的实时、语音驱动的 AI co-pilot。同时将探讨为什么 WebSockets 对于连续的交互式体验至关重要，研究 REST 的局限性，并展示 OpenAI 的实时 API 如何利用这些技术创建更易于访问、更吸引人的 AI 代理。

了解 REST 及其局限性

REST 被设计为一种无状态的客户端-服务器通信协议，通过 HTTP 实现请求-响应循环。在 REST 中，每个客户端操作都需要向服务器发送一个新的 HTTP 请求，然后服务器发送一个响应并关闭连接。这种模式对于独立、隔离的事务非常有效，每个请求和响应都被分开处理，因此非常适合检索数据或执行离散操作。

实时应用程序的 REST 瓶颈

尽管 REST 有很多优点，但它也有一些固有的瓶颈，这使得它对于实时通信和交互式应用程序来说并不理想：

无状态：REST 中的每个请求都是独立的，这意味着在交互过程中没有连续性或持久性。对于实时 AI 应用来说，在消息间保持上下文或保持一个持续的 “会话 ”对于流畅的交互体验至关重要。

延迟：在 REST 中，客户端每次需要数据时都必须发送请求，这就带来了延迟。对于高频更新，这种模式会导致严重的延迟，因为每个请求-响应周期都会增加开销。

轮询作为一种解决方法：依赖 REST 的实时应用程序通常采用轮询（以设定的时间间隔重复发送请求）来模拟连续更新。然而，轮询的效率很低，会给客户端和服务器带来不必要的负载、消耗带宽并增加延迟。

缺乏双向沟通：REST 本质上是单向的：只有客户端可以发起请求，服务器的角色仅限于响应。这种结构阻止服务器在更新可用时将更新推送给客户端，而这在实时应用程序中至关重要，因为用户希望获得即时响应和持续交互。

这些限制凸显了 REST 为何难以与实时 AI 代理兼容，因为实时 AI 代理需要即时、双向的数据交换才能创造流畅、响应迅速的体验。随着应用程序需要更具吸引力的实时功能，很明显，仅靠 REST 已无法满足这些不断变化的需求。

WebSockets：实时双向通信的关键

为了解决 REST 在实时场景中的局限性，WebSockets 提供了一个替代方案。WebSockets 通过单个 TCP 连接在客户端和服务器之间建立持久的全双工连接。REST 在每个请求-响应周期后都会关闭连接，而 WebSockets 则不同，它保持着一个开放的通道，允许持续的双向通信，而不会产生重复请求的开销。

WebSockets 如何实现实时 AI 应用

持久连接：WebSockets 可创建一个长期开放的连接，使客户端和服务器都能自由交换数据。这种设置非常适合需要持续更新的应用，如实时分析、实时聊天和 AI co-pilot。

双向全双工通信：借助 WebSocket，通信可以双向进行：服务器可以将更新推送到客户端，而客户端可以与服务器交互而无需等待请求-响应周期。这种双向交互可实现即时反馈和动态、引人入胜的体验。

低延迟：通过消除打开和关闭连接的需要，WebSocket 可最大限度地减少延迟，使其成为需要快速更新的场景的理想选择。监控数据流或响应用户输入的 AI 代理受益于这种低延迟设计，可提供实时响应。

减少开销：WebSocket 减少了 REST 中与 HTTP 标头相关的开销，允许来回发送轻量级数据帧。这种效率意味着更快的数据交换，对于需要实时处理和响应数据的应用程序中尤其有益。

鉴于 WebSockets 的优势，它正迅速成为实时应用的实际选择，尤其是在涉及AI代理和co-pilot的场景中。REST 在满足实时需求方面的局限性使 WebSockets 成为理想的替代品，它能提供现代交互式应用程序所需的响应速度和灵活性。

OpenAI 的实时 API：WebSocket 在 AI 中的实际应用

OpenAI 的 Realtime API 是 WebSockets 如何支持实时 AI 交互的前沿示例。Realtime API 专为语音驱动的对话式应用程序而设计，通过利用持久的 WebSocket 连接实现无缝的语音到语音交换。

OpenAI 的 Realtime API 实现了 WebSockets 的优势，具体如下：

低延迟、自然交互：Realtime API 基于 OpenAI 的 GPT-4o 模型构建，可提供超低延迟，实现自然的对话体验。用户可以与 AI 驱动的代理交谈，几乎可以立即收到响应，从而创造出接近人类对话的体验。

具有持久连接的双向通信：通过使用 WebSockets，Realtime API 可以维持恒定的双向数据流，从而使服务器能够在收到用户输入后立即做出响应，甚至处理中断。例如，如果用户在对话中途更改主题，Realtime API 会即时进行调整，而不会出现任何明显的延迟（介绍 Realtim…）。

集成函数调用以实现动态交互：Realtime API 还支持函数调用，使 AI 能够根据用户请求执行外部任务，例如检索数据或设置提醒。此功能为 AI 代理打开了大门，使其能够处理除简单响应之外的复杂任务，从而使其更加灵活和实用。

实时音频功能：借助文本转语音和语音转文本功能，Realtime API 可以处理语音输入并生成语音响应，满足语音助手和客户支持代理等应用程序的需求。这些功能对于客户服务、医疗保健和语言学习等自然交互至关重要的应用程序至关重要。

增强安全性和隐私性：OpenAI 嵌入了严格的安全协议，包括自动监控和人工审核，以减少滥用。开发人员保留对其数据的控制权，OpenAI 承诺未经明确许可不会将输入用于模型训练。这使得 Realtime API 成为注重用户隐私的开发人员的强大而负责任的选择。

使用 Realtime API 构建实时语音代理

开始使用 Realtime API 包括配置 WebSocket 连接、设置音频处理以及处理实时动态交互的事件。

1. 设置实时控制台

为了简化集成，OpenAI 在 GitHub 上提供了基于 React 的实时控制台，让开发人员可以检查、测试和调试实时 API。该控制台附带用于音频流和工具管理的实用程序，并包括天气检查和设置内存等基本功能。

该控制台既可作为参考客户端，又可作为探索 API 功能的调试工具

2. 连接到 API

Realtime API 使用WebSocket 连接来实现实时双向通信。这对于对话式 AI 和语音驱动代理所需的低延迟交互至关重要。

初始化 WebSocket 连接：首先使用 Realtime API 端点创建一个 WebSocket 连接。为确保访问安全，请在标头中传递 API 密钥。对于开发或较简单的设置，API 提供了直接传递 API 密钥的insecure模式，但建议在生产中使用中继服务器以提高安全性。

const url = "wss://api.openai.com/v1/realtime?model=gpt-4o-realtime-preview";
const ws = new WebSocket(url, {
  headers: {
    "Authorization": `Bearer ${process.env.OPENAI_API_KEY}`,
    "OpenAI-Beta": "realtime=v1",
  },
});

在生产中使用中继服务器：

中继服务器充当中间人，将敏感的 API 密钥从客户端代码中隐藏起来。这种设置在生产中至关重要，可防止未经授权的访问。
中继服务器使用您的 API 密钥进行配置，将请求从客户端路由到 OpenAI 的服务器，同时在服务器端保护密钥的安全。

// 使用中继服务器的示例
const replyUrl = "http://localhost:8081" ; // 中继服务器 URL 
const client = new  RealtimeClient ({ 
    url: replyUrl, 
    apiKey: process.env.OPENAI_API_KEY, // 在中继服务器上设置 API 密钥
    dangerouslyAllowAPIKeyInBrowser: false , // 在生产中禁用
});

用于快速测试的不安全模式：

在初始测试或沙盒环境中，可以使用dangerouslyAllowAPIKeyInBrowser 直接连接，而无需中继服务器。但是，在生产过程中应避免这样做，因为这样会暴露您的 OpenI API 密钥。

核心实时 API 事件

Realtime API 提供各种事件，让开发人员能够对对话、音频处理和错误处理进行精细控制。其中，两个事件对于实时文本流至关重要：deltas和.done 事件。

了解这些事件的作用对于实现响应式、交互式的用户体验至关重要。

1. Deltas：Delta 表示API 在生成数据时发送的部分更新。Delta 允许应用程序逐步接收文本或音频片段，而不是等待整个响应，从而增强实时交互性。例如，在对话式 AI 设置中，Delta 允许在生成响应时向用户显示响应，从而使交互感觉更加流畅和即时。

每次增量更新都可以看作是完整响应的“一部分”，实时传输。这种方法对于较长的响应或即时反馈至关重要的场景（例如聊天机器人或语音助手）特别有用。

client.on('response.text.delta', (partialText) => {on ( 'response.text.delta' , ( partialText ) => { 
    appendToTranscript (partialText); // 实时显示部分文本
});

2. .done 事件：

.done 事件表示特定响应的流式传输结束。API 完全生成响应后，它会发出 .done 事件，表示不会再有增量。
虽然 deltas 提供了增量更新，但 .done 可确保完整的响应是完整的，这使得它在应用程序等待整个消息再执行下一步的情况中很有用，例如在文件保存操作或需要完整响应摘要时。

client.on('response.text.done', (finalText) => {on ( 'response.text.done' , ( FinalText ) => { 
    displayFinalResponse (finalText); // 显示完成的文本
});

通过同时使用 deltas 和 .done 事件，应用程序可以平衡实时响应能力和完整性，立即显示部分信息，同时确保在准备就绪时可以访问完整响应。

构建实时语音代理概述

利用 WebSocket 设置、Realtime API 中的事件监听器和音频管理工具，下面是将这些组件集成到实时语音代理的快速概述：

// 初始化 Realtime Client 并进行配置
const client = new RealtimeClient({
   url: "wss://api.openai.com/v1/realtime",
   apiKey: YOUR_API_KEY,
   turn_detection: 'server_vad', // 使用 VAD 进行自动检测
});

// 附加事件监听器
client.on('conversation.updated', handleConversationUpdate);
client.on('error', handleError);
client.on('conversation.interrupted', handleInterruption);

// 配置并开始录音
const recorder = new WavRecorder({ sampleRate: 24000 });
await recorder.startRecording((audioData) => client.appendAudio(audioData));

// 初始化音频播放
const player = new WavStreamPlayer({ sampleRate: 24000 });
function handleConversationUpdate({ delta }) {
   if (delta.audio) {
       player.playAudio(delta.audio);
   }
}

// 开始对话
await client.connect();
client.sendUserMessage({ text: 'Hello, how can I assist you?' });