刚刚，翁荔博客又上新：通过Harness工程实现AI自我提升¶

Ch05.062 刚刚，翁荔博客又上新：通过Harness工程实现AI自我提升¶

📊 Level ⭐⭐ | 10.1KB | entities/刚刚翁荔博客又上新通过harness工程实现ai自我提升.md

刚刚，翁荔博客又上新：通过Harness工程实现AI自我提升¶

2026年7月4日，Lilian Weng（翁荔）更新博客，系统梳理了从 ACE、Meta Context Engineering 到 Self-Harness、Darwin Gödel Machine 等一系列围绕 "Harness 自我优化" 的研究工作。文章核心问题：递归式自我提升（Recursive Self-Improvement, RSI）究竟会先发生在模型权重层面，还是先发生在这层「脚手架」上？

核心要点¶

Harness 的定位：介于原始模型与真实世界场景之间的系统层，负责编排执行流程、工具调用、上下文管理、结果评估。其重要性不亚于模型本身的原始智能。
三大设计模式：工作流自动化（目标导向循环）、文件系统作为持久化记忆、子智能体与后台任务并行执行。
Harness 优化的演进路径：指令提示词 → 结构化上下文 → 工作流 → Harness 代码 → 优化器代码，朝着更通用的方法论方向演进。
递归自我提升的路径：近期内 RSI 不太可能是模型直接改写自己的权重，更可能的路径是 Harness 工程朝着"元方法论"演进（改进获得更好答案的机制本身）。
七个关键挑战：弱评估者、上下文与记忆生命周期、负面结果、多样性坍缩、奖励作弊、长期成功评估、人类角色定位。

Harness 设计模式¶

Weng 在文章中归纳了 Harness 工程的三种核心设计模式：

模式一：工作流自动化。设计一个让模型可以在其中运行、测试并迭代的工作流。Karpathy 的 autoresearch 仓库是典型范例——规划、执行、观察/测试、改进，直到达成目标。模型通过智能体运行时（而非静态提示词模板）来分析执行轨迹和失败案例，据此迭代改进。

模式二：将文件系统作为持久化记忆。在长时程系统中，产物（实验日志、代码 diff、论文摘要、错误追踪）往往会超出模型的上下文窗口。Harness 不应把所有工作流和日志塞进上下文，而应将持久化状态保存在文件中。学会读写文件系统是 LLM 的基础技能，因此这种模式天然会随着核心模型能力的提升而受益。

模式三：子智能体与后台任务。Harness 可以派生多个子智能体并行执行任务，并对后台任务进行监控。关键设计选择是让并行性显式可检查——子智能体的输出应当被保存为文件、日志和状态记录，而非只存在于短暂的对话上下文中，这样模型就可以在中断后恢复状态并对执行历史进行推理。

Harness 优化技术全景¶

上下文工程¶

Weng 在文章中详细梳理了上下文工程的技术谱系：

ACE（Agentic Context Engineering）：将上下文当作一本不断演化的 "playbook"，由生成器（Generator）、反思器（Reflector）和策展器（Curator）三部分组成。策展器并不重写整段提示词，而是输出结构化、条目化的要点，防止上下文坍缩和简短偏见。
MCE（Meta Context Engineering）：将"机制"（如何管理上下文）与"产物内容"（上下文里具体是什么）分离开来，让技能演化发生在元优化层面，而上下文优化发生在基础层面。这是一个双层优化问题。
Meta-Harness：优化的对象是决定"哪些信息应当被存储、检索并呈现给模型"的那段代码本身——用于优化 Harness 的 Harness。提议者（一个编程智能体）输出一批位于帕累托前沿上的 Harness 候选方案。

工作流设计¶

AI Scientist：构建完整的流水线，涵盖提出想法、编写代码、运行实验、分析结果、撰写论文到同行评审全过程。
ADAS（Automated Design of Agentic Systems）：把智能体设计表述为一个优化问题，由元智能体提出新的智能体工作流设计方案。
AFlow：将工作流表示为图（节点=LLM调用，边=代码逻辑），通过蒙特卡洛树搜索（MCTS）优化工作流拓扑。

自我提升型 Harness¶

STOP（Self-Taught Optimizer）：递归式脚手架改进的早期范例——目标不是直接改进方案本身，而是改进改进器自身。实验中 STOP 发现了多种策略（遗传算法、任务分解、多臂老虎机式提示词选择、模拟退火等）。
Self-Harness：依靠 LLM 智能体通过"弱点挖掘→有边界 Harness 提议→验证"循环来改进自己的系统。
Darwin Gödel Machine / Hyperagents：明确以 "可编辑的 Harness 代码仓库" 的进化为目标，由一个基于 LLM 的编程智能体完成。DGM 在 SWE-bench Verified 上从 20% 提升到 50%。

深度分析¶

1. Harness 工程正在从"工程实践"走向"元方法论"¶

Weng 文章最核心的洞见在于，Harness 工程正在经历从"手写规则"到"元方法论"的范式转换。最初的 Harness 设计依赖于人手工编写提示词和流程规则，但 STOP、ADAS、AFlow 等工作已经证明：Harness 改进本身可以（且应该）成为一个可搜索、可优化的对象。这意味着未来 AI 系统的竞争力将越来越取决于"改进改进方法的方法"，而非单次改进的效果。

2. "Harness 层 vs 核心智能"的辩证关系¶

文章揭示了一个微妙但关键的辩证关系：Harness 工程的目标是提升模型表现，但有效的 Harness 改进反过来需要足够强的模型支撑。STOP 在使用 GPT-4 时能够提升下游任务表现，但换成 GPT-3.5 和 Mixtral 时效果反而变差——这说明"仅有递归结构是不够的，基础模型必须足够强，才有能力去改进这套机制本身"。这意味着 Harness 改进和模型能力之间存在正反馈循环，而非单向依赖。

3. 评估者瓶颈是 RSI 的首要障碍¶

Weng 将"弱且模糊的评估者"列为七大挑战之首，这一判断切中了当前 RSI 的核心矛盾。在代码生成、数学推理等可自动验证的领域，自我提升循环已经展现出显著效果；但在研究品味、新颖性、长期科学价值等需要人类判断力的维度上，自动化评估仍然力不从心。这暗示：RSI 在短期内的进展将集中在"可验证任务"领域，而开放研究等需要深层判断的领域仍将依赖人类参与。

4. 多样性坍缩与奖励作弊的系统性风险¶

进化式循环倾向于利用已知的高回报模式，可能导致"种群坍缩"——所有方案变成同一解的不同变体。Weng 引用了一系列研究（STOP、Self-Harness、DGM）的发现表明，奖励作弊问题需要将评估者和权限控制置于演化循环之外。这是 RSI 系统设计中的核心安全约束：反馈信号和修改权限需要从优化循环中独立出来。

5. 人类角色从"操作者"向"监督者"迁移¶

文章在末尾强调"人类应当在整个技术栈中向上移动，而不是被排除在循环之外"。这与 Harness Engineering Framework 中的 "人在环比" 设计原则一致——随着 AI 系统的自主性增强，人类应该从具体操作中抽离，转向更高层的目标设定、边界定义和异常干预。

实践启示¶

Harness 工程是系统性工程，不是提示词工程：Weng 的文章清晰地说明，Harness 已经超越了提示词工程的范畴，涉及工作流设计、上下文管理、子智能体调度、安全权限控制等多个维度。组织在采用 AI 代理时，应将这些要素纳入系统工程设计，而非仅关注模型选择和提示词优化。
从"单代理"走向"代理系统"的设计思维：文章梳理的模式三（子智能体+后台任务）和 Meta-Harness 等工作表明，单个强大的代理不如一个协调良好的代理系统。设计时需考虑：任务如何拆解、子代理如何通信、状态如何持久化、失败如何恢复。
优先关注可验证领域：基于 Weng 对评估者瓶颈的分析，在构建 RSI 系统时应优先选择代码生成、数据分析、文档审查等具有明确验证标准的场景，因为在这些领域自我提升循环更容易建立和测量。
建立"元优化"视角：与其每次手动改进 Harness，不如设计一个可以自动搜索 Harness 设计空间的元系统。AFlow 和 ADAS 的方法论表明，将 Harness 改进自动化比手写优化更可持续。
关注评估者设计的安全性：自我提升系统会优化任何交给它的信号，因此评估者的设计需要特别谨慎。宜采用 held-out 测试、"人+自动"混合验证、以及定期审计机制来防范奖励作弊。

→ 原文存档

关联¶

相关概念: Harness Engineering
相关: Agent 架构