从自我改进智能体到 Harness 工程：Recursive Self-Improving Agent 调研

本文整理自《Paper Survey》演示文稿，讨论递归自我改进智能体（Recursive Self-Improving Agent，RSI）、典型自我改进 Harness，以及编码智能体的 Harness 工程。文中涉及论文版本、引用量和开源项目数据均来自原始调研材料，发布前建议再核对其最新元数据。

从自我改进智能体到 Harness 工程

大语言模型驱动的 Agent 已经具备长程规划、代码生成、工具使用和反思能力，但让系统持续变强，仍然高度依赖人工：人来诊断瓶颈、重新设计工作流、编写实现、构造数据并安排下一轮训练。

Recursive Self-Improving Agent（RSI）关注的正是这一层问题：智能体不仅完成任务，也根据经验和评估反馈更新自身；进一步地，它还能改进“如何改进自己”的机制。

1. 一个早期例子：OpenSearch-VL

现代 Deep Search Agent 往往需要主动检索、证据核验和多步推理。OpenSearch-VL 的材料提供了一个面向视觉检索的实践例子：

• 训练数据从 Wikipedia 路径采样、模糊实体改写和 source-anchor visual grounding 等流程构建，得到 SearchVLSFT-36k 与 SearchVL-RL-8k；
• 系统可调用文本检索、图像检索、OCR、裁剪、锐化、超分和透视校正等工具；
• 多轮训练中采用 fatal-aware GRPO：发生工具故障后屏蔽相关 token，避免故障沿后续轨迹级联，同时保留故障前仍有效的推理片段。

它反映出一个现实问题：即使模型能力足够，公开数据、轨迹合成流程和训练细节若不透明，其他人也很难稳定复现 Agent 能力。

2. RSI 的定义与组成

自我改进智能体根据执行经验和评价反馈，更新其内部组件或参数。可以将一个 Agent 抽象为五类可改进对象：

符号	组件	作用
M	Foundation Model	理解语言、规划、生成代码和调用工具
H	Agent Harness	观察状态、组织流程、管理工具与执行环境
D	Agent Data System	生产并利用环境、任务、轨迹和评价数据
T	Agent Trainer	将训练证据转化为模型更新
Imp	Improvement Mechanism	诊断、提出候选、验证并集成改进

“自我改进”通常指其中一个组件发生变化，例如更新记忆库或重写工具调用流程。“协同改进”指多个组件共同变化，例如 Harness 改进后产生更有价值的轨迹，再由数据与训练模块将其转成模型能力。

RSI 的关键区别在于 Imp 本身也会演化。若一个固定的优化器只是反复改 Prompt 或调参，它仍属于自我改进系统；只有优化器的诊断、搜索与验证方式也能被后续证据更新，才进入递归自我改进的讨论范围。

一个完整的改进周期可概括为：定位瓶颈，提出修改候选，验证与筛选候选，再将有效候选纳入系统。真正困难之处不在于“生成一个修改”，而在于证明它在未知任务上仍然有益，并能在失败时安全回滚。

3. Harness 自我改进

Harness 决定基础模型在什么状态下看到什么信息、可以执行什么动作，以及如何处理失败。它的改进不直接改变模型权重，而是改变模型调用时的外部条件、接口和可执行脚手架。

3.1 模块层改进

模块层改进主要围绕记忆、技能与工具、Prompt 和上下文展开。

记忆。 将交互轨迹压缩为反思、示例、原因分析或经验条目，存入可检索的经验库。关键问题不只是“记住什么”，还包括如何组织、何时写入、如何压缩、检索是否可信、何时遗忘。层次化记忆、结构化语义、动态索引笔记、图结构和文档结构都是常见方向。

成熟的记忆机制还需要门控与信用分配：系统应判断一条记忆是否仍有价值、是否可靠、能否迁移到新任务。否则错误经验会随着复用不断放大。

技能与工具。 可复用能力可以是代码、函数、API、工作流或技能文档。Agent 能从轨迹和外部资料中构造能力库，并进行去重、重构、合并和生命周期管理。更深一层的改进是学习何时选择、组合、细化或替换技能。

Prompt 与上下文。 系统提示词、任务指令、few-shot 示例、规则文档和上下文 playbook 都可视为可优化的外部参数。优化信号可以来自监督反馈、执行结果或可回滚的环境交互。多次模型调用时，难点会转为信用分配：究竟是哪个提示、哪个上下文片段或哪个工具结果带来了成功。

3.2 编排与架构

难任务通常无法由一次连续调用或固定工作流解决。编排层负责决定轨迹如何分叉、资源投向哪些候选、多个 Agent 如何协作以及反馈如何路由。

常见机制包括：

• 将推理、行动和规划视作搜索节点，采用 beam search、tree search 或蒙特卡洛树搜索；
• 根据验证反馈、动作熵或失败信号，决定分支扩展、剪枝、修复或重启；
• 缓存高价值轨迹并通过日志检索、蒸馏或表示引导跨任务复用；
• 通过遗传算法、角色分工或元智能体搜索多 Agent 团队结构；
• 优化工作流拓扑和通信方式，减少冗余消息，并根据任务复杂度和预算切换协作模式。

编排的目的不是无边界地增加 rollout 数量。有效的系统需要尽早识别局部错误，有可信的选择信号，并把有价值的中间结果保留下来影响之后的决策。

3.3 自指式代码修改

自指式修改把可编辑范围扩大到 Harness 或 scaffold 自身。Agent 可以修改运行规则、动作接口、工具契约、运行时约束，甚至修改负责诊断和改进的程序。

这类系统一般会使用失败信号、代码审查、反事实分析和测试结果定位问题，再修改 Harness 代码并验证候选。STOP 一类方案把这一过程递归应用于改进器，逐步形成 beam search、遗传算法等更强的搜索程序。

开放式递归修改的风险也更高：一次错误提交可能污染记忆、工具和后续训练数据。因此需要把候选与当前版本比较，只在通过门槛时提交，保留版本历史与回滚能力，并将安全监控纳入改进循环。

4. Agent Data System 自我改进

数据系统包含两部分：数据生产与数据利用。前者生成或仿真环境、合成任务和轨迹，并完成验证与质量控制；后者决定数据的选择、排序、配比和课程安排。

4.1 数据生产

环境是 Agent 获得反馈的主要来源。高质量数据生产需要同时关注真实性、有效性、多样性和难度分布。合成环境如果退化为不可解、过于简单或与真实任务偏离，后续训练将失去意义。

任务合成需要定义任务指令、环境状态、约束、可用工具、可验证标准以及必要时的示范轨迹。质量控制可以使用规则、模型一致性、结构检查和外部验证器。另一种更具挑战性的信号是能力边界匹配：生成强模型可解、弱模型难解的任务，以持续逼近当前能力边界。

轨迹方面，可以通过竞争式交互、答案细化、恢复轨迹和受控扰动，获得正确性、难度和多样性更高的经验。验证器自身也可以改进，但必须防止它与生成器形成自我确认的闭环。

4.2 数据利用与课程适配

固定的数据配方很容易成为瓶颈。课程适配器可以根据训练反馈调整难度、选择数据子集，或为不同能力缺口重新分配训练预算。

• 规则式适配：预先定义更新规则，例如依据 reward 调整工具数量、交互步数或系统提示的具体程度；
• 离线学习式适配：在部署前联合学习难度估计器、元策略或奖励模型；
• 在线学习式适配：训练时让 curator 选择预计能带来最大提升的问题，性能变化再反馈给 curator。

数据生产和利用可以协同更新。Capability Boundary Matching 根据求解器当前能力边界决定下一轮生成与选择的数据；Goal-directed Curriculum Bridging 则从目标任务出发，判断中间训练任务是否真的构成通往目标能力的有效台阶。

5. Agent Trainer 自我改进

Trainer 决定训练证据如何变成模型更新，可分为监督设计、优化策略和训练基础设施三部分。

5.1 内循环适配

内循环中，当前训练的证据直接修改 Trainer，但改进机制本身保持固定。可变内容包括：

• 标签、奖励、批评、教师目标以及 rubric；
• 步骤级奖励和更细粒度的信用分配；
• 不同监督信号的路由与权重；
• 目标函数、优化算法和学习率、batch size 等超参数；
• CUDA kernel、分布式拓扑、并行策略和资源调度。

例如，系统可根据梯度噪声、吞吐量和设备负载动态调整 worker 数量或 collective topology。关键在于，这些重配置应由运行时证据触发，而不是仅靠人工静态设置。

5.2 外循环训练器搜索

外循环跨越多个训练实验。每个实验按常规方式训练模型，实验之间则由改进机制读取日志、reward、KL、回复长度等证据，提出新的训练器候选，并在验证协议下选择是否保留。

一个稳健的外循环应完成以下事情：

1. 将原始日志转为能绑定到明确版本的诊断证据；
2. 明确故障方式、可能原因、影响对象和不确定性；
3. 生成可执行的候选，包括配置修改、损失或奖励代码、采样策略与完整训练流水线；
4. 用完整训练、多保真评估、共享 checkpoint 分支和多随机种子验证候选；
5. 将 no-change control、置信阈值和 abstention 规则写入决策流程。

5.3 元循环：改进机制也要演化

元循环的目标是让 Imp_t 根据多个训练周期的累计证据演化为 Imp_{t+1}。改进对象可以是负责后续决策的模型，也可以是其运行 Harness，例如分析器、技能、执行代码、角色分配和团队组织。

当现有证据无法解释实验结果、无法区分竞争假设，或无法证明下一项干预合理时，系统不应只修改训练配置，也应有能力修订诊断与组织机制本身。

6. 跨组件协同改进

组件之间天然相互依赖。更好的 skill、tool、workflow 和 scaffold 会产生更有信息量的轨迹与训练信号；训练后的策略变化又会揭示 Harness 中最值得修订的模块。

几个典型闭环包括：

• Harness 与 Trainer：技能与经验回放可作为条件信号或蒸馏目标，训练后的新策略继续细化技能库；
• Harness 与 Data：改进工具和 Harness 代码扩大动作空间，失败轨迹与调试记录反过来推动新工具和新代码；
• Data 与 Trainer：更好的训练产生更有价值的数据，数据质量提升又进一步改善训练；
• 模拟器与 Policy：真实轨迹修正 world model，改进后的 world model 再在当前策略的薄弱区域合成经验。

难点是跨组件信用分配。面对状态

$$
z_t = {\text{trace}, \text{error}, \text{reward}, \text{history}, \text{cost}},
$$

系统需要决定下一步应更新 Prompt、Memory、Tool、Harness、Data、Weights 还是 Trainer，也可能需要联合更新多个组件。

7. 开放问题

7.1 需要多少外部真实信号

自我改进若过度依赖系统内部生成的标签、评价和经验，可能出现多样性坍缩、奖励投机、评价器漂移和自我确认错误。真实答案、单元测试、环境反馈和人类评价等外部信号能打破该闭环。

可以把外部可靠信号的比例记为 $\alpha$。一个值得研究的问题是，是否存在临界值：高于该值时系统能够持续改善，低于该值时误差会逐步放大。直觉上，所需的 $\alpha$ 与验证器可靠性正相关，与系统内部错误放大能力负相关。

从可靠性看，形式化验证器通常强于执行反馈，执行反馈通常强于学习型 Judge，学习型 Judge 又强于纯粹的自评估。如何提升内部信号的可审计性，仍是 RSI 的核心问题。

7.2 如何证明“改进机制”真的进步

单次性能提升不足以证明 RSI。更有说服力的实验应比较：固定 Imp_0 下的 $A_0 \rightarrow A_1 \rightarrow A_2$，以及更新改进机制后的 $A_0 \rightarrow A_1 \rightarrow A_2’$。若后者在未见任务、多个周期和多个领域中更稳定，才能说明机制本身发生了改善。

7.3 安全与可信性

错误或恶意投毒的经验一旦被写入 skill、memory 或 evaluator，可能跨任务持久化并持续放大。安全设计至少需要覆盖候选门控、版本追踪、可回滚状态、独立验证、权限隔离和异常审计。

8. 案例一：Darwin Godel Machine

Darwin Godel Machine（DGM）将自我改进聚焦在编码 Agent 的 Harness 上：基础模型保持固定，系统修改自身源代码与 Agent 设计，并在下游任务评估改进效果。

经典 Godel Machine 强调通过数学证明确认修改有益，DGM 则采用实验验证。其基本思想是：搜索空间巨大且容易陷入局部最优，因此将探索得到的候选都归档，保留多样性和未来可能有用的分支。原始材料中提到其在 SWE-Bench、Polyglot 等编码评测上进行探索，并使用沙箱与可追溯改进记录控制风险。

这个案例的循环很直接：编码能力提升，有助于改进自身代码；更好的 Harness 又反过来提升编码能力。真正需要谨慎验证的是，这种提升是否来自对特定 benchmark 的适配，还是能够迁移到未见任务。

9. 案例二：Prime Agent

Prime Agent 将自己定位为长程 evaluation 与 coding agent，并用 Recursive Language Model（RLM）和 Continual Harness 支持跨任务的持续状态。

9.1 信息与计算管理

RLM 通过持久化的 IPython REPL 让模型用程序化方式处理上下文、执行测试和调用工具；递归子 Agent 可以并行工作并相互通信。Harness 负责将模型选择的动作转换为代码执行、工具调用或子会话，并记录模型调用、工具使用、消息、资源消耗和 Harness 修改。

材料将状态分为四层：

层级	类比	保存内容	典型更新
L0	CPU	模型权重、先验知识与推理能力	微调，通常保持固定
L1	RAM	当前模型可见的活跃上下文	压缩与重启
L2	进程	REPL、工具、变量、子 Agent 状态	创建、保留、总结、删除
L3	硬盘	history、artifacts、memory、skills、prompts、子 Agent 规范	Refinement 与版本化更新

L2 到 L1 的信息会通过打印结果或返回值序列化为 token；L1 中的旧对话可压缩并归档到 L3；运行时再把相关的 L3 条目检索并注入 L1。这样可以在有限上下文内维持较长任务链，同时保留恢复、分支和回滚的基础。

9.2 Continual Harness

Continual Harness 位于 L3，保存四类持久条目：Prompt note、Memory、Skill 和 Subagent Specification。它支持创建、读取、更新与删除；Refinement 会把轨迹证据转为带版本控制的状态更新，记录来源与预期效果。

从这个角度看，自我改进就是把有价值的执行过程沉淀为下次任务可复用的外部状态：有用计算变成技能，重复协作模式变成子 Agent 规范，修正后的假设变成记忆或提示笔记。

9.3 调研材料中的一次实验记录

原始材料记录了一个小规模 Polyglot 设置：使用 GLM-5.3-flash，随机选取 5 个任务，Refine 前首次通过率为 60%，Refine 后为 100%。该结果规模有限，适合作为持续改进机制的演示，而非普适能力结论。

阶段	Input tokens	Output tokens	Cache read	Cost ($)
前置 5 个任务	60,945	79,548	335,872	0.0256
Refine	24,693	4,301	70,912	0.0036
启用改进	128,230	68,604	909,056	0.0370
未启用改进	25,405	53,403	444,160	0.0200

四个任务执行示意如下：

该例子也说明一个务实的取舍：Refine 可以带来收益，但需要额外 token、执行时间和可靠验证机制。任务变难后，如何避免“总结出错误规则并长期复用”会变得更关键。

10. Harness 工程：编码 Agent 的运行时

可以将编码 Agent 简化为：

$$
\text{Agent} = \text{Base Model} + \text{Harness}.
$$

Harness 负责 Agent loop、上下文、工具、执行环境、权限、记忆、子 Agent、恢复、验证和扩展。随着基础模型能力接近，竞争重点逐渐转到这套运行时系统如何组织模型能力。

调研材料将 Harness 拆为七个部分：Agent Loop、LLM Integration、Tool & Action System、Memory & Context、Safety & Permission、Orchestration 和 Extensibility。

10.1 Agent Loop

最常见的是迭代式循环：模型提出行动，Harness 执行并返回观察，再继续下一轮。更复杂的系统会加入反思、验证、并发调度、循环检测和预算控制。

系统	循环类型	并发策略	卡住检测	停止条件
Mini-SWE-Agent	线性 while	串行	步数、格式错误、运行上限	退出消息
Aider	生成器加反思	串行	最大反思次数	流结束且无反思
Claude Code	流式加批处理	安全分区批处理	手动处理	end_turn
Codex	异步状态机	有序 futures	材料未列出	end_turn
Gemini CLI	异步生成器加调度器	并行，编辑强制串行	SHA-256 加模型检查	end_turn 或 100 轮
OpenHands	事件溯源会话引擎	资源锁下的并行批处理	五类场景	FINISHED

循环本身越开放，就越需要明确的停止条件、资源预算和恢复策略，否则系统容易重复执行相似动作或在局部错误中消耗大量上下文。

10.2 LLM Integration

LLM Integration 负责模型调用、Prompt 组装、缓存、模型路由和推理内容管理。不同系统的共同趋势是将稳定内容与动态内容分开，以提高缓存命中率并降低重复 token 成本。

系统	Prompt 组织	缓存或路由特点
OpenHands	Prompt Registry，静态与动态模块分离	使用 cache_control 标记
Claude Code	多个命名模块并设边界	基于哈希与边界标记
Codex	服务端按模型提供 Prompt	以 thread 标识关联缓存
Gemini CLI	基础 Prompt、工具、项目上下文、memory、skills	模型变化时重建
Mistral Vibe	每个 Agent 独立 Prompt，可进行 A/B 版本选择	缓存 Git 状态
OpenCode	按模型类型匹配 Prompt 矩阵	多种缓存分界和 session key

10.3 工具与行动系统

编码 Agent 的工具系统不仅决定“能做什么”，也决定失败时系统能否给出可恢复的反馈。编辑操作尤其是一个工程重点。

系统	编辑接口	匹配和失败处理
Claude Code	精确字符串替换	唯一子串匹配，失败时返回错误和上下文
Codex	*** Begin/End Patch 补丁格式	统一 diff 块与块级重试
Aider	SEARCH/REPLACE、udiff 等多种格式	从精确匹配逐步放宽到模糊匹配
OpenHands	str_replace_editor、apply_patch 等	精确唯一匹配，支持撤销编辑
Gemini CLI	edit 与 write_file	精确、灵活、正则、模糊的级联匹配
Hermes	单一 Patch 工具加 DSL	多阶段匹配，失败后可升级到写文件
OpenCode	按模型切换 Patch 或 SEARCH/REPLACE	区分未找到与匹配歧义，并附加诊断

这里没有一种绝对最佳的编辑语言。精确匹配可预测但容易失败，模糊匹配更宽容却可能改错位置。成熟系统通常把格式设计、可理解报错、重试机制和预览或回滚结合起来。

10.4 Memory 与 Context

上下文管理决定长程任务能否延续。常见策略包括线性保留、递归摘要、可插拔压缩器、状态快照和会话树上的增量摘要。

例如，Aider 在历史超过上限后摘要前半段内容；OpenHands 将压缩器作为独立模块并把压缩过程写入事件日志；部分系统保留最近历史原文，同时把更早内容压缩为可恢复的状态。重点不是单纯缩短 token，而是让模型在压缩后仍能找到关键决策、错误证据和未完成的工作。

10.5 Safety 与 Permission

Agent 具有命令执行与文件操作能力时，安全不应只靠模型的自我约束。常见保护层包括执行策略、生命周期钩子、对高风险动作的审批审查，以及操作系统级沙箱。

权限系统应让模型知道哪些动作可直接执行、哪些需要确认、哪些被禁止，并保留精确的动作记录。自我改进系统还需额外限制：修改自身策略、工具和持久记忆时，应经过独立验证与可逆提交。

10.6 多 Agent 编排

多 Agent 运行时需要处理任务拆分、子任务并行、消息传递、结果汇总和资源隔离。除了提高吞吐量，编排还要避免同质化重复工作和无效通信。

一个可控的架构通常会明确父子会话的生命周期、可共享资源、消息边界、预算上限和中断后的恢复方式。对于复杂任务，分配更多计算给不确定性高的节点往往比平均扩展所有分支更有效。

10.7 扩展性：Skills、插件与 MCP

扩展机制决定 Harness 能否接入特定领域能力。调研材料显示，多个系统都支持 Skill，并逐步采用 SKILL.md 或 agentskills.io 兼容的描述方式。

系统	Skill 发现位置示例	调用或加载方式
Claude Code	.claude/skills/ 与用户目录	延迟加载的 Skill 工具
Codex	core-skills/、skills/ 与插件路径	列表、RPC、TUI 提及或隐式触发
Gemini CLI	.gemini/skills/、.agents/skills/ 等	ActivateSkill 按需加载
Mistral Vibe	.agents/skills/、.vibe/skills/ 等	skill 工具或 slash command
OpenHands	工作区、Git 根目录、用户目录等	展示元数据，再按需调用
Hermes	内置目录与 Skills Hub	index、查看正文、加载资源的渐进流程
OpenCode	配置目录、项目目录和远程 registry	原生延迟加载工具

一个值得注意的趋势是：通用 Agent 框架并没有成为主流编码智能体的核心依赖。许多系统选择用 Python、TypeScript 或 Rust 手写异步循环、工具注册表和权限逻辑，以换取更强的调试性、可控性与 Prompt 控制。同时，代码检索更常依赖 rg、tree-sitter、glob 和项目内 Markdown 指南，而不是通用代码 RAG。

11. 评测基准与“Bench of Bench”

编码 Agent 与 Harness 的评测常见于以下基准：

基准	主要任务	调研材料中的注意点
SWE-Bench	修复真实软件工程问题	有 Verified、Multilingual、Live、Pro 等变体，通常依赖 Docker
Terminal-Bench v4	在终端完成复杂真实任务	持续维护，通常依赖 Docker
Harness-Bench	直接评估 Harness 差异	较新，认可度仍需观察
TUA-Bench	通用终端使用	较新
OSWorld	GUI 与 computer-use	不局限于编码
tau2-Bench	Tool/API 与用户交互	材料指出部分任务可能存在质量问题

原始调研材料特别提到 tau2-Bench 的潜在问题：Airline 子集有 22/50 个任务可能在不执行操作时获得满分，44/50 个 communicate_info 为空时评分器仍可能给通信项满分；Banking 的个别任务曾出现退款金额或出生日期与金标不一致。这些例子提醒我们，benchmark 本身也需要验证。

因此，除了让 Agent 在 benchmark 上得分，更应评估 benchmark 是否正确、是否有区分度、是否存在投机路径，以及是否与真实能力相关。这个方向可以称为 “Bench of Bench”。

12. 可能的研究机会

Evo-Bench 被原始材料列为评估 LLM 内在 Agent 框架自我进化能力的一个方向。它区分两类分数：

• Overall Score：对冻结后的最终 Harness 在未见评测任务上打分，用于降低对已知任务过拟合的影响；
• Anytime Validation Score：衡量整个进化过程中的平均最佳验证表现，反映系统能否较快找到高质量 Harness。

除编码外，RSI 还可能进入 GUI/computer-use、机器人、科学发现、硬件与 EDA、医疗模拟等领域。每个领域都需要重新回答相同的问题：什么是可靠反馈，哪些状态可以持久化，什么修改应允许自动提交，以及怎样证明能力提升能够迁移。

13. 总结

RSI 不是给 Agent 增加一次反思或一个记忆库，而是把诊断、候选搜索、验证、提交与回滚组成可持续运行的闭环。Harness、数据系统、训练器以及改进机制本身都可能成为优化对象。

短期内，最务实的方向是构建可审计的局部闭环：用可靠外部信号验证记忆、工具、工作流或训练配置的改动；保留版本历史；在未见任务上验证；让失败可追溯且可回滚。长期目标才是让改进机制跨周期、跨组件、跨领域地稳定进化。

参考材料

• OpenSearch-VL、Recursive Self-Improving Agent 与 Harness 调研演示文稿
• Self-adapting Language Models，SEAL 项目
• Darwin Godel Machine: Open-Ended Evolution of Self-Improving Agents
• Prime Agent: A Self-Improving Recursive Language Model Harness
• Harness Engineering: Anatomy, Architecture, and Evolution of Coding Agents
• Evo-Bench