Agent 的"操作系统"也需要学习：MemoHarness 把执行经验变成可复用的控制层

  核心洞察：Agent harness 不是一个需要手写的静态配置，而是一个应该从执行经验中持续学习的控制层。MemoHarness 把 harness 拆成六个可编辑维度，用双层经验银行积累诊断式反馈，测试时无需标签即可自适应。

问题：手写 harness 的困境

AI agent 圈有个奇怪的分裂：LLM 本身越来越强，但把它变成能干活 agent 的那层"壳"——harness——仍然靠手写。prompt 模板、工具调用策略、编排逻辑、记忆策略，全是工程师拍脑袋定下来的，一套配置打天下。

这很脆弱。"一个 harness 可能在平均意义上很强，但仍然对特定类型的 case 系统性错配。"更麻烦的是，大多数自动优化方法只优化 harness 的某个窄切片——prompt、pipeline、workflow——而不去联合编辑决定 agent 行为的整个控制层。

MemoHarness 把这个问题重新定义成一个从执行经验中学习的 harness 优化问题。

图1. MemoHarness 总体架构：Phase A（Search）对六维 harness 空间进行引导式搜索；Phase B（Test）从双层经验银行检索相似案例，无需标签、反馈或额外搜索。

三个设计决策

一、六维 harness 空间

不是优化一个不透明的 prompt，而是沿推理的时间流，把 harness 分解为六个独立可编辑的控制面：

维度	控制内容	示例决策
D1 Context	上下文组织与检索	RAG 参数、chunk 策略、上下文窗口分配
D2 Tool	工具调用策略	工具选择顺序、超时、错误重试逻辑
D3 Generation	解码策略	temperature、top-p、最大 token 数
D4 Orchestration	编排逻辑	workflow 拓扑、检查点、回退路径
D5 Memory	记忆策略	记忆写入/检索策略、上下文压缩
D6 Output	输出后处理	验证逻辑、格式化、后处理 pipeline

每个维度可以独立编辑，但搜索时会考虑维度间的交互——改 retrieval 策略可能改变最佳 prompt 格式、解码预算和 workflow 拓扑。

二、双层经验银行

传统的 harness 搜索只看 benchmark 分数——知道"这次成了还是败了"，不知道"哪个维度导致了失败"。

MemoHarness 的双层经验银行解决了这个问题：

Per-case 执行记录：每个训练 case 的配置、轨迹和结果，用于检索相似场景
Distilled 全局模式：跨 case 的抽象规律——哪些操作跟成功强相关，哪些维度的改动最可能带来提升

这让每次迭代变成诊断式的，而不仅仅是看分数涨没涨。

三、测试时无标签适应

训练完后，全局 harness 在测试时根据每个 case 的特征（domain、ambiguity、complexity、是否需要外部知识），从经验银行检索相似历史案例和相关全局模式，自动调整六个维度的配置——不需要测试时的标签、梯度更新或额外搜索。

图2. Terminal-Bench 基线对比。MemoHarness（最右，GPT-5.3-Codex）达到 0.806，超越所有固定 harness 基线。

效果：不只是刷榜

MemoHarness 在三个 benchmark 族上验证：Terminal-Bench（长程 shell agent）、LiveCodeBench（代码生成）、FinanceAgent（多步金融推理）。

在 Terminal-Bench 上达到 0.806，超越 CoALA、SWE-agent、Terminus、Claude Code、OpenCode 等所有基线。在 LiveCodeBench 和 FinanceAgent 上也都有显著提升。

Harness 质量检查点 — 图3. 六个检查点的 harness 质量：Base → 四个中间迭代 → 最终选中。三个 benchmark 一致提升。

更有意思的是迁移实验：用 GPT-5.3-Codex 搜出来的 harness 直接套到 DeepSeek-V3.2、GLM-5、GPT-4.1、Claude 上，平均提升 +0.098。受益最大的是 GLM-5（+0.233），最小的是 GPT-4.1（+0.038）——更强的基座模型留给 harness 优化的空间更小，但这个结论还需更大规模验证。

逐轮成功率 — 图4. FinanceAgent（左）和 LiveCodeBench（右）上 10 轮搜索的每轮成功率。FinanceAgent 持续改进到 65%，LiveCodeBench 约第 6 轮收敛。

操作级诊断：什么操作真正有用？

论文做了一件很漂亮的分析：检查每一次 harness 迭代中，哪些 shell 操作的新增最可能带来 reward 提升。

操作	新增次数	正向率	提升幅度
cat	11	72.7%	+451.9%
sed	11	36.4%	+175.9%
which	15	33.3%	+152.9%
test	46	30.4%	+130.9%
grep	9	11.1%	-15.7%
echo	28	10.7%	-18.7%
curl	19	5.3%	-60.1%

cat、sed、test 这些"理解文件内容、做条件判断"的操作跟成功强正相关；而 grep、echo、curl 的新增反而不如基线——说明 harness 搜索不是盲目堆砌工具，而是学会了"什么场景该用什么"。

成本与局限

MemoHarness 引入的额外上下文确实增加了 token 消耗，但大部分检索到的经验是可缓存的——相似 case 共享同一批经验时不需要重复计算。论文展示经过缓存优化后，额外成本可以保持在可接受范围。

论文也坦诚了局限性：统计显著性验证不足，各组件的贡献归属还不够清晰。但它确立了一个方向——harness engineering 可以成为一门系统化研究的学问，而不仅仅是工程直觉。

这意味着什么

过去我们讨论 agent 优化的思路很窄：要么换更强的模型，要么改写 prompt/workflow。MemoHarness 打开了第三条路——harness 本身就是一个可以搜索、可以积累经验、可以跨模型迁移的 artifact。

类比一下：LLM 是 CPU，harness 是操作系统。我们花了几十年优化操作系统的调度策略、内存管理、IO 策略，但对 agent harness 的设计还停留在手工作坊阶段。MemoHarness 迈出了自动化的第一步。