The loop that
improves the loop

递归自我改进（recursive self-improvement，RSI）的概念可以追溯到 I. J. Good（1965），他把"超智能机器"（ultraintelligent machine）定义为一种能在所有智力活动中超越人类、并能设计出更好的机器来改进自身的系统。Yudkowsky（2008）用"递归自我改进"指代一个特定的反馈回路：AI 利用它当前的智能，去改进产生这种智能的认知机器（cognitive machinery）。

在现代 AI 中，这个反馈回路可能意味着模型直接重写自己的权重；更广义地说，是模型改进训练管线（training pipeline）和部署系统（deployment system），从而催生出一个在经济上有价值的任务上表现更好的后继模型。前沿实验室的研究开发速度已被证明在急剧加快（Anthropic、OpenAI）。

我特意提到"部署系统"，是因为原始模型与现实世界语境之间的那一层，似乎与模型的原始智能（即预训练之后立刻评测出来的水平）同等重要。Harness 是 AI 部署的重要组成部分，Claude Code、Codex 等成功的编码智能体产品就是明证。Harness 是包围基础模型的那套系统：它编排执行过程，决定模型如何思考与规划、如何调用工具和行动、如何感知与管理上下文、如何存储产物、如何评估结果。

这篇文章将聚焦 harness 工程的相关研究，以及它如何为 RSI 做出贡献。近期大量关于自动研究（auto-research）、自我改进智能体、进化程序搜索的工作，都可以围绕这个问题来组织。其他工作——如模型自博弈、合成数据、测试时训练，以及更广泛的持续学习主题——同样契合 RSI 愿景（例如 Yuan et al. 2024；Chen et al. 2024；Zhao et al. 2025；Choi et al. 2026），但它们不是本文的重点。

与早期智能体框架（"智能体 = LLM + 记忆 + 工具 + 规划 + 行动"）相比，harness 工程还额外包含工作流设计（例如循环工程）、评估、权限控制，以及持久状态管理。它不再只是提示词模板，而更接近运行时与软件系统设计：模型如何观察、行动、记忆、自我检查、自我改进。

设计应该刻意保持简单和通用，以便泛化，并且很可能要借鉴现有的软件工程实践，以利用预训练知识。操作系统与 harness 之间也有很强的类比：类似 OS，harness 应该把复杂的逻辑封装起来，同时保持接口简单。与此同时，配置、工具接口和其他协议可能会在行业内逐步标准化。

模式 1：工作流自动化Workflow Automation

定义一个模型可以在其中操作、测试、迭代的工作流，是实现自动化的关键设计。Karpathy 的 autoresearch 仓库（github.com/karpathy/autoresearch）就是如何构建这种工作流的一个干净范例。常见的工作流遵循一个目标导向的循环：规划 → 执行 → 观察/测试 → 改进 → 再次执行，直到达成目标。过程中，系统可能会主动向用户请求澄清，确认任务规格或执行偏好。

FIG. 01 — CODEX AGENT LOOP

简化的 Codex 智能体循环：智能体调用工具，工具响应又影响模型的下一次生成。（图片来源：OpenAI Codex Agent Loop 博文）

工作流图还强调：模型要分析自己的轨迹和失败案例，然后通过一个"智能体运行时"（agent runtime）迭代推进，而不是依赖静态的提示词模板。

模式 2：文件系统作为持久记忆File System as Persistent Memory

长周期（long-horizon）智能体系统中反复出现的一个模式是：对丰富的状态和产物做简单控制。harness 不应把整个工作流和全部日志都装进上下文；相反，它应该把持久状态保存在文件里。在长周期的智能体 rollout 中，实验日志、代码 diff、论文摘要、错误追踪、历史 rollout 轨迹等产物，往往长得远远超过模型训练所用的上下文窗口。

学会读、写、编辑文件系统（通常通过 bash 命令）是 LLM 的基础技能，因此，以文件这种简单形式来管理持久记忆，自然能受益于核心模型能力的提升。

模式 3：子代理与后台任务Sub-agents & Backend Jobs

harness 可以派生多个子代理并行执行，并监控后台任务。当主代理需要搜索多个假设、并发运行实验，或者委托一些隔离的子任务而又不想污染主上下文时，这非常有用。父代理于是需要一个小小的进程管理器：启动任务、检查日志、取消失败的运行、把结果合并回主代理线程。

关键的设计选择是让并行变得显式且可检查。如果子代理的输出只存在于转瞬即逝的对话上下文中，它们很快就会过时并被隐藏；如果它们被存成文件、日志和状态记录，模型就能在中断后恢复，并能对自己过去的执行历史进行推理。

案例研究：编码智能体 HarnessCase Study

主流编码智能体的核心接口在 Claude Code、Codex、OpenCode 和 Cursor 风格的智能体之间已经趋于稳定。它们通常使用这样的循环：

FIG. 02 — CODING AGENT HARNESS

拥有一组工具后，编码智能体能够在给定的代码仓库中开发和调试问题，就像人类开发者配备了 IDE 一样。（非完整清单，仅作演示。）

很难预测 RSI 的未来有多大程度会依赖 harness 工程，但近期的 RSI 路径不太可能从"模型直接重写自己的权重"开始。作者对近期可行路径的预测：

最终，许多 harness 的改进有可能被内化（internalized）进核心模型的行为中，但与外部上下文和工具的接口应该保留下来。我们已经在提示词工程上看到过这种模式的较软版本：随着指令微调和模型推理能力的提升，手工提示技巧变得不那么核心了，但指定目标、约束、上下文和评估的需求并没有消失。

harness 系统中被优化对象的演进大致是：指令（提示词）→ 结构化上下文 → 工作流 → harness 代码 → 优化器代码。随着模型变得更聪明、更强大，我们走向更复杂的目标和更通用的方法。

上下文工程Context Engineering

把所有的工具响应和模型生成都简单追加进上下文，在智能体任务周期大幅拉长时会迅速失控。上下文管理（context engineering）是这样一个层：为 LLM 构建更结构化、更精简的上下文，并管理持久状态。毫无疑问，长上下文研究会持续进步，但就目前而言，长上下文智能与上下文工程有时是交织在一起的。

Agentic Context Engineering（ACE；Zhang et al. 2025）把上下文当作一本不断演化的"剧本"（playbook），而不是一条越来越长的提示词。它用三个组件来维护一份要点式（bullet points）的上下文剧本，每个要点都有标识符和描述：

• 生成器（Generator）：参照要点，产出任务轨迹。
• 反思器（Reflector）：从成功和失败的轨迹中提炼洞见。
• 策展人（Curator）：以增量、逐条的方式更新结构化上下文。

FIG. 03 — ACE FRAMEWORK

Agentic Context Engineering（ACE）框架。（图片来源：Zhang et al. 2025）

为了防止迭代重写过程中的上下文坍缩（context collapse）和简洁偏差（brevity bias），ACE 的一个关键设计是：策展人不重写整块提示词。它输出一组结构化的逐条要点（标识符，描述），这些要点以确定性逻辑合并进一本结构化的上下文日志，并定期精炼、去重。

ACE 从 rollout 中学习洞见，这让我们朝着"自管理记忆"迈进了一步，但它的更新规则和整体工作流仍然是手工设计的。为了走向更自我改进的循环，Meta Context Engineering（MCE；Ye et al. 2026）把机制（如何管理上下文）与产物内容（上下文里有什么）分离开来：在元优化层运行技能进化（skill evolution），在基础层运行上下文优化。

MCE 中，一个技能 s ∈ 𝒮 定义一个上下文函数 c_s = (ρ_s, F_s)，把输入 x 映射为上下文 c = F_s(x; ρ_s)，其中：

• ρ_s = {ρ₁,…,ρ_m} 是静态组件（提示词、知识库、代码库）。
• F_s = {F₁,…,F_k} 是动态算子（搜索、选择、过滤、格式化）。

双层优化的目标是：内层在训练数据上找到给定技能 s 下的最佳上下文 c_s*；外层在验证集上找到表现最好的技能 s*：

技能数据库跟踪历史技能、上下文函数和评估指标：𝒽_k-1 = {(sᵢ, cᵢ, Jᵢᵗʳᵃⁱⁿ, Jᵢᵛᵃˡ)}ᵢ₌₁ᵏ⁻¹。一个元层代理对先前的技能执行智能体式交叉（agentic crossover），给定任务 τ 生成新技能：s_k = crossover(τ, 𝒽_k-1)。然后基础层的上下文工程师执行技能 s_k，在 rollout 反馈 ℛ_k 的指导下、依据当前技能学习上下文函数：c_k = engineer(τ, s_k; c_k-1*, ℛ_k)。

FIG. 04 — META CONTEXT ENGINEERING

Meta Context Engineering（MCE）框架：元层技能进化搜索上下文管理机制，基础层优化任务上下文。（图片来源：Ye et al. 2026）

MCE 不像 ACE 那样对上下文结构施加启发式规则。它用自由形式的技能来存储一项任务最重要的知识，并让技能与技能条件化的上下文一起迭代进化。实现上，上下文函数 c 被实例化为专用目录中的一组文件，既包含静态组件（skill.md），也包含动态组件（context 与数据 rollout）。元层和基础层的优化都在标准工具集的智能体编码环境中执行：

Meta-Harness（Lee et al. 2026）再往深处走了一层：被优化的对象变成了"决定并优化应该存储、检索、呈现什么信息给模型"的代码。"Meta-"的意思是，它是一个用于优化 harness 的 harness。

FIG. 05 — META-HARNESS OUTER LOOP

Meta-Harness 的外层循环优化算法。（图片来源：Lee et al. 2026）

创建新 harness 的提议者（proposer）本身就是一个编码智能体，最终输出是 Pareto 前沿上的一组 harness 候选：

• 整个执行历史都可以通过文件系统访问，因此编码智能体用 grep 或 cat 之类的命令翻阅历史，而不是把一切都塞进单个提示词上下文。
• 被提议的 harness 是文件系统中的一个字典（目录），包含它自己的源代码、分数、rollout 轨迹和状态更新。
• 元 harness 循环迭代地创建新 harness，只有合格的才被保留。

FIG. 06 — META-HARNESS PERFORMANCE

Meta-Harness 的性能：（左）文本分类，少量迭代即可；（右）TerminalBench-2。注意 TerminalBench-2 实验的搜索是从 Terminus-KIRA 和 Terminus-2 这两个非常强的 harness 初始化的。（图片来源：Lee et al. 2026）

不过，重要的教训已经很清楚了：一旦 harness 设计变成一个可执行的搜索空间，一个强大的编码智能体就能利用人类工程师所用的同一个设计空间。

工作流设计Workflow Design

harness 工程中的工作流设计可以由领域专家手工完成。以自动研究为例，人们已经提出并测试了各种框架。AI Scientist 系统（Lu et al. 2026，Nature）构建了一条管线：提出研究想法 → 写代码 → 跑实验 → 分析结果 → 写论文 → 进行同行评审。ScientistOne（Meng et al. 2026）把可验证性（verifiability）作为核心设计约束：每一个声明（引用、数值、方法论、结论）都必须追溯到证据来源，并通过证据链（Chain-of-Evidence）检查来审计。

FIG. 07 — AI SCIENTIST PIPELINE

AI Scientist 的想法生成、实验、论文写作和评审管线。（图片来源：Lu et al. 2026）

Autodata 智能体（Kulikov et al. 2026）被设计成一位"数据科学家"，负责生成训练和评估数据。主智能体管理一个提出问题的挑战者（challenger）、一个弱求解器（weak solver）、一个强求解器（strong solver）和一个验证器/裁判（verifier/judge），目标是合成"难度刚好"（just right）的数据——即强求解器能成功、而弱求解器会失败的那种难度。

FIG. 08 — AUTODATA WORKFLOW

Autodata 智能体式工作流设计：围绕挑战者、求解器和验证器角色生成合成训练与评估数据。（图片来源：Kulikov et al. 2026）

在 Autodata 中，挑战者的提示词会根据求解器和验证器的反馈迭代更新。它的局限在于：合成任务被用来微调弱求解器，而不是强求解器；如果这个循环不能迭代地改进强模型，它就更像是在一个生成的提示分布上做间接蒸馏（indirect distillation），RSI 的味道不足。

工作流的设计空间巨大。我们自然会想到：工作流设计本身就是一个搜索问题，因此应该能通过算法找到好的解，而不只是靠手工设计。沿着这个方向，Automated Design of Agentic Systems（ADAS；Hu et al. 2025）把智能体设计本身形式化为一个优化问题——"元智能体搜索"（meta-agent search），由一个元智能体提出智能体工作流的新设计：

• 用简单的智能体（如 CoT、self-refine）初始化一个智能体工作流存档（archive）。
• 让一个元智能体受存档中现有解的启发，用代码编程出新的智能体。
• 元智能体首先生成新工作流的高层描述，然后用代码实现。
• 草稿程序经过两步 self-refine（即让模型提供反馈，再让同一个模型基于反馈改进之前的输出；Madaan et al. 2023）来检查其新颖性。
• 评估每个新候选，把成功的加回存档。
• 重复第 2-3 步，直到达到最大迭代次数。

FIG. 09 — ADAS

Automated Design of Agentic Systems（ADAS）示意图。（图片来源：Hu et al. 2025）

AFlow（Zhang et al. 2025）把智能体工作流表示为一个图：节点是调用 LLM 的动作，边是用代码实现的逻辑操作。工作流优化依赖蒙特卡洛树搜索（MCTS）：

• 用模板初始化树中的起始工作流 W₀。
• 用"分数 + 均匀探索"的软混合方式选择一个工作流节点。
• 让 LLM 基于其评估表现，产出该工作流的修改版（扩展节点）。
• 执行并评估新工作流。
• 如果在 N 轮预算内新工作流有改进，就把它加回树中。
• 重复第 2-5 步，直到 top-k 平均分趋于平稳或预算耗尽。

FIG. 10 — AFLOW OPTIMIZATION

AFlow 在工作流候选树上的优化过程。（图片来源：Zhang et al. 2025）

FIG. 11 — AFLOW EXPERIMENTS

AFlow 在 QA、代码和数学任务上的实验：相比人工设计的工作流和 ADAS 都有明显提升。（图片来源：Zhang et al. 2025）

上下文工程或工作流设计都只是 harness 的一部分。我们需要搜索整个设计空间，把上下文管理逻辑、工作流、权限以及许多其他 harness 组件放在一起优化。正如 Meta-Harness、ADAS 和 AFlow 这些工作所展示的：代码是定义程序和系统的通用语言。简单地说，harness 就是一段代码，它编程规定了提示词、工具调用、子代理、控制流、记忆和工作流逻辑如何协同工作。如果 LLM 能够优化执行智能体的那段代码，它就能触及比手写提示词大得多的设计空间。

STOP：优化"改进器"本身Self-Taught Optimizer, 2023

Self-Taught Optimizer（STOP；Zelikman et al. 2023）是递归脚手架改进（recursive scaffolding improvement）的早期例子之一。在 t=0 步，一个种子改进器（seed improver）I₀ 接收初始解 s、一个效用函数 u 和一个黑盒语言模型 M，返回改进后的解 s′，即 s′ = I(u, s; M)。STOP 的目标不是直接改进 s，而是改进改进器 I 本身。

首先，定义元效用（meta-utility）为一个给定改进器函数 I 在一组下游任务 𝒟 上的平均效用：

因为改进改进器函数本身就是一个优化问题，我们可以基于 Iₜ₋₁ 的元效用表现，递归地得到 I 的新版本：

FIG. 12 — STOP ALGORITHM

Self-Taught Optimizer（STOP）算法。（图片来源：Zelikman et al. 2023）

在他们的实验中，被改进后的改进器发现了各种策略：遗传算法、分解并改进各个部分、多臂提示老虎机（multi-armed prompt bandits）、模拟退火、改变温度、beam/tree search 等。这类似于 harness 工作流如何被表示成一个可优化的对象。

FIG. 13 — STRATEGIES DISCOVERED BY STOP

STOP 发现的自我改进策略示例。（图片来源：Zelikman et al. 2023）

更新能力 ≠ 收益能力Lin et al. 2026

Lin et al.（2026）更细致地研究了 harness 进化对模型能力的依赖。他们拆解出两条轴：① harness 更新能力（harness-updating）：产出有用的 harness 编辑的能力；② harness 收益能力（harness-benefit）：利用更新后的 harness 来更好地解决任务的能力。有趣的是，从 Qwen3.5-9B 到 Claude Opus 4.6，一系列不同尺寸、不同核心智能的模型在实验中表现出相似的 harness 更新能力——一个 9B 的 harness 提议者/进化器能写出与 Opus 程序同构的技能。而要最好地利用一个 harness，模型需要正确且及时地调用技能/工具，并擅长长周期的指令跟随。

FIG. 14 — UPDATE vs BENEFIT

主要结果：（A）从 Qwen2-32B 到 Opus 4.6，harness 更新能力基本持平；（B）harness 收益能力是非单调的，中档模型受益最大。（图片来源：Lin et al. 2026）

Self-Harness：提议-评估-接受Zhang et al. 2026

更近的工作 Self-Harness（Zhang et al. 2026）让 LLM 智能体通过一个"提议-评估-接受"（propose-evaluate-accept）循环来改进自己的 harness。这个循环有三个阶段：

• 弱点挖掘（Weakness mining）：把失败聚类成"验证器落地"（verifier-grounded）的失败模式。当前 harness hₜ 被用在任务上评估，收集执行轨迹供分析。注意：两次运行可能在错误日志表面上共享同一个验证器结果（比如都是超时、都缺产物），但因果机制却不同。因此需要一份信息丰富的失败记录——包含终端的验证器级原因、相关智能体行为的因果状态、以及轨迹所暴露的抽象智能体机制——才能揭示根本原因。
• Harness 提议（Harness proposal）：基于挖掘出的失败模式，提出有界（bounded）的 harness 编辑。同一个模型在 hₜ 下被调用作为提议者。模型得到一个有界的提议上下文：(1) 当前 harness 的可编辑面（editable surfaces）；(2) 来自评估系统的、验证器落地的失败模式；(3) 应该保留的通过行为记录；(4) 先前尝试过的编辑的摘要。编辑应当优先处理那些可解决（可寻址）的反复错误模式（而不是任务特异的难度）、并且能通过狭窄改动解决；编辑候选应当彼此不同、保持多样。
• 提议验证（Proposal validation）：验证并合并合格的编辑，生成新 harness hₜ₊₁。候选编辑在 held-in 数据 D_in（测试弱点是否被解决）和 held-out 数据 D_out（检查是否引入了其他未知问题）上做回归测试；只有两个都不回归的候选才被接受。被接受的候选合并更新为 hₜ₊₁，被拒绝的候选只记日志、不改动当前 harness。

FIG. 15 — SELF-HARNESS LOOP

Self-Harness 用"弱点挖掘 → 有界 harness 提议 → 验证"的循环来更新 harness。（图片来源：Zhang et al. 2026）

在 Terminal-Bench-2 上运行 MiniMax M2.5、Qwen3.5-35B-A3B 和 GLM-5 时，Self-Harness 学会了针对不同基础模型的不同弱点、模型专属的 harness 指令，并提升了 held-out 的通过率。

AHE：可观测性驱动的演进Agentic Harness Engineering, 2026

Agentic Harness Engineering（AHE；Lin et al. 2026）认为 harness 进化的瓶颈在于可观测性——当一个 rollout 失败时，我们需要知道是哪个组件该为此负责，而且每一次编辑都应该有证据支撑。该框架用三根可观测性支柱形成一个闭环：

• 组件可观测性（Component observability）：每个可编辑的 harness 组件在文件系统中都有对应表示，这样动作空间就是显式、可追踪的。一个 harness 包含 7 个组件：系统提示词、工具描述、工具实现、中间件、技能、子代理配置、长期记忆。每个失败模式都被映射到一个组件，编辑因此更有针对性。
• 经验可观测性（Experience observability）：把大量原始轨迹分析、总结成"证据 + 失败模式"的层次结构。每个 harness 生成 k 条轨迹；用一个智能体（"Agent debugger"）分析逐文件存储的轨迹，为每个任务生成根因分析报告（失败或成功的原因）；所有任务报告再聚合成一份基准总览供下一步使用，原始轨迹按需访问。这种分层访问结构更省 token。
• 决策可观测性（Decision observability）：每次编辑都配一个对下一轮的预测，用来验证。一个智能体（"Evolve agent"）读取仓库、决定编辑哪个组件，然后产出编辑及其背后的推理。每一个编辑都是文件级的、可证伪的声明，可以在下一轮被验证，并受两个约束：
  • (1) 编辑只作用于 harness 工作区；runs 目录、追踪器、验证器和 LLM 配置都是只读的——这禁掉了一整类 reward hacking（比如禁用验证器、偷换模型、抬高推理预算），从而保证每一个记录的增益都能归因于 harness 编辑本身。
  • (2) 编辑是证据驱动的，带一份"宣言"条目（manifesto entry）：失败证据的名称、推断出的根因、目标修复，以及预期影响（既包括预期修复，也包括有回归风险的项）。

在 Terminal-Bench-2 上，AHE 超过了人工设计的 harness（OpenCode、Terminus-2、Codex），除了 Hard 档和少数自进化基线（ACE、TF-GRPO）之外。同一个冻结的 harness 不再继续进化，直接迁移到 SWE-bench-verified 上仍有表现——这说明进化出的 harness 是把工程经验编码进了 harness 组件里，而不是在做针对基准的过拟合优化。

进化搜索是一种受自然选择启发的优化方法：通过变异（mutation）进化一群解，只保留适应度（fitness）高的个体。进化搜索在两种情况下很管用：① 搜索空间很大或形状怪异；② 难以用梯度直接优化、但很容易评估。Harness 搜索看起来非常契合。

进化搜索过去就被用在提示词工程上。Promptbreeder（Fernando et al. 2023）通过一套丰富的变异操作来优化任务专用提示词；有趣的是，变异提示词本身（即"让 LLM 变异任务提示词"的指令）也通过进化来改进。GEPA（Agrawal et al. 2025）把基于反思的提示（reflection-based prompting）与进化搜索结合起来，利用试错轨迹上的自然语言反思来提出提示词更新。

AlphaEvolve（Novikov et al. 2025）引入了一个编码智能体进化搜索系统：维护一个候选程序池，冻结 LLM、让它们生成改进的 diff。随着系统反复评估子程序、保留成功的，它会随着时间发现更好的解。

FIG. 16 — ALPHAEVOLVE

AlphaEvolve 的工作原理。（图片来源：Novikov et al. 2025）

AlphaEvolve 的设计里有几个细节很关键：

• 提示词包含父程序、结果、指令，有时还有元信息。
• 编码智能体可以访问整个仓库，但需要改进的代码区域被显式标记出来：# EVOLVE-BLOCK-START 和 # EVOLVE-BLOCK-END。
• 元提示词（meta-prompt）随指令和上下文一起共同进化（co-evolve），方式类似于我们进化解程序本身。

FIG. 17 — ALPHAEVOLVE ABLATIONS

消融实验展示了进化过程、提示词中的上下文、元提示词、全文件进化以及使用更强 LLM 的价值。（图片来源：Novikov et al. 2025）

近期的变体包括：ThetaEvolve（Wang et al. 2025）把进化搜索与强化学习和上下文学习结合；DemoEvolve（Che et al. 2026）用人类专家演示来增强自 rollout 存档，作为 harness 级诊断和编辑的参考经验；ShinkaEvolve（Lange et al. 2025）则引入三个新组件来提升 LLM 采样效率：

• 更省样本的探索：父代采样在设计时平衡"性能排名"与"后代数量"。
• 代码新颖性拒绝采样：基于嵌入余弦相似度，丢弃与现有群体过于相似的候选。
• 在元草稿本（meta-scratchpad）中识别成功解中的好模式，用来指导未来的变异。

与上述聚焦于解改进的方法不同，Darwin Gödel Machine（DGM；Zhang et al. 2025）明确针对"可编辑 harness 代码库"的进化：基于 LLM 的编码智能体被允许修改自己的 harness。后续工作 Hyperagents（Zhang et al. 2026）引入了一个元智能体，控制如何修改现有任务智能体来创造新智能体：

• 从池中的一个编码智能体开始。
• 每一轮，按"与性能成正比、与已有子代数成反比"的概率挑选一个父代，修改并分支产生新智能体。
• 被选中的父智能体检查自己的基准评估日志，然后对自己的 harness 代码库提出改进，生成编码智能体的新版本。代码编辑用两个基本工具实现：(1) bash（参数：bash 命令）和 (2) editor（参数：view/create/edit 文件路径）。
• 新编码智能体被评估，只有性能足够高的才被加回池中。
• 重复第 2-4 步，直到某个停止条件达成。

DGM 是在固定模型下的 harness 进化。以 Claude 3.5 Sonnet 为基础 LLM、配简单初始 harness 配置的实验里，DGM 发现的智能体在 SWE-bench Verified（20% → 50%）和 Polyglot（14.2% → 30.7%）上与手工智能体相当或更好。

这一族方法在"候选解可自动评估、适应度容易量化"时表现出色，例如矩阵乘法、GPU kernel 优化、算法竞赛、数据中心调度。它在评估缓慢、模糊或主要靠启发式的领域会吃瘪。进化的计算效率和有效性也是顾虑。

Harness 进化改变的是模型周围的非参数系统。要实现完整的自我改进，模型完全可以同时被允许更新自己的权重——权重更新可以通过改进模型训练管线、或在测试时做持续学习来实现。持续学习这个主题值得未来单独写一篇。

SIA（Hebbar et al. 2026）是把 harness 改进和模型参数更新放进同一个优化循环的早期尝试，设计上有三个组件：

• 元智能体（Meta-Agent）：提出初始 harness。
• 任务专用智能体（Task-Specific Agent）：执行任务。
• 反馈智能体（Feedback-Agent）：根据最近的轨迹，决定是更新 harness 还是更新模型权重。

FIG. 18 — SIA FEEDBACK AGENT

SIA 中的反馈智能体决定下一轮迭代的类型。（图片来源：Hebbar et al. 2026）

SIA 的实验中有几个混杂的选择让结果难以解读：例如任务专用智能体远弱于元智能体和反馈智能体所用的模型（gpt-oss-120b vs Claude Sonnet 4.6），基线也太弱，无法与相关方法干净地交叉对照。作者认为这个方向很有趣，但证据是暂定的。而且训练稳定性、古德哈特效应（Goodhart effect）等许多挑战仍然悬而未决。

Continual Harness（Karten et al. 2026）在长周期游戏场景中做了实验：一边更新 harness，一边通过"把强教师模型在低奖励轨迹上的标签蒸馏下来"来共同学习一个策略模型。

AI Scientist 这条工作线有力地证明：专家设计的 harness 能够协调自动研究循环的很大一部分（以写论文的形式被实验验证）。但论文生产不等于科学发现。一个系统能写出像样的稿件，同时仍然存在编造引用、实现漂移（implementation drift）、实验证据薄弱的问题。

Trehan & Chopra（2026）测试了 LLM 能否在极简脚手架和基础工具（即 read_file、write_file、llm_search、list_files）下从研究想法走到论文。每个想法都有一个专用工作区，智能体可以在其中生成和阅读文档（作为上下文的一部分）。他们在三个领域做实验（世界模型、多智能体强化学习、AI 安全与对齐），每个领域准备了 45-50 篇高质量种子文档来激发新想法。最终只有 4 个想法被人类专家选中跑完整管线，只有 1 个被完整执行成一篇论文。实验中观察到六个反复出现的失败模式：

在迈向完整 RSI 的道路上，研究者们取得了实实在在的进展，但仍有几个瓶颈：

参考文献References · 原文列表保留英文原样