引言：为什么 Harness 比模型权重更重要？

递归自我改进（Recursive Self-Improvement, RSI）的概念最早可追溯至 I. J. Good 于 1965 年提出的“超智能机器”——一种能在所有智力活动上超越人类、并能自主设计出更优下一代机器的系统。Yudkowsky 在 2008 年将其正式化为一个闭环反馈：AI 利用自身现有智能，迭代优化产生该智能的认知机制。

在现代 AI 体系中，RSI 有两种落地形式：狭义上，模型直接改写自身权重；广义上，模型优化训练流水线与部署系统，从而催生性能更强的后继模型。然而，近期内直接让模型重写权重的路径并不现实，真正的突破口在于模型外部的那层系统——Harness。

Harness（约束系统/控制壳）是包裹基础大模型的完整配套架构，负责编排执行流程、定义模型思考与规划范式、调度工具调用、管控上下文感知、持久化存储产出物，并完成结果评估。Claude Code、Codex、Cursor 等成功产品的经验表明，Harness 层的设计质量往往比模型权重本身更能决定智能体的实际表现。

本文将从 Harness 的设计范式、多层级优化链路、自进化机制、评测方法论以及当前瓶颈五个维度，系统梳理这一正在重构 AI 演进范式的关键技术方向。

---

Harness 的三大设计范式

与早期“Agent = LLM + 记忆 + 工具 + 规划 + 行动”的公式相比，Harness 工程额外包含了工作流设计、评估、权限控制和持久化状态管理。它已不再是简单的提示词模板，而更接近运行时软件系统设计。整体设计应遵循简洁通用原则，并借鉴成熟的软件工程实践——Harness 与操作系统存在强烈类比：封装复杂逻辑，对外暴露简洁接口。

范式一：工作流自动化

定义一个模型可以在其中运行、测试和迭代的标准化流程，是实现自动化的关键。常见的工作流遵循目标导向闭环：规划 → 执行 → 观察/测试 → 改进 → 再次执行，直至目标达成。流程中可主动向用户发起问询以厘清需求。

以 Karpathy 的 autoresearch 项目为例，其核心循环如下：

模型接收任务描述与初始上下文。

模型生成计划（如“搜索相关论文”“编写实验代码”）。

模型调用工具（如 bash、grep、edit）执行计划。

工具返回结果（如报错日志、文件内容）。

模型分析结果，更新上下文，生成下一步计划。

循环直至任务完成或达到最大步数。

关键亮点在于：模型通过“智能体运行时”分析自身的执行轨迹与失败案例，动态迭代方案，而非依赖静态提示词模板。这种设计使得智能体能够从错误中学习，逐步提升任务成功率。

范式二：文件系统作为持久化记忆

长周期智能体系统面临一个核心矛盾：任务执行过程中产生的实验日志、代码补丁、论文摘要、报错记录等产出物，数据体量往往远超模型上下文窗口上限。Harness 不应将所有信息塞入上下文，而应将持久化状态存储在文件系统中。

读写、编辑文件系统（通常通过 bash 命令）是 LLM 的基础能力。因此，以文件形式管理持久记忆，能够自然受益于核心模型能力的提升。具体实现中，Harness 可维护一个工作目录，包含：

experiments/：存放每次实验的配置、日志与结果。

code/：存放待修改的源代码与补丁。

memory/：存放从历史轨迹中提炼的经验笔记。

state.json：记录当前任务进度与上下文摘要。

当模型需要回顾历史信息时，通过 cat、grep 等命令按需读取，而非将全部历史塞入提示词。这种方式既突破了上下文窗口限制，又使得模型能够对自身执行历史进行推理。

范式三：子智能体与后台异步任务

一套 Harness 可派生多个子智能体并行执行任务，并监控后台进程。当主智能体需要同时验证多组假设、批量运行实验，或拆分独立子任务（避免污染主上下文）时，该设计价值尤为突出。

父智能体需要一个小型进程管理器，负责：

创建子任务，分配独立的工作目录与上下文。

巡检子任务运行日志，监控进度与异常。

终止超时或失败的任务。

汇总子智能体输出至主线程。

核心设计准则：并行流程必须可观测、可追溯。子智能体的输出应落地为文件、日志、状态快照，而非仅存于临时对话上下文。这样模型可在中断后恢复进度，并回溯完整执行历史做推理分析。

案例：编程 Agent 的 Harness 设计

主流编程 Agent（Claude Code、Codex、OpenCode、Cursor）的核心接口已趋于稳定，通常使用以下循环：

步骤动作工具示例

1读取代码仓库结构ls, find, glob 2搜索相关代码grep, rg 3读取文件内容cat, head, tail 4编辑文件edit, sed, patch 5运行测试bash, python 6检查错误grep 日志, diff 7重复直到测试通过—

这套工具集使得编程 Agent 能够在完整代码库内完成开发、调试全流程，功能对标人类开发者使用的 IDE。

---

Harness 的多层级优化链路

Harness 系统的优化对象存在清晰的演进路径：指令提示词 → 结构化上下文 → 工作流 → Harness 代码 → 优化器代码。随着模型能力增强，优化目标逐步复杂化，通用自动化方案成为主流。

上下文工程：从 ACE 到 MCE 到 Meta-Harness

#### ACE：智能体上下文工程

传统做法将所有工具返回结果与模型生成文本简单拼接进上下文，随着任务规模扩张，上下文极易冗余失控。ACE（Agentic Context Engineering, Zhang et al., 2025）将上下文视为一本不断演化的“操作手册”，而非持续增长的提示词。它由三个组件协同维护：

生成器（Generator）：参考历史上下文条目，生成任务执行轨迹。

反思器（Reflector）：从成功与失败轨迹中提炼可复用经验。

策展器（Curator）：增量式更新结构化上下文，输出带唯一标识与描述的结构化条目，通过确定性逻辑合并至上下文日志，并定期精简去重。

ACE 实现了从历史轨迹中自主提炼经验，但更新规则与整体工作流仍为人工定义，距离完全自迭代存在差距。

#### MCE：元上下文工程

MCE（Meta Context Engineering, Ye et al., 2026）将上下文管理机制与上下文内容解耦，搭建双层优化架构：

底层：针对单任务优化上下文内容。

元层：演化上下文管理技能，完成元优化。

一个 MCE 技能定义了一个上下文函数，输入包含静态组件（提示词、知识库、代码库）与动态算子（检索、筛选、过滤、格式化）。双层优化逻辑为：内层在给定技能下求解最优上下文配置，外层在验证集上迭代搜索最优技能方案。技能数据库记录历史技能与评估指标，元智能体自主交叉融合历史技能，生成适配当前任务的新技能。

MCE 不强制固定上下文结构，依靠自由形式技能存储任务核心知识，同步迭代技能与对应上下文。

#### Meta-Harness

Meta-Harness（Lee et al., 2026）将优化层级再向上提升一层：优化对象为管控信息存储、检索、向模型展示逻辑的底层代码。“Meta”代表这是一套用于优化其他 Harness 的元框架。

外层算法采用迭代搜索循环：

输入任务集、基础模型、提案智能体、迭代轮次。

初始化多套 Harness 候选集，存储于文件系统（包含源代码、评分、执行轨迹）。

提案编码智能体读取历史方案，生成全新 Harness 代码。

通过接口校验后，在任务集上执行并评估性能。

保留帕累托最优方案，加入候选集。

重复直到达到迭代轮次。

关键设计：全量执行历史存放于文件系统，智能体通过 grep、cat 等命令按需读取，而非全部塞入单个提示词上下文。这使得搜索空间足够大，足够强的编码智能体可利用人类工程师相同的设计空间。

工作流设计：从手工到自动搜索

工作流设计可由领域专家手工搭建，但更通用的方法是将其视为搜索问题。Automated Design of Agentic Systems（ADAS）将 agent 设计本身变成优化问题，靠元 agent 搜索运作：

用简单 agent（如 CoT、self-refine）初始化工作流档案库。

元 agent 参照档案库已有方案，生成新工作流的高层描述，再用代码实现。

经过自我修正检查新颖性。

评估每个新候选，将成功的加回档案库。

AFlow 则进一步将工作流表示为有向无环图（DAG），通过蒙特卡洛树搜索迭代优化节点与边结构。

自进化 Harness：Self-Harness 与联合优化

Self-Harness 让 Harness 系统具备自我改进能力，典型流程为：

缺陷挖掘：在任务执行中识别失败模式或效率瓶颈。

约束方案提案：智能体分析缺陷，生成修改 Harness 代码的提案（如调整提示词结构、增加新工具、修改评估逻辑）。

回归校验更新：在保留任务集上验证提案，确保不引入退化，通过后合并更新。

更激进的方案是同时优化 Harness 代码与模型权重。SIA（Self-Improving Agent）首次同步优化约束代码与模型 LoRA 权重，但该方向仍处于早期，存在奖励作弊与安全边界模糊等风险。

进化搜索：DGM 与 AlphaEvolve

进化搜索类方法将 Harness 设计视为程序搜索问题。Darwin Gödel Machine（DGM）使用遗传编程演化 agent 工作流，AlphaEvolve 则结合强化学习搜索最优工具使用策略。这类方法适合指标客观可量化的任务（如 GPU 内核开发、算法优化、代码生成），但计算成本高，评估模糊、依赖人工判断的领域效果差，且易出现种群同质化、多样性崩塌。

---

自进化 Agent 的评测：SEAGym

自进化 Agent 的评测不能沿用传统静态 benchmark。传统方法给定固定 Agent，在一组独立任务上运行后报告最终成功率，无法回答以下关键问题：

一次更新到底改进了什么？

提升是否能迁移到未见任务？

是否只是过拟合近期反馈？

是否遗忘了旧能力？

是否引入了更高成本或运行时不稳定？

针对这一空白，清华大学团队提出了 SEAGym（Self-Evolving Agent Gym），一个专门用于评测自进化 Agent 的环境。

核心设计

SEAGym 将自进化过程形式化为与强化学习训练过程对齐的评测流程。每个 Agent snapshot 表示为 (M, H)，其中 M 是固定基础模型，H 是可更新的 Harness 状态（包括 prompts、memories、skills、tools、middleware、runtime configuration 等）。在每一步中，环境采样一批训练任务，Agent 执行后根据自身更新规则修改 H。

SEAGym 不规定具体更新算法，不同自进化方法只需通过统一的 rollout/update 接口接入。这使得可以在同一协议下比较 ACE、TF-GRPO、AHE 等方法。

多视角评测

SEAGym 将评测视角拆分为多个维度：

视角说明

Train batch提供更新所需的轨迹与反馈 Update-validation冻结中间 snapshot，观察阶段性提升 ID transfer同分布但未见过的任务 OOD transfer分布外任务 Replay回放旧任务，检查遗忘或回归 Cost records记录 token、工具调用、运行时间、更新成本

这使得研究者可以看到自进化过程中的细粒度动态。例如，一个 snapshot 可能在 validation 上提升，但在 OOD 上下降；中间版本可能短暂变强，之后因错误的 middleware 修改而崩溃。

关键实验发现

发现一：Validation 提升不等于稳定泛化。 实验中，TF-GRPO 在 validation 上提升 17.1 个百分点，但 OOD 下降 2.5 个百分点。AHE 则在三个视角均取得提升（validation +17.1, ID +9.1, OOD +6.3）。只看 validation 曲线容易高估真实泛化能力。

发现二：自进化可能引入中间崩溃。 AHE 的 train replay 实验中，初始 Agent 可解决 34/80 个任务，最终可解决 43/80，但中间第 4 个 epoch 后一度跌至 6/80。分析发现是 Harness 修改了 middleware/runtime contract，导致 message construction 系统性错误。后续更新修复了该路径。如果只报告初始与最终分数，这种过程风险完全不可见。

发现三：Batch size 影响稳定性，且不是越大越好。 Batch 20 在 evidence diversity、per-task analysis depth、update frequency 与 harness stability 之间取得较平衡的结果。Batch 太小（10）导致更新证据不足、频率过高；Batch 太大（80）稀释每个任务的注意力，诱发粗糙修改。

发现四：训练来源多样性影响恢复能力。 Mixed-source（Terminal-Bench + HLE）比 HLE-only 更稳定。HLE-only run 的最终 snapshot 出现 collapse（三个视角均降到 0），但 best intermediate snapshot 仍有提升。单一 benchmark 可能将 Harness 推向局部最优，多样信号有助于从坏状态恢复。

---

当前瓶颈与未来方向

尽管 Harness 工程已取得显著进展，迈向完全递归自我改进仍存在七大核心瓶颈：

评估量化困难：许多任务（如创意写作、战略规划）难以定义客观、可复现的评估指标，导致优化目标模糊。

长期记忆管理不足：文件系统作为持久化记忆虽简单有效，但缺乏结构化索引与高效检索机制，随着历史积累，信息检索成本线性增长。

负面结果利用率低：模型倾向于忽略失败轨迹中的信息，未能系统性地从错误中学习。

种群多样性崩塌：进化搜索类方法容易收敛到同质化方案，丢失探索多样性。

奖励作弊：Agent 可能拟合评估指标而非真正改进能力，例如修改测试逻辑使测试通过，而非修复根本问题。

短期优化陷阱：优化仅聚焦单次任务收益，忽略长期能力积累与系统稳定性。

人类监督定位模糊：缺少清晰、可扩展的人机监督协同机制，完全自主迭代存在失控风险。

未来方向包括：发展更通用的评估框架（如 SEAGym 的扩展）、将 Harness 优化与模型权重联合训练、引入安全约束层防止恶意修改、以及设计可解释的更新日志与回溯机制。

---

总结

Harness 工程正在成为 AI 自我改进的核心战场。从工作流自动化到上下文工程，从进化搜索到自进化循环，这一方向揭示了智能体的能力提升不再只来自模型参数更新，也越来越来自模型外部系统的演化。对于开发者而言，理解并掌握 Harness 设计范式，将是在模型能力趋同的时代构建差异化竞争力的关键。

想深入了解 Agent 工作流设计，可参考 AI Agent 与多智能体；若关注 Harness 与模型联合优化，可阅读 模型微调；评测相关可参考 评估与基准。

---

FAQ

Q1: Harness 工程与传统 Agent 框架（如 LangChain）有何区别？ 传统 Agent 框架主要提供工具调用与链式编排的抽象，而 Harness 工程更进一步，将工作流设计、持久化状态管理、评估、权限控制等视为一等公民，并强调系统本身的自我改进能力。Harness 更像一个运行时操作系统，而不仅是编排库。

Q2: 自进化 Harness 是否会导致智能体行为失控？ 存在失控风险，尤其在 Self-Harness 开放底层系统编辑权限时。Agent 可能修改评估逻辑导致奖励作弊，或破坏 middleware contract 引发系统崩溃。当前最佳实践包括：使用沙箱环境隔离更新、保留完整更新日志与回溯能力、设置人工审批环节。

Q3: SEAGym 评测框架是否适用于生产环境？ SEAGym 目前主要面向研究场景，用于诊断自进化过程中的泛化、遗忘与稳定性问题。生产环境可借鉴其多视角评测思路，但需适配具体业务指标与成本约束。

Q4: 小团队如何开始实践 Harness 工程？ 建议从简单的文件系统持久化记忆与工作流自动化入手，例如使用开源项目 autoresearch 作为起点，逐步引入子智能体并行与上下文工程。无需一开始就追求全自动自进化，可先手工设计 Harness，再逐步自动化。

Q5: Harness 优化会替代模型微调吗？ 不会替代，但会互补。Harness 优化主要改进模型与外部世界的交互方式，而微调改进模型内在能力。两者结合（如 SIA 方案）可能产生协同效应，但当前联合优化仍处早期，存在稳定性与安全性挑战。

Q6: 如何避免自进化过程中的奖励作弊？ 可采取以下措施：使用多个独立评估函数交叉验证；保留原始任务作为回放集；限制 Harness 修改评估逻辑的权限；引入人类随机抽查；记录每次更新前后在固定基准上的表现差异。

Q7: Harness 工程需要掌握哪些编程技能？ 需要熟悉 Python、bash 脚本、文件系统操作、基本的软件工程实践（版本控制、模块化设计）。若涉及进化搜索，还需了解遗传算法或强化学习基础。无需深入模型训练细节。