Lilian Weng 综述 Harness 工程:大语言模型走向自我改进的关键架构与挑战
Harness Engineering for Self-Improvement
Lilian Weng 发布长文系统梳理面向递归自我改进的 Harness 工程,指出近期自我提升的实用路径并非直接重写模型权重,而是将基座模型外层的运行时调度系统(Harness)作为代码级优化目标。
系统梳理了智能体运行时系统从手工搭建向程序化自演化的架构演进,有助于读者理解外层工程如何决定长程任务落地。
递归自我改进(recursive self-improvement, RSI)的概念最早可以追溯到 I. J. Good (1965)。他在文中将“超智能机器”定义为一种不仅在所有智力活动上都能超越人类,还能设计出更优秀机器以改进自身的系统。Yudkowsky (2008) 则用“递归自我改进”来指代一种特定的反馈回路:AI 利用当下的智能,去改进产生该智能的认知机制本身。
在现代 AI 中,这种反馈回路既可以指模型直接重写自身权重,也可以广义地指模型优化训练管线与部署系统,从而迭代出在各种高经济价值任务上表现更佳的后续模型。在前沿实验室(如 Anthropic、OpenAI)中,AI 研发的迭代速度已经呈现出急剧加快的态势。
我之所以特别强调“部署系统”,是因为夹在原始模型与真实应用场景之间的这一层,其重要性丝毫不亚于模型的原始智能水平(即刚完成预训练时的评测表现)。从 Claude Code 和 Codex 等成熟的代码智能体产品中可以看出,Harness 是 AI 部署的核心组件。所谓 harness,是指包裹在基础模型外部的支撑系统,负责统筹整个执行流程,并决定模型如何思考规划、调用工具与行动、感知并管理上下文、存储产物以及评估输出结果。
这篇文章将重点探讨 Harness 工程相关的研究,以及它对 RSI 的推动作用。近期关于自动科研(auto-research)、自改进智能体(self-improving agents)和演化程序搜索的大量工作,都可以围绕这一问题展开梳理。此外,模型自博弈(self-play)、合成数据、测试时训练(test-time training)以及更宽泛的持续学习研究,同样契合 RSI 的构想(例如 Yuan et al. 2024、Chen et al. 2024、Zhao et al. 2025、Choi et al. 2026),但它们并非本文的讨论重点。
Harness 设计模式
与早期智能体框架所定义的“智能体 = 大语言模型 + 记忆 + 工具 + 规划 + 行动”相比,Harness 工程额外涵盖了工作流设计(如循环工程)、评估机制、权限控制以及持久化状态管理。它不再局限于提示词模板,而是更接近运行时环境与软件系统的系统化设计,关乎模型如何观察、行动、记忆、自检以及自我提升。
为了保证泛化能力,其设计应当保持克制,力求简单通用,并借鉴既有的软件工程实践,以充分利用模型在预训练阶段掌握的先验知识。操作系统与 Harness 之间也存在极强的相似性:与操作系统类似,Harness 应当将复杂的底层逻辑封装起来,对外保持简洁的接口。与此同时,配置规范、工具接口等协议也有望在整个行业内逐步走向标准化。
模式一:工作流自动化
为模型设计一套能够自主运行、测试并迭代的工作流,是实现自动化的核心。Karpathy 的 autoresearch 项目(https://github.com/karpathy/autoresearch)生动展示了这种工作流的构建方式。一种常见的工作流遵循以目标为导向的闭环机制:规划、执行、观察/测试、改进,随后再次执行,直至目标达成。在此过程中,系统还可能主动向用户提问,以澄清任务细节或明确执行偏好。
(图片来源:OpenAI 关于 Codex 智能体的博文)
该工作流图还强调,模型会自主分析过往执行轨迹和失败案例,并通过“智能体运行时”不断迭代演进,而非仅仅依赖静态的提示词模板。
模式二:以文件系统充当持久化内存
在长流程智能体系统中,一个屡试不爽的设计模式是用简单的控制逻辑去管理丰富的状态与中间产物。测试框架不该把整个工作流和所有日志都硬塞进上下文,而是应该将持久状态写入文件。在长流程的智能体推进过程中,实验日志、代码差异、论文摘要、错误堆栈和历史执行轨迹等产物,其体量往往远超模型训练时所能容纳的上下文窗口极限。
学会如何读写和编辑文件系统(通常通过 bash 命令实现)已成为大语言模型的基础能力;因此,直接用文件这种简单形态来管理持久化内存,能自然而然地享受到核心模型能力提升带来的红利。
模式三:子智能体与后台作业
测试框架可以派生出多个并行执行的子智能体,并负责监控后台作业。当主智能体需要同时探索多个假设、并行跑实验,或者要在不污染主上下文的前提下指派隔离的子任务时,这一模式非常实用。此时,父智能体只需充当一个微型进程管理器:负责启动作业、查看日志、中止失败的运行,并将产出结果合并回主智能体线程即可。
这里核心的设计抉择在于:并行过程必须做到显式化、可被检查。如果子智能体的输出仅停留在临时对话的上下文里,很快就会过时并被淹没;但如果把它们存为文件、日志和状态记录,模型即便中途被打断也能顺利恢复,并能对自己的执行历史进行回溯与推理。
案例分析:编程智能体测试框架
从 Claude Code、Codex、OpenCode 到类 Cursor 智能体,主流编程智能体的核心交互界面已基本趋于定型。它们通常采用如下循环:
正如人类开发者离不开 IDE 一样,编程智能体在接入一系列工具后,同样能在指定的代码库中进行开发和排错。
(清单仅供示意,并非完整列举。感兴趣可参阅此文。)
| 分类 | 工具定义 |
|---|---|
| 文件系统 | - 文件检索:glob、grep、ls- 文件读取: read、read_many- 文件修改: write(创建全新文件);edit(字符串精确匹配替换);multi_edit;apply_patch(应用结构化补丁/diff) |
| Shell 执行 | 运行命令:bash、PowerShell |
| IO | lsp,以及像 git_status、git_diff、git_commit 等 Git 工具 |
| 外部上下文 | MCP 工具、Skills |
| 网络搜索 | web_search、web_fetch、浏览器工具 |
| 生成产物 | 阅读文档、查看图片;生成 HTML、图片 |
| 后台进程 | 例如:CronCreate、CronDelete、CronList |
| 智能体任务分派 | 例如:spawn_agent、resume_agent、wait_agent、list_agents、close_agent、interrupt_agent 等 |
测试框架层 vs 核心智能?
未来的 RSI(递归自我改进)究竟会在多大程度上倚重测试框架工程,目前还很难预料;但近期来看,RSI 绝不可能一开始就走通“模型直接改写自身权重”这条路。我认为更务实的近期演进路径是:
- 测试框架工程将向“元方法论”方向演进——即不仅要提升答案本身的质量,更要改进“获取更优答案的运转机制”。测试框架系统本身会演变成优化目标,其中的启发式规则将逐渐减少,取而代之的是更通用的机制。
- 反过来,日趋成熟的测试框架能支撑起自动化研究,推动模型进入自我改进的良性循环;而更聪明的模型又可以防止测试框架陷入过度工程化,让整套系统得以健康、可持续地演进。
长远来看,外围运行环境(harness)的诸多优化很可能会被内化为模型的核心行为,但连接外部上下文与工具的接口仍将长期存在。类似的发展轨迹在提示词工程中已经出现过:随着指令微调和模型推理能力的提升,人工编写提示词的各种技巧逐渐退居次席,但明确目标、限制条件、上下文信息与评估标准的需求从未消失。
运行环境优化
在运行环境系统中,优化对象的演化路径大致是:指令提示词 → 结构化上下文 → 工作流 → 运行环境代码 → 优化器代码。随着模型越来越聪明、能力越来越强,我们优化的目标也愈发复杂,所采用的方法也更趋通用。
上下文工程
随着智能体任务周期的拉长,如果只是把工具的所有返回结果和模型的生成内容一股脑塞进上下文,内容量很快就会失控。上下文管理充当了一个关键层,专门负责为大语言模型构建更结构化、更精简的上下文,并维护持久状态。尽管长上下文技术的研究势必会持续突破,但在现阶段,长上下文智能与上下文工程往往依然密不可分。
智能体上下文工程(Agentic Context Engineering,简称 ACE;Zhang 等,2025)将上下文视为一份动态演进的“操作手册”,而非一段不断变长的前置提示词。它通过三个组件来维护这份由多个要点构成的上下文手册,每个要点都包含标识符和描述:
- 生成器(Generator):参考手册中的要点,生成任务执行轨迹。
- 反思器(Reflector):从成功和失败的轨迹中提炼经验。
- 整理器(Curator):通过增量添加要点条目,持续更新结构化上下文。
为了避免在多次迭代重写过程中出现上下文崩溃和简略偏差,ACE 的一项关键设计是:整理器绝不会重写整段提示词文本,而是以(标识符,描述)的形式输出一组结构化、条目化的要点;随后,系统通过确定性逻辑把这些要点合并到结构化的上下文日志中,并定期对上下文条目进行提炼与去重。
ACE 能从执行轨迹中汲取经验,这让我们向“自我管理记忆”迈进了一步,但其更新规则和整体工作流仍需人工设计。为了实现更彻底的自我迭代循环,元上下文工程(Meta Context Engineering,简称 MCE;Ye 等,2026)将“管理机制”(如何管理上下文)与“产物内容”(上下文里包含什么)拆分开来,在元优化层推进技能演进,在基础层执行上下文优化。
在 MCE 中,一项技能 $s \in \mathcal{S}$ 定义了一个上下文函数 $c_s=(\rho_s,F_s)$,将输入 $x$ 映射为上下文 $c = F_s(x;\rho_s)$,其中:
- $\rho_s = \{\rho_1,\dots,\rho_m\}$ 为静态组件(包括提示词、知识库、代码库等)。
- $F_s = \{F_1,\dots,F_k\}$ 为动态操作符(涵盖搜索、选择、过滤、格式化等操作)。
这一双层优化的内层任务是:在训练数据上,针对给定技能 $s$ 寻找最优上下文 $c_s^*$;外层循环则是在验证集上寻找能够带来最佳表现的最优技能:
$$ \text{内层:}c_s^*=\arg\max_{c_s}J_\text{train}(c_s;s)\quad \text{外层:}s^*=\arg\max_{s\in\mathcal{S}}J_\text{val}(c_s^*) $$
技能数据库记录了以往技能、上下文函数及评估指标的历史记录:$\mathcal{H}_{k-1} = \{(s_i,c_i,J_i^\text{train}, J_i^\text{val})\}_{i=1}^{k-1}$。面对给定的任务 $\tau$,元级智能体会对以往技能执行智能体式的交叉操作,从而生成新技能:$s_k=\text{crossover}(\tau,\mathcal{H}_{k-1})$。
随后,基础级上下文工程模块会执行该技能 $s_k$,并在当前技能的指导下,结合运行反馈 $\mathcal{R}_k$ 学习上下文函数:$c_k=\text{engineer}(\tau,s_k;c_{k-1}^*,\mathcal{R}_k)$。
与 ACE 不同,MCE 不会强制使用启发式规则来组织上下文。它通过自由格式技能来存储任务最核心的知识,并推动技能与依赖该技能的上下文共同迭代演化。在实现层面,上下文函数 $c$ 在专用目录中被实例化为一组文件,既包含静态部分(skill.md),也包含动态部分(上下文与数据运行轨迹)。元级和基础级的优化都是在配备标准工具集的智能体编程环境中执行的,
$$ \mathcal{T}=\{\texttt{Read},\texttt{Write},\texttt{Edit},\texttt{Bash},\texttt{Glob},\texttt{Grep},\texttt{TodoWrite}\} $$
Meta-Harness(Lee et al. 2026)则更深入了一层:它的优化对象,正是决定并优化“该存储、检索哪些信息并呈现给模型”的代码本身。名字里的“Meta-”意味着它是一个用于优化 harness 的 harness。
用于生成新 harness 的提议器本身就是一个编程智能体,最终输出的是位于帕累托前沿的一组候选 harness。
- 完整的执行历史都可以通过文件系统访问,因此编程智能体可以使用
grep或cat等命令来查阅历史,而不必把所有内容一股脑全塞进单个提示词上下文中。 - 提议生成的 harness 在文件系统中表现为一个目录,里面包含它自身的源代码、评分、运行轨迹以及状态更新。
- Meta-Harness 循环不断迭代生成新的 harness,并且只保留合格的候选方案。
不过,其中最重要的启示十分明确:一旦 harness 设计变成了可执行的搜索空间,强大的编程智能体就能充分利用与人类工程师相同的设计空间。
工作流设计
在 harness 工程中,工作流设计可以由领域专家手工完成。以自动化科研(auto-research)为例,业界已经提出并测试了多种框架。AI Scientist 系统(Lu et al. 2026)搭建了一套流水线,涵盖提出研究构想、编写代码、运行实验、分析结果、撰写论文以及进行同行评审的全流程。Meng et al. (2026) 则在 ScientistOne 中把“可验证性”作为核心设计约束,要求每项主张(包括引用、数据、方法和结论)都必须追溯至证据源,并通过证据链(Chain-of-Evidence)检查进行审计。
Autodata 智能体(Kulikov et al. 2026)旨在充当数据科学家,用于生成训练与评估数据。主智能体统筹调度负责出题的挑战者(challenger)、弱求解器(weak solver)、强求解器(strong solver)以及验证器/裁判(verifier/judge),目标是合成出难度“恰到好处”的数据——即强求解器能够做对、而弱求解器会做错的数据。
在 Autodata 中,挑战者的提示词会根据求解器和验证器的反馈进行迭代更新。不过这种方法存在局限:合成的任务仅用于微调弱求解器,而未用于提升强求解器。如果该闭环无法迭代提升强模型的能力,它就更像是在生成的提示词分布上进行间接蒸馏,缺乏了递归自我提升(RSI)的味道。
工作流的设计空间极其庞大,我们自然可以将其视为一个搜索问题,进而借助算法找出优质方案,而不仅靠人工设计。沿着这一方向,智能体系统自动设计(Automated Design of Agentic Systems,简称 ADAS;Hu et al. 2025)将智能体设计本身建模为一个优化问题,即通过“元智能体搜索”(meta-agent search),由元智能体提出全新的智能体工作流设计方案。
- 用 CoT、self-refine 等简单智能体初始化智能体工作流档案库。
- Ask a meta-agent to program new agents, all in code, inspired by existing solutions in the archive.
- 元智能体先生成新工作流的高层描述,随后将其用代码实现。
- 随后,该程序草稿会由元智能体进行两轮自我迭代(self-refine,即让模型提供反馈,再让同一模型根据反馈完善之前生成的内容;Madaan et al. 2023),以校验其新颖性。
- 评估每个新的候选方案,并将达标方案存回档案库。
- 重复步骤 2 至 3,直至达到最大迭代次数。
(图片来源:Hu et al. 2025)
AFlow(Zhang et al. 2025)将智能体工作流表示为一张图,其中节点代表调用 LLM 的动作,边则通过代码实现逻辑运算。其工作流优化依赖于蒙特卡洛树搜索(MCTS):
- 使用模板在搜索树中初始化起始工作流 $W_0$。
- 结合评分与均匀探索的软混合策略选择工作流节点。
- 根据该节点的评估表现,让 LLM 生成修改后的工作流以进行扩展。
- 执行并评估这一新工作流。
- 如果在 $N$ 轮预算内,新工作流表现出性能提升,就将其重新加入候选树中。
- 重复步骤 2 至 5,直到前 $k$ 个工作流的平均得分趋于平缓,或耗尽设定的预算。
AFlow 在问答、代码和数学任务上的实验表明,相比人工设计的工作流以及 ADAS,AFlow 带来了相当可观的性能提升。
可自我改进的运行架构
无论是上下文工程还是工作流设计,都只是运行架构的一部分。我们需要遍历整个设计空间,将上下文管理逻辑、工作流、权限控制以及其他众多架构组件结合起来统一优化。正如我们在 Meta-Harness、ADAS 和 AFlow 等工作中所见,✨代码✨是定义程序与系统的通用语言。简而言之,运行架构就是一段代码,用来编排提示词、工具调用、子智能体、控制流、记忆以及工作流逻辑之间如何协作。如果大语言模型能够优化执行智能体的底层代码,它所能探索的设计空间将远大于单纯手写提示词。
自学优化器(Self-Taught Optimizer,简称 STOP;Zelikman et al. 2023)是递归改进脚手架架构的早期代表作之一。在步骤 $t=0$ 时,种子改进器 $I_0$ 接收初始解决方案 $s$、效用函数 $u$ 以及黑盒语言模型 $M$,并输出改进后的方案 $s'$,即 $s' = I(u, s; M)$。STOP 的目标并不是直接优化 $s$,而是改进优化器 $I$ 本身。
首先,我们将元效用(meta-utility)定义为特定优化器函数 $I$ 在一系列下游任务 $\mathcal{D}$ 上的平均效用:
$$ \hat{u}(I) \triangleq \frac{1}{\vert\mathcal{D}\vert}\mathbb{E}_{(u,s)\sim \mathcal{D}}[u(I(u,s; M))] $$
由于优化这个改进器函数本身就是一个优化问题,我们可以通过自我改进更新,根据元效用衡量的上一代 $I_{t-1}$ 表现,递归得到新一代的 $I_t$:
$$ I_t=I_{t-1}(\hat{u},I_{t-1};M) $$
在他们的实验中,进化的优化器摸索出了多种策略,例如遗传算法、拆分子模块分别改进、多臂提示词老虎机、模拟退火、动态调整采样温度,以及束搜索/树搜索。这种机制正契合了将运行架构工作流视作优化对象的思路。
Zelikman 等人(2023)的研究中有一个值得警惕的发现:在使用 GPT-4 时,STOP 随着迭代推进提升了下游任务的平均表现;但换用能力稍弱的模型(如 GPT-3.5 和 Mixtral)时,性能反而出现了下滑。仅靠递归架构本身并不足够,底层模型必须具备足够的智能才能优化机制。这说明,运行架构的演进虽然能让模型发挥出更大威力,但核心依然取决于模型本身的智能水平。
Lin 等人(2026)更深入地研究了测试框架演化对模型能力的依赖关系。他们将其解耦为两个维度:(1)框架更新能力(harness-updating),即提出有效框架修改的能力;(2)框架获益能力(harness-benefit),即利用更新后的框架更出色地完成任务的能力。有趣的是,在他们的实验中,从 Qwen3.5-9B 到 Claude Opus 4.6,各种不同体量与核心智能水平的模型都表现出了相近的框架更新能力——9B 的框架提议/演化器写出的技能逻辑,在程序层面与 Opus 编写的高度一致。而要想最充分地利用框架,模型则需要做到准确、及时地调用技能/工具,并具备良好的长程指令遵循能力。
另一项更新的研究 Self-Harness(Zhang et al. 2026)则借助大语言模型智能体,通过“提议-评估-接受”循环来优化自身的测试框架。
Self-Harness 的循环包含三个阶段:
- Weakness mining: cluster failures into verifier-grounded failure patterns.
- 利用当前测试框架 $h_t$ 评测任务,并收集执行轨迹用于分析。
- 需要注意的是,两次运行可能表面上在错误日志中有着相同的验证器结果(例如超时或缺失构建产物),但背后的因果机制却截然不同。因此,我们需要一份包含丰富信息的失败记录——涵盖终端验证器层面的原因、相关智能体行为的因果状态,以及轨迹暴露出的智能体抽象机制,以此揪出根本原因。
- Harness proposal: propose bounded harness edits based on mined failure patterns.
- 在当前框架 $h_t$ 下调用同一个模型,充当提议器(proposer)。
- 系统会为模型提供一个受限的提议上下文,包含:(1)当前框架的可编辑层面;(2)评估系统基于验证器得出的失败模式;(3)应当予以保留的通过行为记录;(4)此前尝试过的修改总结。
- 框架修改应当优先针对可解决的复发性错误模式(例如非任务本身的特殊难题),且能通过局部改动予以解决。
- 候选修改方案之间应保持独立且具备多样性。
- Proposal validation: validate and merge qualified edits to create a new harness $h_{t+1}$.
- 候选修改会分别在内置数据集 $D_\text{in}$(用于测试弱点是否修复)和保留数据集 $D_\text{out}$(用于排查是否引入其他未知问题)上进行回归测试。
- 只有在内置和保留数据集上均未出现回归回退的候选方案,才会被采纳。
- 被采纳的修改会被合并,从而将框架更新为 $h_{t+1}$;被否决的修改则仅记录日志,不对当前生效的框架做任何改动。
在 Terminal-Bench-2 上运行 MiniMax M2.5、Qwen3.5-35B-A3B 和 GLM-5 时,Self-Harness 成功学习到了针对不同基座模型弱点的专属框架指令,从而提升了保留集上的通过率。
不过,Self-Harness 这类工作确实让我有些担忧:一旦允许程序修改操作系统层面,抽象边界就被打破了。可编辑的范围必须经过审慎设计,权限控制和安全层也必须置于该循环之外。此外,围绕奖励作弊(reward hacking)的所有挑战依然存在。
Agentic Harness Engineering(AHE;Lin et al. 2026)认为,harness 演进的瓶颈主要在于可观测性——也就是说,当某次运行失败时,必须能够明确是哪个组件出了问题,且每一次修改都应有据可依。
该框架围绕三大可观测性支柱构建了一个闭环:
- Component observability: every editable harness component has a representation in the file system so the action space is explicit and tracable.
- 一个 harness 包含 7 个组件:系统提示词、工具描述、工具实现、中间件、技能、子智能体配置以及长期记忆。
- 每种失败模式都会映射到一个具体组件上,从而让修改更有针对性。
- Experience observability: analysize and summarize a large amount of raw trajectories into a hierarchy of evidence and failure patterns.
- 每个 harness 会生成 $k$ 条执行轨迹。
- 系统使用专门的智能体(“智能体调试器”)来分析分别保存在独立文件中的轨迹,并针对每个任务生成分析报告,归纳成功或失败的根本原因。
- 所有单任务报告随后会汇总成一份评测基准总览,供下一步使用;如有需要,系统也可以直接查阅原始轨迹。这种分层访问结构能更有效地节省 token。
- Decision observability: every edit is paired with a prediction for the next round to validate.
- 随后由另一个智能体(“演进智能体”)读取代码库,决定修改哪个组件,并输出具体的修改方案及背后的推导逻辑。
- Every edit is a file-level, falsifiable claim and can be verified in the next round, under two constraints:
- (1) 修改仅作用于 harness 工作区。运行记录目录、追踪器、验证器和大模型配置均设为只读,这杜绝了一系列作弊手段(例如禁用验证器、偷换模型或增加推理预算),从而确保记录到的每一次性能提升都完全归功于 harness 本身的修改。
- (2) 修改完全由证据驱动,并附带一份清单条目:失败证据名称、推断的根本原因、针对性修复方案,以及对影响的预估(包括预期可修复的问题与可能引发回退的风险点)。
在 Terminal-Bench-2 上,除了高难度(Hard)梯队以及少数自我演化基线(ACE、TF-GRPO)之外,AHE 的表现超越了人工设计的 harness(如 OpenCode、Terminus-2、Codex)。在不作进一步演化的情况下,同一套冻结的 harness 直接迁移到 SWE-bench-verified 上依然有效,这表明演化后的 harness 成功将工程经验沉淀到了自身组件中,而不仅仅是针对特定基准进行过拟合优化。
演化搜索
演化搜索是一种受自然选择启发的优化方法(参见我之前关于演化算法的博文)。它通过对候选解种群进行变异,并在群体中仅保留高“适应度”的解来推动演进。演化搜索在以下两种场景中格外好用:(1) 搜索空间极其庞大或形状奇特;(2) 难以直接利用梯度优化,但评估解的优劣却很简单。harness 搜索恰好非常契合这一场景。
以往的研究中,演化搜索已被应用于提示词工程。Promptbreeder(Fernando et al. 2023)通过丰富的变异操作来优化针对特定任务的提示词;有趣的是,用于变异的提示词本身(即指导大模型如何修改任务提示词的指令)也会随着演化而迭代改进。GEPA(Agrawal et al. 2025)则将基于反思的提示技术与演化搜索相结合,通过对试错轨迹进行自然语言反思来提出提示词更新方案。
Novikov et al. (2025) 提出了代码智能体演化搜索系统 AlphaEvolve。该系统维护一个候选程序池,并提示冻结的大模型生成用于改进的代码差异(diff)。随着系统不断评估衍生程序并保留成功的候选者,它会逐步发掘出更优的解决方案。
AlphaEvolve 的设计中有几个关键细节:
- 提示词包含父代程序、运行结果、指令,有时还会附带元信息。
- 编写代码的智能体可以访问整个代码仓库,但需要改进的代码区域会用
# EVOLVE-BLOCK-START和# EVOLVE-BLOCK-END明确标出。 - 元提示词会根据大语言模型的建议,与指令和上下文一同协同进化,演进方式与求解程序类似。
消融实验展示了进化流程、提示词上下文、元提示词、全文件进化以及采用更强大大语言模型的作用。
近期的衍生工作中,ThetaEvolve(Wang 等人,2025 年)将进化搜索与强化学习及上下文学习相结合;DemoEvolve(Che 等人,2026 年)则在自主展开的归档中加入人类专家示范,为测试框架层面的诊断与修改提供参考经验。另一方面,ShinkaEvolve(Lange 等人,2025 年)引入了三个新组件,用以提升大语言模型的采样效率:
- 通过设计父代采样策略来平衡性能排名与后代数量,实现样本效率更高的探索。
- 引入基于代码新颖度的拒绝采样,利用嵌入向量的余弦相似度,剔除与现有种群过于相似的候选方案。
- 在元草稿本(meta-scratchpad)中提炼成功方案的优秀模式,用以指导后续的变异。
上述方法主要着眼于改进解决方案,而达尔文哥德尔机(Darwin Gödel Machine,简称 DGM;Zhang 等人,2025 年)则明确聚焦于让大语言模型代码智能体去进化一套可编辑的测试框架代码库。具体而言,该智能体有权修改自身的测试框架。其后续研究 Hyperagents(Zhang 等人,2026 年)还引入了一个元智能体,负责控制如何修改现有的任务智能体以创造出新智能体。
- 池中最初只有一个代码智能体。
- 每次迭代中,系统会挑选一个父代智能体进行修改并衍生出新智能体;挑选概率与该智能体的性能成正比,与其已生成的子代数量成反比。
- 选出的父代智能体会检查自己的基准测试评估日志,针对自身的测试框架代码库提出改进建议,从而生成新版本的代码智能体。代码编辑主要借助两个基础工具实现:(1) bash(参数:
<bash_command>)和 (2) editor(参数:view/create/edit <file_path>)。 - 评估新生成的代码智能体,只有性能足够出色的才会被放回池中。
- 重复第 2 至第 4 步,直到满足某项终止条件。
DGM 是在模型固定不变的前提下对测试框架进行进化。在以 Claude 3.5 Sonnet 为基础大语言模型、搭配简单初始测试框架配置的实验中,DGM 探索出的智能体在 SWE-bench Verified(从 20% 提升至 50%)和 Polyglot(从 14.2% 提升至 30.7%)上的表现,足以媲美甚至超越人工精心设计的智能体。
这类方法非常适合候选方案能够自动评测、适应度易于量化的场景,例如矩阵乘法、GPU 内核优化、算法竞赛以及数据中心调度等。但在评估耗时长、结果模棱两可或主要依赖启发式规则的领域,其表现则捉襟见肘。此外,进化的计算效率与实际效果也是不容忽视的问题。
与模型权重的联合优化
测试底座的演进改变的是模型周边的非参数系统。要想实现完全的自我提升,完全可以让模型在更新底座的同时,也更新自身的权重。权重更新既可以通过改进模型训练流水线来实现,也可以借助测试期的持续学习。关于持续学习这个话题,未来值得单独写一篇文章来聊。
SIA(Hebbar et al. 2026)是一次早期尝试,试图将底座改进与模型参数更新整合进同一个优化循环中。该架构包含三个核心组件:
- 元智能体(Meta-Agent):提出初始测试底座。
- 任务专属智能体(Task-Specific Agent):负责执行具体任务。
- 反馈智能体(Feedback-Agent):根据近期的执行轨迹,决定是更新测试底座还是更新模型权重。
SIA 的实验设计中存在一些干扰因素,导致实验结果较难解读。例如,任务专属智能体的能力远逊于元智能体和反馈智能体所用的模型(gpt-oss-120b 对比 Claude Sonnet 4.6);基线设置也过弱,无法与其他相关方法进行严谨的交叉对比。我认为这个研究方向很有意思,但目前给出的证据只能算初步成果。此外,像训练稳定性、古德哈特定律等诸多挑战仍未解决。
Continual Harness(Karten et al. 2026)则在长跨度游戏场景下展开实验,结合了底座更新,并通过在低奖励轨迹上蒸馏强教师模型的标签,联合学习策略模型。
未来的挑战
AI Scientist 系列研究有力地证明,由专家设计的底座足以协调自动科研循环的大部分环节(实验形式为撰写科研论文)。但炮制论文并不等同于科学发现。一个系统就算能写出一篇看起来像模像样的论文,也可能依然存在伪造引用、实现偏离预期或实验结果单薄等问题。
Trehan & Chopra (2026) 测试了大语言模型在仅配备极简脚手架和基础工具(即 read_file、write_file、llm_search、list_files)的情况下,能否独立将一个研究想法转化为一篇完整的论文。每个想法都有专属的工作区,智能体可以在其中生成并读取文档作为上下文。他们选择了三个领域展开实验(世界模型、多智能体强化学习、AI 安全与对齐),每个领域提供 45-50 篇高质量种子文档以激发新构想。人类专家最终只挑选了 4 个想法跑完完整流程,而其中只有 1 个真正落实成了一篇论文。研究人员在实验中观察到了 6 类反复出现的失败模式:
- 偏向训练数据的默认惯性:调用过时的库、陈旧的命令、标准格式,或者做出与当前代码库或数据集脱节的预设。
- 执行压力下的实现漂移:一旦代码实现变得过于复杂,模型就容易退而求其次,采用常见的简单方案,而不是原本提出的研究方法。
- 记忆与上下文退化:在长周期项目中,除非将运行日志保存为持久化的工作产物,否则关键细节很容易丢失。
- 盲目乐观:哪怕实验数据充满噪声甚至彻底失败,模型也会宣称大获成功。这种现象与 Bubeck et al. (2025) 观察到的“P值黑客与假顿悟”(p-hacking and eureka-ing)如出一辙——模型会在数据上打各种“补丁”,在有效信号仍被噪声淹没时就过早宣布胜利。
- 领域理解不足:模型缺乏实践中的默会经验,比如预估实现的复杂度、判断实验结果是否合理,或是明确哪些基准对比真正有参考价值。
- 科研品味欠佳:实验哪怕能够跑通,也无法切中真正重要的问题。
在迈向完全 RSI(递归自我提升)的道路上,研究人员已取得实质进展,但仍有几大瓶颈有待突破。
1. 评估机制薄弱且模糊。 许多科研主张缺乏快速且精准的验证手段,现实中的诸多任务同样如此。当前的自我提升闭环只有在评估指标客观、可量化的任务中才能发挥最大效用,这与强化学习的运作逻辑如出一辙。
科研品味、新颖度以及长期科学价值则要难衡量得多。例如,科研品味往往综合了问题界定、实验设计,以及对哪些意外结果值得深挖、哪些失败案例值得重试的敏锐判断。
2. 上下文与记忆生命周期。 随着 AI 智能体的自主性和独立性不断提高,其记忆也在不断膨胀。一个实用的运行框架需要有效管理上下文与记忆,在弥补当前长上下文生成能力局限的同时,最大化长周期任务的成功率。正如人类能够终生保留记忆,我认为这里的逻辑也是一致的:上下文工程势必也应当成为智能本身的核心部分,而不仅仅停留在软件系统层面。
3. 负面结果。 现有的激励机制促使研究人员发表成功结果,导致学术文献严重偏向成功案例。大语言模型基于海量数据训练而成(至少目前大多还是人类产出的),由于数据中成败案例比例失衡,模型往往很难判断何时该放弃某个假设、何时该报告负面结果,甚至难以正视失败。科研支撑框架应该让失败的尝试易于留存,因为从失败中吸取教训是缩减任务搜索空间的最佳途径。
4. 多样性坍缩。 进化算法和强化学习闭环往往倾向于过度利用已知的获高奖励模式。我们需要相关机制来防止种群坍缩成同一种方案的各种变体。这对于开放式科研尤为关键,因为最优路径在现有的评估体系下,起初看起来可能反而是更差的。
5. 奖励作弊。 自我提升闭环无论接收到什么信号都会竭力优化。如果奖励来自单元测试,智能体可能会对测试集过拟合;如果来自评审模型,它可能会掌握针对该特定评审模型的投机技巧;如果来自基准测试跑分,它则可能钻基准测试中人工痕迹的空子。
评估器与权限控制或许应该置于框架进化闭环之外,配合保留测试集、轨迹审计,并在关键决策点引入人工审核——至于这种监管在多大程度上能够实现规模化与自动化,目前仍是一个悬而未决的研究课题。
6. 长期成效。 外层优化闭环所针对的奖励,存在于我们在训练沙盒中模拟单次展开试错(rollout)之外。
以代码智能体为例。这类智能体现已提升了软件工程的日常生产力,但许多优化目标依然过于短视。它往往能完成手头的具体任务,却很难说清楚该如何维护一个由成百上千名工程师共同协作的代码库的长期健康。基于沙盒的标准 RLVR 式训练,极少能兼顾代码的可维护性、代码归属边界、迁移成本、向后兼容性或未来的调试负担。
7. 人类的角色。人类应该走向技术栈的上层,而不是被完全排除在流程之外。换言之,人类应当在恰当的时机、以合适的抽象层次进行把关,而我们的系统设计也必须考量何时以及如何设置这些人工介入点。
上述许多挑战都需要人类的反馈与引导。毕竟,我们发展技术是为了让人类的未来更美好,而非本末倒置。
引用
请按如下格式引用本文:
Weng, Lilian. “Harness Engineering for Self-Improvement”. Lil’Log (Jul 2026). https://lilianweng.github.io/posts/2026-07-04-harness/
或使用 BibTeX 引用:
@article{weng2026harness,
title = {Harness Engineering for Self-Improvement},
author = {Weng, Lilian},
journal = {lilianweng.github.io},
year = {2026},
month = {July},
url = "https://lilianweng.github.io/posts/2026-07-04-harness/"
}
附录:一些实用的基准测试
- PaperBench: replicate 20 ICML 2024 Spotlight and Oral papers from scratch, including understanding paper contributions, developing a codebase, and successfully executing experiments.
- 每个复现任务都被拆解为更小、可单独评分的子任务。
- 共计 8,316 条评分标准,由评测团队与论文原作者共同制定。
- 当时表现最好的模型(
Claude 3.5 Sonnet,约 21%)表现未超过机器学习方向的博士生。 - 包含 PaperBench、轻量版的 PaperBench Code-Dev 以及 JudgeEval。
- CORE-Bench: evaluate computational reproducibility of published research.
- 基于涵盖计算机科学、社会科学和医学领域的 90 篇科研论文,设计了 270 项任务。
- 任务内容涉及基于所提供的代码和数据来复现研究结果。
- 涵盖多种难度等级,同时包含纯文本任务与视觉语言任务。
- 当时文献记录中表现最好的智能体(
GPT-4o和GPT-4o-mini)在最具难度的任务上仅取得了 21% 的准确率。
- ScienceAgentBench: evaluate LLM agents for data-driven scientific discovery.
- 从数学、化学、生物学和地理学四大领域的 44 篇同行评审论文中提炼出 102 项任务。
- 覆盖这些领域的基础数据科学任务,包括数据处理、模型开发、数据分析与信息可视化。
- RE-Bench: evaluate frontier AI agents on realistic ML research-engineering envs against human experts.
- 包含 7 个极具挑战性、开放式的机器学习研发工程环境。
- 每个环境均由“评分函数、初始方案、参考方案”组成;且均可在不超过 8 张 H100 GPU 上运行。
- 例如:优化算子核心(kernel)、运行缩放定律(scaling-law)实验、修复嵌入向量、针对问答微调 GPT-2 等。
- 包含 61 位不同人类专家共计 71 次、每次限时 8 小时的解题尝试数据。
- 在 8 小时的尝试中,人类专家在 82% 的测试中拿到了非零分数;有 24% 的尝试达到或超过了强参考方案的水平。
- 在 2 小时的时间预算内,表现最优秀的 AI 智能体得分达到了人类专家的 4 倍;但在更充裕的时间下,人类的表现提升幅度更大,在 8 小时和 32 小时的设置中反超了智能体。
- MLE-bench: evaluate ML engineering agents on offline Kaggle competitions.
- 包含从 Kaggle 精选出的 75 场机器学习工程竞赛。
- 考核模型训练、数据集准备、实验运行以及向评分脚本提交预测结果等全流程能力。
- 以 Kaggle 公开排行榜上的成绩作为人类基准。
- 论文中的最优配置(搭配 AIDE 框架的
o1-preview)在 16.9% 的竞赛中达到了至少 Kaggle 铜牌的水平。 - 包含资源扩展与数据污染分析。
- KernelBench: evaluate correctness and speed for generated GPU kernels.
- 提供 250 项 PyTorch 任务,用于评估大语言模型是否能编写出既正确又高效的算子核心(kernel)。
- 评估指标 fast_p 指的是生成的算子中既正确且运行速度快于基准的百分比。
参考文献
[1] Good, I. J. “Speculations Concerning the First Ultraintelligent Machine.” Advances in Computers, 6:31–88, 1965.
[2] Yudkowsky, Eliezer. “Recursive Self-Improvement.” LessWrong, 2008.
[3] Choi 等人。“用于代码修复的锚定自我对弈。” ICML 2026。
[4] Zhao 等人。“绝对零度:基于零数据的强化自我对弈推理。” arXiv preprint arXiv:2505.03335, 2025。
[5] Yuan 等人。“自我奖励语言模型。” arXiv preprint arXiv:2401.10020, 2024。
[6] Chen 等人。“自我对弈微调:将弱语言模型转化为强语言模型。” ICML 2024。
[7] Zhang 等人。“智能体上下文工程:面向自主改进语言模型的上下文演进。” ICLR 2026。
[8] Ye 等人。“基于智能体技能演进的元上下文工程。” arXiv preprint arXiv:2601.21557, 2026。
[9] Lee 等人。“Meta-Harness:模型测试框架的端到端优化。” arXiv preprint arXiv:2603.28052, 2026。
[10] Lu 等人。“迈向 AI 科研的端到端自动化。” Nature, 651:914–919, 2026。
[11] Meng 等人。“ScientistOne:通过证据链迈向人类级自主科研。” arXiv preprint arXiv:2605.26340, 2026。
[12] Kulikov 等人。“Autodata:用于构建高质量合成数据的智能体数据科学家。” arXiv preprint arXiv:2606.25996, 2026。
[13] Hu、Lu 与 Clune。“智能体系统的自动化设计。” ICLR 2025。
[14] Madaan 等人。“Self-Refine:基于自我反馈的迭代优化。” NeurIPS 2023。
[15] Zhang 等人。“AFlow:自动化智能体工作流生成。” ICLR 2025。
[16] Zelikman 等人。“自学优化器(STOP):递归自我改进的代码生成。” COLM 2024。
[17] Zhang 等人。“Self-Harness:能自我改进的测试框架。” arXiv preprint arXiv:2606.09498, 2026。
[18] Fernando 等人。“Promptbreeder:通过提示词演进实现自指式自我改进。” arXiv preprint arXiv:2309.16797, 2023。
[19] Agrawal, A. 等人。“GEPA:反思性提示词演进可超越强化学习。” arXiv preprint arXiv:2507.19457, 2025。
[20] Novikov 等人。“AlphaEvolve:面向科学与算法发现的编程智能体。” arXiv preprint arXiv:2506.13131, 2025。
[21] Lange、Imajuku 与 Cetin。“ShinkaEvolve:迈向开放式与高样本效率的程序演进。” arXiv preprint arXiv:2509.19349, 2025。
[22] Wang 等人。“ThetaEvolve:面向开放问题的测试期学习。” arXiv preprint arXiv:2511.23473, 2025。
[23] Zhang 等人。“达尔文-哥德尔机:自我改进智能体的开放式演进。” arXiv preprint arXiv:2505.22954, 2025。
[24] Zhang 等人。“超智能体(Hyperagents)。” arXiv preprint arXiv:2603.19461, 2026。
[25] Yuksekgonul 等人。“在测试期学会发现。” arXiv preprint arXiv:2601.16175, 2026。
[26] Riaz 等人。“用于测试期发现的认知不确定性。” arXiv preprint arXiv:2605.11328, 2026。
[27] Hebbar 等人。“SIA:结合测试框架与权重更新的自我改进 AI。” arXiv preprint arXiv:2605.27276, 2026。
[28] Trehan 与 Chopra。“为什么大语言模型目前还成不了科学家:来自四次自主科研尝试的教训。” arXiv preprint arXiv:2601.03315, 2026。
[29] Bubeck 等人。“利用 GPT-5 加速科学发现的早期实验。” arXiv preprint arXiv:2511.16072, 2025。
[30] Starace 等人。“PaperBench:评估 AI 复现 AI 科研成果的能力。” ICML 2025。
[31] Wijk 等人,“RE-Bench:对比人类专家评估语言模型智能体的前沿 AI 研发能力”,ICML 2025。
[32] Chan 等人,“MLE-bench:评估机器学习智能体的机器学习工程能力”,arXiv 预印本 arXiv:2410.07095, 2024。
[33] Chen 等人,“ScienceAgentBench:对数据驱动科学发现语言智能体进行严谨评估”,ICLR 2025。
[34] Siegel 等人,“CORE-Bench:通过计算可复现性智能体基准提升已发表研究的可信度”,TMLR 2024。
[35] Ouyang 等人,“KernelBench:大语言模型能写出高效的 GPU 内核吗?”,arXiv 预印本 arXiv:2502.10517, 2025。
[36] Lin 等人,“Harness 更新不等于 Harness 收益:解耦自进化大语言模型智能体中的进化能力”,arXiv 预印本 arXiv:2605.30621, 2026。
[37] Lin 等人,“智能体 Harness 工程:由可观测性驱动的代码智能体 Harness 自动进化”,arXiv 预印本 arXiv:2604.25850, 2026。
[38] Karten 等人,“Continual Harness:面向自我提升基础智能体的在线自适应”,arXiv 预印本 arXiv:2605.09998, 2026。
[39] Che 等人,“DemoEvolve:借助示范克服智能体 Harness 进化中的稀疏反馈问题”,arXiv 预印本 arXiv:2605.24539, 2026。
来源:Lilian Weng's Blog · lilianweng.github.io