事故与整改

备份在、回滚却从未生效；五道闸门里有一道判据先坏了；默认最高规格是我亲手造出的 bug。这一组不写「以后小心」，只写让下次能被机器拦住的那一步。

系列

7 篇

恢复机制存在了 9 天，日志显示它工作正常——但它一次都没真正生效过。根因是打包用相对路径、解压用 -C $HOME 的不匹配，产物是一段不该存在的 ~/home 目录。复盘这个静默失败，以及改完之后的 known-good 检查点与级联恢复设计。

2026-10-11

一段脚本只要没被真的执行过，它就只是文本——而文本会以非常安静的方式损坏：粘贴时丢一个空格、换行处截断一个字符、正则少一个右括号。用一个真实案例给出三关判据（能解析、能重复执行、失败可回滚），以及两处容易被忽略的部署约束。

2026-10-11

一篇博客被编排层拆成 8 个任务、产生 393 条跨 agent 消息。问题不在哪条门禁坏了，而在编排层根本没有「级别」这一维，于是最高规格成了默认值。复盘我怎么加上这一维、把「只能更轻」变成机器不变量，以及我为这个改动亲手造出、又被独立复核对出来的一个危险 bug。

2026-10-13

我给这台 agent 的改动加过很多能力，却只有一个六道合成题的行为闸门。真正的问题在落地五件测量工具那天暴露：重放闸门把四道真实任务里的两道判成回归，查下去发现坏的是判据，不是系统。这篇写这五件工具各自回答什么问题、什么时候触发、以及每件证明不了什么。

2026-10-18

让 agent 自己长技能，真正的风险在于它把错的做法记成经验：技能库同时是它自己的判据来源，错一次会被记住很多次。我把它做通了（检索→计划→白名单执行→成功后蒸馏成技能写回同一个知识库），但通读代码后找到三处设计缺陷：白名单把解释器放了进去、自动沉淀默认开启、参数替换发生在分词之前。

2026-10-11

现场调参最贵的失败不是"参数调错了"，而是"调崩之后回不去"。所以执行框架的设计目标是让每一次变更都可回滚、可验证、可审计；优化更快只是副产品。把"回滚永远可达"拆成六件可以写成脚本的事，并给出启动后五步验证、故障关键字速查与算子级杠杆的落点。

2026-10-11

一个自动化闭环最容易被漏掉的部分不是流程本身，而是"谁来验收、拿什么验收、不通过怎么办"。复盘两个真实系统的设计：三位一体对齐与不做清单，以及一套把"还行"变成数字的评分卡、五层监督与自动卡点——并给出一个关键判据：规则与机制的差别，在于有没有卡点。

2026-10-11