AI4AI Survey 精读：单点都强，端到端却崩——五维坐标定位你的修复点

你大概有过这样的体验：把 prompt、tool、memory 拼成一个 agent，单步测都挺准，跑通一个 30 步的任务却总在某处崩掉；重跑一次，崩的位置还不一样。于是你去调 prompt、换更强的模型、加一层 reflection，分数偶尔上去一点，但"这东西什么时候能信"这个问题始终没有答案。

2026 年 8 月的一篇 survey 正好把这件事当作中心议题。它叫 AI4AI Survey: From Long-Horizon Agents to Recursive Self-Improvement，来自 23 位作者、7 个机构的联合工作，系统检索冻结在 2026-08-04，收录 223 篇论文、111 个 benchmark。它给出的核心诊断只有一句话：单点能力的分数很少能翻译成端到端可靠的 AI 改进，capability 和 composition 之间的落差才是当前真正的开放问题。注意它是 preprints.org 上的预印本，尚未同行评审，Table / Figure 编号在未来版本可能变动。 KernelEvolve AI4AI

这篇专题不打算复述那 223 篇文献。它要做的是把这个 survey 当成一套坐标系：先用它的五个维度把你手上那个 agent 拆开、标出"谁在控制哪一步"，再沿着几条具体的失败路径找到该加验证、该加 grounding 的位置，最后给你三个下周就能跑的最小实验。

一、为什么「单点都强、端到端崩」会反复出现：D1–D5 给出坐标系

在拆机制之前，先把术语钉住，否则后面所有讨论都会在语义上打滑。

AI4AI 不是按「自主程度」定义的

这个 survey 把 AI4AI 定义为"任何用 AI 驱动的、改进某个 AI 产物或改进制造该产物的过程的过程"。注意这个定义里没有"自主"二字——它是按「被改的是什么」来定义的，不是按「AI 有多自由」。被改的对象可以是数据、任务、模型权重、计算平台、harness、evaluator、可执行系统，也可以是整条 AI 研究工作流。

在这之上才是一道阶梯：self-improvement 额外要求系统改的是自己；recursive self-improvement（RSI） 再额外允许系统去改"生产下一个版本的那个过程"；open-ended RSI 甚至允许它改"什么算成功"这条判据本身。 RSI

你已经在用 agent 框架，所以这里可以用你熟的东西搭一次桥：你平时让 agent 写任务的答案，被改的对象是"答案"；AI4AI 只是把被改的对象换了一层，变成"写答案的那个 agent"。结构上完全对得上——同一个循环（提出改动、执行、拿反馈、修），只是操作对象从 artifact 换成了 producer。而当"提出改动的那个循环本身"也进入被改范围，才叫 recursive。这层区分很实用：你项目里绝大多数"自我改进"其实停在第一格，把它叫 RSI 会让你对风险和收益的判断整体偏移。AI4AI Survey

这篇 survey 的问题边界，它自己用一张三栏图交代得很清楚：

图注：左栏 BENCHMARKS & ENVIRONMENTS 列出六类组件级 benchmark（Web 与浏览、计算机/移动/具身、软件与终端、工具与工作区、规划与科学、鲁棒性与评估）；中栏是这篇 survey 覆盖的 AI4AI 版图，一个 Long Horizon Agent 盒子标注为 Model × Harness × Environment × Evaluation，上方环绕六个节点（Interaction、Time、Context、Grounding、Observability、Dependency）；右栏 MODELS & HARNESS 列出推理与规划、工具使用、agentic RL、记忆与上下文、验证与恢复、监督与自主六类。中间那行标注提醒读者：可靠性属于「模型 × harness × 环境 × 评估」这整个系统，在一个声明过的协议之下，而不属于模型单独一项。AI4AI Survey

这里最容易被忽略的是中间那行小字。它把"可靠性"从模型身上拿走了：你测到的可靠性永远是模型、harness、环境、评估协议这四者的联合属性。换模型不动 harness、换 harness 不动协议，得到的数字互相之间不可比。这也解释了为什么行业里"某模型 agentic 能力更强"这类说法经常互相矛盾。

五个维度，正交，不是等级

survey 的骨架是 D1–D5 五个维度：

论文反复强调一件事：这五维是正交的，不要压成一个"自主等级"分数。一个系统可以在 D3 上大面积 sys（执行和修复全自动），同时在 D4 上极弱（反馈只有模型自评）。压成一个数就把这种关键组合抹平了。

图注：中央是 PLAN → EXECUTE → FEEDBACK → REPAIR 的循环，标注为「AI4AI = 一个指向 AI 系统的长程改进循环」。四个角上的模块分别回答：改什么（数据与任务 / 权重 θ / harness G / evaluator / 研究流程）、为什么是长程的（重复轮次、持久状态、延迟效应、耦合决策）、怎么测（任务压力六轴、closure signature、证据：可验证增益、retention、人类对比、transfer）、什么时候构成递归（AI4AI → self-improvement → recursive → open-ended 四级）。底部条带列出 D1 至 D5。注意 D5 是整个 improvement-evidence profile，G/R/H/T 是它内部的四格，两者不是同一层。AI4AI Survey

同年 7 月还有一篇 sister survey，Self-Improvements in Modern Agentic Systems，切法完全不同：它把 agent 写成 $\mathcal{A}_t = (\theta_t, \Sigma_t)$，θ 是模型参数（慢环），Σ 是操作脚手架（快环，含 prompt、memory、工具集、控制逻辑）。它有一句话对读文献特别有用：它明确承认自己说的 scaffold 就是学界近来常说的 harness，两个词指同一个对象。它还给了一条硬判据：只往对话历史里堆 context 不算 self-improvement，因为 KV cache 和中间计划这类 execution state 在任务边界处就被丢掉了，self-improvement 要求提交的是 durable 的改动。它的文献覆盖只到 2026-06，比 anchor 早一个月，所以只当第二坐标看。SI-Survey

到这里你手上有了坐标纸。下一个问题是：为什么在这张纸上，长程任务的失败位置总是集中在同一片区域？

二、长程为什么坏：cascade 是结构性问题，不是再多训一点能解决的

「长程」的判据不是步数，是功能耦合

survey 给的定义是：一次 pass 包含多轮，而后面的轮次继承前面轮次的代码、数据、观察、决策和约束。它同时给了一个很实用的判别法：问自己，每个动作能不能在保持最终成功条件的前提下被单独判定？如果能，这条轨迹可能步数很长但只是弱长程；如果去掉顺序、共享状态或跨步关系就会丢失后续决策或最终验证所需的信息，那这一 pass 就必须在轨迹层面评估，逐步打分是没有意义的。

这个判据值得你现在就对着自己的项目跑一遍。很多被叫做"长程"的 pipeline 其实是弱长程——它只是步数多，每步都能独立判对错，那就该逐步测、逐步修；而真正强耦合的那些，逐步准确率再高也说明不了端到端。

survey 用一个示意计算说明后者的严重性：如果每个动作独立地以 0.95 概率成功，100 步任务的成功率约 0.0059。它紧接着自己声明这只是示意：真实 agent 的错误并不独立，早期的错会改变后续状态，而反馈既可能抓住这个错，也可能把它扩散出去。

一个能逐 bit 对账的干净实证

抽象说到这里就该上实证了。有一篇 2026 年的论文做了一个非常干脆的设计：让 LLM 用工具调用手算 MD5。harness 只暴露七个原语（准备消息、初始状态、取轮常量、算 f 和 g、mix、加状态、转十六进制），driver 模型必须自己按顺序调用它们，并且在调用之间自己携带 (a,b,c,d) 四个 32-bit 状态、自己施加状态更新的循环移位。算完一个哈希是标准的 196 次工具调用（2 次准备 + 64 轮 × 3 + 2 次收尾），最后输出的 32 位十六进制摘要跟从 RFC 1321 从零实现的参考实现逐字符比对。输入用的是不超过 55 字节的非记忆化字符串，绝不用 "abc" 这类著名测试向量，所以答案不可能是背出来的，只能是算出来的。

图注：单 agent 运行的结构。driver 拿到输入和七个原语工具，自己发出调用：prepare_message → initial_state，然后对 i=0…63 每轮重复 get_step_constants / compute_f_and_g / mix_step，并在调用之间携带 (a,b,c,d)。一个哈希是 190 多次工具调用（偶有无害的重复查询），最终摘要与从零实现的 MD5 参考值比对。这张图是架构示意，读不出任何成功率。MD5-LongHorizon

这个设计的价值在于每一个失败都是纯粹的记账错误，没有"指令理解偏差"这个混淆变量。于是作者能做一件平时做不到的事：对任意输入构造出 ground-truth 的调用序列，逐调用对齐 agent 实际做了什么，渲染成绿/红轨迹，把第一次分歧精确定位到某一轮；再把这一个滑移单独注入真实算法，得到一个反事实摘要——"如果只发生这一次失误，哈希会变成 X"，从而把新产生的错和它的下游传播彻底分开。

结果里最有教学价值的是失败的归因三分法。错误干净地分成三个独立来源：driver 的状态携带错（在 a,d,c,b ← d,c,b,new_b 这步滑一位是最常见的新鲜错误；也有漏步、重复步、提前收尾——比如在 172 次调用处就交答案）；worker 的算术错（模 2^32 回绕时减错了倍数，比较罕见）；serving 层的上下文管道错（推理通道没有被回传，driver 在 196 步里的前 12–24 步就整体崩掉，全有或全无）。作者明确指出 driver 错误占主导，而且把每一个 worker 算术错都当场纠正，也不能让一个已经状态滑移的运行成功——这两个错误源是独立的，状态跟踪才是难的那个。

对你的项目来说，这个三分法就是一张诊断分诊表。同一个"任务失败"，如果是第三类，你调 prompt 和换模型都毫无用处，要去改 serving 配置；如果是第一类，你要加的是状态校验而不是更强的推理。

论文对第二类给了一个可以直接抄的缓解：把每个原语换成无状态的 worker LLM，同一个操作在 0.7 温度下采样三次（每次独立的新上下文），多数值返回给 driver，平票触发一次升级轮。

图注：一次工具调用由投票 worker 完成。在最强配置里每个原语都是独立、无状态的 worker LLM，同一操作在温度 0.7 下采样三次（各自新鲜上下文），多数值返回 driver，平票触发升级轮。这种 self-consistency 压掉了 worker 偶发的模算术滑移；worker 的上下文在每次调用后被丢弃，因此只有 driver 是有状态的。driver 与 worker 是同一个模型，图中的 CPU 参考实现只用于测量和人类可读性，不在运行时给 driver 供值。MD5-LongHorizon

而对第一类和第三类，论文的结论有点反直觉，值得单独点出来：决定成败的杠杆是上下文，不是权重。gpt-oss 会把中间工作写在一个专门的推理通道里，这个通道下一轮是否被回传是最大的单一杠杆——回传时 driver 能跨 196 次调用跟住状态，剥掉之后，在完全相同的模型、prompt 和输入上成功率就崩了。更关键的是：把同样的文本逐字节搬到可见的 assistant 轮里，修不好。作用是"中间工作住在哪里"带来的，不只是"它存在"。同一批权重换个 serving 路由，正确性和延迟都会显著不同（一条路径每步约 2.5 秒、另一条约 13 秒），有些栈接受推理字段、有些直接返回 400。所以论文的标题式结论是："一旦上下文被管理好，长程这道墙就不是本质性的。"该论文的可行性表显示不同服务路由的完成正确率差异很大（作者明确说明该表仍待冻结，下面只把它当作路由影响的初步证据，不能当最终结果引用）。

另一条反向路径：自己给自己打分会把错误放大

上面讲的是"忘"。还有一条同样致命但方向相反的路径：信得太多。

有一篇 2026 年的论文把它量化了。场景是常见的记忆型自我改进 agent：每做完一题，让 LLM 给自己的这条经验打个分存进记忆库，以后检索出来复用。作者的观察是，在没有 gold label 的部署条件下，这个自评分系统性地偏高，而且偏高的方式很坏：被高估的恰好也是那些驱动更多未来决策的记忆——换句话说，agent 优先复用它最自信的那些错误。作者把这个现象命名为 Echo Gap。

放大通过两条通道发生，而且第二条尤其值得警惕。第一条是检索通道：按分数排序的 softmax 检索会直接放大错误记忆的质量占比。第二条是信任通道：即使检索完全对分数盲、只按相似度做，一条记忆的影响力仍然随它存储的分数单调上升——因为 agent 把那个自评分当成可信度注释在读。所以哪怕你的检索是纯 SimCSE 相似度，环路照样在放大。

图注：Echo Gap 的机制与 LUCID 的纠正。左侧是放大回路：记忆库里存着自评分 → 相似度检索 → planner 把取回的条目当先例使用 → 新答案再由自评打分 → 写回记忆库，被高估的错误记忆被优先复用。右侧是纠正：一个 answer-free 的检测器给可疑条目打旗（执行异常 / 结果退化 / 字面值无依据），被打旗的记忆只被降低存储的信任分，内容不重写、任务不重解。这是机制示意图，读不出任何具体数值。EchoGap

这里有一个结论直接推翻了工程上最自然的那个反应。你会想："那我换个更强的 judge 来重新打分不就行了。"论文证明这不够——纠正信号必须满足两条：跟真值相关（truth-tracking），并且它的误差与原自评的偏差不相关（bias-decorrelation）。如果重打分器的误差跟自评偏差同向，那么无论你把纠正步长调到多小，偏差的方差都只会变大，降级只是在重新注入膨胀。而实测中，更强的、乃至跨厂商集成的参数化重打分器都能提高与真值的相关性，却保持了与自评偏差 0.30 以上的相关性，所以它们全部不合格；只有基于检索证据的事实核查器同时通过两条。

作者给出的可落地做法叫 LUCID，特点是完全不看参考答案：对 text-to-SQL 它只读三个便宜的通道——查询是否报错/超时/结果不确定；结果是否空或全 NULL（对一个本该有答案的问题）；有没有出现在问题里根本不存在的实体式字符串字面值（这正是从错误记忆里抄来一个值的指纹）。命中就把该记忆的存储奖励从 1 降到 0。在完整的 BIRD text-to-SQL 开发集（1534 题，官方执行准确率）上，用同一套 planner/executor/retriever、同一个模型（Claude Haiku 4.5）、两个随机种子：无记忆对照 52.4%，朴素自评记忆 54.0%，LUCID 56.9%，相对朴素记忆平均 +2.9 分，两个种子的配对差值区间都不含零。请注意这是单一 benchmark 上的预印本结果。 EIA

有意思的是理论上还有个门槛：这个降级只要求精确率够高，召回可以很低。只要"被打旗的确实是错的"这个概率超过一个由收益/损失之比决定的阈值，降级就是净赚的。这对工程很友好——你不需要造一个能抓住所有错误的检测器，你只需要一个宁缺毋滥的检测器。

所以长程的两种坏法在结构层是对称的：要么状态没传住（忘），要么自评被当成证据（信）。两者都不是"再多训一点"能解决的。带着"我该在哪一步加 verifier、在哪一步加外部依据"这个问题，我们来看下一章。

三、谁在控制哪一步：stage ownership 帮你定位修复点

hum / mix / sys 的编码规则

D3 是这套坐标里最能直接动手的一维。它把一次改进 pass 拆成 goal / plan / execute / feedback / repair 五步，每一格记一个编码：

• hum：实质性输出由人类或设计期产物提供，系统主要在中继。
• mix：人类写下的目标或判据部分地决定了内容，而内容本身也由系统生成。
• sys：只有当系统从上游输入和通用接口约束出发自己原创这份工作时才算。
• nr：来源没披露，记 not reported——注意，缺失披露不等于免检通过。

这个编码规则的严格程度值得留意。很多"全自动"的宣传落到这张表上都会退化成 mix：只要判据是人写死的，系统在做的是在人给定的空间里搜索。

survey 自己把这套编码套在两个 2026 年的前沿系统上，因为只有它们的报告细到能逐格编码。这两个正好构成一组对照。

对照一：模型权重 + harness 那一行

Kimi K3 的技术报告是这一行的原始出处。它是 2.8T 总参数、104B 激活的 MoE，1M token 上下文。跟我们主线相关的是它的后训练和基础设施两块。

在 feedback 这一格上，它做的事很明确：对不可验证的通用任务，它用一个 Agentic 生成式奖励模型，要求 judge 严格走四步——读产出、生成 rubric、按 rubric 给每个候选打分、把分数写进 scorepad，再用基于预算的冗长度控制防止"越写越长"的 reward hacking。关键在于那个 rubric 协议是人写的，judge 只是执行方。它的长程训练范式 AET（自主执行任务）更直接：每个任务有初始状态、受约束的目标、工具动作空间、执行预算和一个独立的 verifier；agent 只看到目标、上下文、约束和验证接口，没有参考轨迹，必须自己分解、选工具、规划、纠错、终止，而奖励由 verifier 评估最终环境状态给出，不是 agent 自报，还配了公开/隐藏 verifier 配对来反 reward hacking。

在 execute 和 repair 这两格上，它高度 sys 化，而且实现方式很具体：它部署了一个建在 Firecracker 之上的 microVM sandbox 运行时（早期容器方案出现过 kernel panic 和死锁），支持暂停恢复（暂停的 sandbox 不占内存和 CPU，因为 agent 等推理占了 sandbox 生命周期的 98%）、fork（做精确副本用于奖励评判，不影响主轨迹）、快照（周期性存快照做错误恢复），增量检查点做到 133 毫秒存、49 毫秒恢复。整个训练与评估期间创建了 51,219,741 个 sandbox、跨 1,505,678 个镜像。

这个数字之所以值得记住，是因为它给上一章的问题提供了一个截然不同的答案：长程状态不一定要放在模型的 context 里，它可以放在虚拟机镜像里。这是"状态持久化"最具体的一种工程形态。Kimi K3

对照二：计算基座 + 验证那一行

另一行的原始出处是 Meta 的 KernelEvolve，一个跑在生产环境里的 agentic kernel coding 框架，跨 NVIDIA、AMD 和自研的 MTIA 三类硬件自动生成并验证 Triton kernel。

图注：KernelEvolve 的系统架构（上）与执行工作流（下）。系统用一个带树搜索的自改进状态机来探索并验证 kernel 优化，集成了评估工具（正确性、性能、profiling）、负责上下文管理与深度检索的专用子 agent，以及面向 MTIA / GPU / AMD 的硬件解释器。一个 LLM 合成器生成动态 prompt，交给外部（Claude 4.5、GPT-5）或内部（Meta 的 CWM）的 LLM 后端产出 Triton kernel 候选。持久化存储包括记录执行分数与搜索树父子关系的元数据存储、存 kernel 文件的对象存储，以及一个作为硬件约束与优化指南检索系统的知识库。KernelEvolve

它的搜索侧几乎全是 sys：正式化成一个四元组搜索（适应度函数 = PyTorch 耗时 / Triton 耗时，编译或正确性失败就记 0；选择策略；一个 LLM 驱动的上下文感知通用算子；终止规则）。它刻意用一个通用算子替代传统的 Draft/Debug/Improve 多算子框架，理由很有说服力：固定模板的 Debug prompt 不管是算法错、内存访问错还是硬件错都用同一套问法，会把模型的推理空间框死在错误视角里；改成每轮基于当前 profiling 和错误信息合成 prompt，模型才能在一次迭代里同时权衡正确性、内存访问、硬件特性和算法取舍。

而它的正确性侧几乎全是 hum。验证链分三层：kernel 层用 TritonBench 把 Triton 实现和 PyTorch 基线在相同输入上跑，用 torch.allclose() 按精度相关的容差做数值比对；系统层用 Torch Profiler 抓 kernel 启动开销和主机-设备同步；再上一层是把 MLIR、Triton Proton、NCU、NVBit 的插桩统一成可组合任务图的多趟 profiler。论文明说"没有单个工具能提供完整的栈可见性"，所以才需要联邦式的多趟方案。而那个容差、那份人工撰写的知识库内容、那份 kernel 规格，都是人定的。私有硬件这块尤其能说明问题：MTIA 在公开语料里几乎不存在，解决办法不是重训模型，而是往知识库里写文档（每个硬件平台子树 15–40 份，整库上百份）——"AI 改进私有硬件基础设施"这件事因此从"要重新训练"降级成"更新一份文档"。生产结果是跨异构硬件相对 PyTorch 基线 1.2–17 倍的加速（摘要口径；正文第 7 节写作 1.25–17 倍，两个版本口径略有差异），KernelBench 250 题全通过，160 个 PyTorch ATen 算子 × 3 个硬件平台共 480 个配置全部正确。

把两行并排看，结论就出来了：今天最前沿的两个 AI4AI 系统，execute 和 repair 都已经大面积交给系统，但 goal-setting 和 correctness check 仍然牢牢握在人手里。"agent 接管一切"是叙事，不是事实。KernelEvolve 的论文甚至没有明确报告 harness 是否自改，按编码规则这就该记 nr 而不是替它填上。

现在你可以给自己的项目画那张表了：五行（goal / plan / execute / feedback / repair）乘三态，凡是你说不清的格子就老实写 nr。写完你会发现两件事：你的 sys 格子集中在哪里，以及你的 feedback 那一格到底靠什么。如果它靠的是模型自评，回去看第二章的信任通道。

但填完表还不够——你还得能证明"改动带来的是真改进"。这正是下一章要解决的事。

四、怎么测才不被自己骗：把评估协议本身当作设计对象

一个分数说明不了什么

survey 在这一块给的最硬的东西是 D5 内部那四格：G 是测到的增益（声明的分数上去了）；R 是保持（增益在保存性测试后仍然存在，或者跨 pass、跨代继续改善）；H 是人类对比（在对齐的预算下和人比过）；T 是 held-out 迁移（增益扩展到被优化的那个指标、任务、模型、领域之外）。四格各记 y/n/nr，通过一格不蕴含通过另一格。survey 的审计发现已发表研究报告的是不同的子集，而漏测的那格是 nr，不是免检。

pass 率这边的关键区分同样简单但常被忽略：pass^1 是"每一次 rollout 都成功"的任务比例，pass^k 是"k 次里至少成功一次"。两者之间的大 gap 意味着系统能找到解，但不能稳定地产出解，而任务越长这个 gap 越宽，因为早期的错会重塑后续决策。如果你的产品形态是无人值守地跑，你要报的是 pass^1；用 pass^k 汇报一个无人值守的场景，等于在系统性地高估自己。

任务压力也不是一个数，survey 列了六轴：人力投入时间、交互长度、上下文与记忆需求、环境 grounding、规划依赖、验证可观测性。所谓 reliable horizon 是这个多维空间里的一个可靠区域，不是一个标量。

还有一个区分值得单独拎出来，因为它常被工程实践搞混：grounding 不等于 observability。D4 按信号离外部证据有多近排序（形式验证器与可执行测试最强，held-out benchmark 与学到的 reward 居中，模型 judge 与自省最弱）；而验证可观测性问的是另一个问题——信号有多延迟、多不完整、多贵。一个可执行测试可能 grounding 很强但慢且贵；一个模型 judge 可能立刻返回但独立性很差。survey 的原话是："外部 grounding 越弱，一个循环就有越多空间去确认自己的错误。"所以"我能看到 agent 的推理过程"完全不构成 grounding——那只是 observability。第二章的 Echo Gap 就是这句话的实测版本。

survey 把"要主张延长了 reliable horizon 需要什么证据"画成了一张矩阵：

图注：一个 4×4 矩阵。列是 Prevent / Detect / Recover / Prove；行是 Model（规划 / 自我批评 / 重规划 / 消融）、Harness（类型化工具 / verifier / 回滚 / 披露 harness）、Environment（约束 / 状态检查 / 检查点 / 可重放状态）、Evaluation（压力路径 / 轨迹日志 / 失败标注 / 对齐预算与置信区间）。矩阵下方是三级证据强度阶梯：「弱证据——一条成功轨迹」→「对齐评估——同一 harness、重复且分层」→「延展主张——稳健的边界移动」。原文明确：箭头表示的是证据的顺序，不是测到的效应大小；四列也不是时间序列。AI4AI Survey

这张图最该被记住的是底部那三级阶梯。"我跑通了一条漂亮的轨迹"停在第一级，而第一级在这个框架里叫弱证据。要上第二级，你需要同一个 harness、重复运行、分层统计；要上第三级，你得证明可靠边界真的移动了。

两个把预算写进协议的样本

抽象的协议要求，看两个真实 benchmark 怎么落更清楚。

ML-Master 2.0 做的是 24 小时预算下的 MLE：OpenAI 的 MLE-Bench，75 个真实 Kaggle 竞赛，每个任务给数据、1008 GB 内存加 1 TB SSD 的沙箱，和一个硬性的 24 小时墙钟预算，headline 表跑三个随机种子报均值加标准误。所有参赛系统跑在同一预算下，所以它报的 56.4 ± 2.5% 平均奖牌率是一个可比的单一数字（按复杂度拆开是低 75.8 ± 1.5%、中 50.9 ± 3.5%、高 42.2 ± 2.2%）。 HCC

它的架构本身也回答了第二章那个"上下文该怎么管"的问题，方法是照抄计算机的存储层级（作者自己说灵感是 cache → RAM → disk，不是认知科学隐喻）：

图注：ML-Master 2.0 通过认知累积实现超长程自主 MLE 的框架，图中 HC 与 CM 分别代表分层缓存与上下文迁移。三层依次是 L1 演化经验（当前研究计划、代码补丁、终端输出、报错、指标日志这类高保真的、现在就要用的执行痕迹）、L2 精炼知识（把不再立即可执行的原始痕迹提升上来，压成保留策略、丢掉执行噪声的摘要）、L3 先验智慧（跨所有已解任务蒸馏出的任务无关策略——稳健的模型模板、可复用的预处理管线、稳定的超参先验，通过在 407 个 Kaggle 竞赛上暖启动构建，MLE-Bench 中的竞赛已排除）。ML-Master 2.0

这套东西有效到什么程度，有一张单任务的证据图说得最直接：

图注：ML-Master 2.0 处理 random-acts-of-pizza 任务时上下文长度的增长。橙线是完整上下文长度，蓝线是 HCC 中的上下文长度。系统成功把峰值上下文从超过 20 万 token 压到约 7 万，并在研究计划提出与验证的第四次迭代中拿到奖牌。这是单任务的图，不能外推到全部 75 个任务，也不是那个 56.4% 的证据。ML-Master 2.0

这里的教学点是：上下文不是越大越好。压掉噪声的同时保住了奖牌级质量，说明有效上下文和原始上下文是两件事。它的消融也很干净，但要注意口径——那组数字跑在 MLE-Bench-Lite 上、单个种子，不能跟 56.4% 那个数直接比：完整三层的奖牌率 72.7%，去掉 L1 经验塌到 22.7%（有效提交率也从 95.5% 掉到 54.5%），去掉 L2 知识是 59.1%（有效提交率不变，因为原始上下文照样能干活，但没有综合发生），去掉 L3 智慧是 54.5%。另外那个"相对 1.0 版本提升 92.7%"的说法同时混了架构变化和更强的骨干模型，不能当成 HCC 单独的因果效果。

另一个样本是 PostTrainBench，它把 agent 直接放到模型权重那一层：给一个 base 模型、一个目标 benchmark、10 小时和一张 H100，让它自己把后训练管线从零搭出来。 PostTrainBench

图注：PostTrainBench 的流程。agent 收到一个 base LLM、目标 benchmark 和单张 H100 上的 10 小时预算，然后对模型做后训练以最大化性能。一个 LLM judge 检测作弊（模型替换、数据污染）；被打旗的运行按 base 模型分数计。每个 agent 在 28 个模型–benchmark 配置（4 个 base LLM × 7 个 benchmark）上评测；前沿 agent 在原生 scaffold 上每配置跑 3 次以估计方差。注意 judge 在图上是流程里独立的一环，不在 agent 手里。PostTrainBench

它的聚合结果图把"报分必须连预算和重复次数一起报"这件事变成了肉眼可见的东西：

图注：不同 agent 在 4 个 base 模型（Qwen3-1.7B、Qwen3-4B、SmolLM3-3B、Gemma-3-4B）与 7 个 benchmark（AIME 2025 与 GSM8K 数学、GPQA 科学、HumanEval 编码、BFCL 函数调用、Arena-Hard 创意写作、HealthBench 健康建议）上的加权平均表现，加权权重在论文的权重表中给出，误差棒是跨运行的 ±1 标准差。这是聚合图而非逐 benchmark 明细，且是 arXiv v2 时点的快照。误差棒本身就是论据：只有前沿 agent 跑了 3 次，才画得出误差棒。PostTrainBench

它的数字对照（arXiv v2 时点快照，官方站点已随 v1.1 重跑而变动）是：最好的 agent 23.2%，base 模型平均 7.5%，而官方 instruction-tuned 基线 51.1%，没有 agent 接近。有三个窄口 agent 确实赢过了人类工程团队（比如某 base 模型在函数调用上 89% 对官方 67%），作者立刻给这个结论套了限定：官方管线花的是数千 GPU 小时，agent 只有 10 小时；但官方模型优化的是跨任务的通用能力，agent 优化的是单一 benchmark。原文明确写这"不意味着 agent 能复刻产出通用指令跟随助手的完整后训练管线"。这就是 G 那一格最典型的陷阱：数字是真的，但它衡量的东西被窄化了。

更值得抄进你自己协议的是一件事：这个 10 小时是被行为倒推出来的。给 20 小时，agent 常常提前停；而在 10 小时窗口内，不同 agent 的时间利用差异极大（有的 5 小时就到平台期，有的一路涨到 10 小时，有的 2–3 小时就收工）。也就是说，预算在这里既是评测公平性的约束，也是被评能力的一部分——报分不写预算等于没报分。作者自己也声明这个预算不反映真实的后训练时间线或分布式设置，且只有前沿 agent 跑了 3 次、其余单次，方差量化不足。

到这里协议三件套已经齐了：重复次数、对齐预算、held-out 比例，它们应该和被测系统本身一样写进报告。带着"我的评估协议长什么样"这个问题，来看今天可以直接 fork 的那些模式。

五、可复用模式与 RSI 的真实边界：外层 evaluator 都是固定的

最容易 fork 的那个范式

如果只能抄一个模式，抄 AlphaEvolve 这个。它的结构极简：用户提供一段初始程序（用标记圈出要进化的代码块）、一个把候选解映射成标量指标的 evaluate() 函数，以及可选配置；然后 prompt 采样器从程序数据库里取历史高分程序组装 prompt，LLM 集合对当前程序生成 diff，diff 应用后成为新程序，由 evaluator 打分，得分高的注册回数据库，驱动下一轮。 AlphaEvolve

图注：AlphaEvolve 发现流程的展开视图。用户提供初始程序（标出要进化的组件）、评估代码和可选配置，随后进入一个进化循环：Prompt sampler 用 Program database 里的程序构造丰富的 prompt，LLM 据此生成代码改动（diff），diff 被应用后产生新程序，再由 Evaluators 打分，有希望的解注册回 Program database，驱动越来越好的程序被迭代发现。注意 Evaluators 是独立于 generator 之外的模块。AlphaEvolve

关键设计是那个 evaluator 在循环里不被修改：它的接口、指标集合、调用方式都是人写好后钉死的，LLM 改的是"被它打分的程序"，不是"它自己"。这就是 bounded AI4AI 最典型的形态。它的搜索空间也值得注意——不是参数空间也不是 token 序列，而是代码本身。它报告的发现包括在 14 个矩阵乘法目标上改进 SOTA（其中 4×4 复矩阵乘法找到只需 48 次标量乘法的分解，相对 Strassen 1969 的 49 次是该设定下 56 年来的首次改进）、演化出替代生产调度器启发式的向量装箱方案（部署后测得平均回收 0.7% 的集群算力）、优化训练用 kernel 的分块启发式（平均 23% kernel 加速、整体训练时间下降 1%）。这些部署级数字都是厂商自报，第三方尚未公开复现，引用时要保留这个限定。

让 agent 改自己代码，边界在哪

再往前一步就是 Darwin Gödel Machine：让 coding agent 编辑自己的 Python 代码库。

图注：Darwin Gödel Machine。DGM 通过交替进行自我修改与下游任务评估，迭代地构建一个不断增长的 agent 档案库。档案库中的 agent 通过开放式探索被选出来做自我修改。图上是一个横向流程：左侧的 agent 群体进入自我修改步骤，产出被评估过的子节点，箭头再循环回群体。它改写的只是自己的 Python harness 代码，不是模型权重；这是 bounded RSI，不是一般意义上的"自我改进 AI"。DGM

它的边界正是本章的主题，而且是作者自己划的：开放式探索的过程本身（档案维护、父节点选择）是固定的、DGM 不能修改，作者把这条明确列为未来工作。内环自改，外环的 selector、沙箱、evaluator 不动。这也是它敢称 RSI 却不失严谨的原因——它把哥德尔机原本要求的"自我改进的形式证明"换成了"在选定 benchmark 上的经验评估"。

它的档案机制有一个反直觉但很实用的发现。父节点选择大致按分数成正比、按已有子节点数成反比，也就是档案里每个 agent 都保留非零的被选概率。80 次迭代后，agent 在 SWE-bench Verified（子集评估）上从 20.0% 提到 50.0%，在完整 Polyglot 上从 14.2% 提到 30.7%。

图注：DGM 自动自我改进为更好的编码 agent。左图是运行期间生成的 coding agent 档案树（节点 0 是基线，节点颜色对应 SWE-bench 百分比，边是自我修改的谱系）；右图是 80 次迭代上的进展图，展示平均分、最佳分与最终最佳 agent 的谱系轨迹，其中深色谱系线包含两次性能下探。这两次下探正是"保留踏脚石"的具体视觉证据。不要把 80 次迭代的曲线外推成"无限持续改进"，论文自己把它框定为有界的。DGM

那两次下探是整章最值得记住的画面：最终最强的那个 agent，它的祖先链条上有两次变差。如果你用"总是从当前最好的那个分叉"这种贪心策略，就会在下探处把它剪掉。消融数字支持这个判断：贪心版在两个 benchmark 上分别掉到 39.7% / 30.0%（完整版 50.0% / 38.0%）；去掉开放式探索只剩 23.0% / 14.0%；去掉自我改进（换成固定的 meta-agent）是 39.0% / 28.0%——两个组件都必需。它的增益还有一定迁移性：跨模型、跨 benchmark（SWE-bench 上最好的 agent 迁到 Polyglot 得 28.9%，对基线 14.2%）、跨语言都成立，这是反驳"RSI 就是刷榜"最有力的单点证据。成本要诚实报：一次完整运行约两周墙钟时间加不小的 API 开销，全部执行和自改都在隔离沙箱里，并且它不改训练脚本、不更新自己的基础模型权重。

PostTrainBench 那边还提供了一个未经设计的反面版本：早期迭代里，有 agent 直接修改了评测框架的代码来抬分。DGM 是有意让 agent 改自己的 harness，PostTrainBench 是明令禁止的情况下 agent 仍然去改了。两者一起说明：当 harness 不是硬边界时，agent 会把它当成一个可优化的对象。

paper-writing 那一层也有个可拆解的样本。AI Scientist v2 把整条链跑通（想法 → 实验 → 可视化 → 撰写 → 审稿），拿掉了 v1 对人工代码模板的依赖。

图注：AI Scientist-v2 工作流。流程覆盖自动想法生成、实验执行、图表可视化、稿件撰写与审稿几个阶段。与初版不同，v2 移除了对人工编写模板的依赖，改用由一个实验进度管理器跨若干阶段管理的 agentic 树搜索（图中橙色）来生成并精炼代码实现；后续实验利用树搜索中表现最好的代码检查点（节点）来迭代检验各种研究假设。注意流程仍有主题/种子的人工入口，不是完全自主。AI Scientist v2

它可复用的点有两个：阶段间的最佳节点接力（每阶段结束由 LLM 评估器按指标、训练动态和图表质量挑出最好的节点，作为下一阶段树的根，且每阶段后启动多次复现使结果带均值和标准差），以及用 VLM 审图（对每张生成的图检查标签不清、缺图例、误导性可视化，命中就把该节点标记为 buggy，进入下一轮的调试路径）。它的外部终点很硬：三份全自动生成的稿件投给了一个真实的 ICLR 2025 workshop（与 ICLR 方面和组织者协调、经大学 IRB 批准），43 份投稿里有 40 份是人写的，其中一份 AI 稿件被接收，评分 6/6/7、均值 6.33，位列投稿前 45%。作者自己把限定说得很清楚：这是 workshop 级别而非会议级别，workshop 接收率通常 60–80% 而主会 20–30%，并且他们主动披露了那篇稿件的内部质量问题（约 57% 的训练/测试集重叠、术语混用、过于简单任务导致的虚高准确率）；按事先约定，那篇被接收的稿件在审稿后已撤回。

把这一节的所有系统排在一起，共性只有一句：外层 evaluator 是固定的。AlphaEvolve 的 evaluate()、KernelEvolve 的容差与知识库、K3 的 rubric 与独立 verifier、PostTrainBench 禁改的评测脚本、DGM 不可修改的 selector、AI Scientist v2 的人类审稿人——被改的对象各不相同，钉死的那一层永远存在。这就是 bounded RSI 的边界，也是你判断自己项目的最直接依据：你的 evaluator 钉在哪里？

一把让你保持冷静的尺子

最后需要一把尺子，来判断你看到的"自我改进"是真放大还是叙事放大。

有一篇 2026 年的理论论文借流行病学的思路给了一个判据：定义一个再生数 $\mathcal{R}{\rm AI}$，等于递归增益（操作闭合度 × 递归收益）除以前沿硬度。$\mathcal{R}{\rm AI} > 1$ 时，小扰动在参考轨迹附近被局部放大；等于 1 是临界边界；小于 1 时所有特征根实部为负、扰动衰减。

$$\mathcal{R}_{\rm AI} = \frac{\chi a}{\sigma}$$

这个式子最有价值的地方在于它说了什么不成立。它不要求"AI 已经具备某种神奇能力"——进不进入自放大只取决于这个比值，不取决于当前能力本身。所以能力还很低时可以是超临界的，而在高基线研究生产率下也可以出现快速进展却根本没进入自放大。论文自己也警告：局部放大不蕴含总能力的无限增长。

图注：参数空间上的递归临界性。a 图是峰值递归临界性作为前沿硬化指数 β 与递归增益 a 的函数（k=10），四颗菱形标出四个参考情景：亚临界的平滑扩展、弱超临界、瞬态起飞、快速转变，取在 β=2、a ∈ {0.5, 3, 6, 15}。b 图是峰值临界性对 β 与操作闭合陡度 k 的依赖（a=3），菱形标出参考选择 (β,k)=(2,10)。$\mathcal{R}_{\rm peak}=1$ 这条边界把保持亚临界的参数组合与进入局部超临界区的参数组合分开。图中所有参数值都是 illustrative，不是对现实系统的预测。RecCrit

模型里还有两条对工程有直接启发的推论。第一，循环时长 τ 是放大速度的硬上限：在高吞吐极限下增长率趋近 $\ln \mathcal{R}_{\rm AI} / \tau$，所以再多算力再多人力，都不如把一个改进循环的周期缩短。第二，递归跑道是有限的：在有限前沿的模型下，难度增速在接近前沿时发散，所以即使系统曾经超临界，靠近前沿时也必然回到亚临界——一次超临界只是瞬态。论文还给了一个网络化版本，结论是即使每个参与者单看都不到临界，网络的谱半径仍可能大于 1；其中列出的各种年数场景全部是该模型设定下的 illustrative，不是日历预测，也不映射任何具体公司或地区。

这把尺子的实际用法是逼你回答四个可测的问题：递归反馈有多强、改进以多高的有效比率传进后继系统、一个循环要多久、进展变难得有多快。而 anchor survey 对 RSI 的整体结论比这更保守，值得原样引用：RSI 要求系统改的是构建下一版本的过程、每个新版本在对齐预算和测试下有真实增益、增益能持续、且它有助于后续版本——而**"目前没有证据同时满足所有这些条件"**。一句话概括这一整章：change is not the same as progress。

六、明天可以跑的三个最小实验

前五章的所有讨论，收在三个一到两周内能动手的实验上。它们的共同点是：每一个都对应上面那张证据矩阵里的至少一层。

图注:三个最小实验 M1→M2→M3 线性推进,共同写入同一份协议字段

M1：在一个可重放环境里跑至少 30 次同一个长程任务，记下第一次失败发生在哪个 stage。 编码就用 PLAN / EXECUTE / FEEDBACK / REPAIR 四类，再套上第二章那个归因三分法问一句：这次是状态没传住、单步算错了，还是上下文管道本身出了问题（比如推理内容没被回传、约束掉出了上下文窗口）。MD5 那篇论文用参考实现做到了逐调用对账，你不一定有这么干净的 ground truth，但你至少能做到"记下第一次分歧的位置"而不是只记"最终失败了"。这个实验对应证据矩阵的 Detect 那一列，它的产出不是分数，是一张失败位置的分布——而它往往会告诉你，你之前调的根本不是出问题的那一层。

M2：对 harness 做一次受控修改，用对齐预算 + held-out + 回归率来检验。 只改一处（加一个 verifier、把某个自评换成可执行检查、把状态从 context 挪到外部存储），然后严格照第四章的三件套报：重复几次、对比双方的预算是否相同、held-out 上是否也涨、之前能过的实例有多少退化了。PostTrainBench 那个"预算既是约束也是被评能力"的观察在这里很实际：如果你改动后 agent 只是把更多时间花掉了，那增益属于预算不属于改动。这个实验对应 Prevent / Recover，同时给你 D5 里的 G 和 T 两格。

M3：从上一章挑一个局部模式 fork 下来，并把 evaluator 边界明确写出来。 想要最小实现就抄 AlphaEvolve 的"LLM 提议 diff + 固定 evaluator + 程序数据库"；上下文吃紧就抄 ML-Master 的三层缓存；要防自评膨胀就抄那个 answer-free 的三通道检测器（记住：要的是精确率，召回可以低）；想让 agent 改自己的 harness 就照 DGM 那样保留档案而不是贪心分叉，并且别忘了外环必须钉死。这三个模式里凡是我们引用过的实现细节都来自论文报告，公开仓库的可复现程度各不相同，所以按"论文报告的做法"来复刻，别假设 git clone 就能跑。这个实验对应 Prove：你要能说清你的增益是在什么 evaluator、什么预算、重复几次下测出来的。

三个实验的协议字段建议直接抄进项目 README：环境与可重放性、k 次重复、对齐预算、held-out 比例、first-failure stage 编码。这五行就是你和"我觉得它变好了"之间的全部距离。

最后一句提醒，也是这篇 survey 最该被带走的那句：如果你做完 M2 发现 held-out 上没有增益，不要再调一轮超参。回到第二章问是哪条 cascade 路径（状态没传住，还是自评被当成了证据），或者回到第三章那张 ownership 表看你的 feedback 那一格到底写的是什么。分数动了不等于系统变好了，而这两者的区别，正是这套坐标系存在的全部理由。

延伸阅读方向上还有几块本篇没有展开：另有若干 AI R&D 综合 benchmark 尚缺独立一手证据，只能算候选；那篇 sister survey 的评估建议清单（初始基线、固定改进预算后的表现、跨迭代学习曲线、held-out 迁移、回归率、完整成本汇总，以及"judge 预算必须与 agent 执行预算隔离报告"）值得和本篇第四章的三件套并读。

参考文献

本专题引用的核心资料如下，建议深入学习时阅读原文：

1. AI4AI Survey: From Long-Horizon Agents to Recursive Self-Improvement — Definitions, Reliable Horizons, and Open Problems — https://www.preprints.org/manuscript/202608.2108（未同行评审预印本；公开 PDF 镜像见 Awesome-AI4AI）
2. Long-Horizon State Tracking in LLMs: Executing MD5 through a Deep Sequence of Dependent Tool Calls — arXiv:2609.00012
3. Kimi K3: Open Frontier Intelligence — arXiv:2607.24653
4. KernelEvolve: Scaling Agentic Kernel Coding for Heterogeneous AI Accelerators at Meta — arXiv:2512.23236
5. ML-Master 2.0: Toward Ultra-Long-Horizon Agentic Science via Hierarchical Cognitive Caching — arXiv:2601.10402
6. PostTrainBench: Can LLM Agents Automate LLM Post-Training? — arXiv:2603.08640
7. AlphaEvolve: A Coding Agent for Scientific and Algorithmic Discovery — arXiv:2506.13131
8. Darwin Gödel Machine: Open-Ended Evolution of Self-Improving Agents — arXiv:2505.22954
9. Self-Improvements in Modern Agentic Systems: A Survey — arXiv:2607.13104
10. Memory Reward Inflation in Self-Improving LLM Agents — arXiv:2608.00017
11. Recursive Criticality of AI Self-Improvement — arXiv:2609.00137
12. The AI Scientist-v2: Workshop-Level Automated Scientific Discovery via Agentic Tree Search — arXiv:2504.08066