ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

Harness自进化全景:三种范式与六个系统的实现思路

2026/8/30 4:47:52 拓冰建站 浏览量
Harness自进化全景:三种范式与六个系统的实现思路 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提出新版本如此循环。整个搜索循环见下图图 2Meta-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——让模型改自己的HarnessSelf-Harness把这个改进循环内化进目标agent自身同一个固定模型M既当执行者也当proposer。“we invoke the same fixed model M with current harness h_t in a proposer role”不引入外部、更不引入更强代理。这是和Meta-Harness的硬分界改进者就是被改进者。整个循环的总览见下图图 3Self-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-HarnessSelf-Harness谁来改Harness人类专家外部coding agentproposer目标模型自身同一M当proposer改什么全部Harness设计要素完整Harness源码端到端搜索可编辑surface的有界编辑需要什么外部资源人力 领域知识可执行评估 filesystem经验池verifier held-out回归门代表系统ReAct、Claude Code、CodexMeta-HarnessSelf-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证明这三件事缺一不可。整体迭代流程见下图图 4AutoSaddler迭代优化总览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-HarnessGAIA2 上分别为 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 agentEnvHarness把同一套思路用到交互的另一侧冻结环境加一层插件把static environment变成customized environment。同样的加层不改核心对象从模型换成了环境见下图两侧的类比图 5Agent 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一路保留。图 6EnvHarness三类组件如何包裹base environment的标准接口reset / step / obs底层环境冻结三类组件各在外层包一层、只改写各自关心的方法。来源EnvHarness论文Figure 3。但该为难哪里得针对某个具体策略的弱点组件本身策略无关、不能瞎改。EnvRigger把这一步自动化把策略当黑盒、只看它的执行轨迹走四步把组件对症到弱点上。整个EnvRigger流程见下图图 7EnvRigger流程为目标策略诊断弱点、合成候选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-ForecasterLLM agent直接读时序、对话式给预测MetaCaster走第三条Agent-as-EngineerAgent不当预测器而当工程师为部署目标生成数据、训练并挑选轻量预测器推理时只用选出的轻量模型。下图把三条范式放一起对照图 8三种用LLM做时序预测的范式对比(a) LLM-as-Forecaster用LLM当骨干、(b) Agent-as-Forecaster让agent直接预测、© MetaCaster让agent当工程师去训练轻量预测器。来源MetaCaster论文。具体到MetaCasterMGAgent负责按few-shot样本和上下文生成合适数据集FTAgent用它训练并选出最好的轻量预测器。关键在于MGAgent自身的外部Harness被HPAgent一个meta-harness优化。HPAgent在outer loop里跑三段收集MGAgent/FTAgent的性能证据、诊断、编辑Harness参数 θ并用一个基于hinge-loss的度量评估整体优化目标生成数据与真实数据间的性能差距能rollback有害更新、在优化结束时输出最佳 θ。整体框架见下图图 9MetaCaster的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到权重的通道接了起来。它的整体架构见下图图 10Prime Agent总览持久root与subagent会话连接daemon、Continual Harness、Agents View和环境实线传递执行与消息、虚线传递持久状态。来源Prime Agent论文。它分两个层次。4.1 当前层纯Harness自进化Continual HarnessPrime Agent把信息状态分成L0–L3 几层模型权重是L0活跃上下文是L1持久REPL与递归子代理是L2磁盘上的历史、记忆、技能是L3。这个分层的用意是借了von Neumann架构里可寻址状态的概念模型能读、改、写当前指令之外的、可寻址的状态而不是只能读当前prompt里的token。Harness自进化主要发生在L3refinement版本化更新L3 条目权重不动。分层结构见下图图 11Prime Agent的状态层级L0–L3L1 与L2 之间的边界区分了上下文内状态和上下文外、可寻址的持久状态refinement在L3 做版本化更新而权重L0 不动。来源Prime Agent论文。除了状态分层Prime Agent还靠两块机制把长程、可自改进撑起来。一块是多代理编排与直接通信root session可以派生subagent sessionsubagent还能再嵌套它们通过daemon的rlm() 调用和handle直接通信、不靠固定的调度图每个session有自己的生命周期状态ADMITTED/RUNNING/IDLE/INACTIVE。这让人能inspect、attach、介入某个subagent而不必跟每一轮交互。编排生命周期见下图图 12Prime Agent多代理编排root与subagent session通过daemon直接通信支持嵌套每个session有独立生命周期状态人可介入任意子会话。来源Prime Agent论文。另一块是长程控制的三种机制用来支撑多日、多步的执行Autonomous mode在显式预算内持续turn每轮后跑一个end-condition测试过了才停、没过带有限输出继续Goal把目标跨延续保留直到Agent自己标记完成Heartbeats按cron或定时触发turn。三种机制解决什么时候继续、什么时候算完的长程问题配合标准化的persistence/recovery/termination/accounting把Harness失败和模型失败分开计。长程控制机制见下图图 13Prime 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的配置定义文件怎么声明、怎么控制AgentContinual Harness改的是运行时持续生长的typed stateprompt notes / memories / skills / subagent specs。两者一个偏改配置、一个偏改记忆但都守住权重不动这条线。4.2 延伸层轨迹训练下一代模型Prime Agent在一处提到了方向性的延伸它说产出的trajectory record也为later model generations提供训练数据。注意这是Prime Agent提出的设想不是已验证的闭环。它的实测Factorio上refinement带来持续技术进步、ARC-AGI-3 上Best1 从 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时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】