Trae远程开发中DeepSeek自定义模型4054错误的排查与修复

契机

最近Trae这工具还挺良心的，允许自定义模型，已经成了远程debug的得力助手。不过通过SSH-Remote连到远程服务器，在Trae里用DeepSeek自定义模型（deepseek-v4-flash或deepseek-v4-pro）时，一直弹4054错误，这就很头疼了。

问题

错误信息长这样：

error_code: 4054
error_message: "Custom model internal error occurred. Please check the proxy response for details."

以前大家碰到这个问题，第一反应就是rm /root/.trae_server，但这样聊天记录、同事的配置全丢了，实在不够优雅。所以换个思路，从根上找原因。

先简单说下Trae远程开发的架构：

• 本地Trae客户端通过SSH连到远程服务器
• 服务器上跑着trae-server，包含多个子进程：server-main、ai-agent、trae-helper（网络层）、ckg_server（代码知识图谱）等
• AI请求链路：ai-agent → custom_model_proxy_client（WebSocket）→ Trae云网关 → DeepSeek API
• 聊天记录存在ai-agent/database.db（SQLite）里

排查过程

确认网络层状态

先翻服务器端Trae日志，重点关注TTNet的country_code参数：

grep 'country_code' ~/.trae-server/manager-logs/*/Modular/trae-helper_*_stdout.log

输出如下：

country_code=tw, country_code_src=uid

这里就发现了第一个线索：服务器明明在境内，可Trae网络层把客户端IP识别成了tw。这意味着AI请求可能会被路由到错误的CDN节点。而其他正常的服务器日志显示country_code=hk。

检查Trae Server实例数量

ps aux | grep 'trae-server' | grep -v grep

不看不知道，一看吓一跳：服务器上竟然残留了5个不同版本的Trae Server进程——

分析4054错误的时间线

从ai-agent日志里提取几个关键指标：

svr_11_gateway_server_processing_time: 4927ms   # 网关处理耗时
svr_06_platform_first_token_timing: 4000ms        # 等first token
svr__06_platform_provider_first_token_timing: 0      # DeepSeek零token返回
svr__06_platform_provider_network_latency: 0          # 零网络延迟记录

请求确实到了Trae云网关，但DeepSeek那边什么都没返回。platform_provider_first_token_timing: 0说明网关和DeepSeek之间的袋里层就已经挂了。

对比测试

关键发现：即使country_code已经手动修正为hk，错误依旧。说明问题压根不在路由参数，而是连接状态已经“脏了”。

定位根因

Trae的custom_model_proxy_client在进程启动时，会建立一条到Trae云CDN节点的WebSocket长连接。这条连接建立时决定的参数（CDN节点选择、路由表）在进程运行期间不会自动刷新。

问题链路也就清晰了：

1. 服务器曾有多版本Trae混杂运行，网络层参数被污染
2. 某次连接时country_code被判定为tw
3. WebSocket被分配到一个不对的CDN节点
4. 该节点对DeepSeek的袋里不稳定
5. 之后虽然country_code修正了，但长连接没断，一直复用错误的节点

修复方案

方案A：rm .trae-server（不推荐）

删除整个Trae Server数据目录，完全重建。代价是：聊天记录、CKG索引、用户设置、同事的上下文全部丢失。

方案B：精准重启ai-agent（推荐）

只重启ai-agent进程，trae-server的manager进程会检测到子进程退出并自动拉起来新的。聊天记录完整性不受影响。

#!/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')"

# 1. 备份聊天数据库
if [ -f "$DB_PATH" ]; then
    BACKUP="$DB_PATH.backup.$(date +%Y%m%d_%H%M%S)"
    cp "$DB_PATH" "$BACKUP"
    echo " 数据库已备份:$BACKUP"
fi

# 2. 找到当前活跃版本的 ai-agent 和 agent-tool-host
AGENT_PIDS=$(ps aux | grep 'trae-server.*modules/ai-agent/ai-agent$' | grep -v grep | awk '{print$2}')
TOOL_PIDS=$(ps aux | grep 'trae-server.*modules/ai-agent/bin/agent-tool-host$' | grep -v grep | awk '{print$2}')

# 3. Kill（manager 会自动重启）
echo "→ 停止 ai-agent..."
for pid in $AGENT_PIDS; do
    kill "$pid" 2>/dev/null && echo "killed ai-agent pid=$pid"
done

echo "→ 停止 agent-tool-host..."
for pid in $TOOL_PIDS; do
    kill "$pid" 2>/dev/null && echo "killed agent-tool-host pid=$pid"
done

# 4. 等待 manager 自动重启
echo "→ 等待 manager 自动重启..."
sleep 2

# 5. 验证
for i in 1 2 3 4 5; do
    NEW_AGENT=$(ps aux | grep 'trae-server.*modules/ai-agent/ai-agent$' | grep -v grep | awk '{print$2}')
    NEW_TOOL=$(ps aux | grep 'trae-server.*modules/ai-agent/bin/agent-tool-host$' | grep -v grep | awk '{print$2}')
    if [ -n "$NEW_AGENT" ] && [ -n "$NEW_TOOL" ]; then
        echo " ai-agent 已重启 (pid=$NEW_AGENT)"
        echo " agent-tool-host 已重启 (pid=$NEW_TOOL)"
        break
    fi
    sleep 1
done

if [ -f "$DB_PATH" ]; then
    echo " 聊天数据库完好 ($(du -h "$DB_PATH" | cut -f1))"
fi

echo "=== 完成 ==="

总结

回过头来看这个问题的排查过程，有个挺有意思的体会：分布式系统里，“缓存”和“连接池”往往是问题的温床。一条在启动时建立的WebSocket长连接，跑了几个小时甚至几天后，它的路由信息可能已经完全过时了。Trae的网络层虽然自动修正了country_code，但应用层的custom_model_proxy_client还死死抱着那条旧连接不放——这才是4054背后的真正元凶。

写到最后

《夸克》非常好用的免费AI浏览器

下载APP查看