本文整合并翻译自 Lilian Weng 的博客文章《Harness Engineering for Self-Improvement》（Lil'Log, 2026-07-04），并补充了相关技术原理的背景解读。原文链接：https://lilianweng.github.io/posts/2026-07-04-harness/。图片均来自原文。
引言：从"递归自改进"说起递归自改进（Recursive Self-Improvement, RSI） 的概念可以追溯到 I. J. Good（1965）。他把"超级智能机器"定义为在一切智力活动上都能超越人类、并能设计出更好的机器来改进自身的系统。Yudkowsky（2008）则用"递归自改进"一词描述了一个具体的反馈闭环：一个 AI 用它当前的智能，去改进那台生产它智能的"认知机器"本身。
背景补充｜RSI 的现代含义RSI 最初脱胎于 1965 年 Good 提出的"智能爆炸"设想——一旦超级智能能设计出更优的自身版本，改进便会加速失控。但在现代大语言模型（LLM）语境下，RSI 的含义已从科幻式的"自我重写内核"收敛为更工程化的形态：系统通过修改自身的提示词、工具、编排逻辑、训练数据或代码来提升在特定任务上的表现，并用可度量的评估指标来筛选有效改进。其价值在于——若改进环路能被可靠、可度量地闭合，agent 便可在人类监督下持续自动优化；但这也带来对齐、评估可信度与"改进坍塌"（reward hacking）等关键风险。
在现代 AI 中，这个反馈闭环可能意味着模型直接改写自己的权重，或更宽泛地说，模型改进自己的训练流水线（training pipeline） 与部署系统（deployment system），进而催生一个在各类经济价值任务上表现更好的后继模型。前沿实验室已经证明，AI 的研究开发速度正在被极大地加速（Anthropic、OpenAI）。
原文特别强调"部署系统"，因为夹在原始模型与真实世界上下文之间的这一层，其重要性似乎不亚于模型的原始智能（即预训练之后的评测能力）。Harness 正是 AI 部署中的重要组件——Claude Code、Codex 等成功的编码 agent 产品便是明证。所谓 harness（马具 / 支架系统），指的是环绕基础模型的那套系统，它负责编排执行，并决定模型如何思考与规划、如何调用工具与行动、如何感知与管理上下文、如何存储产物，以及如何评估结果。
本文聚焦围绕 harness 工程的研究，以及它如何促成 RSI。近期大量关于自动化研究（auto-research）、自改进 agent、进化式程序搜索的工作都可以围绕这个问题来组织。其他关于模型自博弈、合成数据、测试时训练以及更广义的持续学习（continual learning）的工作也符合 RSI 愿景，但不在本文讨论范围内。
一、Harness 设计模式与早期的 agent 框架（"agent = LLM + 记忆 + 工具 + 规划 + 行动"）相比，harness 工程额外包含了工作流设计（如循环工程 loop engineering）、评估、权限控制、持久化状态管理。它不再只是提示词模板，而更接近运行时（runtime）与软件系统设计：模型如何观察、行动、记忆、自查、自我改进。
背景补充｜Harness 与早期 Agent 框架的分野早期框架（如 2023 年的 AutoGPT、BabyAGI）往往用大量硬编码的规划逻辑、固定的 prompt 链和复杂调度器去"补足"当时模型推理能力的不足——框架本身承载了智能。而现代 harness 遵循"薄编排、厚模型"的理念：尽量减少刚性脚手架，把决策权交还给能力更强的模型，harness 只提供环境、约束与反馈通道。随着模型能力提升，过度工程化的框架反而成为瓶颈，轻量、可被模型自身修改的 harness 更利于实现自改进与泛化。
设计应当刻意地保持简单且通用，以支持泛化，并尽量参照既有的软件工程实践，从而复用预训练知识。原文还提出了一个精妙的类比：操作系统与 harness 高度相似。就像 OS 一样，harness 应当封装复杂逻辑，同时保持接口简单。与此同时，配置、工具接口及其他协议，可能会在整个行业内逐渐走向标准化。
模式 1：工作流自动化（Workflow Automation）定义一个模型可以在其中运行、测试、迭代的工作流，是自动化的关键设计。Karpathy 的 autoresearch 仓库（https://github.com/karpathy/autoresearch）就是构建这类工作流的一个干净范例。常见的工作流遵循一个目标导向的循环：规划 → 执行 → 观察/测试 → 改进 → 再执行，直到目标达成。过程中可能会主动向用户发起请求，以澄清任务规格或执行偏好。
图 1：简化的 Codex agent 循环——agent 调用工具，工具的响应影响模型的下一步生成。
这张工作流图还强调：模型要分析自己的执行轨迹（trajectory）与失败案例，然后通过一个"agent 运行时"而非静态提示词模板，来迭代推进自身的进展。
模式 2：文件系统作为持久化记忆（File System as Persistent Memory）长周期（long-horizon）agent 系统中反复出现的一个模式，是对丰富的状态与产物进行简单的控制。harness 不应把整个工作流和所有日志都塞进上下文；相反，它应当把持久状态保存在文件里。在长周期的 agentic rollout 中，实验日志、代码 diff、论文摘要、错误堆栈、过往 rollout 轨迹等产物，往往会远远超过模型训练时所用的上下文窗口长度。
学会读、写、编辑文件系统（通常通过 bash 命令）是 LLM 的一项基础技能。因此，以"文件"这种简单形式管理持久化记忆，天然能从核心模型能力的进步中获益。
模式 3：子 Agent 与后台作业（Sub-agent and Backend Jobs）harness 可以派生（spawn）多个子 agent 并行执行，并监控后台作业。当主 agent 需要同时搜索多个假设、并发运行实验、或把隔离的子任务委派出去而不污染主上下文时，这一点非常有用。父 agent 因此需要一个小型的进程管理器：启动作业、检查日志、取消失败的运行、并把结果合并回主 agent 线程。
关键的设计取舍是：让并行显式且可检查（inspectable）。如果子 agent 的输出只存在于一个瞬态的对话上下文里，它们很快就会过时并被隐藏。而如果它们被存为文件、日志和状态记录，模型就能在中断后恢复，并对自己的执行历史进行推理。
案例研究：编码 Agent 的 Harness主流编码 agent 的核心接口，已经在 Claude Code、Codex、OpenCode 以及 Cursor 风格的 agent 之间趋于稳定。它们通常使用如下循环：
图 2：编码 agent 的通用循环。
通过访问一组工具，编码 agent 得以在给定仓库中开发并调试问题，就像人类开发者配备了 IDE 一样。下表展示了典型的工具分组（非完整列表，仅作演示）：
分组
工具定义
文件系统
文件发现：glob、grep、ls；文件读取：read、read_many；文件修改：write（写整个新文件）、edit（字符串精确匹配替换）、multi_edit、apply_patch（应用结构化补丁/diff）
Shell 执行
运行命令：bash、PowerShell
IO
lsp、git 工具如 git_status、git_diff、git_commit
外部上下文
MCP 工具、Skills
网络搜索
web_search、web_fetch、浏览器工具
产物
读取文档、图片；生成 HTML、图片
后台进程
如 CronCreate、CronDelete、CronList
Agent 委派
如 spawn_agent、resume_agent、wait_agent、list_agents、close_agent、interrupt_agent 等
Harness 层 vs 核心智能？未来的 RSI 会在多大程度上依赖 harness 工程，很难预测；但 RSI 的近期路径，不太可能一上来就是模型直接改写自己的权重。原文给出的近期实用路径预测是：
Harness 工程将朝"元方法论"方向演进——即改进"获得更好答案的机器"，而不仅是改进答案本身。harness 系统自身会成为优化目标，启发式规则更少、通用机制更多。反过来，成熟的 harness 使模型自改进的 auto-research 闭环成为可能；而更聪明的模型又能防止 harness 过度工程化，让系统保持可持续。最终，许多 harness 改进可能会被内化（internalized） 进核心模型行为，但与外部上下文和工具的接口应当保留。我们在 prompt engineering 上已经见过这一模式的温和版本：随着指令微调和模型推理能力的提升，手工的提示词技巧不再那么核心——但指定目标、约束、上下文和评估的需求并未消失。
二、Harness 优化在 harness 系统中，被优化的对象大致沿着这样的路径演进：
指令提示词 → 结构化上下文 → 工作流 → harness 代码 → 优化器代码
随着模型越来越智能、越来越强大，我们朝着更复杂的目标与更通用的方法迈进。
2.1 上下文工程（Context Engineering）简单地把所有工具响应和模型生成都追加进上下文，随着 agentic 作业周期的显著拉长，会很快失控。上下文管理这一层，用于为 LLM 构建更结构化、更精炼的上下文，并管理持久状态。长上下文研究无疑会持续进步，但当下——长上下文智能与上下文工程有时是交织在一起的。
背景补充｜上下文工程 vs 提示词工程上下文工程是在 prompt engineering 基础上的扩展：它关注如何在推理时动态构建、组织、管理模型整个上下文窗口的信息，而不仅是写一句好指令。其手段包括检索并注入相关知识（RAG）、压缩与摘要历史、结构化组织工具定义与示例、管理记忆的读写、以及控制信息的相关性与顺序。核心洞见是：模型表现在很大程度上取决于"给它看什么"，上下文是需要被主动、程序化管理的动态资源。
Agentic 上下文工程（ACE；Zhang et al. 2025） 把上下文当作一本不断演化的"操作手册"（playbook），而非一段越来越长的提示词。它用三个组件来维护一份由条目（bullet points）构成的上下文手册，每个条目带有一个标识符和一段描述：
生成器（Generator）：参照条目产出任务轨迹。反思器（Reflector）：从成功与失败的轨迹中提炼洞见。策展器（Curator）：以增量、逐条目的方式更新结构化上下文。
图 3：Agentic 上下文工程（ACE）框架。（图片来源：Zhang et al. 2025）
为防止迭代重写过程中的上下文坍塌（context collapse） 与简短偏置（brevity bias），ACE 的一个关键设计是：策展器不重写整段提示词大块（prompt blob），而是输出一组结构化、逐条目的 (标识符, 描述)，并用确定性逻辑将这些条目合并进结构化的上下文日志。上下文条目会被定期精炼与去重。
ACE 从 rollout 中学习洞见，帮助我们朝"自管理记忆"迈进，但其更新规则和整体工作流仍是手工设计的。为进一步走向自改进闭环，元上下文工程（Meta Context Engineering, MCE；Ye et al. 2026） 把机制（如何管理上下文）与产物内容（上下文里是什么）分离：在元优化层运行"技能演化"，在基础层做上下文优化。
图 4：元上下文工程（MCE）框架——元层的技能演化在"上下文管理机制"上搜索，基础层则优化任务上下文
与 ACE 不同，MCE 不强制"如何组织上下文"的启发式规则。它用自由格式的技能来存储对任务最重要的知识，并把技能与"技能条件化的上下文"一起迭代演化。实现上，上下文函数 c 被实例化为一个专用目录下的一组文件，既含静态部分（skill.md）也含动态部分（上下文与数据 rollout）。元层与基础层的优化都在带有标准工具集的 agentic 编码环境中执行：
元 Harness（Meta-Harness；Lee et al. 2026） 又深入了一层：被优化的对象是那段决定并优化"哪些信息该被存储、检索、呈现给模型"的代码。名字里的"Meta-"意味着它是一个"优化 harness 的 harness"。
图 5：元 Harness 的外层优化算法
创建新 harness 的"提议器（proposer）"本身就是一个编码 agent，最终输出是帕累托前沿（Pareto frontier） 上的一组 harness 候选。几个要点：
整个执行历史可通过文件系统访问，因此编码 agent 用 grep、cat 等命令去读取，而非把一切铲进单一的提示词上下文。被提议的 harness 是文件系统里的一个字典，包含它自己的源代码、分数、rollout 轨迹和状态更新。元 harness 循环迭代地创建新 harness，只保留合格者。
图 6：元 Harness 在（左）少量迭代的文本分类任务，和（右）TerminalBench-2 上的表现。
不过，重要的教训很清楚：一旦 harness 设计成为一个可执行的搜索空间，一个强大的编码 agent 就能利用人类工程师所用的同一片设计空间。
2.2 工作流设计（Workflow Design）harness 工程中的工作流设计，可以由领域专家手工打造。以自动化研究（auto-research）为例，已有多种框架被提出并测试。
AI Scientist 系统（Lu et al. 2026） 构建了一条流水线：提出研究想法、写代码、跑实验、分析结果、撰写论文稿、执行同行评审。ScientistOne（Meng et al. 2026） 则把可验证性（verifiability） 作为核心设计约束——每一条主张（引用、数值、方法论、结论）都必须能追溯到证据来源，并由"证据链（Chain-of-Evidence）"检查审计。
图 7：AI Scientist 流水线，用于想法生成、实验、论文撰写与评审
Autodata agent（Kulikov et al. 2026） 被设计成一个"数据科学家"，用于生成训练和评估数据。主 agent 管理一个出题者（challenger）、一个弱求解器（weak solver）、一个强求解器（strong solver） 和一个验证器/裁判（verifier/judge），目标是合成"难度恰好"的数据——即强求解器能做对、弱求解器做不对。在 Autodata 中，出题者的提示词会根据求解器和验证器的反馈迭代更新。其局限在于：合成任务只用于微调弱求解器而非强求解器；如果闭环无法迭代地改进强模型，它就更像是在一个生成的提示词分布上做间接蒸馏，RSI 的味道较淡。
图 8：Autodata 的 agentic 工作流设计，围绕出题者、求解器、验证器角色生成合成训练与评估数据
工作流的设计空间极其庞大，因此我们自然会把工作流设计看作一个搜索问题——那么就应该能用算法而非仅靠手工去找到好的解。沿此方向，智能体系统的自动化设计（Automated Design of Agentic Systems, ADAS；Hu et al. 2025） 把 agent 设计本身表述为一个优化问题，即"元 agent 搜索（meta-agent search）"：一个元 agent 提议新的 agentic 工作流设计。
背景补充｜ADAS 的关键洞见ADAS 的核心是将整个 agentic 系统表示为代码（用编程语言定义工作流、提示、工具调用与控制流），从而在图灵完备的搜索空间内探索。其 Meta Agent Search 算法让一个 meta agent 根据不断增长的"已发现智能体归档库"迭代地编程发明新智能体，并证明自动发现的智能体具有跨领域、跨模型的可迁移性。
ADAS 的流程：
用简单 agent（如 CoT、self-refine）初始化一个 agentic 工作流的归档库。让元 agent 参照归档库中的既有解，用代码编写新 agent： 元 agent 先生成新工作流的高层描述，再用代码实现。 草稿程序随后经过两步 self-refine（Madaan et al. 2023：先让模型给反馈，再让同一模型基于反馈精炼此前输出），由元 agent 检查其新颖性。评估每个新候选，把成功者加回归档库。重复第 2–3 步，直到达到最大迭代次数。
图 9：智能体系统自动化设计（ADAS）示意
AFlow（Zhang et al. 2025） 把 agentic 工作流表示为一张图：节点代表 LLM 调用动作，边则用代码实现逻辑操作。工作流优化依赖 MCTS（蒙特卡洛树搜索）：
用模板在树中初始化起始工作流 W_0。用"分数 + 均匀探索"的软混合策略选择一个工作流节点。让 LLM 基于其评估表现，生成一个修改后的工作流来扩展它。执行并评估新工作流。若新工作流在 N 轮预算内展现出改进，就把它加回树中。重复第 2–5 步，当 top-k 平均分停滞或耗尽预算时停止。背景补充｜MCTS 在工作流搜索中的作用MCTS 通过随机采样与统计回溯，在庞大决策树中寻找高价值路径，因 AlphaGo 而广为人知。其核心是选择（selection）→ 扩展（expansion）→ 模拟（simulation/rollout）→ 回传（backpropagation）的四步循环，并用 UCB 等策略平衡探索与利用。在工作流搜索中，它把"哪种编排/解法更优"转化为可量化的树搜索问题，比贪心或纯采样能在有限算力下更高效地权衡"尝试新方案"与"深挖已知优质方案"。
图 10：AFlow 在工作流候选树上的优化过程
AFlow 在 QA、代码、数学任务上的实验表明，它相比手工设计的工作流以及 ADAS 都有不错的改进。
图 11：AFlow 与手工方法及 ADAS 的对比实验
2.3 自改进 Harness（Self-Improving Harness）上下文工程也好、工作流设计也罢，都只是 harness 的一部分。我们需要在整个设计空间中搜索，把上下文管理逻辑、工作流、权限以及其他众多 harness 组件一并优化。正如在 Meta-Harness、ADAS、AFlow 中所见——✨代码✨是定义程序与系统的通用语言。简言之，harness 就是"编排提示词、工具调用、子 agent、控制流、记忆、工作流逻辑如何协同工作"的代码。如果一个 LLM 能优化执行 agent 的那段代码，它就能触及一个远比手写提示词更大的设计空间。
自学优化器（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 在一组下游任务上的平均效用：
由于"改进改进器"本身就是一个优化问题，我们可以基于 I_{t-1} 由元效用度量的表现，递归地得到 I_t：
图 12：自学优化器（STOP）算法。（图片来源：Zelikman et al. 2023）
在 Zelikman et al.（2023）的实验中，被改进的改进器自发地发现了多种策略：遗传算法、分解并改进各部分、多臂提示词老虎机（multi-armed prompt bandits）、模拟退火、变化温度、束搜索/树搜索。这与"harness 工作流可被表示为一个优化对象"高度类比。
图 13：STOP 发现的自改进策略示例。（图片来源：Zelikman et al. 2023）
其发现中有一个警示性结果：STOP 在 GPT-4 上能逐轮提升下游平均表现，但在 GPT-3.5、Mixtral 等较弱模型上却是退化的。仅有递归结构是不够的——基础模型必须足够强，才能改进这套机制。 这意味着 harness 改进能让模型被更好地部署，但智能仍是核心。
一项更近期的工作 Self-Harness（Zhang et al. 2026），依靠 LLM agent 通过"提议—评估—接受"的循环来改进它们自己的 harness。
图 14：Self-Harness 使用"弱点挖掘、有界 harness 提议、验证"的循环来更新 harness
Self-Harness 的循环分三个阶段：
弱点挖掘（Weakness mining）：把失败聚类为有验证器依据的失败模式。 用当前 harness h_t 在任务上评估，收集执行轨迹用于分析。 注意：两次运行在错误日志表面上可能共享同一个验证器结果（如超时、缺失产物），但因果机制却不同。因此需要一份信息丰富的失败记录，包含终端验证器级别的原因、相关 agent 行为的因果状态、以及轨迹暴露出的抽象 agent 机制，才能挖出根因。Harness 提议（Harness proposal）：基于挖出的失败模式，提议有界（bounded）的 harness 编辑。 同一个模型在 h_t 下被当作提议器调用。 模型获得一个有界的提议上下文：(1) 当前 harness 的可编辑面（editable surfaces）；(2) 来自评估系统的、有验证器依据的失败模式；(3) 应被保留的通过行为记录；(4) 此前尝试过的编辑摘要。 Harness 编辑应偏好可解决的、复发性的错误模式（如非任务本身固有难度），且能通过窄范围改动来修复。 编辑候选应彼此相异、保持多样。提议验证（Proposal validation）：验证并合并合格编辑，生成新 harness h_{t+1}。 候选编辑在 held-in 数据 D_\text{in}（测试弱点是否被解决）和 held-out 数据 D_\text{out}（检查是否引入了其他未知问题）上做回归测试。 仅当在 held-in 与 held-out 上都无回归时，候选才被接受。 被接受的候选合并进 harness 得到 h_{t+1}；被拒绝的则记录在案，不改动活跃 harness。在 Terminal-Bench-2 上运行 MiniMax M2.5、Qwen3.5-35B-A3B、GLM-5 时，Self-Harness 被证明能学到针对不同基础模型不同弱点的、模型专属的 harness 指令，并提升 held-out 通过率。
原作者的顾虑：Self-Harness 这类工作确实引起一个担忧——如果允许一个程序编辑操作系统，抽象边界就会被打破。可编辑面需要被恰当设计，权限控制和安全层必须位于这个循环之外。所有围绕奖励攻击（reward hacking）的挑战依然存在。
2.4 进化搜索（Evolutionary Search）进化搜索是一种受自然选择启发的优化方法（参见 Weng 的旧文进化算法）。它维护一个解的种群，通过变异（mutation）来演化它们，只保留群体中"适应度（fitness）"高的个体。进化搜索在以下情形很有用：(1) 搜索空间庞大或形状怪异；(2) 难以用梯度直接优化，但容易评估解的好坏。Harness 搜索似乎正好契合。
背景补充｜LLM 作为"智能变异算子"进化搜索借鉴生物进化：维护候选解种群 → 用 fitness 打分 → 保留高分个体 → 施加变异与交叉 → 迭代逼近更优解。在 LLM 时代，其独特之处是用模型本身充当"智能变异算子"——让 LLM 根据反馈生成有意义的 prompt 改写或代码修改，而非随机扰动，从而大幅提高搜索效率。这类思路体现在 PromptBreeder、FunSearch、AlphaEvolve 等工作中，天然适合黑盒、无梯度、评估信号稀疏的离散优化问题。
进化搜索过去已被用于提示词工程。Promptbreeder（Fernando et al. 2023） 通过一套丰富的变异操作来优化任务专属提示词，有趣的是，那些"变异提示词"（即指示 LLM 去变异任务提示词的指令）自身也通过进化被改进。GEPA（Agrawal et al. 2025） 把基于反思的提示与进化搜索结合，用对试错轨迹的自然语言反思来提议提示词更新。
Novikov et al.（2025） 提出的 AlphaEvolve 是一个编码 agent 式的进化搜索系统：它存储一池候选程序，并提示冻结的 LLM 生成用于改进的 diff。系统反复评估子代程序并保留成功者，从而随时间发现更优的解。
图 15：AlphaEvolve 的工作原理。（图片来源：Novikov et al. 2025）
AlphaEvolve 设计中的若干细节值得注意：
提示词包含父代程序、结果、指令，有时还有元信息。编码 agent 可访问整个仓库，但待改进的代码区域用 # EVOLVE-BLOCK-START 和 # EVOLVE-BLOCK-END 显式标注。元提示词（meta-prompt）会与指令、上下文协同进化，方式与我们进化解程序一样。背景补充｜AlphaEvolve 的真实突破AlphaEvolve 是 Google DeepMind 于 2025 年发布的进化式编码 agent，以 Gemini 系列模型作变异算子，配合自动评估器打分。它取得了具科学价值的真实成果，例如发现 4×4 复数矩阵乘法仅需 48 次乘法的新算法（改进了 Strassen 1969 年以来的经典结果），并在多个开放数学问题上找到更优构造，还被用于优化 Google 数据中心调度与硬件设计——是"LLM + 进化搜索"能产出人类未知新知识的标志性证明。
消融实验展示了进化过程、提示词中的上下文、元提示词、整文件进化以及使用更强 LLM 各自的价值。
图 16：消融实验展示 AlphaEvolve 若干设计的价值。（图片来源：Novikov et al. 2025）
近期的变体，如 ThetaEvolve（Wang et al. 2025） 把进化搜索与强化学习、上下文学习结合。而 ShinkaEvolve（Lange et al. 2025） 引入三个新组件来提升 LLM 采样效率：
更高样本效率的探索：设计父代采样，平衡"表现排名"与"子代数量"。代码新颖性拒绝采样：基于嵌入余弦相似度，丢弃与现有种群过于相似的候选。元便签（meta-scratchpad）：识别成功解中的好模式，以指导未来变异。与上述聚焦"改进解"的方法不同，达尔文-哥德尔机（Darwin Gödel Machine, DGM；Zhang et al. 2025） 明确地以"进化一个可编辑的 harness 代码仓库"为目标，用基于 LLM 的编码 agent 来做。确切地说，这个 agent 被允许修改它自己的 harness。后续工作 Hyperagents（Zhang et al. 2026）引入一个元 agent 来控制"如何修改既有任务 agent 以创建新 agent"。
DGM 的流程：
池中从一个编码 agent 开始。每轮迭代，以"正比于表现、反比于子代数"的概率挑一个父代，去修改并分叉出新 agent。被选中的父代 agent 检查自己的基准评估日志，然后对自己的 harness 代码库提议改进，生成一个新版本的编码 agent。代码编辑由两个基础工具实现：(1) bash（参数 <bash_command>）；(2) editor（参数 view/create/edit <file_path>）。新编码 agent 被评估，只有表现足够高的才被加回池中。重复第 2–4 步，直到触发某些停止条件。背景补充｜DGM 的核心创新DGM 借鉴哥德尔机的自指思想，但把"必须形式化证明修改有益"这一不可行要求，替换为达尔文式的经验验证——在真实编码基准上实测性能来判断改动是否有益。它维护一个不断增长的归档库，从中采样父代做开放式分支进化，并保留多样中间体以避免局部最优。
DGM 是固定模型下的 harness 进化。在以 Claude 3.5 Sonnet 为基础 LLM、初始 harness 配置很简单的实验中，DGM 发现的 agent 在 SWE-bench Verified（20% → 50%）和 Polyglot（14.2% → 30.7%）上，达到了可与手工 agent 媲美甚至更优的水平。
这一族方法在候选解可自动评估、适应度易量化时效果好，如矩阵乘法、GPU 内核优化、算法竞赛、数据中心调度。而在评估缓慢、模糊或主要靠启发式的领域，它就吃力了。进化的计算效率与有效性也是隐忧。
2.5 与模型权重的联合优化（Joint Optimization with Model Weights）Harness 进化改变的是模型周围那套非参数化系统。要实现完整的自改进，模型完全可以被允许同时更新自己的权重。权重更新可以通过改进模型训练流水线、或在测试时做持续学习（continual learning）来实现。持续学习这个话题本身值得未来单独成文。
SIA（Hebbar et al. 2026） 是把 harness 改进与模型参数更新放进同一个优化循环的一次早期尝试，设计上有三个组件：
元 Agent（Meta-Agent）：提议初始 harness。任务专属 Agent（Task-Specific Agent）：执行任务。反馈 Agent（Feedback-Agent）：基于近期轨迹，决定该更新 harness 还是模型权重。
图 17：SIA 中的反馈 Agent 决定下一轮迭代的类型。（图片来源：Hebbar et al. 2026）
原文指出，SIA 的实验中有几个混淆性（confounding）选择使结果难以解读。例如，任务专属 agent 比元 agent 和反馈 agent 所用的模型弱得多（gpt-oss-120b vs Claude Sonnet 4.6），且基线太弱，难以与相关方法干净对照。可以认为这个方向有趣，但证据仍是初步的。此外，训练稳定性、古德哈特效应（Goodhart effect）等诸多挑战仍未解决。
三、未来的挑战AI Scientist 这条工作线，有力地证明了一个专家设计的 harness 可以协调自动化研究闭环的很大一部分（以撰写研究论文的形式实验）。但论文产出并不等同于科学发现——一个系统可以写出看似合理的稿件，却仍带有伪造引用、实现漂移（implementation drift）、或薄弱的实验结果。
Trehan & Chopra（2026） 测试了 LLM 能否在最小脚手架和基础工具（read_file、write_file、llm_search、list_files）下，从一个研究想法走到一篇论文。每个想法有专属工作区，agent 可生成并读取文档作为上下文的一部分。他们在三个领域（世界模型、多智能体 RL、AI 安全与对齐）实验，每个领域含 45–50 篇高质量种子文档以激发新想法。只有四个想法被人类专家选中跑完整流程，最终只有一个被完整执行成论文。他们观察到六种反复出现的失败模式：
偏向训练数据默认值：用旧库、过时命令、标准格式，或未扎根于实际仓库/数据集的假设。执行压力下的实现漂移：当实现变得技术复杂时，模型可能转向一个更常见、更简单的方案，而非所提出的方法。记忆与上下文退化：长周期项目会丢失关键细节，除非日志被写为持久化产物。过度乐观：尽管实验有噪声或已失败，模型仍宣布成功。这类似 Bubeck et al.（2025） 观察到的"p-hacking 与顿悟（eureka-ing）"模式——模型会打上"数值胶带"（numerical duct tape），在信号仍是噪声时就宣告胜利。领域智能不足：模型缺乏隐性的手艺知识，如预测实现复杂度、判断实验结果是否合理、知道哪些基线才重要。薄弱的科学品味：实验可执行，却没能回答对的问题。朝完整 RSI 迈进的路上，研究者已取得实质进展，但仍有若干瓶颈：
1. 薄弱且模糊的评估器。 许多研究主张没有快速精确的验证器，许多真实世界任务也是如此。当前的自改进闭环，在评估指标可度量、客观时效果最好（类似 RL 的工作方式）。而研究品味、新颖性、长期科学价值则难以度量得多——研究品味往往混合了问题框定、实验设计，以及"哪些惊人结果值得追、哪些失败案例值得重试"的判断。
2. 上下文与记忆生命周期。 随着 AI agent 越来越自主独立，记忆也在增长。有用的 harness 需要管理上下文与记忆，以弥补长上下文生成的现有局限，同时最大化长周期任务的成功率。既然人类能维持终生的记忆，作者认为这里有个类比——上下文工程将、也应当成为智能的核心组成部分，而不是停留在软件系统层。
3. 负面结果。 研究者被激励去发表成功结果，因此文献偏向成功。在海量（目前多为人类创作的）数据上训练的 LLM，可能不擅长决定何时放弃一个假设、报告负面结果、甚至承认失败——因为数据中成功与失败案例是不平衡的。一个研究型 harness 应当让失败尝试易于被保留，因为从失败中学习是收窄任务搜索空间的最佳方式。
4. 多样性坍塌（Diversity collapse）。 进化与 RL 闭环倾向于利用已知的高回报模式。我们需要机制来防止种群坍塌成同一个解的变体。这对开放式研究尤为关键——最好的路径，在当前评估器下起初可能看起来更差。
5. 奖励攻击（Reward hacking）。 自改进闭环会优化被给定的任何信号。如果奖励来自单元测试，agent 可能过拟合测试；如果来自裁判模型，它可能学会针对该裁判的奖励攻击技巧；如果来自基准分数，它可能利用基准的假象（artifacts）。评估器与权限控制，很可能应当置于"进化 harness 的循环"之外——用 held-out 测试、轨迹审计，以及在关键决策点的人类评审。多少监督能被规模化、自动化，仍是一个开放的研究领域。
6. 长期成功。 一个外在（extrinsic）的优化循环，作用于我们能在训练沙箱里模拟的、单次 rollout 之外的奖励。以编码 agent 为例：它已提升了软件工程的日常生产力，但许多优化目标仍过于短期。它常能完成手头任务，却不太清楚该如何守护一个由成百上千工程师共同维护的仓库的长期健康。标准的沙箱式 RLVR 训练很少捕捉可维护性、所有权边界、迁移成本、向后兼容性或未来的调试负担。
7. 人类的角色。 人类应当上移到栈的更高层，而非被移出闭环——即在恰当的时机、恰当的抽象层级提供监督，我们的系统设计应考虑何时、如何设置这些接触点（touch points）。上面列出的许多挑战都需要人类的反馈与引导。毕竟，我们是在为人类更好的未来构建技术，而非相反。
附录：一些有用的基准测试（Benchmarks）PaperBench：从零复现 20 篇 ICML 2024 Spotlight/Oral 论文，涵盖理解论文贡献、开发代码库、成功执行实验。每个复现任务被拆解为更小、可单独评分的子任务；共 8316 条评分标准（与论文作者共同制定）；当时最好的模型（Claude 3.5 Sonnet，约 21%）未能超越 ML 博士。CORE-Bench：评估已发表研究的计算可复现性。基于 90 篇科学论文的 270 个任务，横跨计算机、社会科学、医学；任务涉及从给定代码与数据复现结果；含多难度层级与纯语言/视觉-语言任务；当时最好的 agent（GPT-4o / GPT-4o-mini）在最难任务上仅 21% 准确率。ScienceAgentBench：评估 LLM agent 的数据驱动科学发现能力。从 4 个学科（数学、化学、生物、地理）44 篇同行评审论文提取 102 个任务，覆盖数据处理、模型开发、数据分析、信息可视化。RE-Bench：在真实 ML 研究工程环境中，将前沿 AI agent 与人类专家对比。7 个开放式 ML 研究工程环境，每个 = (评分函数, 起始解, 参考解)，可用 ≤8 张 H100 运行；含 61 位人类专家的 71 次 8 小时尝试数据。人类在 82% 的 8 小时尝试中拿到非零分，24% 达到或超过强参考解；在 2 小时预算下最好的 AI agent 得分是人类的 4 倍，但人类在更长预算下回报更好，并在 8 小时、32 小时设定下超过 agent。MLE-bench：在离线 Kaggle 竞赛上评估 ML 工程 agent。含 75 个精选自 Kaggle 的 ML 工程竞赛，测试训练模型、准备数据集、跑实验、向评分脚本提交预测；用 Kaggle 公开排行榜作人类基线。论文中最好配置（o1-preview + AIDE 脚手架）在 16.9% 的竞赛中至少达到 Kaggle 铜牌水平。KernelBench：评估生成的 GPU 内核的正确性与速度。250 个 PyTorch 任务，评估指标 fast_p = 生成内核中"既正确又比基线更快"的比例。引用信息Weng, Lilian. "Harness Engineering for Self-Improvement". Lil'Log (Jul 2026). https://lilianweng.github.io/posts/2026-07-04-harness