报错是这么冒出来的。连接建立后先发一条 session.update 改语音和轮次检测，服务端回了一个 error 事件，原文 Unknown event type，字段名都是照文档抄的。
中间走过弯路，把「部分字段只在会话创建时能设置，update 阶段不可修改」当成主因，改完现象没变。
这类报错背后常见的原因有几处，逐个排除就行。事件外层要包 type 与 session 两层，字段平铺会被判成未知类型。另一种情况是音频格式字段名是 input_audio_format，写成 format 无效。
不容易想到的是，事件顺序错了，还没收到 session.created 就急着发 update。
连上之后先看第一条服务端事件
wscat -c "wss://api.openai.com/v1/realtime?model=gpt-4o-realtime-preview" -H "Authorization: Bearer $EPHEMERAL"然后按两层结构构造 update 事件
python -c "import json;print(json.dumps({'type':'session.update','session':{'instructions':'简短回答','input_audio_format':'pcm16'}}))"随后确认音频格式取值在白名单内
python -c "print(['pcm16','g711_ulaw','g711_alaw'])"剩下的就是观察 created 与 updated 的先后顺序
wscat -c "wss://api.openai.com/v1/realtime?model=gpt-4o-realtime-preview" -H "Authorization: Bearer $EPHEMERAL" | grep -E "session.created|session.updated"恢复的判定其实很直接。服务端返回 session.updated 而不是 error，之后发送的音频帧能被识别，转写文本开始出现在事件流里。
容易忽略的是，事件协议是严格分层的，外层 type 决定解析分支，把字段直接摊平在顶层，服务端连类型都认不出来。如果同一现象隔几天又出现，说明根因没找到，别当偶发处理。