Capability Persistence：Agentic Engineering 缺失的能力记忆层

导语：每次 AI Agent 写完代码、通过 Review、修完 bug——规则更新了，指令优化了。但"这次执行的 Agent 在这个任务类型上表现如何"——这个维度的信息，没有被记录。下一次同类任务，规则更完善了，但你对执行者的执行性信息一无所知。这不是某个工具的缺陷。这是 Orchestrator-Worker 协作模式内部一个尚未被识别的结构性缺口。本文从一个具体的 Review Finding 出发，逐步拆解出这个被系统性丢弃的信息维度，提炼为两条公理，推导出填补这一缺口的双闭环架构。

0. 规则在变好，但执行者始终是陌生人

先描述一个真实场景——只要你用过 AI 辅助编程，下面这个过程不会陌生。

你用 AI Agent 实现了一个功能模块。它读入了你的项目规范（可能是 .cursorrules、CLAUDE.md，或者一套配置好的 workflow skill），生成了代码。你让它自检，或者你手动 review——发现三个问题：密码错误时返回了过于详细的信息，有被枚举的风险；异常捕获范围过大，catch 了 Exception 而非具体异常；日志中缺少 trace_id，排查时不方便。

Agent 修正了这三处，你确认通过。任务完成。

接下来发生的事情，你大概从来没留意过。

如果你配置了"反思"类的自动化流程——比如一段 prompt instructing Agent 在任务结束后从 Review 中提取编码教训——那这三条教训会被提炼并写回你的规范文件。CLAUDE.md 里多了一条"密码错误不返回详情"，项目编码规范的 Skill 文件里加了"异常捕获应精确到具体类型"，可观测性检查清单里补了"关键日志必须包含 trace_id"。

下一次执行同类任务时，新 Agent 会读入更新的规范。这一次，它不会再犯同样的错误——因为规则变了。

这很好。没有问题。规则在变好。

但另一个维度的信息——同样是这次 Review 产生的——没有被任何东西消费。

我们重新读这三个发现：

• "密码错误时返回了详细错误信息" → 这在告诉你，不仅仅是"规则禁止这样做"，更是在告诉你：本次执行在处理安全敏感逻辑时，判断力出现了偏差。
• "catch 了 Exception 而非具体异常" → 不仅仅是"规范要求精确捕获"，还意味着：本次执行在遵循编码细节时，粒度偏粗。
• "日志中缺少 trace_id" → 不仅仅是"规范要求可观测性"，还暗示着：本次执行在运维友好性上，有提升空间。

同一个 Review 发现，同时说出了两类事：规范偏离了什么，以及这次执行在哪些维度上偏了、偏了多少。

前者被消费了。你更新了规范，下一次 Agent 会遵守。

后者没有被消费。没有任何机制把"这次执行在这些维度上的表现"记录下来、带向下一次。下一次你做同类任务时——规则更好了——但你关于"哪一种配置的 Agent 更适合这个任务类型"的认知，和第一次执行前一模一样：空白。

这就是本文要分析并修补的结构性缺口。

它不在任何工具或框架的文档里。它隐藏在 Orchestrator-Worker 协作模式的内部——一个 Agent 执行任务，Review 检查产出，规范被修正。这个模式是目前 AI 辅助编程实践中最大公约数的形式，无论你用的是哪个工具。而它内部，有一个维度的信息在每一次执行后都被静默地丢弃。

下一章，我们把这个信号彻底拆开。不是问"丢了什么"，而是问：一个 Review Finding 里面到底装着几种信息？它们的结构关系是什么？

1. 一个 Review Finding 里面到底有什么

回到第 0 章里的第一个发现：

P0：密码错误时返回了详细错误信息，存在用户枚举风险。

读这句话的时候，你的注意力大概落在后半句——"存在用户枚举风险"——这是规范告诉你的事：这样做不安全，标准禁止它。前半句"密码错误时返回了详细错误信息"只是在告诉你哪里触发了这条规范。

这是任何一个合格工程师的本能反应。你看到 Review Finding，脑子里自动在做一件事：把"哪里错了"映射成"规范说什么"。于是你修了代码，更新了规范，下次不会再犯。

这个本能反应没有错。但它让你只看到了 Finding 的一半。

1.1 输出物携带生产者的痕迹

我们换一个角度来理解这个 Finding。

假设你不是在 review 一段 AI 生成的代码，而是在质检车间检查一个零件。质检员告诉你："这个零件的轴承公差超标了 0.02 毫米。"

这句话说了两件事。第一，"公差超标 0.02 毫米"——这是关于零件的信息，告诉你它偏离了标准多少。第二，"这个零件"来自特定的生产线和机床——如果你连续三个零件都在轴承位上超标，你不会只修零件，你会去调 3 号机床。

质检信号从来不只关于产出物。它天然携带着关于生产者的信息——因为产出物经过了生产者才到达你的手上。产出物和生产者的关系不是哲学隐喻，是物理事实：信号的来源决定了信号的构成。

Code Review 同理。你 review 的代码，不是凭空出现的——它是一个特定的 Agent，在给定的配置下，针对当前任务类型，执行了一次生成。那份代码是这一次执行的产物。

这意味着什么？

1.2 同一个信号，两个信息维度

回到这个 Finding：

P0：密码错误时返回了详细错误信息，存在用户枚举风险。

它所说的"密码错误时返回了详细错误信息"，既是一个规范偏离描述，也是一个执行性信息描述。

从规范偏离的角度看，它告诉你：在"用户认证-错误处理"这个场景下，安全标准要求不返回详细错误信息，而当前的代码违反了它。这个维度的信息可以被映射为一条编码规则，写入规范文件，约束所有后续执行。它的消费路径很清楚：Finding → 规范更新 → 所有 Agent 受益。

从执行性信息的角度看，同一个描述告诉你的是一件完全不同的事：这一次执行，在处理安全敏感逻辑时，呈现出判断力不足的特征。 不是"规范禁止这样做"——规范一直就禁止——而是"这个 Agent，在这次执行中，没有自然地避开它"。它的关注点不在安全上，在别的地方。

这不是一条规则，这是一条关于执行者的信号。它的消费路径不应该是指向规范文件，而应该指向执行者本身的能力记录。

1.3 这个区分不是直觉，是结构

回过头看另外两个 Finding，同样的结构立刻浮现：

P1：异常捕获范围过大，catch 了 Exception 而非具体异常类型。

• 规范性维度：编码标准要求精确捕获具体异常。
• 执行性维度：这次执行在编码细节的粒度控制上偏粗放。

P2：日志中缺少 trace_id，排查时不方便定位。

• 规范性维度：可观测性标准要求关键日志包含 trace_id。
• 执行性维度：这次执行在运维友好性上存在盲区。

三个 Finding，同一个结构。每一个都在说两件事：标准是什么，以及这次执行离标准有多远、偏在哪个维度上。

2. 公理化

第 1 章在一个具体的 Review Finding 上拆出了两个信息维度。第 0 章展示了其中一个维度被系统性丢弃。现在的问题是：这些发现是只适用于我们分析的那个 Finding，还是有着更深层的必然性？

答案是后者。本章将这两个维度提炼为两条公理——不是因为它们在这一个例子里成立，而是因为它们扎根于比软件工程更底层的结构：任何有反馈的执行系统，都无法绕开这两个维度的约束。

2.1 两个不可约的维度

要理解两条公理从何而来，需要先理解它们所约束的领域。

诺伯特·维纳在 1948 年出版的《控制论》中提出了一个影响深远的结构分析：任何能够自我调节的系统，无论是一台恒温器、一个生物体、还是一个社会组织，都由两个不可约的要素构成——通信和控制[1]。

• 通信：系统如何获取关于自身状态和外部环境的信息。没有通信，系统就是盲的——它不知道自己做得好不好，不知道环境变了没有。
• 控制：系统如何基于信息调整自身的行为。没有控制，意义感知不会转化为行动——系统知道错了，但不会改。

这两个要素不是某个系统特有的设计细节，而是任何自适应系统成立的前提条件。你不能说我只要通信不要控制——那系统就是一台只记录不行动的仪表。你也不能说只要控制不要通信——那系统就是一头在黑暗中挥拳的猛兽。

现在，把控制论的镜头对准我们正在分析的对象——一个 AI Agent 驱动的代码生成系统。它也是一个自适应系统：它执行任务，接收反馈，调整行为。因此，通信和控制两个维度对它同样适用。本文要做的，就是追问这两个维度在当前实践中的具体状态：

• 信息维度：系统通过什么获取关于执行质量的信息？Review 信号。这个信号的结构是什么？——这是公理 1 的领域。
• 控制维度：系统获得反馈信号之后，能否利用它来实施调节？具体到本文：Review 信号中的执行性信息，是否具备被系统性利用的条件？——这是公理 2 的领域。

两条公理不是任选的——它们是两个基础维度各自要求被回答的那个问题。
本文提出的两条公理分别对应这两个维度：公理 1 断言通信维度中反馈信号的结构特征，公理 2 断言控制维度中反馈信号的可利用条件。两条公理合在一起，描述了任何一个自适应系统在利用反馈改进自身时必须面对的两个问题：信号里有什么（公理 1），以及信号能被用来调节吗（公理 2）。

2.2 公理 1：质量反馈的信息复合性

一次质量判定（Code Review、测试结果、验收结论）是一个复合信号。它至少同时编码两类逻辑独立的信息：

• 规范性信息：产出物离标准有多远，以及偏离的具体类型——即"规范应该是什么"。
• 执行性信息：产生该产出物的执行者，在此类任务上的执行性信息——即"这次执行偏离了多少"。

两类信息在信号中共存。消费一类不自动消费另一类。丢弃任何一类，该维度的信息即永久损失。需要强调的是，Capability Path 并不要求单次 Review 是执行者能力的无噪声测量——它只要求 Review 结论与真实能力之间存在统计相关性。单次观测含噪，多次观测的统计聚合会向真实能力收敛。这与监督学习中个体标注者不可靠但标注集的统计信号可靠，是同一类问题。

这条公理的根基已经在第 1 章完整建立了——"输出物携带生产者的痕迹"。因为输出物经过了生产者才到达质量判定环节，所以任何关于输出物的质量判定，都不可避免地同时携带关于生产者的信息。这不是一个需要实验验证的假设，而是一个关于信息传递的基本事实：信号的来源决定了信号的内容结构。你收到的不是一个"纯质量值"，而是一个"谁、在什么任务上、产出了什么、偏离规范多少"的复合体。

老师批改试卷时，既知道"第 3 题答案错了"（规范性），也知道"这个学生在立体几何上偏弱"（执行性）。工厂质检时，既知道"这个零件公差超标"（规范性），也知道"3 号机床最近输出偏了"（执行性）。Code Review 不是特例——它是这个普遍结构的一个实例。

2.3 公理 2：反馈信号的可利用条件

一个反馈信号要能够支撑系统行为的持续性改进，必须在其所描述的对象上表现出统计规律性。纯随机信号——每次观测值独立于前次、不收敛于任何稳定分布——无法为系统性调节提供信息基础。

这条公理描述的是控制维度的基本约束。它不是对现实世界的经验描述——它是控制论的逻辑必然：如果反馈信号是纯随机的，任何基于它的调节策略在期望上都不会优于随机选择。你今天根据这个信号调了参数，明天信号给你一个相反的值——调节没有方向，改进没有积累。

回到本文的具体语境。Review 信号中的执行性信息——"这个 Agent 在这次任务类型上的表现"——要能够被用于改进任务分配，必须假设它在同类任务上不是纯随机的。它不需要每次都一样——方差是允许的。但它需要有一个统计上可把握的规律性：多次同类任务的观测向某些稳定值收敛，同类 Agent 在同类任务上的表现分布可以被区分。

这里有一个重要的分界。 公理 2 本身不包含"Agent 在实践中确实表现出这种规律性"的断言——那是后续要用经验证据回答的问题（第 3.3 节和第 4.2 节）。公理 2 只断言：如果一个反馈信号连统计规律性都不具备，那它就无法被用于系统性改进。纯随机的信号，感知了也无法利用——这是控制论的事实，不是关于 Agent 的经验假设。

公理 2 不需要实验来"证明"——它是一个必要条件陈述。它需要验证的，是它的前提在实际场景中是否被满足——即 Agent 的执行反馈是否确实不是纯随机的。这个验证将在后续章节中通过集成学习的广泛实践和 Agent 领域的实验证据来完成。

2.4 公理的独立性与充分性

独立性：公理 1 约束通信维度（反馈信号的结构），公理 2 约束控制维度（反馈信号的可利用条件）。两者覆盖控制论的两个基本维度，不可互相推导。

• 即使反馈信号只含规范性信息（公理 1 不成立），反馈信号在它所描述的维度上仍然可能具备或不具备统计规律性（公理 2 仍可成立）——公理 2 不依赖信号的具体内容。
• 即使反馈信号在被度量的维度上表现完全随机、无法为调节提供信息基础（公理 2 的前提不成立），反馈信号的内容结构本身仍然可能同时携带两类信息（公理 1 仍可成立）——只是执行性信息没有可利用的统计规律，不值得被纳入控制回路。

两条公理各自独立。拒绝其中一条，另一条不受影响。

充分性：两条公理是否足以推导出双闭环架构？

• 公理 1 告诉我们：Review 信号有两类信息，执行性信息在信号中存在。
• 公理 2 告诉我们：执行性信息要能被利用，必须在同类任务上具备统计规律性——否则基于它的任何分配决策在期望上都不会优于随机选择。

这里有一个关键区分。 公理 2 确立了执行性信息被利用的"资格"——信号不是纯噪声，具有统计规律性。但公理 2 不回答"怎么用"：如果存在一个在所有任务类型上都最优的 Agent，利用执行性信息的最优策略是平凡的——永远选它，不需要路由。路由的必要性来自一个独立的经验命题：不存在全局最优 Agent，不同任务类型的最优 Agent 不同。这个命题的根基是 Wolpert & Macready (1997) 的 No Free Lunch 定理——在所有可能问题上，不存在一个算法严格优于另一个 [2]。虽然软件工程是问题的子集而非全集，但集成学习和 EOM 实验分别在 ML 和 Agent 领域提供了证据，表明在这个子集内，任务特异性差异确实存在且量级显著。第 3.3 节将完整展开这一论证。

两条公理合在一起揭示了一个结构性缺口：在当前的 Orchestrator-Worker 模式中，执行性信息既没有被消费（公理 1 揭示的信号维度浪费），也没有进入任何基于统计规律的系统性调节回路（公理 2 揭示的控制维度空白）。而补上这个回路需要一个路由器——这不是因为"路由"是个好想法，而是在任务特异性成立的前提下，路由是利用执行性信息的唯一非平凡策略。

3. 推导

在进入推导之前，简要重述两条公理：

公理 1（信息复合性）：一次质量判定同时编码规范性信息和执行性信息。两类信息在信号中共存，丢弃任何一类即永久损失。

公理 2（反馈信号的可利用条件）：反馈信号必须在其所描述的对象上表现出统计规律性，才能支撑系统行为的持续性改进。纯随机信号无法为系统性调节提供信息基础。

下面从两条公理出发，逐步推导当前 Orchestrator-Worker 模式中应该存在但缺失的结构。

3.1 当前状态：信息去哪了

我们先做一个事实陈述——不是批评，只是画出当前的信息流向。

在 Orchestrator-Worker 模式下，一次代码生成任务的信息流动是这样的：

任务 → Worker 执行 → 产出代码 → Review → Finding 报告
                                              │
                                              ▼
                                    规范提取（自反思路径）
                                              │
                                              ▼
                                    规范文件更新
                                    （CLAUDE.md / SKILL.md / .cursorrules）

Review Finding 进入了一条消费路径：从 Finding 中提取"哪里不符合规范"，转化为编码规则，写入规范文件。下一次执行时，新 Worker 读入更新后的规范，不再犯同类错误。

这没有问题。问题是这条路径之外，什么也没发生。

3.2 缺口：另一类信息去哪了

公理 1 断言：Review Finding 同时编码两类信息——规范性信息和执行性信息。

回到第 1 章拆解的 P0 Finding：

密码错误时返回了详细错误信息，存在用户枚举风险。

当前路径消费了它的规范性信息——"不返回详细错误信息"被提炼为一条安全编码规则。自上而下——所有后续 Worker 都会遵守。

但公理 1 说这个 Finding 还被执行性信息填充的——"这次执行在处理安全敏感逻辑时，判断力出现了偏差"。这个维度的信息没有进入任何消费路径。它既没有被提取，也没有被存储，更没有影响任何后续决策。

它不是丢失了——丢失意味着本应存在的东西遗失了。它是一开始就没有被识别为一类信息。当前模式不是"丢了执行性信息"，而是根本不知道有这个维度。因此也就没有为它建立消费通道。

这是公理 1 揭示的缺口：当前的信息消费覆盖了一个维度，遗漏了另一个。遗漏本身即损失——因为根据公理 1，丢弃任何一类信息，该维度的信息即永久损失。

3.3 价值：被遗漏的信息有决策价值吗

缺口只说明"有东西被漏掉了"。但如果被漏掉的东西没有实际用途，缺口就是无害的。因此需要追问：被遗漏的执行性信息，有决策价值吗？
这需要回答两个问题：信号能用吗？如果能用，怎么用？

公理 2 为这个需求提供了第一个前提——信号的可利用性：如果多次同域观测不向任何稳定水平收敛——纯随机——那么基于这些观测的任何决策都不会系统性优于随机选择。但可利用只意味着"信号不是噪声"——它不回答信号应该以什么形式被利用。单靠公理 2，你可以选择永远选同一个 Agent（如果那个 Agent 总是最好），也可以选择按任务类型路由（如果不同 Agent 在不同任务上各有所长）。公理 2 给了你利用信号的资格，但没给你利用信号的策略。

这就引入了第二个前提——任务特异性命题。如果存在全局最优 Agent，策略是平凡的：永远选它。路由的必要性来自一个独立的事实判断：不存在这样的全局最优者，不同任务类型的最优 Agent 不同。这个判断有三个层面的支持：(1) No Free Lunch 定理提供了数学否定——在所有可能问题上不存在一个算法严格优于另一个 [2]；(2) 集成学习三十年的持续成功提供了经验证据——不同模型在不同样本上犯错不同，如果所有模型表现一致，集成毫无意义 [5]；(3) EOM 论文的实验进一步在 Agent 群体中确认了这一现象——当 Agent 被持久化并参与基于能力的竞争时，专业化分工自然涌现 [3]。

因此，执行性信息要能支撑路由，需要两个前提同时成立：(a) 信号具有统计规律性，不是纯噪声（公理 2）；(b) 不存在全局最优 Agent，任务特异性差异确实存在且量级显著（经验命题）。公理 2 + 任务特异性命题 → 按任务类型路由是利用执行性信息的唯一非平凡策略。

被丢弃的执行性信息——"这次执行在安全维度上偏了多少"——恰好就是这种任务类型能力差异的原始观测形式。你不需要新建设一个测量体系来评估 Agent 能力；你只需要停止丢弃 Review Finding 中已经存在、但从未被系统化消费的那一维信息。

因此，执行性信息具有决策价值。消费它的成本——相较于新增模型训练、微调或构建复杂调度系统——极低。而它本来就是 Review 过程的免费副产品。

这是一个结构性缺口——结构性的意思是，它不是某个特定配置的疏忽，而是 Orchestrator-Worker 模式在"规范修正"这条唯一消费路径之下，天然缺少第二条路径。

这里有一个容易被忽视的成本事实：Capability Path 的建设成本极低。它不需要新的数据库、不需要新的协议、不需要新的平台——只需要一个 JSON 文件和两个 Markdown 参考文件，在现有的 SKILL.md 中添加两处逻辑分支。当相较于构建复杂调度基础设施，边际成本极低时，执行性信息即使只提供微弱的决策价值，收益也已经超过成本。填补这个缺口不是投资——是停止浪费。
因此，填补这个缺口的方案不是"加功能"——不是在做一件可有可无的优化。它是停止浪费已有信号。它的性质等价于：一台设备有两条数据线，但只接了一条——另一条的数据一直在传输，但没有接收端。接上第二条数据线不是升级，是补全。

3.4 必然性：第二条路径

这就是 Capability Path 的必然性：和已有的 Knowledge Path（规范修正路径）并列运行，各自消费公理 1 规定的一类信息。公理 2 进一步要求这个路径必须是一个闭合回路——执行性信息从感知（Review 信号）到行为（任务分配）之间不能断开。

Knowledge Path（已有）： 规范性信息 → 规范更新 → 所有执行者受益
Capability Path（必须）：执行性信息 → 能力记录 → 任务分配受益

两条路径互补而非替代。公理 1 说反馈信号是两个维度的复合体——两条路径各自消费一个维度。少一条，信号就不完整地被消费。两条都在，整个 Review 信号才被完整地转化为系统改进。

3.5 既然有缺陷，为什么不换一个模式

3.4 的结论可能会让读者产生一个自然的疑问：如果 Orchestrator-Worker 模式内部存在结构性的信息消费缺口，那为什么不直接换一个更优的协作模式——比如 EOM 论文提出的基于市场机制的 Agent 协作方案 [3]？

答案是约束空间不同。EOM 的设计前提是没有中央调度者——任务通过竞拍分配，Agent 在平等地位上自发组织协作。而软件工程存在可审计性、审批门禁、偏序依赖和项目所有权四个硬约束，这些约束天然需要一个中央调度者来强制执行。Orchestrator-Worker 模式是这四个约束下最自然的收敛结果。EOM 证明了能力差异能够驱动专业化——但它运行在去中心化的市场约束下。本文的路径则是在保留中央调度的前提下，补全能力记忆回路，而非替换整个协作模式。

因此，第 3.2 到 3.4 节揭示的缺口，不意味着"这个模式有缺陷，要换掉它"。它的正确解读是：Orchestrator-Worker 模式在软件工程的约束空间里是最优主干。但这个主干上有一个缺失的环节——它没有消费执行性信息。 我们要做的是补上这个环节，而不是切掉主干。

3.6 第二条路径的功能必要性

推导到这一步，结论是"必须有一个 Capability Path"。但 Capability Path 不是一个可以买到的成品——它是一组功能的集合。接下来的追问不能靠经验直觉（"信息链上缺什么就补什么"），因为那条链本身是我们画出来的。需要一个更底层的锚点：执行性信息的消费，本质上是一个从经验中学习的问题——从多次执行的 Review 反馈中，持续改进任务分配。那么，任何能够从经验中学习的系统，在结构上至少需要哪几个部件？

这个问题不需要我们从零回答。Richard Sutton 和 Andrew Barto 在《Reinforcement Learning: An Introduction》（1998 初版，2018 第二版）中建立了强化学习的标准理论框架 [4]。这个框架的核心是智能体-环境接口——定义了一个能从交互中学习的智能体必须具备的三个不可消去的要素：

价值函数（Value Function）。智能体必须维护关于"什么行为在什么状态下是好的"的累积知识。这通常以状态-动作对的期望回报形式存储。没有价值函数，过去的经验无法被记忆——智能体每次只能对当前刺激做出反应，无法从历史中提取模式。价值函数是记忆的结构性等价物。

策略改进（Policy Improvement）。智能体必须能够基于累积的价值知识，调整自己的行为——哪些行动应该更频繁地被选择，哪些应该被避免。没有策略改进，价值函数储存的知识永远不会影响决策——它只是一堆无人读取的数据。策略改进是决策的结构性等价物。

奖励信号（Reward Signal）。环境必须向智能体发送反馈——每次行动得到多少奖励或惩罚。这是智能体与外部世界之间唯一的信息接口。没有奖励信号，价值函数没有更新的数据来源——学习回路断开。奖励信号是反馈的结构性等价物。

这三个要素为分析任何经验学习系统提供了一个有启发性的结构框架——它与 Capability Path 的反馈—记忆—策略更新三元结构具有同构性。虽然 Capability Path 并非一个严格意义上的强化学习系统（它不涉及马尔可夫决策过程中的长期回报估计），但这个框架为识别 Capability Path 在结构上的最小必要组件提供了清晰的方向。

现在把这个框架映射到我们的问题。

这个框架为 Capability Path 的功能分解提供了一个有启发性的参照——一个从 Review 反馈中持续改进任务分配的系统，在结构上可以类比为一个学习回路：

价值函数 → 持久化存储。需要一个数据结构，记录每个 Agent 在每个任务类型上的累积表现——成功次数、失败次数、成功率随时间的变化。没有它，执行性信息无法跨越任务边界，前一次的经验对后一次毫无影响。

策略改进 → 能力路由。需要一个选择函数，在每次任务到来时，根据存储中的历史表现决定由哪个 Agent 执行。没有它，存储的数据只是档案，不会改变谁来执行、执行的质量如何。

奖励信号 → 反馈适配。需要一个转换函数，把一次 Review 的结论（PASS 或 NEEDS_CHANGES，以及 finding 的具体维度）映射为价值函数中的数值更新。没有它，环境反馈（Review 报告）无法进入学习回路，价值函数永远不会更新。

三个功能，缺一个，Capability Path 就不是一个学习系统。缺存储 → 没有记忆，经验无法累积。缺路由 → 没有决策，记忆不影响行为。缺适配 → 没有反馈接口，学习回路断开。

这三个功能的工程名称分别是持久化存储、能力路由、反馈适配。名称不重要——可以叫别的。重要的是这三个功能不是"我们想到了三个有用的模块"——它们是"从经验中学习"这个目标的定义性要求。任何试图填补 Capability Path 的方案，如果缺了其中任何一个，在结构上就不可能完成学习任务。

[第 3 章完。推导链收束：公理 1 + 公理 2 → 结构性缺口 → Capability Path 的必然性 → 三个功能。下一步：检验。]

4. 检验

在进入检验之前，简要说明本文方案在现有技术谱系中的位置。Agent 能力路由（Capability Routing）与多个已有研究方向存在关联——Mixture of Experts（MoE）按输入特征选择专家子网络 [6]，Algorithm Portfolio Selection 根据问题特征选择最优求解器，Meta-Learning 学习"如何学习"以快速适应新任务。这些方向的共同前提是"不同专家/算法/模型在不同输入上有不同表现"——与本文的任务特异性命题一致。本文的独特之处在于聚焦一个特定场景——软件工程中的 AI Agent 代码生成——并将能力信息的来源锚定在已有的 Review 反馈上，而非设计新的评估体系。
第 3 章从两条公理出发，推导出了两个结论：(1) Orchestrator-Worker 模式存在一个结构性缺口——Review 信号的执行性信息维度未被消费；(2) 填补这一缺口至少需要三个功能——存储、路由、适配。

推导的严谨性取决于公理的普适性和推理的正确性——第 2 章和第 3 章已经完成了这部分工作。本章的任务不同：将推导结论放回真实世界，检验它们是否与可观测的事实一致。如果推导预测的现象在现实中不存在，推导就是悬空的；如果存在，推导就获得了经验锚点。

4.1 结构性缺口的检验：主流配置体系中的缺口检验

第 3 章推导出的核心预测是：在当前主流的 AI 编程工具配置中，Review 完成后，规范性信息有一条清晰的消费路径，而执行性信息缺少同等级别的结构化消费机制。

本节检验的是这些工具的原生配置体系（CLAUDE.md、AGENTS.md、.cursorrules）是否提供了针对执行表现的结构化持久化机制，而非工具的全部功能。工具本身当然可以通过 Git 历史、会话记录、Memory 功能等方式保留信息——但这些机制不是为"跨会话的 Agent 能力统计"设计的，也不提供按任务类型分桶、可查询、可路由的结构化数据。检验的范围是配置体系，不是整个工具。
检验这个预测不能依靠抽象推理——必须落到具体的工具上，逐一分析它们的原生配置体系。本节选取三个当前使用最广泛的 AI 辅助编程工具——Claude Code、Codex CLI、Cursor——检查它们各自在规范性信息消费和执行性信息消费两个维度上的状态。

在进入具体分析之前，需要明确检验的范围。这三个工具都能读取诸如 Git 历史、PR 讨论、Issue 记录等项目文档——这些内容中隐式包含了过去的执行表现（哪个模块反复被修改、哪些评审意见频繁出现）。但这种"隐式包含"不能等同于"结构化消费"：Git 历史不是 Agent 的执行性信息，PR Review 不是按任务类型分桶的成功率统计。本节检验的是：工具的原生配置体系是否提供了针对执行表现的结构化、可累积、可查询的跨会话统计机制。如果答案是否定的，那么即使执行性信息碎片化地散落在项目文档中，它也没有被系统地消费。

Claude Code。其原生知识沉淀的核心载体是 CLAUDE.md——一个项目根目录下的 Markdown 文件，定义了编码规范、项目约定和技术约束。每次启动新会话时，Claude Code 读取 CLAUDE.md 作为系统指令的一部分。

在一次代码生成和 Review 完成后，Review 中发现的规则可以被工程师抽象为新的编码约束并写入 CLAUDE.md，从而在后续会话中持续生效。这构成了一条完整的规范性信息消费路径：

Review Finding → 规则提取 → CLAUDE.md 更新 → 后续会话生效

然而，CLAUDE.md 提供的是行为约束，而非执行性信息。它告诉 Agent"应该怎么做"，却不记录"过去做得如何"。Claude Code 的原生配置体系并未提供针对执行表现的结构化能力记忆——跨会话的任务表现、Review 通过率、常见失败模式，以及特定任务类型上的执行质量趋势，不会自动沉淀为可查询、可用于改进调度决策的统计资产。

Codex CLI。其原生配置机制通过 AGENTS.md 文件实现——将项目级的编码约定、架构约束、技术决策以结构化 Markdown 的形式持久化在项目目录中。每次启动会话时，Codex CLI 读取 AGENTS.md 树中所有适用的文件，注入上下文作为行为约束。

在一次代码生成和 Review 完成后，工程师可以将 Review 中暴露的规范问题更新到 AGENTS.md 中，形成规范性信息的完整消费路径：Review 发现 → 规则提取 → AGENTS.md 更新 → 后续会话生效。

但 AGENTS.md 与 CLAUDE.md 在本质上是同一类载体：它们都存储行为约束，而非执行性信息。Codex CLI 原生支持规范的持久化，却不原生支持执行执行性信息的持久化。会话结束后，执行过程中的能力信号——Review 通过率、修复轮次、特定任务类型上的失败模式分布——随会话的关闭而消失，不进入任何可被后续会话查询的数据结构。

Cursor。其 .cursorrules 文件承担了与 CLAUDE.md 和 AGENTS.md 同构的角色——将编码偏好和项目规范持久化为跨会话的行为约束。Review 完成后，工程师可以手动更新 .cursorrules 以反映新学到的规则。规范性信息消费路径存在。

但 .cursorrules 能够持续传递项目规范，并不构成执行能力记忆。它能够保存规则，却不能保存能力；能够保存约束，却不能保存表现。它不记录特定配置在特定任务类型上的执行质量趋势，不累积跨会话的 Review 统计，不提供基于历史表现的任务分配参考。

检验结论：

三个工具的检查结果高度一致。每一个都提供了规范性信息的消费路径——CLAUDE.md、AGENTS.md、.cursorrules 分别作为行为约束的持久化载体，确保 Review 中发现的规则能在后续会话中持续生效。但每一个都缺少执行性信息的对等消费机制——它们的原生配置体系提供了行为约束的持久化，未提供执行性信息的持久化。

换言之，当前主流工具的配置体系普遍解决了 Knowledge Persistence（知识持久化） 问题，却尚未系统解决 Capability Persistence（能力持久化） 问题。第 3 章的推导预测——Orchestrator-Worker 模式下执行性信息维度存在结构性消费缺口——在三个工具中无一例外地得到确认。这个缺口不是任何单一工具的疏忽，而是当前工具设计在信息维度上的共同盲区。

4.2 任务特异性的检验：从数学定理到 Agent 实验

第 3.3 节论证的任务特异性命题——不存在全局最优 Agent，不同任务类型的最优 Agent 不同——是路由机制的理论支柱。没有它，路由没有存在的理由；有了它，路由是利用执行性信息的唯一非平凡策略。

这个命题有两层支撑。第一层是数学的——No Free Lunch 定理证明在所有可能问题上不存在一个算法严格优于另一个 [2]。但 NFL 定理不保证差异的"量级"：差异可能存在，但小到工程上没有意义。因此需要第二层——经验验证：在 AI Agent 代码生成的具体语境中，这种任务特异性能否被观测到？它是否有足够大的量级来驱动有意义的任务分配改进？
这个问题的答案来自三个递进的层面。

第一层：机器学习的普遍经验。 集成学习方法——从 1990 年代的 Bagging 到如今主流的 Gradient Boosting 和 Stacking——成立的基本前提就是：不同模型在不同样本上犯错不同 [5]。如果所有模型的错误模式完全相同，集成毫无意义——投票不会比单模型更准确。集成学习在过去三十年中持续提升各类任务的性能，是"异质执行者表现差异"在机器学习领域最大规模、最直接的经验证据。这验证了差异不仅存在，而且有量级。

第二层：Agent 领域的直接证据。 EOM 论文的实验进一步将这一结论延伸到了 Agent 群体——当 Agent 被持久化并参与基于能力的竞争时，专业化分工自然涌现 [3]。差异不仅存在于传统 ML 模型的测试集上，也存在于 Agent 在真实任务上的执行中，且量级足以驱动专业化的自发形成。

第三层：实践直觉的验证。 不需要依赖论文——任何一个长期使用 AI Agent 的开发者的日常经验都在同时验证两个前提。同一个任务类型（比如"写 React 表单组件"），在不同的 system prompt 配置下，产出的质量和一致性问题有明显差别——某些配置更擅长类型安全，某些在 UI 细节上更贴合设计稿。如果你曾经在多次执行后形成过"这个配置更适合这类任务"的直觉，你已经在进行非正式的、人类记忆驱动的统计路由。而你的经验在告诉你两件事：不同配置在不同任务上各有所长（任务特异性成立），且这种差异并非纯随机噪声（公理 2 的前提在实践中成立）。

第四层：模拟量化。 以上三层建立了任务特异性的定性证据——差异存在，且量级足以被感知。但路由的工程可行性需要一个更精确的答案：在有限样本（10 次执行）内，按任务类型路由是否能在统计上优于随机分配？

为回答这个问题，我们构建了一个最小化模拟实验：

• 3 个 Agent 配置：Safe-Agent（安全优先，API 路由任务上真实通过率 94%，React 组件上仅 48%）、Perf-Agent（性能优先，React 上 91%，API 上 56%）、General-Agent（通用，各类型 70-74%）。差异幅度参考了集成学习中弱分类器的典型异质性区间。
• 3 个任务类型 × 10 次执行。路由策略使用 Thompson Sampling（Bayesian Bandit），每次基于历史观测的 Beta 后验分布采样选择 Agent，天然平衡探索与利用。
• 500 次独立模拟取平均，消除单次运行的随机波动。

结果如下：

任务类型	策略	10次通过率	后5次通过率	理论最优
React组件开发	随机分配	71%	71%	91%
React组件开发	能力路由	77% (+6%)	81%
API路由实现	随机分配	74%	74%	94%
API路由实现	能力路由	81% (+7%)	85%
数据库迁移	随机分配	73%	72%	93%
数据库迁移	能力路由	79% (+6%)	82%

三个任务类型上，能力路由的通过率均系统性优于随机分配（+6% 至 +7%），且后 5 次通过率（81%-85%）持续高于前 5 次（75%-78%），表明路由质量随观测积累而提升。与理论最优（91%-94%）之间仍有差距，这来自两个可预期的来源：10 次执行的有限样本，以及 Thompson Sampling 的结构性探索代价——路由必须偶尔测试非最优 Agent 来维持后验精度。但差距不等于失败：路由在 10 次内已将随机分配与理论最优之间的空白填补了约 35%。

核心结论：任务特异性不仅"存在"——它在有限样本内就可以被路由机制转化为可量化的通过率提升。概率不是空谈，6-7 个百分点在工程上是可以感知的。

四层检验的共同结论是：任务特异性命题不仅在数学上成立（NFL 定理），在机器学习领域的广泛实践中可观测（集成学习），在 Agent 领域的实验中已被验证（EOM），在日常实践中可被直觉感知。命题不悬空，路由有依据。

[第 4 章完。检验完成。下一步：第 5 章——落地设计。]

4.3 反例检验：如果只有一条路径

全文至此都是正向论证——从公理推到缺口，从缺口推到第二条路径。但一个更直观的检验方式是反向的：如果只保留 Knowledge Path，永远不加 Capability Path，会发生什么？

考虑一个简化的思想实验。一个团队使用 Orchestrator-Worker 模式，连续执行 100 个任务，分布在 React 组件、API 路由、数据库迁移、单元测试、代码重构五个类型上。有三个可选 Agent 配置——一个偏安全的、一个偏性能的、一个通用的。

场景 A：只有 Knowledge Path。 每次 Review 后，规范被更新，Skill 文件越来越完善。100 个任务后，规则质量已经很高——安全漏洞类的 Finding 几乎不再出现。但每次任务仍然随机选择一个 Agent。Agent 偏安全的做了很多 React 组件（不是它最擅长的），Agent 偏性能的做了很多安全敏感的路由（也不是它最擅长的）。规则是好的，但分配是盲的。Review 通过率受限于"最差的 Agent-任务匹配"，而非"规则是否完善"。

场景 B：Knowledge Path + Capability Path。 每次 Review 后，除了规范更新，Router 记住了"偏安全的 Agent 在安全敏感任务上 PASS 率最高""偏性能的 Agent 在数据库迁移上修复轮次最少"。随着执行次数增加，分配越来越向最优匹配收敛。100 个任务后，规则质量同样很高（Knowledge Path 仍然在运转），但分配不再是随机的——每个任务类型逐渐稳定地路由到历史表现最好的 Agent。

两种场景的差异不在第 1 个任务，也不在前 10 个——那段时间两个系统看起来差不多。差异出现在第 20 到 50 个任务之间：场景 A 的通过率不再上升，因为规则已经足够好，瓶颈转移到了"谁在执行"上；场景 B 的通过率仍在上升，因为它改进的恰好是场景 A 的瓶颈。

这就是 Capability Path 存在的根本原因：Knowledge Path 改进的是规则的上限——所有执行者能产出的最好结果。Capability Path 改进的是分配的效率——每次执行是否最接近这个上限。两者不是替代关系。规则再完善，分配给不合适的执行者，结果仍然低于可达到的水平。

4.4 理论映射

本文提出的双闭环架构并非凭空设计。下表展示 Capability Persistence 的各组件在多个已有理论框架中的对应概念——这不是为了声称"这些理论证明了本文的正确性"，而是为了说明本文的架构有稳定的理论基础，且读者可以从这些框架中获得进一步的理解路径。

领域	已有概念	Capability Persistence 对应
控制论（Wiener, 1948）	通信与控制二分	双闭环（Knowledge Path × Capability Path）
强化学习（Sutton & Barto, 2018）	价值函数 / 策略 / 奖励	Registry / Router / Adapter（同构映射）
混合专家模型 MoE（Jacobs et al., 1991）	专家路由	能力路由（Capability Routing）
动态能力理论（Teece et al., 1997）	能力积累	能力持久化（Capability Persistence）
组织学习（Argyris & Schön, 1978）	双环学习	双闭环（规范学习 × 能力学习）
集成学习（Breiman, 1996）	模型差异的统计利用	任务特异性的经验支撑

唯一的差异在于：本文的聚焦范围更窄——仅限于 AI Agent 代码生成场景中的能力记忆——并且将能力信息的来源明确锚定在已有的 Review 反馈上，而非设计独立的评估体系。

5. 落地设计

第 3 章的推导建立了三个功能必要性——存储、路由、适配。第 4 章的检验确认了结构性缺口在主流工具中普遍存在。本章将三个功能转化为具体的设计决策和集成方案。

为保持足够的具象性，本章参照 GitHub 上流行的 Workflow 类 Skill（如 Superpowers 及其衍生的 code-generation / code-review 组合）的通用模式——一个 Orchestrator 调度子 Skill，子 Skill 各自完成执行和审查——展示 Capability Path 的集成形态。读者可以将同样的结构映射到自己的 SKILL.md 配置中。

5.1 三个模块的形态与关系

三个功能各自需要一个具体的数据或逻辑载体。

持久化存储：Agent Registry。一个 JSON 文件，记录每个 Agent 配置在各任务类型上的累积执行表现。

{
   
  "_schema": "1.0",
  "agents": {
   
    "<agent-id>": {
   
      "system_prompt": "…",
      "stats": {
   
        "total_tasks": 47,
        "success_rate": 0.83,
        "avg_review_score": 0.89,
        "domains": {
   
          "react_component":    {
   "count": 32, "rate": 0.91},
          "api_route":          {
   "count": 10, "rate": 0.72},
          "db_migration":       {
   "count":  5, "rate": 0.64}
        }
      },
      "parent": "<parent-id>",
      "generation": 3
    }
  }
}

统计对象的定义。 一个容易被忽视但至关重要的问题：Registry 中每一行统计记录对应的是什么？如果直接把"Agent"当作统计对象——Claude Sonnet + Prompt A 和 Claude Sonnet + Prompt B 被记成同一个 Agent——那么 Prompt 的变化会污染能力统计。反过来，如果把 Prompt 差异也视为不同 Agent，则 Registry 中的记录条目可能过多，冷启动问题加剧。

本文的建议是：统计对象 = (Model, System Prompt, Toolchain) 的组合，称为一个 Capability Unit。任意一个维度变化，即为新的 Unit，从零开始统计。父 Unit（如 Prompt 修改前的版本）的历史统计可以通过 parent 和 generation 字段传递给子 Unit 作为先验——但权重要降低，因为能力已经不直接可比。
设计要点：

• domains 按任务类型分桶统计——直接支撑第 3.3 节论证的任务特异性路由。同一个 Agent 在 React 组件上成功率 0.91，在数据库迁移上可能只有 0.64。
• parent 和 generation 字段追踪 Agent 的演化谱系——一个高成功率 Agent 被克隆后的新实例，可以继承父级的 domain 经验起点。
• 所有统计完全自动更新。人类不需要手动填写任何数值。

能力路由：Capability Router。一个选择函数，在每次任务到来时，根据 Registry 中的历史统计决定由哪个 Agent 执行。

路由的核心逻辑：

• 提取当前任务的类型（从 task 描述和 spec 映射中推断）。
• 在 Registry 中查询各 Agent 在该任务类型上的历史表现。
• 按以下公式计算每个 Agent 的选择分数，取最高者：

router_score = domain_match × success_rate × recency_factor

• 首次运行或 Registry 为空 → 降级为默认 Worker。
• 所有 Agent score < 0.3 → 降级为默认 Worker，避免勉强选择一个已知低表现的 Agent。

反馈适配：Review Feedback Adapter。一个转换函数，在每次 Review 完成后，将 Review 结论映射为 Registry 中的统计更新。

核心映射规则：

Review 结论	操作
PASS	success_rate 上调，对应 domain 的 rate 和 count 更新
NEEDS_CHANGES	根据 finding 类型扣减对应维度的统计
PASS + 足够样本 + 高成功率	标记 clone_candidate（可作为演化的种子）
持续低成功率	标记 deprecated（不再路由到该 Agent）

三者的关系：Registry 是数据底座——它存储了执行性信息从每一次 Review 中提取的统计。Router 是决策引擎——它在每次任务到来时消费 Registry 的数据做出分配决策。Adapter 是数据入口——它在每次 Review 完成时将原始信号转化为 Registry 可消费的数值更新。三者构成一个完整的学习回路：

任务执行 → Review → Adapter 提取执行性信息 → Registry 更新统计
                                                    ↓
下一次任务 ← Router 选择 Agent ← Registry 查询历史 ←┘

这条回路独立于已有的 Knowledge Path（Review → 规则提取 → SKILL.md 更新 → 下次注入上下文），与它并列运行，各消费 Review 信号的一个信息维度。

5.2 路由公式的设计依据

router_score = domain_match × success_rate × recency_factor 这条公式不是随意选出来的——它的三个因子各自回应一个从推导中产生的具体需求。

domain_match：为什么需要按任务类型分桶。 第 3.3 节论证了执行能力在实践中表现出任务类型依赖性——同一个 Agent 在 React 组件和数据库迁移上的表现可以显著不同。如果一个 Agent 在所有任务类型上共享同一个评分，任务特异性的信息就丢失了。domain_match 通过查询该 Agent 在当前任务类型上的历史匹配度，保证了路由是在同一个任务类型的上下文中做比较——React 组件任务只和 React 组件任务的历史比较，不和数据库迁移混淆。

success_rate：为什么用成功率。 这个因子是对一个最直接问题的回答：在这个任务类型上，这个 Agent 历史上有多少次被 Review 判定为 PASS？EOM 论文使用财富（Wealth）作为 Agent 能力的代理——财富是多次成功竞拍的累积。但在中央调度场景下，成功率是更直、无中介的指标。不需要价格信号来间接模拟能力——因为 Reviewer 的 PASS / NEEDS_CHANGES 判定就是对能力的直接观测。用成功率替代财富，不是对 EOM 的否定，而是中间少了"市场"这一层抽象——你有直接的质量评分，为什么还要用价格来代理它？

recency_factor：为什么需要时间衰减。 一个纯粹基于历史累计成功率的评分有一个风险：一旦 Agent 积累了足够多的 PASS，后续的失败很难影响它的 rank。如果 Agent 的配置、模型版本、或任务环境发生了变化，代理一个僵化的历史记录会导致持续选择实际上已经不再最优的 Agent。时间衰减保证了近期表现权重更高——连续失败会导致分数快速下滑，阈值以下的 Agent 不再被选中。这是在"利用历史经验"和"对环境变化保持敏感度"之间的平衡——被验证了几十年的强化学习方法（ε-greedy 的衰减、learning rate 的 schedule）都使用了类似机制 [4]。

exploration_factor：为什么需要探索。 纯粹基于历史成功率的贪心路由有一个风险——成功的 Agent 越来越成功，新的 Agent 永远没有机会。如果 Capability Unit A 在前 10 次 React 任务中表现好，Router 会一直选它；Capability Unit B 虽然可能更好，但因为没有历史数据，永远不会被选中。

借鉴强化学习中的 ε-greedy 策略：在大部分时间（如 90%）选择历史评分最高的 Agent，保留一小部分时间（10%）随机探索未充分测试的 Agent。被探索的 Agent 一旦获得新的执行数据，它的评分就可能上升——从而可能在未来取代当前的最高评分者。这个因子不是路由公式的组成部分，而是对公式的一个外层包装——它解决了"最优者永远是老的"这一锁定问题。

5.3 工程属性

这三个模块和一条公式，作为一个整体，引入了三个在推导过程中反复触及的工程属性。

可审计。路由决策完全透明。团队任何成员拿到一次分配结果——"为什么这次 React 组件任务选择了 Agent A？"——都可以通过回溯公式的三个因子得到答案：Agent A 在 React 组件上的 domain_match 为多少，success_rate 为多少，recency_factor 是否因为近期表现进行了调整。没有任何隐变量，没有任何不可解释的模型。这保证了第 3.5 节确立的"可复现性"约束在 Agent 分配层面同样成立——不仅是代码可复现，Agent 分配逻辑也可复现。

有记忆但不僵化。success_rate 的累积性和 recency_factor 的衰减性共同保证了这一点。历史成功不会被遗忘——一个 Agent 在 30 次任务中积累的 0.90 成功率是真实的信号，不会因为一次失败被颠覆。但持续失败不会被忽视——recency_factor 确保连续的负面信号能够逐步降低评分，直到该 Agent 被排除出路由池。这是一个在"利用已知好的 Agent"和"对劣化保持警惕"之间的平衡。

降级安全。系统在任何情况下都可以安全回退。Registry 为空（冷启动）→ Router 降级为默认 Worker，与当前工具的原生行为完全一致。所有 Agent 评分低于阈值 → 降级为默认 Worker，不冒险选择一个已知低表现的 Agent。Registry 文件损坏或缺失 → Router 检测到异常直接降级。新增模块是系统中的一个可开关的优化层，不影响核心 Workflow 的正常运转。演化是渐进的：

阶段	条件	行为
即时	Registry 为空	降级为默认 Worker，等同于当前原生行为
短期	3-5 次运行后	成功 Agent 入库，Router 开始匹配，分配开始偏离默认
中期	20+ 次运行后	专业化自然涌现——同一任务类型的不同 Agent 成功率出现分化
长期	跨项目积累	Registry 成为可迁移的复合资产，新项目冷启动时直接匹配已有 Specialist

5.4 已知局限与失效边界

没有任何架构在所有场景下都有效。以下是 Capability Path 已知的失效条件——明确这些边界不是为了削弱论证，而是为了让读者知道什么时候不该依赖它。

环境突变。 当底层模型升级（如 GPT-4 → GPT-5）或 Prompt 体系发生重大变更时，Capability Unit 的历史统计不再能预测新环境下的表现。此时 Registry 中该 Unit 的历史数据需要被标记为"过期"，或以远高于正常的衰减因子加速淘汰。这不是架构失效——这是统计学习的固有约束：训练分布和测试分布不同时，预测失效。

任务类型定义的粒度错误。 Router 依赖任务类型的正确分类。如果"React 组件"这个分类实际上包含了 UI 实现、TypeScript 类型定义、单元测试三个差异很大的子任务，那么 Agent 在这三个子任务上的真实能力差异会被"React 组件"这个过粗的分类掩盖。Router 在这个粒度上无法做出有意义的区分。分类的粒度决定了路由的信息上限——这需要工程实践中的持续调优。

古德哈特定律（Goodhart's Law）。 当一个度量成为目标时，它就不再是好的度量。如果 Router 只优化 PASS 率，Agent 可能会学会生成"更容易通过 Review"的代码——更保守、更简短、更符合规范但未必更好地解决问题。Registry 中的统计不是能力的纯净测量——它是有偏的代理。减少偏差的方向包括：对 PASS 加权重（一次 PASS vs 多次 NEEDS_CHANGES 后 PASS 不等于同等的"能力"）、记录 Review 修复轮次而非仅 PASS/FAIL 二值、以及最重要的——不让人从路由决策回路中退出。工程师应始终保留手动覆盖 Router 选择的能力。

5.5 集成方案

以 Codex CLI 中一个典型的 code-generation Workflow Skill 为例，集成方案仅涉及 1 个文件的修改和 3 个文件的创建：

skills/code-generation/
├── SKILL.md                              ← [修改] 两处插入
├── agent-registry/
│   └── agent-registry.json               ← [新增] Agent 持久化存储
└── reference/
    ├── capability-router.md              ← [新增] 路由逻辑参考
    └── review-feedback-adapter.md        ← [新增] Review→Stats 转换规则

SKILL.md 的修改：两处插入，不改变现有流程结构。

第一处插入点在任务执行阶段之前。在执行 Worker 的步骤之前，增加一个路由查询步骤：读取 Registry，计算 router_score，选择最优 Agent 或降级为默认 Worker。如果 Registry 为空，这一步静默跳过——对现有行为零影响。

第二处插入点在 Review 阶段结束时。在 Review 报告生成之后，增加一个静默执行的反馈适配步骤：提取 Review 结论和 finding 类型，计算 stats 更新，写入 Registry。这一步不影响 Review 本身的结论——无论 Registry 更新成功或失败，Review 的判定不变，代码修复流程不变。

两个新增参考文件：capability-router.md 定义路由算法和降级策略的完整说明，供 Agent 在执行路由步骤时引用。review-feedback-adapter.md 定义 Review 结论到 stats 更新的映射规则，供 Agent 在执行适配步骤时引用。两者都是 Markdown 格式的参考文件——与 SKILL.md 采用相同的载体，零额外依赖。

一个新增数据文件：agent-registry.json 初始化为空 Registry——{"_schema": "1.0", "agents": {}}。首次运行时 Router 检测到 Registry 为空，自动降级。

这个集成方案的核心主张是：填补 Capability Persistence 缺口，不需要新的平台、不需要新的协议、不需要新的数据库。三个 Markdown 参考文件 + 一个 JSON 数据文件 + 一个 SKILL.md 的两处小修改。它可以在任何基于 SKILL.md 的 Workflow 配置中复刻——无论底层使用的是 Codex CLI 还是其他支持 Markdown 指令集的 Agent 平台。

[第 5 章完。全文结束。]

参考文献

1. Norbert Wiener: Cybernetics: Or Control and Communication in the Animal and the Machine. MIT Press, 1948.
2. David H. Wolpert & William G. Macready: "No Free Lunch Theorems for Optimization." IEEE Transactions on Evolutionary Computation, Vol. 1, No. 1, 1997.
3. Qi, Chen, et al.: "Economy of Minds: A Market-Based Framework for Multi-Agent Collaboration." Harvard & MIT, 2026.
4. Richard S. Sutton & Andrew G. Barto: Reinforcement Learning: An Introduction. 2nd Edition, MIT Press, 2018.
5. Leo Breiman: "Bagging Predictors." Machine Learning, Vol. 24, No. 2, 1996.
6. Robert A. Jacobs, Michael I. Jordan, et al.: "Adaptive Mixtures of Local Experts." Neural Computation, Vol. 3, No. 1, 1991.
7. David J. Teece, Gary Pisano & Amy Shuen: "Dynamic Capabilities and Strategic Management." Strategic Management Journal, Vol. 18, No. 7, 1997.
8. Chris Argyris & Donald A. Schön: Organizational Learning: A Theory of Action Perspective. Addison-Wesley, 1978.

本文的核心论证从一次具体的 Review Finding 出发，拆解出质量反馈信号的信息复合性（公理 1）和反馈信号的可利用条件（公理 2），从两条公理推导出 Orchestrator-Worker 模式下执行性信息的控制回路断裂，在三个主流工具的配置体系中得到检验确认，最终落地为三个模块、一条公式、一个安全降级的集成方案。双闭环架构的本质不是给现有的 Agent 工具"加功能"——它是闭合一条断开的控制回路。