翁荔再发万字长文：AI自进化，从Harness开始

前 OpenAI 安全研究副总裁、Thinking Machines Lab 联合创始人翁荔（Lilian Weng）又发长文了。这一次，继此前对 Scaling Law 发出谨慎信号之后，她把目光投向了一个正在快速升温的方向——Harness Engineering。

在这篇最新的博客中，她提出了一个很有意思的判断：AI 的自我提升，未必会先从“模型自己改写自己的权重”这一步开始。更现实、更可能在近期取得突破的路径，其实是先优化模型外部的 Harness 层——也就是那些围绕模型构建的工作流、上下文管理、工具调用和评估机制。等到这些能力足够成熟，真正的自动化研究和更强模型的出现才会水到渠成。

当然，这条路上也不是一片坦途。评估器模糊、上下文记忆退化、奖励黑客、负结果难以留存，以及人类监督如何有效嵌入等问题，仍然需要直面。

整篇文章围绕 Harness 的设计模式、优化方法以及未来挑战展开，信息量不小。下面就直接进入正题。

何为 Harness Engineering？

先补一个背景。递归式自我提升（RSI）这个概念，最早可以追溯到 1965 年 I. J. Good 的设想——他定义了一台“超智能机器”，能够在所有智力活动上超越人类，并且有能力设计出更好的机器来持续改进自身。到了 2008 年，Yudkowsky 用“recursive self-improvement”这个说法，描述了一种具体的反馈回路：AI 利用自己当前的智能，去改进产生这种智能的认知机器本身。

在现代 AI 语境里，这个反馈回路既包括模型直接改写自己的权重，也包括一种更宽泛的路径——模型改进它的训练流水线和部署系统，而系统层面的改进，又能让下一代模型在经济价值更高的任务上表现更出色。事实上，前沿实验室（比如 Anthropic、OpenAI）已经证明，这样的循环可以显著加快 AI 研发的速度。

这里需要特别点出一个关键：部署系统。在原始模型（即预训练完成、刚刚通过评测时表现出的能力）与它所面对的真实世界上下文之间，还有一层至关重要的系统。这一层，也就是 Harness，其重要性丝毫不亚于模型本身的智能。Claude Code、Codex 这些成功的编程 Agent 产品，已经用实际表现证明了 Harness 的价值。所谓 Harness，就是围绕基础模型构建的一整套系统：它负责编排执行，决定模型怎么思考、怎么规划、怎么调用工具、怎么行动、怎么管理上下文、怎么存储产物，以及如何评估结果。

Harness 的设计模式

模式一：工作流自动化

这是最直观的一种模式。把模型放在一个固定的工作流里，让它像流水线上的工人一样，按步骤完成任务。常见的做法包括：先让模型生成一个计划，再逐步执行；或者让模型在多个步骤间反复迭代，不断优化输出。这种模式的好处是稳定可控，特别适合那些流程明确、步骤可拆解的任务。

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

模型自身有上下文窗口的限制，但很多任务需要跨越较长时间或多次交互才能完成。解决方案之一，就是把文件系统当作模型的“外置大脑”。模型可以在文件里记录中间结果、保存关键信息、甚至维护一个持续更新的“笔记”。这样，即使上下文窗口满了，关键信息也不会丢失。

模式三：子 Agent 和后台任务

当任务变得复杂，一个模型可能忙不过来。这时候可以像团队协作一样，把任务拆解，分配给多个子 Agent。每个子 Agent 负责一个子任务，在后激进分子立运行。主 Agent 则负责调度、协调、汇总。这种模式有点像项目经理带着几个工程师干活，效率往往比一个人单打独斗高得多。

案例研究：编码 Agent 工具

编程 Agent 是 Harness 设计的一个典型应用。比如一个编码 Agent，它需要理解用户需求，搜索相关知识库，生成代码，运行测试，根据错误反馈修改代码，如此循环。这个过程背后，就是一个精心设计的 Harness 在运转：它管理着上下文（用户需求、历史对话）、工具调用（搜索、运行代码、读写文件）、工作流（计划-生成-测试-修改），以及结果评估（测试是否通过、代码是否符合规范）。

Harness 层与核心智能

一个值得思考的问题是：Harness 层的能力，到底应该算作模型智能的一部分，还是独立于模型之外？从实践来看，两者界限其实越来越模糊。好的 Harness 设计，能让一个能力一般的模型表现出远超其自身水平的性能。反过来，再强的模型，如果放在糟糕的 Harness 里，也会干出各种低级错误。

Harness 优化

设计好 Harness 只是第一步，更关键的是怎么持续优化它。

上下文工程

上下文窗口是 Harness 的心脏。怎么塞信息、塞多少、塞什么顺序、什么时候清空，都直接影响模型的表现。一些成熟的实践包括：优先级机制，把最关键的信息放在最前面；摘要机制，当上下文快满时，自动对历史信息进行压缩；分层管理，把长期记忆（比如项目背景）和短期记忆（当前步骤的细节）分开存储。

工作流设计

工作流不是一成不变的，好的工作流本身就应该具备自适应性。比如，在简单任务上，走最短路径快速完成；在复杂任务上，自动切换到更谨慎、多步骤的流程。甚至可以让模型自己根据任务难度，动态调整工作流策略。

自我改进 Harness

这算是 Harness 优化的一个进阶方向：让 Harness 系统本身也能从经验中学习。比如，记录每次任务中哪些步骤拖了后腿、哪些策略效果最好，然后用这些数据来改进 Harness 的配置和策略。这听起来有点循环递归的味道，但确实是一个可行的方向。

进化式搜索

Harness 中有很多超参数（比如上下文长度截断策略、工具调用频率、子 Agent 数量），这些参数的组合空间很大。进化式搜索可以把 Harness 配置当作一个基因组，然后通过变异、交叉、选择，自动找到最优配置。这比手动调参高效得多。

基于模型权重的联合优化

更激进的做法是，把 Harness 的优化和模型本身（权重）的优化联合起来。比如，通过强化学习，同时调整模型生成策略和 Harness 的工作流参数，让两者互相适应。这可能是通往更强系统的路径，但也意味着优化空间和难度都成倍增加。

未来挑战

方向看起来很美，但现实骨感。翁荔在文中也坦诚列出了几个关键难题。

首先是评估器模糊。很多任务的评价标准并不清晰，比如“创意写作”好不好，很难用一个自动评估器说清楚。如果评估器本身就不靠谱，那 Harness 的优化就会走偏。

其次是上下文记忆退化。模型在处理长序列时，早期信息很容易被遗忘或扭曲。尽管有各种机制来缓解，但远未到完全解决的程度。

奖励黑客也是一个大问题。任何基于奖励信号的系统，都逃不过模型想办法钻空子。Harness 越复杂，可能给模型留下的“漏洞”就越多。

负结果难以保留同样棘手。在很多任务中，失败的尝试其实非常有价值，但在当前的 Harness 设计里，负结果往往直接被丢弃。如何系统性地从失败中学习，仍是开放问题。

人类监督如何嵌入。完全自动化的 Harness 看起来很酷，但有些关键节点，还是需要人来把关。问题是，怎么设计这个“人机接口”？让人类审查什么事、什么频率、什么深度，才能既保证质量，又不拖慢整体效率？这些都需要在实践中摸索答案。

总的来说，Harness Engineering 正在从一个边缘话题，走向 AI 自我提升路径的核心位置。它不会替代模型本身的进步，但很可能会成为那条“从能用到好用”之间的关键桥梁。