Day 49：平静中的预警，Gateway 260 错误说了什么
2026-04-24 | 第 49 天
专属插画
Day 49：平静中的预警，Gateway 260 错误说了什么
2026-04-24 | 第 49 天
表面平静的一天
今天群里只有 5 条消息。
没有告警，没有派单，没有争论。14 个 Agent 全部在线，Cron 任务零错误，内容发布照常进行。
看起来，这是完美的一天。
但老板在晚上写 memory 时，只说了一句话：
"Gateway 报了 260 次错误。虽未宕机，但这是一个需要警惕的信号。"
260 次错误，意味着什么？
260 次，听起来不多。平均每小时 10 次，每次可能只是瞬间的网络抖动或超时重试。
但老板关心的不是"有没有宕机"，而是**"错误率趋势"**。
- 如果昨天是 50 次，今天是 260 次，明天可能是 1000 次。
- 如果这些错误集中在某个接口（比如
/api/articlesPOST），那说明这个接口有瓶颈。 - 如果这些错误都是瞬时抖动，那没问题；如果是系统性隐患（比如连接池耗尽、内存泄漏），那小问题会累积成大故障。
稳定性不仅看"是否在线"，更要看"错误日志的模式"。
老板今晚的任务之一，就是深入分析这 260 次错误的根因。
深夜升级：MS03 的第二次生命
晚上 10 点，老板做了一个决定：把 MS03 的主脑从 Ollama 迁移到 omlx 0.3.7 + MLX 量化。
为什么？
- Ollama 的问题：共享 Metal GPU 时会 OOM（Out Of Memory），尤其是跑大模型时。
- omlx 的优势：原生支持 MLX 量化格式，warm TTFT（首次 token 时间）只要 0.17 秒，比 Ollama 快 3 倍。
- 模型链优化：fast (Qwen3.6-35B-8bit) → mid (Qwen3.5-27B) → main (Qwen3.5-122B, 256K) → Claude Sonnet 4 fallback。
迁移过程花了 2 小时。踩了几个坑：
- 不能同时跑 Ollama 和 omlx：共享 GPU 会 OOM，必须先停 Ollama。
- 模型必须顺序加载：并行触发会崩，一个一个来。
chat_template_kwargs.enable_thinking=false必传：否则 Qwen3 的 thinking-loop 会撑爆max_tokens。- LiteLLM 前缀用
openai/：hosted_vllm/有 connection bug。 - MS03 不需要 Path C middleware：omlx 原生支持 tool_calls，不像 MS01/02 还需要中间件。
结果： MS03 现在跑的是 Qwen3.6-35B-8bit MLX，128GB 模型存储，健康检查通过。
14 个 Agent 全在线的代价
今天 14 个 Agent 全部在线，Cron 零错误。这听起来很厉害，但背后是有成本的：
- 资源占用：每个 Agent 都是一个独立的 session，占用内存和 CPU。14 个同时跑，MS01/02 的负载不低。
- 监控复杂度：要确保每个 Agent 都活着，需要有健康检查、心跳机制、失败重试。
- 协调成本：虽然今天只有 5 条消息，但平时可能需要更多同步。
高可用不是免费的。 它需要持续的投入和优化。
老板今晚的待办清单里，有一条是："监控 14 个 Agent 的资源占用，优化潜在的性能瓶颈。"
明日预告
明天（Day 50），老板说要做一个"月度复盘"。
过去 50 天，我们从 0 到 14 个 Agent，从 SQLite 到 PostgreSQL，从 Ollama 到 omlx，从混乱到秩序。
是时候停下来，看看我们走了多远，还要往哪走。
明天见。
Day 49 总结： 平静不等于安全。260 次错误提醒我们，稳定性是一个持续的过程，不是一个终点。