Harness Engineering for Self-Improvement（28 分钟阅读）

# 为自我改进而打造的套件工程 来源：https://lilianweng.github.io/posts/2026-07-04-harness/ **递归自我改进（RSI）** 的概念可追溯至 I. J. Good（1965）(https://philpapers.org/rec/GOOSCT)，他将“超智能机器”定义为一个能在所有智力活动上超越人类并设计出更好机器来改进自身的系统。 Yudkowsky（2008）(https://www.lesswrong.com/posts/JBadX7rwdcRFzGuju/recursive-self-improvement) 用“递归自我改进”一词特指一个反馈循环：AI 利用其当前智能来改进产生该智能的认知机制。在现代 AI 中，这个反馈循环可能意味着模型直接重写自身权重，或者更宽泛地说，模型改进了**训练流水线**和**部署系统**，进而催生出性能更强的后继模型，在经济上有价值的任务上表现更优。前沿实验室的研究速度已被证明大幅加快（Anthropic (https://www.anthropic.com/institute/recursive-self-improvement)；OpenAI (https://openai.com/index/how-agents-are-transforming-work/)）。我特意提到**“部署系统”**，因为原始模型与现实世界上下文之间的中间层与模型的原始智能（即预训练后的评估）同等重要。正如 Claude Code 和 Codex 等成功的编码代理产品所示，套件是 AI 部署的重要组成部分。 **套件（Harness）** 是围绕基础模型构建的系统，负责编排执行，决定模型的思考与规划方式、工具调用与行动方式、上下文感知与管理方式、构件存储方式以及结果评估方式。本文将聚焦于套件工程的研究及其如何推动 RSI。近期许多关于自动研究、自我改进代理和进化程序搜索的工作都可以围绕这一问题来组织。其他有关模型自我对抗、合成数据、测试时训练以及更广泛的持续学习主题的工作也符合 RSI 愿景（例如 Yuan et al. 2024 (https://arxiv.org/abs/2401.10020)、Chen et al. 2024 (https://arxiv.org/abs/2401.01335)、Zhao et al. 2025 (https://arxiv.org/abs/2505.03335)、Choi et al. 2026 (https://openreview.net/forum?id=lTbBFAoPSA)），但本文不会重点讨论这些内容。 ## 套件设计模式 相比早期的智能体框架 (https://lilianweng.github.io/posts/2023-06-23-agent/)，“智能体 = LLM + 记忆 + 工具 + 规划 + 动作”，套件工程额外包含**工作流设计（如循环工程）、评估、权限控制和持久状态管理**。它已不仅仅是提示模板，而更接近运行时与软件系统设计：模型如何观察、行动、记忆、自我检查和改进。设计应刻意简单且通用，以便泛化，可能需参考现有软件工程实践以受益于预训练知识。套件与操作系统之间也存在强烈的类比关系。类似操作系统，套件应封装复杂逻辑，同时保持接口简单。与此同时，配置、工具接口和其他协议可能会在整个行业中逐步标准化。 ## 模式 1：工作流自动化 定义一个能让模型操作、测试和迭代的工作流是自动化的关键设计。Karpathy 的 autoresearch 仓库 (https://github.com/karpathy/autoresearch) 是一个简洁的示例，展示了如何构建这样一个工作流。一个常见的工作流遵循目标导向的循环：规划、执行、观察/测试、改进、再次执行，**直到**达成目标。该过程可能会主动向用户请求澄清任务规范或执行偏好。 简化版 Codex 代理循环：代理调用工具，工具响应影响模型的下一轮生成。（图片来源：OpenAI codex 代理博文 (https://openai.com/index/unrolling-the-codex-agent-loop/)） 工作流图还强调模型分析自身轨迹和失败案例，然后通过“代理运行时”（而非静态提示模板）迭代其进展。 ## 模式 2：文件系统作为持久记忆 在长周期代理系统中，一个反复出现的模式是对丰富状态和构件的简单控制。套件不应将整个工作流和所有日志都携带在上下文中；相反，它应该将持久状态保存在文件中。在长周期代理展开过程中，实验日志、代码差异、论文摘要、错误追踪以及过去的展开轨迹等构件往往比模型训练所用的上下文窗口长得多。学习如何读写和编辑文件系统（通常通过 `bash` 命令）是 LLM 的基础技能，因此以简单的文件形式管理持久记忆自然会受益于核心模型能力的提升。 ## 模式 3：子代理与后台任务 套件可以生成多个子代理并行执行并监控后台任务。当主代理需要搜索多个假设、并发运行实验或委托隔离子任务而不污染主上下文时，这非常有用。父代理需要一个简单的进程管理器：启动任务、检查日志、取消失败运行，并将结果合并回主代理线程。关键设计选择是使并行性显式且可检查。如果子代理的输出仅存在于瞬时的聊天上下文中，它们很快就会变得过时且隐蔽。如果它们被存储为文件、日志和状态记录，模型可以在中断后恢复，并根据自己的执行历史进行推理。 ## 案例研究：编码代理套件 主流编码代理的核心接口在 Claude Code、Codex、OpenCode 和 Cursor 风格代理中已经趋于稳定。它们通常使用如下循环： 借助一套工具，编码代理能够在给定仓库中开发和调试问题，类似于人类开发者配备 IDE 的方式。（非详尽列表；仅作演示。感兴趣可阅读此内容 (https://github.com/yasasbanukaofficial/claude-code)。） | 组 | 工具定义 | |-----------|----------| | 文件系统 | - 文件发现：`glob`、`grep`、`ls`<br>- 文件读取：`read`、`read_many`<br>- 文件修改：`write`（全新文件）、`edit`（字符串精确匹配替换）、`multi_edit`、`apply_patch`（应用结构化补丁/差异） | | Shell 执行 | 运行命令：`bash`、`PowerShell` | | IO | `lsp`、git 工具如 `git_status`、`git_diff`、`git_commit` | | 外部上下文 | MCP 工具、技能 | | 网络搜索 | `web_search`、`web_fetch`、浏览器工具 | | 构件 | 读取文档、图像；生成 HTML、图像 | | 后台进程 | 例如：`CronCreate`、`CronDelete`、`CronList` | | 代理委托 | 例如：`spawn_agent`、`resume_agent`、`wait_agent`、`list_agents`、`close_agent`、`interrupt_agent` 等 | ## 套件层 vs 核心智能？ 很难预测未来 RSI 在多大程度上依赖于套件工程，但 RSI 的近期路径不太可能始于模型直接重写自身权重。我对实际近期路径的预测如下： 1. 套件工程将朝**元方法论**方向发展（即改进获取更好答案的机制，而不仅仅是改进答案本身）。套件系统本身成为优化目标，启发式规则减少，通用机制增多。 2. 反过来，成熟的套件使模型自我改进循环的自动研究成为可能，而更智能的模型则防止套件过度设计，保持系统可持续性。 最终，许多套件改进可能会被**内化**到核心模型行为中，但外部上下文和工具的接口应保持不变。我们已经看到提示工程 (https://lilianweng.github.io/posts/2023-03-15-prompt-engineering/) 中较温和的类似模式：随着指令微调和模型推理能力的提升，手动提示技巧的重要性下降，但**指定目标、约束、上下文和评估的需求并未消失**。 ## 套件优化 套件系统中优化对象的演进大致为： 指令提示 (https://lilianweng.github.io/posts/2023-03-15-prompt-engineering/) → 结构化上下文 → 工作流 → 套件代码 → 优化器代码 随着模型变得更加智能和强大，我们转向更复杂的目标和更通用的方法。 ## 上下文工程 简单地将所有工具响应和模型生成追加到上下文中，随着智能体任务时间跨度的显著增加，会迅速失控。上下文管理是一个层，用于为 LLM 构建更结构化、更简洁的上下文并管理持久状态。毫无疑问，长上下文研究将继续取得进展，但目前长上下文智能与上下文工程有时相互交织。 **智能体上下文工程**（ACE；Zhang et al. 2025 (https://arxiv.org/abs/2510.04618)）将上下文视为一个不断演化的剧本，而非越来越长的提示。它包含三个组件，用于维护一个由项目符号列表组成的上下文剧本，每个项目符号都有标识符和描述。 1. **生成器**：生成任务轨迹，引用项目符号。 2. **反思器**：从成功和失败的轨迹中提炼见解。 3. **策展器**：以增量、逐项条目更新结构化上下文。 智能体上下文工程（ACE）框架。（图片来源：Zhang et al. 2025 (https://arxiv.org/abs/2510.04618)） 为防止在迭代重写过程中出现上下文崩溃和简洁性偏差，ACE 的一个关键设计选择是策展器不重写完整的提示块。相反，它输出一组结构化的、逐项项目符号（标识符，描述），并通过确定性逻辑将这些项目符合并到结构化上下文日志中。上下文条目会定期精炼和去重。 ACE 从展开轨迹中学习见解这一事实使我们朝着自管理记忆的方向前进，但更新规则和整体工作流仍是手工制作的。为了实现更自改进的循环，**元上下文工程**（MCE；Ye et al. 2026 (https://arxiv.org/abs/2601.21557)）将机制（如何管理上下文）与构件内容（上下文中有什么）分离，在元优化层面运行技能进化，在基础层面运行上下文优化。 一个 MCE 技能 $s \in \mathcal{S}$ 定义一个上下文函数 $c_s=(\rho_s,F_s)$，并将输入 $x$ 映射到上下文 $c = F_s(x;\rho_s)$，其中： - $\rho_s = \{\rho_1,\dots,\rho_m\}$ 是静态组件（提示、知识库、代码库）。 - $F_s = \{F_1,\dots,F_k\}$ 是动态操作符（搜索、选择、过滤、格式化）。 双层优化是在训练数据上寻找给定技能 $s$ 的最佳上下文 $c_s^*$，而外部循环寻找在验证集上表现最优的技能： $$ \text{内部：} c_s^*=\arg\max_{c_s} J_\text{train}(c_s;s) \quad \text{外部：} s^*=\arg\max_{s\in\mathcal{S}} J_\text{val}(c_s^*) $$ 技能数据库跟踪先前技能、上下文函数和评估指标的历史 $\mathcal{H}_{k-1} = \{(s_i,c_i,J_i^\text{train}, J_i^\text{val})\}_{i=1}^{k-1}$。给定任务 $\tau$，元级代理对先前技能执行智能体交叉 (https://en.wikipedia.org/wiki/Crossover_(evolutionary_algorithm)) 以创建新技能：$s_k=\text{crossover}(\tau,\mathcal{H}_{k-1})$。然后基础级上下文工程师执行技能 $s_k$，并从展开反馈 $\mathcal{R}_k$ 中学习上下文函数，由当前技能引导：$c_k=\text{engineer}(\tau,s_k;c_{k-1}^*,\mathcal{R}_k)$。 元上下文工程（MCE）框架：元级技能进化搜索上下文管理机制，而基础级优化任务上下文。（图片来源：Ye et al. 2026 (https://arxiv.org/abs/2601.21557)） MCE 不像 ACE 那样强制执行上下文结构的启发式规则。它使用**自由形式技能**来存储任务最重要的知识，并迭代地共同进化技能和以技能为条件的上下文。实现上，上下文函数 $c$ 被实例化为专用目录中的文件集合，包括静态（`skill.md`）和动态（上下文和数据展开）组件。元级和基础级优化均在标准工具集的智能体编码环境中执行： $$ \mathcal{T}=\{\texttt{Read},\texttt{Write},\texttt{Edit},\texttt{Bash},\texttt{Glob},\texttt{Grep},\texttt{TodoWrite}\} $$ **元套件**（Lee et al. 2026 (https://arxiv.org/abs/2603.28052)）再深入一层：优化对象是**代码**，它决定并优化哪些信息应存储、检索和呈现给模型。“元”在其名称中意味着它是用于优化套件的套件。 元套件外层循环优化算法。（图片来源：Lee et al. 2026 (https://arxiv.org/abs/2603.28052)） 用于创建新套件的提议者本身就是一个编码代理，最终输出是帕累托前沿上的一组套件候选。 - 整个执行历史可通过文件系统访问，因此编码代理使用 `grep` 或 `cat` 等命令来读取，而不是将所有内容塞入单个提示上下文。 - 提议的套件是文件系统中的一个字典，包含其自身的源代码、分数、展开轨迹和状态更新。 - 元套件循环迭代地创建新套件，仅保留合格的套件。 元套件在（左）少量迭代的文本分类和（右）TerminalBench-2 上的性能。注意 TerminalBench-2 实验中的搜索是从 Terminus-KIRA 和 Terminus-2（两个非常强的套件）初始化的。（图片来源：Lee et al. 2026 (https://arxiv.org/abs/2603.28052)） 尽管如此，重要的教训是明确的：一旦套件设计成为可执行的搜索空间，强大的编码代理就能利用人类工程师所使用的同一设计空间。 ## 工作流设计 套件工程中的工作流设计可由领域专家手工制作。以自动研究为例，已有多种框架被提出并测试。 **AI Scientist** 系统（Lu et al. 2026 (https://www.nature.com/articles/s41586-026-10265-5)）构建了一个流水线：提出研究想法、编写代码、运行实验、分析结果、撰写论文并进行同行评审。 Meng et al. (2026) (https://arxiv.org/abs/2605.26340) 在 **ScientistOne** 中将可验证性作为核心设计约束，每个主张（引用、数值、方法、结论）必须追溯到证据来源，并通过证据链检查进行审计。 AI Scientist 流水线：想法生成、实验、论文写作和评审。（图片来源：Lu et al. 2026 (https://www.nature.com/articles/s41586-026-10265-5)） **Autodata** 代理（Kulikov et al. 2026 (https://arxiv.org/abs/2606.25996)）旨在作为数据科学家生成训练和评估数据。主代理管理一个**挑战者**（提出问题的提议者）、一个**弱求解器**、一个**强求解器**和一个**验证器/裁判**，目标是合成难度“恰到好处”的数据，即强求解器成功但弱求解器失败。在 Autodata 中，挑战者提示根据求解器和验证器的反馈迭代更新。其局限性在于合成任务被用于微调弱求