Harness是什么，为什么成了被优化的对象
一个base模型本身跑不出Agent的全部能力。它是个受限于权重和当前上下文的顺序处理器：下一步决策只能用到权重和活跃上下文里暴露的状态。真正让它"动手"的，是包裹在外面的那层Harness：系统提示、工具注册、上下文管理与压缩、编排逻辑、验证规则、失败恢复。ReAct把它简化成"思考 - 行动"循环，Claude Code、Codex、OpenHands把它做成产品级系统。从ReAct到这些产品，Harness长期以来几乎都由人类专家手写。
但有两件事让"Harness是写死的外壳"这个旧看法站不住了。第一，它的有效性是模型相关的：不同模型有不同工具使用习惯、错误模式和提示敏感度，给A模型调好的Harness套到B模型上未必好用。新模型发布越来越快，为每个模型人工重写专属Harness既慢又贵。第二，换Harness的影响量级出人意料，Meta-Harness原文引述，仅更换Harness、固定模型与基准，性能差距可达6 倍（引自其文献 [47]，即SWE-Bench Mobile上的结果；这是该文献报告的极端差距，不一定是典型情况，但足以说明Harness的影响不在小数）。Self-Harness同样指出同一base模型在不同Harness下表现差异巨大。Harness的影响不亚于模型本身，却长期被当成一次性写死的设计。
这两条合在一起，把Harness推到了一个新位置：它本身值得被单独、系统化、反复地优化，而不是写完即定型。于是出现一条清晰的范式演进，从人类专家手写，到外部Agent自动搜索Harness代码，再到模型改自己的Harness。顺着这条演进，三个范式各自怎么改Harness、改完怎么验证，以及六个系统在这条路上各自铺了哪一段、又都卡在哪个边界，就是本文要讲的。六个系统和三个范式的关系需要先说清，免得后面混淆：Self-Harness和Meta-Harness直接是范式三、范式二的代表；AutoSaddler和Self-Harness同属propose-evaluate-accept这一大类（范式三的变体）；EnvHarness、Prime Agent、MetaCaster不属于三范式之一，而是把Harness自进化的思路迁移到了新对象：环境、权重通道、非编码域。所以"三范式"指改进者是谁的三种立场，"六系统"是这三种立场及其迁移的具体实例，两者不是一一对应。
PART 02
三范式演进：人工工程 → Meta-Harness → Self-Harness
前面把Harness推到了"值得被单独、系统化优化"的位置。接下来的问题是：谁来改、改什么、改完靠什么保证它真的变好。三个范式递进地回答这三个问题：谁来改Harness、改什么、需要什么外部资源，三者逐级不同。下图把三种范式放在一张图里对照：人工工程由人改、Meta-Harness由外部更强Agent改、Self-Harness由模型自己改。
图 1：三种Harness改进范式（人工工程 → Meta-Harness → Self-Harness）。来源：Self-Harness论文。
2.1 范式一：人工工程
最朴素也最普遍的范式：人类工程师读失败轨迹、改提示、调工具配置、补恢复逻辑。从ReAct的提示模板到Claude Code这类产品级Harness，都属于这一类。它的好处是直接、可控，工程师的领域知识能精准插到具体环节。但它有两个结构性短板：一是不随模型多样性扩展，为每个新模型重写Harness的成本随模型数量线性增长；二是难以系统化验证，一次人工修改有没有泛化、有没有在某类任务上造成回归，多半靠经验判断而非回归测试。当模型数量和任务复杂度一起涨，这条路的边际成本越来越高。
2.2 范式二：Meta-Harness——把Harness当可搜索的代码
Meta-Harness把Harness优化从"人工调参"升级为"outer-loop搜索Harness代码"。它的核心机制是：跑一个coding agent当proposer（即负责提出Harness编辑的那个角色，下文也用"optimizer/evolver"指代它），让它去改Harness的源码，改完拿去评估，把"提议的代码 + 执行轨迹 + 分数"全量存进一个filesystem，下一轮proposer再读这个filesystem提出新版本，如此循环。整个搜索循环见下图：
图 2：Meta-Harness搜索循环，proposer通过filesystem访问全部历史候选的源码、轨迹、分数，提出新Harness，评估后存回filesystem。来源：Meta-Harness论文。
关键设计在怎么给proposer喂历史经验。文本优化器（OPRO、TextGrad一类）之所以不匹配Harness工程，是因为它们把反馈压得太狠，要么无记忆、只看标量分数，要么只给当前artifact一段短文本反馈。Meta-Harness的判断相反：Harness搜索产生的经验量很快超过上下文窗口，proposer必须自己决定读哪些历史、直接和代码库交互来验证编辑。所以它不给压缩后的per-candidate摘要，而是把全部历史候选的源码、轨迹、分数原样放进filesystem，让proposer检索。实测中，proposer中位每轮读82 个文件，它确实在主动检索、而非被动读摘要。
这条路证明了"丰富访问历史经验"能让自动Harness工程跑通：文本分类上比SOTA上下文管理系统高7.7 个百分点且只用其 1/4 的上下文token，检索增强数学在 200 道IMO级题目上跨 5 个held-out模型平均高4.7 个百分点，agentic编码的TerminalBench-2 上超过最好的人工基线Harness。但Meta-Harness仍有一处关键依赖：那个当proposer的coding agent是外部的，它站在目标Harness之外，去改别人的Harness。这就埋了三个问题：外部optimizer可能很贵；对前沿模型可能根本不存在"更强"的外部代理可用；更关键的是，外部optimizer不一定对齐目标模型的真实失败模式，改的方向可能偏。
2.3 范式三：Self-Harness——让模型改自己的Harness
Self-Harness把这个改进循环内化进目标agent自身：同一个固定模型M，既当执行者也当proposer。“we invoke the same fixed model M with current harness h_t in a proposer role”，不引入外部、更不引入更强代理。这是和Meta-Harness的硬分界：改进者就是被改进者。整个循环的总览见下图：
图 3：Self-Harness一轮优化循环总览，当前Harness跑出执行轨迹、聚类成失败模式、同一模型以proposer角色提出有界编辑、回归门验证后接受或拒绝。来源：Self-Harness论文。
它把这个自改进循环拆成三段。
第一段Weakness Mining：在当前Harness下跑模型收执行轨迹，但不是把失败当孤例。它按一个verifier-grounded的失败签名 φ=(c, q, m) 给失败聚类：c是终端验证器拒绝的原因（超时、缺产物等），q是相关agent行为的因果状态，m是轨迹暴露的可复用机制。两条失败即使验证器结果相同（比如都超时），若underlying agent行为不同，也会被分到不同簇，因为需要的Harness改动不同。这一步的目的是把"表面症状"和"可复用的失败机制"分开，让后续改动能对症到机制而非症状。
第二段Harness Proposal：还是那个固定模型M，现在以proposer角色拿到一个有界的提议上下文：当前Harness的可编辑surface、第一段挖出的失败模式、应保留的通过行为、此前试过的编辑摘要。它并行生成K条候选编辑，每条必须绑一个主要失败机制、映射到一个具体的可编辑surface，且彼此materially distinct（不能只是换个说法改写同一簇）。多样性跨分支、最小性在分支内，每条编辑只动它要解决的那个机制所需的surface，不碰无关部分，也不重写整个控制架构。
第三段Proposal Validation：候选不直接采纳，要过回归门。把当前Harness和每个候选Harness都在held-in和held-out两个split上重评，acceptance rule是且
且
，至少在一个split上提升，且另一个不退化，才promote。只拿一个split换另一个split的提议被拒，哪怕总通过数涨了。随机评估时重复跑再按规则聚合，降低单次幸运run把坏改动扶正的概率。多个兼容候选（改动surface不重叠、互不冲突）同轮通过就合并进下一版Harness，被拒的记进日志但不改当前Harness。每条transition都记下改了哪个surface、两个split的结果、重复次数、接受/拒绝，使整条Harness谱系可审计。
这个范式自陈了边界：它研究的是有界编辑、固定benchmark下的自改进，不是开放式自进化；接受的编辑可能仍反映benchmark特定的失败模式；它依赖verifier和trace的质量；更高风险的改动需要比pass-rate非回归更强的接受门。这些边界留到第 5 节展开。
2.4 三范式对照
| 维度 | 人工工程 | Meta-Harness | Self-Harness |
|---|---|---|---|
| 谁来改Harness | 人类专家 | 外部coding agent（proposer） | 目标模型自身（同一M当proposer） |
| 改什么 | 全部Harness设计要素 | 完整Harness源码（端到端搜索） | 可编辑surface的有界编辑 |
| 需要什么外部资源 | 人力 + 领域知识 | 可执行评估 + filesystem经验池 | verifier + held-out回归门 |
| 代表系统 | ReAct、Claude Code、Codex | Meta-Harness | Self-Harness |
从左到右，改动者离目标模型越来越近、改动越来越有界但越来越可验证。Meta-Harness用外部proposer换来了端到端搜索的自由度，Self-Harness用"自改 + 回归门"换来了不依赖外部强模型的可迁移性，代价是改动范围被收窄到可编辑surface。
PART 03
作为对象的Harness怎么被改：补丁即代码、环境侧Harness、跨域迁移
确定了"谁来改"，下一个问题是"改什么、怎么改"。三个系统分别把Harness当作代码补丁、把Harness思路迁移到环境侧、把整套范式搬到非编码域，落点不同，但都守住同一条底线，改完必须用执行验证来接受，而不是看着合理就上。只是"执行验证"的形式各不相同：EnvHarness跑fresh rollout看行为是否被逼出，AutoSaddler在dev集上看泛化，MetaCaster用hinge-loss度量评估整体优化目标。
3.1 AutoSaddler：把Harness当代码做结构化补丁
AutoSaddler和Self-Harness同属propose-evaluate-accept这一大类，但把"改Harness"显式当作一个离线学习问题：用mini-batch的失败信号迭代更新Harness，每个被接受的改动要在dev集上验证泛化。它对"怎么改"的回答浓缩在三句话里，ablation证明这三件事缺一不可。整体迭代流程见下图：
图 4：AutoSaddler迭代优化总览，mini-batch诊断与补丁、验证、反思、进化，产出durable Harness更新。来源：AutoSaddler论文。
第一，深度诊断而非浅层反思。长程任务的失败往往是多步累积的结果，单条trace的浅层反思抓不到根因。AutoSaddler不把诊断和补丁生成分开：Diagnosis-Patch Agent在诊断阶段收集的上下文直接用于生成补丁，让它能充分利用诊断时看到的细节，而不是诊断完丢掉上下文再另起炉灶写补丁。
第二，定向修改而非无约束编辑。补丁是结构化的：agent产出一个结构化patch Δθ，组织进一个补丁分类，而不是无差别地重写Harness。补丁被分作两大组：
| 补丁组 | 作用对象 | 例子 |
|---|---|---|
| Capability补丁（能力） | 增加新能力 | 新增一个工具 |
| Steering补丁（引导） | 改变行为 | 改系统提示、工具描述、hook提醒文本 |
并且禁止访问与评估或benchmark数据相关的代码，把可改的范围圈死。这种约束让每处改动有迹可循、可回溯。
第三，泛化感知选择而非轨迹特化修复。每个补丁不仅要让当前mini-batch涨分，还要在一个独立的validation集上评估泛化。补丁通过后进入Reflection Session，比较前后patch效果、归因它为什么有效/无效/退化、判断它是否泛化到dev set，最后由Evolution Session管理补丁历史（用EvoDAG这个DAG重组先前候选补丁），只留下泛化得动的改动。
这套设计的目标是标题里的那个词，durable updates：改动要持久、能泛化，而不是针对某条轨迹的临时贴膏。结果上，AutoSaddler在GAIA2、SWE-Bench Pro、Terminal-Bench 2.0 三个benchmark上分别比base Harness高9.0、9.6、10.0个百分点，并超过最强自动基线（GEPA和Meta-Harness，GAIA2 上分别为 64.6% 和 61.5%，AutoSaddler达 72.3%）。
效率侧更直观看：在GAIA2 上用约 1000 次任务执行达到 72.3% dev accuracy，而GEPA和Meta-Harness用了约 2800 次才分别到 64.6% 和 61.5%；按轨迹数算，AutoSaddler用 147 条轨迹就达到最佳，Meta-Harness要 1400 条，约 10 倍差距。核心信息是：深度诊断、结构化补丁、泛化选择三个成分都对效率有贡献，砍掉任何一个都会退化成"浅层反思 + 轨迹特化修复"。
3.2 EnvHarness：把Harness思路翻转到环境侧
EnvHarness做了一个关键的翻转。Agent Harness的套路是"冻结LLM、加一层插件把它变成capable agent"；EnvHarness把同一套思路用到交互的另一侧：冻结环境，加一层插件把static environment变成customized environment。同样的"加层不改核心"，对象从模型换成了环境，见下图两侧的类比：
图 5：Agent Harness与EnvHarness的类比，前者用插件把冻结的LLM变成capable agent，后者用插件把冻结的static environment变成customized environment。来源：EnvHarness论文。
为什么有这需求？agent靠和环境交互获取学习信号，可环境是人工搭的、静态的：它对任何Agent都一个样，不管这个Agent有多弱、弱点在哪，也不管Agent已经进步到哪。环境一旦被学透就没东西可教了，也不针对特定Agent的弱点给信号。手工搭新环境又贵：要重写交互逻辑和verifier。
EnvHarness的约束是：所有干预只动标准接口（reset / step / observation）这一层，底层模拟器和原verifier一个字不改。环境之所以可信，就在于它带着ground-truth verifier；连评分都改了，学出来的东西就不可信了。三类插件对应三种"为难方式"：
| 组件 | 改什么 | 例子 |
|---|---|---|
| Stage | 改起点（reset后执行一串动作改场景） | 把杯子藏进抽屉逼策略先搜索 |
| Contract | 改交互（动作前置条件、增删遮蔽观测） | 没拿杯子不许清洗，堵捷径 |
| Chain | 连接多个基础环境拉长episode | 任务完成后追加一段延续目标 |
组件定义里没有"策略"这个变量，所以同一套组件能原样套到任何策略上，跨策略迁移。下图把三类组件如何包裹base environment的标准接口画在一起：底层的Environment完全冻结，Stage、Contract、Chain各自在外层包一层，只改写各自关心的接口方法（起点 / 交互 / 跨环境衔接），原生verifier一路保留。
图 6：EnvHarness三类组件如何包裹base environment的标准接口（reset / step / obs），底层环境冻结，三类组件各在外层包一层、只改写各自关心的方法。来源：EnvHarness论文Figure 3。
但"该为难哪里"得针对某个具体策略的弱点，组件本身策略无关、不能瞎改。EnvRigger把这一步自动化，把策略当黑盒、只看它的执行轨迹，走四步把组件对症到弱点上。整个EnvRigger流程见下图：
图 7：EnvRigger流程，为目标策略诊断弱点、合成候选EnvHarness组件、用fresh rollout验证后接受或迭代修订。来源：EnvHarness论文Figure 4。
▪Observe（观察）：在基础环境里跑策略收轨迹。失败暴露要补什么，成功则标出弱点的边界：哪些能力已经完好、从哪里开始失灵。这步定的是"缺什么"的边界，不是只看失败。
▪Diagnose（诊断）：从轨迹定位根因。比如一个策略"不搜索、直接伸手拿，依赖一条绕过学习的捷径"。诊断不止于"它失败了"，还要定方向：策略挣扎就搭脚手架、简化任务；成功率满格说明环境太松、逼不出弱点，得把环境调更难。
▪Write（写组件）：据诊断对症写组件。针对"不搜索"这条捷径，EnvRigger写一个Contract，在策略没搜索就伸手时阻断拿取动作，逼它去探索。一个弱点可能要多个组件配合（一个Stage改起点 + 一个Contract堵交互）。
▪Validate（验证）：把候选组件套到环境上，跑策略的新rollout看它有没有被逼出缺失能力、且任务仍可解。依据成功率和失败分布做三种裁决之一：接受（逼出能力且可解）、拒绝（任务变不可解或没挑战了）、细化（信号尺度不对）。要细化就把轨迹反馈回流到Write，重复"写-验"循环，直到接受或预算耗尽。
核心就是这条"写-验"循环：只采纳被新鲜轨迹证实有效的东西，而不是"看起来合理就上"。这里有个范围限定：EnvRigger的自动化只覆盖Stage和Contract两类，Chain组件连接多个环境，EnvRigger难以观察被连接环境的内部状态，所以Chain不进自动循环、只在单独分析中考察。反复跑这个EnvRigger loop，就实现策略与环境的持续共进化，性能随定制任务数compound增长，而不是早早plateau。
结果上，EnvHarness在五个基准（具身的ALFWorld、浏览的WebArena、软工的SWE-bench Verified、办公的OfficeQA和SpreadsheetBench）上超过原始环境，held-out任务最高 +9.0 个百分点且交互步数少 9.8%，强化学习设定下最高 +6.5 个百分点。
3.3 MetaCaster：范式迁移到非编码域
前面几个系统都在coding agent上转。MetaCaster把Harness自进化范式搬到了时序预测，证明这不是coding专属的方法论。它先立了一个范式区分：已有的LLM用法要么是LLM-as-Forecaster（预训练LLM加适配器当预测骨干）、要么是Agent-as-Forecaster（LLM agent直接读时序、对话式给预测），MetaCaster走第三条，Agent-as-Engineer：Agent不当预测器，而当"工程师"，为部署目标生成数据、训练并挑选轻量预测器，推理时只用选出的轻量模型。下图把三条范式放一起对照：
图 8：三种用LLM做时序预测的范式对比，(a) LLM-as-Forecaster用LLM当骨干、(b) Agent-as-Forecaster让agent直接预测、© MetaCaster让agent当工程师去训练轻量预测器。来源：MetaCaster论文。
具体到MetaCaster：MGAgent负责按few-shot样本和上下文生成合适数据集，FTAgent用它训练并选出最好的轻量预测器。
关键在于，MGAgent自身的外部Harness被HPAgent（一个meta-harness）优化。HPAgent在outer loop里跑三段：收集MGAgent/FTAgent的性能证据、诊断、编辑Harness参数 θ，并用一个基于hinge-loss的度量评估整体优化目标（生成数据与真实数据间的性能差距），能rollback有害更新、在优化结束时输出最佳 θ。整体框架见下图：
图 9：MetaCaster的Harness优化框架，HPAgent作为meta-harness在outer loop优化MGAgent的Harness，落点是时序预测的轻量预测器训练。来源：MetaCaster论文。
这和Meta-Harness的结构同构：有一个optimizer去改Agent的Harness、改完要评估再接受，但MetaCaster的落点是"比fine-tuning LLM更省"，而且优化后的Harness可跨LLM迁移，下游部署能灵活切换API。意义不在于时序预测本身做得多好，而在于：只要Agent外部有可编辑的Harness结构，自进化范式就能套上去，不必局限于coding agent。
PART 04
打通权重：从Harness进化到轨迹训练下一代模型
前面四个系统都守着同一条边界：模型权重固定，只改外部Harness。这是Harness自进化之所以"安全"的前提，不动权重，就不需要再训、不碰GPU、不冒训崩的风险。但只要把视角拉远一点，一个自然的问题就冒出来：Harness改了一轮又一轮，留下的那些轨迹，能不能反过来训练下一代模型？Prime Agent正是把这条从Harness到权重的通道接了起来。它的整体架构见下图：
图 10：Prime Agent总览，持久root与subagent会话连接daemon、Continual Harness、Agents View和环境，实线传递执行与消息、虚线传递持久状态。来源：Prime Agent论文。
它分两个层次。
4.1 当前层：纯Harness自进化（Continual Harness）
Prime Agent把信息状态分成L0–L3 几层：模型权重是L0，活跃上下文是L1，持久REPL与递归子代理是L2，磁盘上的历史、记忆、技能是L3。这个分层的用意是借了von Neumann架构里"可寻址状态"的概念，模型能读、改、写当前指令之外的、可寻址的状态，而不是只能读当前prompt里的token。Harness自进化主要发生在L3（refinement版本化更新L3 条目），权重不动。分层结构见下图：
图 11：Prime Agent的状态层级L0–L3，L1 与L2 之间的边界区分了上下文内状态和上下文外、可寻址的持久状态，refinement在L3 做版本化更新而权重L0 不动。来源：Prime Agent论文。
除了状态分层，Prime Agent还靠两块机制把"长程、可自改进"撑起来。一块是多代理编排与直接通信：root session可以派生subagent session，subagent还能再嵌套，它们通过daemon的rlm() 调用和handle直接通信、不靠固定的调度图，每个session有自己的生命周期状态（ADMITTED/RUNNING/IDLE/INACTIVE）。这让人能inspect、attach、介入某个subagent而不必跟每一轮交互。编排生命周期见下图：
图 12：Prime Agent多代理编排，root与subagent session通过daemon直接通信，支持嵌套，每个session有独立生命周期状态，人可介入任意子会话。来源：Prime Agent论文。
另一块是长程控制的三种机制，用来支撑多日、多步的执行：Autonomous mode在显式预算内持续turn，每轮后跑一个end-condition测试，过了才停、没过带有限输出继续；Goal把目标跨延续保留，直到Agent自己标记完成；Heartbeats按cron或定时触发turn。三种机制解决"什么时候继续、什么时候算完"的长程问题，配合标准化的persistence/recovery/termination/accounting把Harness失败和模型失败分开计。长程控制机制见下图：
图 13：Prime Agent的长程控制机制，Autonomous mode在预算内跑到通过测试、Goal跨延续保留目标直到完成、Heartbeats定时触发turn。来源：Prime Agent论文。
有了分层状态、多代理编排、长程控制这三块，Prime Agent才能稳定跑长程任务、并把执行证据沉淀回Harness状态。Continual Harness暴露的接口正是干这个的：prompt notes存行为指令，memories存事实，skills打包可执行过程，subagent specifications存可复用角色或分工。它把refinement显式定义成"把执行证据转成版本化状态更新"，有用的计算变成skill，重复的协调模式变成subagent specification，被纠正的假设变成memory或prompt note。每次更新在turn边界应用、记下触发条件和预期效果、给下一轮调用装配补充状态，版本保留provenance、可回滚。refinement补充的是不可改的base prompt，不重写基础policy。
这一层的要点是：自改进把执行证据转成持久的、能改变后续行为的Harness状态，同时模型权重保持固定。这和Self-Harness的propose-evaluate-accept不同：Self-Harness改的是Harness的配置定义文件（怎么声明、怎么控制Agent），Continual Harness改的是运行时持续生长的typed state（prompt notes / memories / skills / subagent specs）。两者一个偏"改配置"、一个偏"改记忆"，但都守住权重不动这条线。
4.2 延伸层：轨迹训练下一代模型
Prime Agent在一处提到了方向性的延伸：它说"产出的trajectory record也为later model generations提供训练数据"。注意这是Prime Agent提出的设想，不是已验证的闭环。它的实测（Factorio上refinement带来持续技术进步、ARC-AGI-3 上Best@1 从 30% 提到 95.5%）都是refinement在当前模型上的结果，不是"训练下一代权重后"的结果。所以这里要区分两件事：Prime Agent的当前层（Continual Harness）权重不动，只是把执行证据转成持久Harness状态并留下trajectory record；"为later model generations提供训练数据"是一条设想中的通道：轨迹可以留给将来训练下一代模型，但Prime Agent自己并没有在线改权重，本文也未见这条环已闭合的证据。
如果这条设想真的走通，意义在于把Harness自进化从"非参数层面的改进"接到"参数层面的改进"：Harness变强 → 留下更好的轨迹 → 轨迹训练下一轮权重 → 更强的模型又跑出更好的轨迹。但目前这一步还停留在设想，环没有闭合，自改进仍受限于"只改外部"。
更激进的方向是把Harness改进和权重更新放进同一个优化loop。SIA这类早期尝试设计了一个Meta-Agent提初始Harness、一个Task-Specific Agent执行任务、一个Feedback-Agent根据近期轨迹决定"该改Harness还是该改权重"，由一个反馈代理判断瓶颈在哪一侧，再决定把改进预算投到非参数还是参数。
但即便是这类尝试，也还在早期：它把"改Harness"和"改权重"当两个并列的可选项交给一个调度器，没有解决两者之间的因果归因，一个任务失败，到底是harness没配好、还是模型能力不够，Feedback-Agent的判断本身缺乏硬证据。真正闭合这条环，需要的不只是调度，而是能区分"瓶颈在外部脚手架"还是"瓶颈在模型本身"的诊断能力。这恰好是Self-Harness的addressability判据和AutoSaddler深度诊断想要回答的同一个问题。只不过它们的答案目前只服务于Harness那一侧，这也是为什么第 5 节把"区分瓶颈在脚手架还是模型本身"列为尚未回答的边界，而不是已闭合的成就。
PART 05
风险与边界：过拟合、Harness-updating ≠ benefit、谁监督优化器
前面四节把Harness自进化讲成一条越走越顺的路：从人工调到自动搜索，从外部proposer到模型自改，从改配置到改记忆，再到轨迹反哺权重。但这条路每一段都有它没跨过的边界。把这些边界摆出来，比把它写成"前景广阔"更有用。
边界一：过拟合到benchmark特定失败。Self-Harness自己把话说在前头，它研究的是有界编辑、固定benchmark下的自改进，不是开放式自进化；被接受的编辑可能仍反映benchmark特定的失败模式，换一批任务就未必成立。这指向一个真实的张力：acceptance rule用的是held-out split的非回归，能挡住"过拟合到held-in"的改动，但挡不住"过拟合到整个benchmark家族"的改动。更高风险的Harness改动需要比pass-rate非回归更强的接受门，这是Self-Harness自己承认的。AutoSaddler用独立的validation集和泛化感知选择去补这个口，方向一样：改动要在没见过的数据上站得住，才算durable。
边界二：能改好Harness的，不等于能用好Harness。这是最反直觉的一条。Lin et al.（2026）把Harness自进化拆成两种独立能力：Harness-updating（从执行证据产出有用的Harness更新）和harness-benefit（任务执行时真的吃下更新、用得上）。结论两条：第一，Harness-updating几乎不随模型能力变化，Qwen3.5-9B写出的更新带来的增益，和Claude Opus 4.6 写出的相当；第二，Harness-benefit非单调，弱档模型几乎无益（它们连相关Harness artifact都激活不了、或激活了也不照着做），中档模型受益最大，强档模型反而比中档受益少（一个可能解释是强模型已自带更新所提供的行为，边际收益递减，但Lin et al. 是否给出这个归因本文未核查）。
这推翻一个直觉：不是模型越强，Harness自进化越划算。真正的瓶颈不在写更新的那个evolver，而在用更新的那个task-solving agent。对工程实践的硬启示是：把能力预算投到执行agent而不是evolver，便宜模型能写出够用的更新，但执行端不能太弱，否则再好的更新也吃不下。这里有个口径要注意：Lin et al. 的设定里evolver和task-solving agent是可分离的两个角色（用 9B写更新、给Opus用），和Self-Harness"同一模型M既当执行者又当proposer"的设定不同，结论是否原样外推到Self-Harness的"同一M"情形，需要谨慎。
边界三：有界编辑vs开放式自进化。目前所有系统的"自进化"都被一条隐形绳子拴着：改动有界、benchmark固定、verifier可信。Self-Harness改的是已声明可编辑surface的有界编辑，AutoSaddler把补丁限制在结构化分类内、禁止碰评估代码，Prime Agent的refinement补充而不重写base prompt。
这些约束不是保守，是必要，没有有界性就没有可审计、可回滚、可回归测试。但这也意味着，目前没有任何一个系统真正实现了"开放式"自进化（让agent自己决定改哪些surface、改到什么程度、何时停止）。开放式自进化是那条路的终点，现在还没走到。
边界四：谁监督优化器。Meta-Harness用外部coding agent当proposer去改别人的Harness，留了一个口子：这个外部optimizer谁来保证它改的方向对？它不一定对齐目标模型的真实失败模式，这是Self-Harness把循环内化进目标模型自身的主要动机。但Self-Harness把optimizer内化后，问题并没有消失，只是换了形态：当被改进者就是改进者，对同一个失败模式的盲点会被重复继承，这正是质量流程里"同一盲区连续命中即升级"要防的，在Harness自进化里同样成立。
SIA那类把"改Harness还是改权重"交给Feedback-Agent调度的尝试，更把这个归因问题摆到了台面：一个任务失败，到底是Harness没配好、还是模型能力不够，这个判断本身目前缺乏硬证据。区分"瓶颈在外部脚手架"还是"瓶颈在模型本身"，是闭合从Harness到权重那条环必须先回答的问题，而现在它的答案只服务于Harness那一侧。
还有两条边界值得提一句但不展开：自进化全流程依赖verifier和trace的质量，verifier不可信则一切回归门都失效；以及评估成本仍是实际瓶颈：Meta-Harness中位每轮读 82 文件、AutoSaddler在GAIA2 上要跑上千次任务执行，这些不是免费的。
回到开头那个判断：换一套Harness、固定模型，性能能差6 倍。这件事的意义不在于"Harness比模型重要"，而在于它把一个一直被当成"写完即定型"的外壳，推成了可以迭代、可以验证、可以自改进的对象。
这篇文里六个系统做的，就是把这条路的几段铺出来：谁改、改什么、改完怎么验证、能不能接到权重。每段都还没跨过自己的边界：还没解决benchmark特化、还没分清updating和benefit的瓶颈、还没走到开放式自进化、还没回答谁监督优化器。把这些边界当现状坦白出来，比假装已经跨过去更接近这条路的真实位置。
学AI大模型的正确顺序，千万不要搞错了
🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！
有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！
就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！
我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～
