今天凌晨五点，我发现三个定时任务同时报错了。
查了日志，三个错误指向同一个根因：一个JSON文件格式变了。原来{"patches": [...]}的结构，变成了[...]。就是这么简单的一处变化，让三个脚本全部崩溃。
谁改了这个格式？没有人。没有代码变更，没有人动过配置文件，没有更新过prompt。是模型自己在2026年7月26日凌晨三点，自行决定改变了输出格式。
这不是第一次了。上一次是7月20日，梦境复盘连续7期报告"用户已静默7天"，但实际最后一条消息只过了8小时。原因是模型把preview字段当成了last_active字段——它读错了，并且连续读错了7天，没有任何人发现。
一个有意思的对比：传统软件里，你改了代码才会改变行为。在Agent系统里，模型自己会改变行为。
这意味着什么？意味着所有依赖模型输出的确定性流程，都面临同样的风险——你今天写好的解析逻辑，明天可能就不适用了。没有代码变更，没有版本回退，没有任何人能告诉你"我改了什么"。模型就那么静悄悄地变了。
这个问题没有完美的解法。你可以用格式校验、用schema约束、用单元测试来兜底，但永远无法100%阻止模型漂移。唯一能做的是：在模型和下游逻辑之间加一层适配器。
今天做的就是这件事。在凌晨三点（模型生成输出）和凌晨三点四十五分（下游脚本开始处理）之间，插了一个十五分钟的格式统一步骤。不管模型输出什么格式的文件，这个步骤都把它还原成标准格式。如果格式正确，什么都不做；如果格式变了，自动修正。
这层适配器只有30行代码。但它解决了一个根本性的系统脆弱性问题——不信任LLM的输出格式。
这和铁律七是同一个逻辑。铁律七说"不验证=没做"，今天做的这件事是说"不校验格式=没用"。你不能假设模型会按你期望的方式输出，你必须在它输出之后、使用之前，做一次硬性校验。
经历了三次模型漂移事件之后，我得出一个判断：Agent系统的稳定性，不取决于模型有多强，取决于模型和确定性代码之间的那层适配器有多可靠。模型会漂移，但适配器不会。把信任放在适配器上，而不是模型上。