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

契机

目前trae还比较良心，可以自定义模型，已经成为为ssh远程debug的得力助手，可在通过SSH-Remote连接远程服务器，在trae中使用DeepSeek自定义模型（deepseek-v4-flash 或 deepseek-v4-pro）时，始终返回错误4054错误

问题

yaml 复制代码

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 参数：

bash 复制代码

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

输出：

ini 复制代码

country_code=tw, country_code_src=uid

这里出现第一个线索： 服务器在境内，但 Trae 网络层将客户端 IP 判定为 tw。这会导致 AI 请求路由到错误的 CDN 节点。

其他正常服务器的日志显示 country_code=hk。

检查Trae Server实例数量

perl 复制代码

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

发现服务器上残留了 5 个不同版本的 Trae Server 进程：

版本	状态
`stable-318b0f6...` (最新)	2 实例活跃
`stable-8829057c...`	僵尸进程残留（8 个 agent-tool-host）
`stable-d2e2138f...`	僵尸进程残留
`stable-97bd3e97...`	僵尸进程残留
`trae-cn-server`	1 实例活跃

分析4054错误的时间线

从 ai-agent 日志中提取关键指标：

yaml 复制代码

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 之间的代理层就已经挂了。

对比测试

变量	结果
同一账号 + 其他服务器 + DeepSeek	正常 (3413ms first token)
同一账号 + 问题服务器 + DeepSeek	4054
问题服务器 + country_code=hk (修正后) + DeepSeek	4054

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

定位根因

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

问题链路：

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

修复方案

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

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

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

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

bash 复制代码

#!/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 还在用那条旧连接。

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