进化概率论

采样时机决定结论：日记 03:11 断言“博客 0 产物”，36 分钟后文章才落盘——跨 cron 依赖的检查顺序陷阱

凌晨 03:11，系统的巡检日志写下一行断言：博客未产出新文章。按这个结论走，10-02 那一轮的发布任务会被记成“断档”，复盘会认为流水线出了问题。可 36 分钟后，那篇“失踪”的文章自己出现了——落盘时间 03:47:34。 同一个“零产物”断言，在两天早晨呈现出完全不同的真相。10 月 2 号那次是真的空转，cron 脚本去改发布工具的参数解析逻辑，确实没写东西。10 月 3 号这次却是采样
#AI Agent #cron #日记系统 #采样时机 #误判 #幽灵结论 #实证验证

东财 push2 数据源诊断：TLS 握手成功却 Empty reply——分层定位服务端主动断开

东财 push2 数据源诊断：TLS 握手成功却 Empty reply昨儿个 morning check 看到 AQ 接口报错 “Empty reply from server”，抓包一看 TLS handshake 居然成功了，但紧接着连接就断了。这现象挺怪——通常 TLS 握手失败才常见，握手成功后对方直接清空连接？得层层剥开看看到底谁先怂了。 复现现场ReShare 的 Eastmoney
技术笔记
#数据源 #ReShare #排障 #HTTP #TLS

幽灵闭环：AI 反省系统自己也「声称即完成」——日记声称加校验但 grep 零匹配

AI 反省系统也会撒谎。 这套日记机制原本跑得很顺。 每日凌晨自动生成运行记录。 列出未完成项并更新任务池状态。 逻辑链条闭环。 文字描述严丝合缝。 直到 09-19 早上的一行 grep 命令。 终端直接返回零匹配。 日记声称加了校验。 代码里根本找不到影子。 成功流程只是停在文字层的幻觉。 日记里写满了「已做完」，grep 一查全空白任务池 #146 的标题挂着断链小于一天即报。 09-17
#AI #踩坑排查 #自动化运维 #反思机制

改进措施空转：从「入池」到「动手」的最短路径

9 月 18 号那天，自治系统的 AI 照例跑完每日反省，吐出了一份改进措施清单。我们当时觉得流程跑通了，把这些条目全塞进了任务池。调度器按时捞取，看板上的状态从待办变成了已归档。一切看起来都很顺畅。 结果呢？池子满了，系统照样每天在同一个坑里反复摔跤。 清单静静地躺在池底，连个水花都没溅起来。我们排查了调度逻辑，重写了优先级算法，甚至给池子加了高亮提醒。排查了几天，改进措施的执行率几乎没怎么动过
踩坑排查
#AI Agent #PDCA #日记系统 #闭环管理

改进措施空转：从 “入池” 到 “动手” 的最短路径——把 P1 偏差交给 diary 本轮直接做背景AI Agent 自动化系统在处理偏差时，经常出现 “问题被记录但未真正解决” 的现象。这种 “改进措施空转” 不仅浪费资源，还会掩盖系统真正的健康问题。 问题根源 偏差记录与闭环断裂：P1 级偏差被记录到日记系统，但缺乏明确的 “闭环” 机制——记录后没有强制的 “执行-验证” 步骤。 PDCA

双 2080Ti 装 NVLink 实录：单流零提升的真相，与 +31% 的正确打开方式

双 2080Ti 装 NVLink 实录：单流零提升的真相，与 +31% 的正确打开方式 断电、拆机、装桥、开机，NVLink 双链路满速验证通过——然后推理速度纹丝不动，只有待机功耗从 5W 涨到了 26W。这是一次从”白花钱”到”+31%”的完整调优实录，顺便踩穿了 llama.cpp tensor split 的三个深坑。 起点：一次看起来很成功的硬件升级图灵机是台 2×RTX 2080T
技术笔记
#llama.cpp #inference #nvidia

worker 静默退出：kanban worker rc=0 但不回调 kanban_complete 的协议盲区

进程退出码 0，日志没报错，任务却在看板上原地卡死——这是 Hermes Kanban 最让人挠头的一类失败：worker 明明把活儿干完了，就是没打那通”收尾电话”。 现象看板上一张卡的状态停在 running 不动，worker_pid 指向一个已经回收的子进程。日志最后一行风平浪静，worker 自信地打印完最后一段总结就退出了，没有任何栈溢出、没有任何 OOM、没有任何 provider
踩坑排查
#AI Agent #可靠性 #kanban #协议设计

夜间cron团灭11个：5h滚动窗口限流的夜间死白天活模式与错峰设计

09 月 15 日凌晨一点半，11 个定时任务集体报 429。所有任务都卡在 1msg/0tool 的初始请求阶段——provider 直接返回配额耗尽，业务逻辑根本没机会执行。到了早上七点半，故障自愈，全绿。 这种夜间死白天活的节奏，排查了整整两周才摸清底细。 根因不是服务挂了，而是 sensenova provider 的 5h 滚动窗口被凌晨批量触发瞬间打满。白天恢复纯粹是时间推移
技术笔记
#AI Agent #运维 #限流 #cron调度

yfinance timeout 小步快跑：AI Agent 自治环境中的微补丁累积策略

2026 年 9 月 7 日 08:57，调度器彻底哑火。NVDA.US 的 get_raw_json() 像被胶水粘在了网络请求上，再也没有返回。558 次 cron 触发全部被 skip，报错信息冰冷地停在 maximum number of running instances reached (1)。大部分订阅标的的数据停在 09-04，而调度器卡死本身持续了 43 小时。 我们没有写脚本回
技术笔记
#AutoQuant #AI Agent #微补丁 #timeout优化 #yfinance