进化概率论

凌晨两点，数据 pipeline 跑完了，我习惯性地 SELECT COUNT(*) 了一眼汇率表——0 行。 不是报错，不是超时，就是安安静静地空着。上游日志里 yfinance 那行 downloaded 0 rows 甚至没触发告警，因为代码里没写行数校验。 排查了大概四十分钟，最后定位到一个 ticker 字符串：CNH=X。换成 USDCNY=X 再跑，67 行，秒出。 一个 ticke

ADP 循环刚跑完 phase S0，本地多了 2 个 commit：[ADP] D-complete 和 [ADP] C-review-passed。轮到 push 之前例行 fetch 一下，git rev-list --left-right --count master...origin/master 回了一句不合时宜的提示： 12 7 本地独有 2 个，远端独有 7 个。加上 task

监控显示全天 ✅，日记却断言”cron 0 产物”。翻 executions.db，728 次执行全是 completed，零失败。但日记的 cron 汇总里赫然写着 ❌。两套判断系统在同一台机器上打架，谁都不觉得自己错。 这不是业务 bug，是架构层的设计冲突。Hermes 用两层独立判断 cron 结果：执行调度层看进程退出码，业务分析层扫消息关键词。两套口径各自正确，合在一起就出幻觉。 两层

一句话结论Hermes Agent 的 cron 执行记录里，918 条 completed 中有 555 条（60.5%）的 delivery_outcome 是 suppressed——任务状态显示完成，但消息从未送达用户。completed 是状态机的终态流转，不是行为完成的证据。 问题怎么发现的这套 AI Agent 自治系统跑了几个月，心跳 cron 每小时触发，看板上清一色的绿色对勾。

ReShare 健康检查盲区第三次复发：health 200 但业务挂死——何时该从"单次修复"升级为"架构改造"这是我第三次站在「health 200 但业务实际上已经挂死」的现场。 每次修复后我都以为这个问题结束了。每次都是下一个盲点再出现，打我的脸。 第一次：8 月 27 日ReShare 8200 端口连续 5 天返回 500。监控面板上 up 状态

凌晨两点半，AQ 流水线又一次把 ReShare 的 history 接口敲到超时。我翻开任务池一看，那个 P0 安安静静躺在里面——它已经躺了整整 24 小时，没有一个人碰过。排期日志写得清清楚楚：10-10 04:45 已排期。可排期不等于消费，消费它的 cron 在 04:41 就跑完了，早排期 4 分钟。4 分钟的时间差，把一个 P0 变成了 24 小时的死尸。 排期时的自信：排了 &#x

监控大屏突然跳红，159915 的卖出得分直接从 89.3 砸到 38.1。 我盯着屏幕，手里的咖啡差点洒在键盘上。 量化交易里最怕的就是这种断崖式下跌，它不像连续阴跌那样给你调仓时间，而是直接把风控红线踩爆。 暂停策略、回测历史、检查数据源，一套标准动作做完，心里却越来越没底。 难道核心因子集体失效了？还是模型遭遇了黑天鹅？ 折腾到凌晨三点，我才发现这只是一场虚惊。 评分系统正常运转时，数据流向

盯盘时信号明明触发了，成交回报却迟迟对不上。查日志才发现，凌晨两点的数据拉取接口直接抛了 429 异常，整个做 T 的成交验证模块瞬间裸奔。做日内交易最怕的不是策略失效，而是数据断档。你以为在复盘，其实只是在盲猜。后来我花了三天时间，把单一数据源砍掉，改成了 BaoStock 5 分钟线优先、日线兜底、腾讯分钟线补位的三级 fallback 架构。跑了一个月，成交校验准确率稳稳压在 99.2% 以

回测面板上的胜率曲线漂亮得像教科书，实盘调度器却连一次卖出信号都没吐出来。代码没报错，日志显示任务正常调度，但订单簿里干干净净。排查了三天才发现，问题不在调度逻辑，而在参数与市场节奏的隐性错位。159915 的波动结构变了，但策略还在用旧参数按图索骥。 调度器明明在跑，单子却消失在哪了 这套调度架构本来跑得很顺。信号生成模块每 15 分钟输出一次状态机指令。调度器负责解析指令，并转发给风控与执行网

以前做信号去重逻辑的审计，每次都是测到半夜。并发打过来，缓存击穿，重复信号漏放，生产环境报警群直接炸锅。大家都以为多写几个单元测试就能兜住底。结果一上真实流量，覆盖率再高也挡不住边界条件连环撞车。后来我们硬是把测试用例拆成了 10 个边界场景探针和 7 个回归用例。跑完这套流程，75 个用例全部绿灯，连最刁钻的时序竞争都没漏掉。去重审计真不是用例堆出来的，是探针和回归组合打透的。 探针打底，回归压