RSI 八步骨架：让 Coding Agent 自己改 Prompt / Skill / Harness 的循环

RSI（Recursive Self-Improvement）在 2026 年已经从概念变成可被 benchmark 的工程范式。它的真正难点不是「让 Agent 改 prompt 再跑一次」，而是搞清楚三件事：改哪个文件决定改哪一层、保留依据怎么不被单一加权分掩盖、什么时候算真的在改进 Agent。本专题先用一段 Coding Agent 主线把八步骨架固定下来，再把它原样迁到「文字/图片 → 可打印 3D 模型」，最后用 R_AI 形式化标尺区分递归放大与「这次恰好答对」。

一、起点：一个普通 Coding Agent 一周被改了几次

要谈「RSI 八步骨架」，先得把 任务仓库 和 Agent 仓库 分清楚，因为工程上最常见的误解就是把这两者揉在一起说「Agent 自己改自己」。贯穿主线的任务基线就是 SWE-bench：每个 instance 是一个四元组 issue 文本 + 仓库代码 + gold patch + hidden tests，评测时严格跑 7 步 codebase checkout → 应用 patch → 跑测试 → 对比 FAIL_TO_PASS / PASS_TO_PASS 的 execution-based validation 协议，参数说明在源里（v3 数字如 Claude 3 Opus 3.79% / Claude 2 1.97% 等）。这段协议不参与 RSI 的改进循环，它永远是 I/O，不是 L。SWE-bench

下面这张图把 SWE-bench 的执行基线画清楚：左侧是 codebase 加上 issue 文本，模型生成预测 patch，apply 后跑测试，所有 FAIL_TO_PASS 与 PASS_TO_PASS 都通过才拿到完成分。这是后续所有 RSI 论文的共同「输入/输出协议」。

图注：SWE-bench 单 instance 单轮评测流程。codebase + issue 文本 → 模型生成预测 patch → unix patch apply → 跑测试 → 与 ground-truth 测试结果对比 → 给出 task completion 判定。整张图描述的是单 instance 单轮 execution-based validation，不是 RSI 循环图。

在 RSI 视角下，Coding Agent 已经不再是「一个模型」。它被拆成 agent = model + harness，harness 里塞着 system prompt、工具、控制流、可选 memory 与 skills 等可加载文件。任务仓库 / Agent 仓库 / 改进者仓库 这三个目录必须显式分开：SWE-bench 实例归任务仓库，CLAUDE.md / SKILL.md / harness 源码 归 Agent 仓库，「改哪类产物」的决策与诊断落进改进者仓库（也叫 meta 仓库）。Self-Evolving Coding Agents 综述把这条共同框架画成一张总览图，三条并列 update 路径（assets / architecture / model）共用一个反馈环——这是后面所有方法学的「同框坐标系」。Self-Evolving

改哪个文件决定改哪一层 这条地基就立住了。RSI 的每个方法——DGM、Socratic-SWE、HarnessDev、OpenSCAD-MCP——都是在这三个仓库之间搬文件、改文件、回写文件。

二、一次完整改进轮：八步骨架的输入、执行者、产物、保留依据

把八步串成一条循环，最容易讲错的是把它简化成「改 prompt 再跑一次」。真正把循环做出来的代表是 Darwin Gödel Machine：左半是 self-improvement 相位，右半是 task evaluation 相位，两个相位交错运行，archive 居中保留所有可编译的子代 agent（DGM 把自身仓库的代码改写作为改造对象，FM 权重 frozen 不动）。

图注：Darwin Gödel Machine 的双相位循环。左侧 self-improvement：父代 agent 经 foundation model 把自身 codebase 改写为子代，节点进入 archive；右侧 task evaluation：archive 里的子代 agent 在下游任务上评估，得分回写 archive。archive 维护与 parent selection 都是 hard-coded 的，并非 agent 自我改造的产物。DGM

为了让八步每一步都落到具体文件上，我们用一个 bug 修复候选贯穿：

每一步的「执行者」和「修改产物」都被显式隔离。这意味着同一次失败可以归因到「改错文件」或「选错门槛」，两者都不必用单一加权分掩盖。

不是所有八步骨架都靠 archive 维持。Prompt 层自演化代表 GEPA 用 Pareto candidate sampling：候选池 P → SelectCandidate → 选 module → 跑 minibatch → feedback function μ_f 取 textual trace → LLM reflection → 生成新 prompt π' → minibatch 重测，若改进则入池并在 D_pareto 上 macro-eval。GEPA 重要的一点是只用 textual feedback（编译报错、rubric 命中、aggregate metric 拆解）做信用分配，而不是 sparse scalar reward。在 Qwen3 8B 上跨 6 个基准，IFBench 一项用 678 次 rollout 就追平 GRPO 24,000 次的 35.88%，把样本效率拉到 ~35×。它把 RSI 八步里「改 Prompt」这条产物路径做到了不需 archive 的另一种保留/回退机制。GEPA

这一章的留口：「权重不动，能力提高留下的是 prompt / skill / harness 等可加载产物」。下一章就来讲这五类文件在工程上各自长什么样。

三、五类可改产物的真实形态：改了之后，能力到底落在哪个文件里

把改进者 LLM 真的去改一份产品仓库时，它面前只有五类可写文件。这五类不是某一家论文的命名，而是 2026 年 8 月综述对齐过的共同命名层：Assets 下的 Memory / Skill / Tool / Context、Architecture 下的 Harness / Workflow / Multi-Agent、Model 权重一类。其中「改权重」一般与 harness 自演化不在同一个时间窗。

图注：自演化 Coding Agent 的三层 taxonomy。Assets（蓝）/ Architecture（橙）/ Model（紫）三层，三层对应越来越深的干预深度，但 depth 不保证 benefit。每个二级节点下挂叶节点论文，108 篇全部铺平。这是后面所有方法学对齐的命名坐标系。

落到真实工程文件上，这五类分别长这样：

• prompt.md / system prompt — 改的是 Prompt 层。GEPA 类的 Pareto reflection 改的就是这一层，rollout 数量少、可解释性高；它的改动对象是 compound AI system 的 prompt 集合 Π_Φ，控制流 C 本身不动。
• SKILL.md / MEMORY.md — 改的是 Skill 与 Memory 层。Socratic-SWE 提出的 Agent Skill Registry 用四字段结构化（name + description + applicability + ordered operations）从轨迹里蒸馏 skill。Refining harness 的实测是 11 个生产级 harness 里有 9 个（占 9/11）已经采用 SKILL.md，而 MCP 8/11 在 2026 Q3 已经被 Skills 反超。HarnessEng
• harness/*.py — 改的是 Harness 层。Refining 给出 11 家生产级 coding harness 的统一 anatomy：七个 subsystem（loop / LLM integration / tool / memory & context / safety / orchestration / extensibility）加 Interface 与 Orchestration 两个 cross-cutting surface。其中 Mini-SWE-Agent 给出 ~100 行 floor，所有 7 个 subsystem 都被收进这个体量。HarnessEng-anatomy

图注：Harness 的规范 anatomy。外层虚线框 Harness，内含 8 个独立模块：Interface Layer（蓝）、Orchestration（黄）、核心三件 LLM Integration / Agent Loop / Memory & Context（粉）、扩展三件 Safety / Tool / Extensibility（绿）。Agent Loop 居中。Interface Layer 与 Orchestration 是 cross-cutting surface，不算七子系统的两个。

• 编排脚本 / workflow / MCTS — 改的是 Workflow 层。AFlow 类把 workflow 写成代码做 MCTS 搜索；Workflow 层与 Prompt 层属于不同干预深度（前者动 C，后者只改 prompt 集合 Π_Φ）。
• model weights — 改 Model 用 SFT/DPO/GRPO 等把 coding 经验写进参数。这条路径不在 harness 自演化主线上，单列时本专题不展开。

Memory 这一类的形态选择可以单独画一张谱系图，说明同一份 memory file 在不同复杂度档下呈现的差异：

图注：Memory 管理按复杂度分四档，水平谱系。Linear（Mini-SWE-Agent，no pruning）→ Summarization（Aider / OpenClaw，递归减半）→ Condensation（OpenHands，10→3 condensers）→ Compaction（Claude Code / Codex / Gemini CLI / Mistral Vibe / Hermes / Pi / OpenCode 共 7 家，阈值触发 LLM compaction）。左 Simple 右 Sophisticated 的灰箭头标注「策略复杂度等级」而非「性能等级」。HarnessEng-memory

Skill 这一类的形态选择单独画：Socratic-SWE 的 trace→skill→task→solver 闭环把 Solver 自己的轨迹蒸馏成结构化 skill registry，再让 Generator 反过来用 skill 生成任务、Verifier Gate 四阶段过滤，最后让闭环有 self-evolving 能力。

图注：Socratic-SWE 闭环。中心两张 Solver / Generator 角色卡，箭头指向中间的 Agent Skill Registry 和 Verifier Gate。横向闭环：task pool → Solver → solving traces → Skill Registry → Generator → task pool。「traces post-hoc 只用一次拿 reward」的传统范式被换成「traces 是下一轮 skill + task 的种子」。Socratic-SWE

闭环带来一段对照：传统 open-loop 用静态规则合成固定任务 supply，轨迹只在末端被读走算 reward；Socratic-SWE 的 closed-loop 让 skill registry 与 trace 之间有双向反馈箭头。两者本质差异是 feedback 是否被当作下一轮的资源。

这一章的留口：「权重一般不动，能力提高留下的是这些可加载文件」——下一章要问的是：当 Agent 用这五类文件刷出漂亮分数时，我们怎么知道它真的在改进、而不是在过拟合反馈？

四、Evaluator 的双层、对照预算：单一分数够吗？

父语境提示用户对「设计 evaluator + 让 Agent 自迭代就够了」的简化叙述存疑，必须打掉这个简化误解。Evaluator 的可信度问题不在分数高低，而在结构上是否被 withheld from development。Refining 这件事最干净的实证来自 HarnessDev：它把 benchmark 的形式定义为 (L_C, D) → H（creator LLM 在开发环境 D 里造 harness），再 (H, L_E, x) → y → score（冻结的 H 配 executor 跑任务并评分）；Evolution 阶段 committed 之后，所有 official versions 都必须在 630-task SWE-Pro held-out split 上再跑一次，这部分分数永远不会返回给 creator，专门测过拟合。

图注：HarnessDev 的 Creation 与 Evolution 两阶段。左侧 Creation：weak seed + 1–3 dev cases + creator LLM → runnable harness。右侧 Evolution：creator's RQ1 harness + downstream execution feedback → frozen harness。两侧用同一评测单位 runnable infrastructure that persists across tasks，明确把评测单位从「task output」换成「可加载、可跨任务复用的 harness 代码」。HarnessDev

HarnessDev 给出了一组硬数字，把简化误解直接戳穿：

• 5 个 self-runtime lineage 在 held-out-630 上都比 H_0 有提升，区间 +1.43 ~ +4.44，平均 +3.11。
• 切到 fixed-Gemini executor：Opus 仍 +2.70，Qwen -1.11、DeepSeek -2.38、GPT-5.5 -10.32。creator 选的版本远不是 held-out 最优的（GPT-5.5 gap = 16.51）。
• 64 个 comparable switches 里只有 53.1%（34/64）在 feedback 和 held-out 上同向；剩下的 46.9%（30/64）方向相反——noisy feedback 与 held-out 真信号高度脱钩；creator 宣告的 9 个 final 版本里只有 2 个真正是 held-out 最优（2/9）。

含义很直接：用 noisy 反馈分数反复 optimize，会挑到那次运气好的，并把过拟合放大。这就是 对照预算 不只是一种工程师审美，而是 HarnessDev 在 2,207 个下游实例、6 个 creator LLM 上拆出来的结构性结论。

把对照预算形式化推到极致的是 Recursive Criticality of AI Self-Improvement。它定义一个无量纲数 R_AI = recursive-feedback strength / frontier-hardening rate，当 R_AI > 1 时进入 self-amplifying regime（扰动会在循环里被放大）；当 R_AI < 1 时扰动被阻尼。论文反复强调这个阈值与能力水平、与可见速度都解耦：

"A system can therefore enter a self-amplifying regime before acceleration becomes visible, while rapid progress can also occur without self-amplification."

R_AI 后面挂的四个可测属性是：feedback strength、propagation effectiveness (operational closure)、cycle duration (τ)、rising difficulty (frontier hardening σ)。这四件事是「改进改进者」这一层递进成立的前提。

图注：Recursive Criticality 给出的四种参考动力学 regime。Panel (a) 是四条 capability trajectories（a ∈ {0.5, 3, 6, 15}）和一条 no-RSI baseline，x_AGI = 0.50、x_ASI = 0.80 标在横线上。Panel (b) 是对应的 R_AI(t) 序列，虚线 R_AI = 1 是 self-amplifying regime 的临界线。smooth scaling（a = 0.5）整段 R_AI < 1，却仍早于 no-RSI baseline 到达 AGI。这意味着「跑得快」与「递归放大」是两件事。

这一章的留口：保留与回退必须用硬性门槛 + 多指标，加权总分会害死你，下一章展开。

五、保留与回退：硬门槛 + 多指标，为什么加权总分会害死你

上一章说反馈与 held-out 同向变化只占 53.1%，意思是「靠平均分上升」做保留会挑到那次幸运的并放大它。要换掉的，正是单一加权总分这种「软门」。把单一 pass/fail 留给 GRPO 这种 group-mean baseline 是合理的；把保留决策交给它就会让 partial repair 这种「修好一半」的状态被压平成 0/1。

工程上最好的替代品有两类。Verify-on-stop guard（在 Refining 的生产级 harness 里最直接的实现是 Hermes）：把反思检查搬到 stop condition 而不是 inner loop——「如果 turn 修改了代码文件但没产出新的验证证据，就把 text response 重写成 continuation」。它只用 outer guard 就实现了 reflection 的功能，cost 只有 inner-reflection 的一小部分。HarnessEng-on-stop

GDPO 三组件奖励对应另一面。Socratic-SWE 的 reward 形式是 r_S = λ₁ · [F✓=F ∧ P✓=P] + λ₂ · |F✓|/|F| + λ₃ · |P✓|/|P|：三项分别奖励 full-suite pass、partial repair rate、regression avoidance。三项量纲不同，但 group-mean 减会掩盖不同尺度。GDPO 处理方式是先对每个 component 在 group 内做 z-score 归一化，再 BatchNorm 求和，让 Solver 能区分「部分修好」与「完全修对」并产生 informative gradients。这一刀的代价是 ablation：把 Solver 改回 GRPO，Verified 从 50.40 降到 48.60（−1.80），这一版是可在工程上 mount 上的损失。Socratic-SWE-GDPO

open-loop 静态规则 vs closed-loop 自演化 skill registry 的对照图就是上面 Socratic-SWE 那张 pipeline 对照图——它把「为什么需要 skill 自演化而不是固定规则」这件事说得最直白：

(a) 传统：static rules → fixed task supply → agent，traces 仅在末端被读走算 reward； (b) Socratic-SWE：skill registry ↔ trace 双向箭头，tasks 动态更新。

这一章的留口：硬门槛在软件闭环里够用，但把同一套机制搬到「文字/图片 → 3D 模型」时，软件侧的 per-angle 置信度能否替代物理试打？下一章直接迁。

六、把八步骨架迁到 3D 打印：任务定义、evaluator、候选空间全部要换

Coding Agent 的八步骨架具有可迁移性——把「issue + codebase + 测试」这一组输入换成「功能 + 尺寸 + 材料 + 打印机」，整套循环就能原样跑在 文字/图片 → OpenSCAD code → STL 这条流水线上。最干净的工程实现入口是 OpenSCAD-MCP：它是一个 stdio 上的 MCP server，把 OpenSCAD 代码生成、STL 编译、PNG 渲染、视觉自评装进 8 个 MCP tool + 1 个 workflow prompt + 3 个 resource。下面这张图是它的 11 步 pipeline 总览，把八步骨架原样迁到一个没有 GitHub patch 副作用阈值的纯软件闭环里。

图注：OpenSCAD-MCP 的 11 步 workflow。init → 库 catalog → 库下载/读源 → 写 .scad → check-syntax → build-stl → measure-stl（is_manifold 闸）→ render-images 8 角 → per-angle 自检 + functional checklist → min 置信度 ≥ 0.8 finalize / < 0.8 迭代 → finalize 可选 submit-feedback。右侧虚框列出 3 个被动 resource（syntax / pitfalls / library-reference）。OpenSCAD-MCP

注意它在 Step 6b 加了一个硬门：is_manifold 不通过就 STOP。这刚好接住第 5 章硬门槛 + 多指标的精神——单个加权分会在 STL 几乎空心时被忽视，必须靠 manifold + per-angle confidence min + functional checklist 三件事一起判定。

迁到 3D 后，候选空间也变了：从前述章节的 prompt / memory / skill / harness / workflow 五类可改产物，扩成 建模策略 / 切片参数 / 支撑策略 三类。建模层推荐路是 BOSL2 / YAPP_Box 等经过审核的 library（OpenSCAD-MCP 直接给出 preferred-library 表，把猜禁行条款 prompt 注入）。切片和支撑层则由 FDM 物理规则划出 hard corridor：

Prusa Knowledge Base 给出的硬数字可以钉成几条必须物理试打的判据：层高 0.20 mm 对应推荐壁厚 0.86 mm（两个 perimeter × 0.45 mm extrusion width 减去 overlap 后的净宽）；overhang threshold 55°（来源是配图 caption 列出的 55/35/15 三个参考选项之一，正文未明写默认，实际默认以 PrusaSlicer Tooltip 为准）；top contact Z distance 推荐 50–75% layer height（即 0.20 mm 层高下 0.10–0.15 mm）；first layer 固定 0.20 mm（主层高若是 0.10 mm 也要保留 0.20 mm 的首层）。这些参数全部嵌进 OpenSCAD-MCP 的 workflow prompt 与 openscad://pitfalls resource，作为 LLM 生成代码时的硬约束清单。Prusa KB Prusa KB Support

这一章的留口：manifold 检查、library review、per-angle 置信度都是软件侧的硬门槛。但这些够吗？必须回到实体试打的步骤是哪几步？下一章给。

七、软件自动化与实体反馈的边界 + 三层递进的判断标尺

把八步骨架从 Coding Agent 迁到 3D 后，必须回答一组更具体的问题：「software loop 能不能 cover 实体试打？」答案分两组。一组属于「软件侧能闭环」的步骤：

• check-syntax 步骤做 OpenSCAD 解析级语法校验，不调 CGAL。
• measure-stl 给 bounding box / volume / surface area，加上 is_manifold 闸。
• 8 相机角渲染 + per-angle confidence min ≥ 0.8（OpenSCAD-MCP 的硬门槛）。
• functional validation checklist（cable 路径 / connector 朝向 / speaker acoustic chamber / grille 不被封死），这一类功能 checklist 都靠 OpenSCAD 是声明式 CSG 来做，所以可以纯软件闭环。

另一组是「必须回到物理试打」的步骤，这是软件 loop 怎么都够不到的地方：首层附着力、support 是否在打印中断裂、装配间隙实测、articulation 关节受力。要把这些纳入评估，要么走真实 FDM 试打（如 Prusa 实机的 0.20 mm 首层 + overhang 阈值），要么退一步走仿真 oracle。

Procedura 是这个退一步的学术对照：它在算法层把 A = (P, C) 表示为 named parts + typed mates，9 个 static + 3 个 kinematic mate，每 part 提交前必须通过 compile / mate / connectivity 三检——其中 connectivity gate 用 span-based floater 检测「明显 detached component 数」，这是软件闭环里能挂的最高门槛。

图注：Procedura 四阶段流水线。(a) Planning：把物体拆成 named parts 的 assembly graph，每个 part 之间由 typed mates 连接；(b) Procedural Modeling：mate-driven build，每次写一个 part，placement 由公式 T_j = F_i · Δ(φ) · F_j^(-1) 求解，verification stack（compile / mate / connectivity）守门；(c) Refine：decoupled vision critic 诊断，每 cycle 只允许一次 gated edit；(d) Materials + Articulation：per-part PBR + Isaac Sim 验证 OpenUSD + URDF 的动力学 battery。Refine 阶段引入 decoupled critic（独立于写作 LLM 之外）这一设计，正是因为 LLM 自纠已经被实证不可靠。Procedura

虽然 Procedura 用 Isaac Sim 做 articulation 验证——这是一台物理仿真 oracle、不是真实 FDM 打印机——但它已经比 OpenSCAD-MCP 在「不能用软件闭环覆盖的部分」上多走了一步。两者界限互补：

下面这张图把软件闭环边界画得更直观：

图注：OpenSCAD-MCP 的 MCP server 架构。左侧 LLM 客户端（含 CLAUDE.md memory 与用户 prompt）→ stdio MCP server（8 tools + 3 resources + 1 prompt + 4 services）→ 容器内 openscad/openscad 镜像 → workspace 四子目录（working / output / libraries / feedback）。init 返回的 persistence_content 用绿色虚箭头流向 memory。软件闭环边界画在容器内——出了容器就必须回到真实 FDM 试打。OpenSCAD-MCP-arch

三层递进的判断标尺

到这里，必须把「修好当前任务 / 改进 Agent / 改进改进者」三层分开看，否则任何一个 RSI 报告都会被「这次分数涨了」糊弄过去。

• 第一层是「任务层」：单条 SWE-bench instance 通过。这是 0/1 的判定，不是递归。
• 第二层是「Agent 层」：在 held-out 任务集上有提升。HarnessDev 的 +1.43 ~ +4.44 平均 +3.11 是这一层的代表数字。
• 第三层是「改进者层」：改进者本身是否变强。这要靠 R_AI 框架的四个可测属性（feedback strength / propagation / cycle duration / rising difficulty），不是任何一次 benchmark 跳跃能替代的。

DGM 的 archive 树给了一个跨论文的视觉证据：节点 0 是 base，节点 24 是关键创新节点，颜色由浅到深对应性能由低到高。许多路径穿越了低性能节点（stepping stones），关键创新（如节点 24）后又是一波新创新。这与 R_AI 多 actor 形式化呼应：单个 lineage 看似不连续，但 archive 把它们积累成 collective stepping stones。

图注：DGM archive 树。左侧：节点 0 是 base agent，节点编号沿 edge 推进，颜色由浅到深对应 SWE-bench 上任务通过率由低到高；许多创新路径穿过低性能节点（stepping stones），而像节点 24 这种关键创新节点之后会引爆后续创新。右侧是 progress plot：浅蓝线 = 全 archive 的平均分，蓝线 = 每轮最佳分，深蓝线 = 最优 agent 的 lineage（含两个下行段）。这张图同时是「open-ended 优于 greedy」与「低性能节点也能延续出关键创新」的视觉证据。DGM-archive

最后的判断问题

如果你下次看到某个 Agent 报告说「self-improved」，不要先看 benchmark 分数，先问三个问题：

1. 它的 evaluator 是不是结构上 withheld from development？ 是 prompt 提醒，还是 hard-coded 进 benchmark 协议（hidden tests / held-out split / 物理试打）？
2. 对照预算够不够？ local gain 与 held-out gain 的差异是多少？creator 宣告的最优版本与 held-out 上的最优版本的 gap 有多大？
3. 它的 R_AI 估计在不在 > 1 区间？ 这是「递归放大」还是「smooth scaling 只是跑得快」？

HarnessDev 实证 与 Recursive Criticality 形式化 把这两件事钉成了 RSI 世界的判据。

参考文献

1. SWE-bench: Can Language Models Resolve Real-World GitHub Issues? — arXiv:2310.06770
2. Darwin Gödel Machine: Open-Ended Evolution of Self-Improving Agents — arXiv:2505.22954
3. Automated Design of Agentic Systems (ADAS) / Meta Agent Search — arXiv:2408.08435
4. Self-Evolving Coding Agents (Survey) — arXiv:2608.03392
5. Harness Engineering: Anatomy, Architecture, and Evolution of Coding Agents — A Source-Code Study of Eleven Systems — arXiv:2609.00006
6. HarnessDev: Can LLMs Create and Evolve Their Own Agent Harness? — arXiv:2609.01437
7. Socratic-SWE: Self-Evolving Coding Agents via Trace-Derived Agent Skills — arXiv:2606.07412
8. GEPA: Reflective Prompt Evolution Can Outperform Reinforcement Learning — arXiv:2507.19457
9. Recursive Criticality of AI Self-Improvement — arXiv:2609.00137
10. OpenSCAD-MCP Server (text-to-3D-printable model agent) — github.com/alexlenk/openscad-mcp
11. Prusa Knowledge Base: Layers and perimeters — help.prusa3d.com
12. Prusa Knowledge Base: Support material — help.prusa3d.com
13. Procedura: Agentic 3D Modeling with Procedural Control — arXiv:2608.26238