# Agent Harness Engineering: A Survey（一次情報精読・2026-06-20）

> HN等で通称「The 98% Problem」と呼ばれる論文の本体。一次情報（OpenReview PDF・pdftotext抽出）を§1〜§12全層精読した記録。
> 出典: https://openreview.net/pdf?id=eONq7FdiHa （TMLR査読中・Under review）/ Project: Awesome-Agent-Harness

## 書誌

| 項目 | 内容 |
|------|------|
| 正式タイトル | Agent Harness Engineering: A Survey |
| 著者 | Junjie Li(CMU), Xi Xiao, Yunbei Zhang, Chen Liu 他19名 |
| 所属 | CMU / Yale / JHU / NEU / Tulane / UAB / OSU / Virginia Tech / **Amazon** |
| 規模 | 本文48頁＋付録・**170+ OSSプロジェクトをマッピング**（agent-harness最大コーパス） |

⚠️ **「60% vs 98%」はブログの脚色で論文本体に無い**。論文の実証主張は下記の3結果（mod固定・harnessのみ変更）。

## Claim 1: Binding-Constraint Thesis（モデルでなくハーネスが律速）

モデルを固定しハーネスのみ変えた3つの実証：

| 実証 | 結果 | 変えたもの |
|------|------|-----------|
| Bölük (2026a) | コーディングベンチで**最大10倍**（15モデル横断） | edit-toolフォーマット＋周辺ハーネスのみ |
| Trivedy (2026) | GPT-5.2-Codex 52.8%→**66.5%**（Terminal-Bench 2.0・**+13.7pt**） | system prompt再構成・context注入・self-verifyフックのみ |
| Meta-Harness (Lee 2026) | Terminal-Bench-2 **76.4%**（全手動ハーネス凌駕） | 自動ハーネス最適化（モデル重み不変） |

→ いずれも有意とされるモデル改善（典型2〜4pt）を遥かに上回る。これが「98%問題」の実体。

## Claim 2: ETCLOVG 七層分類

従来6要素フレームに **Observability と Governance を独立層として追加**：

- **構造コア4層**: E(Execution/sandbox) / T(Tooling) / C(Context/memory) / L(Lifecycle/orchestration)
- **制御プレーン3層**: O(Observability) / V(Verification) / G(Governance)
- state管理はL層内（実行フローの隣）に配置

## Claim 3: 170+ OSSマッピング

E/T/L/Vは密、**O/Gは薄く商用プラットフォームに偏る**。task runners・multi-agent orchestrator・spec-driven開発ツールが新規に第一級カテゴリ化。

## 最重要知見: Context Drift（最難の未解決問題・§5.7）

- **Context Rot ≠ Context Drift**。Rot=単一推論で文脈過多→劣化。Drift=**100ターン超の軌跡全体で意図からズレる**
- 症状: 既出作業の反復・過去決定との無自覚な矛盾・目標喪失
- **compactionでも防げない**: 圧縮のたびに要約の微小不正確が複利的に発散。**そのズレを検知する仕組みが現アーキテクチャに無い**
- 結論: **context engineering単独では長期信頼性は解けない**。verifierループ＋戦略的human-in-the-loopチェックポイント＋異常検知（O層・G層）が必須補完

## §11 クロスレイヤー3問題

1. **Cost-Quality-Speed Trilemma**: 品質はスカラー目標化不可。「どのチェックを非同期/回帰スイートに回すか」を判断する設計問題
2. **Capability-Control Tradeoff**: 権限増＝制御問題拡大。セキュリティは後付けでなく設計軸
3. **Harness Coupling Problem**: 層は密結合し局所最適が脆い。**「ハーネス変更はシステム変更としてテストせよ」**
- §11.4 核心命題: 問いが「どうエージェントを作るか」→**「どうエージェント艦隊を inspectable かつ reversible に運用するか」**へ移行（frameworks→platforms）

## §12 五つの未解決問題

1. 実行環境の堅牢化・スケール（SandboxEscapeBenchでsandbox突破実証・1コンテナ/タスクは数万並列で破綻）
2. 長期状態維持＝**context管理を state estimation として再定義**（各圧縮で失う情報量を定量化・内部状態と実状態の乖離をboundできるか）。要: uncertainty-aware要約・provenance・矛盾処理・staleness markers・artifactからの状態再構成
3. **trace-native評価**: 失敗はモデル推論だけでなくtool schema/sandbox/stale context/flaky test/judge不安定が起源。「評価層は測定器として研究せよ、leaderboard生成器でなく」
4. **標準ハンドオフ契約**: text要約だけでなく intent/constraints/permissions/artifacts/provenance/budget/risk/trace/未解決判断 を移譲。OpenAI Symphony（issue tracker=control plane）を明示引用
5. **モデル改善時のscaffolding陳腐化**: 「scaffoldingは単調増加と仮定するな」。Anthropic実例「あるモデルで有用なcontext resetが強いモデルで不要に→削除でコスト減・品質不変」。harnessは自己最適化・自己単純化が必要（Meta-Harness/NLAH）

## production principles 具体数値（重要実証データ）

- **LangChain 2026調査: 観測性は89%導入・offline評価は52.4%のみ** = 「エージェントが何をしたかは見えるが、正しかったかを体系的に判定していない」構造的断絶（§7.5・§12.3）
- **Anthropicハイブリッド文脈枠組み**（§5.6）: 常時必要=pre-load / 条件付き=just-in-time retrieve / 窓飽和=compact / 探索でorchestrator汚染=sub-agent spawn。「**context管理はインフラの仕事でエージェントの仕事でない**」
- **Manus**: 単純subtask=context非共有 / 複雑subtask=full共有（共有はKVキャッシュ再利用を潰すのでタスク型ごと明示判断）
- **OpenAI**: 小チームが5ヶ月で約100万行の内部製品を「production codeを手書きせず」生成（harness engineeringの定義文脈）

## 当環境（shadow）への突き合わせ

| 論文の核心指摘 | shadowの現状 |
|--------------|------------|
| O層（観測性）普及 | agentboard/ccusage/PM2ログでカバー済 ✅ |
| **V層（trace→自動回帰評価）が手薄（52.4%）** | skill_eval_logはあるが「異常traceを回帰ケース化」する自動ループが無い ⚠️ |
| §12.4 標準ハンドオフ=OpenAI Symphony | retry-policy.mdはSymphony由来だがハンドオフ契約（intent/budget/risk移譲）未実装 ⚠️ |
| §12.5 scaffolding再評価 | contribution-tracking.md（死蔵物棚卸し）がこの思想の萌芽 ✅ |
| Context Drift対策=verifier別エージェント | goal-judge・敵対的相互検証で対応済 ✅ |
| 状態を外部書き出し（state estimation） | MMPO対策のstate.json/git書き出し方針と整合 ✅ |

**結論**: shadowで論文的に最も投資価値が高いのは **V層（Verification）の自動回帰ループ**（§12.3 trace-native評価・89%/52.4%ギャップにピンポイント一致）。今朝(2026-06-20)の横断学習Action①「評価ハーネス構築（trace保存＋自動評価パイプライン）」と完全合致。

## 関連
- 横断学習 2026-06-19 / X Learn ハーネス設計エントリ群（伝聞・要約版。本ページが一次情報）
- multi-model-routing.md（goal-judge/敵対的相互検証=Context Drift対策）
- contribution-tracking.md（§12.5 scaffolding再評価の萌芽）
- retry-policy.md（OpenAI Symphony由来）