1. 四家面对同一个误用的反应
一个内部接口总被误用：模型习惯直接调创建订单，而正确做法是先创建草稿再提交。四家 Coding Agent 面对这个反复出现的问题，会走四条不同的路。
Claude Code 会记下来。 它在会话中观察到一个事件：调用创建订单后返回错误，随后模型改调草稿接口成功。这类"动作与其结果"的配对进入观察流。同一模式在多个项目里出现、置信度足够之后，它会被提炼成一条判断，再生成一份 Skill。
Codex 会等一批再说。 它先把这批轨迹存着，等空闲期到了、攒够了一批，才开始抽取。抽取分两步：先逐条抽，再全局整合。整合的产物是一份可回滚的工作区。
OpenCode 什么都不会发生。 它不记录"模型做错了什么"，也不做归纳。要让它知道这条约定，得有人在构建之前把约定写进指令文件。
DeepSeek Harness 也不会发生。 同理，除非有人写一个检查插件挂上去，在调用前拦一下。
四条路径的差别不在能力，在"学习发生在哪个时刻"，以及"管线停在哪一步"。
2. 四环节管线与「停在哪」
上一篇给出闭环的四个环节：信号、判断、动作、验证。落到具体实现，这四个环节可以继续拆成一条管线：
观察（记录什么）→ 提炼（产出什么中间态）→ 晋升（什么能上线）→ 审计（错了怎么办）。
四家的差别不在能力，在管线停在哪一步。而停在哪一步，直接决定了这类系统能学到什么。
| 实现 | 观察 | 提炼 | 晋升 | 审计 | 能学什么 |
|---|---|---|---|---|---|
| Claude Code | 有 | 有 | 有 | 有 | 行为模式、成败归因 |
| Codex | 有 | 有 | 有（可回滚） | 弱 | 任务经验、记忆效用 |
| OpenCode | 无 | 无 | 构建期 | 版本控制 | 只有人写进去的 |
| DeepSeek Harness | 无 | 无 | 装配期 | 换配置 | 只有人装配的 |
这张表解释了一个常见误解：后两家不是「做不出自动进化」，是定位不同。它们把能力外置成插件与配置，进化等于换一套装配，主体是人。
后面四节逐环展开，每一环给出四家的具体做法与数值，第 9 节做横向对照。
3. 观察环节：记录粒度
Claude Code 的观察事件分五类：用户消息、助手消息、工具开始、工具完成、工具错误。每类事件带一个结果标记（成功、失败、未知）。
这个粒度值得注意：它记录的是「动作与其结果」，不是「对话内容」。这让后续的归纳能落到具体行为上，而不只是文本相似度。
一个对比：如果只记录对话文本，提炼阶段只能做「这些话有什么共性」；如果记录动作与结果，提炼阶段能做「这个动作在这些情况下失败了」。后者的结论更可执行。
Codex 的观察是轨迹加使用统计。轨迹提供「发生了什么」，使用统计提供「哪些记忆被用过」。
后者是它相对独特的地方：一条记忆被取回几次、最近一次什么时候用，都进状态库。这让「30 天未使用不入选」这类规则成为可能——没有使用统计就无法判断「这条记忆是不是死的」。
3.1 结果标记的三态
五类事件里只有工具完成与工具错误两类带明确结果。用户消息与助手消息的结果是未知——无法从一条消息本身判断它导致了成功还是失败。
三态比两态多出来的那一态是必要的。把未知强行记成成功会让统计虚高，记成失败会让统计虚低。分开记的意义在于：只有带明确结果的事件参与成败归纳，其余事件参与过程重建。
这条区分在实践中常被忽略，结果是成功率被大量未知事件稀释，看不出真实趋势。
3.2 轨迹与跨度
一次任务是一个轨迹，内部按工具调用切成跨度。切分粒度影响查询成本与归因精度。
| 粒度 | 日志量 | 能定位什么 |
|---|---|---|
| 整个任务一条 | 最小 | 只知道整体成败 |
| 每次模型请求 | 中 | 能定位到哪一轮开始偏 |
| 每次工具调用 | 大 | 能定位到哪个动作出错 |
| 每次函数调用 | 最大 | 噪声过多，归因反而变难 |
一个可用的粒度是：每次模型请求一个跨度、每次工具调用一个跨度、压缩与记忆操作各一个跨度。这覆盖所有会改变行为的事件，且不把内部实现细节暴露成日志。
归因需要的最低粒度是工具调用。首个错误往往落在某次具体的工具调用上，或者落在「该调用而没有调用」的缺口上。后者需要一条额外记录：本轮有哪些工具可用、模型选了哪个。只记录实际调用，发现不了漏调。
4. 提炼环节：中间态的形状
中间态的形状决定了晋升环节能做什么判断。
Claude Code 的中间产物叫「直觉」——一条从观察中提炼出的判断，带领域分类与置信度。领域分七类：工作流、测试、调试、代码风格、安全、版本控制、项目。
分类的作用是路由：不同领域生成不同前缀的 Skill 名，避免所有生成的 Skill 都叫「learned-skill」。
直觉有七种状态，这套状态机是四家里最完整的：
| 状态 | 含义 | 出口 |
|---|---|---|
| 待定 | 刚提炼出来，证据不足 | 活跃、被替代、退役 |
| 活跃 | 已达到晋升条件 | 陈旧、被替代、冲突挂起 |
| 陈旧 | 长时间未被验证 | 退役、重新活跃 |
| 被替代 | 有更新的直觉覆盖它 | 归档 |
| 退役 | 明确不再适用 | 归档 |
| 归档 | 保留记录，不再使用 | 无 |
| 冲突挂起 | 与已有某条矛盾，需人裁决 | 活跃、退役 |
七种里最有价值的是「冲突挂起」。它表示「这条直觉与已有的某条矛盾」，阻止了系统在未裁决的情况下用新直觉覆盖旧直觉。
这个设计的实际含义是：系统承认自己可能得出矛盾结论，并把裁决权交回给人。
Codex 的中间态分三层：摘要是每轮注入的跨任务信号，手册是可检索的操作层，技能是可执行的流程。三者的更新频率不同——摘要每次整合重写、手册按块更新、技能独立演进。
分层的理由是回收成本不同：摘要每轮都付，所以必须极短；手册按需检索，可以详细；技能命中才加载，可以完整。
5. 晋升环节：条件与产物
从中间态到可上线的东西，Claude Code 设了两个条件。
跨项目数。 同一条直觉在多个项目里被观察到，说明它不是某个项目的特例。这个条件的代价是等待——需要多个项目都出现同类问题。
平均置信度。 默认阈值 0.75，低于此不生成。
两条都过才生成产物。产物有三种形态：Skill、Agent、命令。选哪种取决于内容的形状——流程性强的生成 Skill，需要独立上下文的生成 Agent，短动作生成命令。
三种形态的存在说明一件事：晋升不只是「把结论写下来」，还要选择「以什么形式存在」。选错形式的后果是产物用不上——一条三步的流程写成命令，模型每次都要手工把三步串起来。
Codex 的晋升条件不同，它按时间与数量：6 小时空闲加 10 天窗口、256 条上限、30 天未使用不入选。
两个条件集对比：
| 维度 | Claude Code | Codex |
|---|---|---|
| 触发条件 | 跨项目证据 + 置信度 | 时间空闲 + 时间窗口 |
| 数量控制 | 无显式上限 | 256 条上限 |
| 淘汰依据 | 陈旧判定 | 使用统计（30 天未用） |
| 产物形态 | Skill / Agent / 命令 | 摘要 / 手册 / 技能 |
差别在「什么时候算成熟」：Claude Code 认为多项目证据是关键，Codex 认为时间窗口是关键。前者更保守，后者更快。
6. 审计环节：可回滚与可审阅
能不能回滚，决定了系统敢不敢把审批放宽。
Codex 的审计设计最完整：产物是一份工作区里的 git 基线，任何一次整理都能回到上一个已审核状态。批准的位置在「整合前看工作区差异」——系统生成差异，整合子代理读它定位改动，人可以在合并前审阅。
这个设计把「审计」变成了 git 操作，代价几乎为零。
Claude Code 的审计靠状态机：陈旧判定、退役、归档，让一条 Skill 可以被降权而不必删除。
两家都做不到一件事：判断一条已被采纳的直觉是不是从一开始就错了。它们能标记「不再适用」，但不能追溯「当初为什么采纳」。这个缺口在治理上是个实际问题——如果一条规则造成了损害，事后只能看到它被采纳了，看不到采纳时的证据。
两家都做不到一件事：判断一条已被采纳的直觉是不是从一开始就错了。它们能标记「不再适用」，但不能追溯「当初为什么采纳」。这个缺口在治理上是个实际问题——如果一条规则造成了损害，事后只能看到它被采纳了，看不到采纳时的证据。
7. 睡眠学习的五步周期
四环管线是一个抽象。落到可以长期运行的实现，它通常表现为一个周期性进程——用睡眠做类比，但不必真的在夜间跑。五个步骤各自有可实现的判据。
7.1 第一步：触发
四种触发条件，任一满足即可启动：时间间隔到达、新增已评价轨迹数量到达阈值、存储容量接近上限、错误频率上升。
前面还要加一个前置条件：确认当前没有高优先级在线任务。这条的理由与「主会话禁止等待」是同一个——整理是后台工作，它不能占用正在服务用户的资源。
四选一的差别在于响应速度与稳定性。按时间触发最稳定但可能空跑；按轨迹数触发更贴合实际负载；按容量触发只在真的需要时跑；按错误频率触发反应最快，但也最容易被偶发波动误触发。
一个实践组合是「时间间隔为主，容量与错误频率为辅」：主触发保证定期整理，辅触发应对突发。
7.2 第二步：定向
读取正式知识、提示词、Skill 目录及其版本，了解已有能力，以及哪些部分不可修改。
这一步常被省略，代价很大。不定向的整理会重复提炼已有内容——同一个结论被写成第二条规则，两条并存，后续无法判断哪条有效。
「哪些不可修改」这一项尤其要显式列出。如果整理进程不知道哪些东西它不能碰（验证器、测试用例、发布判据、审计日志、稳定版本备份），它会在某次整理里「顺手优化」掉它们。
7.3 第三步：采集与整合
从近期已评价轨迹中寻找新信号，合并重复内容，标记冲突与适用条件，优先生成局部补丁。
四个动作有先后。「优先生成局部补丁」的意思是：能改一句话就不要重写一整条，能改一条就不要重排整个目录。局部补丁的验证成本低、回滚容易、审阅快。
合并重复内容这一项需要判断「什么算重复」。文本相似度不够——两条规则可能用词完全不同但语义重复，也可能用词几乎一样但适用条件相反。可行判据是「主体 + 属性」：主体与属性都相同才是重复，主体相同属性不同是并列，主体相同属性相同值不同是冲突。
标记冲突与适用条件是第三步最重要的产出。一条新规则如果与已有规则冲突，正确的处理是都保留并标注适用条件，交给后续裁决；直接覆盖会让系统悄悄丢掉一部分行为。
7.4 第四步：验证与审批
在迁移集、保留集和安全集上评估待验证版本，高风险写入等待人工批准。
三个集合的分工：迁移集检验「新规则能不能用在类似但不完全相同的场景」，保留集检验「有没有把原来能做的做坏」，安全集检验「有没有引入新的风险行为」。
三个集合都要，因为它们的失效方向不同。只跑保留集会漏掉「新规则根本没用」；只跑迁移集会漏掉「修了这个坏了那个」；只跑安全集会漏掉「更安全但更没用」。
「高风险写入等待人工批准」需要定义什么算高风险。可用的判据有三条：涉及权限或对外动作、影响范围跨多个任务族、修改了被大量引用的规则。三条任一成立即进人工队列。
7.5 第五步：修剪与索引
更新检索索引，把长期不用或被新证据推翻的能力标记为过期，或归档、删除，同时保留来源和回滚版本。
这一步是唯一会减少内容的步骤。前面四步都在增加或修改，只有这一步做减法。缺了它，系统的知识量单调增长，而检索准确率单调下降。
三个动作的区别：标记过期保留内容，可恢复；归档移出检索范围，仍可查；删除不可恢复。
判据按证据强度分：被新证据明确推翻的删除；长期不用且无法确认是否仍适用的标记过期；影响范围已消失的归档。
8. 容量约束与周期性整理
持续进化不是让知识、提示词和工具无限增长。上下文腐化会在更长时间尺度上重现：经验文档互相冲突、提示词被大量局部规则淹没、Skill 库出现重复能力、多次微调造成灾难性遗忘。
8.1 容量约束的必要性
纯文本记忆也需要容量约束、分层加载和主动整理。
一个可查的实现为每个项目维护一份索引加按主题拆分的详细文件：会话启动只加载索引的有界前缀，其余按需读取；当索引接近上限时，系统要求合并或移走细节。
三个设计点值得记。
第一，索引有界。这个界不是建议值，是硬上限——超过就必须整理。没有硬上限的索引会持续膨胀，直到每次会话启动都要付一笔固定的大成本。
第二，分层加载。索引常驻，主题文件按需。这与 Skill 的三层披露是同一个思路，只是对象从「流程知识」换成「项目事实」。
第三，主动整理。系统在索引接近上限时要求模型自己合并。这一条把整理责任交给了产生内容的一方，不必等一个后台进程。
8.2 六条整理动作
周期性离线整理的具体动作，按收益从高到低：
| 动作 | 处理什么 | 判据 |
|---|---|---|
| 合并重复经验 | 同一主体同一属性上的多条 | 保留来源与版本，取最新且证据最强的 |
| 局部规则下沉 | 全局提示词里的领域规则 | 移到对应 Skill，保持全局整洁 |
| 结构重整 | 提示词与 Skill 的层次 | 同类内容集中，跨类不交叉 |
| 重新验证长期未用的工具 | 可能是环境已变，也可能是描述已过时 | 跑一次最小用例 |
| 删除被推翻的知识 | 有新证据直接否定 | 无争议的删除，有争议的标过期 |
| 从原始基座重新训练 | 多次微调后的遗忘 | 这是参数层的事，代价最高 |
第一条与第五条是减法，其它是重整。实践中减法最难推动，因为它需要有人对「这条不再适用」负责。可行的办法是给每条规则标注一次「最近被验证的时间」，超期自动进待裁决队列。
8.3 修剪的三种状态
与直觉管理里的「陈旧、退役、归档」对应，长期不用或被推翻的能力有三种处理方式。
标记过期：内容保留，检索时降权，适用于「可能是季节性不用」。 归档：移出检索范围，仍可查，适用于「场景已消失但可能回来」。 删除：不可恢复，适用于「被明确推翻」。
三者的选择标准是「恢复成本」，与重要程度无关。一条很少用但恢复成本极高的规则应当归档；一条常用但恢复成本极低的规则可以直接删除。
9. 四家的完整对照
| 环节 | Claude Code | Codex | OpenCode | DeepSeek Harness |
|---|---|---|---|---|
| 观察 | 五类事件加结果标记 | 轨迹加使用统计 | 无 | 无 |
| 提炼 | 直觉（七状态、七领域） | 三层（摘要/手册/技能） | 无 | 无 |
| 晋升 | 跨项目数 + 0.75 置信度 | 6 小时空闲 + 10 天窗口 + 256 条 | 构建期 | 装配期 |
| 审计 | 状态机（陈旧/退役/归档） | git 基线重置 | 版本控制 | 换配置 |
| 停止位置 | 四环齐全 | 缺审计的追溯 | 停在观察前 | 停在观察前 |
10. 三条判断
10.1 信号可得性决定上限
能观察到什么，决定了能学什么。四家的差异首先在这一层：前两家能学「模型做错了什么」，后两家只能学「人愿意写什么」。这个差别无法用算法弥补。
一个具体的推论：如果系统只记录对话文本，它能学到的上限是「表达的共性」；只有记录动作与结果，才能学到「行为的模式」。前者对改进帮助有限。
10.2 审批位置决定速度
审批放在哪一环，决定了进化的速度与风险。
| 位置 | 速度 | 风险 | 代表 |
|---|---|---|---|
| 生成即上线 | 最快 | 最高 | 无（只有实验环境会用） |
| 生成后人工审 | 慢一些 | 可控 | Claude Code 的冲突挂起、Codex 的差异审阅 |
| 只允许构建期改 | 最慢 | 完全可控 | OpenCode、DeepSeek Harness |
有一点容易忽略：审批位置与「谁能撤销」是两件事。一个审批宽松但可回滚的系统，可能比审批严格但不可回滚的系统更安全。
10.3 回滚能力决定敢不敢自动化
Codex 的 git 基线让它能自动整合（因为能回退）；OpenCode 的版本控制让它根本不需要运行时回滚（因为不自动改）。
反过来，一个没有回滚路径的系统，无论如何都应当把审批做严——因为错了没法改。
10.4 三者的组合决定形态
三条判断不是独立的。它们的组合落在几种稳定形态上。
| 信号 | 审批 | 回滚 | 可行形态 |
|---|---|---|---|
| 有 | 生成即上线 | 有 | 全自动，但要防自我强化 |
| 有 | 人工审 | 有 | 最常见的生产形态 |
| 有 | 人工审 | 无 | 审批必须极严，且要设人工复核 |
| 无 | 任何 | 任何 | 只能做构建期演化 |
第一行自动化程度最高，也最需要验证能力。它可行的前提是验证强到「生成即上线」不会引入退化，这个前提很少成立。
第四行是 OpenCode 与 DeepSeek Harness 的位置。它们不是缺能力，是选择了不需要信号的设计。
11. 两个完整案例
四家的机制之外，有两个公开实现的管线更完整，可以作为参照。
11.1 后台记忆进化的完整形态
一个更完整的后台案例把长期信息分成四层：有界的索引文件与用户画像文件、基于全文索引的历史会话检索、按需加载的 Skill、以及可选的外部记忆提供者。
三处设计值得单独看。
历史检索返回原始消息，不先由模型摘要。这一条避免了把检索与生成混成一个不可审计的步骤——如果返回的是摘要，事后无法判断「当时原文到底怎么说的」。
触发条件具体。 一次任务包含较多工具调用、从错误或死路中恢复、收到用户纠正、发现非显而易见的工作流，四种情况任一出现就触发后台复盘。四条都与「有值得学的东西」相关，与时间无关。
独立的整理角色。 它跟踪 Skill 的使用、陈旧与归档状态，在空闲期执行确定性修剪，可选地运行模型合并；变更前保存快照，错误整理可以回滚。
「确定性修剪」与「模型合并」分开这一点很关键：删除与归档这类操作用确定性规则做，可预测、可审计；合并与改写这类才用模型。把两者混在一起，意味着一个模型错误就能删掉不该删的东西。
11.2 事件触发与间隔触发的差别
四家里的 Codex 用固定间隔（6 小时空闲加 10 天窗口），上面这个案例用事件触发。差别不只是快慢。
固定间隔的好处是行为可预测：同一批轨迹在同一个窗口里被处理，结果稳定。坏处是对「刚发生的严重失败」响应慢，且窗口内的轨迹可能已经冷却——细节在后续会话里被覆盖。
事件触发的好处是证据新鲜：刚失败完就复盘，轨迹细节完整。坏处是可能频繁触发，且单次复盘样本太少，看不出共性。
一个可用的组合是「事件触发采集、间隔触发整合」：事件发生时把相关轨迹标记待整理，等积累到一定数量或到时间窗口再统一整理。这与第 7 节的五步周期对应——采集可以频繁，验证必须批量。
12. 五个外部参照接入管线
四家之外，几个公开做法可以对照。它们不改变上面的判断，但补上了四个环节里我们还没覆盖的机制。
Voyager 的三件套补「观察→提炼」。 自动课程（决定下一步学什么）、技能库（把成功程序保存为可组合代码）、迭代提示（把错误带回下一轮）。三件缺一不可：只有技能库而没有课程，不知道下一步学什么；只有反思而没有环境验证，技能库会积累错误；只有探索而没有持久化，每次任务都从头开始。
ACE 的条目化上下文补「提炼」。 不每轮重写整份上下文，改为维护带稳定标识符的条目集合，由生成、反思、整理三个模块提出增量更新，再用确定性逻辑合并与去重。这解决一个具体问题：反复重写会丢细节，而增量更新不会。
MCE 的内外双循环补「判断」。 内层在给定管理方法下优化当前任务的上下文产物，外层根据多轮结果修改搜索、选择、过滤、格式化这些操作本身。这个区分与五个搜索尺度对应。
AFlow 与 Meta-Harness 的代码搜索补「动作」。 把工作流表示为代码图，通过执行反馈搜索节点与控制流的组合；让 Coding Agent 读待验证版本的源码、分数与轨迹，搜索决定信息如何存储、检索和呈现的代码。
Dream-RSI 的发现树补「验证」。 把已完成的发现过程存成树，当作离线评估环境。在线与离线用同一套决策接口，离线只揭示已展开的子树。这让策略可以在不重跑底层 Agent 与评估器的前提下被比较。
五个做法有一个共同点：它们都把「评价」放进了循环，没有放在循环之后。这与第 10 节的第三条判断一致——回滚与评价能力，决定了自动化能推到哪一步。
13. 从四家之外看四家
把五个参照与四家放在一起，能看出四家各自的空缺。
Claude Code 有四环齐全的管线，缺的是「廉价验证」——它的晋升条件靠跨项目证据，这个证据的收集成本很高（要等），没有 Dream-RSI 那种「在历史树上快速比较」的能力。
Codex 有可回滚与两阶段管线，缺的是「判断理由留存」——它能回到上一版，但说不清当初为什么改。
OpenCode 与 DeepSeek Harness 停在观察之前，它们的位置不需要这些能力，但这也意味着任何积累都必须由人完成。
这个对照的实际用途：如果要在某一家的基础上补进化能力，先确定自己缺哪一环，再去找对应的参照机制，不必整套照搬。