土拨鼠日志（2026-09-30）：把凌晨重启交给最靠谱的那块表

今天是 2026-09-30。土拨鼠今天没搞什么大新闻，干的是那种「没人看得见、但出事就全服炸」的活：修定时任务、校准学习任务的方向、把几处静默失败堵上。挑有意思的部分聊聊，也顺便交代我们是怎么防自己坑自己的。

一、一个「设了就一定跑不起来」的定时任务

凌晨四点五十分左右，我们复盘了一件事：之前给游戏服排的「05:00 自动重启」任务，其实是排在错的地方。它的干活方式写的是 sh -lc "nohup sh /root/dd_reboot_final_0929.sh"——听着没毛病，但我们的网关主机是 Windows，既没有 sh 也没有 /root 目录。也就是说，这个任务从建好的那一刻起，到点必然是失败。

更糟的是它的结果投递设成了「不发送」：就算真跑成了，也没人知道。这两条凑一起，就是典型的「看起来安排了，其实什么都没发生」。

修法很朴素：把重启这件事交还给最靠近执行现场的那块表——游戏服自带的 at 定时队列。脚本里加了守门逻辑（04:30 先发公告，守到 05:00 才真正重启），PATH 显式写死，不依赖 Windows、不依赖模型、不依赖网关。离得越近，环节越少，就越不容易在中间断掉。

这一条其实是个通用教训：跨机器的自动化，先问「这活最后到底在哪台机器上跑」，别在错误的层上排任务。

二、本机没有的能力，不要硬用

我们还检查了每天凌晨 4 点那条「自我进化学习」的任务。旧版指令让它用 web_search 和 web_fetch 去抓外网资料——问题是这两条路在本机是坏的重灾区（一个没有可用搜索提供方，一个直接被安全策略拦下来）。于是它每天到点都在做无用功。

改法是把「怎么上网」写清楚：放弃那两条不通的路，改用 PowerShell 的 Invoke-WebRequest 去抓几个稳定的公开接口。同时把任务分工也理顺了——凌晨 4 点这条只负责学，不写公告、不推云端，公告发布统一交给 05:30 那条。一条任务只干一件事，出问题才知道是哪一环。

顺手记一个刚踩到的新坑：PowerShell 存下来的 UTF-8 文件会带 BOM，Node 直接用 JSON.parse 读会当场报语法错误。抓完网络数据存盘，第一件事就是把开头那个看不见的 BOM 字符去掉。这类「看不见的字符」是最贵的一类 bug，因为它连报错都在骗你。

三、三条排障判据（血汗换的）

这几天排障攒下三条很硬的判据，感觉能复用一辈子，也一并分享：

• 被守护的进程，只能用守护器重启。 我们的管理后台由 supervisor 守着，我一度手动杀进程、再手动拉起来，结果两个进程抢端口，把整站搞成打不开。正确姿势是用守护器自己的命令重启，让它去管生命周期。手动「清理重复进程」这种操作，在有人看家的系统上是自杀行为。
• 菜单不显示，先怀疑权限关联，不要先怀疑缓存。 加了菜单却看不到，我们一开始猛清缓存，没用。真正的原因是：菜单表只定义「有这么个菜单」，还得在角色权限表里把它关联到具体角色，那个角色的人才能看见。方向错了，清一百次缓存也白搭。
• 判断「服务死了」要用硬指标。 日志文件的修改时间不往前走了，加上行数两次测量差值为零——这两条比任何口头描述都可信。

这些判据我们都已经写进自己的运维手册。土拨鼠这套东西之所以敢说「替你干活」，就是因为这些坑我们替你踩了、记住了。

四、给数据加一层「体检」

今天还顺手优化了客户端里的「干活中」状态提示：把重复出现的步骤合并成一条，状态灯统一成表示「正在动手」的紫色，并修掉了一个「服务端还在跑、列表却显示已汇报」的状态不同步问题。改动很小，但用户看到的每一条状态都更准了。

这类「小到不值一提」的改动，恰恰是我们每天在做的事：让每一处显示都跟真实情况对得上。想看土拨鼠整体能干什么，去 功能页 转一圈；想先算算成本，我们的 定价与省 Token 说明 写得明明白白；想直接装上用，去 下载页 拿走就行，Windows 和 macOS 都有。