把「不稳」从一句感觉，拆成六个能当场验的原因。
换机器、换模型、换平台 —— 三笔钱通常白花。
「不稳」几乎从来不是 AI 不行，
是六件事没做。
更麻烦的是：归因错了，药就吃错了。
换机器、换模型、换平台，全是在错的地方花钱。
| 项目 | 实测值 | 说明什么 |
|---|---|---|
| 规格 | 2 核 / 总内存 1.6G | 这规格本来就不该跑 7 个服务 |
| 内存已用 | 1.3G，剩 327M | 已经贴着天花板 |
| Swap（虚拟内存） | 4G 里用了 1.9G | 一半以上压在磁盘上 ＝ 靠硬盘当内存用 |
| 容器 | 7 个全在跑 | 没死，但资源已经见底 |
| AI 进程 | 2 个，合计 445M | 两个大脑挤一台小机器 |
| 会话时长 | 8 小时没关 | 这就是 token 悄悄烧掉的地方 |
结论：这不是 bug，是物理。1.6G 内存跑 7 个服务、拿磁盘当内存 —— 不卡才是不正常。
| 你的第一反应 | 听起来很合理 | 真凶通常是 |
|---|---|---|
| 换台更大的机器 | 内存不够就加内存 | 任务太大 / 并发撞 / 没设超时 |
| 换个更聪明的模型 | 笨就是模型不行 | 上下文太长 / 工具返回太多 / 没写停止条件 |
| 是脚本写错了 | 代码有 bug | 页面改版 / 凭证过期 / 没重试 |
| 平台不稳定 | 官方服务不行 | 你没写回执，根本不知道是哪一步没的 |
四条里有 三条，靠「加东西 / 换东西」永远修不好。因为病根不在物件上，在设计和归因上。
进程被系统直接杀掉。
症状：跑到一半就没了，没有任何报错。
写不进去、日志空。
症状：报错说没空间，能明确看到。
几个任务同一分钟挤在一起。
症状：平时好，一到点全崩。
判据：先看症状，再决定加什么。换硬盘治不了内存的病；加内存治不了「任务没拆开」的病。
原理一句话：它每开一次口，都要把前面说过的话全部重发一遍。
| 跑法 | 它要背多少东西 | 结果 |
|---|---|---|
| 挂一个会话干 8 小时 | 第 50 句时，每句都拖着前 49 句 | 又慢又贵，还容易跑偏 |
| 一个活一个短会话 | 每次只带这件事需要的资料 | 快、便宜、判断更准 |
变「笨」先看它被塞了多少东西。上下文砍一半，常常立刻变聪明 —— 不是模型不行，是你让它背着一麻袋东西跑步。
| 脚本 | AI 员工 | |
|---|---|---|
| 遇到页面改版 | 直接崩，只报「找不到元素」 | 看得见就点，看不见会换路子 |
| 遇到没见过的格式 | 整条断掉 | 能现场判断，还会告诉你「这里变了」 |
| 适合什么活 | 精确、稳定、重复 | 要判断、要应变、要说明 |
判据：需要判断的活别用脚本；需要精确重复的活别用 AI 员工。总缺漏不是技术不够，是用错了工具。
90% 的人跳过这一步，直接换机器。先归到 A/B/C/D 四类里，再动手 —— 一次能省下一台机的钱。
预检四样：凭证还能不能用、磁盘够不够、内存余量、时间对不对。
最省钱的一段
三件套：超时上限（卡住就杀）、失败重试、加锁（防两个任务撞一起）。
三件套：回执（干完发消息）、日志落盘、每周体检（列出没跑的）。
最常被跳过的一段
省钱的顺序是从右往左：先把「跑后」补上，你才知道自己在哪一步亏；再补「跑前」，能把失败挡在发生之前。
判据：8 问里有 6 个答「是 / 有」，才算稳。答不上来的那几条，就是你的真实风险点。
别问「稳不稳定」。
问「它挂了，你怎么知道」。
答得出来（有回执、有体检、有日志）＝ 稳定；
答不出来 ＝ 再贵的机器也不稳。