前OpenAI安全副总裁、Thinking Machines Lab联合创始人翁荔，近日发布了最新博客文章。
本次探讨的核心主题是AI自我进化，她提出了一条非常务实的实现路径：
不必非要让模型直接修改自身权重，而是可以从Harness入手进行优化。
这篇博客的标题是《Harness Engineering for Self-Improvement》。
其中，Harness可以通俗地理解为模型外部的运行系统，它决定了模型如何调用工具、管理上下文信息、读写文件、拆分任务、调用子Agent、验证结果，以及如何从失败中总结经验。
DeepSeek研究员崔添翼也第一时间转发了这篇博客，并划出了重点：
基于Harness方向的自进化与基于模型方向的自进化，都是极具潜力的研究方向。
他还指出，Skill其实只是Harness自进化中较为初级的形式——本质上是从prompt层面进行自我进化。
博客原文信息量非常丰富，请各位读者做好心理准备~
翁荔这篇博客的核心概念是RSI（Recursive Self-Improvement），即递归自我改进。
这个概念最初带有浓厚的AGI色彩，指的是一个智能系统能够改进产生自身智能的机制，从而生成更强大的后继系统。
但翁荔在这篇博客里，将这个问题拆解得更具工程化思维。
在当今的AI系统中，自我改进未必只意味着模型直接修改自身的权重参数。
它也可能意味着，模型能够改进训练流程、研究流程和部署系统，从而帮助下一代系统在真实任务中表现出更优的性能。
而Harness，正是部署系统中最关键的一层。
过去谈论Agent时，常见的说法是「LLM+记忆+工具+规划+行动」。
但翁荔认为，Harness已经超越了早期Agent框架中的几个模块，更接近于运行时环境和软件系统设计。
它决定了模型如何观察环境、如何采取行动、如何管理上下文、如何保存状态、如何评估结果，也决定了模型能否在长任务中持续迭代优化。
因此，她的判断非常明确：近期更可行的自进化路径，或许不是模型直接重写自己的大脑，而是模型开始优化自己获取答案的方式。
翁荔梳理了近期一系列相关研究，可以看到一个清晰的趋势：
优化对象正在从上下文、工作流，逐步深入到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的很多改进最终可能会被「内化」进模型本身的行为中——就像提示词工程的手动技巧，随着模型的指令跟随和推理能力变强而逐渐变得不那么重要。
但「明确目标、约束、上下文、评估标准」这件事本身，从未消失过。
不过，她也没有回避实现RSI这条道路上目前存在的瓶颈：
评估器太弱太模糊。目前能够跑通自我改进循环的，基本上都是写代码、解数学题这类有明确、快速、客观反馈的任务。而研究品味、创新性、长期科研价值，几乎难以量化。
上下文和记忆的生命周期问题。任务越自主、越独立，需要管理的记忆就越多，翁荔认为未来这可能会成为智能本身的一部分，而不只是停留在软件系统层面。
负面结果容易被忽视。研究者天然更愿意发表成功的结果，模型在海量以成功案例为主的数据上训练，可能不太擅长判断什么时候该放弃一个假设、该如实报告一次失败。
多样性坍缩。进化和强化学习类的循环容易反复利用已知的高回报模式，如果没有额外机制加以预防，种群会逐渐坍缩为同一种方案的变体。
Reward hacking。自我改进循环会优化给定的任何信号——奖励来自单元测试，模型可能就会去过拟合测试；来自评委模型，模型就可能学会有针对性地「讨好」评委；来自榜单分数，模型就可能去利用榜单本身的漏洞。
长期健康和短期成功之间的矛盾。以coding agent为例，它们已经能够实实在在地提升软件工程的日常生产力，但优化目标大多还是短期的——能否完成眼前任务，而非能否保护一个由成百上千工程师共同维护的代码库的长期健康。
可维护性、权责边界、迁移成本、未来的调试负担——这些标准在沙盒训练中基本还照顾不到。
人类的角色。翁荔的看法是：人类不会被踢出循环，而是要往「环外」移动——在合适的时机、合适的抽象层级上提供监督，这也是系统设计时需要考虑清楚的问题。
过去，大模型竞争主要看参数、数据、算力和推理能力。
但现在，另一个变量已经越来越难以被忽视：Harness。
同一个模型，放进不同Harness里，可能表现出完全不同的能力——这件事已然从少数人的观察演变为行业共识。
从翁荔这篇博客也能看出，「AI自进化更现实的工程入口是什么」，将会成为下一阶段讨论的重点。