引子：智能之外，还有一层被低估的东西
大多数人谈论 AI 进步，第一反应是"模型又变强了"——参数更多、预训练数据更好、推理能力更强。但如果你认真观察过 Claude Code、Codex 这类 agent 产品的迭代历史，会发现一个反直觉的事实：同一个底层模型，换一套"脚手架"（harness），表现可以有天壤之别。
这正是 Lilian Weng 在她 2026 年 7 月发表的《Harness Engineering for Self-Improvement》里想讨论的核心问题。她给出了一个很有意思的框架：AI 的 recursive self-improvement（RSI，递归自我改进）未必要等到模型直接改写自己的权重才算数。在权重更新之外，还有一整层"部署系统"——决定模型如何观察、行动、记忆、自查、迭代的软件系统——同样是可以被优化、甚至被自动化优化的对象。而这一层，就是 harness。
这篇文章试图沿着 Weng 梳理的脉络，把 harness engineering 这条技术路线讲透：它是什么、经历了怎样的复杂度演进、目前卡在哪里，以及——这是我更感兴趣的部分——它接下来可能往哪走。
一、Harness 到底是什么，为什么突然重要起来
早期的 agent 框架有一个很经典的公式：agent = LLM + memory + tools + planning + action。这个公式描述的是"组件清单"，但没有回答一个更工程化的问题：这些组件之间怎么协作、状态怎么持久化、出了错怎么办、什么时候该停下来问人。
Harness engineering 补上的正是这一层。它更接近运行时（runtime）和系统设计，而不是 prompt 模板设计。Weng 打了一个类比：harness 之于模型，就像操作系统之于硬件——把复杂的调度、状态管理、权限控制封装起来，对外暴露一个足够简单的接口。这个类比其实很关键，因为它暗示了一个方向：随着行业发展，工具接口、配置协议会逐渐标准化，就像操作系统的系统调用逐渐收敛成几套标准一样。
文章总结了三个反复出现的 harness 设计模式，我觉得每一个都值得单独展开讲讲，因为它们分别对应了长程 agent 系统的三个核心痛点。
模式一：工作流自动化——从静态模板到可迭代的循环
第一个模式是把 agent 的执行过程定义成一个"目标导向的循环"：plan → execute → observe/test → improve → 再次 execute，直到目标达成或触发主动澄清请求。Weng 举了 Karpathy 的 autoresearch repo 作为例子，也引用了 OpenAI 关于 Codex agent loop 的博客图示——本质上说的是同一件事：agent 不应该是一次性生成答案的黑盒，而应该能读到自己上一步行动的反馈,并据此调整下一步。
这里真正有价值的洞察不是"要有循环"（这已经是常识），而是模型要能分析自己的失败轨迹，并通过一个"agent runtime"而非静态 prompt 来驱动迭代。换句话说，循环本身不是重点，循环里能不能真正利用执行历史才是重点。这个观察为后面 Self-Harness、Meta-Harness 这类工作埋下了伏笔。
模式二：文件系统作为持久记忆
第二个模式几乎是所有长程 agent 系统的共识：不要试图把整个工作流的所有日志都塞进 context。实验日志、代码 diff、论文摘要、错误 trace、历史 rollout 轨迹，这些产物的体量增长速度远快于模型训练时习惯的上下文长度。正确的做法是把它们写成文件，让模型通过读写文件系统（通常借助 bash 命令）来管理持久状态。
我觉得这一条背后有一个更深的判断：“学会用文件系统管理记忆"本质上是一种基础能力，而不是任务特定的技巧，所以它会随着核心模型能力的提升而自然变强——不需要为每个任务单独设计记忆机制。这也解释了为什么后面提到的几乎所有前沿工作（MCE、Meta-Harness、Self-Harness、DGM），无一例外都用文件系统而不是纯 prompt 拼接来管理状态。
模式三：Subagent 与后台任务
第三个模式是并行化：主 agent 派生多个 subagent 并行探索假设、跑实验，或者委托隔离的子任务而不污染主 context。这里的关键设计原则是把并行显式化、可检查——如果 subagent 的输出只存在于临时的对话上下文里，一旦中断就丢失了；但如果它们被写成文件、日志、状态记录，主 agent 就能在中断后恢复，并且能回顾自己的整个执行历史。
这三个模式合在一起，其实回答了同一个问题的三个侧面：agent 怎么在不被自己的历史"淹没"的前提下，充分利用这段历史。
二、Harness 优化的复杂度阶梯
文章里我认为最值得细读的一段，是关于"harness 优化对象"的演进路径：
instruction prompts → structured context → workflow → harness code → optimizer code
这条路径的含义是：随着模型越来越聪明，我们能交给它优化的对象也越来越"底层”、越来越通用。早期我们只敢让模型改改 prompt 措辞；后来我们敢让它管理结构化的 context；再后来敢让它设计整个工作流；现在，最前沿的工作已经在让模型直接修改决定信息存取展示逻辑的代码本身。
这条阶梯上我认为有三个节点特别值得展开：ACE → MCE → Meta-Harness，它们代表了 context engineering 这个子问题被逐层"卸下手工设计"的过程。
ACE：把 context 当作演化中的playbook
Agentic Context Engineering (Zhang et al., 2025) 的出发点是：与其让 context 越写越长、最后被压缩成一团模糊的摘要，不如把它当作一份不断增量更新的"结构化 playbook"。它设了三个角色——Generator 产生任务轨迹，Reflector 从成功和失败的轨迹里提炼 insight，Curator 把这些 insight 合并进 playbook。
ACE 里一个我认为设计得很聪明的细节是：Curator 不重写整段 prompt，而是输出一批带唯一标识符的结构化 bullet，再用确定性逻辑合并进已有的 playbook，并周期性去重、精炼。这个设计直接针对了两个常见问题——context collapse（反复重写导致信息丢失）和 brevity bias（模型天然倾向把内容越写越短、越写越空）。
MCE：把"怎么管理 context"和"context 里装什么"拆开
ACE 虽然让 context 本身能演化，但更新规则和整体工作流依然是手工设计的——Generator/Reflector/Curator 的分工是人定的。Meta Context Engineering (Ye et al., 2026) 更进一步，把这两层彻底拆开：skill（管理机制） 和 context（具体内容） 分别在两个层级上做优化。
用论文的符号来说，一个 MCE skill 定义了一个"context function"，把输入映射成 context，其中静态组件（prompt、知识库、代码库）和动态操作符（搜索、筛选、格式化）都被参数化了。整个优化是 bi-level 的：内层在给定 skill 的前提下找最优 context，外层在验证集上搜索最优 skill；一个"元层 agent"会对已有 skill 做类似"agentic crossover"的操作，生成给定任务的新 skill。实现上，一个 context function 就对应文件系统里的一个专属目录，既有静态的 skill.md，也有动态的 context/rollout 记录。
MCE 相比 ACE 的本质突破是：它不再假设存在一种"正确的"结构化方式（比如 ACE 假设 bullet-point playbook 就是对的形式），而是让"该用什么结构"这件事本身也成为可搜索、可演化的对象。
Meta-Harness：连"该检索什么信息"这件事都不预设了
Meta-Harness (Lee et al., 2026) 是这条阶梯目前最深的一层——它优化的对象干脆就是决定该存储、检索、呈现什么信息给模型的代码本身。这也是为什么它被称为"harness 的 harness"：它本身也是一个 harness，因为它决定了 proposer（负责提出新 harness 候选的模型）能看到什么信息。
我专门去查了这篇论文的细节（arXiv:2603.28052），有几个点我觉得比 Lil’Log 原文提到的更值得展开：
它解决的是"反馈被压缩得太狠"的问题。 论文观察到，现有的文本/prompt 优化方法（OPRO、TextGrad、AlphaEvolve、GEPA 等）无一例外都在用某种压缩过的反馈信号做优化——要么只看当前候选方案，要么只依赖标量分数，要么把反馈限制在简短的模板或摘要里。但 harness 恰恰是一个长程系统：某个关于"存什么、何时取"的设计选择，可能要经过很多步之后才显现出影响。压缩反馈往往正好把追溯这条因果链所需的信息给抹掉了。论文给出的量化对比很直观：现有方法每次优化迭代能看到的上下文大约在百到三万 token 量级，而 Meta-Harness 单次评估能产生的诊断信息量级是千万 token——差了三个数量级。
执行流程本身很朴素：一个具备文件系统访问权限的 coding agent（论文里用的是搭载 Opus-4.6 的 Claude Code）读取一个不断增长的文件系统，里面存着历史候选 harness 的源码、评分、执行轨迹；它提出新的 harness；新 harness 被拿去评测；所有产物再写回文件系统，循环继续。这个"外层循环"故意设计得极简——不预设任何固定的程序数据库结构，直接把无限制的文件系统访问权交给 proposer，让它自己决定要看什么。
一个消融实验很能说明问题：论文对比了三种给 proposer 的信息访问权限——只给分数、分数+摘要、完整执行轨迹。结果只给分数和给摘要的效果几乎没区别，而给完整执行轨迹之后，中位数表现直接跳升，甚至超过了另外两种设定下能找到的"最佳"候选。这说明摘要并不能替代原始执行轨迹——反而可能因为压缩掉了诊断细节而适得其反。
在三个差异很大的实验域（在线文本分类、检索增强的数学推理、TerminalBench-2 上的 agentic coding）里，Meta-Harness 找到的 harness 都超过了对应领域里手工设计的强基线，并且在未参与搜索的分布外任务和模型上依然有效——说明搜出来的策略不是过拟合的巧合，而是某种真正通用的机制。
看完这三层演进，我个人的读法是：这不是三个孤立的方法，而是同一条"卸下人工先验"的曲线。ACE 卸下了"该怎么组织 context 内容"这一层先验；MCE 又卸下了"该用什么机制去管理 context"这一层；Meta-Harness 则连"proposer 该看什么信息才能做出好决策"这层先验都不再预设，直接交给文件系统和 agent 自主检索。这其实正是深度学习历史上反复出现的"苦涩的教训"(bitter lesson) 模式——一旦某个设计空间变得可被自动搜索，通用型方法迟早会超越手工先验。
三、Workflow Design：把"怎么设计工作流"也变成搜索问题
如果说 context engineering 关心的是"给模型看什么"，workflow design 关心的是"模型该按什么流程做事"。这条线上，文章先介绍了几个手工设计的 auto-research 系统（AI Scientist 的提想法-写代码-做实验-写论文-同行评审全流程、ScientistOne 把"每个论断都要能追溯到证据源"作为核心设计约束、Autodata 用 challenger/weak solver/strong solver/verifier 的角色分工来合成"难度恰到好处"的训练数据），然后转向了把工作流设计本身当作搜索问题的两个代表工作：
ADAS (Automated Design of Agentic Systems) 用一个 meta-agent 在已有的 agent 档案库（初始只有 CoT、self-refine 这类简单 baseline）基础上，编程生成新的工作流设计——先出高层描述，再落地成代码，经过两轮自我修正检查新颖性，评估通过后加入档案库，循环往复。
AFlow 则把 agentic workflow 表示成一个图（节点是 LLM 调用动作，边是逻辑操作），用 MCTS 做优化：从模板初始化，按"分数+均匀探索"的混合策略选节点，用 LLM 提出修改，评测后决定是否留在树里，直到 top-k 均分收敛或预算耗尽。实验显示 AFlow 在 QA、代码、数学任务上都优于人工设计的工作流以及 ADAS。
这两个工作的共同点是：它们都把"设计一个好工作流"这件事从"一次性的人类决策"变成了"一个可以反复试错、有反馈信号的搜索过程"。这和前面 context engineering 那条线的演进逻辑其实是一回事——只是搜索的对象从"context 该长什么样"换成了"流程该怎么走"。
四、当 Harness 开始改自己：递归结构的希望与警示
这一节是我认为整篇文章里最值得警惕、也最有启发性的部分。
STOP (Self-Taught Optimizer) 是这条线最早的代表。它的目标不是直接改进某个具体方案，而是改进"改进者"这个函数本身——用一个 meta-utility（改进函数在一系列下游任务上的平均效果）作为优化目标，反复迭代出更好版本的改进函数。实验里，改进后的改进者摸索出了遗传算法、拆解再改进、多臂 prompt bandit、模拟退火、变化温度、beam/tree search 等一系列策略——这些都是人类工程师在做类似优化时会用到的经典手法，但是被模型自己"重新发现"了出来。
但这里有一个我觉得比"成功案例"本身更值得记住的细节：STOP 在 GPT-4 上能提升下游表现，换成较弱的 GPT-3.5 和 Mixtral 反而变差。这个结果给整条 harness self-improvement 的技术路线泼了一盆很必要的冷水——递归结构本身不是万能药，基础模型必须足够强，才能真正驾驭自我改进这个机制。换句话说，harness 改进能放大模型的能力，但不能替代能力。这个结论在我看来比任何一个具体的性能提升数字都重要，因为它划定了这条技术路线的适用边界。
Self-Harness 则设计了一套更工程化的三阶段循环：
- Weakness mining：把失败案例聚类成"经过验证器确认的失败模式"。这里有个细节值得注意——两次运行可能在表面上共享同一个"verifier 判定的结果"（比如同样都是 timeout 或 missing artifact），但背后的因果机制完全不同，所以需要保留一份信息丰富的失败记录，包含终端层面的判定原因、agent 行为的因果状态、以及 trace 暴露出的抽象机制,才能真正找到根因。
- Harness proposal：同一个模型作为 proposer，在有边界的提案上下文里工作——包括当前 harness 的可编辑区域、验证过的失败模式、需要被保留的"正确行为"记录、以及之前尝试过的修改摘要。修改应该优先针对可被窄范围改动解决的、反复出现的错误模式，而不是任务本身的难度问题；候选修改之间应该保持差异化和多样性。
- Proposal validation：候选修改要在 held-in（检验弱点是否真的被解决）和 held-out（检查有没有引入新问题）两个split上做回归测试，两边都没有回归才会被接受合并；被拒绝的候选会被记录下来但不影响当前 harness。
这套流程在 MiniMax M2.5、Qwen3.5-35B-A3B、GLM-5 三个不同的基础模型上跑 Terminal-Bench-2 时，学出了针对不同模型各自弱点的、不同的 harness 指令，并且提升了held-out通过率——这说明好的 harness 未必是"放之四海而皆准"的，它可能天然需要针对具体模型做定制。
Weng 在这一节末尾提了一句我觉得分量很重的话：如果一个程序被允许编辑自己所在的"操作系统"，抽象边界就被打破了。可编辑的范围需要被谨慎设计，权限控制和安全层必须活在这个自我修改循环之外。reward hacking 相关的所有老问题，在这里一个都没有消失，反而因为修改对象从"输出"变成了"决定输出的机制"而变得更隐蔽。
五、进化搜索：当评估比优化更容易的时候
进化搜索这条线的适用场景很明确：搜索空间庞大或形状怪异、难以用梯度直接优化、但评估解的好坏相对容易。Harness 搜索恰好符合这个条件。
文章按脉络介绍了几个代表工作：Promptbreeder 用丰富的变异算子优化任务特定 prompt，有意思的是连"变异指令本身"也在被同步进化；GEPA 把基于反思的 prompting 和进化搜索结合，用自然语言反思试错轨迹来提出 prompt 更新。
AlphaEvolve 是这条线上比较有代表性的系统：它维护一个候选程序池，用冻结（不参与训练）的 LLM 生成程序的 diff 来实现改进，反复评估子程序并保留表现好的。几个设计细节值得记住：prompt 里会包含父代程序、结果、指令，有时还有元信息；coding agent 能访问完整代码仓库，但明确用 # EVOLVE-BLOCK-START/END 标出可改进的代码区域；meta-prompt（也就是驱动进化的指令本身）会跟着指令和 context 一起被 LLM 建议着共同进化。消融实验显示，进化流程本身、prompt 里的 context、meta-prompt、全文件级进化、以及更强的底层 LLM，都各自贡献了增益——没有哪一个环节是可以省略的。
后续的 ThetaEvolve 把进化搜索和 RL、in-context learning 结合；ShinkaEvolve 则专注在采样效率上做了三处改进：设计 parent 采样策略平衡表现排名和子代数量、用 embedding 相似度做"代码新颖性拒绝采样"过滤掉太像的候选、以及维护一个"元便签本"来提炼成功方案里的好模式，指导未来的变异方向。
真正把这条线推到"harness 层面"的是 Darwin Gödel Machine (DGM)：它明确让一个 LLM coding agent 修改自己所在的 harness 代码库。流程是：从一个 agent 开始，每轮按性能高、子代少优先的概率挑一个父代，让它检视自己的评测日志、对自己的 harness 代码库提出改进、生成新版本的 coding agent；新 agent 经过评测，只有表现足够好的才会被加回种群池；如此反复。在 Claude 3.5 Sonnet 上、从很简单的初始 harness 配置出发，DGM 发现的 agent 在 SWE-bench Verified 上从 20% 做到 50%，在 Polyglot 上从 14.2% 做到 30.7%。后续的 Hyperagents 又加了一层元 agent，专门控制"该怎么修改已有的 task agent 来生成新 agent"。
这条线的天然局限也很直白：它在评估自动化、fitness 容易量化的领域（矩阵乘法、GPU kernel 优化、算法竞赛、数据中心调度）效果最好，一旦评估变得缓慢、模糊、依赖启发式判断，就很容易失灵。计算效率和有效性之间的取舍，也始终是这类方法绕不开的成本问题。
六、权重和 harness 一起优化：还很早期，但方向对了
SIA (Self Improving AI) 是文章里提到的把 harness 改进和模型权重更新放进同一个优化循环的早期尝试，设了三个角色：Meta-Agent（提出初始 harness）、Task-Specific Agent（执行任务）、Feedback-Agent（根据最近的轨迹决定该更新 harness 还是权重）。
Weng 对这个工作的态度是审慎的——她直接点出了实验设计里几个混杂因素：比如 task-specific agent（gpt-oss-120b）明显比负责 Meta-Agent 和 Feedback-Agent 的模型（Claude Sonnet 4.6）弱得多，基线选择也偏弱，导致很难跟其他相关方法做干净的横向对比。她的结论是"方向有趣，但证据还只是初步的"——这种克制的表述方式，我觉得恰恰是这篇文章比很多"AI 突破性进展"式报道更可信的地方。
七、七道未解的坎
文章末尾列出的七个挑战，我认为不是简单的"待办清单"，而是这条技术路线能走多远的天花板：
- 弱且模糊的评估器——自我改进循环目前只在评估指标可量化、可客观判定的任务上跑得动（这跟 RL 能work的条件几乎一样）。但 research taste、novelty、长期科学价值这些东西，本质上混合了问题构建、实验设计、以及"该追哪个意外结果、该放弃哪个失败尝试"的判断力，这些很难被压缩成一个标量。
- Context 与记忆的生命周期——Weng 提出一个我很认同的类比：既然人类能靠记忆维持一生的连续性，context engineering 或许不该永远停留在"软件系统的外挂层"，而应该逐渐成为智能本身的核心构成部分。
- 负面结果的缺失——研究文献天然偏向发表成功案例，LLM 在海量以"成功"为主的人类数据上训练出来，可能天生不擅长判断"该放弃这个假设了"“该承认这次失败了”。而一个好的研究 harness，理应让失败的尝试也容易被保留下来——因为从失败里学到的东西，往往是缩小搜索空间最有效的方式。
- 多样性坍塌——进化和 RL 循环天然倾向于利用已知的高回报模式，容易让整个种群坍缩成同一个解的变体。这对开放式研究尤其致命，因为最优路径初期往往在当前的评估标准下看起来更差。
- Reward hacking——自我改进循环会优化给定的任何信号：如果奖励来自单元测试，agent 可能过拟合到测试用例；来自 judge 模型，可能学会针对这个 judge 的取巧手段；来自 benchmark 分数，可能钻 benchmark 本身设计上的漏洞。评估器和权限控制理应活在这个演化循环之外,靠 held-out 测试、trace 审计、以及在关键决策点上引入人工评审来兜底。
- 长期健康 vs 短期任务完成——以 coding agent 为例，它已经能实实在在提升日常生产力，但优化目标普遍偏短期：能不能完成眼前这个任务是一回事，能不能长期维护一个由成百上千工程师共同维护的代码仓库的健康度，是完全另一回事。标准的 sandbox 式 RLVR 训练很难捕捉可维护性、所有权边界、迁移成本这些更慢变量的代价。
- 人的位置——人类应该往上层移动而不是被移出这个循环，问题是"在什么时机、什么抽象层级"提供监督，这本身就是一个需要被认真设计的系统问题。
文中引用的 Trehan & Chopra (2026) 那个实验我觉得特别值得多提一句：让 LLM 用最简单的工具（读文件、写文件、搜索、列文件）从一个研究想法一路走到一篇论文，三个领域里选出的四个想法，最后只有一个被完整跑通。观察到的六种失败模式——偏向训练数据里的默认做法、执行压力下往简单方案漂移、长程记忆退化、对噪声结果盲目乐观（也就是 Bubeck 等人说的"p-hacking and eureka-ing"）、缺乏领域直觉、以及科学品味薄弱——这几乎是一份"AI 自动化科研目前卡在哪"的清单,比任何单一 benchmark 分数都更诚实。
八、我自己怎么看接下来的方向
读完整条脉络，我想跳出综述本身,谈几个我自己觉得值得关注、但文章里没有展开的方向。
第一，“可解释的自我修改"会比"更强的自我修改"更快成为工程刚需。 DGM 和 Self-Harness 这类系统一旦规模化部署，“agent 改了自己的 harness"这件事本身就需要被审计。代码空间的过拟合虽然比权重空间"看得见”（一段写死的 if-else 判断远比一堆权重矩阵容易被人类工程师一眼识破），但这不等于它天然可解释——当搜索出的 harness 变成几百行互相耦合的逻辑时，审计成本会指数级上升。我预期接下来会出现专门针对"harness diff"的审计工具，类似代码审查里的静态分析，但目标是识别 reward hacking 的痕迹而不是传统意义上的 bug。
第二，Meta-Harness 揭示的"信息压缩是主要瓶颈"这个洞察，可能比它本身的方法更重要。 如果给 proposer 完整执行轨迹比给摘要好这么多，那意味着我们过去几年在 prompt engineering、context engineering 上投入的大量精力，某种程度上都是在"和有限上下文窗口做斗争”,而不是在解决问题本身。随着上下文窗口和长上下文推理能力持续增长，一部分 harness engineering 的价值可能会像 Weng 预测的那样被内化进模型本身——但"决定该检索什么、该呈现给谁看"这件事，我认为不会完全消失，它会从"应对上下文限制的权宜之计"变成"信息路由"这个更本质的问题。
第三，评估器的瓶颈会倒逼"评估器本身"成为下一个被优化的对象。 现在几乎所有能自我改进的系统,都依赖一个相对客观的评估信号（unit test、benchmark、verifier）。真正卡住 harness engineering 往"科研发现"这类模糊领域延伸的,不是 proposer 不够聪明，而是我们没有一个足够好的、能评判"这个研究方向有没有价值"的信号。ScientistOne 那种"每个论断都要溯源到证据"的做法,本质上是在用可验证性替代品味——这是一个务实但有代价的妥协。我预计接下来会看到更多"用多个弱评估器投票/交叉验证来逼近一个强评估信号"的尝试，本质上是把评估这件事也纳入自我改进的循环,而不是把它当作外部给定的、一成不变的裁判。
第四，人机协作的"接口设计"会成为一个独立的研究问题，而不只是安全附加项。 文章里说"人应该往上移动而不是被移出循环"，这句话说起来容易，做起来涉及一整套接口设计问题：在什么时间点触发人工审查？以什么形式呈现给人看（一份 diff？一份自然语言摘要？一段执行轨迹回放）？人的反馈又该怎么被系统正确地吸收、而不是被下一轮压缩摘要冲刷掉？这本质上是一个 HCI 问题，但目前几乎所有自我改进系统的论文都把它当作"未来工作"一笔带过。我认为这恰恰是接下来最容易被低估、但决定这条技术路线能不能真正规模化落地的一环。
回到最开始的问题：AI 的自我改进，到底走的是"模型直接改自己权重"这条路，还是"模型改自己周围的系统"这条路？读完这篇文章我的感觉是——这个问题本身可能问错了。Harness engineering 展示的恰恰是,这两条路径正在互相渗透：文件系统本身就是一种"外部记忆权重"，proposer 检索历史轨迹的方式本质上是一种"注意力机制"的软件实现，而 DGM、SIA 这类工作已经在探索把两者揉进同一个循环里。也许最终的答案不是"harness 会被内化进模型"或者"模型会一直依赖外部 harness"这种二选一，而是这条边界本身会一直模糊下去——就像今天我们已经很难说清楚,一个 agent 的"智能"到底应该归功于它的权重，还是它周围那套决定它能看到什么、能做什么的系统。