harness自进化，先从脚手架开始：翁荔新博客的工程现实主义
harness自进化，先从脚手架开始：翁荔新博客的工程现实主义
前OpenAI安全副总裁翁荔提出：AI的递归自我提升，可能不始于模型重写自身权重，而始于那层常被忽略的外部系统——Harness。
1. 一个被忽视的真相：模型强，不等于系统强
想象你有一支NBA全明星级别的篮球队（这就是今天的大语言模型），但如果教练只会喊“把球投进”，没有战术板、没有训练计划、没有赛后复盘——这支球队能赢几场？
AI系统面临的正是类似困境。我们花了大量精力训练越来越聪明的“大脑”（模型权重），却很少认真设计它赖以运作的“身体”和“战术体系”。这个被忽视的部分，就是翁荔在新博客中聚焦的核心概念——Harness。
Harness可以理解为包裹在大模型外部的整套运行时系统。它不只是提示词模板或工具调用接口，而是决定模型如何观察环境、调用工具、管理上下文、读写文件、拆分任务、验证结果、从失败中复盘的全部机制。
一个成熟Harness的价值在编程Agent领域已经显现：Claude Code和Codex等产品的核心竞争力，很大程度上不来自模型本身，而来自精心设计的Harness。同一个模型，放进不同的Harness，可能表现出天壤之别的能力——这已成为行业共识。
为什么Harness如此关键？
原因在于模型的“原生局限”。即便是最先进的大模型，本质上仍是一个“无状态”的推理引擎：它每次面对的是一个有限的上下文窗口，无法天然地记住昨天执行的任务，也无法跨会话复用经验。Harness正是填补这一鸿沟的桥梁——它通过持久化的文件系统和工作空间（Workspace），让Agent能够在更长的时间尺度上运作。
# 伪代码：Harness如何扩展模型的有限视野
class AgentHarness:
def __init__(self):
self.workspace = Workspace() # 持久化存储，跨任务保留
self.context = ContextManager() # 动态管理短期记忆
self.tools = ToolRegistry() # 可扩展的工具链
def run(self, task):
# 模型只处理当前上下文
# 但Harness负责把历史经验注入上下文
context = self.context.build(task,
history=self.workspace.get_relevant_experience(task))
action = model.generate(context)
result = self.execute(action)
self.workspace.log(task, action, result) # 沉淀经验
return result
2. 自进化的递进：从Prompt到Harness，从手工到自动
翁荔在博客中梳理出一条清晰的进化路径。理解这条路径，就理解了“自进化先从Harness开始”的逻辑基础。
这条递进链条是：Prompt → 结构化上下文 → 工作流 → Harness代码 → 优化器本身。
第一层：Prompt Engineering（提示词工程）。这是最基础的层面，人类手工编写指令，告诉模型该怎么做。问题是，Prompt是静态的，每次任务都从零开始。
第二层：Context Engineering（上下文工程）。当Agent执行长任务时，上下文越塞越多，很快就会失控。研究者提出了ACE（Agentic Context Engineering）等方法，把上下文当作一本会持续更新的“操作手册”。三个角色配合：Generator生成任务轨迹，Reflector从成功和失败中提炼要点，Curator将这些要点整理成结构化条目，增量更新进手册。更进一步的是MCE（Meta Context Engineering），它把“如何管理上下文”和“上下文里放什么”拆成两层，让一个元智能体去优化管理上下文的“技能”。
第三层：Workflow Design（工作流设计）。解决“模型该怎么干活”的问题。AI Scientist搭建了一条从提出想法、写代码、跑实验到写论文的完整科研流水线；AFlow把工作流表示成一张图，用蒙特卡洛树搜索去寻找更优的图结构。优化对象从单个Prompt扩展到了整个Agent组织行动的方式。
第四层：Self-Improving Harness（自改进Harness）。这是翁荔着墨最多的一层。到这一层，模型不再只是“使用”Harness，而是开始分析Harness哪里不好，并提出修改方案。
Self-Harness框架的运作循环非常清晰：
- 弱点挖掘（Weakness Mining）：系统收集Agent执行任务时的轨迹（工具调用、错误日志、失败结果），从中找出反复出现的失败模式。
- Harness提案（Harness Proposal）：模型基于这些失败模式，提出对Harness的小范围、可验证的修改。
- 提案验证（Proposal Validation）：候选修改必须经过测试，确认确实提升表现且无倒退，才会成为新版本。
这套流程在MiniMax M2.5、Qwen3.5等模型上跑Terminal-Bench-2时，确实学出了针对不同模型薄弱点的Harness配置。
更进一步：进化搜索
如果说Self-Harness是“修补”，那进化搜索就是“生成式探索”。DGM（Darwin Gödel Machine）直接让一个编码Agent去修改自己的Harness代码仓库本身。实验结果令人震撼：在SWE-bench Verified上，从20%提升到50%；在Polyglot上从14.2%提升到30.7%——超过了人工设计的Agent。这意味着，即使不动模型权重，Harness本身已经成为能力提升的广阔搜索空间。
# 进化搜索Harness的简化示意
def evolve_harness(initial_harness, benchmark, generations=10):
population = [initial_harness]
for gen in range(generations):
# 变异：让模型修改Harness代码
candidates = [mutate(h, model) for h in population] + population
# 评估：跑benchmark看表现
scores = [benchmark.run(h) for h in candidates]
# 选择：保留表现更好的版本
population = select_top(candidates, scores, k=5)
return population[0] # 返回最优Harness
3. 现实的边界：Harness不是万能药
翁荔的博客之所以值得认真对待，不仅因为她指出了方向，更因为她没有回避这条路上的坑。
评估器太弱太模糊。目前能跑通自改进循环的任务，基本是写代码、解数学题这类有明确、快速、客观反馈的领域。而“研究品味”“创新性”“长期科研价值”，几乎没法量化。奖励黑客（Reward Hacking）的老问题依然存在：模型会优化你给的任何信号——来自单元测试就过拟合测试，来自评委模型就讨好评委。
安全与权限控制。一旦允许程序自己修改系统层代码，抽象边界就有被打破的风险。翁荔强调，权限控制和安全层必须留在这个循环之外。
多样性坍缩。进化和强化学习类循环，容易反复利用已知的高回报模式。如果没有额外机制，种群会逐渐坍缩成同一种方案的变体。
长期健康vs短期成功。以Coding Agent为例，它们确实能提升日常生产力，但优化目标大多是短期的——能否完成眼前任务，而非保护一个由成百上千工程师共同维护的代码库的长期健康。可维护性、迁移成本、未来调试负担，这些沙盒训练照顾不到。
人类的角色。翁荔的判断是：人类不会被踢出循环，而是要往“环外”移动——在合适的时机、合适的抽象层级上提供监督。工程师的角色从编写具体规则，转变为设计更通用的进化框架。
结语：真正的RSI，可能静悄悄地开始
递归自我改进（RSI, Recursive Self-Improvement）这个概念，过去带有很强的科幻色彩：一个智能系统改进产生自身智能的机制，从而产生更强的后继系统，进而指数级加速。
翁荔这篇博客的贡献，在于把这个宏大概念拉回到了工程现实：自我改进未必意味着模型直接重写权重。更务实的起点，是让模型先学会优化自己获得答案的方式——也就是优化Harness。
这条路的意义在于：它是可验证的、渐进的、风险可控的。每一次Harness的改进，都能在benchmark上被量化评估；每一次迭代，都在为下一代系统积累更优的运行框架。
真正的RSI，可能不会以“模型突然觉醒、重写自身代码”的戏剧性方式到来。它更可能静悄悄地萌芽在一次次Harness版本迭代中，在一次又一次任务轨迹的经验沉淀里，慢慢攒够通往更高阶智能的每一级台阶。
如DeepSeek研究员崔添翼所言：“Harness方向的自进化，和模型方向的自进化一样，都是非常可能出成果的方向。”而翁荔的博客，为这个方向画出了第一张务实的工程地图。