Harness-of-Harness 以規劃、開發、獨立測試迴圈延長程式代理工作期，但核心實作尚未公開

Harness-of-Harness（HoH）不是新的基礎模型，而是套在 Codex、OpenCode、Pi 等既有程式代理外面的長週期控制框架。每一輪由 Planner 根據需求與上一輪證據產生小幅、可驗證的開發計畫；Developer 在共享工作區實作並執行局部測試；唯讀的 QA Tester 再以白箱與黑箱方式檢查完整性、功能和可用性。測試報告成為下一輪輸入，而隱藏評測結果不會回流，意在降低直接針對 benchmark 過度適配的風險。

框架不要求代理遵循固定推理步驟，而是約束計畫、程式成品與測試報告等輸出格式；不合規輸出會重試。長期狀態透過版本化工作區與檔案索引保存，詳細資料按需載入，以免把全部歷史塞進上下文。這種設計把「記憶」轉化為可檢查的工程產物，也讓重大退步可以回到先前驗證版本。

研究以 Codex＋GPT-5.5、OpenCode＋DeepSeek-V4-Pro及 Pi＋MiniMax-M3 測試 GameCraft-Bench、FrontierSWE 與 ProgramBench。三輪 HoH 相較單次原生代理平均相對提升 52.25%；其中 Codex 在 FrontierSWE 的 dominance score 由 44% 升至 71%，十輪測試則由 22% 增至 72.67%。團隊另展示超過 70 輪完成可遊玩 FPS，但這不是受控 benchmark。

工程團隊應先把結果視為「迭代協定可能比單次更有效」的證據，而非無人值守開發已成熟。主要實驗每個任務與條件僅跑一次，模型端沒有共同可重現 seed，token 統計也因供應商快取口徑不同而不能跨模型比較。更關鍵的是，GitHub 目前只有論文、素材與展示，承載核心流程的 HoH-lite 尚未釋出；真正的部署成本、故障恢復與安全邊界仍待重現。