OO-Harness：用面向对象继承演化出「专用 harness 家族」 · 干货攻略

• 链接:https://x.com/omarsar0/status/2112911038098317422
• 分类:x-tips
• 来源:X @omarsar0（Elvis S.）
• 作者:Jay
• 更新:2026-10-22
• 论文原文:https://arxiv.org/abs/2610.28380 （Object-Oriented Harness: Evolving Agent Harnesses through Object-Oriented Design，v1 提交于 2026-10-20，20 页 10 图，CC BY 4.0）
• 仓库:无 —— 论文未给出 OO-Harness 自身的官方代码仓库，文中出现的 GitHub 链接均属基准或基线方法（如 https://github.com/zapier/AutomationBench 、https://github.com/OpenDataBox/Workspace-Bench 、https://github.com/eigent-ai/toolathlon_gym 、https://github.com/stanford-iris-lab/meta-harness 、https://github.com/A-EVO-Lab/a-evolve ），不可当作 OO-Harness 主仓库

这是什么

一条技术推文，推荐 Google Cloud AI Research 的论文 OO-Harness（Object-Oriented Harness）。它要解决的问题是：agent harness（跑在模型外面的那层 prompt / 工具 / 控制流代码）通常是"一全局 harness 打天下"，面对异质任务会失效——一条改写在难任务上有效的经验，套到简单任务上反而拉低分数。

OO-Harness 的做法是：让一个 evolution agent 用执行记录去演化出一棵 harness 类的继承树。每个专用 harness 都是基类（或某个已演化的专用类）的子类，只覆写/新增该任务簇真正需要的方法；演化过程中沉淀 design lessons（哪些改动有用、哪些失败）；测试期由一个 harness router 读任务描述 + base run 的轨迹，从冻结的类目录里挑一个子类执行，挑不中就沿用 base 的结果。整篇论文只动 harness 代码，executor 模型权重全程冻结。

推文里那句 "Build specialized harnesses, folks" 的潜台词是：与其进化一个全局 harness，不如进化一组共享代码的专用 harness。

核验来源与关键数字

原推文正文（截断）只给了 AutomationBench 从 61.6% 到 77.4%、执行器是 Gemini 3.5 Flash、以及全面超过 Meta-Harness。以下数字全部回原论文 Table 1 / §4.1 / 附录 A.1 核对过：

• 61.62 → 77.41 即论文摘要所称"对 base 的绝对提升最高 15.79%"，与推文的 61.6% → 77.4% 对得上。
• 三个基准的 primary 分数（AutomationBench/Workspace-Bench 取 Mean，Toolathlon-GYM 取 PASS）上，OO-Harness 均高于 Meta-Harness 和 AAH；AutomationBench 上平均步数还最低。
• ⚠️ 口径提醒：77.4% 是 AutomationBench 的 Mean（平均部分分），严格 PASS 只有 37.22%。推文没写清这一层，转述时别把它说成"任务完成率"。
• 模型与预算（附录 A.1 / §4.1）：executor 固定为 gemini-3.5-flash；各 harness 优化方法的 evolution agent 统一用 Claude Opus 4.8，最多 40 轮迭代；OO-Harness 的 router 用 Claude Sonnet 5。每个方法 × 每个基准跑 3 次独立 executor，报告均值 ± 标准差。
• 基准规模：AutomationBench 300 训练 + 300 held-out；Workspace-Bench 288 + 100（Lite-100）；Toolathlon-GYM 251 + 252。

上手步骤

论文没有发布可 pip install 的实现（无主仓库），下面是把它的方法移植到自己项目里的最小路径：

1. 先冻结 executor 与基座 harness。固定模型（论文用 gemini-3.5-flash）和一份能跑的 base harness，别动权重，只动 harness 代码——这是全套实验成立的前提。
2. 跑一遍 base，收集执行记录。在 discovery 任务集上跑 base harness，保留轨迹、工具报错、评分反馈、产出物。
3. 按"共享执行需求"聚类。用记录里的证据把任务分成任务簇（论文里 AutomationBench 按业务域、Workspace-Bench 按产物类型/文件依赖、Toolathlon 按应用族），每簇记下它共同的执行需求。
4. 写一个 evolution agent，让它产子类。给它文件系统访问权：能读 harness 源码、任务簇、执行记录，能改代码、可派子 agent。它每轮选一个簇 + 一个父类，写出一个可执行的子类（覆写或新增方法），然后只在这个簇上跑候选并打分——不是每次都重跑整个 discovery 集，这是主要省算力的地方。
5. 按"簇内变好"接受。候选在该簇分数超过当前水平且通过该基准的验收检查才被接受，否则拒绝并记录。连续拒绝会降低该簇的搜索优先级。簇的划分每轮都可重审（拆分/合并/改归属）。
6. 沉淀两类经验：design lessons（哪些改动有效）供后续演化用；routing lessons（什么问题该配哪个 harness）供 router 用。论文里注入路由器的 lesson 文本上限 6,000 字符，单次提案超时 2,400 秒。
7. 测试期：router 选类，选不中就用 base。router 拿到任务描述 + base 轨迹 + 冻结的类目录 + 冻结的 routing lessons，返回一个类或 leave-on-base。测试期不可见 grader 分数、裁定和参考答案。
8. 务必保留 base 作为兜底选项。这是它在分布外不崩的关键（见下）。

适用边界与已知限制

• 路由必须看执行轨迹，不只看任务描述。消融（Table 2）：只按任务选类，AutomationBench 只有 64.88；加入 base 轨迹后升到 77.52（+12.64）。Toolathlon-GYM PASS +4.37；Workspace-Bench 只 +0.53（那边任务类型本身就是好线索，如"写文档/改表格"）。
• 继承本身有收益。Workspace-Bench 上同样预算下：OO 40.56 > Flat（直接继承基类、拷贝已演化代码）40.56−4.96 > Base-reset（每次从基类重来）。跨版本继承好用，但每次推倒重来最差。
• 多花推理不必然更好。best-of-K（K=2,5）与顺序自精炼（K=2）都没有稳定提升，甚至在 AutomationBench 上不如 base（59.29）。
• base 复用是安全阀。某次 AutomationBench 300 任务里，134 个（44.7%）复用 base、166 个选专用 harness；被送去专用 harness 的任务 base 均分只有 44.40，留在 base 的高达 77.15——路由器把"base 表现差"当作该特化的信号。分布外实验（训练/测试应用族完全不重叠）里，router 全部选择复用 base，保住了性能；而强行套用 Meta-Harness 学到的全局 harness，PASS 反而下降。
• 论文自己列的限制：依赖宿主提供的 API 与执行环境，服务宕机、限流会影响可靠性；接口变更会让已演化的 harness 需要返工；接私有/需鉴权的服务要自己处理凭证与权限。标注的限制还有：主要开销就是托管模型 API 调用。
• 安全边界：进化 agent 会写代码并被执行，权限（文件系统、子 agent、API）需要自行收敛，别让它在生产环境里无监督改自己的执行路径。

不确定处

• 原推文正文在证据快照里是截断的（"It also beats…"），后半段完整内容来自该推文页面的公开索引文本，已与论文 Table 1 对齐；未核对推文是否附有论文之外的额外数据。
• Workspace-Bench 上"base → 专用"的提升，论文 Table 1 是 25.45 → 39.48（Mean）；推文该处被截断，未直接显示这两个数字。
• 是否存在官方 OO-Harness 代码仓库：论文正文与附录只列出基准和基线方法的仓库，未给出自身实现地址；如后续放出，链接需以官方发布为准。
• 论文为 arXiv v1，未见同行评审信息；数字均引自 v1 表格，修订版可能变化。