最近在使用 Trae 做远程 SSH 开发时，AI 编程体验整体非常顺滑，自定义模型接入 DeepSeek 后，可以直接在远程服务器上进行代码生成与重构，这种“远程 + AI Agent”的组合在工程效率上提升明显。但在实际使用过程中，遇到了一个比较典型但又非常隐蔽的问题：在连接远程服务器后使用 DeepSeek 自定义模型时，频繁报 4054 错误，并且该问题无法通过常规重试解决。
错误信息如下：
error_code: 4054 error_message: "Custom model internal error occurred. Please check the proxy response for details."
更关键的是，这个问题具有明显的“环境相关性”：同一账号在本地环境正常、在其他服务器正常，只有某一台远程服务器出现异常，并且问题是“突然发生”的，没有任何明显配置变更。这种情况基本可以排除模型本身问题，而更可能是远程运行时环境或代理链路状态异常。
一、问题现象与触发条件
在 Trae 通过 SSH Remote 连接远程服务器后，选择 DeepSeek（如 deepseek-v4-flash 或 deepseek-v4-pro）作为自定义模型，输入任意消息后立即返回 4054 错误。但如果切换到其他模型或者更换服务器，该问题完全消失。
这种现象具有几个典型特征：
- 同账号不同机器表现不一致
- 同机器不同模型表现不一致
- 问题出现无明显触发事件
- 重启 IDE 无法修复
这些特征通常意味着问题不在业务层，而是在代理层或连接状态层。
二、Trae 远程开发架构拆解
要理解问题根因，需要先明确 Trae 远程开发的整体链路结构：
-
本地 Trae 客户端通过 SSH 连接远程服务器
-
远程运行
trae-server主进程 -
子模块包括：
server-main（主控制）ai-agent（AI对话执行）trae-helper（网络层 / TTNet）ckg_server（代码知识图谱）
-
AI 请求链路为：
ai-agent → custom_model_proxy_client → WebSocket → Trae云网关 → DeepSeek API
- 聊天记录存储位置：
ai-agent/database.db（SQLite）
在这个链路中，真正关键的不是模型，而是：
custom_model_proxy_client 的 WebSocket 长连接机制
三、初步排查：网络层异常信号
首先检查 Trae 网络层日志：
grep 'country_code' ~/.trae-server/manager-logs/*/Modular/trae-helper_*_stdout.log
得到结果：
country_code=tw, country_code_src=uid
这里出现了一个明显异常：服务器被识别为 tw（台湾节点），而正常情况应为 hk 或 cn 路由。这意味着请求可能被调度到了错误的 CDN 节点。
但需要注意，这一现象并不是直接错误原因，而是后续链路异常的诱因之一。
四、进程状态异常：多版本 Trae 混跑
继续检查服务器进程：
ps aux | grep 'trae-server' | grep -v grep
结果发现存在多个版本混合运行：
| 版本 | 状态 |
|---|---|
| stable-318b0f6... | 2 实例活跃 |
| stable-8829057c... | 僵尸进程残留（8 个 agent-tool-host） |
| stable-d2e2138f... | 僵尸进程残留 |
| stable-97bd3e97... | 僵尸进程残留 |
| trae-cn-server | 1 实例活跃 |
这种状态会导致：
- 网络参数污染
- WebSocket连接复用异常
- 路由策略不一致
- 代理层状态混乱
在分布式客户端系统中，这属于典型的“多版本运行污染问题”。
五、请求链路分析：关键时间异常
从 ai-agent 日志中提取关键指标：
svr_11_gateway_server_processing_time: 4927ms
svr_06_platform_first_token_timing: 4000ms
svr__06_platform_provider_first_token_timing: 0
svr__06_platform_provider_network_latency: 0
分析结果：
- 请求已到达 Trae 云网关
- 网关处理耗时约 5 秒
- DeepSeek 侧无任何响应
- provider 层未返回 token
结论非常明确：
问题发生在“网关 → 模型代理”之间，而不是模型本身
六、根因定位：长连接状态污染
进一步分析后发现核心问题在于：
custom_model_proxy_client 在启动时会建立 WebSocket 长连接，并绑定当前：
- CDN 节点
- country_code
- 路由策略
关键问题是：
该 WebSocket 在生命周期内不会随网络状态更新自动刷新
导致以下链路：
- 初始连接被错误标记为 tw 节点
- WebSocket 绑定到错误 CDN
- 后续请求持续复用该连接
- 即使 country_code 修正，也不会影响已建立连接
- 最终持续返回 4054 错误
本质是典型的：
长连接状态漂移 + 路由不一致问题
七、修复方案：避免数据丢失的精准重启
❌ 方案A：全量删除（不推荐）
rm -rf ~/.trae-server
问题：
- 聊天记录丢失
- 配置丢失
- 索引重建成本高
✅ 方案B：精准重启 ai-agent（推荐）
核心思路：只重建 WebSocket，不动数据层。
#!/bin/bash
# Trae AI Agent 精准重启脚本
# 只重启 ai-agent，不丢聊天记录
set -e
TRAE_DIR="$HOME/.trae-server"
DB_PATH="$TRAE_DIR/ai-agent/database.db"
echo "=== Trae AI Agent 精准重启 ==="
echo "时间:$(date '+%Y-%m-%d %H:%M:%S')"
if [ -f "$DB_PATH" ]; then
BACKUP="$DB_PATH.backup.$(date +%Y%m%d_%H%M%S)"
cp "$DB_PATH" "$BACKUP"
echo "✓ 数据库已备份:$BACKUP"
fi
AGENT_PIDS=$(ps aux | grep 'trae-server.*ai-agent' | grep -v grep | awk '{print$2}')
TOOL_PIDS=$(ps aux | grep 'agent-tool-host' | grep -v grep | awk '{print$2}')
for pid in $AGENT_PIDS; do
kill "$pid" 2>/dev/null
done
for pid in $TOOL_PIDS; do
kill "$pid" 2>/dev/null
done
sleep 3
echo "✓ ai-agent 已重启"
echo "=== 完成 ==="
八、工程视角总结：问题本质
该问题并不是模型错误，而是典型的分布式系统问题：
- 长连接生命周期未刷新
- 路由状态与实际网络不一致
- 旧 WebSocket 复用错误 CDN
- 代理层状态漂移
在更复杂的工程体系中，这类问题通常会通过统一 API 网关进行隔离与控制，例如类似 TreeRouter 这样的多模型聚合网关，仅提供统一 OpenAI 兼容接口与模型路由能力，从工程上减少多接口切换复杂度，但连接层的稳定性仍主要依赖底层通信系统与客户端实现。
九、结语
4054 错误的本质并不是 DeepSeek 或模型问题，而是 AI Agent 架构中典型的“长连接状态不一致”问题。在分布式与多节点代理系统中，这类问题往往比业务错误更难定位，因为表象是“模型失败”，本质却是“连接已经变质但仍在复用”。
真正稳定的 AI 开发环境，需要同时控制三件事：
- 网络路由一致性
- 长连接生命周期管理
- 代理层状态同步机制
否则再强的模型，也会被错误的连接状态拖垮。
