Agent 的实际能力并不只由模型权重决定，还取决于模型外部的一整套运行框架。这套框架负责组织上下文、调用工具、执行动作、维护状态、隔离风险并验证结果，通常称为 Harness。
早期的 Harness 主要由工程师手工配置接口、工具和控制流程。近期研究则开始利用执行轨迹自动优化提示词、记忆和工作流，甚至直接修改 Harness 代码。
研究重点也因此从“如何搭建可用的运行框架”，转向“如何让框架持续改进而不失控”。系统需要记录每次修改，通过可靠评测确认收益，控制优化成本，防止跨任务回归，并在持续变化的开放任务流中保持稳定。
建议读法：先用四篇综述建立 Harness、自进化对象、经验复用和更新机制的互补地图，再用 SWE-agent、OpenHands 与 Agentless 理解设计边界；最后顺着 ADAS、DGM、Meta-Harness、AHE、VeRO、Adaptive Auto-Harness 与 Harness Handbook 进入自动进化及治理主线。
当前展示 16 篇，前 4 篇为综述入口
先用四篇互补综述建立领域地图：Harness 的工程组成、自进化对象、经验复用路径，以及模型参数与脚手架更新的统一分类。
这篇综述把自进化 Agent 拆成三个基本问题：进化什么、何时进化、如何进化。它同时覆盖模型参数、记忆、工具和系统架构，并区分测试时适应、跨任务积累以及标量奖励、文本反馈和多智能体协同等不同机制。对本专题而言，它提供的是“自进化对象”的总分类。
01SURVEY
这篇综述把代码视为 Agent 的运行底座：接口层负责连接推理、行动和环境，机制层承载规划、记忆、工具与反馈控制，多智能体层再通过共享代码工件完成协作、复核和验证。它还把无回归改进、共享状态一致性和高风险操作的人类监督列为 Harness 工程的开放问题。
02SURVEY
这篇综述把 Harness 明确为部署后经验基础设施，解释轨迹如何转化为技能、持久记忆、可验证环境反馈、参数更新与元层控制。它还提出 SIP-Bench 纵向评测协议，并把前向增益、反向保留、改进效率、延迟稳定性与安全非退化纳入同一框架。
03SURVEY
这篇综述将现代 Agent 表示为基础模型与操作脚手架的耦合系统，并把自我改进形式化为自诱导更新算子。它沿基础模型参数更新与脚手架非参数更新两条路径组织文献，再按内在示范、内在反馈和外在经验区分驱动信号，为比较提示、记忆、工具和控制逻辑的更新提供统一坐标。
04SURVEY
理解接口、状态、工具、沙箱、评测与确定性控制如何把同一个模型变成不同能力和可靠性的 Agent。
研究分析 2,853 个 GitHub 仓库中的 coding-agent 配置，归纳从静态上下文到可执行技能、外部集成和子智能体的八类机制。结果显示 Context Files 仍占主导，AGENTS.md 正形成跨工具入口，而 Skills 和 Subagents 的实际采用率仍低。这为专题提供了真实工程生态的基线。
05HARNESS
SWE-agent 把语言模型视为一种新的计算机用户，为它专门设计浏览仓库、编辑文件和运行测试的 Agent-Computer Interface。论文最重要的贡献不是某个提示词，而是证明接口和工具反馈的设计会显著改变同一个模型在软件工程任务中的行为与成功率。
06HARNESS
OpenHands 给出一套完整而可复现的 Agent 平台：事件流保存动作与观察，状态记录成本和委派信息，Docker Runtime 隔离代码执行，AgentSkills 扩展工具，多智能体通过显式动作进行委派，评测框架则统一接入不同任务。它适合用来认识生产级 Harness 的基本部件。
07HARNESS
Agentless 用“定位、修复、补丁验证”三阶段确定性流程挑战复杂 Agent 循环。它表明在部分软件修复任务上，清晰、可解释且成本更低的流程能够达到很强的结果。专题收录它是为了建立一个重要约束：Harness 的目标是可靠完成任务，而不是最大化自主循环和组件数量。
08HARNESS
把提示词、工作流和 Agent 代码从人工设计对象变成可搜索、可修改、可通过执行反馈筛选的候选系统。
论文提出 Automated Design of Agentic Systems（ADAS），让元智能体在代码空间中编写和筛选新的 Agent 系统，而不是只在人工预设的工作流里调参。Meta Agent Search 维护不断增长的候选档案，并利用任务反馈继续发现新的提示词、工具使用方式和控制流。
09HARNESS
Darwin Gödel Machine 让 coding agent 修改自己的代码，并通过软件工程基准检验修改是否真的有效。系统不是只保留一个当前最优版本，而是维护多样化 Agent 档案并沿不同分支继续探索，因此能够积累代码编辑、长上下文管理和同伴复核等新的 Harness 机制。
10HARNESS
AutoHarness 让模型根据环境反馈迭代生成代码约束层，阻止非法动作并把部分决策逻辑固化成可执行策略。论文在 TextArena 游戏中展示了“小模型加定制 Harness”超过更大模型的可能性；它的机制很直接，但实验环境较窄，适合被视为概念验证。
11HARNESS
让 Harness 的代码、工具、中间件、记忆和路由持续演化，同时用版本、轨迹、预算、回滚与跨任务验证约束改进过程。
Meta-Harness 用外层 Agent 搜索 Harness 代码。提出者可以通过文件系统读取过去候选的源码、分数和执行轨迹，避免把历史经验压缩成过短的文字反馈。论文在上下文管理、数学推理和 TerminalBench-2 coding agent 上验证了这种端到端自动 Harness 工程。
12HARNESS
AHE 用组件可观测、经验可观测和决策可观测三个层次约束自动进化：每个可编辑部件都有文件表示和回滚点，海量轨迹被整理成可钻取证据，每次修改还要提前声明预期并在下一轮验证。消融结果把主要收益定位到工具、中间件和长期记忆，而非单纯修改系统提示词。
13HARNESS
VeRO 是包在目标 Agent 外层的优化 Harness，负责保存版本快照、限制评测预算并记录结构化执行轨迹；配套 VeRO-Bench 用统一流程比较不同优化器和修改类型。它回答了自进化工程中最容易被忽略的问题：怎样知道一次改动真的更好，并且能够被复现和回滚。
14HARNESS
Adaptive Auto-Harness 关注固定 benchmark 之外的开放任务流：历史持续增长、任务异质且分布会漂移，反复密集更新一个 Harness 反而可能先升后降。系统使用有状态多智能体进化器、Harness Tree 和求解时路由，并在历史缺少信号时保留人类干预接口。
15HARNESS
论文把 Harness 演化前最容易被忽略的步骤单独提出：修改请求描述的是系统行为，代码库却按文件和函数组织，开发者或 coding agent 很难找齐所有实现位置。Harness Handbook 通过静态分析与 LLM 辅助结构化生成行为中心的代码地图，再用 Behavior-Guided Progressive Disclosure 从高层行为逐步定位、验证并同步更新源码位置。
16HARNESS
