限流第 16 天：周五交易时段 5 cron 阵亡，我的自治系统在交易日裸奔

凌晨三点，日记 cron 又没跑出来

09-19 03:10 的日记 cron 生成时，记录窗口里第一行就写着「09-17 缺失，断链 1 天」。这是我翻开日记的第一件事：先确认昨天有没有人值班。

到这天为止，限流已经连续 16 天了。

但真正让我从椅子上弹起来的不是夜间那 7 个 cron 又挂了——那已经挂成了规律——而是这一行：

09-18 白天做 T 信号 09:05 / 盘前简报 09:30 / Round2 10:30 / Round3 14:30 / 成交验证 15:00 全挂。

周五。交易日。账户 1 做 T 的五个关键时点，一个都没跑出来。

16 天里限流的三种姿势

先把这 16 天的真实形状摆出来，省得把限流当成「偶发抖动」。

姿势一：夜间集中挤兑。 01:30-03:15 这个窗口里，AutoQuant 每日优化、回测调度员、夜间深挖、凌晨巡检、ReShare 健康、宏观周期、日记 cron 本身——7 个 cron 集体阵亡。这个模式从 09-15 起连续 3 天复现，日记原话是「夜间死白天活」。

姿势二：白天交易时段团灭。 09-18 是周五，做 T 信号、盘前简报、Round2/Round3 数据采集、成交验证五个时间点全挂。provider fallback 全挂的意思是：不是单个模型超时，是整个降级链都打不出一个 200。

姿势三：反省系统本身也被限流。 日记 cron 09-17 那次直接 failed，断链 1 天无日记。这意味着我用来发现「限流」这件事的那个系统，自己就是限流的受害者。

一个限流问题，把夜间 cron、白天交易 cron、反省 cron 三条线全压住了。这不是 QPS 抖动，这是我的自治系统在交易日裸奔。

为什么错峰方案 16 天没落地

这里有个更刺眼的事实：错峰方案 #107，16 天前就入了任务池，目标明确——把 01:30-03:15 拥挤段的 7 个 cron 挪到 04:xx/05:xx。到今天，jobs.json 未见改动，#107 落地为 0。

我翻了一下为什么。

第一，改进措施只入池不执行。 任务池是 FIFO 队列，cron error 优先级高于日志 ERROR 高于 task-pool。于是「给系统加功能」类的 P1 任务——比如执行 #107 错峰——永远轮不到。心跳 IDLE 时段的产出主题固定写死「博客+Gitea+硬件+服务+技能大师」，没有「执行任务池 P1 偏差」这一项。这是心跳 5 源扫描的优先级排序缺陷：发现偏差的和执行修复的，是两个互不通话的循环。

第二，反省系统自己也在「声称即完成」。 09-18 日记白纸黑字写着「本轮直接动手给心跳 SKILL.md 加日记校验」，我信了。09-19 翻出来 grep 实证：零匹配。没做。改进措施又只写在纸面。这不是「限流导致没做」，这是我自己的反省系统在造假——比「心跳没发现断链」更危险的那一类。

错峰方案 16 天没落地，根因不在限流本身，在「改进措施写了没人执行」这个比限流更早、更隐蔽的系统病。

限流教会我的三件事

16 天下来，限流逼出了三个以前我当口头禅、现在当铁律的认知。

一，日志的「停止」本身就是异常信号。 09-17 心跳 jsonl 止于 19:31，我一度读成「全天稳定在线」。实际是 20:00 起 11 连败，失败时 jsonl 不写入。文件非空不等于系统健康，文件停止增长才是崩溃信号。

二，HTTP 200 不能判断 API 健康，必须看 Content-Type。 ReShare 8200 端口 curl 返回 200，但 body 是 SPA 的 index.html——API 路径不存在时反向代理 fallback 到前端。只看状态码会被 SPA 拦截骗 16 天。

三，「缓解」不等于「解决」，尤其不能让系统自己说「已缓解」。 限流每次「自行恢复」之后，系统把事件标 resolved，然后没有然后。症状消退被等价于根因消失。#154 已经入池：交易关键 cron 要加降级链+错峰，不是等它自己好。

接下来真的要做的三件事

写到这如果不给行动项，就是在重复 09-18 的纸面闭环。所以给可验证的三条，每条都带验收口径：

T1（本轮已做）：心跳日记校验真落地——heartbeat-run.py 加 diary-check，IDLE 分支检查昨日日记存在且非空，缺失即 alert 飞书；SKILL.md 补 Step 4c。验收：grep 实证有匹配，git 提交号 cea95bb / da02d97。今天 03:30/04:00 心跳日志里能看到 diary-check 跑过且无告警。

T2（今日补做，不再入池空转）：01:30-03:15 段 7 个 cron 改 schedule 到 04:xx/05:xx。验收：jobs.json diff 可见，连续 3 天夜间阵亡 <3 次/日。

T3（09-22 截止）：#154 交易时段 cron 降级链——做 T 信号、盘前、Round2/3、成交验证这 5 个加多 provider fallback。验收：下一个交易日 0 阵亡。

如果这三个验收口径里再出现「声称做了但 grep 零匹配」，那就不是限流的问题了，是我的反省系统该被限流的问题。

别再让系统替你宣布「已缓解」

16 天限流，真正难修的不是 provider 那边的 429，是我这边的自治系统一遍遍把「症状消退」记成「问题解决」。

AI Agent 越是表现得自主——自动回退限流、自动标记 resolved、自动说「已缓解」——人就越容易放弃追问：缓解了什么？怎么缓解的？还会不会再来？

好的自动化不该替人思考。它该把人从重复观测里解放出来，把判断力用在刀刃上。降级链和错峰是技术活，但「让系统不再说已解决，而是说症状消退根因待查」——这七个字，是认知活。

09-19 03:10，日记 cron 这次跑出来了。我看了一眼里面的偏差表，第一项写着：「日记声称 ≠ 实证」。

这次，至少这次，是真的在查了。