前OpenAI安全副总裁、Thinking Machines Lab联创翁荔,又发新博客了。
这回讨论的是AI自进化,她提出了一条现实路径:
不一定从模型直接改写自己的权重开始,而是先从Harness开始。
这篇博客题为《Harness Engineering for Self-Improvement》。
其中,Harness可以简单理解为模型外部的运行系统,决定模型如何调用工具、管理上下文、读写文件、拆分任务、调用子Agent、验证结果,以及从失败中复盘。
DeepSeek研究员崔添翼也第一时间转发了,还画了重点:
Harness方向的自进化,和模型方向的自进化一样,都是非常可能出成果的方向。
他还提出,Skill就是Harness自进化中比较初级的一种形式:从 prompt层面进行自进化。
博客原文信息量巨巨巨大,请各位看官做好心理准备~
自进化可能先发生在Harness层
翁荔这篇博客讨论的核心概念,是RSI(Recursive Self-Improvement),递归自我改进。
这个概念最早带有很强的AGI色彩,指的是一个智能系统能够改进产生自身智能的机制,从而产生更强的后继系统。
但翁荔在这篇博客里,把这个问题拆得更工程化。
在今天的AI系统里,自我改进未必只意味着模型直接改写自己的权重。
它也可能意味着,模型改进训练流程、研究流程和部署系统,进而帮助下一代系统在真实任务中表现得更好。
△
而Harness,就是部署系统里最关键的一层。
过去谈Agent,常见说法是「LLM+记忆+工具+规划+行动」。
但在翁荔看来,Harness已经不只是早期Agent框架里的几个模块,而是更接近运行时和软件系统设计。
它决定模型如何观察环境、如何行动、如何管理上下文、如何保存状态、如何评估结果,也决定模型能不能在一个长任务里持续迭代。
所以她的判断是:近期更可行的自进化路径,可能并非模型直接重写自己的大脑,而是模型开始优化自己获得答案的方式。
从Context Engineering到Self-Harness,优化层层递进
翁荔梳理了最近一批相关研究,可以看到一个很清楚的趋势:
优化对象正在从上下文、工作流,一步步深入到Harness本身。
递进链条是:prompt→structured context→workflow→harness code→optimizer code。
随着模型越来越强,能被优化的对象也在变得更抽象、更通用。
第一层是Context Engineering。
最基础的问题是:Agent做长任务时,上下文塞得越来越多,很快就会失控。
翁荔在这里提到两个代表性工作:ACE和MCE。
ACE(Agentic Context Engineering),把上下文当成一本会持续更新的「操作手册」,而不是一段越堆越长的提示词。
它靠三个角色配合:Generator负责生成任务轨迹,Reflector从成功和失败的轨迹里提炼要点,Curator把这些要点整理成结构化的条目、增量更新进手册里。
MCE(Meta Context Engineering),则更进一步。
它把「怎么管理上下文」和「上下文里具体放什么」拆成两层优化:外层进化管理上下文的技能,内层再用这个技能去优化具体任务的上下文。
翁荔认为,相比ACE还需要人工设计更新规则,MCE朝「自我管理的记忆」又迈进了一步。
第二层是Workflow Design,解决的是「模型该怎么干活」。
翁荔举了几个例子:
AI Scientist搭了一条从提出想法、写代码、跑实验、分析结果,到写论文、同行评审的完整科研流水线。
ADAS更进一步,把「设计Agent工作流」本身当成一个可以被搜索的优化问题,让一个元智能体不断提出新的工作流设计并接受评估。
AFlow则把工作流表示成一张图,用蒙特卡洛树搜索去寻找更优的图结构。
这条线的递进在于:一开始是人类把任务流程工程化,后来是模型参与设计流程,再后来,流程结构本身也进入搜索空间。
也就是说,优化对象不再只是单个prompt,而是整个Agent如何组织行动。
第三层是Self-Improving Harness。
到这一层,模型不只是使用Harness完成任务,而是开始分析Harness哪里不好,并提出对Harness的修改。
翁荔重点提到Self-Harness这类工作,它的循环非常清楚。
第一步是Weakness Mining(弱点挖掘)。
系统先收集Agent执行任务时留下的轨迹,包括工具调用、错误日志、失败结果、验证器反馈等。然后从中挖出反复出现的失败模式。
比如,模型总是在某类任务里遗漏文件,总是在某种测试失败后重复尝试无效修复,或者总是在上下文变长后丢掉关键约束。
第二步是Harness Proposal(Harness提案)。
模型基于这些失败模式,提出对Harness的小范围修改。
重点在于「小范围」和「可验证」。
模型能看到的信息包括:当前Harness里哪些地方可以改、具体的失败模式、哪些「正确行为」必须保留、以及之前已经尝试过的修改记录。
提案要尽量聚焦在能被小范围改动解决的、可复现的问题上,而且不同提案之间要保持差异化。
第三步是Proposal Validation(提案验证)。
候选修改不能直接合入,而是要经过测试验证。只有确认它确实提升表现,并且没有引入明显回归,才会成为下一版Harness的一部分。
翁荔提到,这套流程在MiniMax M2.5、Qwen3.5、GLM-5等不同模型上跑Terminal-Bench-2时,确实学出了针对不同模型薄弱点、各不相同的Harness配置。
不过她也直接指出隐患:一旦允许程序自己修改系统层代码,抽象边界就有被打破的风险,权限控制和安全层必须留在这个循环之外,reward hacking的老问题依然存在。
此外,翁荔还进一步提到了Evolutionary Search(进化搜索)。
如果说Self-Harness更像是从失败中修补自己的工作系统,那么进化搜索则是把Harness直接变成一个可搜索对象。
它的逻辑更像自然选择:
先生成多个候选Harness,让模型基于已有版本做修改,再用benchmark或验证器评估表现,留下更好的版本,淘汰较差版本,然后继续下一轮。
她还特别提到DGM(Darwin Gödel Machine):直接让一个coding agent去修改自己的Harness代码仓库本身。
实验里,用Claude 3.5 Sonnet做基座模型,从简单的初始配置出发,DGM进化出来的agent效果惊人:
在SWE-bench Verified上的表现从20%提升到50%;
在Polyglot上从14.2%提升到30.7%;
达到甚至超过了人工设计的agent。
这说明,即使不动模型权重,Harness本身也已经可以成为能力提升的搜索空间。
不过,这类方法更适合代码、算法、GPU kernel等可自动评估的任务。
如果任务涉及科研品味、产品长期质量、复杂组织协作,评估就会慢得多,也模糊得多。
Harness会变强,但依然有边界
翁荔并不认为Harness是替代模型训练的路线,她的判断更像是二者互相强化。
足够成熟的Harness能让模型自我改进的研究循环跑起来;而更聪明的模型又能防止Harness被过度设计、保持系统的可持续性。
长期看,Harness的很多改进最终可能被「内化」进模型本身的行为里——就像提示词工程的手动技巧,随着模型的指令跟随和推理能力变强而逐渐没那么重要了。
但「说清楚目标、约束、上下文、评估标准」这件事本身,从来没有消失过。
不过,她也没有回避,实现RSI这条路上目前存在的瓶颈:
评估器太弱太模糊。现在能跑通自我改进循环的,基本都是写代码、解数学题这类有明确、快速、客观反馈的任务。而研究品味、创新性、长期科研价值,几乎没法量化。
上下文和记忆的生命周期问题。任务越自主、越独立,需要管理的记忆就越多,这件事翁荔认为未来可能会成为智能本身的一部分,而不只是停留在软件系统层面。
△
负面结果容易被忽视。研究者天然更愿意发表成功的结果,模型在海量以成功案例为主的数据上训练,可能不太擅长判断什么时候该放弃一个假设、该如实报告一次失败。
多样性坍缩。进化和强化学习类的循环容易反复利用已知的高回报模式,如果没有额外机制去防止,种群会逐渐坍缩成同一种方案的变体。
Reward hacking。自我改进循环会优化给定的任何信号——奖励来自单元测试,模型可能就去过拟合测试;来自评委模型,就可能学会针对性地「讨好」评委;来自榜单分数,就可能去利用榜单本身的漏洞。
长期健康和短期成功之间的矛盾。以coding agent为例,它们已经能实实在在提升软件工程的日常生产力,但优化目标大多还是短期的——能不能把眼前任务做完,而非能不能保护一个由成百上千工程师共同维护的代码库的长期健康。
可维护性、权责边界、迁移成本、未来的调试负担,这些标准的沙盒训练基本还照顾不到。
人类的角色。翁荔的认为:人类不会被踢出循环,而是要往「环外」移动——在合适的时机、合适的抽象层级上提供监督,这也是系统设计时需要考虑清楚的问题。
过去,大模型竞争主要看参数、数据、算力和推理能力。
但现在,另一个变量已经越来越难被忽略:Harness。
同一个模型,放进不同Harness里,可能表现出完全不同的能力——这件事已然从少数人的观察成为了行业共识。
从翁荔这篇博客也能看出,「AI自进化更现实的工程入口是什么」,将会是下一阶段要讨论的重点。
博客原文:https://lilianweng.github.io/posts/2026-07-04-harness/
参考链接:https://x.com/tianyi/status/2074475185957380379
本文来自微信公众号“量子位”,作者:听雨
