文：PaperWeekly
AI 要自我改进，短期内最先被改写的，可能不是模型权重，而是模型外层的 Harness。
AI 如果走向自我改进，第一步会发生在哪里？
很多人会想到模型权重：模型读自己的代码，改自己的参数，训练出更强版本，再继续迭代。但翁荔最新博客讨论的重点，却放在模型外层。
7 月 4 日，翁荔在 Lil'Log 发布《Harness Engineering for Self-Improvement》。这篇长文延续了她一贯的写法，从一批看似分散的研究工作切入，再把问题推到更底层的系统设计。
博客地址：https://lilianweng.github.io/posts/2026-07-04-harness/自动科研、自我改进 Agent、进化式程序搜索，在这里被放进同一条线索中重新审视。
这条线的核心，就是 Harness。
它是围绕基础模型运行的一整套系统，负责任务编排、工具调用、上下文管理、产物存储和结果评估。
模型能力当然重要，但裸模型不会自动变成能长期工作的 Agent。让模型进入真实任务环境的，是外层运行系统。
01、竞争来到模型之外
早期 Agent 框架常被概括为大模型加记忆、工具、规划和行动。但在翁荔这篇文章里，Harness 的范围更大。
Harness 已经不再等同于提示词模板或工具调用接口。工作流、评估、权限、持久状态，都会成为系统设计的一部分。
它要回答的问题也更具体，模型如何观察任务、采取行动、保留状态、检查结果，并在失败后继续推进。
原文把 Harness 类比为操作系统。复杂逻辑被封装在底层，对外只保留简单接口。工具接口、配置协议、上下文管理和权限边界，构成了 Agent 系统的基础层能力。
递归自我改进既可以指模型直接改写自身权重，也可以指模型改进训练流程和部署系统，从而产生更强的后继模型。翁荔这篇文章把重点放在后者，尤其是模型与真实世界之间的部署系统。
02、Agent如何真正跑起来？
代码 Agent 是理解 Harness 最直接的场景。
一个代码 Agent 接到任务后，需要理解仓库、搜索文件、读取上下文、修改代码、运行测试、检查报错，再根据结果继续调整。
循环越长，越依赖稳定的系统来管理状态和行动。
〓 Codex Agent 的基础循环，工具调用结果会进入下一轮模型生成工作流自动化负责把任务持续往前推。常见流程围绕目标循环：计划、执行、观察或测试、改进，直到任务完成。
Karpathy 的 autoresearch repo 是原文给出的例子。关键是模型能否在运行时分析轨迹和失败案例，而不是继续堆长提示词。
文件系统承担持久记忆。长程任务里的实验日志、代码 diff、论文摘要、错误轨迹和历史运行记录，很快会超过上下文窗口。
Harness 不应把所有内容塞进上下文，而应把长期状态写进文件，让模型随时恢复工作现场。
子 Agent 和后台任务处理并行与长程执行。主 Agent 可以探索多个假设、委派独立任务、查看日志、取消失败运行、合并结果。
真正困难的是可检查、可恢复、可追踪。
〓 Coding Agent Harness 的典型循环：观察仓库、读写文件、修改代码、运行测试，并根据错误继续迭代Claude Code、Codex、OpenCode 和 Cursor 风格 Agent 的核心接口已经趋于稳定。常见工具包括文件搜索与读写、shell 执行、LSP 和 git 工具、MCP 与 Skills、网页检索、产物处理、后台任务，以及 Agent 委派。
在工程任务里，模型给出下一步动作，Harness 负责执行、记录和检查，再把结果带回下一轮决策。代码 Agent 让这套外层系统的作用变得很清楚。
03,、先改运行系统
短期内，现实起点不太可能是模型直接重写自身权重，而是先让外层运行系统变得更稳定、更可验证。
任务怎么拆，工具怎么调，上下文怎么存，失败怎么记录，候选改动怎么验证，都可以先进入优化循环。这里优化的不是某一次回答，而是产生回答的运行过程。
模型能力仍然是前提。STOP 相关实验说明，递归结构本身并不够。
Zelikman 等人的实验中，改进后的改进器在 GPT-4 上带来平均下游性能提升，但在 GPT-3.5 和 Mixtral 等较弱模型上出现退化。
基础模型决定上限，Harness 决定这些能力能否稳定转化为任务执行。
提示词工程提供了一个参照。很多手工提示技巧后来被指令微调和模型推理能力吸收，但目标、约束、上下文和评估并不会消失。
Harness 也可能经历类似过程。部分技巧会被模型内化，外部工具和上下文接口仍会保留下来。
04、把Harness变成优化对象
原文把这条变化概括为一条递进线：
提示词 → 结构化上下文 → 工作流 → Harness 代码 → 优化器代码
第一步是上下文工程。简单地把所有工具返回和模型输出追加进上下文，很快会失控。
ACE 把上下文视为持续演化的 playbook，而不是越写越长的提示词：Generator 产生任务轨迹，Reflector 从成功和失败中提炼经验，Curator 再把这些经验整理成结构化条目，更新到上下文里。
〓 ACE 将上下文组织成持续更新的 playbookMCE 把上下文管理机制也纳入优化。Meta-Harness 则改到 Harness 代码本身：信息如何存储、如何检索、如何呈现给模型，不再只靠人工手写规则，也可以变成被搜索和修改的系统逻辑。
接下来是工作流。AI Scientist 展示了专家设计的 Harness 如何串起选题、代码、实验、写作和评审；ScientistOne 则把可验证性放在核心位置，要求引用、数值、方法和结论都能追溯到证据来源。
工作流一旦复杂起来，手工设计很快会遇到组合空间问题。ADAS 把 Agent 设计本身变成优化问题。
元 Agent 不再只执行任务，而是生成新的工作流代码。候选工作流经过评估后，表现好的被留下，继续进入下一轮搜索。
到 AFlow，工作流不再只是人工写好的流程，而被拆成一张可搜索的图：节点是一次大模型调用，边是由代码实现的操作逻辑。
这样，系统就可以用 MCTS 在不同工作流之间搜索，而不是只依赖人手调流程。
〓 AFlow 将 Agent 工作流表示为图，并在候选工作流树上搜索更优结构到 Self-Harness，修改对象从工作流继续往下走，进入 Harness 本身。
只要提示词、工具调用、子 Agent、控制流、记忆和评估逻辑都写进代码，Harness 就不再只是运行环境，也变成了一段可修改的系统代码。
Self-Harness 的核心，是提出候选、验证效果，再决定是否合并。
系统先用当前 Harness 运行任务，收集执行轨迹并聚类失败模式。再让同一模型查看这些失败案例，提出范围受控的 Harness 修改方案；最后在已用任务上检查弱点是否修复，再用留出任务检查是否引入新问题。
只有不带来退化的候选改动，才会合并进下一版 Harness。
〓 Self-Harness 通过弱点挖掘、候选修改和验证来更新 Harness在 Terminal-Bench-2 上，Self-Harness 还能为不同基础模型学到模型特定的 Harness 指令，并提升留出任务上的通过率。
Agent 不只是用 Harness 完成任务，也开始参与修改自己运行所在的 Harness。
但边界也很清楚，如果程序被允许编辑类似操作系统的部分，抽象边界会被打破。可编辑区域必须被正确设计，权限控制和安全层应位于这个循环之外。
进化搜索进一步扩大了可尝试的候选空间。Promptbreeder、GEPA、AlphaEvolve 等工作，都把候选方案放进可评估的搜索空间。
AlphaEvolve 将候选程序存入池中，由固定大模型生成代码补丁，不断评估候选程序，保留成功版本，逐步发现更优解。
〓 AlphaEvolve 通过候选程序池、大模型修改和评估循环持续寻找更优程序DGM 则直接面向可编辑的 Harness 代码库，让代码 Agent 修改自己的 Harness。
系统从一个代码 Agent 池开始，每轮根据性能和已有子代数量选择父代；被选中的 Agent 查看自身评测日志，修改 Harness 代码库，生成新版本；新 Agent 经过评估后，表现足够好才会加入池中。
在 Claude 3.5 Sonnet 作为基础模型、初始 Harness 配置较简单的实验中，DGM 发现的 Agent 在 SWE-bench Verified 上从 20% 提升到 50%，在 Polyglot 上从 14.2% 提升到 30.7%。
原文将其概括为固定模型下的 Harness 演化。
这类方法适合候选方案容易自动评估、适应度容易量化的任务，比如矩阵乘法、GPU kernel 优化、算法竞赛和数据中心调度。进入评估慢、标准模糊、依赖启发式判断的领域，计算效率和有效性都会成为问题。
05、难点回到评估
Harness 演化改变的是模型外层的非参数系统。更完整的自我改进，还会触及模型权重。
SIA 是一个早期尝试。它把 Harness 改进和模型参数更新放进同一个优化循环。
系统包含三个角色：元 Agent 提出初始 Harness，任务 Agent 执行任务，反馈 Agent 根据近期轨迹决定下一轮更新 Harness，还是更新模型权重。
〓 SIA 让反馈 Agent 在 Harness 更新和模型权重更新之间做选择SIA 的结果很难直接归因。实验里，任务 Agent 明显弱于元 Agent 和反馈 Agent 使用的模型，基线也偏弱。训练稳定性和 Goodhart 效应仍是绕不开的问题。
真正棘手的是评估。
AI Scientist 一类工作已经展示出，专家设计的 Harness 可以协调自动科研流程中的大部分环节，包括想法提出、代码编写、实验运行、结果分析、论文撰写和评审。
但论文生产不等于科学发现。系统可以写出看似可信的论文，同时仍然存在伪造引用、实现漂移、实验结果薄弱等问题。
〓 AI Scientist 展示了自动科研 Harness 覆盖选题、实验、写作和评审的流程Trehan 和 Chopra 的研究也给出类似提醒。他们让大模型从研究想法走向论文，在世界模型、多智能体强化学习、AI 安全与对齐三个方向做实验。
最终只有 4 个想法被人类专家选中进入完整流程，其中只有 1 个完整执行成论文。
实验里出现的失败模式包括偏向训练数据中的默认做法、执行压力下的方法漂移、长程记忆退化、过度乐观、领域判断不足，以及科研判断力薄弱。
评估问题还会继续放大。开放研究任务往往缺少快速、精确的验证器。
科研判断、问题价值、长期影响，很难被单一分数稳定刻画。演化和强化学习循环还容易利用已知高奖励模式，带来多样性坍缩。
如果奖励来自单元测试，Agent 可能过拟合测试；如果奖励来自评审模型，系统也可能学到奖励劫持（reward hacking）。
以代码 Agent 为例，完成当前任务并不等于维护好长期演进的代码库。可维护性、迁移成本、向后兼容和未来调试负担，很难被短期评测完整捕捉。
评估器和权限控制很可能不能放进 Harness 自我进化循环内部。更稳妥的设计，是用留出测试、轨迹审计，以及关键节点的人类审查来约束系统。监督能否规模化、自动化到什么程度，仍然是开放问题。
从 ACE 到 DGM，变化已经很明显。Agent 不只是在 Harness 里完成任务，也开始修改 Harness 本身。
短期内，AI 自我改进很可能先从 Harness 开始。至于 Harness 能改到什么程度，最终取决于我们能否判断每一次改动到底提升了系统，还是只优化了某个脆弱的分数。
·
