利用 Harness 工程实现自我提升 (Lilian Weng)

递归自我提升 (Recursive Self-Improvement，简称 RSI) 的概念可以追溯到 I. J. Good (1965)，他将“超智能机器 (ultraintelligent machine)”定义为一种能够在所有智力活动中超越人类，并能设计出更优秀的机器以改进自身的系统。Yudkowsky (2008) 则使用“递归自我提升”一词来指代一种特定的反馈回路：即 AI 利用其当前的智能，去改进用以产生该智能的认知机制 (cognitive machinery)。

在现代 AI 语境下，这种反馈回路可能直接体现为模型对自身权重的重写；但更广泛地，它表现为模型对训练流水线 (training pipeline) 和部署系统 (deployment system) 的优化，进而催生出在各项具有经济价值的任务中表现更出色的后继模型。前沿实验室的实践表明，AI 研发的迭代速度已被大幅加快（参见 Anthropic 和 OpenAI 的相关工作）。

我在此特别强调**“部署系统”**，是因为连接原生模型与真实世界上下文的这一中间层，其重要性似乎不亚于模型本身的基座智能（即预训练结束后的即刻评测表现）。正如 Claude Code 和 Codex 等大获成功的编程智能体所示，Harness 是 AI 部署的核心组件。所谓 Harness（外壳系统），是指围绕基座模型构建的系统，负责编排整个执行流程，决定模型如何思考与规划、如何调用工具与采取行动、如何感知并管理上下文、如何存储交付物 (artifacts)，以及如何评估产出结果。

本文将专注于 Harness 工程及其对 RSI 贡献的相关研究。近期关于自主科研 (Auto-research)、自我提升智能体 (Self-improving agents) 以及演化程序搜索 (Evolutionary program search) 的许多工作，基本上都可以围绕这一核心议题展开。其他关于模型自博弈 (Self-play)、合成数据、测试时训练 (Test-time training) 以及更广泛的持续学习 (Continual learning) 方面的工作也与 RSI 的宏伟愿景相契合（例如 Yuan 等人，2024、Chen 等人，2024、Zhao 等人，2025、Choi 等人，2026），但这些并非本文的讨论重点。

Harness 设计模式 (Harness Design Patterns)

与早期经典的智能体框架（即“智能体 = LLM + 记忆 + 工具 + 规划 + 行动”）相比，Harness 工程额外涵盖了工作流设计（例如循环工程 loop engineering）、评估机制、权限控制以及持久化状态管理。它不再局限于单纯编写提示词模板 (Prompt templates)，而是更接近于运行时 (Runtime) 和软件系统层面的设计：即具体定义了模型如何观察、行动、记忆、自我纠错和自我迭代。

为了便于泛化与复用，此类设计应当刻意保持简单与通用，并可参考现有软件工程实践，以更好地释放模型在预训练阶段积累的先验知识。操作系统 (OS) 与 Harness 之间存在极强的类比关系：类似于 OS，Harness 应当将复杂的底层逻辑封装起来，同时保留简洁易用的交互接口。与此同时，配置文件、工具接口及其他协议也正在整个行业中逐步走向标准化。

模式一：工作流自动化 (Workflow Automation)

定义一个让模型能在其中进行操作、测试与迭代的工作流，是实现自动化的核心设计。安德烈·卡帕西 (Andrej Karpathy) 的 autoresearch 仓库 (https://github.com/karpathy/autoresearch) 就是如何构建这种自动化工作流的一个极具启发性的极简范例。一个常见的工作流会遵循一个目标导向的闭环：规划、执行、观察/测试、改进，并再次执行，直到达成最终目标。在此过程中，系统可能会主动向用户发起请求，以厘清任务的具体定义 (task specification) 或执行偏好。

简化的 Codex 智能体闭环：智能体调用各种工具，而工具返回的响应会直接影响模型的下一步生成。（图片来源：OpenAI codex agent post）

该工作流设计还强调：模型应当主动分析自身的执行轨迹 (trajectories) 和失败案例，然后通过“智能体运行时 (agent runtime)”而非静态的提示词模板来对自身的进展进行迭代。

模式二：文件系统作为持久化内存 (File System as Persistent Memory)

在复杂长任务的智能体系统中，一个经常出现的模式是：通过简单的控制逻辑实现对复杂状态和丰富交付物 (artifacts) 的精细管理。Harness 不应该在上下文窗口中承载整个工作流和所有日志；相反，它应当将持久的状态保存在文件系统里。在长时间跨度的智能体推演 (long-horizon rollout) 中，诸如实验日志、代码差异 (diff)、论文摘要、错误追踪信息以及历史推演轨迹等产物，其长度往往会远远超出模型预训练时所能容纳的上下文窗口。

学习如何对文件系统进行读取、写入和编辑（通常是通过 bash 命令）是 LLM 的一项基础核心技能。因此，直接以文件这种简单形式来管理持久化内存，可以自动且无缝地从底层基座模型核心能力的不断提升中获益。

模式三：子智能体与后台任务 (Sub-agent and Backend Jobs)

Harness 能够派生出多个子智能体并行执行，并对后台异步作业进行追踪。当主智能体需要探索多种假设、并发运行实验或在不污染主上下文的前提下派发独立的子任务时，这种设计非常有用。此时，父智能体需要扮演一个微型的进程管理器 (process manager)：启动任务、检查日志、取消失败的运行，并将执行结果合并回主智能体线程。

这里的核心设计决策是让并行执行变得显式且可审计 (explicit and inspectable)。如果子智能体的输出仅仅存在于临时性的聊天上下文中，它们会很快随着上下文窗口的滚动而失效并变得不可见。如果将它们以文件、日志和状态记录的形式进行存储，模型就能够在中断后进行状态恢复，并对其自身的历史执行过程进行推理。

案例研究：编程智能体 Harness (Case Study: Coding Agent Harness)

目前主流编程智能体（例如 Claude Code, Codex, OpenCode 以及 Cursor 等风格的智能体）的核心接口和工作逻辑已经基本稳定。它们通常采用如下的循环：

在获得了一系列工具的调用权限后，编程智能体便能像配备了 IDE 的人类开发人员一样，在给定的代码库中进行开发和调试。

（以下并非完整列表，仅作演示之用。若有兴趣可参阅此项目）

工具分类 (Group)	工具定义 (Tool definitions)
文件系统 (File system)	- 文件发现: `glob`, `grep`, `ls` - 文件读取: `read`, `read_many` - 文件修改: `write` (新建完整文件); `edit` (字符串精确匹配替换); `multi_edit`; `apply_patch` (应用结构化的 patch/diff)
Shell 执行 (Shell execution)	运行终端命令: `bash`, `PowerShell`
外部输入输出 (IO)	`lsp` (语言服务协议接口), 以及 git 工具 (如 `git_status`, `git_diff`, `git_commit`)
外部上下文 (External context)	MCP (模型上下文协议) 工具, 技能集 (Skills)
网页搜索 (Web search)	`web_search`, `web_fetch`, 浏览器交互工具
中间产物 (Artifacts)	读取文档、图片; 生成 HTML、图片
后台进程 (Backend processes)	如: `CronCreate`, `CronDelete`, `CronList` 等后台定时任务
智能体指派 (Agent delegation)	如: `spawn_agent`, `resume_agent`, `wait_agent`, `list_agents`, `close_agent`, `interrupt_agent` 等智能体生命周期管理工具

Harness 中间层 vs 基座智能？ (Harness Layer vs Core Intelligence?)

目前很难预测未来的 RSI（递归自我提升）在多大程度上会依赖于 Harness 工程，但在短期内，RSI 的实现路径不太可能一上来就是由模型直接重写其自身权重。我对近期实际可行路径的预测如下：

Harness 工程将向元方法论 (meta-methodology) 方向演进（即优化目标不再只是答案本身，而是“获取更好答案的系统机制”）。Harness 系统本身将成为优化对象，启发式规则会减少，通用机制会增多。
相应地，成熟的 Harness 可以为模型自我提升闭环开启自动科研 (auto-research)；而更聪明的模型又反过来避免了 Harness 的过度工程化 (overengineering)，从而保证了系统的可持续性。

最终，许多关于 Harness 的优化可能会被内化 (internalized) 到核心模型的行为中，但与外部上下文和工具的接口则应继续保留。这类似于我们在提示词工程 (prompt engineering) 中看到的较为温和的演进模式：随着指令微调 (instruction tuning) 和模型推理能力的提升，手工编写提示词的技巧逐渐退居次要地位，但定义明确的目标、约束条件、上下文和评估指标的需求并未消失。

Harness 自动优化 (Harness Optimization)

在 Harness 系统中，被优化对象的发展脉络大致为：指令/提示词 (prompts) → 结构化上下文 → 工作流 (workflow) → Harness 源代码 → 优化器代码 (optimizer code)。随着模型变得更加智能和强大，我们的优化目标变得更加复杂，采用的方法也更为通用。

上下文工程 (Context Engineering)

随着智能体执行任务的深度（Horizon）大幅增加，如果只是简单地将所有工具响应和模型生成的内容不断追加到上下文里，很快就会导致上下文规模失控。上下文管理是一个中间层，负责为 LLM 构建更有结构、更为精炼的上下文，并管理持久状态。毫无疑问，长上下文（long-context）的相关研究将继续推进，但就目前而言，长上下文的实际利用率与上下文工程往往是交织在一起的。

智能体上下文工程 (Agentic Context Engineering，简称 ACE； Zhang 等人, 2025) 将上下文视为不断演进的“运行手册 (playbook)”，而非一条不断被拉长的提示词。它包含三个核心组件，用以维护一个由要点 bullet points 构成的结构化上下文手册，每个要点都带有一个唯一标识符（ID）及对应描述。

生成器 (Generator)：在参考上下文要点的前提下生成具体的任务执行轨迹。
反射器 (Reflector)：从成功和失败的轨迹中提炼出洞察与教训。
策展器 (Curator)：以增量、逐项条目的形式来更新结构化的上下文。

智能体上下文工程 (ACE) 框架示意图。（图片来源：Zhang 等人, 2025）

为了防止在迭代重写过程中发生上下文坍塌 (context collapse) 和“字数偏见 (brevity bias)”，ACE 的一个核心设计抉择是让策展器不去直接重写整个 prompt 块。相反，它输出一组形如 (标识符, 描述) 的结构化要点，并基于确定性逻辑将这些要点合并到结构化上下文日志中。这些上下文条目会定期进行精简和去重。

尽管 ACE 能够通过任务执行来学习经验，这让我们朝着“自我管理记忆”迈进了一步，但其更新规则和整体工作流依然是手工设计的。为了实现更深层次的自我提升闭环，元上下文工程 (Meta Context Engineering，简称 MCE； Ye 等人, 2026) 将**机制（如何管理上下文）与内容（上下文中有什么）**进行了分离，在元优化（meta-optimization）层级运行技能演进，在基础层级运行上下文优化。

一个 MCE 技能 $s \in \mathcal{S}$ 定义了一个上下文函数 $c_{s} = \left(\rho_{s} , F_{s}\right)$ ，并将输入 $x$ 映射到上下文 $c = F_{s} \left(x ; \rho_{s}\right)$ ，其中：

$\rho_{s} = \left\{\rho_{1} , \ldots , \rho_{m}\right\}$ 为静态组件（如提示词、知识库、代码库）。
$F_{s} = \left\{F_{1} , \ldots , F_{k}\right\}$ 为动态操作算子（如搜索、筛选、过滤、格式化）。

这种双层优化 (bi-level optimization) 的目标是，在训练数据上寻找给定技能 $s$ 下的最佳上下文 $c_{s}^{*}$ ，而外层循环则是在验证集上寻找能够带来最佳性能的优选技能 $s^{*}$ ：

\begin{aligned} \text{Inner: } & c_{s}^{*} = \arg\max_{c_{s}} J_{\text{train}}(c_{s}; s) \\ \text{Outer: } & s^{*} = \arg\max_{s \in \mathcal{S}} J_{\text{val}}(c_{s}^{*}) \end{aligned}

技能数据库记录了历史的技能、上下文函数和对应的评估指标 $\mathcal{H}_{k - 1} = \left\{\right. \left(s_{i} , c_{i} , J_{i}^{\text{train}} , J_{i}^{\text{val}}\right) \left.\right\}_{i = 1}^{k - 1}$ 。元级智能体会对先前的技能进行智能体层面的交叉操作 (crossover)，以针对给定任务 $\tau$ 生成新技能 $s_{k}$ ： $s_{k} = \text{crossover} \left(\tau , \mathcal{H}_{k - 1}\right)$ 。

随后，基础级的上下文工程师会执行技能 $s_{k}$ ，并在当前技能的指导下，基于执行反馈 $\mathcal{R}_{k}$ 来学习上下文函数： $c_{k} = \text{engineer} \left(\tau , s_{k} ; c_{k - 1}^{*} , \mathcal{R}_{k}\right)$ 。

元上下文工程 (MCE) 框架：元级的技能演进用于搜索上下文管理机制，而基础级则负责优化任务本身的上下文。（图片来源：Ye 等人, 2026）

MCE 并不像 ACE 那样强制使用启发式规则来组织上下文结构。它使用自由格式的技能来存储任务最核心的知识，并将技能和基于技能约束的上下文进行联合迭代演进。在实现上，上下文函数 $c$ 被实例化为特定目录下一系列文件的集合，包含静态组件（skill.md）和动态组件（上下文和数据执行记录）。元级和基础级的优化过程都是在配备了如下标准工具集的智能体编程环境中运行的：

\mathcal{T} = \left\{\mathtt{Read} , \mathtt{Write} , \mathtt{Edit} , \mathtt{Bash} , \mathtt{Glob} , \mathtt{Grep} , \mathtt{TodoWrite}\right\}

Meta-Harness (Lee 等人, 2026) 则更进一层：其优化对象是代码本身，即通过编写和优化代码来决定哪些信息应当被存储、检索并呈现给模型。其名字中的“Meta-”代表它是一个“用于优化 Harness 的 Harness”。

Meta-Harness 外层循环优化算法流程。（图片来源：Lee 等人, 2026）

提出新 Harness 设计的提议器 (proposer) 本身就是一个编程智能体，其最终输出是位于帕累托前沿 (Pareto frontier) 的一组候选 Harness 集合。

整个执行历史都可以通过文件系统进行访问，因此编程智能体可以使用类似于 grep 或 cat 的命令来阅读这些历史，而不是将所有内容全部塞进单次的提示词上下文中。
提议的新 Harness 在文件系统中以字典的形式存储，包含其自身的源代码、评分、运行轨迹以及状态更新信息。
Meta-Harness 闭环会迭代地产生新的 Harness 候选，最终只有合格的才会被保留。

Meta-Harness 在以下任务上的性能表现：（左）小迭代次数下的文本分类任务；（右）TerminalBench-2 基准测试。值得注意的是，在 TerminalBench-2 实验中，搜索是在两个极其强劲的基底 Harness（Terminus-KIRA 和 Terminus-2）之上初始化的。（图片来源：Lee 等人, 2026）

尽管如此，其揭示的核心经验是显而易见的：一旦 Harness 的架构设计变成了一个可执行的搜索空间，一个足够强大的编程智能体就能够像人类工程师一样去探索和利用这个设计空间。

工作流设计 (Workflow Design)

Harness 工程中的工作流设计可以由领域专家手工定制。以自动科研为例，研究界已提出并测试了多种系统架构。例如 AI Scientist 系统 (Lu 等人, 2026) 构建了一条涵盖提出研究设想、编写实验代码、运行实验、分析结果、撰写论文草稿到执行同行评审的完整流水线。Meng 等人 (2026) 则在 ScientistOne 系统中将可验证性作为核心设计约束，要求文中的每一个论断（包括引用、数据、方法和结论）都必须追溯到确凿的证据源，并通过“证据链 (Chain-of-Evidence)”校验进行严格审计。

AI Scientist 系统关于设想生成、实验、论文撰写和评审的流水线流程图。（图片来源：Lu 等人, 2026）

Autodata 智能体 (Kulikov 等人, 2026) 被设计用于担任生成训练与评估数据的数据科学家。主智能体管理着一个提出问题的挑战者 (challenger)、一个弱解题器 (weak solver)、一个强解题器 (strong solver) 以及一个校验器/裁判 (verifier/judge)，旨在合成处于“恰到好处”难度级别的任务数据，即强解题器能成功解答，但弱解题器会失败。

在 Autodata 中，挑战者的提示词会根据解题器和校验器的反馈进行迭代更新。该系统的局限性在于，合成的任务仅被用于微调弱解题器，而没有微调强解题器；如果这个闭环无法迭代地提升强基座模型本身，那么它实际上更像是针对生成的提示词分布进行的一种间接蒸馏，所具有的 RSI 色彩也相对较淡。

基于挑战者、解题器和校验器角色的 Autodata 智能体数据合成工作流设计图。（图片来源：Kulikov 等人, 2026）

工作流的设计空间是极其庞大的，我们很自然地会把工作流设计看作一个搜索问题。因此，我们应该能够通过算法找到优良的方案，而非完全依赖手工雕琢。沿着这一方向，智能体系统自动设计 (Automated Design of Agentic Systems，简称 ADAS； Hu 等人, 2025) 将智能体设计本身形式化为一个优化问题——即“元智能体搜索 (meta-agent search)”，由一个元智能体来不断提出新的智能体工作流设计方案。

初始化存档：使用包含思维链 (CoT) 和自我修正 (self-refine) 等基础工作流的智能体系统初始化一个设计存档。
生成新方案：元智能体以代码形式编写新的智能体架构，其灵感来源于存档中的历史方案。
- 元智能体首先会生成新工作流的高层逻辑描述，然后将其实现为具体的代码。
- 随后，生成的程序草稿会由元智能体进行两次自我修正 (self-refine) 校验（即先让模型对生成的代码进行自我反馈，再让同一个模型根据反馈去优化其输出; Madaan 等人, 2023），以检查其新颖性。
评估与更新：评估新生成的候选方案，并将其中成功的方案重新收录进存档中。
循环往复：重复上述步骤 2-3，直至达到最大迭代限制。

ADAS (智能体系统自动设计) 的架构示意图。（图片来源：Hu 等人, 2025）

AFlow (Zhang 等人, 2025) 将智能体工作流表示为一张有向图，其中的节点代表调用 LLM 的动作，边则通过代码实现逻辑控制。其工作流优化算法基于蒙特卡洛树搜索 (MCTS)：

初始化：用一个基础模板初始化搜索树中的起始工作流节点 $W_{0}$ 。
选择：结合当前节点评分与均匀探索策略（软混合策略），选择树中的一个工作流节点。
扩展：要求 LLM 根据该节点的评估表现，生成一个优化后的新工作流变体。
模拟与评估：在任务上运行并评估这一新工作流的性能。
回溯更新：如果在预设的 $N$ 轮运行中新工作流表现出了性能提升，则将其作为新节点添加回搜索树中。
终止条件：重复步骤 2-5，直到前 $k$ 个工作流的平均性能达到饱和，或消耗完全部的搜索预算。

基于候选工作流树的 AFlow 优化过程示意图。（图片来源：Zhang 等人, 2025）

AFlow 在问答、代码和数学等任务上的简单实验表明，相比于手工设计的工作流以及 ADAS，AFlow 能够带来相当显著的性能提升。

AFlow 与手工方法及 ADAS 的实验对比图。（图片来源：Zhang 等人, 2025）

自我提升的 Harness (Self-Improving Harness)

无论是上下文工程还是工作流设计，都仅仅是整个 Harness 的一部分。我们需要在庞大的设计空间中进行全局搜索，将上下文管理逻辑、工作流、权限控制及其他诸多 Harness 组件进行协同优化。正如 Meta-Harness, ADAS 和 AFlow 等研究所昭示的，✨代码 (code)✨ 是定义程序与系统的通用语言。简单来说，Harness 本质上就是一段代码，它规定了提示词、工具调用、子智能体、控制流、记忆以及工作流逻辑如何协同运作。如果 LLM 能够直接优化执行这些智能体的底层代码，那么它所能触及的设计空间将远远大于传统的纯手工编写提示词。

自我学习优化器 (Self-Taught Optimizer，简称 STOP； Zelikman 等人, 2023) 是递归脚手架/外壳优化 (scaffolding improvement) 的早期典型案例之一。一个处于 $t=0$ 步的种子优化器 $I_{0}$ 接收初始解 $s$ 、效用函数 (utility function) $u$ 以及黑盒语言模型 $M$ ，并输出一个改进的解 $s^{'}$ ，即 $s^{'} = I \left(u , s ; M\right)$ 。STOP 的目的并不是直接去优化 $s$ ，而是为了优化这个优化器 $I$ 本身。

首先，我们将“元效用 (meta-utility)”定义为给定优化器函数 $I$ 在一组下游任务集合 $\mathcal{D}$ 上的平均表现：

\hat{u} \left(I\right) \triangleq \frac{1}{\left|\mathcal{D}\right|} \mathbb{E}_{\left(u , s\right) \sim \mathcal{D}} \left[u \left(I \left(u , s ; M\right)\right)\right]

由于优化这个优化器函数本身就是一个优化问题，我们可以基于由元效用度量的 $I_{t-1}$ 的表现，通过自我提升更新，递归地得到一个新版本的 $I_{t}$ ：

I_{t} = I_{t - 1} \left(\hat{u} , I_{t - 1} ; M\right)

STOP 算法伪代码图。（图片来源：Zelikman 等人, 2023）

在 Zelikman 等人 (2023) 的实验中，优化后的优化器自行探索出了许多策略，如遗传算法、模块拆解优化、多臂老虎机提示词选择、模拟退火、动态调整温度参数以及束搜索/树搜索等。这与如何将 Harness 工作流转化为一个可优化对象的逻辑如出一辙。

由 STOP 自动发现的自我提升策略示例。（图片来源：Zelikman 等人, 2023）

然而，他们发现的一个警示性结果是：STOP 在使用 GPT-4 进行迭代时确实提升了下游的平均表现，但在使用更弱的模型（如 GPT-3.5 和 Mixtral）时性能反而出现了衰退。这说明单靠递归的系统架构是远远不够的。基座模型自身必须具备足够强大的智能门槛，才能切实优化这套系统机制。这意味着优化 Harness 能够为模型提供更出色的外部加持，但基座智能本身依然是至关重要的核心。

更近期的研究 Self-Harness (Zhang 等人, 2026) 则让 LLM 智能体通过一个“提议-评估-接受 (propose-evaluate-accept)”闭环来改进其自身的 Harness。

Self-Harness 采用由漏洞挖掘、受限方案提议和评估验证构成的循环来更新其 Harness。（图片来源：Zhang 等人, 2026）

Self-Harness 的优化闭环包含三个阶段：

漏洞挖掘 (Weakness mining)：将失败案例聚类为基于校验器底层反馈的失败模式。
- 利用当前版本的 $h_{t}$ 在任务上运行评估，并收集所有执行轨迹 (traces) 进行分析。
- 注意，在表象上，两次运行可能会在错误日志中共享相同的校验结果（如超时或缺失产物），但其实际底层成因大相径庭。因此，我们需要一份包含丰富状态的“失败档案”——记录最终校验器层面的诱因、相关智能体行为的因果状态以及轨迹所暴露的抽象智能体机制，从而揭示失败的根本原因。
方案提议 (Harness proposal)：根据挖掘出的失败模式，提出具有明确边界的 Harness 修改方案。
- 依然调用相同的模型（在 $h_{t}$ 约束下）来充当提议器。
- 系统为模型提供了一个受限的上下文：(1) 当前 Harness 中可供编辑的接口代码，(2) 评估系统整理的校验级失败模式，(3) 必须予以保留的历史成功用例记录，(4) 先前尝试过但失败的修改方案摘要。
- 系统的修改应当优先针对那些频繁出现、可被解决的错误模式（而非特定任务的高难关卡），并且能够通过局部细微修改予以解决。
- 候选的 Harness 修改方案应当保持差异度与多样性。
方案验证 (Proposal validation)：对修改方案进行评测与合并，以生成新版的 Harness $h_{t+1}$ $h_{t + 1}$ 。
- 所有的候选修改都会通过回归测试（包含验证漏洞是否被解决的内部集 $D_{\text{in}}$ ，以及验证是否引入了新问题的外部集 $D_{\text{out}}$ ）进行评估。
- 候选修改只有在内部集和外部集上都没有发生性能衰退（即无 Regression）时，才会被接纳。
- 被接受的方案会被合并并更新为新版本 $h_{t+1}$ ，而被拒的方案则只会被记录在日志里，不会更改当前运行的 Harness。

在 Terminal-Bench-2 上分别以 MiniMax M2.5、Qwen3.5-35B-A3B 和 GLM-5，Self-Harness 被证实能够针对不同基座模型的独特缺陷，学习到模型特异的 (model-specific) Harness 操控指令，从而提升外部测试集的任务通过率。

然而，Self-Harness 这类工作确实引发了我的隐忧：如果允许一个程序直接编辑操作系统层，那么传统的抽象隔离边界就会被打破。可供编辑的暴露面需要经过极其周密的设计，而且安全与权限控制层必须完全独立于该迭代闭环之外。关于奖励黑客/奖励篡改 (reward hacking) 的所有经典挑战，在此依然严峻。

演化搜索 (Evolutionary Search)

演化搜索是一种受到自然选择启发的优化算法（参见我之前关于演化算法的博客）。它通过对当前解的种群进行变异，并在种群中淘汰表现不佳的个体、保留“适应度 (fitness)”高的解来进行演化。在以下情况中，演化搜索非常有用：(1) 搜索空间极其庞大或极不规则；(2) 难以通过梯度直接进行优化，但评测候选方案却相对容易。对 Harness 的搜索恰好高度契合这两个特点。

在过去的研究中，演化搜索已被应用于提示词工程中。例如 Promptbreeder (Fernando 等人, 2023) 通过丰富的变异操作来优化针对具体任务的提示词，而且有趣的是，用于变异任务提示词的“变异提示词本身”也是通过演化不断优化提升的。GEPA (Agrawal 等人, 2025) 将基于反思 (reflection) 的提示词机制与演化搜索相结合，使用针对试错轨迹的自然语言反思来提出提示词的更新策略。

Novikov 等人 (2025) 推出了 AlphaEvolve，这是一个针对编程智能体的演化搜索系统。它维护着一个候选程序池，并调用权重固定的 LLM 生成 diff 代码修改以进行优化。随着系统反复评估生成的后代程序并保留表现出色的程序，它会随着时间的推移不断发现更优的解法。

AlphaEvolve 运行机制图解。（图片来源：Novikov 等人, 2025）

在 AlphaEvolve 的系统设计中，有几处细节非常关键：

提示词中融合了父代程序、评测得分、演化指令以及部分元信息。
编程智能体具有访问完整代码库的权限，但是需要优化的目标代码区域被显式地标记为 # EVOLVE-BLOCK-START 和 # EVOLVE-BLOCK-END。
元提示词 (Meta-prompt) 能够与具体的执行指令和上下文信息（由 LLM 推荐）共同演进，其方式类似于我们对解题程序的演化。

消融实验证实了演化流程、提示词上下文、元提示词、全局文件演进以及更强 LLM 配合的实际价值。

AlphaEvolve 各项核心设计的消融实验对比图。（图片来源：Novikov 等人, 2025）

近期的演化变体如 ThetaEvolve (Wang 等人, 2025) 将演化搜索与强化学习 (RL) 以及上下文学习 (ICL) 相结合。而 ShinkaEvolve (Lange 等人, 2025) 则引入了三个新组件，以大幅提升 LLM 的样本采样效率：

更高效的样本探索：设计了能够均衡个体性能排行与后代繁衍数量的父代采样策略。
基于代码新颖性的拒绝采样：计算基于嵌入向量的余弦相似度，抛弃与当前种群中已有代码过于相似的候选方案。
优秀范式提炼：在元草稿箱 (meta-scratchpad) 中提炼成功用例的优秀逻辑，用以指导后续的变异方向。

与上述侧重于“具体方案优化”的方法不同，达尔文哥德尔机 (Darwin Gödel Machine，简称 DGM； Zhang 等人, 2025) 明确将优化目标锁定在可编辑的 Harness 代码仓库上——通过引入基于 LLM 的编程智能体，允许其自行重写自身的 Harness 代码。控制新智能体如何修改现有智能体以派生变体，这一过程在 DGM 论文的后续研究中（即 Hyperagents; Zhang 等人, 2026）由一个元智能体来实现。

初始化：在智能体池中初始化一个编程智能体。
父代选择：在每次迭代中，以与个体性能成正比、与其已繁衍子代数成反比的概率来挑选父代智能体，进行修改并分叉 (branch off) 繁衍新版本。
代码演进：选中的父代智能体会审查自身的基准评估日志，随后对自身的 Harness 代码库提出优化，从而生成新版编程智能体。代码编辑主要通过两个基础工具实现：(1) bash (参数: 终端命令) 和 (2) editor (参数: 文件查看/创建/修改)。
验证与入库：评估新生成的编程智能体，只有性能达到阈值的优胜者才会被重新收录进智能体池。
循环：重复上述步骤 2-4，直至满足特定终止条件。

DGM 代表了在基座模型固定的前提下对 Harness 系统的纯代码演化。在以 Claude 3.5 Sonnet 为基座 LLM 并且只提供极简初始 Harness 配置的实验中，DGM 自动搜索出的智能体系统性能已经比肩或超越了手工精心设计的产品级智能体（在 SWE-bench Verified 上的通过率从 20% 提高至 50%，在 Polyglot 上从 14.2% 提高至 30.7%）。

此类算法非常适用于可自动评估且适应度极易量化的领域，例如矩阵乘法、GPU 内核算子优化、算法编程竞赛以及数据中心资源调度等。然而，在那些评估反馈极其缓慢、指标模糊或主要依赖启发式判定的领域，该演化机制会表现得非常吃力。此外，演化过程中的计算开销与实际收敛效率也一直是难以忽视的核心痛点。

协同基座模型权重进行联合优化 (Joint Optimization with Model Weights)

Harness 的演化主要优化了围绕模型的“非参数系统 (non-parametric system)”。为了实现真正意义上的全局自我提升，我们可以完全允许模型在优化外壳系统的同时，同步更新其自身的参数权重。模型权重的更新既可以通过改善整体训练流水线来完成，也可以在测试期通过持续学习来实现。有关“持续学习”的专题非常宏大，值得我们在未来专门写一篇文章进行探讨。

SIA (Hebbar 等人, 2026) 是将 Harness 改进与模型参数更新整合在同一个优化闭环中的早期探索，其系统包含如下三个设计组件：

元智能体 (Meta-Agent)：提出初始的 Harness 设计方案。
任务智能体 (Task-Specific Agent)：执行具体任务。
反馈智能体 (Feedback-Agent)：根据最近的任务运行轨迹，抉择是应该去更新 Harness 逻辑，还是应该直接微调更新模型权重。

SIA 中的反馈智能体 (Feedback-Agent) 负责决定下一步执行哪种类型的迭代优化。（图片来源：Hebbar 等人, 2026）

SIA 实验中的一些混杂变量使得其最终结论变得难以解读。例如，任务智能体所采用的底层模型能力远远逊色于元智能体和反馈智能体（gpt-oss-120b vs Claude Sonnet 4.6），且其实验中设置的对比基准（baselines）过于薄弱，难以与现有的其他同类方案进行清晰的横向对比。我认为这一探索方向极具启发性，但目前的实证证据依然是暂时的。诸如训练稳定性以及古德哈特效应 (Goodhart's Law) 等挑战，依然悬而未决。

未来面临的挑战 (Future Challenges)

以 AI Scientist 为代表的系列工作有力地表明，专家手工设计的 Harness 能够协同并处理自动科研流的大部分核心环节，这已在“全自动论文撰写”中得到了验证。然而，批量产出论文并不等同于真正实现了科学发现。系统或许能够生成一份看似合理的论文草稿，但其中可能依然充斥着捏造的引文、不符本意的技术路线漂移或漏洞百出的实验数据。

Trehan 与 Chopra (2026) 测试了 LLM 在仅配备极简脚手架和基本工具（如 read_file, write_file, llm_search, list_files）的前提下，能否独立完成从学术构想到撰写论文的全过程。每个构想都有一个专属的工作空间，智能体可以在此读写文档并将其作为上下文。他们针对三个研究领域（世界模型、多智能体强化学习、AI 安全与对齐）进行了评估，每个领域都提供了 45-50 篇高质量的基础论文以启发新设想。然而，在所有的尝试中，仅有 4 个设想通过了人类专家的筛选被允许跑完完整流水线，其中更只有 1 个 被真正实现为一份完整的学术论文。他们在实验中观察到了 6 类高频出现的失效模式：

训练数据路径依赖偏见 (Bias toward training-data defaults)：倾向于使用过时的代码库、已被废弃的命令、标准的模板格式，或者依赖不符合当前实际代码库或数据集的假设。
执行压力下的实现漂移 (Implementation drift under execution pressure)：当实际的代码工程实现变得极其复杂时，模型可能会主动偏向一种平庸但省事的通用方案，而非真正践行最初提出的科学设想。
记忆与上下文衰退 (Memory and context degradation)：长周期的项目会丢失许多关键细节，除非将系统日志作为持久产物显式地写盘保存。
盲目乐观 (Over-optimism)：即便实验结果混乱或基本失败，模型依然倾向于宣告成功。这与 Bubeck 等人 (2025) 观察到的"P 值操纵与尤里卡时刻幻觉"模式如出一辙——模型在输出全为噪声时，仍会引入"数值创可贴"并径直宣称大获全胜。
领域经验不足 (Insufficient domain intelligence)：模型缺乏大量隐性行业经验知识 (Tacit Craft Knowledge)，例如：评估实现的复杂度上限、判断实验结果的合理性，或明确哪些对照基线才真正具有说服力。
缺乏科学品味 (Weak scientific taste)：实验流程或许可以顺利运行，但在立意上根本无法回答所针对的核心科学问题。

在迈向完全递归自我提升 (RSI) 的征程上，研究人员已取得了令人瞩目的进展，但目前仍有数个核心瓶颈悬而未决：

1. 评估器模糊且薄弱 (Weak and fuzzy evaluators)：许多科研论断并不存在能够快速精确判定的硬性验证器，许多真实世界的复杂任务亦是如此。目前的自我提升机制主要在评测指标清晰客观的任务上表现最佳，这与强化学习 (RL) 的适用局限高度相似。

科研品味、新颖度以及长期的科学价值都是极难被量化的。例如，“科研品味”往往融合了问题的切入视角、实验结构设计，以及辨识哪些意外的实验现象值得穷追猛打，而哪些挫败应当果断放弃并换路尝试的专业直觉。

2. 上下文与记忆的生命周期 (Context and memory lifecycle)：随着 AI 智能体变得越来越自主和独立，其产生的记忆体量也将呈现爆发式增长。一个优秀的 Harness 必须妥善管理上下文和内存结构，以弥补当前长上下文生成方面的局限，同时最大化长周期任务的成功率。鉴于人类能够维持伴随一生的长效记忆，我认为在这里存在一个显而易见的类比：上下文工程 (Context Engineering) 最终必将成为模型自身底层智能的核心组成部分，而不会永远仅仅停留在软件系统的外挂外壳层。

3. 负面结果/失败用例的失落 (Negative results)：由于学术界更倾向于发表成功的研究，现有的文献数据天然偏向于成功案例。主要在人类历史数据（至少目前主要是人类创造的，哈哈）上训练出来的 LLM，可能非常不擅长抉择何时该放弃某项假设、何时该汇报“负面结果”，甚至由于训练数据中成功/失败样本比例的严重失调，导致其难以坦白承认失败。一个优良的科研 Harness 应该建立让失败尝试得以轻松记录和保存的机制，因为从失败中吸取教训是缩减任务搜索空间的最佳途径。

4. 多样性塌缩 (Diversity collapse)：演化算法和强化学习闭环天然具有过度利用 (exploit) 已知的高奖励行为模式。我们需要特定的探索策略和机制，以防止解的种群坍缩成同一种方案的各种微调变体。这在开放式研究中尤为关键，因为许多颠覆性的最优路径在早期评估时，其设计在初期看起来往往反而逊于平庸的常规方案。

5. 奖励黑客/奖励篡改 (Reward hacking)：自我提升闭环网络往往会无情地针对分配给它的任何评估信号进行极致压榨优化。如果奖励机制来自单元测试，智能体可能会产生针对测试集的过拟合；如果信号来自一个裁判模型 (Judge model)，智能体可能会学到专门迎合该裁判特定盲点的奖励黑客手段；如果是根据基准测试得分来评判，它可能会去极力钻测试集本身特定组织缺陷的漏洞。

因此，评估系统与权限控制机制应该完全隔离于演化 Harness 的闭环之外，在关键的决策关卡引入外部测试集、运行轨迹审计以及必要的人工审查——如何安全地扩大监管规模并实现高度自动化，依然是当下非常前沿的研究课题。

6. 长效成功的定义限制 (Long-term success)：外部优化环往往依赖于我们在训练沙盒中可以模拟的、短期单次执行奖励信号。

以编程智能体为例。编程智能体虽然确实大幅提高了软件工程师的日常产出效率，但是目前大多数的优化目标依然过于聚焦短期。它通常能够迅速解决当前的具体 Bug，但是我们很难保证它会去考虑和保护由成百上千名工程师协同维护的代码库的长期健康状态。在标准的、基于沙盒的 RL 训练中，像代码的维护性、架构边界、迁移成本、向后兼容性以及未来的调试负担等维度，几乎是完全无法被捕获和优化的。

7. 人类扮演的角色 (The role of humans)：人类应当上升到更高维的控制栈层（Move up the stack），而不是被彻底剔除出这一反馈闭环。这意味着人类应当在恰当的时间、恰当的抽象维度上提供全局监管；我们的系统设计应当仔细思考何时以及如何引入这些监督和决策节点。

上述列举的许多核心瓶颈都需要人类的反馈和把关。毕竟，我们开发科技的初衷是为了给人类创造更好的未来，而非背道而驰。

引用方式 (Citation)

请按如下格式引用本文：

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/"
}

附录：一些实用的基准评测集 (Appendix: Some Useful Benchmarks)

PaperBench：评测从零复现 20 篇 ICML 2024 Spotlight 和 Oral 论文的能力，包括理解论文核心贡献、从零编写代码库并成功运行实验。
- 每个复现任务都会被分解成更小的、可被单独评分的子任务。
- 总共包含 8,316 个评估细则，全部与论文原作者协同制定。
- 评测时表现最好的模型（当时是 Claude 3.5 Sonnet，得分约为 21%）依然落后于机器学习方向的在读博士。
- 评测集包含 PaperBench、PaperBench Code-Dev（轻量版）和 JudgeEval。
CORE-Bench：评估已发表学术研究的计算可复现性（computational reproducibility）。
- 基于计算机科学、社会科学和医学领域的 90 篇科学论文，设计了 270 个评估任务。
- 任务包含利用提供的代码和原始数据复现论文的实验结果。
- 包含多种不同难度，涵盖纯文本以及多模态（视觉-语言）任务。
- 评测时表现最出色的智能体（GPT-4o 和 GPT-4o-mini）在最高难度的任务上仅取得了 21% 的准确率。
ScienceAgentBench：评估 LLM 智能体在数据驱动下的科学发现能力。
- 从数学、化学、生物学和地理学四个学科的 44 篇同行评审文献中提炼出 102 个具体任务。
- 覆盖这些学科中的基础数据科学任务：包含数据处理、模型构建、数据分析以及数据可视化。
RE-Bench：在高度逼真的机器学习研发工程环境里，评估前沿 AI 智能体与人类专家的横向对比表现。
- 包含 7 个极具挑战性、开放式的机器学习研发工程环境。
- 每个环境都定义为 (评分函数, 初始方案, 参考方案)；且都可以在 8 颗或更少 H100 GPU 上运行。
- 示例任务：优化底层算子内核、运行缩放定律 (Scaling Law) 实验、修复词嵌入缺陷、微调 GPT-2 以运行问答任务等。
- 收集了 61 名人类专家进行 71 次为期 8 小时的真实尝试数据。
- 人类专家在 82% 的 8 小时尝试中都获得了非零的成绩；且有 24% 的人达到或超过了强参考方案的水平。
- 在 2 小时的时间预算内，最出色的 AI 智能体的得分是人类的 4 倍；但在更长的时间周期里，人类的表现展现出了更高的长程边际收益，在 8 小时和 32 小时的设置中完全超越了 AI。
MLE-bench：评测机器学习工程智能体在离线 Kaggle 竞赛环境中的实操水平。
- 包含从 Kaggle 精心挑选出的 75 个机器学习工程比赛。
- 考验模型训练、数据清洗准备、实验调试和向评分脚本提交预测结果的能力。
- 使用 Kaggle 公开排行榜上的真实人类成绩作为对比基线。
- 论文中表现最优秀的配置（o1-preview 结合 AIDE 脚手架系统）在 16.9% 的竞赛中达到了至少 Kaggle 铜牌的水平。
- 报告中还包含计算资源缩放实验以及数据集污染审查分析。
KernelBench：评测生成的 GPU 算子内核的正确性与运行速度。
- 包含 250 个 PyTorch 任务，用以测试 LLM 能否写出既正确又高速的底层算子。
- 其核心评测指标 $fast\_p$ 为：编写正确且速度超越预设对比基线的算子所占的百分比。