大家好，我是玄姐。

递归自我改进（recursive self-improvement，RSI）的概念可追溯至 I. J. Good（1965），他将”超智能机器（ultraintelligent machine）”定义为一种在所有智力活动上都能超越人类、并能设计出更好的机器来改进自身的系统。Yudkowsky（2008）用”递归自我改进”一词描述一个特定的反馈回路：AI 利用其当前的智能，去改进产生其智能的认知机制。

这一反馈回路在现代 AI 中，可能体现为模型直接重写自己的权重；或者更广义地说，模型去改进训练流水线（training pipeline）与部署系统（deployment system），从而催生出在经济价值任务上表现更强的下一代模型。前沿实验室的 AI 研发速度已被证明在大幅加速（Anthropic；OpenAI）。

我特意提到”部署系统”，是因为介于原始模型与真实世界上下文之间的这一层，其重要性似乎不亚于模型的原始智能（即预训练后立刻跑出的评测成绩）。Harness 是 AI 部署的重要组成部分，Claude Code、Codex 等成功的编程智能体产品已经证明了这一点。Harness 指包裹在基础模型外围的系统，它负责编排执行，决定模型如何思考与规划、如何调用工具与行动、如何感知与管理上下文、如何存储产物、以及如何评估结果。

本文聚焦 Harness 工程相关研究，以及它如何推动 RSI。近期许多关于自动化研究（auto-research）、自我改进智能体、进化式程序搜索的工作，都可以围绕这一问题来组织。模型自博弈（self-play）、合成数据、测试时训练（test-time training）以及更大的持续学习（continual learning）主题也符合 RSI 的愿景（如 Yuan et al. 2024、Chen et al. 2024、Zhao et al. 2025、Choi et al. 2026），但不是本文的重点。

一、Harness 设计模式

与早期智能体框架”智能体 = LLM + 记忆 + 工具 + 规划 + 行动”相比，Harness 工程还额外包括：工作流设计（如循环工程）、评估、权限控制与持久状态管理。它不再只是提示词模板，而更接近运行时与软件系统设计：模型如何观察、行动、记忆、自检与改进。

设计上应当刻意保持简单与通用，以实现泛化；同时最好借鉴现有软件工程实践，从而受益于预训练知识。操作系统与 Harness 之间存在很强的类比：正如操作系统一样，Harness 应当封装复杂逻辑，同时保持接口简单。与此同时，配置、工具接口等协议可能会逐渐在行业内标准化。

1.1 模式一：工作流自动化

定义一个模型可以在其中运行、测试与迭代的工作流，是自动化的关键设计。Karpathy 的 autoresearch 仓库（https://github.com/karpathy/autoresearch）就是构建此类工作流的一个干净范例。常见的工作流遵循目标导向的循环：规划（plan）→ 执行（execute）→ 观察/测试（observe/test）→ 改进（improve）→ 再执行，直到目标达成。过程中还可能主动向用户发起请求，以澄清任务规格或执行偏好。

（图1：简化的 Codex 智能体循环：智能体调用工具，工具返回结果影响模型的下一次生成。图片来源：OpenAI codex agent 文章）

这张工作流图还强调了一点：模型通过”智能体运行时（agent runtime）”（而非静态提示词模板）分析自己的轨迹与失败案例，然后在此基础上迭代。

1.2 模式二：文件系统作为持久记忆

长程智能体系统中反复出现的一个模式是：用简单的控制方式管理丰富的状态与产物。Harness 不应把整个工作流和所有日志都背在上下文里，而应把持久状态保存在文件中。在长程智能体展开（rollout）中，实验日志、代码 diff、论文摘要、错误堆栈、历史轨迹等产物，往往会增长到远超模型训练时上下文窗口的长度。

学会读写、编辑文件系统（通常通过bash命令）是 LLM 的一项基础技能，因此用文件这种简单形式管理持久记忆，自然会随核心模型能力的提升而受益。

1.3 模式三：子智能体与后台任务

Harness 可以派生多个子智能体并行执行，并监控后台任务。当主智能体需要搜索多个假设、并发跑实验、或把隔离的子任务委派出去而不污染主上下文时，这一点非常有用。父智能体随后需要一个小型进程管理器：启动任务、检查日志、取消失败的运行、把结果合并回主智能体线程。

关键设计选择是让并行显式化且可检查。如果子智能体的产出只存在于临时的聊天上下文中，它们很快就会过时且不可见；如果以文件、日志和状态记录的形式存储，模型就能在中断后恢复，并对自身的执行历史进行推理。

1.4 案例研究：编程智能体 Harness

主流编程智能体的核心接口已经趋于稳定，Claude Code、Codex、OpenCode 以及 Cursor 风格的智能体普遍采用如下循环：

（图2：观察代码仓库 → 规划 → 搜索/阅读文件 → 编辑/写补丁 → 跑测试 → 检查错误 → 重复，直至完成）

借助一组工具，编程智能体可以在给定仓库中开发和调试问题，就像人类开发者配备 IDE 一样。

（并非完整清单，仅作演示。）

1.5 Harness 层 vs 核心智能？

RSI 的未来在多大程度上依赖 Harness 工程，很难预测；但 RSI 的近期路径大概率不会从”模型直接重写自身权重”开始。我对可行的近期路径的预测是：

Harness 工程将朝元方法论（meta-methodology）方向演进（即改进”获得更好答案的机制”，而不只是改进答案本身）。Harness 系统本身成为优化对象，启发式规则更少，通用机制更多。

反过来，成熟的 Harness 使模型自我改进循环的自动化研究成为可能；而更聪明的模型能防止 Harness 过度设计（overengineering），让系统保持可持续。

最终，许多 Harness 改进很可能被内化为核心模型行为，但与外部上下文和工具的接口应当会保留。我们在提示词工程上已经见过这一模式的温和版本：随着指令微调与模型推理能力的进步，手工提示词技巧变得不再那么核心，但对目标、约束、上下文与评估的显式指定的需求并没有消失。

二、Harness 优化

Harness 系统中被优化对象的演进路径大致是：指令提示词→ 结构化上下文 → 工作流 → Harness 代码 → 优化器代码。随着模型变得更智能、更强大，我们正走向更复杂的优化目标与更通用的方法。

2.1 上下文工程

简单地把所有工具响应和模型生成追加进上下文，会随着智能体任务时程的显著拉长而迅速失控。上下文管理是这样一层：为 LLM 构建更结构化、更精简的上下文，并管理持久状态。毫无疑问，长上下文研究会继续进步，但当下长上下文智能与上下文工程有时是相互交织的。

智能体上下文工程（Agentic Context Engineering，ACE；Zhang et al. 2025）把上下文视为一本不断演化的”作战手册（playbook）”，而不是越来越长的提示词。它用三个组件维护一份由要点（bullet）组成的上下文手册，每个要点带有标识符与描述：

• 生成器（Generator）：参考要点，产出任务轨迹。
• 反思器（Reflector）：从成功与失败的轨迹中提炼洞见。
• 管理器（Curator）：以增量、条目化的方式更新结构化上下文。

（图3：ACE 框架。图片来源：Zhang et al. 2025）

为防止迭代重写过程中的上下文坍缩（context collapse）与简洁性偏置（brevity bias），ACE 的一个关键设计是：管理器不重写整段提示词，而是输出一组（标识符，描述）形式的结构化条目，这些条目通过确定性逻辑合并进结构化的上下文日志簿。上下文条目会被定期精炼与去重。

ACE 从 rollout 中学习洞见，帮助我们迈向自管理记忆；但其更新规则与整体工作流仍是手工打造的。为了走向更自我改进的循环，元上下文工程（Meta Context Engineering，MCE；Ye et al. 2026）把机制（如何管理上下文）与产物内容（上下文里有什么）分离开来：在元优化层做技能进化（skill evolution），在基础层做上下文优化。

一个 MCE 技能 s ∈ 𝒮 定义一个上下文函数 c_s = (ρ_s, F_s)，把输入 x 映射为上下文 c = F_s(x; ρ_s)，其中：

• ρ_s = {ρ_1, …, ρ_m} 为静态组件（提示词、知识库、代码库）。
• F_s = {F_1, …, F_k} 为动态算子（搜索、选择、过滤、格式化）。

双层优化（bi-level optimization）是指：内层在给定技能 s 的训练数据上寻找最优上下文 c_s*，外层在验证集上寻找表现最优的技能：

• 内层：c_s* = arg max_{c_s} J_train(c_s; s)
• 外层：s* = arg max_{s ∈ 𝒮} J_val(c_s*)

技能数据库记录历史技能、上下文函数与评估指标：H_{k-1} = {(s_i, c_i, J_i^train, J_i^val)}{i=1}^{k-1}。一个元层智能体针对任务 τ，对历史技能执行智能体式交叉（agentic crossover）以创建新技能：s_k = crossover(τ, H{k-1})。

随后，基础层的上下文工程师执行技能 s_k，并在当前技能指导下从 rollout 反馈 R_k 中学习上下文函数：c_k = engineer(τ, s_k; c*_{k-1}, R_k)。

（图4：MCE 框架：元层技能进化在上下文管理机制上搜索，基础层优化任务上下文。图片来源：Ye et al. 2026）

MCE 不像 ACE 那样强制规定”上下文该如何组织”的启发式规则。它用自由形式的技能存储任务最重要的知识，并让技能与技能条件下的上下文一起迭代进化。实现上，一个上下文函数 c 被实例化为专用目录下的一组文件，包含静态组件（skill.md）与动态组件（上下文与数据 rollout）。元层与基础层优化都在智能体编程环境中执行，使用标准工具集：

𝒯 = {Read, Write, Edit, Bash, Glob, Grep, TodoWrite}

Meta-Harness（Lee et al. 2026）又深入了一层：被优化的对象是代码本身，即决定”哪些信息应被存储、检索并呈现给模型”并对此进行优化的代码。名字里的”Meta-“意味着：它是用于优化 Harness 的 Harness。

2.2 工作流设计

Harness 工程中的工作流设计可以由领域专家手工完成。以自动化研究为例，已有多个框架被提出并验证。AI Scientist 系统（Lu et al. 2026）构建了一条流水线：提出研究想法、写代码、跑实验、分析结果、撰写论文手稿并执行同行评审。Meng et al.（2026）则把”可验证性”作为ScientistOne 的核心设计约束：每一条论断（引用、数值、方法、结论）都必须可追溯至证据来源，并由”证据链（Chain-of-Evidence）”检查进行审计。

（图5：AI Scientist 的流水线：想法生成、实验、论文写作与评审。图片来源：Lu et al. 2026）

Autodata 智能体（Kulikov et al. 2026）被设计为一名数据科学家，负责生成训练与评估数据。主智能体管理着一个提出问题的挑战者（challenger）、一个弱求解器（weak solver）、一个强求解器（strong solver）和一个验证器/裁判（verifier/judge），目标是合成难度”刚刚好”的数据，即强求解器能解出、而弱求解器解不出。

在 Autodata 中，挑战者的提示词会根据求解器与验证器的反馈迭代更新。其局限在于：合成任务被用于微调弱求解器而非强求解器；如果这个循环无法迭代改进强模型，那它更像是在生成的提示词分布上做间接蒸馏，RSI 的意味就淡了些。

（图6：Autodata 的智能体工作流设计，围绕挑战者、求解器与验证器角色生成合成训练与评估数据。图片来源：Kulikov et al. 2026）

工作流的设计空间是巨大的。我们自然可以把工作流设计看作一个搜索问题，从而应当能用算法找到好的方案，而非只能手工打造。沿这一方向，智能体系统自动化设计（Automated Design of Agentic Systems，ADAS；Hu et al. 2025）把智能体设计本身形式化为一个优化问题，”元智能体搜索（meta-agent search）”：由一个元智能体提出新的智能体工作流设计。

• 用 CoT、self-refine 等简单智能体初始化一个工作流档案库。
• 让元智能体以代码形式编写新智能体，灵感来自档案库中的现有方案。

• 元智能体先生成新工作流的高层描述，再用代码实现。

• 草稿程序再经过两轮自我精炼（self-refine，即让模型给出反馈，再让同一模型基于反馈改进之前的输出；Madaan et al. 2023），由元智能体检查其新颖性。
• 评估每个新候选，把成功者加回档案库。
• 重复步骤 2–3，直到达到最大迭代次数。
  

（图7：ADAS 示意。图片来源：Hu et al. 2025）

AFlow（Zhang et al. 2025）把智能体工作流表示为一张图：节点代表调用 LLM 的动作，边用代码实现逻辑操作。其工作流优化依赖 MCTS（蒙特卡洛树搜索）：

• 用模板初始化起始工作流 W_0，作为树的根。
• 按”得分 + 均匀探索”的软混合策略选择一个工作流节点。
• 让 LLM 基于该节点的评估表现生成一个修改后的工作流，完成扩展。
• 执行并评估新工作流。
• 若新工作流在 N 轮预算内有改进，则加回树中。
• 重复步骤 2–5，当 top-k 平均分进入平台期或预算耗尽时停止。
  

（图8：AFlow 在工作流候选树上的优化过程。图片来源：Zhang et al. 2025）

AFlow 在问答、代码与数学任务上的实验显示，它相比人工设计的工作流和 ADAS 都有可观的提升。

（图9：AFlow 与人工方法、ADAS 的实验对比。图片来源：Zhang et al. 2025）

2.3 自我改进的 Harness

无论上下文工程还是工作流设计，都只是 Harness 的一部分。我们需要在整个设计空间中搜索，把上下文管理逻辑、工作流、权限以及许多其他 Harness 组件放在一起优化。正如 Meta-Harness、ADAS、AFlow 等工作中所见，✨代码✨是定义程序与系统的通用语言。简言之，Harness 就是用代码来编排提示词、工具调用、子智能体、控制流、记忆与工作流逻辑如何协同。如果 LLM 能优化执行智能体的代码，它就能触及比手写提示词大得多的设计空间。

自教自学优化器（Self-Taught Optimizer，STOP；Zelikman et al. 2023）是递归式脚手架（scaffolding）改进的早期例子。在 t=0 时，种子改进器 I_0 接收初始解 s、效用函数 u 和黑盒语言模型 M，返回改进后的解 s′，即 s′ = I(u, s; M)。STOP 的目标不是直接改进 s，而是改进改进器 I 本身。

首先，把元效用（meta-utility）定义为给定改进器函数 I 在一组下游任务 𝒟 上的平均效用：

û(I) ≜ (1/|𝒟|) · 𝔼_{(u,s)~𝒟}[u(I(u, s; M))]

由于改进”改进器函数”本身也是一个优化问题，我们可以基于 I_{t-1} 在元效用下的表现，递归地得到 I 的新版本，即自我改进更新：

I_t = I_{t-1}(û, I_{t-1}; M)

（图10：STOP 算法。图片来源：Zelikman et al. 2023）

实验中，进化后的改进器发现了多种策略，如遗传算法、分解并改进局部、多臂提示词老虎机（multi-armed prompt bandits）、模拟退火、调节温度、束搜索/树搜索等。这类似于把 Harness 工作流表示为可优化的对象。

（图11：STOP 发现的自我改进策略示例。图片来源：Zelikman et al. 2023）

Zelikman et al.（2023）的一个警示性结果是：STOP 在 GPT-4 下能逐轮提升下游平均表现，但在 GPT-3.5、Mixtral 等较弱模型下反而退化。仅有递归结构是不够的，基础模型必须足够有能力才能改进机制。这意味着：Harness 改进能让模型部署得更好，但智能仍是核心。

Lin et al.（2026）更细致地考察了 Harness 进化对模型能力的依赖。他们拆解出两个轴：(1)Harness 更新能力（harness-updating），产出有用 Harness 修改的能力；(2)Harness 受益能力（harness-benefit），利用更新后的 Harness 更好地解决任务的能力。有趣的是，实验中从 Qwen3.5-9B 到 Claude Opus 4.6、不同规模与核心智能的一系列模型，表现出相近的 Harness 更新能力：9B 的 Harness 提议者/进化者写出的技能，与 Opus 在过程上几乎同构。而要充分利用 Harness，模型需要正确且适时地调用技能/工具，并擅长长程指令遵循。

（图12：主要结果 (A) 从 Qwen2-32B 到 Opus 4.6，Harness 更新能力大体持平；(B) Harness 受益能力呈非单调，中间档模型受益最大。图片来源：Lin et al. 2026）

更近的工作 Self-Harness（Zhang et al. 2026）依靠 LLM 智能体通过”提议—评估—接受（propose-evaluate-accept）”循环来改进自己的 Harness。

（图13：Self-Harness 使用”弱点挖掘—有界 Harness 提议—验证”的循环来更新 Harness。图片来源：Zhang et al. 2026）

Self-Harness 的循环有三个阶段：

• 弱点挖掘（Weakness mining）：把失败聚类为”有验证器依据”的失败模式。

a.用当前 Harness h_t 在任务上评估，收集执行轨迹用于分析。

b.注意：两次运行在错误日志表面上可能有着相同的验证器结果（如超时、产物缺失），却有着不同的因果机制。因此需要信息丰富的失败记录，包含最终的验证器层原因、相关智能体行为的因果状态、以及轨迹暴露出的抽象智能体机制，以揭示根本原因。

• Harness 提议（Harness proposal）：基于挖掘出的失败模式，提出有界的 Harness 修改。

a.同一模型在 h_t 下被调用，充当提议者。

b.模型获得一个有界的提议上下文：(1) 当前 Harness 的可编辑面；(2) 来自评估系统的、有验证器依据的失败模式；(3) 应当保留的通过行为记录；(4) 过往已尝试修改的摘要。

c.Harness 修改应优先针对反复出现、且可解决的错误模式（而非任务本身固有的难度），且能通过窄改动解决。

d.Harness 修改候选之间应当有区分度、有多样性。

• 提议验证（Proposal validation）：验证并合并合格修改，生成新 Harness h_{t+1}。

a.候选修改在 held-in 集 D_in（测试弱点是否解决）与 held-out 集 D_out（检查是否引入其他未知问题）上做回归测试。

b.只有在 held-in 与 held-out 上均无回归的候选才会被接受。

c.被接受的候选被合并以更新 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）的所有挑战依然存在。

智能体 Harness 工程（Agentic Harness Engineering，AHE；Lin et al. 2026）认为，Harness 进化的瓶颈在于可观测性（observability），即当一次 rollout 失败时，我们需要知道是哪个组件导致的，且每次修改都要有证据支撑。

该框架以三根可观测性支柱构成闭环：

• 组件可观测性：每个可编辑的 Harness 组件都在文件系统中有对应表示，使动作空间显式且可追踪。

a.一个 Harness 包含 7 个组件：系统提示词、工具描述、工具实现、中间件、技能、子智能体配置、长期记忆。

b.每种失败模式被映射到一个组件，使修改更有针对性。

• 经验可观测性：把大量原始轨迹分析、汇总为”证据与失败模式”的层级结构。

a.每个 Harness 生成 k 条轨迹。

b.用一个智能体（”Agent debugger”）分析每条存储为独立文件的轨迹，生成逐任务的成败根因分析报告。

c.所有逐任务报告被聚合为基准总览供下一步使用，原始轨迹在需要时可访问。这种分层访问结构更省 token。

• 决策可观测性：每次修改都配对一条”对下一轮的预测”，以供验证。

a.一个智能体（”Evolve agent”）阅读仓库、决定编辑哪个组件，然后产出修改及其理由。

b.每次修改都是一条文件级的、可证伪的声明，可在下一轮被验证，并受两条约束：

i.修改仅应用于 Harness 工作区；runs 目录、tracer、验证器与 LLM 配置均为只读。这禁掉了一类奖励黑客行为（如禁用验证器、更换模型、抬高推理预算），从而保证记录的每一点收益都可归因于 Harness 修改。

ii.修改必须由证据驱动，并附一条”宣言（manifesto）”条目：失败证据的名称、推断的根因、针对性修复、以及预测影响（包含预期修复项与存在回归风险项）。

在 Terminal-Bench-2 上，AHE 超过了人工设计的 Harness（OpenCode、Terminus-2、Codex）（Hard 档除外）以及若干自我进化基线（ACE、TF-GRPO）。同一套冻结 Harness 不经继续进化即可迁移到 SWE-bench-verified，说明进化出的 Harness 能把工程经验编码进 Harness 组件，而非做针对特定基准的过拟合优化。

2.4 进化搜索

进化搜索是一种受自然选择启发的优化方法（参见我此前关于进化算法的旧文）。它通过变异来进化一个解的种群，只保留群体中”适应度”高的个体。进化搜索在以下情形很好用：(1) 搜索空间庞大或形状怪异；(2) 难以直接用梯度优化、但容易评估解。Harness 搜索看起来非常适合。

过去的研究已将进化搜索用于提示词工程。Promptbreeder（Fernando et al. 2023）通过丰富的变异操作优化任务提示词；有趣的是，变异提示词本身（即指示 LLM 去变异任务提示词的指令）也通过进化来改进。GEPA（Agrawal et al. 2025）把基于反思的提示与进化搜索结合，用对试错轨迹的自然语言反思来提出提示词更新。

Novikov et al.（2025）提出了 AlphaEvolve，一个编程智能体进化搜索系统：它维护一个候选程序池，提示冻结的 LLM 生成用于改进的 diff。随着系统反复评估子程序并保留成功者，它会随时间发现更好的解。

（图14：AlphaEvolve 的工作方式。图片来源：Novikov et al. 2025）

AlphaEvolve 的设计中有几个关键细节：

• 提示词中包含父程序、结果、指令，有时还有元信息。
• 编程智能体可访问完整仓库，但待改进的代码区域用 #EVOLVE-BLOCK-START 与 # EVOLVE-BLOCK-END 显式标记。
• 元提示词（meta-prompt）按 LLM 的建议与指令、上下文共同进化，方式与我们进化解程序类似。
• 消融实验显示了进化流程、提示词中的上下文、元提示词、整文件进化以及使用更强 LLM 的价值。
  

（图15：消融实验证明 AlphaEvolve 若干设计的价值。图片来源：Novikov et al. 2025）

近期的变体如 ThetaEvolve（Wang et al. 2025）把进化搜索与 RL、上下文内学习结合；DemoEvolve（Che et al. 2026）用人类专家演示增强自我 rollout 档案库，作为 Harness 层诊断与编辑的参考经验。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（参数：）；(2) editor（参数：view/create/edit）。
• 新编程智能体被评估，只有表现足够高的才会被加回池中。
• 重复步骤 2–4，直到满足停止条件。

DGM 是固定模型下的 Harness 进化。在以 Claude 3.5 Sonnet 为基础 LLM、初始 Harness 配置很简单的实验中，DGM 发现的智能体在 SWE-bench Verified（20% → 50%）与 Polyglot（14.2% → 30.7%）上与手工打造的智能体相当或更优。

这一族方法在候选解可自动评估、适应度易量化的场景效果很好，如矩阵乘法、GPU kernel 优化、算法竞赛、数据中心调度。在评估缓慢、模糊或主要依赖启发式的领域则很吃力。进化的算力效率与有效性也是隐忧。

2.5 与模型权重的联合优化

Harness 进化改变的是模型外围的非参数系统。要实现完全的自我改进，模型当然也完全可以被允许同时更新自己的权重。权重更新可以通过改进模型训练流水线，或在测试时进行持续学习来实现。持续学习这个主题值得未来单独写一篇文章。

SIA（Hebbar et al. 2026）是把 Harness 改进与模型参数更新放进同一优化循环的早期尝试，设计上有三个组件：

• 元智能体（Meta-Agent）：提出初始 Harness。
• 任务智能体（Task-Specific Agent）：执行任务。
• 反馈智能体（Feedback-Agent）：基于近期轨迹，决定下一步更新 Harness 还是更新模型权重。
  

（图16：SIA 中的反馈智能体决定下一次迭代的类型。图片来源：Hebbar et al. 2026）

SIA 的实验中存在一些混杂因素，使结果难以解读。例如，任务智能体远弱于元智能体与反馈智能体所用的模型（gpt-oss-120b vs Claude Sonnet 4.6），基线也太弱，无法与相关方法干净地交叉对照。我认为这个方向有趣，但证据尚属初步。训练稳定性、古德哈特效（Goodhart effect）等许多挑战仍然悬而未决。

Continual Harness（Karten et al. 2026）在长程游戏场景中实验了 Harness 更新，并通过在低奖励轨迹上蒸馏强教师模型的标签来共同学习一个策略模型。

三、未来挑战

AI Scientist 这一系列工作有力地证明：专家设计的 Harness 能协调自动化研究循环的大部分环节，其实验形式是撰写研究论文。但”论文产出”并不等同于”科学发现”。一个系统可以写出看似可信的手稿，同时仍存在伪造引用、实现漂移或实验结果薄弱的问题。

Trehan & Chopra（2026）测试了 LLM 能否在极简脚手架和基础工具（即read_file、write_file、llm_search、list_files）下从一个研究想法走到一篇论文。每个想法有独立工作区，智能体可以生成并阅读文档作为上下文的一部分。他们在三个领域（世界模型、多智能体 RL、AI 安全与对齐）做了实验，每个领域含 45–50 篇高质量种子文档以激发新想法。只有四个想法被人类专家选中跑完整流水线，且只有一个被完整执行成论文。他们观察到六种反复出现的失败模式：

• 偏向训练数据默认值：使用旧库、过时命令、标准格式，或未经实际仓库/数据集验证的假设。
• 执行压力下的实现漂移：当实现变得技术上复杂时，模型可能转向常见的更简单方案，而非所提出的方法。
• 记忆与上下文退化：长程项目会丢失关键细节，除非日志被写成持久产物。
• 过度乐观：尽管实验充满噪声或已失败，模型仍宣布成功；Bubeck et al.（2025）也观察到类似的”p 值操纵与 Eureka 时刻”模式，模型会引入”数值创可贴”，在信号仍是噪声时就宣布胜利。
• 领域智能不足：模型缺乏默会的技艺性知识，如预估实现复杂度、判断实验结果是否合理、知道哪些基线重要。
• 科学品味薄弱：实验也许可以执行，但没能回答正确的问题。

迈向完全的 RSI，研究者们已取得实质进展，但仍有若干瓶颈：

1. 评估器弱且模糊。许多研究论断没有快速精确的验证器，许多真实世界任务也是如此。当前的自我改进循环在评估指标可测量、客观的任务上效果最好，这与 RL 的奏效条件相似。而研究品味、新颖性与长期科学价值要难衡量得多。例如，研究品味往往混合了问题框定、实验设计，以及”哪些意外结果值得追、哪些失败案例值得重试”的判断。

2. 上下文与记忆的生命周期。随着 AI 智能体变得更自主独立，记忆会不断增长。一个有用的 Harness 需要管理上下文与记忆，在弥补长上下文生成现有局限的同时，最大化长程任务的成功率。既然人类能终身维持记忆，我在此看到一个类比：上下文工程将会、也应当成为智能的核心组成部分，而不是停留在软件系统层。

3. 阴性结果（negative results）。研究者的激励是发表成功结果，因此文献偏向成功。训练于海量数据（至少目前 mostly 是人类创造的，笑）的 LLM，可能不擅长决定何时放弃一个假设、报告一个阴性结果、甚至承认一次失败，因为数据中成功与失败案例不平衡。一个研究型 Harness 应让失败的尝试易于保存，因为从失败中学习是削减任务搜索空间的最佳方式。

4. 多样性坍缩。进化与 RL 循环倾向于利用已知的高奖励模式。我们需要机制来防止种群坍缩成同一个解的变体。这对开放式研究尤其关键，最好的路径在当前评估器下可能起初看起来更差。

5. 奖励黑客（reward hacking）。自我改进循环优化的是任何被给予的信号。如果奖励来自单元测试，智能体可能对测试过拟合；如果来自裁判模型，它可能学会针对该裁判的奖励黑客技巧；如果来自基准分数，它可能利用基准的漏洞。

评估器与权限控制很可能应当置于进化 Harness 的循环之外，辅以 held-out 测试、轨迹审计、以及在关键决策点的人类评审，”多大程度的监督可以被规模化与自动化”仍是一个开放的研究领域。

6. 长期成功。外在优化循环作用于单次 rollout 之外的奖励，而我们只能在训练沙箱中模拟这些 rollout。

以编程智能体为例。编程智能体已经提升了软件工程的日常生产力，但许多优化目标仍过于短期。它常常能完成手头任务，但对于”如何维护一个由数百上千名工程师共同维护的仓库的长期健康”，答案就不那么明显了。标准的沙箱式 RLVR 训练很少捕捉到可维护性、所有权边界、迁移成本、向后兼容性或未来的调试负担。

7. 人的角色。人类应当向栈的上层移动，而不是被移出循环，即人类应在恰当的时间、恰当的抽象层级提供监督，我们的系统设计应考虑何时、如何设置这样的接触点。

上面列出的许多挑战都需要人类的反馈与引导。毕竟，我们构建这项技术是为了人类更好的未来，而不是反过来。

本文引用：

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