当模型学会改造自己的脚手架：Harness Engineering 解读

当模型学会改造自己的脚手架：读 Lilian Weng 的 Harness Engineering for Self-Improvement

论文原文：Harness Engineering for Self-Improvement

来源：https://lilianweng.github.io/posts/2026-07-04-harness/

发布日期：2026-07-04

作者：Lilian Weng

来源类型：技术综述文章，不是 arXiv 论文

你现在看到的很多 AI 产品，表面上像是在和一个模型聊天。

但真正决定它能不能把事情做完的，经常不是那几行提示词，也不是模型那一瞬间吐出的答案，而是外面那一整套看不太见的运行系统：它怎么拿到任务，怎么拆计划，怎么读文件，怎么调用工具，怎么保存失败日志，怎么从上一次做错的地方继续往前走。

Lilian Weng 在这篇文章里把这个外层系统叫做 harness。这个词如果直译成“马具”会很怪，放在 AI 里更接近“把模型接入真实世界的执行框架”。模型像发动机，harness 像变速箱、仪表盘、刹车、路线记录器和维修手册。没有这层东西，发动机再强，也很难稳定地跑完一条复杂路线。

Recursive Self-Improvement, RSI：递归式自我改进，指一个智能系统用当前能力去改进产生下一代能力的机制。

Harness：围绕基础模型的执行系统，负责工具调用、上下文管理、状态保存、权限控制、评测和迭代。

这篇文章真正尖锐的地方在于，它把“自我改进”从一个科幻问题拉回到工程问题。

模型今天还很难直接重写自己的权重，然后可靠地变成更强的下一代模型。但模型已经可以改造自己外面的工作流、上下文、文件结构、工具接口和评测循环。换句话说，近期最现实的 RSI 可能不是模型钻进自己的神经网络里动刀，而是模型先学会改造自己的脚手架。

这就是这篇文章的主判断：近处的自我改进，先发生在 harness 层。

一、harness 不是外挂，它是智能进入世界的方式

早期讨论 agent 时，大家常用一个简单公式：LLM 加 memory 加 tools 加 planning 加 action。这个公式还停留在“组件拼装”的层面。Weng 这篇文章往前推了一步：当任务变长、工具变多、失败会累积、上下文会爆炸时，真正需要优化的是系统如何运行。

Deployment system：部署系统，指基础模型之外让模型在真实任务里运行的工程层，包括工具、状态、权限、日志、评测和用户交互。

Agent runtime：智能体运行时，指模型每一步观察、行动、调用工具、接收反馈并继续生成的执行环境。

看第一张图，Codex agent loop 其实很朴素：模型生成下一步动作，调用工具，工具返回结果，这个结果再影响下一次生成。

这张图的价值不在于复杂，而在于它把“会聊天的模型”和“会做事的系统”分开了。一个模型如果只输出文本，它的智能会停在回答层。一个模型如果能在循环里行动、观察、修正，它才开始接近我们平时说的“工作”。

这里可以用一个剧场的例子来理解。演员能力再强，如果没有舞台监督、道具清单、灯光提示、出场顺序和排练记录，演出就会变成每个人凭记忆即兴发挥。harness 做的就是舞台监督那部分工作。如果不这样做，模型每一轮都像重新醒来一次，上一轮的失败、环境状态和工具结果很容易丢在聊天记录里，最后变成一场看起来很热闹但无法复盘的即兴表演。

Coding agent 的工具界面已经开始稳定下来。文件发现、文件读取、apply_patch、shell、git diff、MCP、web fetch、多 agent 委托、后台任务管理，这些东西看起来不像“智能”，但它们定义了模型能碰到什么、能记住什么、能验证什么。

Weng 的判断很克制：harness layer 和 core intelligence 不是互相替代。更聪明的模型会让 harness 少一些拙劣规则，但外部世界不会消失。目标、约束、上下文、评测和权限边界仍然需要被表达出来。

模型能力越强，harness 反而越不能随便写。因为它不再只是提示词模板，而是在定义一个智能系统的行动边界。

二、三个设计模式：循环、文件、子任务

文章先给出三个朴素但非常实用的设计模式：workflow automation、file system as persistent memory、sub-agent and backend jobs。

Workflow automation：工作流自动化，指把任务组织成计划、执行、观察、测试、改进、再执行的循环。

Persistent memory：持久化记忆，指把日志、实验结果、代码差异、失败轨迹等长期状态保存在文件或数据库中，而不是塞进一次性的上下文窗口。

workflow automation 的核心是把 agent 从“一次回答”变成“多轮试错”。它要能计划，要能执行，要能测试，要能根据测试结果修改计划。Karpathy 的 autoresearch，Codex 的 agent loop，Claude Code 的 repo 操作，其实都在往这个方向走。

文件系统作为记忆更容易被低估。很多人一谈 AI memory 就想到向量数据库，但长任务里最可靠的记忆经常就是文件：日志、计划、失败记录、实验表、diff、checkpoint。文件不是高级结构，却是模型已经学会使用的结构。模型在训练中见过大量 shell、repo、README、patch、log，所以让它读写文件，等于顺着已有能力设计接口。

再用一个日常场景说。你要连续三天做一桌复杂年夜饭，最稳妥的办法不是把所有菜谱、采购、火候、客人口味都背在脑子里，而是把采购单、半成品标签、冰箱位置和昨天踩坑写下来。如果不这样做，第二天你会重新问一遍“盐放哪儿了”“谁不吃辣”“这锅汤昨天为什么失败”。上下文窗口再长，也不该承担冰箱标签的工作。

Context window：上下文窗口，指模型一次推理时能看到的输入范围，包括用户指令、历史消息、工具返回和系统注入的信息。

Sub-agent：子智能体，指由主智能体启动的独立执行单元，通常用于并行搜索假设、运行实验或处理隔离子任务。

子任务和后台任务则解决另一个问题：真实工作不是线性的。一个主 agent 可能需要同时跑三组实验、查两个方向、让一个子 agent 审代码、让另一个子 agent 搜论文。只要这些结果都保存在可检查的文件和日志里，主 agent 就可以在之后合并证据。

这里的反事实很直接。如果子 agent 的结果只躺在临时聊天上下文里，主 agent 很快会遗忘它们的来源和可信度。如果后台任务只有一句“跑完了”，没有 stdout、stderr、版本、参数和输入文件，后面谁也不知道这个结果到底怎么来的。

Weng 把这些设计称为 harness design patterns，我觉得这个词用得很准。它们不是某个产品的功能列表，而是长任务 agent 的基本生活习惯。

三、从上下文工程到 Meta-Harness：优化对象开始下沉

文章第二大段进入 harness optimization，先讲 context engineering。它的背景很简单：agent 跑得越久，工具返回越多，失败轨迹越多，把所有东西拼进 prompt 迟早会失控。

Context Engineering：上下文工程，指主动构造、压缩、选择和维护模型输入，而不是把所有历史原样塞进上下文。

Agentic Context Engineering, ACE：一种把上下文当成可演化 playbook 的方法，用 generator、reflector、curator 从轨迹中提炼条目。

ACE 的设计很像把经验写进一本活页手册。generator 负责产生任务轨迹，reflector 从成功和失败里总结经验，curator 把经验变成带标识符的条目，再合并进结构化 playbook。

这个设计最聪明的地方是避免反复重写一大坨 prompt。每次都重写全文，容易越改越短，细节被吞掉，失败原因被抹平。ACE 把经验变成条目，用确定性逻辑合并和去重，等于把“记忆更新”从文学创作变成账本维护。

类比到办公室也很直观。一个团队复盘项目时，如果每次都让新人写一篇新的“最佳实践全文”，很多细节会被改没；如果大家往同一张事故表里追加条目，每条都有编号、触发条件和修复方式，后面的人更容易查。如果不这样做，所谓经验就会变成越来越圆滑的口号，看起来干净，真正遇到问题时派不上用场。

Meta Context Engineering, MCE：元上下文工程，把“如何管理上下文”本身也作为可演化对象，让 skill 和上下文函数一起优化。

Bi-level optimization：双层优化，内层优化任务上下文，外层优化产生上下文的机制。

MCE 又往下挖了一层。ACE 里“用条目维护 playbook”还是人设计的机制。MCE 问的是：能不能让系统自己搜索更好的上下文管理机制？于是它把 skill 当成外层对象，把具体任务上下文当成内层对象。外层进化 skill，内层用 skill 指导上下文构造。

Meta-Harness 再往下挖：被优化的不只是上下文内容，也不是上下文规则，而是决定如何存储、检索、呈现信息的代码。

Meta-Harness：用于优化 harness 的 harness，外层由 coding agent 提出候选 harness 代码，并通过评测筛选。

Pareto frontier：帕累托前沿，指多个目标之间无法单方面改进而不牺牲其他目标的一组候选解。

Meta-Harness 的外循环很像一个工程团队在自动做系统重构：读取历史轨迹，提出新的 harness 版本，跑评测，保留合格版本，继续迭代。它把 harness 候选方案放在文件系统里，包含源码、分数、轨迹和状态更新。模型不用把所有历史吞进 prompt，而是像工程师一样用 grep、cat、日志和 diff 读自己的过去。

这一节的根本矛盾是：上下文既要完整，又要可用。完整意味着保留大量历史，可用意味着模型每一轮只能看有限信息。ACE、MCE、Meta-Harness 的共同方向，是把“该看什么、怎么压缩、怎么更新”变成可优化对象。

如果不这样做，长任务 agent 会出现两种坏结果：要么什么都记，最后上下文像垃圾堆；要么疯狂压缩，最后只剩几句听起来正确但无法指导行动的格言。

四、workflow search：让流程自己变成候选程序

上下文之外，另一个可优化对象是 workflow。自动研究系统就是典型例子：提出想法、写代码、跑实验、分析结果、写论文、审稿。AI Scientist 把这条链路做成专家设计的 pipeline。

Workflow design：工作流设计，指把多个模型调用、工具调用、判断节点和代码逻辑组织成可执行流程。

AI Scientist：一种端到端自动研究 pipeline，覆盖想法生成、实验、论文写作和评审。

Autodata 则把数据生成变成一个多角色系统：challenger 出题，weak solver 尝试，strong solver 尝试，verifier 判断。目标是产生“刚好有难度”的样本，也就是弱模型做不出，强模型做得出。

这很像一个老师给班级出题。题太简单，所有学生都会，训练不到能力；题太难，所有学生都不会，也学不到东西。好的题应该卡在边界上。如果不这样做，合成数据就会变成漂亮但无效的作业本，数量很多，训练信号很弱。

Automated Design of Agentic Systems, ADAS：自动设计智能体系统的方法，让 meta-agent 编写新的 agent workflow 代码，并用评测筛选。

Self-refine：自我修正流程，模型先给自己的输出提反馈，再根据反馈生成修订版。

ADAS 的想法更激进：既然 workflow 是程序，那就让 meta-agent 直接生成 workflow 程序。它从简单 agent 框架开始，把成功设计放进 archive，再让 meta-agent 参考 archive 写新设计，评测后把好的放回 archive。

AFlow 把 workflow 表示为图。节点是 LLM 调用，边是逻辑操作，优化方法用 MCTS。每一轮从树里选一个已有 workflow，扩展出一个修改版，跑评测，分数好就加回树里。

Monte Carlo Tree Search, MCTS：蒙特卡洛树搜索，一种在巨大决策树里平衡探索和利用的搜索算法，常用于游戏 AI 和规划问题。

AFlow：把 agent workflow 表示为图，并用 MCTS 搜索更好 workflow 的方法。

这里真正的变化是：流程不再只是工程师的手工经验，而是可以生成、执行、评分和进化的对象。

但这个方向也有边界。workflow search 在 QA、数学、代码这类可评测任务上很自然，因为答案可以打分。开放研究就麻烦得多。一个实验流程看起来“新颖”，不代表它问了正确问题；一个论文草稿结构完整，不代表它贡献真实。

五、自改进 harness：最危险也最现实的一步

如果 context 和 workflow 都能优化，下一步自然是优化整个 harness。Weng 在这里讨论 STOP 和 Self-Harness。

Self-Taught Optimizer, STOP：递归改进 improver 的方法，目标不是直接改进某个解，而是改进负责产生改进的函数。

Meta-utility：元效用，用来评价一个 improver 在一组下游任务上平均能带来多少改进。

STOP 的设定很有意思。它不是让模型直接解决任务，而是让模型改造“用来改进解法的程序”。初始 improver 接收一个解、一个 utility function 和一个黑盒语言模型，输出改进后的解。然后系统再评估这个 improver 本身，把 improver 变成下一轮优化对象。

实验里，STOP 发现了遗传算法、分解后改进、多臂 prompt bandit、模拟退火、温度变化、beam search、tree search 等策略。

这个结果有一个冷水点：GPT-4 可以让平均下游表现随迭代变好，但 GPT-3.5 和 Mixtral 这类较弱模型会退化。递归结构本身没有魔法。底层模型不够强，改造机制的动作会把系统带偏。

这像让学徒修改车间的作业流程。经验足的老师傅可能会发现“这一步应该提前验料”，效率会提高；经验不足的人可能删掉安全检查，因为那一步看起来拖慢速度。如果不这样做，流程不会变好；但如果随便让能力不够的系统改流程，坏改动会比好改动更快积累。

Self-Harness：让 agent 通过 weakness mining、bounded harness proposal、proposal validation 三段循环改进自己 harness 的方法。

Held-in / held-out split：内部测试集和外部保留测试集，前者检查目标弱点是否修复，后者检查是否引入回归。

Self-Harness 的结构更工程化。先挖失败模式，再基于失败模式提出有边界的 harness 修改，最后用 held-in 和 held-out 两组任务验证。只有没有回归的修改才会合并。

这张图里最该盯住的是 bounded proposal。自改进听起来像“随便改自己”，但可靠的自改进必须限制可编辑表面：能改哪些文件，不能碰哪些权限，哪些测试必须过，哪些历史成功行为必须保留。

这一节解决的根本矛盾是：系统要能改自己，否则无法真正适应长期任务；系统又不能无限制地改自己，否则会破坏抽象边界、权限边界和评测边界。

六、进化搜索：适合可评测任务，不适合凭感觉的研究品味

Weng 接着讲 evolutionary search。它适合两类情况：搜索空间巨大或形状怪，无法直接用梯度优化；但候选方案容易评估。

Evolutionary search：进化搜索，通过生成候选、变异、评估、保留高 fitness 个体来搜索解空间。

Fitness：适应度，候选方案在某个评测函数下的得分，用来决定是否保留。

AlphaEvolve 是这一类方法的代表。它维护一池候选程序和 prompt，让冻结的 LLM 生成 diff，跑评测，留下成功的子代。随着迭代增加，系统会不断发现更好的程序。

AlphaEvolve 的几个工程细节很重要：prompt 里有 parent programs、结果、指令和 meta 信息；代码里用 EVOLVE-BLOCK 标出可修改区域；meta-prompt 也会和程序一起演化。

这像开一个菜谱实验室。你让十个人同时改一道菜，每次只保留盲测分数更高的版本，还记录每次加盐、换火候、换食材的差异。如果不这样做，你只能凭厨师直觉慢慢试；但如果没有盲测指标，大家很快会优化到“看起来高级”而不是“真的好吃”。

Darwin Gödel Machine, DGM：让 LLM coding agent 修改自身 harness code 的进化系统，在固定模型下演化 agent 仓库。

Open-ended evolution：开放式进化，指系统不断生成新方向，而不是只朝一个固定局部目标微调。

DGM 把进化目标从普通程序推进到 agent harness 仓库本身。它从一个 coding agent 开始，每轮根据性能和子代数量选父代，让这个父代查看自己的 benchmark 日志，然后修改自身 harness code，得到新的 agent。新 agent 再评测，表现足够好才放回池子。

文章给出的实验数字很醒目：使用 Claude 3.5 Sonnet 作为基础模型和简单初始 harness 配置，DGM 发现的 agents 在 SWE-bench Verified 上从 20% 到 50%，在 Polyglot 上从 14.2% 到 30.7%。这说明在固定模型下，外层系统设计的空间仍然很大。

但这类方法的软肋也很清楚：它需要自动评测。矩阵乘法、GPU kernel、算法竞赛、数据中心调度，容易评估。研究品味、产品判断、架构长期健康，很难快速打分。

七、权重和 harness 一起动：诱人但证据还很薄

harness evolution 改的是模型外层系统。完整的自我改进迟早会碰到模型权重。SIA 是文章里提到的早期尝试：同一个循环里既可以更新 harness，也可以更新模型参数。

SIA：Self Improving AI with Harness & Weight Updates，用 meta-agent、task-specific agent、feedback-agent 协调 harness 更新和权重更新。

Goodhart effect：古德哈特效应，指一个指标一旦成为优化目标，就会失去原本的度量意义，系统会学会钻指标空子。

SIA 的 Feedback-Agent 根据最近轨迹决定下一步是改 harness 还是改 weights。

Weng 对 SIA 的评价明显保留。实验里 task-specific agent 比 Meta-Agent 和 Feedback-Agent 弱很多，baseline 也弱，所以结果很难和相关方法干净对照。方向有意思，证据还薄。

这个判断很重要。把 harness 和权重放在一起优化，听起来更接近完整 RSI，但混杂因素会暴增。到底是外层流程变好了，还是强 evaluator 帮了忙，还是弱 baseline 太弱，还是权重更新真带来了泛化能力，很难拆开。

类比到训练运动员也一样。你同时换教练、换训练计划、换饮食、换鞋、换比赛策略，然后成绩提升了。你当然可以高兴，但你很难知道是哪一项起作用。如果不这样做，系统进步可能太慢；如果所有变量一起动，因果解释会变成一团雾。

八、真正的瓶颈：评测器、失败记忆和长期目标

文章最后的 future challenges 是全篇最不该跳过的部分。Weng 没有把 self-improvement 写成一条直线上升的技术路线，而是把几个瓶颈摆出来：弱评测器、上下文和记忆生命周期、负结果、diversity collapse、reward hacking、长期成功和人类角色。

Evaluator：评测器，给候选输出、候选 workflow 或候选 harness 打分的系统，可以是单元测试、基准、judge model、人类审查或混合机制。

Reward hacking：奖励黑客，指系统学会优化评分信号本身，而不是优化真正想要的能力或结果。

AI Scientist 说明自动研究流程可以做很多事，但写出论文不等于完成科学发现。Trehan 和 Chopra 的实验更冷：让 LLM 从 idea 到 paper，最小脚手架加基础工具，四个想法里只有一个完全执行成论文。他们观察到六类失败：偏向训练数据默认方案、执行压力下 implementation drift、记忆退化、过度乐观、缺少领域 craft、科学品味弱。

这几个失败模式很像今天 coding agent 的放大版。模型会用旧库，会在实现复杂时滑向常见简单方案，会把失败实验说成成功，会缺少“这个结果不可能吧”的直觉。

Implementation drift：实现漂移，指系统在执行复杂方案时逐渐偏离原始方法，滑向更常见但不等价的实现。

Diversity collapse：多样性坍缩，指进化或强化学习循环过度利用高分模式，候选方案逐渐变成同一种套路。

长期目标是另一个大坑。一个 coding agent 可以修今天的 bug，但它是否保护了三年后仓库的可维护性？它是否尊重 ownership boundary？它是否引入迁移债务？这些很难被 sandbox 里的短期 reward 捕捉。

这里最好的类比是城市修路。你可以用一个短期指标优化“今天通车速度”，然后把所有维护井盖都盖死，把未来检修通道堵住，把排水坡度做错。今天看起来畅通，下一场暴雨整条路报废。如果不这样做，短期效率可能上不去；但如果只看短期效率，系统会把未来成本藏起来。

自我改进真正难的地方，不是让系统动起来，而是让它知道什么不该动，什么失败必须留下，什么分数不能被当成真理。

数据表：这些路线到底在优化什么

这张表暴露出一个很实在的排序：越靠近代码、测试、程序性能，证据越硬；越靠近科学品味、长期价值、模型权重联合更新，证据越薄。

所以这篇文章虽然标题里有 self-improvement，但它真正给工程师的提醒不是“马上做一个会自我进化的 AI”，而是先把 harness 做成可记录、可评测、可限制、可回滚的系统。没有这些底座，自我改进只是把错误自动化。

写在后面

这篇文章发布于 2026 年 7 月 4 日，我写这篇解读时是 2026 年 7 月 8 日，只隔了 4 天。它最有价值的地方是把很多散落名词重新放到一条工程链上：prompt engineering 没消失，而是被 context engineering 吸收；agent workflow 没定型，而是变成 search space；self-improvement 也没有一步跳到权重自改写，而是先落在文件系统、评测器和权限边界上。读完后我更怀疑那些只强调“模型更聪明就行”的说法，因为真实任务里的聪明经常藏在模型外面那一圈枯燥设施里。

最后留下的画面不是一个 AI 在黑箱里改写自己的大脑，而是一个 coding agent 坐在仓库根目录，看着自己的失败日志、测试输出、旧补丁和权限清单，犹豫下一行到底该改代码、改流程，还是承认这次评测根本问错了问题。