Agent RSI 复盘

过去一年，把产品类项目的开发全流程交给 Agent 的范式已经跑通，AIMO 和 Moment 都是这个范式的产物（AIMO 的开发过程见 AIMO：用 Agent 开发跨平台闪念笔记）。我们给出整个产品的需求全景图之后，技术方案、开发计划、代码产出、功能测试和部署基本不需要人工参与。基本思路是规划和调度交给一个 SOTA 模型（如 Kimi-k3、Gpt-sol-MAX），实际执行由它调度更便宜的模型（GLM-5.3、Grok-4.6）完成，控制成本。

这个过程里 SOTA 模型会启动一个工作流，类似 Claude Code 下的 /workflow，但我们采用了自己实现的可编排架构：SOTA 模型对整体需求进行编排，生成 JS 编排脚本；脚本中先调度模型产出技术方案，换一个模型 Review，通过后出开发计划，再 Review，通过后调度新的模型进入开发，随后调度 CSI 和 RabJS 提供的能力自测。CSI（操作真实 Chrome）和 RabJS（可观察、可断言的应用状态）已经开源，编排框架 River 还在内部项目中使用。

过去两周，我开始尝试用 Agent 自迭代的方式完成两个新项目：一个是类似 Multica/Raft 的人-Agent 协作平台 Waka，另一个是 Vue 转 React 的产品 V2R-Agent。前者成功了，后者失败了。

什么是 RSI

RSI 指 AI 系统在不依赖人类持续手动干预、标注或调参的情况下，通过内部反馈闭环自主识别缺陷、优化架构/工具（Harness）或更新模型权重，从而让自身变得越来越强的系统级演进过程。

RSI（Recursive Self-Improvement，递归自我改进）常指更新模型权重的自我改进。本篇的两个项目不更新权重，改进对象是 harness 和知识库：编排脚本、工具、提示词、知识条目，可以称为 harness 级 RSI。这类系统的边界清楚：每一步改进都是文件级变更，可以 diff、回滚和审计；天花板也明确，迭代优化的是模型的使用方式，模型本身的能力不变。

为什么这两个系统是 RSI 的

1. Waka 的主要使用者就是 Agent，目标是让 Agent 之间可以更好、更方便地调度。最开始的设计由人提供产品原型，后续所有迭代都是 Agent 在实际使用中围绕这个目标进行的架构升级和功能迭代。
2. V2R-Agent 脱离了之前规则优先的方案，采用启发式架构。除基本工程规范外没有提供任何前置信息，由模型探索和总结，将经验逐步写入知识库；自主调试，通过创建工具、修改提示词提升数据的准确性和召回率；建立金标准作为反馈指标，用 CSI 验证。最终目标是将一个 Vue 项目转化为对等的 React 项目。

两者代表 harness 级 RSI 的两种形态。Waka 是使用驱动：系统被使用的过程就是反馈来源，迭代目标统一在让 Agent 交互更好。V2R-Agent 是自举：没有现成的使用过程，工具、提示词、知识库都要在执行中从零建立，反馈指标（金标准、覆盖率）也要自己构造。两种形态对反馈回路的依赖不同，是后文成败差异的来源之一。

为什么一个成功一个失败

Waka 的成功

Waka 大约花了 38 个小时，Agent 就完成了第一版可交付的产物，我试用了一下，功能基本正常。随后派发任务，Agent 就可以自己评测、自己调试和迭代。

后续使用中 RSI 开始自迭代。成功有两个因素：

1. 有可参考的先例。 正式开发前它调研了类似 Multica 的实现方案，对如何调度 Claude Code、Codex 等有清楚的认识，接口设计不需要从零发明。
2. 反馈快且闭环，标准清晰。 每个功能执行完成后，针对耗时过长、失败和花费较大的任务，有一个旁路的 SOTA 模型对当前任务做异步分析，针对不符合预期的结果进行修改和迭代。反馈的三个维度（耗时、失败、花费）都是机器可读的量化指标，不需要人参与判断。

V2R-Agent 的失败

这个项目一开始看起来会比 Waka 简单：V2R-Agent 的完成标准非常确定，迁移后的代码行覆盖率 100%。围绕这个目标，结合基本的工程规范，让 Agent 设计架构，我们把可能用到的资产都放到工程目录下。

实际结果和预期差异很大。Agent 自主运行 10 天后，我停止了这个项目。问题有三类：

1. 反馈回路失效。 一个页面维度的迁移涉及上千个文件，迁移按文件逐个进行；单个文件除了静态检查外没有其他方式确定功能是否正常，verify 环境的噪声盖过信号，反馈回路长到模型没办法对代码进行有效组织。
2. 知识沉淀没有统一接口。 我们自己的组件资产、库资产代码量都很大。原计划不冷启动知识库，让模型在过程中用到哪个学哪个；实际让模型按自己的方式总结代码，很难有统一的接口，过程中召回率也低。
3. repair 不消化错误反馈。 这一点单独展开在下一节。

repair：错误在局部，修复在全局

单个文件的迁移错误是具体的：类型不匹配、生命周期差异、props 映射错误。这类错误的修复应该落在文件或迁移规则这一层。系统的实际行为是：错误出现后，repair 环节优先重新审视整体架构是否合理。全局改动让已经验证过的部分回到未验证状态，错误既没有被修复，也没有被沉淀为规则，下轮还会重新出现。

Sota 模型对以上问题的组织方式是继续加码 spec 和评审，试图找到更好的方案。但验证过程太长，更多前置流程进一步延长了回路。这和人类团队在缺少可靠验证手段时的反应一致：增加评审、补充文档、推迟集成。

PI-Agent 与 Claude Code 的差距

同时还发现另一个问题。V2R-Agent 的整体架构基于 PI-Agent，当时的考虑是迭代过程中方便让 Agent 根据实际情况定制插件。具体执行下来，基于 PI-Agent 的最终效果并没有那么好，Claude Code 反而不错。

原因没有验证。猜测是模型后训练阶段针对 Claude Code 进行过训练，模型更擅长使用 Claude Code 的工具协议。这里有两种可能：如果差距来自训练分布，它是暂时的，会随模型泛化或自建 harness 的使用数据增多而缩小；如果官方 harness 与模型持续同步迭代形成耦合，自建框架就是在追赶一个移动目标，差距会长期存在。目前没有数据区分这两种情况。

实践上的取舍是：任务通用、验证手段现成时，优先用官方 CLI；自建 harness 的收益（可定制、可编排）要能覆盖这层差距再选自建。

Waka 与 V2R-Agent 的条件对照

逐行看，V2R-Agent 唯一占优的是完成标准的明确程度。但完成标准只定义终点，不提供每一步的反馈。两个项目在反馈周期、信号质量、先验、知识接口、修复层级上的差异，决定了迭代能否收敛。

把迭代交给 Agent 前的五个条件

从对照里提炼一份检查清单。派发自迭代任务前，五个条件逐项确认：

1. 反馈周期在小时级。 改动后的验证结果要能很快回来。周期以天计时，单轮迭代的因果链断裂，模型无法归因。
2. 失败信号能归因到具体改动。 需要从大量输出里筛信号时，噪声会主导迭代方向。
3. 存在可参考的先例。 Agent 需要一个接口层面的参照，避免从零发明。
4. 经验沉淀有统一 schema。 跨任务复用的经验按统一格式写入可检索的库；自由总结的笔记接口不统一，召回率低。
5. 修复层级匹配。 错误出现在哪一层，修复落在哪一层；文件级错误触发全局重构，等于重置已验证的部分。

V2R-Agent 五项全部违反。Waka 在反馈周期、信号质量和先例上满足，这与结果一致。

人的角色：启动条件与停止条件

停止 V2R-Agent 的依据：三类问题在 10 天内没有收敛迹象，Sota 模型的应对方式（加码 spec 和评审）在延长回路而不是缩短它。

我的判断是，这类系统里人的角色从写代码变成定义启动条件和停止条件。启动前写下：

• 预算上限：时间、token、费用；
• 收敛信号：核心指标在多少轮内应出现改善，没有出现就触发复盘；
• 回路方向检查：每次大改动是在缩短验证周期还是延长它。方向反了，继续投入只会放大偏差。

后续

V2R-Agent 的架构（确定性 DAG + 状态机 + 轨迹）这条路径，我判断仍然可收敛。可收敛的依据在回路结构：状态机约束每次状态转移，验证随转移逐步进行，反馈周期从天级回到小时级。V2R-Agent 的教训（知识 schema、修复层级、验证环境噪声）需要人工介入处理。

失败经验总结之后，我启动了 V2R-Studio，后续会针对这个项目单独复盘。

这个结果也回应了 Agent 系列收官时的预判：agentic RL 可能让环境和反馈设计更值得投入，任务定义、奖励信号、验证器和成本约束会直接影响优化结果（两年搭 Agent 的复盘）。Waka 验证了反馈设计到位时自迭代可以持续；V2R-Agent 给出了反面条件。harness 级 RSI 的工程问题归结起来还是：反馈从哪里来，多快回来，能不能定位到改动。