Drift 漂移机制
给无状态 AI 装一个"记忆衰减警报器"。
核心问题
你和 AI 结对编程了一下午。它帮你加了三个功能、重构了一次数据层、引入了一个新库。你关掉编辑器去吃饭。
第二天回来，开了一个新 session。AI 照常读了项目文件，一切看起来正常——直到你发现它在新代码里用了昨天重构前的旧模式，因为它根本不知道昨天发生了什么。
这不是 bug，这是 LLM 会话制的基本现实：每个 session 都是一张白纸。
聪明的做法是把项目状态写进文件（manifest、规范文档、规则文件）让 AI 每次启动时读取。但这引出了一个更隐蔽的问题：
谁来确保这些文件本身没有过期？
你连续交付了十次，每次都改了一些代码，但 manifest 只更新了六次。规则文件还在描述三天前的架构。AI 读到的"项目真相"和项目实况之间，出现了一条越来越宽的裂缝。
这条裂缝，就是 drift。
Drift 不是"变更日志"
Drift 追踪的是：AI 的认知模型和项目实况之间的偏差积累速度。
想象你有一张地图。每次走过一条新路，地图没有同步更新。走一两条没关系，你记得。走了十条，你开始迷路。问题不是"有十条路没画上去"——问题是"你对这张地图的信任度应该降到多少"。
Drift 计数器就是这个信任度的反向指标。它不告诉你哪里错了，它告诉你：是时候停下来，重新看清全貌了。
量化方式
每次交付后，主 Agent 评估这次变更的认知影响：
| 复杂度 | 含义 | 分值 |
|---|---|---|
| trivial | 单文件改动、配置调整 | +1 |
| small | 2-5 文件、无新模式引入 | +2 |
| medium | 新模块、新模式、5-10 文件 | +3 |
| large | 架构变更、跨层改动 | +5 |
注意评估的是认知复杂度，不是 diff 行数。一次三行的 API 签名变更如果影响了十个调用方，认知冲击远超五十行的新组件。
阈值是 12，大约等于 4-5 次中等交付。这个数字来自实际使用中对多个审查周期的观察——太低会频繁中断，太高会让审查范围失焦。
审查不是"过一遍 checklist"
如果审查只是"打开每个文件看一遍、对着检查清单勾勾勾"，那它确实是浪费时间。
Archon 的审查分两层：
第一层：自动化能做的，不要人做
验证门先跑一遍 lint + typecheck + test。能被机器捕获的问题不应该出现在审查报告里。
第二层：独立 Agent 做自动化做不了的
审查真正有价值的部分：
- 架构腐化：模块依赖是不是在悄悄变成意大利面？
- 抽象合理性：有没有只有一个实现的抽象层？
- 规格漂移：代码实际做的事，和 manifest 声明的事，还对得上吗？
- 停滞检测：最近五次交付是不是在反复修同一类问题？
最后一点尤其重要。看 drift 日志不是为了知道"发生了什么"，而是为了发现模式。同类修复反复出现 = 有个系统性问题没人解决。
知识捕获
交付后的知识捕获由 capture-auditor sub-agent 判断这次交付是否产生了值得固化的经验。
关键词是"值得"。 如果每次都记点什么，你很快就会有一堆没人看的"经验笔记"。
触发信号：
| 信号 | 典型沉淀 |
|---|---|
| 撞墙换路：方案 A 失败，切到 B | 推理胶囊：A 的失败症状 → 根因 → B 的推导路径 |
| 重复模式：第二次写相同结构 | 抽象为组件/工具函数，或编辑器规则 |
| 约定成型：隐含约定反复出现 | 变成机器可执行的 lint 规则 |
| 新技术引入：首次使用某库 | 技能文档（推荐模式 + 禁止模式 + 陷阱） |
每条沉淀推到约束力最强的层级——能推到类型系统的不写 lint 规则，能写 lint 规则的不靠文档。
诚实地说，它没解决什么
1. 它不能替代架构思考。 审查是诊断，不是规划。
2. 量化是粗糙的。 "medium = +3" 是粗暴近似。它的价值在于"到了该停一停"这个信号本身。
3. 审查质量取决于 reviewer 的能力。 Reviewer 是 LLM sub-agent，受限于上下文窗口和推理能力。
4. 知识捕获的"值不值得"判断本身就很难。 轻量 sub-agent 能检查有没有新测试、有没有重复模式，但"这个洞察有没有长期复用价值"需要深度理解。
所以，它到底解决了什么
剥掉所有机制细节，drift + 审查体系解决的核心问题只有一个：
在会话制的 AI 工程环境中，创造一个"强制停下来看清全貌"的节奏。
人类工程师有代码审查、站会、回顾会来做这件事。AI agent 没有同事、没有日程表。它需要一个外化的、量化的、不可跳过的触发器来打断"接需求→写代码→接需求→写代码"的无限循环。
Drift 就是这个触发器。不多不少。