目录
递归自我改进(recursive self-improvement, RSI) 的概念可以追溯到 I. J. Good (1965)。他把「超智能机器」(ultraintelligent machine)定义为一个能在所有智力活动上超越人类、并能设计出更好的机器来改进自身的系统。Yudkowsky (2008) 用「递归自我改进」一词特指这样一种反馈回路:AI 用它当前的智能,去改进那套产生其智能的认知机制。
在现代 AI 中,这个反馈回路可能意味着模型直接改写自己的权重;也可以更宽泛地理解为:模型改进训练流水线和部署系统,从而催生一个在各类具有经济价值的任务上表现更好的后继模型。前沿实验室的 AI 研究进展速度已被证明在急剧加速(Anthropic;OpenAI)。
我特意提到*「部署系统」*,是因为位于原始模型与真实世界上下文之间的这一层,似乎与模型的原始智能(即预训练之后立刻做的那些评测)同等重要。Harness 是 AI 部署的重要组件,Claude Code、Codex 等成功的编码智能体产品已经证明了这一点。Harness 指的是围绕基础模型的整套系统:它编排执行过程,决定模型如何思考与规划、如何调用工具并行动、如何感知和管理上下文、如何存储产物(artifacts)、以及如何评估结果。
本文聚焦于 harness 工程相关的研究,以及它如何为 RSI 做出贡献。近期关于自动研究(auto-research)、自我改进智能体和演化式程序搜索的许多工作,都可以围绕这个问题来组织。另有一些关于模型自博弈(self-play)、合成数据、测试时训练(test-time training)以及更宏观的持续学习主题的工作,同样契合 RSI 的愿景(例如 Yuan et al. 2024、Chen et al. 2024、Zhao et al. 2025、Choi et al. 2026),但它们不是本文的重点。
Harness 设计模式
与早期的智能体框架——「agent = LLM + 记忆 + 工具 + 规划 + 行动」——相比,harness 工程还额外涵盖工作流设计(例如循环工程 loop engineering)、评估、权限控制和持久状态管理。它不再只是提示词模板,而更接近运行时与软件系统设计:模型如何观察、行动、记忆、自检和改进。
设计应当刻意保持简单、通用,以便泛化;并且最好参考现有的软件工程实践,从预训练知识中获益。操作系统与 harness 之间也有很强的类比:和 OS 一样,harness 应当封装复杂逻辑、同时保持接口简单。与此同时,配置、工具接口和其他协议可能会逐渐在业界形成标准。
模式一:工作流自动化
定义一个让模型可以在其中操作、测试、迭代的工作流,是实现自动化的关键设计。Karpathy 的 autoresearch 仓库(https://github.com/karpathy/autoresearch)是构建这类工作流的一个干净的例子。常见的工作流遵循一个目标导向的循环:规划、执行、观察/测试、改进、再执行,直到达成目标。过程中可能会主动向用户发起请求,以澄清任务规格或执行偏好。

图:简化的 Codex agent 循环——agent 调用工具,工具响应影响模型的下一步生成。(图片来源:OpenAI codex agent 博文)
这个工作流图还强调让模型分析自己的轨迹(trajectory)和失败案例,然后通过一个「agent 运行时」而不是静态的提示词模板来迭代推进。
模式二:文件系统即持久记忆
长程(long-horizon)智能体系统中一个反复出现的模式是:用简单的控制来管理丰富的状态和产物。harness 不应该把整个工作流和全部日志都装进上下文,而应该把持久状态放在文件里。在长程 agentic rollout 中,实验日志、代码 diff、论文摘要、错误堆栈、历史 rollout 轨迹等产物,往往会远远超过模型训练时所适应的上下文窗口长度。
学会读、写、编辑文件系统(通常通过 bash 命令)是 LLM 的基础能力,因此以「文件」这种简单形式管理持久记忆,天然能随核心模型能力的提升而受益。
模式三:子智能体与后台任务
harness 可以派生多个子智能体(subagent)并行执行,并监控后台任务。当主智能体需要同时探索多个假设、并发跑实验、或者在不污染主上下文的前提下委派相互独立的子任务时,这非常有用。此时父智能体需要一个小型的进程管理器:启动任务、检查日志、取消失败的运行、把结果合并回主智能体线程。
关键的设计选择是让并行显式化、可检查。如果子智能体的输出只存在于转瞬即逝的聊天上下文里,它们很快就会过时、被埋没。如果以文件、日志和状态记录的形式存储,模型就能在中断后恢复,并对自己的执行历史进行推理。
案例研究:编码智能体的 Harness
主流编码智能体的核心接口在 Claude Code、Codex、OpenCode 和 Cursor 风格的智能体之间已经趋于稳定。它们普遍使用类似这样的循环:

借助一组工具,编码智能体能够在给定仓库中开发功能、调试问题,就像人类开发者配备了 IDE 一样。
(并非完整列表,仅作演示。感兴趣的话可以读这个。)
| 分组 | 工具定义 |
|---|---|
| 文件系统 | 文件发现:glob、grep、ls文件读取: read、read_many文件修改: write(写一个全新文件)、edit(字符串精确匹配替换)、multi_edit、apply_patch(应用结构化 patch/diff) |
| Shell 执行 | 运行命令:bash、PowerShell |
| IO | lsp,以及 git 工具如 git_status、git_diff、git_commit |
| 外部上下文 | MCP 工具、Skills |
| 网络搜索 | web_search、web_fetch、浏览器工具 |
| 产物 | 读取文档、图片;生成 HTML、图片 |
| 后台进程 | 例如 CronCreate、CronDelete、CronList |
| 智能体委派 | 例如 spawn_agent、resume_agent、wait_agent、list_agents、close_agent、interrupt_agent 等 |
Harness 层 vs 核心智能?
很难预测未来的 RSI 会在多大程度上依赖 harness 工程,但近期的 RSI 路径不太可能以「模型直接改写自身权重」开场。我对一条务实的近期路径的预测是:
- Harness 工程会朝元方法论(meta-methodology)的方向演化(即改进「获得更好答案的机制」,而不只是改进答案本身)。harness 系统本身成为优化目标,启发式规则越来越少,通用机制越来越多。
- 反过来,成熟的 harness 让服务于模型自我改进循环的自动研究成为可能;而更聪明的模型能防止 harness 过度工程化,让系统保持可持续。
最终,许多 harness 上的改进可能会被内化进核心模型行为,但与外部上下文和工具的接口应当会保留下来。我们已经在提示词工程上见过这一模式的温和版本:随着指令微调和模型推理能力的进步,手工的提示词技巧不再那么核心,但明确目标、约束、上下文和评估标准的需求并没有消失。
Harness 优化
harness 系统中「被优化对象」的演进轨迹大致是:指令提示词 → 结构化上下文 → 工作流 → harness 代码 → 优化器代码。随着模型越来越聪明、越来越强大,我们会走向更复杂的优化目标和更通用的方法。
上下文工程
简单地把所有工具响应和模型生成追加进上下文,会随着 agentic 任务时程的显著拉长而迅速失控。上下文管理是这样一层:为 LLM 构建更结构化、更简洁的上下文,并管理持久状态。长上下文研究无疑会继续进步,但眼下,长上下文智能与上下文工程时常交织在一起。
Agentic Context Engineering(ACE;Zhang et al. 2025)把上下文当作一本不断演化的战术手册(playbook),而不是一段越拉越长的提示词。它用三个组件维护一份由条目(bullet point)构成的上下文手册,每个条目都有标识符和描述:
- Generator(生成器):参照手册条目产出任务轨迹。
- Reflector(反思器):从成功和失败的轨迹中提炼洞见。
- Curator(策展器):以增量、逐条的方式更新结构化上下文。

图:Agentic Context Engineering(ACE)框架。(图片来源:Zhang et al. 2025)
为了防止迭代重写过程中的上下文塌缩(context collapse)和简短偏置(brevity bias),ACE 的一个关键设计选择是:curator 不去重写一整块提示词,而是输出一组(标识符,描述)形式的结构化条目,再由确定性逻辑把这些条目合并进结构化的上下文日志。上下文条目会被定期精炼和去重。
ACE 能从 rollout 中学习洞见,这让我们朝「自我管理的记忆」迈进了一步,但它的更新规则和整体工作流仍是手工设计的。为了走向更彻底的自我改进循环,Meta Context Engineering(MCE;Ye et al. 2026)把机制(如何管理上下文)与产物内容(上下文里有什么)分离开来:在元优化层面运行技能演化,在基础层面运行上下文优化。
一个 MCE 技能 定义一个上下文函数 ,把输入 映射为上下文 ,其中:
- 是静态组件(提示词、知识库、代码库)。
- 是动态算子(搜索、选择、过滤、格式化)。
这个双层优化的内层,是在训练数据上、给定技能 时找到最优上下文 ;外层则寻找在验证集上表现最好的技能:
技能数据库记录历史技能、上下文函数和评测指标 。一个元层面的智能体在既有技能上执行 agentic 交叉(crossover),针对任务 生成新技能:。
随后,基础层面的上下文工程师执行技能 ,并在当前技能的引导下,从 rollout 反馈 中学习上下文函数:。

图:Meta Context Engineering(MCE)框架——元层面的技能演化在上下文管理机制的空间中搜索,基础层面则优化任务上下文。(图片来源:Ye et al. 2026)
MCE 不像 ACE 那样对上下文结构强加启发式规则。它用自由形式的技能来存储任务最重要的知识,并让技能与技能条件化的上下文一起迭代演化。在实现上,一个上下文函数 被实例化为专用目录下的一组文件,既包含静态组件(skill.md),也包含动态组件(上下文与数据 rollout)。元层面与基础层面的优化都在带有标准工具集的 agentic 编码环境中执行:
Meta-Harness(Lee et al. 2026)又深入了一层:被优化的对象是那些决定并优化「哪些信息应当被存储、检索并呈现给模型」的代码。名字里的「Meta-」意味着它是一个用来优化 harness 的 harness。

图:Meta-Harness 的外层循环优化算法。(图片来源:Lee et al. 2026)
负责提出新 harness 的 proposer 本身就是一个编码智能体,最终输出是位于帕累托前沿(Pareto frontier)上的一组 harness 候选。
- 全部执行历史都可以通过文件系统访问,因此编码智能体用
grep、cat之类的命令去翻阅它,而不是把所有内容一股脑塞进单个提示词上下文。 - 被提出的 harness 是文件系统中的一个目录结构,包含它自己的源代码、得分、rollout 轨迹和状态更新。
- 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 中把可验证性作为核心设计约束:每一个论断(引用、数值、方法、结论)都必须能追溯到证据来源,并接受证据链(Chain-of-Evidence)检查的审计。

图:AI Scientist 的想法生成、实验、论文撰写与评审流水线。(图片来源:Lu et al. 2026)
Autodata agent(Kulikov et al. 2026)被设计成一名生成训练与评测数据的数据科学家。主智能体管理一个提出问题的 challenger、一个弱 solver、一个强 solver 和一个 verifier/judge,目标是合成难度「刚刚好」的数据——强 solver 能做对而弱 solver 会做错。
在 Autodata 中,challenger 的提示词会根据 solver 和 verifier 的反馈迭代更新。这里的局限在于:合成任务只被用来微调弱 solver 而非强 solver;如果这个循环不能迭代地改进强模型,它就更像是在一个生成出来的提示分布上做间接蒸馏,RSI 的味道要淡一些。

图:Autodata 围绕 challenger、solver、verifier 角色设计的 agentic 工作流,用于生成合成训练与评测数据。(图片来源:Kulikov et al. 2026)
工作流的设计空间极其庞大,我们很自然可以把工作流设计看作一个搜索问题,从而应该能靠算法、而不是仅靠手工来找到好的方案。沿着这个方向,Automated Design of Agentic Systems(ADAS;Hu et al. 2025)把智能体设计本身表述为一个优化问题——「元智能体搜索」(meta-agent search):由一个元智能体提出 agentic 工作流的新设计。
- 用 CoT、self-refine 等简单智能体初始化一个 agentic 工作流档案库(archive)。
- 让元智能体在档案库现有方案的启发下编写新的智能体——全部用代码表达。
- 元智能体先生成新工作流的高层描述,再用代码实现它。
- 草稿程序随后经过元智能体的两步 self-refine(即让模型给出反馈、再让同一个模型基于反馈改进先前生成的输出;Madaan et al. 2023),以检查其新颖性。
- 评估每个新候选,把成功者加回档案库。
- 重复步骤 2-3,直到达到最大迭代次数。

图:Automated Design of Agentic Systems(ADAS)示意。(图片来源:Hu et al. 2025)
AFlow(Zhang et al. 2025)把 agentic 工作流表示为一张图:节点代表调用 LLM 的动作,边则以代码实现逻辑操作。工作流优化依赖 MCTS(蒙特卡洛树搜索):
- 用模板初始化树中的起始工作流 。
- 用「分数 + 均匀探索」的软混合来选择一个工作流节点。
- 让 LLM 在其评测表现的条件下产出修改后的工作流,以扩展该节点。
- 执行并评估新工作流。
- 如果新工作流在 轮预算内表现出改进,就把它加回树中。
- 重复步骤 2-5,当 top- 平均分进入平台期或耗尽预算时停止。

图:AFlow 在工作流候选树上的优化过程。(图片来源:Zhang et al. 2025)
AFlow 在 QA、代码和数学任务上的实验显示,相对手工设计的工作流和 ADAS,它都有可观的提升。

图:AFlow 与手工方法和 ADAS 的实验对比。(图片来源:Zhang et al. 2025)
自我改进的 Harness
无论是上下文工程还是工作流设计,都只是 harness 的一部分。我们需要在整个设计空间中搜索,把上下文管理逻辑、工作流、权限以及许多其他 harness 组件放在一起优化。正如我们在 Meta-Harness、ADAS 和 AFlow 等工作中所见,✨代码✨ 是定义程序与系统的通用语言。简单说,harness 就是一段代码,它编排提示词、工具调用、子智能体、控制流、记忆和工作流逻辑如何协同工作。如果 LLM 能优化「执行智能体的代码」,它能触及的设计空间就比手写提示词大得多。
Self-Taught Optimizer(STOP;Zelikman et al. 2023)是递归式脚手架(scaffolding)改进的早期例子之一。在步骤 ,种子改进器 接受初始解 、效用函数 和黑盒语言模型 ,返回一个改进后的解 ,即 。STOP 的目标不是直接改进 ,而是改进改进器 本身。
首先,把元效用(meta-utility)定义为给定改进器函数 在一组下游任务 上的平均效用:
由于「改进改进器函数」本身也是一个优化问题,我们可以基于 在元效用上的表现,通过自我改进更新递归地得到新版本 :

图:Self-Taught Optimizer(STOP)算法。(图片来源:Zelikman et al. 2023)
在 Zelikman et al. (2023) 的实验中,被改进的改进器发现了多种多样的策略,比如遗传算法、分解后分别改进、多臂提示词老虎机(multi-armed prompt bandits)、模拟退火、变化温度、beam/树搜索等。这与「harness 工作流可以被表示为优化对象」是同一个道理。

图:STOP 发现的自我改进策略示例。(图片来源:Zelikman et al. 2023)
他们的发现中有一个值得警惕的结果:使用 GPT-4 时,STOP 能随迭代提升下游平均表现;但换成 GPT-3.5、Mixtral 等较弱的模型时反而退化。仅有递归结构是不够的——基础模型必须足够有能力去改进这套机制。这意味着 harness 改进能让模型部署得更好,但智能仍然是核心。
更近的工作 Self-Harness(Zhang et al. 2026)依靠 LLM 智能体,通过「提议-评估-接受」循环来改进它们自己的 harness。

图:Self-Harness 用「弱点挖掘、有边界的 harness 提议、验证」的循环来更新 harness。(图片来源:Zhang et al. 2026)
Self-Harness 的循环分三个阶段:
- 弱点挖掘(weakness mining):把失败聚类成有验证器依据(verifier-grounded)的失败模式。
- 用当前 harness 在任务上做评测,并收集执行轨迹用于分析。
- 注意,两次运行可能在错误日志的表面上共享同一个验证器结果(比如超时或产物缺失),但因果机制不同。因此我们需要信息丰富的失败记录——包含最终的验证器层面原因、相关智能体行为的因果状态、以及轨迹所暴露的抽象智能体机制——才能揭示根因。
- Harness 提议(harness proposal):基于挖掘出的失败模式,提出有边界的 harness 编辑。
- 同一个模型在 下被调用为提议者。
- 提供给模型一个有边界的提议上下文:(1) 当前 harness 的可编辑面;(2) 来自评测系统的、有验证器依据的失败模式;(3) 应当保留的通过行为的记录;(4) 先前尝试过的编辑的摘要。
- Harness 编辑应优先处理那些可解决(例如并非任务本身难度所致)、且能用小改动修复的反复出现的错误模式。
- Harness 编辑候选应彼此不同、保持多样。
- 提议验证(proposal validation):验证并合并合格的编辑,得到新 harness 。
- 候选编辑通过回归测试来评估,分为留内集 (检验弱点是否被解决)与留外集 (检查是否引入了其他未知问题)。
- 只有在留内、留外数据上都没有回归的候选才会被接受。
- 被接受的候选合并进 harness 得到 ;被拒绝的候选只做记录,不改动现役 harness。
在 Terminal-Bench-2 上运行 MiniMax M2.5、Qwen3.5-35B-A3B 和 GLM-5 时,Self-Harness 被证明能学到针对不同基础模型不同弱点的、模型专属的 harness 指令,并提升留外数据上的通过率。
Self-Harness 这类工作确实让我担心:如果允许一个程序去编辑操作系统,抽象边界就被打破了。可编辑面需要被恰当地设计,权限控制和安全层必须位于这个循环之外。围绕奖励欺骗(reward hacking)的所有挑战也依然存在。
演化搜索
演化搜索是一种受自然选择启发的优化方法(参见我以前那篇关于演化算法的文章)。它通过变异来演化一个解的种群,只保留群体中「适应度」高的个体。当 (1) 搜索空间庞大或形状怪异;且 (2) 难以直接用梯度优化、但很容易评估解的好坏时,演化搜索特别趁手。harness 搜索看起来正契合这两点。
过往研究已经把演化搜索用在了提示词工程上。Promptbreeder(Fernando et al. 2023)通过一组丰富的变异操作来优化任务专属的提示词;有趣的是,变异提示词(即指示 LLM 去变异某个任务提示词的指令)本身也通过演化得到改进。GEPA(Agrawal et al. 2025)把基于反思(reflection)的提示与演化搜索结合,用对试错轨迹的自然语言反思来提出提示词更新。
Novikov et al. (2025) 提出了 AlphaEvolve,一个编码智能体式的演化搜索系统:它维护一池候选程序,并提示冻结的 LLM 生成用于改进的 diff。随着系统反复评估子代程序并保留成功者,它会随时间发现更好的解。

图:AlphaEvolve 的工作方式。(图片来源:Novikov et al. 2025)
AlphaEvolve 的设计中有几个重要细节:
- 提示词包含父代程序、结果、指令,有时还有元信息。
- 编码智能体可以访问整个仓库,但要改进的代码区域用
# EVOLVE-BLOCK-START和# EVOLVE-BLOCK-END显式标出。 - 元提示词(meta-prompt)按照 LLM 的建议,与指令和上下文共同演化,方式与演化解程序类似。
消融实验展示了演化过程、提示词中的上下文、元提示词、全文件演化以及使用更强 LLM 各自的价值。

图:消融实验展示了 AlphaEvolve 中若干设计的价值。(图片来源:Novikov et al. 2025)
近期的变体如 ThetaEvolve(Wang et al. 2025)把演化搜索与 RL 和上下文内学习(in-context learning)结合起来。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_command>)和 (2) editor(参数:view/create/edit <file_path>)。 - 评估新的编码智能体,只有性能足够高的才会被加回池中。
- 重复步骤 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 还是更新模型权重。

图:SIA 中的 Feedback-Agent 决定下一轮迭代的类型。(图片来源:Hebbar et al. 2026)
SIA 的实验中存在一些混淆因素,让结果难以解读。比如,task-specific agent 比 Meta-Agent 和 Feedback-Agent 所用的模型弱得多(gpt-oss-120b vs Claude Sonnet 4.6),而基线又太弱,难以与相关方法干净地相互印证。我认为这个方向有意思,但目前的证据只能算初步。而训练稳定性、Goodhart 效应等诸多挑战仍然悬而未决。
未来挑战
AI Scientist 这条线的工作有力地证明了:专家设计的 harness 能够以撰写研究论文的形式,协调自动研究循环的很大一部分。但产出论文并不等同于科学发现。一个系统可以写出看似可信的稿件,却仍然存在捏造引用、实现漂移或实验结果薄弱的问题。
Trehan & Chopra (2026) 测试了 LLM 能否在极简脚手架和基础工具(即 read_file、write_file、llm_search、list_files)下,从一个研究想法走到一篇论文。每个想法都有专属的工作区,智能体可以在其中生成和阅读文档,作为上下文的一部分。他们在三个领域(世界模型、多智能体 RL、AI 安全与对齐)做了实验,每个领域包含 45-50 份高质量的种子文档来启发新想法。只有四个想法被人类专家选中走完整个流水线,而其中只有一个被完整执行成了论文。实验中观察到六种反复出现的失败模式:
- 偏向训练数据的默认值:使用过时的库、陈旧的命令、标准格式,或做出与实际仓库/数据集不符的假设。
- 执行压力下的实现漂移:当实现变得技术复杂时,模型可能滑向常见的更简单的方案,而不是坚持所提出的方法。
- 记忆与上下文退化:除非把日志写成持久产物,否则长程项目会丢失关键细节。
- 过度乐观:即使实验嘈杂或失败,模型也宣布成功。Bubeck et al. (2025) 观察到类似的「p-hacking 与 eureka 化」模式——模型会引入「数值胶带」(numerical duct tape),在信号还只是噪声时就宣布胜利。
- 领域智能不足:模型缺少隐性的手艺知识,比如预估实现复杂度、判断某个实验结果是否合理、或知道哪些基线才重要。
- 科学品味薄弱:实验可以执行,却没有回答正确的问题。
朝着完全 RSI 的方向,研究者已经取得了实打实的进展,但若干瓶颈仍在。
1. 弱且模糊的评估器。 许多研究论断没有快速而精确的验证器,许多现实任务同样如此。当前的自我改进循环在评估指标可测量、客观的任务上效果最好,这与 RL 的工作原理类似。
研究品味、新颖性和长期科学价值则要难衡量得多。例如,研究品味往往混合了问题表述、实验设计、以及对「哪些出人意料的结果值得追下去、哪些失败案例值得重试」的判断。
2. 上下文与记忆的生命周期。 随着 AI 智能体越来越自主、越来越独立,记忆会不断增长。一个有用的 harness 需要管理上下文与记忆,以弥补长上下文生成的现有局限,同时最大化长程任务的成功率。既然人类能够维系一生的记忆,我在这里看到一个类比:上下文工程将会、也应该成为智能的核心部分,而不是停留在软件系统层。
3. 负面结果。 研究者有发表成功结果的激励,因此文献偏向成功案例。在海量数据(目前至少大多是人类创造的,lol)上训练出来的 LLM,可能由于数据中成功与失败案例的不平衡,不善于决定何时放弃一个假设、报告一个负面结果、甚至承认一次失败。研究用的 harness 应当让失败的尝试易于保存——从失败中学习,是收窄任务搜索空间的最好方式。
4. 多样性塌缩。 演化和 RL 循环倾向于利用已知的高回报模式。我们需要相应机制来防止种群塌缩成同一个方案的各种变体。这对开放式研究尤为关键——最好的路径在当前评估器下,最初可能反而看起来更差。
5. 奖励欺骗(reward hacking)。 自我改进循环会优化任何给它的信号。如果奖励来自单元测试,智能体可能对测试过拟合;如果来自一个评审模型,它可能学会专门针对这个评审的奖励欺骗技巧;如果来自基准分数,它可能钻基准数据的空子。
评估器和权限控制大概率应该位于演化 harness 的循环之外,配合留出测试、轨迹审计、以及在真正重要的决策点上的人工评审——监督能被放大和自动化到什么程度,仍是一个开放的研究领域。
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:从零复现 20 篇 ICML 2024 Spotlight 和 Oral 论文,包括理解论文贡献、开发代码库、成功执行实验。
- 每个复现任务被分解成更小的、可单独评分的子任务。
- 共 8,316 条评分细则(rubric),与论文作者共同制定。
- 当时最好的模型(
Claude 3.5 Sonnet,约 21%)没有超过 ML 博士生。 - 包含 PaperBench、PaperBench Code-Dev(轻量版)和 JudgeEval。
- CORE-Bench:评估已发表研究的计算可复现性。
- 基于计算机科学、社会科学和医学领域 90 篇科学论文的 270 个任务。
- 任务要求从提供的代码和数据中复现结果。
- 包含多个难度级别,以及纯语言和视觉-语言两类任务。
- 当时报告的最好智能体(
GPT-4o和GPT-4o-mini)在最难任务上只达到 21% 的准确率。
- ScienceAgentBench:评估用于数据驱动科学发现的 LLM 智能体。
- 从四个学科(数学、化学、生物、地理)的 44 篇同行评审论文中抽取 102 个任务。
- 覆盖这些领域的基础数据科学任务:数据处理、模型开发、数据分析和信息可视化。
- RE-Bench:在贴近现实的 ML 研究工程环境中,将前沿 AI 智能体与人类专家对比评估。
- 7 个具有挑战性的开放式 ML 研究工程环境。
- 每个环境 =(评分函数,初始解,参考解);每个环境都能用不超过 8 张 H100 GPU 运行。
- 示例:优化一个 kernel、跑一个 scaling law 实验、修复一个 embedding、微调 GPT-2 做 QA 等。
- 包含 61 位不同人类专家的 71 次 8 小时尝试数据。
- 人类专家在 82% 的 8 小时尝试中取得了非零分数;24% 达到或超过了强参考解。
- 在 2 小时预算下,最好的 AI 智能体得分是人类的 4 倍;但人类在更长预算下回报更好,在 8 小时和 32 小时设置下超过了智能体。
- MLE-bench:用离线 Kaggle 竞赛评估 ML 工程智能体。
- 包含从 Kaggle 精选的 75 个 ML 工程竞赛。
- 测试训练模型、准备数据集、跑实验、向打分脚本提交预测结果。
- 用 Kaggle 公开排行榜作为人类基线。
- 论文中最好的组合(
o1-preview+ AIDE 脚手架)在 16.9% 的竞赛中至少达到 Kaggle 铜牌水平。 - 包含资源扩展与数据污染分析。
- KernelBench:评估生成的 GPU kernel 的正确性与速度。
- 250 个 PyTorch 任务,评估 LLM 能否写出又快又对的 kernel。
- 评估指标 fast_p = 生成的 kernel 中「正确且比基线更快」的比例。
参考文献
[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, et al. “Anchored Self-Play for Code Repair.” ICML 2026.
[4] Zhao, et al. “Absolute Zero: Reinforced Self-play Reasoning with Zero Data.” arXiv preprint arXiv:2505.03335, 2025.
[5] Yuan, et al. “Self-Rewarding Language Models.” arXiv preprint arXiv:2401.10020, 2024.
[6] Chen, et al. “Self-Play Fine-Tuning Converts Weak Language Models to Strong Language Models.” ICML 2024.
[7] Zhang, et al. “Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models.” ICLR 2026.
[8] Ye, et al. “Meta Context Engineering via Agentic Skill Evolution.” arXiv preprint arXiv:2601.21557, 2026.
[9] Lee, et al. “Meta-Harness: End-to-End Optimization of Model Harnesses.” arXiv preprint arXiv:2603.28052, 2026.
[10] Lu, et al. “Towards end-to-end automation of AI research.” Nature, 651:914–919, 2026.
[11] Meng, et al. “ScientistOne: Towards Human-Level Autonomous Research via Chain-of-Evidence.” arXiv preprint arXiv:2605.26340, 2026.
[12] Kulikov, et al. “Autodata: An agentic data scientist to create high quality synthetic data.” arXiv preprint arXiv:2606.25996, 2026.
[13] Hu, Lu, and Clune. “Automated Design of Agentic Systems.” ICLR 2025.
[14] Madaan, et al. “Self-Refine: Iterative Refinement with Self-Feedback.” NeurIPS 2023.
[15] Zhang, et al. “AFlow: Automating Agentic Workflow Generation.” ICLR 2025.
[16] Zelikman, et al. “Self-Taught Optimizer (STOP): Recursively Self-Improving Code Generation.” COLM 2024.
[17] Zhang, et al. “Self-Harness: Harnesses That Improve Themselves.” arXiv preprint arXiv:2606.09498, 2026.
[18] Fernando, et al. “Promptbreeder: Self-Referential Self-Improvement Via Prompt Evolution.” arXiv preprint arXiv:2309.16797, 2023.
[19] Agrawal, A. et al. “GEPA: Reflective Prompt Evolution Can Outperform Reinforcement Learning.” arXiv preprint arXiv:2507.19457, 2025.
[20] Novikov, et al. “AlphaEvolve: A coding agent for scientific and algorithmic discovery.” arXiv preprint arXiv:2506.13131, 2025.
[21] Lange, Imajuku, and Cetin. “ShinkaEvolve: Towards Open-Ended And Sample-Efficient Program Evolution.” arXiv preprint arXiv:2509.19349, 2025.
[22] Wang, et al. “ThetaEvolve: Test-time Learning on Open Problems.” arXiv preprint arXiv:2511.23473, 2025.
[23] Zhang, et al. “Darwin Gödel Machine: Open-Ended Evolution of Self-Improving Agents.” arXiv preprint arXiv:2505.22954, 2025.
[24] Zhang, et al. “Hyperagents.” arXiv preprint arXiv:2603.19461, 2026.
[25] Yuksekgonul, et al. “Learning to Discover at Test Time.” arXiv preprint arXiv:2601.16175, 2026.
[26] Riaz, et al. “Epistemic Uncertainty for Test-Time Discovery.” arXiv preprint arXiv:2605.11328, 2026.
[27] Hebbar, et al. “SIA: Self Improving AI with Harness & Weight Updates.” arXiv preprint arXiv:2605.27276, 2026.
[28] Trehan and Chopra. “Why LLMs Aren’t Scientists Yet: Lessons from Four Autonomous Research Attempts.” arXiv preprint arXiv:2601.03315, 2026.
[29] Bubeck, et al. “Early science acceleration experiments with GPT-5.” arXiv preprint arXiv:2511.16072, 2025.
[30] Starace, et al. “PaperBench: Evaluating AI’s Ability to Replicate AI Research.” ICML 2025.
[31] Wijk, et al. “RE-Bench: Evaluating frontier AI R&D capabilities of language model agents against human experts.” ICML 2025.
[32] Chan, et al. “MLE-bench: Evaluating Machine Learning Agents on Machine Learning Engineering.” arXiv preprint arXiv:2410.07095, 2024.
[33] Chen, et al. “ScienceAgentBench: Toward Rigorous Assessment of Language Agents for Data-Driven Scientific Discovery.” ICLR 2025.
[34] Siegel, et al. “CORE-Bench: Fostering the Credibility of Published Research Through a Computational Reproducibility Agent Benchmark.” TMLR 2024.
[35] Ouyang, et al. “KernelBench: Can LLMs Write Efficient GPU Kernels?” arXiv preprint arXiv:2502.10517, 2025.