刚刚，翁荔（Lilian Weng）又更新博客了！距离她上一次更新《谨慎对待 Scaling Law》还不到 10 天。要知道，之前她的博客已经断更了 13 个月。不知道这是否意味着她又要开始进入高产模式了？
这一次，她书写的主题是当前大热的 Harness Engineering，聚焦的正是当下 AI 研究最前沿一个环节：当模型本身的智能已经足够强大时，真正决定它能走多远的，或许是包裹在模型外面的那层「Harness」也就是负责编排模型思考、调用工具、管理上下文、评估结果的那套系统。
翁荔在文中系统梳理了从 ACE、Meta Context Engineering 到 Self-Harness、Darwin Gödel Machine 等一系列围绕「Harness 自我优化」展开的研究工作，并试图回答一个更根本的问题：递归式自我提升（RSI）究竟会先发生在模型权重层面，还是先发生在这层「脚手架」上？
文章的后半部分同样值得关注：翁荔坦率列出了当前自动化研究和自我提升系统面临的多个真实瓶颈，包括评估标准模糊、上下文与记忆的生命周期管理、负面结果被系统性忽视、多样性坍缩，以及绕不开的奖励作弊问题。这些既是研究者们正在攻克的难题，某种程度上也是这类系统距离真正「自我提升」还有多远的一份诚实清单。
我们借助 AI 智能体将这篇文章整理成了中文版，更多详情请参阅原博客。
文章标题：Harness Engineering for Self-Improvement
文章地址：https://lilianweng.github.io/posts/2026-07-04-harness/
目录
• Harness 设计模式
￮ 模式一：工作流自动化
￮ 模式二：将文件系统作为持久化记忆
￮ 模式三：子智能体与后台任务
￮ 案例研究：编程智能体的 Harness
￮ Harness 层与核心智能之争？
• Harness 优化
￮ 上下文工程
￮ 工作流设计
￮ 自我提升型 Harness
￮ 进化搜索
￮ 与模型权重的联合优化
• 未来的挑战
• 引用
• 附录：一些有用的基准测试
• 参考文献
递归式自我提升（recursive self-improvement，RSI）这一概念可以追溯到 I. J. Good（1965）。他把「超级智能机器」定义为一种能够在所有智力活动上超越人类、并能设计出更好的机器来提升自身的系统。Yudkowsky（2008）则用「递归式自我提升」这个说法来指代一种特定的反馈循环：AI 利用自己当下的智能，去改进产生这种智能的认知机制本身。
在现代 AI 中，这个反馈循环可能表现为模型直接改写自己的权重。但更广义地说，它也可以是模型去改进训练流程和部署系统，从而催生出一个在各类具有经济价值的任务上表现更好的后继模型。已有证据显示，前沿实验室的 AI 研究开发速度正在急剧加快（Anthropic；OpenAI）。
我之所以特意提到「部署系统」，是因为介于原始模型与真实世界场景之间的这一层，其重要性似乎不亚于模型本身的原始智能（也就是预训练刚结束时的那些评测结果）。Harness 正是 AI 部署中的重要组成部分，Claude Code 和 Codex 这类成功的编程智能体产品就是明证。Harness 指的是围绕基础模型搭建的系统，它负责编排执行流程，并决定模型如何思考和规划、如何调用工具并采取行动、如何感知和管理上下文、如何存储产物，以及如何评估结果。
这篇文章将聚焦于 Harness 工程方面的研究，以及它对 RSI 的贡献。近期关于自动化研究、自我提升型智能体和进化式程序搜索的许多工作，都可以围绕这个问题展开梳理。另外还有一些关于模型自我博弈、合成数据、测试时训练，以及更广义的持续学习方向的工作，同样契合 RSI 的愿景（例如 Yuan et al. 2024、Chen et al. 2024、Zhao et al. 2025、Choi et al. 2026），但这些不是本文的重点。
Harness 设计模式
相比于早期的智能体框架——「智能体 = LLM + 记忆 + 工具 + 规划 + 行动」，Harness 工程还额外包含了工作流设计（例如循环工程）、评估、权限控制和持久化状态管理。它已经不再只是提示词模板，而更接近运行时和软件系统设计：模型如何观察、如何行动、如何记忆、如何自我检查，以及如何自我提升。
这种设计应当刻意保持简单和通用，以便实现泛化，并且最好能参照已有的软件工程实践，从而受益于预训练阶段积累的知识。操作系统和 Harness 之间其实有一种很强的类比关系。就像操作系统一样，Harness 应当把复杂的逻辑封装起来，同时保持接口的简洁。与此同时，配置、工具接口以及其他协议也可能会逐渐在整个行业中走向标准化。
模式一：工作流自动化
设计一个让模型可以在其中运行、测试并迭代的工作流，是实现自动化的关键。Karpathy 的 autoresearch 仓库就是这样一种工作流构建方式的清晰范例。一种常见的工作流遵循目标导向的循环：规划、执行、观察/测试、改进，然后再次执行，直到达成目标为止。这个过程中也可能会触发模型主动向用户请求澄清，以明确任务规范或执行偏好。
一个简化版的 Codex 智能体循环：智能体调用工具，工具的返回结果会影响模型下一步的生成内容。（图片来源：OpenAI codex agent post）
这张工作流图也强调了一点：模型是通过一个「智能体运行时」，而不是一个静态的提示词模板，来分析自己的执行轨迹和失败案例，并据此迭代改进的。
模式二：将文件系统作为持久化记忆
在长时程的智能体系统中，一个反复出现的模式，是用简单的方式来管控丰富的状态和产物。Harness 不应该把整个工作流和所有日志都塞进上下文里，而是应该把持久化状态保存在文件中。在长时程的智能体运行过程中，诸如实验日志、代码 diff、论文摘要、错误追踪记录以及过往的运行轨迹这类产物，往往会远远超出模型训练时所适应的上下文窗口长度。
学会如何读取、写入和编辑文件系统（通常通过 bash 命令来实现），是 LLM 的一项基础技能。因此，以文件这种简单形式来管理持久化记忆，天然会随着核心模型能力的提升而受益。
模式三：子智能体与后台任务
一个 Harness 可以派生出多个子智能体来并行执行任务，并对后台任务进行监控。当主智能体需要同时搜索多个假设、并发运行多组实验，或是把某些孤立的子任务委托出去、又不想污染主上下文时，这种做法就很有用。这时主智能体就需要一个小型的进程管理器：负责启动任务、查看日志、取消失败的运行，并把结果合并回主智能体的会话线程中。
这里的关键设计选择，是让并行性变得显式且可检查。如果子智能体的输出只存在于短暂的对话上下文里，它们很快就会过时并变得难以追溯。但如果它们被保存为文件、日志和状态记录，模型就可以在中断之后恢复状态，并对自己的执行历史进行推理。
案例研究：编程智能体的 Harness
在 Claude Code、Codex、OpenCode 以及 Cursor 风格的智能体中，主流编程智能体的核心接口已经趋于稳定。它们通常都采用类似下面这样的循环：
借助一整套工具，编程智能体能够在给定的代码仓库中进行开发并调试问题，这与人类开发者配备 IDE 的方式颇为相似。
上表并非详尽列举，仅作演示之用。感兴趣可以阅读这篇文章：https://github.com/yasasbanukaofficial/claude-code
Harness 层与核心智能之争？
未来的 RSI 在多大程度上会依赖 Harness 工程，这一点很难预测。但可以确定的是，近期内 RSI 的路径不太可能一上来就是模型直接改写自己的权重。我对近期切实可行路径的预测是：
Harness 工程将朝着「元方法论」的方向演进（也就是改进「获得更好答案的机制本身」，而不只是改进答案本身）。Harness 系统本身会成为一个优化目标，启发式规则会越来越少，通用机制会越来越多。
反过来，成熟的 Harness 能够支撑起用于模型自我提升的自动化研究循环；而更聪明的模型也能防止 Harness 被过度工程化，从而让整个系统保持可持续性。
最终，很可能许多 Harness 层面的改进都会被内化为核心模型的行为，但与外部上下文和工具之间的接口应当会保留下来。我们其实已经在提示词工程身上见过一个更温和版本的这种模式：随着指令微调和模型推理能力的提升，人工设计的提示词技巧变得不再那么核心，但明确目标、约束、上下文和评估标准的需求并没有消失。
Harness 优化
Harness 系统中被优化的对象大致经历了这样的演进：指令提示词 → 结构化上下文 → 工作流 → Harness 代码 → 优化器代码。随着模型变得越来越智能、越来越强大，我们也在朝着更复杂的优化目标和更通用的方法迈进。
上下文工程
如果只是简单地把所有工具返回结果和模型生成内容一股脑塞进上下文，那么随着智能体任务时长的显著增加，上下文很快就会失控。上下文管理这一层，负责为 LLM 构建出更加结构化、更加简洁的上下文，并管理持久化状态。毫无疑问，长上下文方面的研究会持续取得进展，但就目前而言，长上下文智能与上下文工程有时是相互交织在一起的。
智能体上下文工程（Agentic Context Engineering，简称 ACE；Zhang et al. 2025）把上下文当作一本不断演化的「playbook」，而不是一段越写越长的提示词。它维护一个由多条要点组成的上下文 playbook，每条要点都有自己的标识符和描述，整个框架包含三个组成部分。
1. 生成器（Generator）：参照已有的要点，生成任务执行轨迹。
2. 反思器（Reflector）：从成功和失败的执行轨迹中提炼出洞见。
3. 策展器（Curator）：以增量、条目化的方式更新结构化上下文。
智能体上下文工程（ACE）的框架示意图。（图片来源：Zhang et al. 2025）
为了在迭代重写过程中防止上下文坍缩和「简短偏见」，ACE 的一个关键设计选择是：策展器并不会重写整段提示词。相反，它输出的是一组结构化的、条目化的要点，形式为（标识符，描述），这些要点会依据确定性的逻辑被合并进结构化的上下文日志中。这些上下文条目还会被定期精炼和去重。
ACE 能够从执行轨迹中学习洞见，这有助于我们朝着「自我管理的记忆」迈进，但它的更新规则和整体工作流仍然是人工设计的。为了朝着一个更加自我提升的循环迈进，元上下文工程（Meta Context Engineering，简称 MCE；Ye et al. 2026）把「机制」（如何管理上下文）与「产物内容」（上下文里具体是什么）分离开来，让技能演化发生在元优化层面，而上下文优化发生在基础层面。
一个 MCE 技能 s ∈ S 定义了一个上下文函数 c_s = (ρ_s, F_s)，将输入 x 映射为上下文 c = F_s(x; ρ_s)，其中：
ρ_s = {ρ_1, ..., ρ_m} 是静态组件（提示词、知识库、代码库）。
F_s = {F_1, ..., F_k} 是动态算子（搜索、筛选、过滤、格式化）。
这是一个双层优化问题：在给定技能 s 的前提下，先在训练数据上找到最优的上下文 
；外层循环则负责在验证集上寻找能带来最佳表现的最优技能 s*：
技能数据库会追踪历史上出现过的技能、上下文函数以及评估指标：
元层面的智能体会对已有的技能执行智能体化的交叉（crossover）操作，针对给定任务 τ 生成一个新的技能：
随后，基础层面的上下文工程智能体会执行这个技能 s_k，并在该技能的指导下，根据执行反馈 R_k 学习出对应的上下文函数：
元上下文工程（MCE）的框架示意图：元层面的技能演化在各种上下文管理机制之间进行搜索，而基础层面则负责优化具体任务的上下文。（图片来源：Ye et al. 2026）
MCE 并不像 ACE 那样强制规定一套上下文结构的启发式规则。它使用自由形式的技能来存储某项任务中最重要的知识，并将技能和「以技能为条件的上下文」一起迭代演化。在具体实现上，一个上下文函数 c 被实例化为专属目录下的一组文件，既包括静态部分（skill.md），也包括动态部分（上下文和数据执行轨迹）。元层面和基础层面的优化都是在具备标准工具集 
的智能体编程环境中执行的。
Meta-Harness（Lee et al. 2026）则更进一步：它优化的对象是决定「哪些信息应当被存储、检索并呈现给模型」的那段代码本身。它的名字里之所以有「Meta-」，就是因为这是一个用于优化 Harness 的 Harness。
Meta-Harness 的外层循环优化算法。（图片来源：Lee et al. 2026）
负责提出新 Harness 的提议者本身就是一个编程智能体，最终输出的是一批位于帕累托前沿上的 Harness 候选方案。
整个执行历史都可以通过文件系统访问，因此编程智能体会使用 grep 或 cat 之类的命令来查阅，而不是把所有东西都塞进单一的提示词上下文里。
每个被提出的 Harness 在文件系统中都对应一个目录，里面包含它自己的源代码、评分、执行轨迹以及状态更新记录。
Meta-Harness 循环会不断迭代创建新的 Harness，只有符合标准的才会被保留下来。
Meta-Harness 在（左）少量迭代下的文本分类任务和（右）TerminalBench-2 上的表现。需要注意的是，TerminalBench-2 实验中的搜索是从 Terminus-KIRA 和 Terminus-2 这两个非常强的 Harness 出发进行初始化的。（图片来源：Lee et al. 2026）
不过有一点很清楚：一旦 Harness 设计本身变成了一个可执行的搜索空间，一个足够强的编程智能体就能够利用起人类工程师所使用的那同一套设计空间。
工作流设计
Harness 工程中的工作流设计，可以由领域专家手工搭建。以自动化研究为例，学界已经提出并测试了多种框架。AI Scientist 系统（Lu et al. 2026）构建了一条完整的流水线，涵盖提出研究想法、编写代码、运行实验、分析结果、撰写论文稿件，直到执行同行评审的全过程。Meng et al.（2026）则在 ScientistOne 中把「可验证性」作为核心设计约束，要求每一条论断（无论是引用、数值、方法论还是结论）都必须能追溯到证据来源，并通过「证据链」检查来接受审核。
AI Scientist 流水线：涵盖想法生成、实验、论文写作和评审各个环节。（图片来源：Lu et al. 2026）
Autodata 智能体（Kulikov et al. 2026）的设计目标，是扮演一名负责生成训练和评估数据的数据科学家。主智能体管理着一个出题者（challenger）——负责提出问题；一个弱解题者（weak solver）；一个强解题者（strong solver）；以及一个验证者/评判者（verifier/judge），目标是合成出难度「恰到好处」的数据，也就是强解题者能够解决、而弱解题者却做不到的那种难度。
在 Autodata 中，出题者的提示词会根据解题者和验证者的反馈进行迭代更新。这里存在一个局限：合成出来的任务被用来微调弱解题者，却没有用来微调强解题者；如果这个循环无法迭代地改进强模型本身，那么它更像是在一个生成出来的提示词分布上做间接蒸馏，RSI 的意味就比较淡了。
Autodata 围绕出题者、解题者和验证者三种角色设计的智能体工作流，用于生成合成的训练和评估数据。（图片来源：Kulikov et al. 2026）
工作流的设计空间极其庞大，我们自然可以把工作流设计本身当作一个搜索问题来看待，因此理论上应当能够通过算法而非纯手工来找到好的方案。沿着这个方向，智能体系统自动化设计（Automated Design of Agentic Systems，简称 ADAS；Hu et al. 2025）把智能体设计本身表述为一个优化问题，也就是「元智能体搜索」：由一个元智能体来提出新的智能体工作流设计方案。
1. 用 CoT、自我修正（self-refine）之类的简单智能体，初始化一个智能体工作流的档案库。
2. 让元智能体在已有档案库方案的启发下，用代码编写出新的智能体。
元智能体首先生成新工作流的高层描述，然后再将其实现为代码。
生成的草案程序会经过元智能体的两轮自我修正（即先让模型对结果提供反馈，再让同一个模型根据反馈修正自己先前的输出；Madaan et al. 2023），以检查其新颖性。
3. 评估每一个新的候选方案，把成功的方案加回档案库。
4. 重复步骤 2 到 3，直到达到最大迭代次数。
智能体系统自动化设计（ADAS）示意图。（图片来源：Hu et al. 2025）
AFlow（Zhang et al. 2025）把一个智能体工作流表示为一张图：节点代表调用 LLM 的动作，边则用代码实现逻辑操作。它的工作流优化依赖于蒙特卡洛树搜索（MCTS）：
用一个模板在搜索树中初始化起始工作流。
依据评分与均匀探索的软性混合策略，选择树中的一个工作流节点。
让 LLM 根据该节点当前的评估表现，生成一个经过修改的新工作流，以此来扩展该节点。
执行并评估这个新工作流。
如果新工作流在预算轮数内表现出改进，就把它加回搜索树中。
重复步骤 2 到 5，直到排名靠前的平均分数趋于平稳，或达到预算上限为止。
AFlow 在一棵工作流候选方案树上的优化过程。（图片来源：Zhang et al. 2025）
在问答、代码和数学任务上的实验显示，AFlow 相较人工设计的工作流以及 ADAS 都有明显的提升。
AFlow 实验结果与人工方法及 ADAS 的对比。（图片来源：Zhang et al. 2025）
自我提升型 Harness
无论是上下文工程还是工作流设计，都只是 Harness 的一部分。我们需要在整个设计空间中进行搜索，把上下文管理逻辑、工作流、权限设置以及其他许多 Harness 组件放在一起联合优化。正如我们在 Meta-Harness、ADAS 和 AFlow 等工作中所见到的那样，✨代码✨是定义程序和系统的通用语言。简单来说，Harness 就是代码，它规定了提示词、工具调用、子智能体、控制流、记忆以及工作流逻辑之间该如何协同工作。如果一个 LLM 能够优化执行智能体所依赖的代码，那么它所能触及的设计空间，就会远大于手写提示词所能覆盖的范围。
自学习优化器（Self-Taught Optimizer，简称 STOP；Zelikman et al. 2023）是递归式脚手架改进的早期范例之一。在第 t=0 步的种子改进器 I_0，接收一个初始方案 s、一个效用函数 u，以及一个黑盒语言模型 M，并返回一个改进后的方案 s'，也就是 s' = I(u, s; M)——STOP 的目标不是直接去改进方案 s 本身，而是去改进这个改进器 I 自身。
首先，可以把「元效用」定义为某个改进器函数 I 在一系列下游任务 D 上的平均效用：
由于改进这个改进器函数本身就是一个优化问题，我们可以依据元效用衡量出的表现，递归地得到一个新版本的改进器 I_t，通过一次基于 I_(t-1) 的自我提升式更新来实现：
自学习优化器（STOP）的算法流程。（图片来源：Zelikman et al. 2023）
在 Zelikman et al.（2023）的实验中，经过改进的改进器发现了多种策略，包括遗传算法、任务分解与分部改进、多臂老虎机式的提示词选择、模拟退火、调节温度参数，以及集束/树搜索。这与 Harness 工作流可以被表示为一个可优化对象的思路是相通的。
STOP 发现的一些自我提升策略示例。（图片来源：Zelikman et al. 2023）
他们的研究结果中有一个值得警惕的现象：STOP 在使用 GPT-4 时，能够随着迭代提升下游任务的平均表现，但换成 GPT-3.5 和 Mixtral 这类较弱的模型时，效果反而变差了。这说明仅有递归结构是不够的：基础模型必须足够强，才有能力去改进这套机制本身。这也意味着，Harness 的改进能够让模型的部署效果更好，但智能本身依然是核心所在。
一项更近期的工作 Self-Harness（Zhang et al. 2026）依靠 LLM 智能体，通过「提议—评估—接受」的循环来改进自己的 Harness。
Self-Harness 使用「弱点挖掘、有边界的 Harness 提议、验证」这一循环来更新 Harness。（图片来源：Zhang et al. 2026）
Self-Harness 的循环分为三个阶段：
1. 弱点挖掘：将失败案例聚类，归纳为有验证依据的失败模式。
用当前 Harness h_t 在各项任务上进行评估，并收集执行轨迹以供分析。
需要注意的是，两次运行在错误日志的表层上可能得到同样的验证结果（比如都是超时或产物缺失），但背后的因果机制却可能完全不同。因此我们需要记录信息丰富的失败记录，其中包含终端验证层面的直接原因、相关智能体行为的因果状态，以及执行轨迹所暴露出的抽象智能体机制，以此来揭示真正的根本原因。
2. Harness 提议：基于挖掘出的失败模式，提出有边界限制的 Harness 修改方案。
由同一个模型在 h_t 之下被调用，充当提议者。
提供给该模型的提议上下文是有边界的，包括：（1）当前 Harness 中可编辑的部分；（2）来自评估系统、有验证依据的失败模式；（3）应当被保留的、已通过验证的行为记录；以及（4）此前尝试过的修改方案摘要。
Harness 的修改应当优先针对那些反复出现、且可以被解决的错误模式（例如排除掉那些只是任务本身难度较大的情况），并且能够通过局部、有限的改动来解决。
提出的 Harness 修改候选方案彼此之间应当各不相同、足够多样化。
3. 提议验证：验证并合并合格的修改方案，生成新的 Harness h_(t+1)。
候选修改方案会在 held-in 数据集 D_in（用于检验该弱点是否已被解决）和 held-out 数据集 D_out（用于检查是否引入了其他未知问题）上，通过回归测试进行评估。
只有在 held-in 和 held-out 数据上都没有出现回归的候选方案，才会被接受。
被接受的候选方案会被合并，用以更新 Harness；被拒绝的候选方案则会被记录下来，但不会改变当前正在使用的 Harness h_t。
在 MiniMax M2.5、Qwen3.5-35B-A3B 和 GLM-5 上运行 Terminal-Bench-2 的实验表明，Self-Harness 能够学习到针对不同基础模型、不同弱点的、具有模型特异性的 Harness 指令，并提升 held-out 测试集上的通过率。
Self-Harness 这一类工作确实让我担心：如果允许一个程序去编辑操作系统层面的内容，抽象边界就会被打破。可编辑的范围需要被恰当地设计，权限控制和安全层也需要独立存在于这个循环之外。围绕 reward hacking（奖励作弊）的所有挑战，依然存在。
进化搜索
进化搜索是一种受自然选择启发的优化方法（可参考我之前关于进化算法的旧文）。它通过对一群解进行变异，并只保留其中「适应度」较高的个体，来演化整个解的种群。当（1）搜索空间极大或形状怪异；以及（2）很难直接用梯度优化、但很容易评估解的好坏时，进化搜索就会派上用场。Harness 搜索似乎正好契合这两个条件。
进化搜索此前也曾被用在提示词工程中。Promptbreeder（Fernando et al. 2023）通过一整套丰富的变异操作来优化特定任务的提示词，有意思的是，这些「变异提示词」本身（也就是指导 LLM 如何变异任务提示词的指令）也在通过进化被不断改进。GEPA（Agrawal et al. 2025）将基于反思的提示与进化搜索结合起来，利用对试错轨迹的自然语言反思来提出提示词更新方案。
Novikov et al.（2025）提出了 AlphaEvolve，作为一套面向编程智能体的进化搜索系统，它维护一个候选程序池，并提示（保持权重冻结的）LLM 生成用于改进的 diff。随着系统不断评估子代程序并保留其中成功的部分，它会逐渐发现更好的解决方案。
AlphaEvolve 的工作原理。（图片来源：Novikov et al. 2025）
AlphaEvolve 的设计中有几个值得关注的细节：
提示词中包含父代程序、结果、指令，有时还包括元信息。
编程智能体可以访问整个代码仓库，但需要改进的代码区域会用# EVOLVE-BLOCK-START 和# EVOLVE-BLOCK-END 明确标注出来。
元提示词会和 LLM 建议的指令与上下文一起共同演化，方式与解程序的演化过程类似。
消融实验展示了进化流程本身、提示词中的上下文、元提示词、全文件级别的进化，以及使用更强 LLM 各自的价值。
消融实验展示了 AlphaEvolve 中多项设计各自的价值。（图片来源：Novikov et al. 2025）
近期的一些变体，比如 ThetaEvolve（Wang et al. 2025），将进化搜索与强化学习及上下文学习结合了起来。而 ShinkaEvolve（Lange et al. 2025）则引入了三个新组件，用于提升 LLM 采样效率：
通过设计父代采样策略，在表现排名和子代数量之间取得平衡，实现更高样本效率的探索。
基于 embedding 的余弦相似度，对与现有种群过于相似的候选方案进行「代码新颖性拒绝采样」，将其剔除。
在一个「元便签本」中识别成功方案中的良好模式，用以指导后续的变异方向。
与上述这些专注于「解方案」改进的方法不同，达尔文哥德尔机（Darwin Gödel Machine，简称 DGM；Zhang et al. 2025）明确以「一个可编辑的 Harness 代码仓库」的进化为目标，由一个基于 LLM 的编程智能体来完成。准确地说，这个智能体被允许修改自己的 Harness。一项后续工作 Hyperagents（Zhang et al. 2026）则引入了一个元智能体，负责控制如何修改现有的任务智能体、以创造出新的智能体。
从智能体池中的一个编程智能体开始。
在每一轮迭代中，按照与其表现成正比、与其子代数量成反比的概率，选出一个父代，对其进行修改并分支，从而产生新的智能体。
被选中的父代智能体会检查自己的基准评估日志，随后针对自己的 Harness 代码库提出改进方案，从而生成一个新版本的编程智能体。代码编辑通过两个基础工具来实现：（1）bash（参数：
对新产生的编程智能体进行评估，只有那些表现足够优秀的才会被重新加入智能体池。
重复步骤 2 到 4，直到达到某个停止条件为止。
DGM 是在固定模型条件下进行的 Harness 进化。在以 Claude 3.5 Sonnet 作为基础 LLM、并搭配简单的初始 Harness 配置的实验中，DGM 发现的智能体在 SWE-bench Verified（从 20%提升到 50%）和 Polyglot（从 14.2%提升到 30.7%）上，其表现可以与手工设计的智能体相当，甚至更胜一筹。
这一类方法在候选方案可以被自动评估、且候选方案的适应度容易被量化的领域中效果很好，比如矩阵乘法、GPU 内核优化、算法竞赛、数据中心调度等。但在那些评估过程缓慢、模糊，或者主要依赖启发式判断的领域中，它就会遇到困难。进化过程的计算效率和有效性，也依然是需要关注的问题。
与模型权重的联合优化
Harness 的演化改变的是模型周围那套非参数化的系统。要实现完全意义上的自我提升，也可以完全允许模型同时更新自己的权重。这种权重更新既可以通过改进模型训练流程来实现，也可以通过测试时的持续学习来实现。持续学习这个话题本身，值得未来单独写一篇文章来讨论。
SIA（Hebbar et al. 2026）是较早尝试将 Harness 改进与模型参数更新纳入同一个优化循环中的工作，其设计包含三个组成部分：
元智能体（Meta-Agent）：提出初始的 Harness。
任务专属智能体（Task-Specific Agent）：执行具体任务。
反馈智能体（Feedback-Agent）：根据近期的执行轨迹，决定应该更新 Harness 还是更新模型权重。
SIA 中的反馈智能体（Feedback-Agent）负责决定下一轮迭代的类型。（图片来源：Hebbar et al. 2026）
SIA 的实验设计中存在一些令人困惑、使结果难以解读的选择。举例来说，任务专属智能体所使用的模型（gpt-oss-120b）要比元智能体和反馈智能体所使用的模型（Claude Sonnet 4.6）弱得多，而且基线设置也偏弱，难以与相关方法进行干净的横向比较。我认为这个方向本身很有意思，但目前的证据还只能算是初步的。此外，诸如训练稳定性和古德哈特效应（Goodhart effect）之类的诸多挑战，也仍然是悬而未决的问题。
未来的挑战
AI Scientist 这一系列工作有力地证明了：一个由专家设计的 Harness，可以协调完成自动化研究循环中的相当一部分内容，并已经在撰写研究论文这种形式上得到了实验验证。但「产出论文」并不等同于「科学发现」本身。一个系统完全可能写出一篇看起来言之成理的稿件，但其中却夹杂着编造的引用、实现层面的偏差，或是站不住脚的实验结果。
Trehan & Chopra（2026）测试了 LLM 能否在极简的脚手架和基础工具（即 read_file、write_file、llm_search、list_files）支持下，从一个研究想法一路走到一篇论文。每个想法都配有一个专属的工作空间，供智能体在其中生成和读取文档，作为上下文的一部分。他们在三个领域（世界模型、多智能体强化学习、AI 安全与对齐）中进行了实验，每个领域都包含 45 到 50 篇高质量的种子文献，用以启发新的研究想法。最终只有四个想法被人类专家选中、进入完整流水线，而其中只有一个被完整执行成了一篇论文。他们在实验中观察到了六种反复出现的失败模式：
对训练数据默认设定的偏向：使用陈旧的库、过时的命令、标准化的格式，或是一些并未真正立足于实际代码仓库或数据集的假设。
执行压力下的实现偏移：当实现方案在技术上变得复杂时，模型可能会转向一种更常见、更简单的方案，而不是坚持最初提出的方法。
记忆和上下文退化：如果没有把日志作为持久化产物写下来，长时程项目就会丢失关键细节。
过度乐观：即便实验结果嘈杂或失败，模型也会宣称成功。Bubeck 等（2025）也观察到过类似的「p-hacking 式的灵光乍现」模式，即模型会引入「数字胶布」，在信号本质上仍是噪声时就宣布获胜。
领域智能不足：模型缺乏必要的默会性专业知识，比如预判实现的复杂程度、判断某个实验结果是否合理，或者知道哪些基线才是真正重要的。
科学品味不足：实验本身或许可以执行，但却未能回答真正应该回答的问题。
在通向完全 RSI 的道路上，研究者们确实取得了实实在在的进展，但仍有若干瓶颈存在。
一、弱且模糊的评估者。 许多研究层面的论断都缺乏一个快速而精确的验证器，很多现实世界的任务也同样如此。目前的自我提升循环，在评估指标可测量、且客观的任务上效果最好，这与强化学习的工作原理颇为类似。
研究品味、新颖性以及长期的科学价值，则要难以衡量得多。举例来说，研究品味往往融合了问题的框定方式、实验设计，以及判断哪些出人意料的结果值得深入追究、哪些失败案例值得重试等诸多考量。
二、上下文与记忆的生命周期。 随着 AI 智能体变得越来越自主、越来越独立，记忆也在不断增长。一个真正有用的 Harness 需要管理好上下文和记忆，去弥补现有长上下文生成能力的局限，同时还要尽量提高长时程任务的成功率。既然人类能够在一生中维持记忆，我觉得这里有一个值得类比的地方：上下文工程将会、也应该成为智能本身的核心组成部分，而不是继续停留在软件系统这一层。
三、负面结果。 研究者往往有动机去发表成功的结果，因此文献本身就带有偏向成功的偏差。LLM 是在海量数据（至少目前来说，大多还是由人类创造的，哈）上训练出来的，它们可能不太擅长判断何时应该放弃某个假设、报告一个负面结果，甚至坦然承认一次失败——这正是因为数据中成功与失败案例本身就存在不平衡。一个好的研究 Harness 应当让失败的尝试也容易被保存下来，因为从失败中学习，正是缩小任务搜索空间最有效的方式。
四、多样性坍缩。 进化式和强化学习式的循环，往往倾向于利用那些已知的高回报模式。我们需要一些机制，来防止整个种群坍缩成同一个解的各种变体。这一点对于开放式研究尤其关键，因为在这种场景下，最优路径在当前评估者眼中，一开始很可能看起来反而是比较差的。
五、奖励作弊（Reward hacking）。 自我提升循环会优化任何交给它的信号。如果奖励来自单元测试，智能体就可能对测试本身产生过拟合；如果奖励来自一个评判模型，它就可能学会针对这个评判模型的特定作弊技巧；如果奖励来自基准测试分数，它就可能利用基准测试本身的漏洞。
评估者和权限控制或许都应当被放置在演化 Harness 的循环之外，并辅以 held-out 测试、执行轨迹审计，以及在关键决策点上的人工审查——至于这种监督能在多大程度上被规模化、被自动化，仍然是一个开放的研究方向。
六、长期成功。 一个「外在」的优化循环，作用于个体执行轨迹之外的、我们无法在训练沙盒中模拟出来的那些奖励信号上。
以编程智能体为例。编程智能体已经切实提升了软件工程领域的日常生产力，但许多优化目标依然过于短视。它往往能完成手头的具体任务，但如何在此基础上，维护好一个由成百上千名工程师共同维护的代码仓库的长期健康状况，就没那么直观了。标准的基于沙盒的 RLVR 式训练，很少能够捕捉到可维护性、职责边界、迁移成本、向后兼容性，或未来调试负担这些方面的问题。
七、人类的角色。 人类应当在整个技术栈中向上移动，而不是被排除在循环之外，也就是说，人类应当在恰当的时机、以恰当的抽象层级提供监督，而我们的系统设计也应当考虑何时、以何种方式来设置这样的接触点。
上面列出的许多挑战，都需要人类的反馈与引导。毕竟，我们所构建的这项技术，是为了让人类拥有更美好的未来，而不是反过来。
附录：一些有用的基准测试
PaperBench：从零开始复现 20 篇 ICML 2024 Spotlight 和 Oral 论文，任务涵盖理解论文贡献、开发对应代码库，以及成功执行实验。
每个复现任务都被拆解为更小的、可单独打分的子任务。
总计 8316 条评分细则，由论文作者共同参与制定。
当时表现最好的模型（Claude 3.5 Sonnet，约 21%）也未能超越机器学习博士的水平。
包含 PaperBench 本身、PaperBench Code-Dev（一个更轻量的版本），以及 JudgeEval。
CORE-Bench：评估已发表研究成果的计算可复现性。
基于计算机科学、社会科学和医学领域的 90 篇科学论文，设计了 270 项任务。
任务要求根据提供的代码和数据复现相应结果。
包含多个难度等级，既有纯语言任务，也有视觉-语言任务。
当时表现最好的智能体（GPT-4o 和 GPT-4o-mini）在最难任务上的准确率仅为 21%。
ScienceAgentBench：评估 LLM 智能体在数据驱动型科学发现中的表现。
从数学、化学、生物、地理四个学科的 44 篇同行评审出版物中，提取出 102 项任务。
覆盖这些领域中基础的数据科学任务：数据处理、模型开发、数据分析和信息可视化。
RE-Bench：在真实的机器学习研究工程环境中，将前沿 AI 智能体与人类专家进行对照评估。
包含 7 个具有挑战性的、开放式的机器学习研究工程环境。
每个环境由（评分函数、初始方案、参考方案）构成，且每个环境都可以在 8 块或更少的 H100 GPU 上运行。
示例任务包括：优化一个内核、运行一次 scaling-law 实验、修复一个 embedding、为问答任务微调 GPT-2 等。
数据来自 61 位不同人类专家共计 71 次、每次 8 小时的尝试。
在这些 8 小时的尝试中，人类专家有 82%都取得了非零分数；其中 24%达到或超过了强参考方案的水平。
在 2 小时的预算下，最好的 AI 智能体得分是人类的 4 倍；但人类随着时间预算增加、回报也更高，在 8 小时和 32 小时的设置下最终反超了智能体。
MLE-bench：在离线的 Kaggle 竞赛环境中评估机器学习工程类智能体。
包含 75 个从 Kaggle 精选出来的机器学习工程竞赛。
测试内容包括训练模型、准备数据集、运行实验，以及向评分脚本提交预测结果。
以 Kaggle 公开排行榜作为人类基线。
论文中表现最好的方案——搭配 AIDE 脚手架的 o1-preview——在 16.9%的竞赛中达到了至少 Kaggle 铜牌的水平。
还包含了关于资源规模扩展和数据污染的分析。
KernelBench：评估生成的 GPU 内核在正确性和速度上的表现。
包含 250 个 PyTorch 任务，用以评估 LLM 能否写出既快又正确的内核代码。
评估指标 fast_p，指的是生成的内核中「既正确、又比基线更快」的比例。
