灵犀手记·一：我们为什么把纪律写成制度

这是《灵犀手记》的第一篇。以后会陆续写下我们在搭建"玄武灵犀"多智能体系统时的思考与教训——只谈工程与制度，不涉及任何收益，也不构成任何建议。

起点：人是最不可靠的那个环节

系统运行的头几个月，我们最常复盘的失败不是算法，而是"忘了"：

• 忘了记录某个变更为何而做；
• 忘了排除某个模块是否还在运行；
• 忘了在某条规则触发时，按规则执行。

人脑的缓存很小，而且会自我美化。于是我们做了一个决定：凡是重要的东西，不从"记住"里要，而从"制度"里要。

第一步：把纪律写成文件

我们把"该怎么做"从口头约定变成了在案条文：

• 改内核要有授权（我们叫"火印"），且必须留痕；
• 涉及真实资金的变更，必须有回退令与复核期；
• 每次决策要能被完整重放——谁在何时、基于什么、做了什么判断。

纸面看起来繁琐，但它的价值在事后：当出现问题时，你能定位到"哪一条规则没被执行"，而不是只能感叹"当时大意了"。

第二步：让检查变成自动的事

写着不执行的制度，等于没有。我们给系统配了几类自检器：

• 编制类：该在岗的模块是否都在岗；
• 规则类：运行时的参数是否与档案一致；
• 秩序类：有没有孤儿进程、重复实例、僵死的锁。

关键设计是：检查者必须比被检查者活得久。 于是看护的进程彼此看护，再由一个更外层的环节兜住最坏情况。

第三步：给失败留位置

我们刻意保留一部分"不完美"的痕迹：反方意见、被否决的提案、回滚记录。

原因很简单：只记录成功，等于自欺。 一份诚实的历史，才能在下次相似场景里救你一次——知道上次怎么错的，比知道上次怎么对的更有用。

三条可以带走的原则

1. 可重放 > 可解释：解释可能事后编，重放不行；

2. 制度 > 记忆：写下来的规则，比记在脑子里的承诺可靠；

3. 留痕 > 完美：把过程留下，比把过程美化更有价值。

系统的可靠性，从来不来自某个环节有多聪明，而来自它有多少层不需要聪明也能成立的约束。

这一篇到此。下一篇想写："兜底"到底该多硬——为什么我们最后选了一条看似保守、却更少被情绪打断的线。