翁荔提自进化从Harness开始，崔添翼附议
速览
翁荔在最新博客中提出“自进化先从Harness开始”的观点，强调AI自进化的起点。DeepSeek创始人崔添翼转发并附议，认为该方向容易产生成果。这一讨论反映了AI领域对自进化路径的探索，可能引发更多关注。
AI 深度解读
背景
前 OpenAI 安全副总裁、Thinking Machines Lab 联合创始人翁荔（Lilian Weng）近日发布新博客《Harness Engineering for Self-Improvement》，提出 AI 自进化（Recursive Self-Improvement, RSI）的一条现实路径：不一定从模型直接改写自身权重开始，而是先从 Harness 层入手。DeepSeek 研究员崔添翼（Tianyi Cui）第一时间转发并附议，强调 Harness 方向的自进化与模型方向的自进化同样可能出成果，其中 Skill 是 Harness 自进化中较为初级的形式——从 prompt 层面进行自进化。
过去，大模型自进化常被赋予强烈的 AGI 色彩，即一个智能系统能够改进产生自身智能的机制，从而产生更强的后继系统。但翁荔在博客中将这个问题拆得更工程化：在今天的 AI 系统里，自我改进未必只意味着模型直接改写自己的权重，也可能意味着模型改进训练流程、研究流程和部署系统，进而帮助下一代系统在真实任务中表现得更好。Harness 正是部署系统中最关键的一层。
核心内容
什么是 Harness
Harness 可以简单理解为模型外部的运行系统，决定模型如何调用工具、管理上下文、读写文件、拆分任务、调用子 Agent、验证结果，以及从失败中复盘。过去谈论 Agent 时常见说法是「LLM + 记忆 + 工具 + 规划 + 行动」，但在翁荔看来，Harness 已经不只是早期 Agent 框架里的几个模块，而是更接近运行时和软件系统设计。它决定模型如何观察环境、如何行动、如何管理上下文、如何保存状态、如何评估结果，也决定模型能不能在一个长任务里持续迭代。
自进化的递进层次
翁荔梳理了近期相关研究，指出优化对象正从上下文、工作流，一步步深入到 Harness 本身，递进链条为：prompt → structured context → workflow → harness code → optimizer code。随着模型越来越强，能被优化的对象也在变得更抽象、更通用。
第一层：Context Engineering
最基础的问题是 Agent 做长任务时上下文塞得越来越多，很快就会失控。翁荔提到两个代表性工作：
- 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 的老问题依然存在。
进化搜索：DGM
翁荔进一步提到 Evolutionary Search（进化搜索）。如果说 Self-Harness 更像是从失败中修补自己的工作系统，那么进化搜索则是把 Harness 直接变成一个可搜索对象。逻辑更像自然选择：先生成多个候选 Harness，让模型基于已有版本做修改，再用 benchmark 或验证器评估表现，留下更好的版本，淘汰较差版本，然后继续下一轮。
她特别提到 DGM（Darwin Gödel Machine）：直接让一个 coding agent 去修改自己的 Harness 代码仓库本身。实验里，用 Claude 3.5 Sonnet 做基座模型，从简单的初始配置出发，DGM 进化出来的 agent 效果惊人：
- 在 SWE