Mode A 单篇综合：把 Meta-Harness 放进"对冻结基座做外层优化"的同侪簇里， 沿两条轴定位——优化什么（权重 / 代码 / 配置 / 上下文工件）与 反馈压缩到什么程度（全保真 trace / 结构化记忆 / scalar+summary）。
七个同侪按与本篇的关系分三组。
A. 同范式近邻：coding-agent 作为整个 variation operator（最近邻）
+ 多维评分"当作进化搜索的整个 Vary 算子，agent 自主决定查阅哪段历史、改哪段代码、怎么诊断失败
[2603.24517]。差别只在被搜索对象——AVO 搜 B200 CUDA attention kernel
源码 [2603.24517]，Meta-Harness 搜包裹冻结 LLM 的 harness 程序
[2603.28052]。两者都用持久化文件/git 历史代替显式 mutation 算子，
都在 agent 停滞时（AVO 用 supervisor、Meta-Harness 靠 proposer 自主重读 trace）重新引导探索。
Plan-Execute-Summarize 认知回合、显式 lineage parent_id 链、multi-island MAP-Elites
与 Boltzmann 选择 [2512.24077]。Meta-Harness 刻意不内置
mutation 算子、不做 parent selection [2603.28052]，是同一
"LLM-augmented evolutionary search"谱系上的极简对立端。
B. 对冻结基座的另几种外层杠杆（正交近邻）
（entropic objective + PUCT，LoRA 热更新）来逼近 SOTA 解 [2601.16175]，
而 Meta-Harness 始终冻结权重、只改外层代码 [2603.28052]。两者是"改权重"
与"改 harness"两条改进固定基座的路。Meta-Harness 在 Table 4 直接把 TTT-Discover 列为程序搜索基线
并在同等评估预算下超过它 [2603.28052]。
（planner/solver 各用哪个模型），用 Matrix UCB-E bandit 在组合×数据点网格上搜
[2604.06296]。它是黑盒配置搜索，本篇是白盒代码搜索——同一外层
优化空间的两个不同坐标。
raw trace（$L_0$）压到 episodic memory（$L_1$）/ skill（$L_2$）/ rule（$L_3$），并指出
高压缩通常带来高性能（$L_2$ vs $L_1$ +5.3~68.5pp）[2604.15877]。
Meta-Harness 恰好坐在该谱被忽视的 $L_0$ 极端（全保真 trace + 选择性访问），与 ECS 的主张正面相关又张力十足（见 §2）。
C. 上下文工程的机制与对照（共享 mechanism / 共享 baseline）
skill、MCP schema 全落盘成文件，让 agent 用 grep/read 按需懒加载，A/B 实测 MCP 会话省 46.9% token
[blog-dynamic-context-discovery]。Meta-Harness 的 proposer 正是用这种
"文件系统作通用懒加载接口"读取远大于 context window 的历史 $\mathcal{D}$
[2603.28052]——blog 是这一访问模式的生产级佐证。
long-context 上比 ACE 高 7.8–15.0% [2605.19932]，Meta-Harness 在文本分类上比
ACE 高 7.7 分 [2603.28052]。两者都诊断出 ACE 过拟合任务级 playbook
[2605.19932]，却给出相反的压缩处方（见 §2）。
新意（本篇独有）
[2603.24517]，本篇把同一范式搬到"决定存什么/取什么/怎么呈现给模型"的 harness 代码空间
[2603.28052]——这块地盘此前由 prompt-learning（ACE/PEEK）占据，本篇用代码空间搜索抢了进来。
[2512.24077]，本篇主张 outer loop 极简到不设 parent selection、不设 mutation 算子，
把诊断与编辑决策完全交给 coding agent [2603.28052]。
median [2603.28052]——这是 AVO/LoongFlow 都未提供的、关于"原始 trace 访问不可压缩"的直接实验证据。
矛盾一：压缩方向与 ECS 正相反
ECS 的核心实证是"压缩层级越高、性能越好"（$L_2$ skill 显著优于 $L_1$ memory）
[2604.15877]，而 Meta-Harness 的消融显示把诊断信号压成 summary 反而从
median 50.0 跌到 34.9 [2603.28052]。
矛盾根源：两者压缩的对象与消费者不同。ECS 压缩的是"供 agent 未来任务复用的知识工件"，
消费者是执行任务的 agent；Meta-Harness 压缩的是"供 proposer 做因果归因的诊断信号"，消费者是做
优化的外层 proposer，它要把下游 failure 归因到早期 harness 决策
[2603.28052]。更关键的是 ECS 自己留了个口子：SkillsBench 上 curated $L_2$ +16.2pp
而 LLM 自生成 $L_2$ 仅 +0.0pp [2604.15877]——即收益取决于压缩保真度而非层级。
Meta-Harness 只测了 LLM 生成的 summary（低保真），因此"summary 不能替代 trace"很可能把"压缩"与
"劣质摘要"混为一谈（这条也进 §3 攻击面）。两篇在各自范围内都自洽：本篇坐在 ECS 明确指出"被忽视"的
$L_0$ 全保真极端，恰是 ECS 谱系图上空着的那一格。
矛盾二：与 PEEK 对"上下文该多大"给出相反处方
PEEK 主张把 orientation 知识 curate 成 1024-token 的常驻小工件，且实测原始前缀 +0.73%、
runtime full-swap −14.86%，即"塞原始上下文"无效甚至有害 [2605.19932]。
Meta-Harness 主张保留全保真原始 trace、按需 grep [2603.28052]。
矛盾根源：消费时机与预算约束不同。PEEK 的 map 每次 query 都常驻 system prompt，必须在硬预算 B
内 [2605.19932]；Meta-Harness 的 trace 喂给离线 proposer，由文件系统按需检索、
无每调用预算压力 [2603.28052]。即 PEEK 优化的是 resident-in-prompt 成本，
Meta-Harness 用的是 on-demand-retrieval 成本模型（正是 blog-dynamic-context-discovery 的机制
[blog-dynamic-context-discovery]）。有趣的是两篇出自同一脉络且都把 ACE 当 baseline 打——
它们不是真冲突，而是同一问题在"常驻 vs 懒加载"两种部署约束下的两个解。
增量（非颠覆）
并补上 AVO 缺的接口消融；但"agent 自主多步 edit-evaluate-diagnose + 持久历史"的核心机制是共享的，非本篇首创。
与算法（coding agent vs bandit）不同 [2604.06296]。
针对本篇具体 claim 的反驳：
[2603.28052]，但搜索期成本被隐藏：单次评估可达 10M token、一次 run 约评估 60 个 harness、
proposer 是 Opus-4.6 [2603.28052]。这是一次性巨额前置成本，论文没有像 AgentOpt 那样
明算搜索 $ 开销（AgentOpt brute-force $4.71–123.87/benchmark，且 bandit 省 62–76%
[2604.06296]）。拿部署省 4× 去对标 ACE，回避了搜索投入。
outer-loop 与 proposer 实现均未公开 [2603.28052]。无法排除"换个弱
proposer 文件系统访问就失效"的混淆——而这恰是 AVO 同样存在的问题（NVIDIA 内部 agent，kernel 源码未开
[2603.24517]）。更尖锐的是 TerminalBench-2 上唯一比它高的 ForgeCode(81.8)
"从公开代码无法复现"，于是本篇把自己排到一个不可复现系统之下的 #2 [2603.28052]——
这是选择性比较。
[2603.28052]，没有消融种群管理维度。LoongFlow 提供了反向证据：去掉显式记忆结构会
diversity collapse、agent 跨代重复同样错误 [2512.24077]；AVO 也需要 supervisor
在停滞时重新引导 [2603.24517]。本篇 run 很短（20 iter / ~60 harness
[2603.28052]），停滞可能还没发作；放到 AVO 的 7 天 / 500+ 方向尺度
[2603.24517]，无选择策略是否还成立完全未知。
而自生成压缩 +0.0pp [2604.15877]；PEEK 进一步证明把 Distiller（抽取）与
Cartographer（编辑）分离、只保留可迁移知识，比单次 LLM 摘要高 7.7%
[2605.19932]。本篇只测了单次 LLM summary，没测结构化/分离式压缩，结论"原始 trace 不可压"过强。
[2603.28052]。这意味着 OOD 73.1% 等泛化数字可能依赖这份人工调过的 eval 设计，
稳健性存疑。
把同侪簇摊到二维：优化对象 × 反馈压缩度。
| 优化对象 \ 压缩度 | 全保真 trace（$L_0$，选择性访问） | 结构化记忆（lineage/island/map） | scalar/summary |
|---|---|---|---|
| 模型权重 | — | — | TTT-Discover [2601.16175] |
| 代码（kernel） | AVO [2603.24517] | LoongFlow [2512.24077] | — |
| 代码（harness） | Meta-Harness（本篇） | — | — |
| 模型组合配置 | — | — | AgentOpt [2604.06296] |
| 上下文工件 | blog-dcd 机制 [blog-dynamic-context-discovery] | PEEK 1024-token map [2605.19932] | ACE（被打败的 baseline） |
Meta-Harness 占据"(优化 harness 代码 + 冻结权重 + 全保真 trace + 选择性文件系统访问)"这一此前空着的格子。
它的范式定位是：把 AVO/LoongFlow 的"agentic 进化搜索"从 kernel 这一窄域，搬进原本属于 prompt-learning
（ACE/PEEK）的 harness/上下文管理域，并以 ECS 谱系上"被忽视的 $L_0$ 全保真端"作为理论锚点
采用证据：本篇真正落地的部分是它依赖的底层机制——blog-dynamic-context-discovery 描述的
"文件系统作懒加载上下文"已在生产 A/B 跑出 46.9% token 缩减 [blog-dynamic-context-discovery]，
说明 proposer 赖以工作的访问模式在真实系统里成立。但 Meta-Harness 本体（闭源 proposer、未公开实现
[2603.28052]）短期难被直接复用；其贡献偏概念重构 + 消融证据，
而非可直接 pip install 的工件——这点与同样未开源的 AVO/LoongFlow [2603.24517]
[2512.24077] 一致，与开源的 AgentOpt
[2604.06296] 形成对照。
从这个簇里能拼出的杂交 / 自适应方向：
Meta-Harness 改 harness、冻结权重 [2603.28052]——两者正交。把内层 TTT 与外层
harness 搜索交替（先 TTT 适配权重，再搜 harness，再 TTT…）是一个无人占据的格子。
[2603.28052]；引入 ECS 的 missing-diagonal meta-controller
[2604.15877] 或 PEEK 的 Distiller/Cartographer 分离
[2605.19932] 来决定"哪些 trace 留全保真、哪些可压"，有望砍掉那 10M-token/eval 的成本，
同时回应 §3 攻击点 1 和 4。
[2604.06296]；可把"谁当 proposer、谁当 base"也纳入 Meta-Harness 的联合搜索空间，
做 (组合配置, harness 代码) 的二级优化。
[2603.24517] 或 LoongFlow 的 island/Boltzmann
[2512.24077]，在 7 天尺度实测"无 parent selection"是否还成立——直接检验 §3 攻击点 3。
维护策略本身就是一种 harness 组件 [2605.19932]；让 proposer 在搜索空间里自动发现
"何时 distill / evict / 常驻"，可把同脉络的两条线（全保真懒加载 vs 常驻小 map）统一为可搜索的连续谱。
[blog-dynamic-context-discovery] 目前是 proposer 的固定工具；
把 proposer 自身的检索/导航策略也当成搜索目标，可让"如何读历史"与"读出什么 harness"协同进化。