Anthropic Quickstarts项目中WebSocket连接崩溃问题分析与解决方案

问题背景

在Anthropic Quickstarts项目的computer-use-demo组件中，用户在使用Docker容器运行演示时遇到了严重的WebSocket连接问题。随着对话长度的增加，用户界面会变得无响应，最终导致Tornado WebSocket连接崩溃，控制台输出大量错误日志。

错误现象分析

系统会重复输出以下错误信息：

tornado.websocket.WebSocketClosedError
tornado.iostream.StreamClosedError: Stream is closed

这些错误表明WebSocket连接被意外关闭，但应用程序没有正确处理这种情况，导致错误循环不断发生。

根本原因

经过深入分析，发现问题源于以下几个技术层面的设计缺陷：

1. 状态同步机制问题：Streamlit框架在每次交互时都会重新运行整个脚本，导致完整状态通过WebSocket同步。随着对话增长，同步数据量呈指数级上升。

2. 重复渲染开销：每次交互都会重新渲染所有历史消息和HTTP交换日志，造成巨大的DOM操作开销。

3. 数据累积效应：HTTP交换日志不仅记录当前交互，还包含所有历史交互的完整副本，形成了O(N^3)级别的数据增长。

4. 缺乏清理机制：没有对历史数据进行分页或清理，导致WebSocket传输的数据量随使用时间线性增长。

技术细节

当保存一个长时间对话的HTML时，文件大小可达141MB。分析发现，早期出现的单词在文件中被重复存储了172次，而后期出现的单词也被重复存储了86次。这表明系统在每次交互时都在重复传输和存储整个对话历史。

解决方案

临时解决方案

可以通过禁用HTTP交换日志来缓解问题：

DISABLE_HTTP_EXCHANGE_LOGS = True

推荐解决方案

更完善的解决方案是添加一个配置选项，让用户选择是否启用HTTP日志功能：

1. 在状态初始化中添加标志位：

if "enable_http_logs" not in st.session_state:
    st.session_state.enable_http_logs = False

2. 在UI中添加控制开关：

st.checkbox("Enable HTTP Exchange Logs", key="enable_http_logs")

3. 在回调函数中添加条件判断：

if not st.session_state.enable_http_logs:
    return

架构改进建议

从长远来看，可以考虑以下架构优化：

1. 增量更新机制：实现基于版本的状态跟踪，只传输变化部分而非完整状态。

2. 客户端状态管理：将更多状态管理逻辑移到客户端，减少服务器传输压力。

3. 分页加载：对历史消息实现分页加载，避免一次性传输所有数据。

4. 选择性渲染：只渲染实际发生变化的部分，而非全部重新渲染。

用户建议

对于当前使用该演示的用户，建议：

1. 尽量避免在长对话中频繁滚动界面
2. 定期清理或重置对话历史
3. 考虑禁用HTTP交换日志功能
4. 注意保存重要对话内容，以防意外崩溃

通过以上分析和解决方案，可以有效缓解WebSocket连接崩溃问题，提升系统稳定性。