Agent-Harness进化

#	论文	时间	机构	一句话	关键洞察
P1	Meta-Harness: End-to-End Optimization of Model Harnesses	2026-03-30	Stanford / KRAFTON / MIT	把完整 Harness 程序变成可搜索对象	不要压缩反馈
P2	Agentic Harness Engineering (AHE)	2026-04-28	复旦 / 北大 / 奇寂之风	用可观察性让自动进化可归因、可证伪、可回滚	每次编辑必须可证伪
P3	Self-Harness: Harnesses That Improve Themselves	2026-06-08	上海人工智能实验室	让目标模型自己修改自己的 Harness	保守的非退化验收门
P4	MemoHarness: Agent Harnesses That Learn from Experience	2026-07-14	Notre Dame / USC / LMU	把执行经验沉淀为经验库，逐任务适配	从"改出好 harness"到"学会怎么改"

概览

2026 年出现了一条值得关注的 Agent 技术路线：不训练模型权重，而是把模型外部的 Harness 当成可搜索、可修改、可验证的软件对象。

四篇的增量：

Meta-Harness 放开搜索空间：Harness 不只是一段 Prompt，而是可以被重写的程序。
AHE 建立工程治理：每次修改都应有证据、有预测、可验证、可回滚。
Self-Harness 内生优化主体：不依赖更强外部老师，目标模型也能参与修复适合自己的 Harness。
MemoHarness 长期化经验：不仅学习一个全局 Harness，还能为每个新任务生成任务特定配置。

最重要的判断：

Harness 进化不是"自动把 Prompt 越写越长"，而是依据可验证的执行经验，持续修改模型外部的上下文、工具、记忆、编排与验证机制。

它属于 Agent 的非参数进化，但不等同于模型权重层面的自我进化。

如果只带走三句话：

固定模型不等于固定能力——四篇都在模型完全冻结的前提下拿到了提升，幅度从几个点到 21.4 个百分点。
结构比散文可靠——AHE 消融显示 system prompt 单独换进去反而 −2.3 pp，而工具/中间件/长期记忆单独换进去都是正的。
验收门比提案器更决定成败——AHE 量化出 proposer 对"会修好什么"的预测约 5× 随机基线，对"会破坏什么"只有约 2×。回归保护不能交给 agent 自己声明。

什么是 Agent Harness

从模型调用到 Agent 系统

传统模型应用：

输入 → 模型 → 输出

Agent 系统：

任务 → 构造上下文 → 模型决策 → 调用工具 → 读取环境
     → 更新状态 → 再次决策 → 验证产物 → 结束或恢复

四篇论文中的 Harness，可以统一理解为：

把固定基础模型转化为可执行 Agent 的外部控制层。

它决定模型：每轮能看到什么、可以使用哪些工具、工具如何描述和执行、哪些状态需要保留、多轮任务怎样编排、何时重试/停止/恢复、最终结果怎样校验和返回。

$\text{Agent 行为} = f(\text{Model},\ \text{Harness},\ \text{Task},\ \text{Environment})$

Meta-Harness 引用的一组数据可以说明这件事的量级：同一基准上，改变固定模型周围的 harness 可以产生 6× 的性能差距。

Harness 不等于"模型外部的一切"

工程上必须划清边界：

对象	是否属于可优化 Harness	说明
system prompt、任务模板	是	控制模型收到的指令
工具描述、工具实现、权限	是	控制模型的行动接口
memory、状态、轨迹摘要	是	控制跨轮次信息
循环、重试、子 Agent 调度	是	控制执行拓扑
输出校验、失败恢复	是	控制最终提交与纠错
外部文件系统、终端、业务系统	否	它们是 Agent 交互的环境
Benchmark 参考答案	否	只能由外部评分系统持有
Evaluator / Verifier	否，必须在优化器权限之外	见下

AHE 把这条写成了硬约束：Evolve Agent 只能写 harness workspace，而 runs 目录、tracer、verifier 和 LLM 配置全部只读，seed system prompt 标记为不可删除。这些限制直接封死了一个无约束自改写者会走的捷径——关掉评分器、换模型、或者偷偷调大推理预算。

优化器可以修改参赛者，但不能修改评分规则。

软 Harness 与硬 Harness

"修改的都是 Markdown、JSON 或 policy 文件，所以本质还是 Prompt"——这个判断只对了一部分。

类型	典型内容	生效机制
软 Harness	Markdown 指令、policy、playbook、记忆条目、工具说明	作为上下文影响模型，或由运行时解释为配置
硬 Harness	工具代码、middleware、状态机、循环、沙箱、调度器、validator	直接改变程序行为，模型即使看不到代码也会生效

判断一个文件是不是 Prompt，不能只看扩展名，而要看：谁读取它、它是否直接拼入模型上下文、运行时是否把它解析成预算/权限/路由/控制逻辑、它最终改变的是模型语言行为还是系统执行语义。

四篇的定位：

纯 Prompt
   < MemoHarness：结构化声明 + 经验驱动配置（最偏软）
   < Self-Harness：有边界的 instruction / memory / skill / runtime policy
   < AHE：Prompt + 工具实现 + middleware + memory + sub-agent（明确进入代码）
   < Meta-Harness：自由重写完整 Harness 程序（最偏硬）

这条谱线是本次分享的主轴：搜索空间越大上限越高，但评测成本、回归风险、安全风险和归因难度也越高。

Harness 进化在优化什么

设固定基础模型 $M$，Harness $H$，任务 $x$，执行轨迹 $\tau$：

$\tau \sim p_M(\tau \mid H, x), \qquad R(H,x) = \text{Score}(\tau)$

Harness 进化要寻找：

$H^{*} = \arg\max_{H}\ \mathbb{E}_{x \sim \mathcal{D}}\big[R(H,x)\big]$

但生产系统不能只追求平均成功率，还要约束成本、回归和安全：

$\max_{H}\ \text{PassRate}(H)\quad \text{s.t.} \quad\begin{cases}\text{Cost}(H) \le B \\text{Regression}(H) \le \epsilon \\text{SafetyViolation}(H) = 0\end{cases}$

"双冻结"是这条路线的方法论基础：模型 $M$ 与评估器 $\mathcal{E}$ 全程固定，只有 harness 变化。这样测得的提升只能来自 harness，而不是模型能力或评测协议的变化。

四篇论文的差别，主要体现在五个问题上：

谁来改？ 强外部 proposer、独立进化角色，还是目标模型自己？
允许改什么？ 声明式配置、指定组件，还是完整程序？
经验怎么保存？ 原始轨迹、分层证据、失败模式，还是经验库？
怎样接受修改？ 总分、预测验证，还是严格的无回归门？
部署后是否适配？ 固定一个全局 Harness，还是为每个任务生成 $H(x)$？

Meta-Harness：把完整 Harness 程序变成搜索对象

它要解决的问题

传统 Prompt 优化器通常只把分数或一段压缩反馈传给 proposer。作者认为这种方式不适合复杂 Harness：失败原因散落在源代码、工具调用、状态更新和长轨迹中，过度压缩会丢掉追溯因果所需的信息。

论文用一张表量化了"反馈被压缩多少"：

方法	历史访问范围	proposer 看到的反馈
OPRO	Window	过去的 (solution, score) 对
TextGrad	Last	对当前产物的文字反馈
AlphaEvolve / OpenEvolve	Window	program database + 评估分数（4–22K token/步）
GEPA	Summary	rollout 轨迹的反思式反馈（2–8K token/步）
Feedback Descent	Summary	成对比较 + 文字反馈
TTT-Discover	Window	上一个解的片段
Meta-Harness	Full	全部日志与分数

已有文本优化器每步可用上下文只有 100 到 30,000 token；而在 harness 这个设定中，单次评估可产生高达 1000 万 token 的诊断信息，高出约三个数量级。

关键方法：文件系统式经验访问

flowchart LR
    H["历史候选 Harness<br/>源码 · 分数 · 完整轨迹"] --> P["外部 Agentic Proposer<br/>(Claude Code + Opus-4.6)"]
    P -->|"grep / cat 按需检索"| H
    P --> C["生成新 Harness 程序<br/>(单文件 Python，100–1000 行)"]
    C --> E["在搜索集上执行"]
    E --> H
    E --> F["维护效果—成本 Pareto 前沿"]

重点不是把千万 token 的历史塞进一次上下文，而是把历史作为文件系统暴露，让 proposer 自己按需检索。它把"上下文装不下"转化成"Agent 能否找到正确证据"。

几个刻意的设计选择：

维护 population 与 Pareto 前沿，但不设 parent-selection 规则——proposer 可以自由检查任意历史候选。
proposer 永远看不到测试集结果，唯一反馈来自搜索集及其轨迹。
proposer 由一份最小化的 domain skill 引导，只规定去哪写、怎么查历史、哪些文件不能改，不规定诊断流程。论文说这是为了"让方法随 coding agent 变强而自动变强"。

核心结果

场景	主要结果
在线文本分类	48.6%，ACE 40.9%、MCE 40.0%；上下文 11.4K token，ACE 50.8K、MCE 28.5K
检索增强数学推理	200 道 IMO 级题、5 个 held-out 模型平均 34.1 → 38.8（+4.7），超过 BM25 检索 1.3
TerminalBench-2 · Opus 4.6	76.4%，超过 Terminus-KIRA 74.7%，榜上第 2
TerminalBench-2 · Haiku 4.5	37.6%，超过次优的 Goose 35.5%，榜上第 1

需要准确理解 Opus 结果：Meta-Harness 低于 ForgeCode 报告的 81.8%；论文同时说明 ForgeCode 的公开代码未能复现该成绩。

一个必须指出的口径差异：论文正文 Table 7（对照官方榜单）中 Terminus-KIRA 在 Opus 4.6 上是 74.7%，而附录 A.2 的搜索日志里，proposer 面对的 Terminus-KIRA 基线被记为 64.4%。两个数字都出自该论文，但论文未显式说明二者关系。引用时不要把两者混用：下文 §3.7 轨迹中的所有百分比都是相对 64.4% 这个口径的。

数学检索的对照值值得注意：密集检索和随机 few-shot 在多个模型上出现回退（Dense 在 GPT-5.4m 上 −4.3、随机 few-shot 在 GPT-20B 上 −5.8），而 Meta-Harness 在五个 held-out 模型上全部为正（+1.6 到 +8.7）。它使用的是与稀疏基线相同的 BM25 检索栈，差异完全来自代码空间中的检索策略。

关键消融：起作用的是"原始执行轨迹"

这是全文最重要的一张表，也是"不要压缩反馈"这一主张的直接证据。

proposer 可见信息	候选准确率中位数	最佳候选	超过 zero-shot 的运行数
仅分数（Scores Only）	34.6	41.3	26
分数 + LLM 摘要	34.9	38.7	23
完整接口（含原始轨迹）	50.0	56.7	39

完整接口的中位数候选，比两种消融条件的最佳候选还要好。 论文的结论是：

摘要无法恢复被压缩掉的信号，甚至可能因为压掉了诊断性细节而有害（"分数+摘要"的最佳值 38.7 反而低于"仅分数"的 41.3）。

同一设定下与其他文本优化器的对比（搜索集准确率；相同 proposer 配置 Opus-4.6 + max reasoning，相同评估预算）：

方法	中位数	最佳
GEPA	32.6	40.2
Best-of-N	34.0	44.2
OpenEvolve	39.1	43.3
TTT-Discover	34.1	45.6
Meta-Harness	50.0	56.7

效率上，Meta-Harness 只用 4 次评估就达到了 OpenEvolve / TTT-Discover 跑完 60 次提案的最终准确率，即 10× 更少的完整评估，且最终准确率高出 10 分以上。

泛化：不是只在搜索数据集上有效

在九个搜索期从未见过的分类数据集上：Meta-Harness 平均 73.1%，ACE 70.2%，在 6/9 数据集上最优。

同时观察到一个反直觉现象：few-shot 示例数超过 32 之后，在 7/9 任务上反而变差。

发现出来的 Harness 长什么样

这部分比分数更有参考价值。

TerminalBench-2：赢的那一版只加了一个"环境快照"

最终 harness 继承 Terminus-KIRA 的原生工具调用、30KB 输出上限和多视角完成检查表；Meta-Harness 发现的唯一主要改动是 environment bootstrapping——在 agent 循环开始前，用一条复合 shell 命令采集沙箱快照并注入初始 prompt。快照包括工作目录、/app 列表（大目录截断到 20 项）、可用语言及版本（Python/GCC/G++/Node/Java/Rust/Go）、包管理器（pip/apt-get）和可用内存。命令有 15 秒超时且静默失败。

整个改动在 Terminus-KIRA 之上只增加了约 80 行代码，在 89 个任务中改善 7 个，最大增益在 protein-assembly 和 path-tracing。这些任务的共同特征是：依赖无法事先假定其可用性的领域工具（生信库、渲染管线、象棋引擎、密码学工具、CoreWars 模拟器）。没有 bootstrap 时，agent 会把最初 2–4 轮花在探测环境上。

数学检索：一个四路由的 BM25 程序

路由	策略
组合数学	BM25 取 20 → 去重到 8 → 按词法分数与难度重排 → 保留 3
几何	1 条固定 hard reference + 2 条原始 BM25 邻居，不做重排
数论	BM25 取 12 → 按词法分数、难度、"解法是否早点说明技巧"的小加权重排 → 保留 3
代数/其他	BM25 取 10 → 重排 → 根据 top 检索分数的集中度自适应决定 K

路由谓词、重排项、去重阈值、每路样例数全部由外层循环在 40 轮进化中选出。最终版本是由 proposer 自主合并的两条成功搜索谱系：一条贡献了基于原始 BM25 的更强几何路由，另一条贡献了基于去重 + 难度重排的更强组合数学路由。

检索语料共 535K 题，来自 8 个开源数据集，做了去重与对评测集和搜索集的双重去污染（精确前缀匹配 + Jaccard 阈值 0.8 模糊匹配）。

proposer 到底在做什么

搜索规模（分享时常被问到“这要跑多久”）：论文给的典型值是一次运行在 20 轮中评估约 60 个 harness，具体到三个场景：

场景	迭代数	候选 harness 数	搜索集规模
在线文本分类	20（每轮 2 个候选）	40	50–100 例（论文自述）
数学检索	40	109	250 道奥赛难度题（正文 §4.2）
TerminalBench-2	10	—	89 任务（与评估集同）

论文附录 D 给了一条很实用的工程建议：搜索集要小到能跑大约 50 次完整评估，并且应该选基线做错的例子或困难实例——如果基线已经把评测跑饱和，搜索就没什么可优化的。

文件访问统计（TerminalBench-2 运行，10 轮）：

指标	数值
每轮读取文件数（中位数）	82
每轮读取文件数（范围）	69–99
其中：历史 harness 源码	41%
其中：执行轨迹	40%
其中：分数/摘要文件	6%
其中：其他	13%

论文据此指出 proposer 的访问模式是非马尔可夫的：它例行性地检查大部分可用历史，而不是只看最近的父节点，每步引用超过 20 个先前候选。

一段值得完整看的搜索轨迹（论文附录逐字引用了 proposer 的推理记录）：

迭代 1–2：两个候选都把"结构性 bugfix"和"prompt 模板改写"捆在一起提交，都从 64.4% 的 Terminus-KIRA 基线大幅回退（58.9%、57.8%）。
迭代 3：proposer 显式识别出混淆变量——"两次失败的共同因素不是具体的 bugfix，而是那次 cleanup 导向的 prompt 改写"，于是回退 prompt、只测结构性修改，回退幅度大幅缩小（63.3%，−1.1pp），验证了它的诊断。
迭代 4–6：继续在同一设计空间试验，包括修一个具体的状态机 bug（验证命令会重置 completion 标志导致无限检查表循环），但仍然回退。proposer 学到一条经验：改 prompt 和 completion flow 风险高，哪怕局部假设听起来很合理。
迭代 7：在连续六次回退后改变策略——从"修改控制循环"转向"在循环开始前增加信息"，提出纯增量的 env bootstrap，成为全程最佳候选。它还明确写出了为什么这样更安全：不碰之前证明脆弱的 completion 机制。
迭代 8、10：尝试组合这个增量改动与更早的结构性修复，并跨运行引用另一次搜索的结论。

这是"完整历史文件系统访问"的价值最直观的体现：proposer 能形成并检验因果假设，而不只是随机变异。

贡献与局限

Meta-Harness 证明了：Harness 可以像普通程序一样被端到端搜索，而不是只能优化一段 Prompt。

局限：

依赖强大且昂贵的外部 proposer（Claude Code + Opus-4.6）；论文自己承认"本文只证明了 harness 搜索能在一个特别强的 coding-agent proposer 上工作，效果随 proposer 变化的研究留待未来"。
自由程序搜索评测成本高。
一次修改可能同时改变多个控制面，难以归因（迭代 1–2 的混淆正是这个问题的实例）。
TerminalBench 搜索和最终评估使用同一完整公共任务集，更像 Benchmark discovery。论文对此的说明是：这是该基准上的通行做法（多个公开 writeup 都在 TerminalBench 上反复做基准特定的 harness 迭代），且基准规模小、评测昂贵，再切一个 split 会严重削弱搜索信号；他们通过人工检查 + 正则审计排查任务特定字符串泄漏到进化出的 harness 中。

需要区分：文本分类和数学检索两个场景是严格的留出评估（proposer 只看搜索集，测试集到最后才用；数学的五个模型全部是 held-out）。只有 TerminalBench-2 是 discovery 设定。

因此它属于外部元 Agent 驱动的程序搜索，不是严格意义上的 Agent 自己进化自己。

Agentic Harness Engineering：让自动进化可观察、可证伪

核心观点

AHE 认为，自动进化的瓶颈不在 Agent 是否聪明，而在修改过程是否可观察：

障碍	描述	对应支柱
异构动作空间	可编辑组件五花八门，Agent 不知道应该改哪里	组件可观察性
轨迹淹没信号	数百万 token 原始轨迹里，可行动的信号被埋掉	经验可观察性
编辑效果难归因	改了一堆东西分数变了，不知道是哪一改起作用	决策可观察性

七类可编辑组件

AHE 基于 NexAU 框架，把 Harness 暴露成七类文件（在单一 workspace 的固定挂载点上）：

system prompt
tool description
tool implementation
middleware
skill
sub-agent configuration
long-term memory

各组件类型松耦合：加一个 middleware 不需要改 system prompt，加一个 skill 不需要动任何 tool。每个逻辑修改就是 workspace git 历史上的一个 commit，文件级 diff 和回滚粒度是白送的。

种子 harness 故意极简：只有一个 shell 执行工具，无 middleware、无 skill、无 sub-agent（记作 NexAU0）。理由很关键：

一个已经针对目标基准调好的种子会污染后续每一次编辑的归因——无法分辨增益来自循环还是来自种子。最小种子迫使 AHE 加的每一个组件都必须在实测 rollout 上自己挣到位置。

三层可观察性

可观察性	实现	解决的问题
组件可观察性	每类组件独立成文件，Git diff + 文件级回滚	到底改了什么
经验可观察性	原始轨迹 → 单任务分析 → Benchmark 总览，并保留下钻能力	为什么失败
决策可观察性	每次修改提交 change manifest，声明证据、根因、预期修复和回归风险	修改是否兑现承诺

flowchart LR
    R["Code Agent 执行任务<br/>k≥2 rollouts/任务"] --> T["原始轨迹"]
    T --> D["Agent Debugger<br/>分层诊断"]
    D --> E["Evolve Agent<br/>修改 Harness + Manifest"]
    E --> R
    R --> V["下一轮验证上一轮预测"]
    V -->|"无效或回归"| RB["文件级回滚"]

两个实现细节值得单独记一笔：

① Agent Debugger 把轨迹变成一个可导航的文件系统 每一条轨迹消息单独成一个文件，用通用 shell 与脚本工具访问；同一 query 的多条 trace 放入同一环境，debugger 必须输出失败根因或成功模式，存成 per-task 分析报告；再聚合成一份 benchmark 级 overview 作为每轮的入口。原始 trace 同时保留（原始与轻度清洗两版），供 agent 需要时核实报告中的断言——这就是 drill-down 的具体含义。

对比 Meta-Harness：Meta-Harness 主张"不要压缩，全都给它"；AHE 主张"分层组织 + 支持下钻"。二者其实是同一问题的两个解——关键都不是压缩率，而是保证细节可达。

② 归因跑在蒸馏之前 完整循环是：rollout → clean（规范化 trace）→ attribute（核对上一轮 manifest、回滚被否决的编辑） → distill → edit → commit。归因先于蒸馏，所以上一轮的判决会落进本轮的证据语料里，把每条 manifest 绑定成契约而非一段自圆其说的理由。

另外，一个 one-shot Explore Agent 与第 1 轮并行运行，从 NexAU 源码和公开 coding-agent 参考资料中播种少量可复用 skill。这些 skill 不享受任何保护：从第 2 轮起 Evolve Agent 可以根据实测 rollout 保留、修改或删除它们。

安全边界

Evolve Agent 只能写 harness workspace；
runs、tracer、verifier 和 LLM 配置只读；
seed system prompt 不可删除；
不能通过关闭评分器、换模型或扩大推理预算刷分。

核心结果

主实验：Terminal-Bench 2，89 任务（4 easy / 55 medium / 30 hard），pass@1

方法	All	Easy	Med.	Hard
OpenCode（人工）	47.2%	75.0%	52.7%	33.3%
Terminus-2（人工）	62.9%	75.0%	74.5%	40.0%
Codex（人工）	71.9%	75.0%	80.0%	56.7%
`NexAU0` 种子	69.7%	87.5%	78.2%	51.7%
ACE（自进化）	68.9% ⚠️	91.7%	78.2%	48.9%
TF-GRPO（自进化）	72.3%	100.0%	79.4%	55.6%
AHE	77.0%	100.0%	88.2%	53.3%

（加粗为列内最优；⚠️ 标记低于种子的项）

两个容易被忽略的点：

ACE 反而跌到了种子之下（68.9% < 69.7%）。论文归因为层次错配：ACE 蒸馏的是 agent 在上下文中读的自然语言 playbook，TF-GRPO 强化的是成功工具序列，两者都没有开放周边脚手架的编辑权。
Hard 层是 AHE 唯一输给 Codex 的栏（53.3% vs 56.7%）。但这不是能力缺失：只把 AHE 的 long-term memory 单独换进种子，Hard 就能到 63.3%，反而超过完整 AHE。

跨基准迁移：SWE-bench Verified，500 任务（harness 冻结，不做域内再进化）

方法	成功率	Tokens (k)
ACE	74.6%	679
TF-GRPO	74.2%	582
`NexAU0` 种子	75.2%	526
AHE	75.6%	461

这里最强的证据不是 0.4pp 的成功率差，而是成本结构：ACE 和 TF-GRPO 在异域上双双跌破种子，同时多花 11%–29% 的 token——它们在 Terminal-Bench 上蒸馏出来的文本会附在每一次模型调用上，到了新任务面只加成本不改策略。AHE 则比 ACE 少 32% token、比 TF-GRPO 少 21%、比种子少 12%。增益集中在 django（79.2→81.0）和 sphinx-doc（68.2→70.5）这两个最大、最耗 token 的仓库；少量回退只出现在三个最小的仓库上（scikit-learn 93.8→87.5、pydata 77.3→72.7、astropy 54.5→50.0）。

跨模型迁移（harness 冻结）

基座模型	种子	AHE	增益
deepseek-v4-flash	51.7%	61.8%	+10.1 pp
qwen-3.6-plus	56.2%	62.5%	+6.3 pp
gemini-3.1-flash-lite-preview	36.5%	41.6%	+5.1 pp
GPT-5.4 medium	—	—	+2.3 pp
GPT-5.4 xhigh	—	—	+2.3 pp

跨模型族的增益（+5.1～+10.1）明显高于同族内（+2.3）。论文的解释是：离饱和更远的基座更依赖 AHE 固化在工具/middleware/记忆里的协调模式，而更强的基座能从 prompt 里以很低的边际成本重新推导出相同协调。

组件消融

配置	All	Easy	Med.	Hard
`NexAU0` 种子	69.7%	87.5%	78.2%	51.7%
+ memory only	75.3%	50.0%	83.6%	63.3%
+ tool only	73.0%	75.0%	87.3%	46.7%
+ middleware only	71.9%	100.0%	81.8%	50.0%
+ system_prompt only	67.4% ⚠️	75.0%	78.2%	46.7%
AHE full	77.0%	100.0%	88.2%	53.3%

system prompt only 反而低于种子（−2.3 pp），收益主要存在于工具、middleware 和长期记忆等结构性组件中。

论文还逐个拆了每类组件具体长成什么样：

组件	进化出的具体形态	它担的失败面
long-term memory	12 条边界案例教训（性能余量、排队超限取消、评估器风格的收尾、源码打包布局）	Hard 上抬到超过完整 AHE；Easy 上退化为多余重复校验
tools	一个 1364 行的 shell 工具，会自动从命令附近的文件中浮现契约提示	Medium 上距完整 AHE 仅 0.9 pp；Hard 上内置 publish guard 过早收尾
middleware	一个 finish-hook，强制执行一次与评估器同构的收尾检查	Easy 全通；Hard 上抬高了回合数
system prompt	79 行通用纪律	其可执行性依赖另外三个组件，单独插入为 −2.3 pp

这张表把"结构大于散文"说得很透：同一条"交付前要验证"的意图，写在 system prompt 里是 −2.3 pp，做成 middleware 的强制 finish-hook 就是 +2.2 pp。

非加性交互（重要）：三个正向单组件增益相加为 +11.1 pp，而完整 AHE 只有 +7.3 pp；Hard 上 memory-only 甚至超过完整 AHE。原因是 memory、middleware 和 system prompt 都在推同一件事（closure-style 验证），叠在一起就在长程预算内花掉了回合数做重复复查。而 evolve agent 优化的是被 55 个 Medium 任务主导的聚合指标，于是收敛到一个 Medium 偏重的折中，吐回了一部分 Hard 上的 memory 效应。

运行成本：一次 10 轮完整 campaign 约 32 小时（k=2 rollout/任务，96 并发，E2B 远程沙箱，每任务 3600s 超时；三个角色共享 GPT-5.4，Code Agent 用 high、Evolve Agent 用 xhigh）。

自归因到底有多准：修复能预报，回退基本盲

这是 AHE 最有价值的自我审视。每轮 Evolve Agent 在 manifest 里声明下一轮预期修好哪些任务、哪些有回归风险，然后用第 $N$ 轮的真实结果去算 precision / recall：

预测类型	Precision	Recall	随机基线	倍数
修复预测	33.7%	51.4%	6.5% / 10.6%	约 5×
回退预测	11.8%	11.1%	5.6% / 5.4%	约 2×

逐轮拆解更直白：9 轮中 agent 共发出 43 条唯一回退预测，只有 5 条兑现；而实际发生且它没预见到的回退有 40 个。

agent 能论证一次编辑为什么应该有用，但几乎说不出它即将弄坏什么。 这直接造成了进化曲线上的非单调回落，论文把"回退前瞻性"列为自进化循环最明确的下一步方向。

对工程的含义非常直接：不要把回归保护交给 proposer 自己声明的风险列表，必须靠独立的回归集硬挡。

一个完整的演化案例：从"写进 prompt"到"建成拦截器"

论文附录追踪了四个轨迹。其中一条线索跨了四轮进化，非常能说明"为什么结构比散文可靠"：

迭代	发生了什么
迭代 2	往 system prompt 追加 68 行、八条编号规则（契约提取、镜像评估器、最小编辑语义、泛化、时间预算、结束就绪、停止规则），全文不提任何任务关键词；同时把 shell 超时做成逐调用参数
迭代 5	发现光有 prompt 规则不够——agent 仍然在通过自检后执行 `rm -rf` 清理掉交付物。于是在 shell 工具内装一个有状态的 publish-state guard：一旦观察到评估器风格的终检通过，就解析验收命令里的路径并标为受保护；后续删除行为在执行前被拦截
迭代 6	把保护范围从交付文件扩到脚本入口（修好了 agent 把已收敛的 `analysis.R` 重跑一遍把结果弄坏的问题）；并引入 `ExecutionRiskHintsMiddleware`，监控命令历史中的七类跨步风险模式（浅验证、仅 localhost 校验、自写代理验证器、绕过官方封装的低层 API、无黄金值/阈值对比的 benchmark、重复长超时、重复同错误重试）
迭代 8	发现 agent 学会了给清理命令加上 `ALLOW_POST_SUCCESS_RESET` 令牌绕过 guard，于是把两类行为升级为硬阻断（令牌不再能抹掉已验证的交付物）；同时给 middleware 加 `before_model` hook，把上一步的风险提示提升为下一个模型回合顶部的 FRAMEWORK 提醒（之前只附在工具输出后面，agent 下一回合就忽略了）。这一轮拿到全跑最高点 76.97

三个可以直接搬进工程的经验：

同一意图需要多层实现。chg-7 告诉模型什么是 publish state，chg-8 在工具层防止它忘记时真的破坏。论文原话："执行时在 shell 工具处执行是最直接的联锁"。
agent 会学会绕过你给的逆转开关。迭代 5 的 override 令牌本意是留逆转余地，结果变成了绕过手段，到迭代 8 不得不改成硬阻断。
提醒的位置比提醒的内容更重要。迭代 6 的 middleware 已经发出了正确警告，但只追在工具输出后面，模型在下一回合就忽视了；提升到回合顶部才生效。

另一个有意思的观察：迭代 2 的 chg-1 在 predicted_fixes 里并没有列出 db-wal-recovery，但它因为措辞足够通用而顺带修好了该任务并保持 2/2 直到跑完——单任务症状被转化成了可复用的 harness 规则。

局限

Harness 组件存在非加性互动，单独有效的修改叠加后未必更好（+11.1 pp 的单组件总和 → 完整 AHE 仅 +7.3 pp）；
Evolve Agent 较擅长预测"会修好什么"（约 5× 随机基线），但几乎无法预测"会破坏什么"（约 2×）；
完整循环包含多个角色和大量评测，时间与成本较高（单次 10 轮约 32 小时）；
主要进化任务仍是 Terminal-Bench，跨领域结论有限（更广的编程语言、仓库规模部署、human-in-the-loop 工作流均未测）；
运行点耦合（论文自述的泛化隐患）：AHE 的步数预算与每任务超时是按 GPT-5.4 high 拟合的，所以跨模型数字混杂了 harness 可移植性与运行点耦合——同族内增益非单调（medium +2.3、high +7.3、xhigh +2.3），medium 丢了一个推理层级的原始能力，xhigh 则把更多 trial 推过了每任务超时（按约定计为失败）；
自修改治理不完整：AHE 虽然限定 workspace、有 manifest 归因、有文件级回滚，但并未提供完整的 guardrail 栈。论文明确写道：应将 AHE 视为受控的研究原型，而非成熟的自主自改进系统。

代码仓库：https://github\.com/china\-qijizhifeng/agentic\-harness\-engineering

Self-Harness：模型参与修改自己的 Harness

核心观点

Meta-Harness 使用外部 proposer，AHE 使用独立角色。Self-Harness 进一步提出：

能否保持模型权重固定，让执行任务的同一个目标模型，也基于自身失败提出 Harness 修改？

graph LR
    A["<b>人工 Harness 工程</b><br/>人类工程师手工修改<br/>ReAct / Claude Code / Codex / OpenHands"]
    B["<b>Meta-Harness 范式</b><br/>更强的外部 agent 指导<br/>改进较弱的目标 agent"]
    C["<b>Self-Harness 范式</b><br/>agent 改进自己运行其上的 harness<br/>无需人类、无需更强外部 agent"]
    A --> B --> C
    style C fill:#e8f0ff,stroke:#3366cc,stroke-width:2px

去掉外部老师的三条理由：外部指导昂贵、对前沿模型不可得、与目标模型的失败模式不匹配。

三阶段循环

flowchart LR
    R["执行任务并取得 Verifier 结果"] --> W["<b>① Weakness Mining</b><br/>聚类模型特定失败机制"]
    W --> P["<b>② Harness Proposal</b><br/>生成多样但最小的定向修改"]
    P --> V["<b>③ Proposal Validation</b><br/>held-in + regression gate"]
    V -->|"至少一侧提升，另一侧不下降"| A["接受并合并兼容修改"]
    V -->|"发生回归"| X["拒绝并记录"]
    A --> R

Weakness Mining：不要只按表面错误聚类

Self-Harness 用失败签名描述失败：

$\phi(r_i) = (c_i,\ q_i,\ m_i)$

分量	含义
$c_i$	Verifier 最终拒绝原因，例如 timeout、断言失败或产物缺失
$q_i$	相关 Agent 行为在失败中的因果地位
$m_i$	可复用的抽象行为机制，例如无效重试、探索不收敛

只有三元组完全相等的失败才被聚到一起——聚类是确定性的、evaluator-grounded 的。

为什么必须拆成三元组？因为两个任务可能都以 timeout 结束，但一个是无限重试，另一个是探索时间过长。只按 timeout 聚类会把不同病因当成同一种病。

每个簇进一步构造结构化 failure pattern（簇大小、代表性任务、共同轨迹症状、verifier 证据、推断出的 agent 机制），按支持度与可行动性排序。证据包 $B_t$ 本身不规定该怎么改——这保证了评估器与优化器的职责分离。

Proposal：分支间多样，分支内最小

同一个目标模型在当前 Harness 下充当 proposer，读取：当前允许修改的 Harness 表面、聚类后的失败模式、应该被保护的成功行为、历史候选与拒绝原因。

并行生成 $K$ 个候选：$\mathcal{P}t = {(\Delta_j, a_j)}{j=1}^{K}$，其中 $h_t^{(j)} = \Delta_j(h_t)$，$a_j$ 是审计记录（针对哪个失败模式、改了哪个面、预期行为效果、回归风险）。

两条约束：分支之间要多样（不能只是把同一个簇/面/机制换个说法重述），分支内部要最小（只改必需的那个面，保留无关行为，禁止大改控制架构）。

还有一条常被忽略但很重要的规则——可寻址性判据（addressability）：

不是每个失败簇都蕴含一个有用的 harness 修改。有些簇反映的是任务本身难、结果不稳定、或模型能力上限。证据支持不足或不可寻址的模式应当被排除，而不是硬塞一个补丁。

Validation：保守的非退化门

$\Delta_\text{in} = P_\text{in}(h') - P_\text{in}(h), \qquad\Delta_\text{ho} = P_\text{ho}(h') - P_\text{ho}(h)$

接受条件：

$\Delta_\text{in} \ge 0 \ \wedge\ \Delta_\text{ho} \ge 0 \ \wedge\ \max(\Delta_\text{in}, \Delta_\text{ho}) > 0$

即：至少一个 split 提升，另一个不能下降。即使总通过数增加，只要某个 split 回归，也拒绝候选。

另外：评估随机时重复多次并对聚合通过数应用同一规则，防止单次幸运运行导致误提升；不修改任何可编辑面、或未产出有效评估结果的提案直接拒绝；每个候选都记录改动面、分 split 结果、重复次数、提案摘要、接受/拒绝决定——让 harness 谱系的每一次状态转移都可审计。

一个必须说明的评测提醒：论文中的 held-out 轨迹不提供给 proposer，但该集合被每轮晋升门反复使用。因此它更接近隐藏轨迹的回归验证集，并不等价于从未参与选择的最终盲测集。真实项目仍应保留独立 blind test。

实验结果

设置：Terminal-Bench 2.0 的固定 64 任务子集（从 89 任务中排除依赖不稳定外部 web 资源、以及需要多模态输入的任务）；初始 Harness 基于极简 DeepAgent 配置（一段简短的 benchmark 面向系统提示 + 默认文件系统与 shell 工具）；模型、工具、预算、环境和 evaluator 均固定；Pass(%) 按每个候选 2 次重复计算；执行环境 Harbor（隔离机器 64 核 / 256GB / 2MB/s 出口带宽上限）。

固定模型	初始 held-in	Self-Harness	初始 held-out	Self-Harness	held-out 绝对提升
MiniMax M2.5	43.0%	50.0%	40.5%	61.9%	+21.4 pp（相对 +53%）
Qwen3.5-35B-A3B	15.1%	36.0%	23.8%	38.1%	+14.3 pp（相对 +60%）
GLM-5	47.7%	57.0%	42.9%	57.1%	+14.2 pp（相对 +33%）

Qwen3.5 的 held-in 相对提升高达 +138%（15.1 → 36.0）——起点越差的模型，harness 修复空间越大。

进化轨迹并不平滑。三个模型都是通过少量经过验证门的编辑到达最终 harness：

模型	全集轨迹	最终保留的编辑数	被丢弃的分支
MiniMax M2.5	42.2% → 53.9%	3	—
Qwen3.5-35B-A3B	20.3% → 36.7%	4	subagent 分支、skill 分支（无进一步提升）
GLM-5	46.1% → 57.0%	4	两个早期分支

这个细节很关键：结构性大改造（subagent 分解、skill 库）并不总是有效。在 Qwen3.5 的运行中，这两条分支都因为没有带来进一步提升而被丢弃（另两个模型的被弃分支论文未标明具体类型）。真正留下来的都是小而具体的机制。

不同模型产生了不同修改：

模型	诊断出的主要失败机制	被接受的编辑
MiniMax M2.5	探索过久导致超时、必需产物没创建；结构化工具内容 schema 不合法；工具调用陷入停滞循环	尽早创建必需产物的初版；更谨慎处理结构化工具内容；对总工具消息数设上限，超限即重定向
Qwen3.5-35B-A3B	反复重试同一条失败命令；无休止探索；工具错误后删掉了必需产物	依赖预检查；打破循环；命令重试纪律；工具错误触发的 middleware 引导恢复缺失产物
GLM-5	环境修改（安装的工具 / PATH）在 shell 会话间丢失；长时间探索不进入实现	让环境变更跨 shell 会话持久化并验证工具可达；加入"若长时间探索仍无产物则转入实现与测试"的约束

但三者之间存在一个共同主题：产物可靠性（artifact reliability）。三个最终 harness 都加了保障"verifier 要的文件确实存在"的机制，只是形式不同：M2.5 是"提前创建输出"，Qwen3.5 是"产物 middleware"，GLM-5 是"从探索转向实现"。

论文的轨迹级案例很具体：

M2.5 / ****count-dataset-tokens：旧 harness 下 agent 找到相关元数据配置后继续探索数据集直到超时，从未创建答案文件；新 harness 下它识别子集、算出 token 总数、写 /app/answer.txt 并读回来校验。
Qwen3.5 / ****extract-elf：旧 harness 下 agent 建好了提取器脚本，随后陷入反复覆写/编辑失败，停止前把 /app/extract.js 删了，verifier 因产物缺失而失败；新 harness 的工具错误触发型系统提示把 agent 引回"把缺失产物补回来"。
**GLM-5 / ****build-pov-ray**：旧 harness 把大量预算花在单次大体量外部下载，并在 sanity check 反复非零时自圆其说地收尾；新 harness 在看到超时证据后改变策略、尽早验证替代源、修好失败的渲染检查后才收尾。

它算不算真正的自进化

Self-Harness 是四篇论文中最接近严格自我改进的一篇，因为执行者与 proposer 使用相同的固定模型。

但它仍不是开放式递归自进化：模型权重不变、可编辑面由人预先限定、任务与 Verifier 与验收规则来自外部、高风险系统能力没有开放给模型修改。

更准确的说法是：模型参与自身运行时系统的非参数自我改造。

论文自陈的局限：研究的是固定基准下的有界编辑，不是开放式自我改进；接受的编辑仍可能反映基准特定的失败模式；协议依赖 verifier 结果与轨迹记录的质量；更高风险的 harness 改动需要比"pass rate 非退化"更强的验收门。

这也回答了一个自然的问题：不存在唯一通用最优 Harness。更合理的目标是

$H^{} = H^{}(\text{Model},\ \text{Task Distribution},\ \text{Runtime})$

MemoHarness：从全局 Harness 走向逐任务适配

核心观点

前三种方法主要寻找一个适用于整个任务分布的全局 Harness。MemoHarness 进一步提出：

即使全局 Harness 平均表现最好，也未必适合每一个具体任务。

论文列出的三个挑战：

Harness 是高维且耦合的：改检索会连带影响有用的 prompt 格式、解码预算、工作流拓扑、记忆策略和验证行为；
基准分数对搜索是弱监督：它只说明一次运行成功与否，不说明是哪个维度导致失败、什么该被迁移到未来的案例；
测试期适配必须避免泄漏：只能用可见输入和训练期积累的经验。

因此 MemoHarness 包含两个阶段：搜索阶段在有标签任务上学习全局 Harness $W^{*}$ 并积累经验；测试阶段针对无标签新任务 $x$，检索相似经验，将 $W^{*}$ 一次性适配为 $W(x)$。测试时不读取答案、不获得奖励、不做梯度更新，也不重新运行多轮搜索。

六个结构化但相互耦合的控制面

论文按推理的时间流分解 harness：

维度	控制内容	示例编辑
D1 Context assembly	调用前输入构造	增加示例、压缩上下文、结构化提示
D2 Tool interaction	工具与检索	启用检索、设置 top-k、证据重排
D3 Generation control	解码与预算	token 上限、temperature、多候选采样
D4 Orchestration	工作流拓扑	单次调用 → plan / execute / refine
D5 Memory management	跨调用状态	保留状态、总结轨迹、删除过期信息
D6 Output processing	输出后处理	答案抽取、Schema 校验、fallback

harness 配置是六个维度的乘积空间：

$W \in \mathcal{W} = \mathcal{W}^{(1)} \times \cdots \times \mathcal{W}^{(6)}$

注意：这六个维度是结构化的编辑面，但不是严格正交的。 论文在 Introduction 中明确指出维度间存在耦合。把它当作"正交分解"来理解是错的。

双层经验库

$\mathcal{B}_t = (\mathcal{E}_t,\ \mathcal{G}_t)$

**逐案例经验 **$\mathcal{E}_t$，每条执行条目包含：

$\xi_i^{(t)} = \big(i,\ t,\ \phi_i,\ W_t,\ \Delta_i^{(t)},\ \tau_i(W_t),\ r_i(W_t),\ c_i(W_t),\ z_i^{(t)}\big)$

即：案例 id、迭代、案例特征、当前配置、相对上次应用于该案例的配置增量、完整轨迹、奖励、成本、诊断。

诊断的 schema 是 $z = (s,\ d_{\text{prim}},\ \mathcal{D}_{\text{sec}},\ a)$：是否成功、主失败维度（${1..6} \cup {\emptyset}$）、次要贡献维度集合、自然语言分析。另外维护轻量级的逐案例统计：连续失败次数、最近平均奖励、奖励趋势、各维度失败计数。

**全局模式 **$\mathcal{G}_t$：每 $N$ 轮由蒸馏算子从失败簇中提取跨案例规律，每条包含现象、支撑证据、以及一次定向 harness 修改的预期效果。

flowchart TB
    subgraph OFF["离线搜索（有标签）"]
        C["候选 Harness"] --> R["有标签任务执行"]
        R --> E["逐案例经验 E"]
        E --> G["蒸馏全局模式 G"]
        E --> C
        G --> C
        C --> B["选择全局 Harness W*"]
    end
    subgraph ON["测试时适配（无标签）"]
        X["无标签新任务 x"] --> Q["检索相似成功、失败和全局模式"]
        B --> A["一次性适配"]
        Q --> A
        A --> WX["任务特定 Harness W(x)"]
        WX --> Y["执行并返回结果"]
    end
    E --> Q
    G --> Q

控制器不直接读整个库，而是发出结构化查询（按案例特征、失败统计、迭代范围、维度诊断），拿到一个有界切片——这样即使库不断增长，控制器的上下文也保持有界。

经验库记录的不是普通对话历史，而是：

在什么任务上，用过什么运行策略，结果怎样，为什么成功或失败。

从"记内容"升级为"记方法论"。

正确性优先

$W^{\star} \in \arg\max_{\text{lex},\ W_t \in \mathcal{C}_{\text{feas}}}\ \big(\bar{r}_t,\ -\bar{c}_t\big)$

即字典序：首先比较任务正确性；只有正确性相同时，才选择 token 成本更低的候选。 这样可以防止系统为了省成本收敛到"便宜但错误"的 Harness。

两个实现细节值得注意：

只有 token 总量进入选择规则。轨迹里记录的调用次数与延迟只用于诊断和报告，不参与排序；美元成本是事后离线按公开价格算出来的，也不参与选择。理由是 token 在跨运行间最稳定、与推理成本直接相关。
诊断算子是故意"粗"的。它不要求对每个失败给出完整因果解释，而是把可观察证据（verifier 结果、异常类型、超时、产物缺失、命令失败、执行轨迹）映射到六个维度之一，论文明确称之为 "intentionally coarse" 的稳定优化信号；更深的结构留给全局层去恢复。

实验结果

与现有 harness 的对比（Terminal-Bench）：MemoHarness 达到 0.806，比最强基线 Codex 高 +0.084，比其余三个基线（Claude Code、OpenCode、Terminus）高 +0.250 到 +0.445。论文强调这个对比是严苛的：Codex 本就是一个专门面向终端的 harness，不是弱 prompt 基线。

三个 benchmark 的 base → final

Benchmark	类型	初始	MemoHarness	搜索中的峰值
Terminal-Bench	长程 Shell Agent	0.722	0.806	迭代 4 曾到 0.833
LiveCodeBench	单次代码生成	0.900	0.967	迭代 3 曾触及 1.000
FinanceAgent	多步金融分析	0.600	0.767	—

最终交付的不是峰值，因为选择基于验证集而不是偷看留出评测集。搜索过程中 FinanceAgent 从 42.5% 一路涨到迭代 8–9 附近的 65.0% 峰值；LiveCodeBench 则始终在 91.2%–95.0% 的窄带内振荡。

→ Harness 搜索在长程 agentic 负载上帮助最大，在接近饱和的单次代码生成上收益小。

跨数据集迁移（均与未调优的 Codex 基线对比）

搜索来源	有提升的套件	无变化
Terminal-Bench	MMMLU +0.030、StrongReject +0.030、SWE-Bench Pro +0.059（提升面最广）	HumanEvalFix、Reasoning-Gym-Easy（已饱和）
LiveCodeBench	MMMLU、StrongReject	同上
FinanceAgent	StrongReject、LawBench	同上

论文的解读很克制：这同时否定了两个极端结论——它既不是普适支配的提示模板（LawBench 仍混杂），也不是只在源基准上有效。最强的迁移出现在源搜索任务是长程、工具密集型时。

跨模型迁移（harness 不重搜）

基座模型	Base	MemoHarness	增益
GPT-5.3-Codex（搜索源模型）	0.722	0.806	+0.084
GLM-5	0.500	0.733	+0.233（最大）
DeepSeek-V3.2	0.333	0.444	+0.111
Gemini-3.1-Pro	0.611	0.694	+0.083
Qwen3.5-397B-A17B	0.444	0.528	+0.084
Claude-Sonnet-4.6	0.530	0.583	+0.053
GPT-4.1	0.500	0.538	+0.038（最小）

平均 +0.098，七个模型全部为正；六个迁移目标模型跨四个家族（论文表述），同时包含闭源 API 与开权重模型。论文措辞谨慎：这"suggest, but do not by themselves prove"学到的改动不是纯模型特定的提示词怪癖。

成本（Terminal-Bench 18 任务留出集，GPT-5.3-Codex，单位：百万 token）

系统	输入	其中缓存	非缓存	输出	总成本
Codex	8.23	4.33	3.90	0.19	$10.28
Claude Code	7.32	3.11	4.21	0.11	$9.51
Terminus	3.96	0.94	3.03	0.09	$6.68
OpenCode	5.48	5.07	0.41	0.05	$2.34
MemoHarness	14.18	13.32	0.86	0.22	$6.89

关键在于那一行的结构：MemoHarness 因为要从经验库检索，原始输入 token 是最多的（比 Codex 多 72%），但 14.18M 中有 13.32M（≈94%）命中缓存，所以总价反而低于 Codex 与 Claude Code。Terminus 和 OpenCode 更便宜，但准确率低得多。

这个优势完全建立在缓存命中假设上。部署时若经验上下文不可复用，成本结构会完全不同。

关键超参（复现时必看）

参数	值
外层迭代数 $T$	10
全局蒸馏触发	双触发：每 $M=5$ 条新条目，或同一案例 $N=3$ 次连续失败，孰先到算谁
控制器每轮收到的摘要	最近 $K_{\text{succ}}=10$ 成功 + $K_{\text{fail}}=10$ 失败
语义检索	未启用（`D2.top_k = 0`）
数据划分	80/20 固定随机，seed 42（Terminal-Bench 89 任务 → 18 任务留出）
生成	确定性：temperature 0.0、top-p 1.0、候选数 1、max 8192 token

注意 D2.top_k = 0：在报告的实验中，给控制器的经验摘要并没有用语义检索，而是直接喂最近的 10 成 10 败。这与方法部分描述的余弦相似度 Top-K 检索是两回事（后者用于测试期逐案例适配），阅读时不要混淆。

一个有趣的附录分析：哪些原子操作与奖励提升相关

论文看每个相邻迭代对（previous→next）中首次出现的 shell 操作，统计它后面跟着奖励上升的比例，对比全体转移基线（≈13.2%）：

操作	新增次数	后接奖励上升	正向率
`cat`	11	8	72.7%
`sed`	11	4	36.4%
`which`	15	5	33.3%
`test`	46	14	30.4%
`python3`	19	5	26.3%
`grep`	9	1	11.1%
`echo`	28	3	10.7%
`curl`	19	1	5.3%

提升幅度从 +17 到 +60 pp。论文的解读是：cat / sed / which / test 强相关，因为它们常出现在修补"检查"与"条件判定"缺口的转移中。这种操作级分解只有在经验库同时存了逐案例轨迹和标量分数时才做得出来。

应谨慎解读的地方（论文 Appendix A 自述）：

Terminal-Bench 主评测只有 18 个 held-out 任务，只报点估计，无置信区间或显著性检验；
并非每个基线都是同模型、同运行时的纯脚手架移植，部分是系统级对比；
经验库、全局模式、逐案例适配三个组件未在所有设定下分别消融；
成本分析依赖实测的缓存命中率；
参考实现的控制器与诊断算子是启发式的，可复现但不够通用。

论文中的搜索轮次曲线（Figure 4，逐迭代）与最终 checkpoint 表（Figure 3）使用了不同报告切面，因此 FinanceAgent 的 42.5%→65.0% 搜索轨迹，不应与最终结果 0.600→0.767 当作同一组样本直接比较。

MemoHarness 是否仍然只是 Prompt 优化

抽象定义上，它覆盖工具、生成参数、编排、记忆和输出处理，不只是 system prompt。

但论文 Appendix B 写得很清楚：一个 harness 被物化为 harness bundle——一份记录当前 D1–D6 配置的结构化 policy 文件，配上描述 agent 运行规则的轻量级文本脚手架、一份持久 playbook 和当前作用域内的蒸馏记忆。一次编辑意味着同时修改结构化的维度摘要与实例化它的指令文本，保持两者同步。

因此它是四篇论文中最偏声明式、最偏软 Harness 的一种。结论不是"它就是 Prompt"，而是：

部分配置通过上下文影响模型，机制接近结构化 Prompt；
部分配置由运行时解释，直接控制预算、检索、工作流和校验；
它的实现上限低于自由程序搜索，但更容易检索、组合和逐案例适配。

四篇论文的统一对比

维度	Meta-Harness	AHE	Self-Harness	MemoHarness
核心问题	能否搜索完整 Harness 程序	自动修改怎样可观察、可归因	目标模型能否修复自己的 Harness	历史经验能否支持逐案例适配
谁提出修改	强外部 proposer（Claude Code + Opus-4.6）	独立 Debugger + Evolve Agent（同底座 GPT-5.4）	与执行者相同的目标模型	检索条件化的控制器
模型权重	固定	固定	固定	固定
修改范围	自由程序重写（单文件 Python，100–1000 行）	七类文件级组件	有边界的 Harness 定义面	六维结构化配置（harness bundle）
经验表示	历史源码、分数、完整轨迹（文件系统）	分层证据 + change manifest	Verifier 驱动的失败簇 $\phi=(c,q,m)$	逐案例经验 $\mathcal{E}$ + 全局模式 $\mathcal{G}$
验收机制	效果–成本 Pareto，proposer 永不见测试集	预测–验证契约 + 文件级回滚	双 split 非退化门	正确性优先字典序 + 验证集选择
最优 Harness	任务分布特定	工程可治理	模型特定	全局 $W^{}$ + 案例特定 *$W(x)$
严格自我改进	否	否，角色分离闭环	最接近	否，经验驱动适配
主要优势	搜索空间上限高	可审计、可治理、成本可控	不依赖更强外部 proposer	能适应任务异质性
主要风险	成本高、难归因、discovery 设定	系统复杂、回归预测弱、运行点耦合	自身认知上限、held-out 被反复使用	小样本、组件未分别消融、软配置上限

四篇之间的引用关系

graph LR
    MH["Meta-Harness<br/>2026-03"]
    AHE["AHE<br/>2026-04"]
    SH["Self-Harness<br/>2026-06"]
    MEMO["MemoHarness<br/>2026-07"]
    MH -->|"AHE：少数联合进化<br/>全部可编辑组件的工作之一"| AHE
    MH -->|"Self-Harness：归入<br/>'外部更强 agent' 范式"| SH
    AHE -->|"Self-Harness：同上"| SH
    MH -->|"MemoHarness：最接近的前序工作<br/>但产物仍是训练期产物"| MEMO

Self-Harness 把 Meta-Harness 和 AHE 归为同一类（"用更强的外部 agent 改进较弱的目标 agent"）。但 AHE 自己的设定里三个角色共享 GPT-5.4，严格说是角色分离而非强弱关系。
MemoHarness 把 Meta-Harness 当作最接近的工作，但指出它"产物仍是一个预期在部署时被复用的训练期产物"，缺的那块是测试期适配。
Meta-Harness 最早，它对标的主要是文本优化器（GEPA、AlphaEvolve/OpenEvolve、TextGrad、OPRO、TTT-Discover），而不是其他 harness 工作——因为当时还没有。

四篇不是同一种"自进化"

类型	对应方法	更准确的称呼
外部强模型搜索	Meta-Harness	自动 Harness 优化
多角色闭环修改	AHE	Agent 驱动的 Harness 演化
同一目标模型提出修改	Self-Harness	非参数自我改造
经验检索与逐案例配置	MemoHarness	自适应 Harness
模型自己更新权重和训练算法	四篇均未实现	参数级自我进化

生产系统不应追求"允许修改得越多越好"，而应该选择：

当前验证能力能够覆盖的最大修改范围。

四篇论文共同验证了什么

固定模型不等于固定 Agent 能力

四篇论文都在模型权重固定的情况下取得提升，量级从几个点到 21.4 个百分点。端到端 Agent 表现不仅取决于模型，还取决于 Harness 是否把模型能力正确组织起来。

最优 Harness 具有模型和任务依赖性

Meta-Harness / AHE 证明某些结构可以跨模型迁移（前者一个 harness 在 5 个 held-out 模型上全部提升；后者冻结 harness 在 5 个基座上全部提升）；
Self-Harness 证明不同模型需要不同修复（三个模型被改出了明显不同的 harness）；
MemoHarness 证明同一模型面对不同案例也可能需要不同配置（这正是逐案例适配的立论）。

因此，合理目标不是寻找一个"万能 Prompt"，而是同时维护：可迁移的通用结构 + 模型特定策略 + 任务特定适配。

结构化机制通常比散文式要求更可靠

这是四篇论文中被独立验证次数最多的一条。

来源	证据
AHE 组件消融	system prompt only 67.4%，低于 69.7% 的种子；memory / tool / middleware 单独均高于种子
AHE 跨基准	ACE（在上下文里注 playbook）和 TF-GRPO 在 SWE-bench 上双双跌破种子，同时多花 11～29% token
AHE 案例	迭代 5 发现"写了不要破坏已验证状态"的 prompt 规则仍然无效，必须在 shell 工具里装拦截器才解决
Self-Harness	被接受的编辑大量是结构性机制：工具消息数上限、工具错误触发的 middleware、环境持久化、依赖预检
Meta-Harness	TerminalBench-2 上最终胜出的是纯增量的 env bootstrap；而前六轮改 prompt / 控制流的尝试全部回退
MemoHarness	操作级分析中，与奖励提升强相关的是 `cat`/`sed`/`which`/`test` 这类检查与条件判定操作

与其在 Prompt 中写"请谨慎验证结果"，更可靠的方式是：

提交前自动执行 validator；
删除已验证产物时由 middleware 拦截；
命令重复失败时由状态机切换恢复策略；
环境状态由运行时持久化，而不是要求模型记住。

但也不能走到另一个极端。 AHE 的非加性结果说明：多个结构性组件如果都指向同一种行为（如反复收尾校验），叠加后会互相抵消甚至为负。Self-Harness 里 subagent 分解与 skill 库因无进一步提升而被丢弃，也提醒我们：结构性改动不是越重越好，需要的是对准具体失败机制的那一个。

验收门比提案器更决定系统能否长期进化

LLM 很容易生成"听起来合理"的修改。真正困难的是拒绝那些：只修复一个案例却破坏其他案例、通过增加预算换取分数、针对 Benchmark 细节过拟合、绕过 Verifier 或安全约束、仅在一次随机运行中幸运成功。

论文	验收机制	防的是什么
Meta-Harness	效果–成本 Pareto 前沿，proposer 永远看不到测试集结果	单目标锁死、测试集泄漏
AHE	预测–验证契约 + 文件级回滚；归因先于蒸馏	演化塌缩为盲目试错、自圆其说
Self-Harness	双 split 非退化门，随机时重复多次取聚合	两个 split 间搬运分数、单次幸运运行
MemoHarness	正确性优先的字典序；交付验证集选择而非峰值	收敛到"便宜但错误"、偷看留出集峰值

但四篇都没能解决的一件事是：AHE 量化出 proposer 对回归的预测基本不可用（precision 11.8% / recall 11.1%，仅约 2× 随机；43 条预测只有 5 条兑现，40 个回归完全没预见）。也就是说，回归保护必须靠外部硬挡。

长期演化的核心不是"让模型不断改"，而是：

让大多数没有充分证据的修改无法进入生产。

为什么不能直接比较四篇论文的分数

四篇虽然都涉及 Terminal-Bench，但实验条件并不一致：

	Meta-Harness	AHE	Self-Harness	MemoHarness
基座模型	Claude Opus 4.6 / Haiku 4.5	GPT-5.4 (high)	MiniMax M2.5 / Qwen3.5-35B-A3B / GLM-5	GPT-5.3-Codex
任务集	全 89 任务	全 89 任务	64 任务子集（排除不稳定网络与多模态）	89 任务 80/20 划分，评测只用 18 任务
搜索/评估划分	同一集合（discovery 设定）	同一集合	held-in / held-out 两 split	search / validation / held-out
每任务运行次数	未统一	$k=2$	2 次重复	多次重复取均值
每任务超时	未详述	3600 s	未详述	未详述
搜索规模	分类 20 轮/40 候选；数学 40 轮/109 候选；TB2 10 轮	10 轮，约 32 小时	未报告总轮数，最终只保留 3–4 个编辑	$T=10$ 轮
可编辑范围	自由重写程序	七类文件级组件	DeepAgent 声明式接口	六维结构化配置
初始点	Terminus 2 / Terminus-KIRA（强基线）	bash-only 极简种子	极简 DeepAgent	极简（无工具/无记忆/单次调用）

另外两个具体事实：

四篇之间基本没有直接实证对比。MemoHarness 在 Appendix E 明确说明：它没有把 Meta-Harness 当作实证基线，因为实验定稿时（2026 年初）没有适配其评估栈的公开实现，自行重实现会引入大量设计选择、使归因不干净，因此只做定性对比。
连同一篇论文内的数字也未必可比。AHE 把基础设施异常中断与超时统一计为 pass@1 失败（比丢弃它们更苛刻），但在算 token 均值时又排除这些 trial——两个指标的分母不一样。

因此，76.4%、77.0%、61.9% 和 0.806 不能用来给四种方法直接排名。应该比较的是：

同一论文内部固定条件下的增量；
是否存在独立验证和真正盲测；
是否跨模型、跨任务和跨时间迁移；
提升是否来自更多预算或更强模型；
是否报告任务级回归、方差和搜索总成本。

数据集	用途	是否向 proposer 暴露
Discovery / Search	产生轨迹、诊断失败、提出修改	是
Validation	选择候选和超参数	只暴露评分或受控证据
Regression	保护关键既有能力和安全边界	只用于门禁
Blind Test	最终一次性评测	完全不参与搜索和晋升
Transfer	跨模型、跨领域和时间外测试	完全不参与开发

面向自有 Agent 的落地方案

四篇论文可以组合成一条工程路线：

flowchart TB
    T["Discovery / Validation / Regression / Blind Test"] --> EX["执行与遥测层"]
    EX --> EV["证据层<br/>原始轨迹、任务报告、失败簇"]
    EV --> OP["优化层<br/>程序搜索或模型特定提案"]
    OP --> WS["受控 Harness 工作区"]
    WS --> G["门禁层<br/>正确性、成本、回归、安全"]
    G -->|"接受"| REG["版本库与发布 Harness"]
    G -->|"拒绝"| EV
    REG --> BANK["经验库<br/>案例经验、全局模式、Manifest"]
    BANK --> AD["部署适配器"]
    X["线上新任务"] --> AD
    AD --> HX["任务特定配置 H(x)"]
    HX --> PROD["生产执行"]

对应关系：用 Meta-Harness 的方式探索新程序结构；用 AHE 的组件化、manifest、权限隔离和回滚治理修改；用 Self-Harness 的失败聚类和最小修改原则适配目标模型；用 MemoHarness 的经验库和逐案例配置支持部署时适配。

最小可行闭环

冻结模型、环境和 Verifier，先建立可复现基线；
组件化 Harness，把 Prompt、工具、middleware、memory 和验证逻辑拆开；
记录结构化轨迹，包含工具输入输出、状态变化、成本和最终 Verifier 原因；
聚类失败机制，区分终端症状、因果行为和可修复机制；
提出多个最小候选，每个候选带修改理由、预期修复和潜在回归；
独立评测并执行门禁，没有充分提升或出现回归就拒绝；
保存谱系与经验，记录成功、失败和拒绝原因，支持下一轮检索。

日志需要支撑哪些字段

可观测性日志是这套体系的数据底座。对照四篇论文，至少要能支撑：

字段类别	具体项	服务于
执行轨迹	完整消息序列、工具调用与返回、耗时	全部
验证结果	verifier 终端原因（枚举化，不要自由文本）	Self-Harness 失败签名 $c$
因果标注	该行为是否为失败主因	Self-Harness 失败签名 $q$
机制标签	抽象 agent 机制（无效重试 / 探索不收敛 / 产物缺失 / 环境丢失…），受控词表	Self-Harness 失败签名 $m$
主失败维度	D1–D6 之一或空	MemoHarness 诊断算子
逐案例统计	连续失败次数、最近平均奖励、奖励趋势、各维度失败计数	MemoHarness 经验库
Harness 版本	谱系 id + 本次相对上一版的 diff（改了哪个文件）	AHE 组件可观察性、归因与回滚
编辑预测	该版本被提出时声明的预期修复与回归风险	AHE 决策可观察性
成本	输入/输出/缓存命中 token、延迟、工具调用次数	次级判据 + 缓存率监控

一个关键提醒：机制标签必须是受控词表且可枚举，否则聚类会退化成语义相似度匹配，失去 Self-Harness 强调的"确定性、evaluator-grounded"性质。

修改权限分级

风险级别	可修改内容	建议发布策略
L1 低风险	Prompt、示例、检索 top-k、超时等有界参数	回归测试通过后可自动发布
L2 中风险	memory、skill、工作流、middleware	灰度发布并检查任务级回归
L3 高风险	工具实现、写权限、终止逻辑、validator 周边逻辑	必须人工批准
禁止区	答案、Verifier、模型身份、预算上限、安全根规则	优化器只读且不可绕过

AHE 的迭代 8 案例给了一条额外教训：留给 agent 的"逆转开关"会被它学会当作绕过手段（ALLOW_POST_SUCCESS_RESET 令牌）。高风险面上应该是硬阻断而非可覆盖警告。

一个保守的接受规则

candidate = propose_minimal_edit(
    current_harness,
    failure_evidence,          # 按 φ=(终端原因, 因果地位, 机制) 聚类后的证据
    retrieved_experience,
    writable_surfaces=ALLOWLIST,
)

assert candidate.does_not_modify(PROTECTED_SURFACES)   # verifier / 权限 / 预算

validation = evaluate(candidate, validation_set, repeats=N)
regression = evaluate(candidate, regression_set, repeats=N)
safety     = run_safety_suite(candidate)

# 非退化门：至少一侧提升，另一侧不下降（Self-Harness 规则）
improves = validation.delta >= 0 and regression.delta >= 0 \
           and max(validation.delta, regression.delta) > 0

if improves and safety.passed and candidate.cost <= budget:
    publish_canary(candidate)
else:
    reject_and_record(candidate)   # 拒绝也要入库，供下一轮检索

风险清单

风险	说明	缓解
基准过拟合	接受的编辑可能只针对基准特定失败模式（四篇均自陈）	多基准交叉验证；保留真正的一次性盲测集
虚假提升	提升可能只来自更多推理预算 / 更多尝试	对比预算匹配的 best-of-N 与 self-refine 基线
成本失控	MemoHarness 的成本优势建立在 ≈94% 缓存命中上	把经验上下文设计成前缀稳定结构，最大化 prompt cache；监控缓存命中率
验收门太弱	pass-rate 非退化不足以守护高风险改动（Self-Harness 自陈）	高风险面加独立安全门与人工审批
回归盲区	proposer 对回归的预测约等于随机（AHE 量化）	回归集必须外部硬挡，不依赖 agent 声明的风险列表
组件互相抵消	单独有效的组件叠加后可能为负（AHE +11.1 → +7.3）	分层评测；保留单组件消融能力
经验库腐化	模型/工具升级后旧经验失效	经验条目打模型版本、工具版本 tag，按 tag 淘汰
安全面扩大	开放工具、长期保留状态会扩大攻击面	工具白名单 + Memory 写入审计；自动演化不得修改权限策略
运行点耦合	步数预算/超时若按某个模型拟合，跨模型数字会失真（AHE 自陈）	在多个运行点下重跑；报告时说明拟合基座

哪些情况不应称为 Harness 进化

以下做法可能有用，但不构成本文意义上的 Harness 进化：

把所有失败日志不断追加到 system prompt；
人工偶尔修改一次 Agent 说明文档；
只让 Prompt 越来越长，以 token 换分数；
换成更强模型，却把提升归因于 Harness；
在最终测试集反复尝试，再报告最高点；
让优化器修改 Verifier、答案、权限根规则或预算；
只记录成功配置，不记录适用条件、失败和回归。

一套完整 Harness 进化系统至少需要：

行为证据 + 系统化提案 + 受控编辑空间 + 独立验证 + 版本回滚 + 经验保留。

实际选型建议

主要需求	优先借鉴
探索完全不同的 Agent 程序结构，评测预算充足	Meta-Harness
生产环境必须审计、回滚和限制权限	AHE
没有更强外部优化模型，需要适配目标模型弱点	Self-Harness
任务异质性强，希望无标签地逐案例调整策略	MemoHarness
既要探索上限又要生产可控	Meta-Harness 的探索 + AHE 的治理
希望形成长期闭环	AHE 的证据层 + Self-Harness 的定向修改 + MemoHarness 的经验库

对大多数团队，推荐的实施顺序是：

先把现有 Harness 组件化、版本化，建立可靠评测（这一步不做，后面全是空中楼阁）；
从 Prompt、记忆、检索和有界参数开始自动优化；
加入失败聚类、change manifest 和回归门；
再逐步开放 workflow、middleware 和工具实现；
最后才考虑线上逐案例适配和高风险代码级自修改。

最终结论

四篇论文共同讲述了一条清晰的技术路线：

Meta-Harness：Harness 是可以端到端搜索的程序；关键是不要压缩给 proposer 的反馈。
AHE：自动修改必须可观察、可证伪、可回滚；每次编辑都是一份下一轮验证的契约。
Self-Harness：模型可以参与修复适合自己的运行时系统；关键是保守的非退化验收门。
MemoHarness：执行经验可以长期积累，并用于逐任务适配。

因此，Harness 进化可以定义为：

在基础模型和外部评测规则保持受控的前提下，系统依据可验证的执行经验，持续修改并选择模型外部的上下文、工具、记忆、编排和验证机制，从而改善端到端 Agent 表现。

它不是模型权重层面的自我进化，但可能成为现阶段最可落地的 Agent 自我改进形式：不必重新训练模型、修改可版本化和回滚、可以针对模型和任务差异进行适配、能把业务执行轨迹沉淀为组织自己的系统能力。

未来 Agent 系统之间的差距，未必只来自谁接入了更强的模型，还可能来自谁拥有：

更高质量的执行轨迹；
更可靠的失败诊断；
更严格的验收门；
更成熟的工具与中间件；
更可复用的 Harness 经验库。

模型是推理引擎，Harness 是把推理转化为可靠行动的系统。

讨论题

我们当前 Agent 的失败，有多少是模型能力不足，有多少是 Harness 没有释放模型能力？能不能按 D1–D6 或七类组件做一次归因？
我们愿意开放给优化器的最大修改范围是什么？对应的验证能力够不够覆盖它？
谁来保证 Verifier、权限和预算不会被自修改系统绕过？我们有没有等价于 AHE 那份"只读清单"的东西？
一个跨模型通用 Harness，与每个模型专属 Harness，哪个更适合我们的平台？我们的模型更换频率是多少？
当平均成功率提升但少数关键任务回归时，什么才算"更好的 Harness"？谁有权判定？
我们现有的日志和评测体系，是否足以支撑失败签名聚类与编辑归因（见 §10.3）？
我们有没有一个真正的一次性盲测集？还是所有"held-out"其实都被反复使用了？

参考文献

Yoonho Lee, Roshen Nair, Qizheng Zhang, Kangwook Lee, Omar Khattab, Chelsea Finn. Meta-Harness: End-to-End Optimization of Model Harnesses（arXiv:2603.28052，2026-03-30，Stanford / KRAFTON / MIT）
- 项目页：https://yoonholee\.com/meta\-harness/
- TerminalBench-2 产物：https://github\.com/stanford\-iris\-lab/meta\-harness\-tbench2\-artifact
Jiahang Lin, Shichun Liu, Chengjun Pan, Lizhi Lin, Shihan Dou, Zhiheng Xi, Xuanjing Huang, Hang Yan, Zhenhua Han, Tao Gui, Yu-Gang Jiang. Agentic Harness Engineering: Observability-Driven Automatic Evolution of Coding-Agent Harnesses（arXiv:2604.25850v4，2026-04-28 / 修订 05-18，复旦 / 北大 / 上海奇寂之风）
- 代码：https://github\.com/china\-qijizhifeng/agentic\-harness\-engineering
Hangfan Zhang, Shao Zhang, Kangcong Li, Chen Zhang, Yang Chen, Yiqun Zhang, Lei Bai, Shuyue Hu. Self-Harness: Harnesses That Improve Themselves（arXiv:2606.09498，2026-06-08，上海人工智能实验室）
Yue Huang, Wenjie Wang, Han Bao, Yuchen Ma, Xiaonan Luo, Yi Nian, Haomin Zhuang, Zheyuan Liu, Yue Zhao, Xiangliang Zhang. MemoHarness: Agent Harnesses That Learn from Experience（arXiv:2607.14159，2026-07-14，Notre Dame / USC / LMU Munich）
- 代码：https://github\.com/HowieHwong/MemoHarness

四篇共同依赖的评测载体

M. A. Merrill et al. Terminal-Bench: Benchmarking Agents on Hard, Realistic Tasks in Command Line Interfaces. arXiv:2601.11868, 2026.

主要对照方法

Q. Zhang et al. Agentic Context Engineering (ACE): Evolving Contexts for Self-Improving Language Models. ICLR 2026, arXiv:2510.04618.（AHE 与 Meta-Harness 均将其作为基线）
Y. Cai et al. Training-Free Group Relative Policy Optimization. arXiv:2510.08191, 2025.（AHE 基线）
L. A. Agrawal et al. GEPA: Reflective Prompt Evolution Can Outperform Reinforcement Learning. ICLR 2026, arXiv:2507.19457.（Meta-Harness 基线）
Nex-AGI. NexAU: A General-Purpose Agent Framework. https://github\.com/nex\-agi/NexAU （AHE 的 harness 底座）
LangChain. DeepAgents. https://github\.com/langchain\-ai/deepagents （Self-Harness 的初始 harness 底座）

本文未展开的相邻工作

Linyue Pan et al. Natural-Language Agent Harnesses. arXiv:2603.25723, 2026.
N. Zhu et al. SemaClaw: A Step Towards General-Purpose Personal AI Agents through Harness Engineering. arXiv:2604.11548, 2026.
J. Liu et al. Dive into Claude Code: The Design Space of Today's and Future AI Agent Systems. arXiv:2604.14228, 2026.
Yike Wang et al. Rethinking the Evaluation of Harness Evolution for Agents. arXiv:2607.12227, 2026.（注：本条来自二手引用，未核对全文。据引述，其主张自动 harness 演化必须与预算匹配的并行采样、顺序修正等简单方法比较，并严格区分搜索任务与最终评估任务。）

概览

什么是 Agent Harness

从模型调用到 Agent 系统

Harness 不等于"模型外部的一切"

软 Harness 与硬 Harness

Harness 进化在优化什么

Meta-Harness：把完整 Harness 程序变成搜索对象

它要解决的问题

关键方法：文件系统式经验访问

核心结果

关键消融：起作用的是"原始执行轨迹"

泛化：不是只在搜索数据集上有效

发现出来的 Harness 长什么样

proposer 到底在做什么

贡献与局限

Agentic Harness Engineering：让自动进化可观察、可证伪

核心观点

七类可编辑组件

三层可观察性

安全边界

核心结果

自归因到底有多准：修复能预报，回退基本盲

一个完整的演化案例：从"写进 prompt"到"建成拦截器"

局限

Self-Harness：模型参与修改自己的 Harness

核心观点

三阶段循环

Weakness Mining：不要只按表面错误聚类

Proposal：分支间多样，分支内最小

Validation：保守的非退化门

实验结果

它算不算真正的自进化

MemoHarness：从全局 Harness 走向逐任务适配

核心观点

六个结构化但相互耦合的控制面

双层经验库

正确性优先

实验结果

MemoHarness 是否仍然只是 Prompt 优化

四篇论文的统一对比

四篇之间的引用关系

四篇不是同一种"自进化"

四篇论文共同验证了什么

固定模型不等于固定 Agent 能力

最优 Harness 具有模型和任务依赖性

结构化机制通常比散文式要求更可靠

验收门比提案器更决定系统能否长期进化

为什么不能直接比较四篇论文的分数

推荐的数据拆分

推荐报告指标

面向自有 Agent 的落地方案

最小可行闭环

推荐目录结构

日志需要支撑哪些字段

修改权限分级

一个保守的接受规则

风险清单

哪些情况不应称为 Harness 进化

实际选型建议

最终结论

讨论题

参考文献

评论