客户端事件
客户端事件
了解并处理对话应用中客户端实时接收的事件。
客户端事件是从服务器发送到客户端的系统级事件,用于实现实时通信。这些事件向客户端应用传递音频、转写内容、智能体回复及其他关键信息。
有关可从客户端发送到服务器的事件,请参阅客户端到服务器事件文档。
概述
客户端事件对于维持对话的实时性至关重要。它们提供从初始化元数据到已处理音频和智能体回复的所有信息。
这些事件属于 WebSocket 通信协议的一部分,由我们的 SDK 自动处理。对于高级实现和调试,了解这些事件至关重要。
客户端事件类型
conversation_initiation_metadata
- 开始对话时自动发送
- 初始化对话设置和参数
queue_status
- 智能体达到并发限制时,仅发送给在通话队列中等待的来电者
waiting在conversation_initiation_metadata之后、任何等待音频之前发送一次- 等待结束时,
admitted或timed_out会发送一次。timed_out后会以代码 4300 关闭 WebSocket - 始终发送给排队中的来电者。无需在智能体的
client_events配置中启用
来电者排队时,等待音频会作为常规 audio 事件到达。请使用此事件显示等待状态,而不要将等待音频视为智能体语音。
ping
- 需要立即响应的运行状况检查事件
- 由 SDK 自动处理
- 用于维持 WebSocket 连接
audio
- 包含用于播放的 Base64 编码音频
- 包含用于跟踪和排序的数字事件 ID
- 处理语音输出流
- 包含具有字符级时间信息的对齐数据
通过 WebRTC 连接时,不会发送 audio 事件,因为音频由 LiveKit 直接处理。
user_transcript
- 包含已完成的语音转文本结果
- 表示完整的用户话语
- 用于对话历史记录
agent_response
- 包含完整的智能体消息
- 消息完成后发送一次,因此在语音对话中,通常会在该消息的音频开始流式传输后才到达
- 用于显示和历史记录
如需在智能体文本生成时显示,请使用下文所述的 agent_chat_response_part 事件,而非等待此事件。
agent_response_correction
- 包含中断后的截断回复
- 更新显示的消息
- 保持对话准确性
agent_response_metadata
- 包含来自自定义 LLM 回复的任意元数据
- 仅在使用自定义 LLM时发送
- 必须在智能体的
client_events配置中明确启用
此事件专用于自定义 LLM 集成。它允许自定义 LLM 服务器随回复传递额外元数据,供客户端应用使用。
client_tool_call
- 表示智能体希望客户端执行的函数调用
- 包含工具名称、工具调用 ID 和参数
- 需要在客户端执行函数,并将结果发送回服务器
如果使用 SDK,将提供回调来处理将结果发送回服务器的操作。
agent_tool_response
- 指示智能体何时执行了工具函数
- 包含工具元数据和执行状态
- 可了解智能体在对话期间的工具使用情况
agent_tool_response_full_payload
- 与
agent_tool_response对应,此外还会将工具的完整结果载荷作为字符串流式传输到full_tool_result。 - 在客户端呈现工具输出,以便显示或进行下游处理。
- 必须在智能体的
client_events配置中明确启用。
此事件会向客户端公开完整工具结果,其中可能包含敏感数据。仅在客户端受信任且能够处理此载荷时启用。超过 64 KB 的结果会自动截断。
React
JavaScript
vad_score
- 语音活动检测评分事件
- 表示用户正在说话的概率
- 值范围为 0 到 1,值越高表示语音置信度越高
mcp_tool_call
- 指示智能体何时执行了 MCP 工具函数
- 包含工具名称、工具调用 ID 和参数
- 以四种状态之一调用:
loading、awaiting_approval、success和failure。
agent_chat_response_part
- 将智能体生成中的回复文本作为
start、delta和stop消息进行流式传输 - 在纯文本模式下始终发送;在语音对话中,必须在智能体的
client_events配置中明确启用 - 当智能体或活跃流程使用阻塞型护栏时不会发送,因为护栏必须先评估完整回复,才能释放任何内容
response_id用于标识正在流式传输的消息,并与稍后确认该消息的agent_response的response_id匹配
agent_reasoning_response_part
agent_reasoning_response_part 会在纯文本对话期间流式传输模型提供的推理内容。
在 client_events 中启用此事件,并为智能体开启推理摘要。服务器会发送
start、delta 和 stop 消息。在语音对话期间,或当智能体或活跃流程使用阻塞型护栏时,不会发送此事件。
此事件及对应的 SDK 回调属于实验性功能。其行为和结构可能在任何版本中发生变化。
开始和停止事件使用空的 text 值。
agent_response_complete
- 当智能体完成回复(包括所有待处理工具调用)时触发。此事件之后,只有当用户提供新输入或轮次超时触发新轮次时,智能体才会继续产生输出。
- 必须在智能体的
client_events配置中明确启用
guardrail_triggered
事件流程
以下是对话期间的典型事件顺序:
当智能体达到并发上限且已启用呼叫排队时,服务器会在 conversation_initiation_metadata 与第一个 audio 事件之间发送 queue_status 事件。等待音频会以 audio 事件的形式传送,直到呼叫者获准接入。
最佳实践
-
错误处理
- 为每种事件类型实现适当的错误处理
- 记录重要事件,便于调试
- 妥善处理连接中断
-
音频管理
- 合理缓冲音频块
- 在中断时做好清理
- 管理音频资源
-
连接管理
- 及时响应 PING 事件
- 实现重连逻辑
- 监控连接状态
故障排除
连接问题
- 确保 WebSocket 连接正常
- 检查 PING/PONG 响应
- 验证 API 凭据
音频问题
- 检查音频块处理
- 验证音频格式兼容性
- 监控内存使用情况
事件处理
- 记录所有事件,便于调试
- 实现错误边界
- 检查事件处理程序注册情况
如需详细实现示例,请查看我们的 SDK 文档。