Nuxt3 AI Agent 控制台实战 17：排查香港服务器访问火山方舟北京模型超时问题

前面已经完成了线上部署的基础链路：

css 复制代码

域名访问
HTTPS
Access Code 登录
Secure Cookie
MySQL
Feedback
Admin 页面
CLS 日志采集
GitHub Actions 自动部署

从传统 Web 项目角度看，这条链路基本已经闭环。

但真正开始在线上测试 Agent Run 时，出现了新的问题：

复制代码

线上 Run 经常失败

通过 CLS 查看日志，发现有一条 Run 的事件大概是：

复制代码

model_call_start
↓
约 60 秒
↓
agent_error

这说明 Agent 已经进入模型调用阶段。

但模型还没有返回下一步结果，Run 就失败了。

1. 先判断失败阶段

一开始怀疑是代码问题。

可能的方向包括：

sql 复制代码

tool call 解析错误
Skill 调模型失败
模型返回 JSON 不稳定
Tool Result 回填异常

但继续看日志，发现失败发生在第一次模型调用阶段。

也就是：

复制代码

tool_planning

这个阶段模型还没有返回 tool call。

Tool Router 还没开始。

Skill 也还没执行。

所以这次失败不太像 Tool / Skill 逻辑问题。

再看失败时间，基本卡在 60 秒左右。

而项目配置里正好是：

ini 复制代码

MODEL_REQUEST_TIMEOUT_MS=60000

所以基本可以判断：

复制代码

第一次模型调用超时

2. 调整模型请求超时

先把超时时间从 60 秒调整到 180 秒：

ini 复制代码

MODEL_REQUEST_TIMEOUT_MS=180000

这个调整不是最终方案。

它只是为了验证：

复制代码

是否因为模型首包过慢导致 60 秒内没有响应

如果 180 秒后成功率提高，说明问题确实偏向网络或上游响应速度。

如果 180 秒仍然失败，则需要继续排查模型平台、网络连接或请求参数。

3. 增强 agent_error 日志

之前 CLS 里只看到：

sql 复制代码

Real Agent Run failed

这个日志粒度太粗。

看不出失败阶段。

也看不出是否超时。

所以给错误日志增加字段：

复制代码

phase
errorMessage
errorName
isTimeout
requestTimeoutMs

这样后续再出问题时，可以直接看出：

bash 复制代码

失败阶段是 tool_planning / tool_execution / final_answer
是否 timeout
当前 timeout 配置是多少
原始错误信息是什么
错误类型是什么

也就是说，错误日志从：

复制代码

Run failed

升级为：

复制代码

Run 在哪个阶段因为什么失败

对 Agent 项目来说，这很关键。

因为一次 Run 里可能有多次模型调用：

sql 复制代码

tool planning
Skill model call
final answer

如果不记录 phase，只看 agent_error，很难判断到底是哪一步失败。

4. 在服务器上直接 curl 模型接口

为了排除业务代码问题，我直接在香港服务器上 curl 豆包 Chat API。

结果比较明显：

复制代码

有时很久才返回
有时直接失败
有时第三次才成功，而且耗时三十多秒

但本地测试相对正常。

这说明问题很可能不在业务代码，而在网络链路。

当前线上模型请求链路是：

复制代码

香港轻量服务器
↓
跨境网络
↓
火山方舟北京接口

服务器在中国香港。

模型接口在北京节点。

跨境网络导致请求不稳定。

这就是当前线上 Agent Run 超时的核心原因。

5. AI 应用多了一条关键链路

传统 Web 项目里，服务器通常访问：

复制代码

数据库
Redis
对象存储
内部服务
日志服务

这些资源一般会尽量放在同地域或同云内网。

但 AI 应用多了一条非常关键的链路：

复制代码

应用服务器 → 大模型平台

这个链路如果不稳定，整个 Agent 就不稳定。

尤其是 Agent 项目里，一次 Run 可能不止一次模型调用。

当前链路可能包括：

sql 复制代码

LLM tool planning
Skill model call
LLM final answer

也就是说，一次 Run 中任意一次模型请求超时，都可能导致整个 Run 失败。

所以模型平台访问链路，本质上是 Agent 系统的核心依赖之一。

它不是普通的外部接口。

6. 香港服务器和国内模型的地域冲突

当前部署方式有一个明显矛盾：

复制代码

香港服务器：
访问 GHCR 相对方便
访问国内模型平台可能不稳定

国内服务器：
访问国内模型平台更稳定
访问 GHCR 可能不稳定

当前镜像仓库使用 GHCR。

香港服务器从 GHCR 拉镜像相对还可以。

但香港服务器访问火山方舟北京接口存在跨境网络抖动。

如果迁到国内服务器，访问火山方舟北京接口大概率会更稳定。

但国内服务器从 GHCR 拉镜像又可能变慢，甚至不稳定。

这说明部署链路里不只要考虑服务器本身。

还要考虑上下游依赖：

复制代码

镜像仓库在哪里
模型服务在哪里
数据库在哪里
日志服务在哪里
服务器和这些依赖之间的网络质量如何

7. 备选方案：国内轻量服务器 + TCR + K3S

针对当前问题，整理了一个备选架构：

复制代码

国内轻量服务器
腾讯云 TCR
自建 K3S
火山方舟北京模型

TCR 是腾讯云容器镜像服务。

它可以作为独立镜像仓库使用，不一定要绑定 TKE。

即使腾讯云 TKE 不支持轻量应用服务器作为节点，也不影响在轻量服务器上自建 K3S，然后从 TCR 拉镜像。

新的部署链路是：

复制代码

GitHub Actions 构建镜像
↓
推送到腾讯云 TCR
↓
国内 K3S 从 TCR 拉镜像
↓
国内服务器访问火山方舟北京接口

这样两个关键链路都在国内网络里：

复制代码

K3S → TCR
K3S → 火山方舟

这会比香港服务器访问北京模型更合理。

8. 国内迁移的代价

这个方案也有代价。

第一个是备案。

香港服务器可以免备案。

大陆服务器如果正式绑定域名，需要 ICP 备案。

对个人练习项目来说，这是额外成本。

第二个是带宽。

南京轻量应用服务器大概配置是：

复制代码

2 核 2G
40G SSD
2Mbps 带宽
100GB 流量
约 35 元 / 月

价格和香港服务器差不多。

但香港服务器是：

复制代码

20Mbps 峰值带宽
512GB 流量

从带宽看，南京弱很多。

不过 Agent 项目的核心流量是 SSE 文本流。

它不太吃带宽。

真正关键的是：

复制代码

服务器到模型平台的稳定性

所以如果只是少量朋友内测，南京 2Mbps 也不是完全不能接受。

第三个是迁移成本。

需要重新搭：

objectivec 复制代码

K3S
MySQL
ConfigMap
Secret
Ingress
HTTPS
CLS LogListener
GitHub Actions SSH 目标
TCR imagePullSecret

数据库迁移也要处理。

不能简单复制 PVC。

更稳的是：

复制代码

mysqldump 导出
↓
新服务器 MySQL 导入

所以当前没有马上迁移。

而是先整理迁移方案，作为备选。

9. 当前决策

当前阶段先不立即迁移。

先做三件事：

复制代码

调大 MODEL_REQUEST_TIMEOUT_MS
增强 agent_error 日志
观察香港服务器访问火山方舟的稳定性

同时准备国内迁移方案：

复制代码

国内轻量服务器
腾讯云 TCR
自建 K3S
火山方舟北京
mysqldump 迁移数据

如果香港链路通过调参还能支撑小范围内测，就先继续用香港。

如果仍然频繁超时，就切国内服务器。

这是当前最现实的策略。

因为马上迁移会打断当前开发节奏。

但不准备迁移方案，又会在问题持续发生时很被动。

10. 本阶段踩到的关键点

这一阶段最大的收获是：

AI 应用上线后，要多关注一条链路：

复制代码

应用服务器 → 模型平台

本次问题暴露出几个关键点：

bash 复制代码

模型调用阶段要记录 phase
agent_error 不能只记录一句 failed
模型请求要有 timeout 配置
需要区分代码错误和网络超时
服务器地域要和模型平台地域匹配
镜像仓库地域也会影响部署稳定性
香港免备案不代表适合调用国内模型
国内服务器访问国内模型更合理，但要考虑备案和镜像仓库

这些都不是 Agent Runtime 代码本身。

但它们会直接影响线上可用性。

11. 总结

以前我以为部署完成主要看：

复制代码

域名能不能打开
HTTPS 是否正常
数据库能不能写入
日志能不能采集
接口能不能访问

但 AI Agent 项目还要继续看：

复制代码

服务器能不能稳定访问模型
模型首包会不会太慢
流式响应会不会中断
模型平台和服务器地域是否匹配
镜像仓库和服务器地域是否匹配

这次线上失败不是因为 Agent Runtime 没写好。

而是因为真实线上环境里，模型调用链路本身不稳定。

当前项目已经不是"本地 Demo 能跑"的阶段。

它开始进入：

复制代码

真实公网
真实模型
真实网络
真实成本
真实故障

这个阶段以后，代码只是系统的一部分。

剩下的，是工程。