递归自我改进：从一杯咖啡到Harness Engineering

2024年，我去美国做访问研究，回程途经旧金山。去之前通过邮件约了几位行业朋友（网友，行业专家，AI公司员工），其中包括素未谋面的Lilian Weng。那时候她还在OpenAI负责安全系统，AI圈还没有后来那些人事震荡。

我乘地铁去了OpenAI当时的那栋小白楼。他们楼下有一家星巴克，我在那儿等她。下午两点，店里不少人带着电脑，三三两两在聊天。硅谷的星巴克就是这样，你分不清谁是来办公的、谁是来面试的、谁是刚从哪个会出来透口气的——但空气里确实有一种说不上来的东西，让人觉得这栋楼里正在发生什么。

那天我们聊的是很宽泛的话题——中美AI的差距和机会、算力成本下降的拐点、token价格降到什么程度会触发应用爆发。我当时也和他分享了在MIT上课时的一些分享：大模型的力量不在于参数规模，而在于电力和算力趋于平静之后，token成本降到极低基点时，整个行业的范式会发生变化。我们都没料到，后来DeepSeek横空出世，中国的开源路线以一种意想不到的方式验证了这个判断。

这些是后话了。真正让我想写这篇文章的，是今年7月4日Weng发表的那篇《Harness Engineering for Self-Improvement》，以及随后她官宣重返OpenAI领导递归自我改进（RSI）团队的消息。RSI不是新概念——1965年I. J. Good就提过了，几十年来更多是哲学讨论。Weng的贡献不在于"发现"RSI，而在于她给出了一条工程化的路径。她指出RSI可以发生在三个层面：模型权重、训练管道、部署系统。其中DeepSeek R1已经在训练管道层证明了自我改进的可行性——模型不需要人类标注，通过强化学习自己学会推理。而Weng选择的切入点是第三层：部署系统（Harness）——即使模型本身的推理能力不变，更好的工具调用、上下文管理、评估机制也能显著提升实际表现，而这些改进本身又可以被模型自动化。更值得追问的是：OpenAI为什么选一个做了七年安全的人来领导RSI？这篇文章，我想从技术的角度拆解。

一、RSI：一个60年的概念，为什么现在才可行

Lilian Weng的文章开篇直接切入主题：递归自我改进（Recursive Self-Improvement, RSI）。

这个概念可以追溯到1965年，英国数学家I. J. Good提出的"超智能机器"——一种能在所有智力活动中超越人类，并设计出比自身更好的机器的系统。2008年，Eliezer Yudkowsky将这个概念精确化为一个反馈循环：AI利用其当前的智能，去改进产生其智能的认知机制。

听起来很抽象。但Lilian Weng把这个抽象概念落到了实处。她指出，在现代AI语境下，这个反馈循环可以发生在三个层面：

  1. 模型权重层面：模型直接重写自己的参数。这是最理想但最难的路径，目前几乎不可行。
  2. 训练管道层面：模型改进生成训练数据、选择训练任务、优化训练策略。这是很多前沿实验室正在探索的方向。
  3. 部署系统层面：模型改进自己与外界交互的方式——如何调用工具、如何管理上下文、如何评估自身输出。

她明确选择了第三个切入点。原因很关键：原始模型和真实世界之间的这层，其重要性不亚于模型本身的原始智能。Claude Code和Codex的成功，不是因为它们的基础模型最强，而是因为它们的部署系统设计最成熟。

她用了一个词来描述这层部署系统：Harness。

二、Harness：模型与世界之间的操作系统

Weng在博客中用了一个精确的类比：Harness就像操作系统。你花在操作系统上的功夫，决定了CPU能发挥多大潜力。

在她的定义中，Harness是围绕在基础模型周围的整个系统，它负责：

  • 编排执行流程（模型如何思考和规划）
  • 定义工具调用（模型如何与外界交互）
  • 管理上下文（模型感知和存储什么信息）
  • 持久化产物（模型如何保存工作成果）
  • 评估结果（如何判断模型表现好坏）

这个定义的精妙之处在于，它将原本分散的概念——Prompt Engineering、Agent Framework、Tool Use、Memory Management、Evaluation——统一到了一个更宏观的架构视角下。

更重要的是，她指出了Harness工程与传统Agent框架的区别：

维度 传统Agent框架 Harness工程
核心公式 agent = LLM + memory + tools + planning + action 额外加入workflow design, evaluation, permission control, persistent state
设计理念 Prompt模板 运行时系统设计
类比 IDE 操作系统

这个类比不是随便说的。Lilian Weng明确指出，Harness的设计应该参考操作系统的工程实践：

  • 封装复杂性：将复杂逻辑封装在Harness内部，对外暴露简单接口
  • 标准化协议：配置、工具接口等协议将逐渐成为行业标准
  • 持续进化：Harness可以独立于底层模型迭代优化

这意味着，AI工程的重心正在从"打造更大的模型"转向"设计更好的Harness"。这是一个范式级的转变。

三、Harness设计模式：从产品中提炼的工程实践

Lilian Weng的文章最有价值的部分之一，是她从Claude Code、Codex、Cursor等成功产品中提炼出的三种核心设计模式。这些不是空洞的理论，而是经过产品验证的工程实践。

模式一：工作流自动化

定义模型可以在其中运行、测试和迭代的工作流，是自动化的关键设计。Karpathy的autoresearch仓库提供了清晰的示例。通用工作流遵循一个目标导向的循环：

计划(Plan) → 执行(Execute) → 观察/测试(Observe/Test) → 改进(Improve) → 重新执行

这个循环持续运行，直到目标达成。关键设计点：

  • 动态性：工作流不是固定脚本，而是根据模型观察结果动态调整
  • 自主性：模型可以主动向用户请求澄清
  • 反思性：模型分析自身的执行轨迹和失败案例，从中学习

这已经不是传统的"Prompt Engineering"了，而是运行时系统设计。

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

这是一个极其简洁但深远的设计决策。

在长时间运行的Agent系统中，模型产生的产物——实验日志、代码差异、论文摘要、错误追踪、历史执行轨迹——会迅速超出上下文窗口的限制。Lilian Weng的解决方案不是扩大上下文窗口，而是将持久化状态存储在文件系统中。

这个设计的美妙之处在于：

  1. LLM天生具备文件操作能力：读写文件是基础技能，随着模型能力提升而自然增强
  2. 可中断性：系统可以在任何时刻中断并恢复，因为状态存储在外部
  3. 可追溯性：完整的执行历史可以被回溯和分析，这是自我改进的基础

她在这里做了一个关键判断：简单的文件管理形式，因为LLM的基础能力提升而自然受益。这意味着，Harness的设计不应该追求花哨的抽象层，而应该利用LLM已经具备的能力。

模式三：子代理与后台任务

单个Agent的上下文是有限的。当需要同时搜索多个假设、并行运行多个实验、或将隔离的子任务分配出去时，Harness需要具备生成和管理子代理的能力。

父代理需要一个轻量级的进程管理器：启动任务、检查日志、取消失败的运行、将结果合并回主代理线程。

核心设计选择是让并行显式化和可检查。如果子代理的输出只存在于短暂的对话上下文中，它们很快就会变得过时且难以追踪。如果存储为文件、日志和状态记录，模型就可以在中断后恢复工作，并基于自身的执行历史进行推理。

案例研究：编码Agent Harness的稳定接口

Lilian Weng详细列举了当前编码Agent的工具集，这是我见过最完整的Harness接口定义：

工具组 具体定义
文件系统 文件发现：glob, grep, ls；文件读取：read, read_many；文件修改：write, edit, multi_edit, apply_patch
Shell执行 bash, PowerShell
IO lsp, git_status, git_diff, git_commit
外部上下文 MCP工具, Skills
Web搜索 web_search, web_fetch, browser tools
产物 读取文档/图像；生成HTML/图像
后台进程 CronCreate, CronDelete, CronList
代理委托 spawn_agent, resume_agent, wait_agent, list_agents, close_agent, interrupt_agent

这套工具集不是某个产品的私有接口，而是Claude Code、Codex、OpenCode、Cursor等主流编码Agent的共识。它代表了Harness设计的"行业标准接口"正在形成。

四、Harness优化：从启发式规则到元学习

如果说设计模式回答了"Harness应该怎么构建"，那么优化路径回答了"Harness应该怎么改进"。这是Lilian Weng文章中最具前瞻性的部分。

她首先指出了优化对象的演进过程：

指令Prompt → 结构化Context → 工作流 → Harness代码 → 优化器代码

随着模型变得更智能，优化的目标变得更复杂，方法变得更通用。

第一阶段：Agentic Context Engineering (ACE)

ACE将上下文视为一个持续演化的"剧本"（Playbook），而不是不断增长的Prompt。它包含三个组件：

  • 生成器（Generator）：参考剧本条目生成任务轨迹
  • 反思器（Reflector）：从成功和失败的轨迹中提炼洞察
  • 策展器（Curator）：以增量、条目的形式更新结构化上下文

关键设计：为防止上下文在迭代重写过程中崩溃，策展器不重写整个Prompt，而是输出结构化的条目集合（identifier, description），通过确定性逻辑合并到结构化上下文日志中。

但ACE的更新规则和整体工作流仍是手工设计的。这限制了它的泛化能力。

第二阶段：Meta Context Engineering (MCE)

MCE进一步将机制（如何管理上下文）与产物内容（上下文中有什么）分离，在元优化层面运行技能进化，在基础层面运行上下文优化。这是一个双层优化问题：

Inner:  cs* = argmax_cs J_train(cs; s)      // 给定技能s，在训练数据上找到最优上下文
Outer:  s* = argmax_s∈S J_val(cs*)          // 在验证集上找到表现最优的技能

其中：

  • s ∈ S 是一个"技能"，定义为上下文函数 cs = (ρs, Fs)
  • ρs = {ρ1, ..., ρm} 是静态组件（Prompt、知识库、代码库）
  • Fs = {F1, ..., Fk} 是动态操作符（搜索、选择、过滤、格式化）
  • J_train 和 J_val 分别是训练集和验证集上的性能指标

这个双层优化的精妙之处在于：

  1. 内层优化在固定技能的约束下，找到当前任务的最优上下文
  2. 外层优化搜索技能空间，找到跨任务泛化能力最强的技能

技能数据库追踪历史：H_{k-1} = {(s_i, c_i, J^train_i, J^val_i)}_{i=1}^{k-1}。元级Agent对历史技能执行交叉操作生成新技能：s_k = crossover(τ, H_{k-1})。基础级上下文工程师从执行反馈中学习：c_k = engineer(τ, s_k; c^*_{k-1}, R_k)。

MCE不强制规定上下文结构的启发式规则，而是使用"自由形式的技能"存储任务的最重要知识，并迭代地共同进化技能和技能条件化的上下文。

第三阶段：Meta-Harness

Meta-Harness再深入一层：优化的对象是决定和优化什么信息应该被存储、检索和呈现给模型的代码。“Meta"的含义是：这是一个优化Harness的Harness。

核心机制：

  • 创建新Harness的提议者本身就是一个编码Agent
  • 整个执行历史可通过文件系统访问，编码Agent使用grep或cat等命令读取
  • 提议的Harness是文件系统中的字典，包含其自身的源代码、分数、执行轨迹和状态更新
  • Meta-Harness循环迭代地创建新Harness，仅保留合格的

最终输出是Pareto前沿上的Harness候选集合。

Lilian Weng在这里指出了一个关键转折点：一旦Harness设计成为可执行的搜索空间，强大的编码Agent就能利用人类工程师使用的相同设计空间。

自我改进Harness与进化搜索

将这些优化推向前沿，就是让Harness本身成为被优化的对象。这涉及一个关键的转变：

  • 搜索过程由编码Agent执行，能够探索人类工程师难以涉及的设计空间
  • 通过进化算法（交叉、变异）在代码层面生成新的Harness候选
  • 通过评估指标筛选出性能最优的设计

这构成了真正的递归改进循环：

模型能力提升 → 更好的Harness设计能力 → 更好的Harness → 更好的训练/部署环境 → 更优的下一代模型

与模型权重的联合优化

Harness优化的最终方向是与模型权重的联合优化。完整的RSI需要在两个层面上同时优化：

  1. Harness层面：优化工作流、上下文管理、工具选择
  2. 模型层面：通过合成数据、自我博弈、测试时训练等方式改进模型能力

这两个层面的优化需要协同进行，形成真正的联合优化过程。

五、Lilian Weng的核心洞察

文章中最值得关注的部分，是Weng对RSI近期路径的预测。她的核心洞察可以总结为：

近期路径：Harness工程的元方法论

改进获取更好答案的机制 ≠ 改进答案本身
  1. Harness工程将向元方法论方向演进——Harness系统本身成为优化目标，减少启发式规则，增加通用机制
  2. 成熟的Harness实现自动研究，用于模型自我改进循环；更智能的模型防止Harness过度工程化

中期展望：内化与外部接口的平衡

最终，许多Harness改进可能被内化到核心模型行为中。这在Prompt Engineering的发展历史中已经发生过类似的模式：

  • 手动的Prompt技巧随着指令调整和模型推理能力的提升变得不那么重要
  • 但指定目标、约束、上下文和评估的需求从未消失

关键洞察：即使Harness的改进内化了，模型与外部上下文和工具的接口应该保留。这是系统开放性的保证。

核心观点

Lilian Weng的文章核心观点，我认为可以浓缩为一句话：

Harness是模型与世界之间的操作系统。正如操作系统的改进能释放CPU的潜力，Harness工程的改进能释放模型的潜力。而RSI的关键，在于让这个操作系统本身也能够自我改进。

六、未来挑战

Lilian Weng没有回避这个方向面临的困难。她指出了四个核心挑战：

评估与验证

当Harness和模型都在持续进化时，如何确保每一步改进都是真实的？这需要可靠的评估基准，能够区分真正的能力提升和指标操纵；需要跨任务的泛化测试，防止Harness针对特定基准过度拟合；需要人类可解释的评估维度，确保改进方向符合实际需求。

稳定性与安全性

递归改进循环可能带来不稳定。关键问题包括：改进的收敛性（系统是否会进入无限改进循环）、能力退化的风险（某些能力提升是否会损害其他能力）、对齐的保持（自我改进过程中是否保持与人类价值观对齐）。

计算成本

Meta-Harness和进化搜索需要大量计算资源。每一代Harness的生成、评估和筛选都需要运行大量Agent轨迹。这带来了一个根本性的权衡：系统改进速度与计算成本之间的平衡。

人类在循环中的角色

随着Harness变得越来越自我改进，一个核心问题是人类在系统中的角色：人类应该在哪些环节保留决策权？如何确保人类能够理解和干预自我改进过程？如何在自动化效率和人类监督之间找到平衡？

七、我的判断

写到这里，我想谈谈自己的预测。

Harness的迭代速度会远超多数人的预期。 Claude Code、Codex、Cursor这些产品的Harness设计，看似已经成熟，但它们仍处于第一代。我预测在接下来的6个月内——甚至3个月——就会迎来一次显著的架构迭代。工具接口会从硬编码转向协议驱动，上下文管理会从固定窗口转向文件系统持久化，评估机制会从事后检查转向实时反馈。这不是线性改进，而是指数加速：每一代Harness都会让构建下一代Harness的效率更高。

这也正是RSI成为窗口期的原因。 当Harness的迭代速度超过人类工程师手动优化的极限时，让模型参与Harness的设计和优化就不再是可选项，而是必然选择。Weng从安全转向RSI，不是追热点，而是看到了这个拐点：Harness工程正在从手工 craft 转向自动化 engineering，而安全背景让她比任何人都清楚——自动化的边界在哪里，人类应该在哪些环节握住方向盘。

DeepSeek已经验证了RSI的另一半。 梁文锋说模型需要自己进化，R1用强化学习证明了这一点：模型不需要人类标注，通过自我博弈就能学会推理。这是RSI在训练管道层的突破。而Weng的Harness Engineering是RSI在部署系统层的突破——两层合在一起，才是完整的递归自我改进：模型变得更聪明（训练管道层），同时更会使用工具和管理上下文（系统层），两者相互促进。中国开源社区在训练管道层已经跑到前面，系统层的工程机会同样值得关注。

算力成本的下降正在打开RSI的工程空间。 2024年那杯咖啡里聊到的token成本下降，现在已经发生——而且比预期更快。当运行一次Agent轨迹的成本从美元降到美分，Meta-Harness的进化搜索就不再是理论实验，而是工程可行方案。算力便宜到可以"浪费"在自动搜索最优Harness设计上时，RSI的飞轮才能真正转起来。这个拐点，我认为在2027年之前就会到来。

对中国AI行业而言，这是一个真实的窗口。 Harness Engineering的工程门槛低于模型预训练，Claude Code和Codex的工具集已经是公开的共识接口。国内团队有机会在这一层快速跟进。但关键在于：不要只做UI封装，要做运行时系统。MCP协议的普及正在降低接口层门槛，谁先建起完整的Harness工程能力——工作流自动化、文件系统持久化、子代理管理——谁就能在下一轮Agent竞赛中占住位置。DeepSeek证明了中国的模型能力不输国际，Harness工程是下一个需要证明自己的战场。

八、回到那栋小白楼

OpenAI楼下那家星巴克，我待了一个下午。那天聊的是算力成本、token价格、中美AI的差距——都是2024年那个时间点最迫切的问题。

当时我们都觉得，故事的下一章是更大的模型、更便宜的算力。谁也没想到，后来的DeepSeek用一种完全不在预期内的方式改写了叙事——不是靠更大的模型，而是靠更聪明的训练方法，让模型自己学会推理。那杯咖啡里聊到的MIT教授的判断——token成本降到极低基点时行业范式会变——被DeepSeek和开源社区以比任何人预期都快的方式验证了。

算力平静了，token便宜了，模型也学会自己进化了。那么下一个问题自然浮现：当模型足够聪明、算力足够便宜，谁来构建让模型持续变好的工程体系？

这就是Weng在7月4日那篇博客里给出的答案——Harness Engineering。而OpenAI让她重返公司领导RSI团队，说明他们认同这个判断：DeepSeek已经在训练管道层证明了自我改进可行，RSI的下一个突破口在部署系统层——让模型更好地使用工具、管理上下文、评估自身输出，并把这个改进过程本身也自动化。

Weng从安全VP到Thinking Machines联创，再到重返OpenAI领导RSI——这条路径从外面看是跳槽和反转，从技术脉络看却是一条清晰的收敛线：从"如何让模型安全"到"如何让模型在部署中持续改进”，再到"如何让改进过程本身也自动化"。

那天咖啡里聊到的事情，有些已经发生，有些正在发生。我只是有幸在它们还没被命名之前，就坐在了旁边。

- FIN -