让 AI 连续写 70+ 次代码还能"修一处不崩三处"？arXiv 2609.01481 把 coding agent 包了一层"元层 harness"
- 关联论文：2609.01481（Harness-of-Harness: Multi-Day Autonomous Software Development with Continual Improvement）
你有没有这种感觉：
你让 AI 写代码做项目——第一天干得漂亮，第二天开始修 bug，第三天修了 A 崩了 B、修了 B 又崩了 C。你以为这是模型不够强。不。 这是所有「AI Agent 框架」自己埋的雷：多日迭代没有"持续改进"的系统目标，只有"每次跑完就行"的局部最优。
arXiv 2609.01481（Harness-of-Harness, HoH） 想改的就是这件事。
他们做了一个架在已有 coding agent harness 之外的元层框架——不替换 Codex / OpenCode / Pi，而是在它们外面包一层"orchestrator"，把整个开发过程组织成 iterative planning–coding–testing loop，并强制执行 5 个核心机制：
- 🔁 修复 vs 能力增长双轴平衡——区分"修 bug"和"加新功能"，不混淆
- 🧩 小且可验证的增量——每个 loop 尽量小到"能在 loop 内自己验证通过"
- 🪞 实施期测试 vs 独立评估分离——杜绝"agent 看测试集作弊"
- 🚪 渐进暴露交付物 / 工具 / skills——按需暴露，避免无意义重构
- 📜 Versioned Project History——跨日版本历史，agent 不"忘了昨天做了什么"
结果：
| 维度 | 数据 |
|---|---|
| 三组 harness-model × 3 benchmark 3 次迭代平均增益 | +52.25% |
| 最大相对增益 | +82.86% |
| 多日自治部署 | 70+ 次迭代无人介入完成一款 FPS 游戏（含主线剧情 + 完整机制 + 视觉打磨 + 音频集成） |
为什么这事跟你我也有关
2024-2026 年 AI coding 经历了三波演化：
- 单次补全（Copilot）——单函数，对错立判 ✅
- 单轮 PR / Issue 修复（SWE-Bench）——一个 fix，少量上下文 ✅
- 多日自治开发——agent 自定 plan、拆任务、写代码、跑测试、迭代修复 ⏳
第三波最难——也是产品化最直接的卡点：
- 任务规划容易"漂移"（"用户登录"变成"重构认证框架"）
- 回归测试容易"成本爆炸"（每个 loop 结束都重跑全量）
- 能力建设容易"乱叠加"（加新工具 / skill 时与旧行为冲突）
HoH 的工作直接回应这三个问题。
一句话核心
Harness-of-Harness 是一个元层框架，把 coding agent 的多日自治开发组织成 iterative planning–coding–testing loop，通过修复 vs 能力增长双轴平衡 + 小且可验证的增量 + 实施期与独立评估分离 + 渐进暴露交付物 + 项目级版本历史，防止"修一处、崩三处"的退化——三组 harness-model × 三 benchmark 平均 +52.25%、最大 +82.86%，70+ 次迭代完成一款 FPS 游戏。
核心架构
┌─ Harness-of-Harness（HoH，元层）────────────────┐
│ Plan: Roadmap │
│ 拆解: Increment Decomposer（Small + Verifiable） │
│ 调度: Loop Driver（Plan → Code → Test） │
│ 平衡: Repair ↔ Capability Growth Balancer │
│ 版本: Versioned Project History │
└──────────────────────────────────────────────────┘
↓ 委托下层
┌─ 已有 coding harness（被包）────────────────────┐
│ Codex + GPT-5.5 · OpenCode + DeepSeek-V4-Pro │
│ Pi + MiniMax-M3 │
└───────────────────────────────────────────────────┘
关键设计哲学：HoH 元层独立可升级，下层 harness 可以独立换——这是"包外不包内"的元层思路。
关键洞察：为什么"修复 vs 增长分账"是命门
跨日开发最致命的反模式：把"修 bug"和"加新功能"混在同一个 loop。
后果：
- 若某个 loop 全在"修 bug"，项目停滞——3 天过去了，新功能零增长
- 若某个 loop 全在"加新功能"，回归测试全红——昨天通过的功能，今天全坏了
HoH 强制让每个 loop 显式声明"我是修 bug loop"还是"加功能 loop"——两类动作各走各的 review / merge 流程，互不污染。
类比：把家里的衣柜分成"工作装 / 运动装 / 居家"三个抽屉，每次只整理一个抽屉——而不是把全部衣服倒在地上混着叠。
关键洞察：实施期测试 ≠ 独立评估
SWE-Bench 等 benchmark 上有个"老千"——agent 能"看测试集猜答案"。
HoH 的解法：把"实施 agent 自己跑的测试"和"loop 间回归判断的测试"强制分开：
- 实施期测试：agent 自己看、自己跑，用来快速迭代本 loop
- 独立评估：agent 永远看不到，只在 loop 结束时批量跑，用来判断"是否真的通过"
这一设计直接回击了"agent 在 benchmark 上作弊"的质疑。
⚠️ 必须看清的 5 个坑
- "Small + Verifiable" 阈值未定义——原文没说"每个 increment 不超过多少行 / 多少函数"。不同团队理解不同会导致验收混乱。建议：先在团队内跑几次，取统计意义上"能在 loop 内验证通过"的增量大小作为阈值。
- Benchmark 不足以代表真实项目——GameCraft-Bench / FrontierSWE / ProgramBench 的代码量与规范度都远低于真实生产项目（几千行–几十万行的遗留代码库）。建议：正式上线前在团队自有代码库上做 pilot，不要只看 benchmark。
- GPT-5.5 的可用性存疑——2026-09 GPT-5.5 是否已正式发布、API 是否稳定可用尚存疑。建议：选择已有稳定 API 的 harness-model 对做主实验。
- 70+ 次迭代 FPS 案例不能当 ROI 锚点——游戏开发（规则明确、反馈快）与真实企业软件（需求模糊、涉众多、技术债累积）差异极大。建议：取 3–5 天的中等规模真实项目做 pilot。
- 独立评估集成本可能被低估——每次 loop 跑全量独立评估可能比开发本身还耗时。建议：实现增量评估（只跑与本次 increment 相关的测试子集），全量只在 milestone 节点跑。
适合谁读
- ✅ 自主软件工程研究者——可作 baseline 或对照
- ✅ AI Coding 产品经理 / 架构师——决定是否走开源栈的元层思路
- ✅ 企业 IT 工程团队——评估"持续 3 天以上的项目"是否值得引入
- ✅ Agentic AI 研究员——"agent 元层"方法学案例
- ❌ 单次 SWE-Bench 任务（HoH 过重）
- ❌ 一次性交付的项目（HoH 收益 < overhead）
一句话给老板
"AI 自动写代码不是'模型越大越强'——多日持续开发的稳定性是系统结构问题，不是模型大小问题。HoH 这种元层思路比'换 GPT-6'更易落地，3 天以上的项目优先评估接入。"
三个标题变体
- 专业向：Coding Agent 多日迭代总在第 8 步崩？arXiv 2609.01481 的 Harness-of-Harness 元层给出 +52.25% 解法
- 大众向：让 AI 连续写 70+ 次代码还能"修一处不崩三处"——这篇 2026 论文把 Agent 框架包了一层"元层"
- 痛点向：AI 写代码第 5 天开始瞎编？答案不是更大的模型，是"持续改进的元层 harness"
📱 小红书风格卡片文案（直接可用）
🌟 今天的 AI 论文神仙现场：
你有没有让 AI 写代码，做个项目3 天后越来越烂？
第 1 天干得漂亮 → 第 2 天开始修 bug → 第 3 天修了 A 崩了 B、修了 B 又崩了 C 😭
你以为这是模型不够强。不！ 这是所有 AI Agent 框架自己埋的雷——
多日迭代没有"持续改进"的系统目标，只有"每次跑完就行"的局部最优。
arXiv 2609.01481（Harness-of-Harness） 想改的就是这件事 ⬇️
✅ 核心思路：包外不包内——不替换已有 coding harness，而是在外面套一层元层 orchestrator
✅ 5 个核心机制： - 🔁 修复 vs 能力增长双轴平衡——修 bug 和加功能各走各的 review 流程 - 🧩 小且可验证的增量——每个 loop 尽量小到 loop 内能验证 - 🪞 实施期 vs 独立评估分离——杜绝 agent 看测试集作弊 - 🚪 渐进暴露交付物 / 工具 / skills——避免无意义重构 - 📜 项目级版本历史——agent 不"忘了昨天做了什么"
✅ 结果震撼： - 三组 harness-model × 三 benchmark 3 次迭代平均 +52.25% - 最大相对增益 +82.86% - 70+ 次迭代无人介入完成一款 FPS 游戏（含主线剧情 + 完整机制 + 视觉打磨 + 音频集成）
✅ 关键洞见： - 跨日开发的稳定性是系统结构问题，不是模型大小问题 - "修复 vs 增长分账"是命门——不分账 → 项目停滞或回归全红 - 两阶段 RAG / Agent 的思路可以套用到 coding agent
📌 对你的工程含义： - 一次性交付项目：HoH 过重，标准 harness 即可 - 3 天以上持续项目：HoH 值得接入，regression cost > overhead - 5 天 + 功能不断扩大的项目：HoH 价值最高，优先接入
🔔 ⚠️ 必须看清的 5 个坑： - "Small + Verifiable" 阈值未定义 → 团队内先跑几次取统计阈值 - Benchmark 不代表真实项目 → 团队自有代码库 pilot 验证 - GPT-5.5 可用性存疑 → 选稳定 API 的 harness-model 对 - FPS 案例不能当 ROI 锚 → 取真实项目做 pilot - 独立评估集成本可能被低估 → 实现增量评估
📎 arXiv 2609.01481 · GitHub: Flesymeb/HarnessOfHarness · 已开源 📅 2026-09-02，三 harness-model × 三 benchmark 一致增益
💬 评论区聊聊：你用过哪些 AI coding 工具？有没有踩过"修一处崩三处"的坑？