Agent Harness Report / X Source Summary

プロンプトではなく
ループを設計する

Lance Martin のX投稿を、エージェントハーネス設計の実践メモに変換する。主眼は「賢い一発プロンプト」ではなく、環境フィードバック、独立Verifier、セッション横断メモリを組み合わせた反復システム。

source claim: X投稿要約interpretation: 実装ガイド化official X API not used

結論：プロンプト最適化から、評価可能なループ設計へ

一文で言うと：強いコーディングエージェントほど、直接「もっと考えて」と促すより、環境が採点し、別コンテキストのVerifierが検査し、次回セッションが検証済みメモリを読むループを作った方が伸びる。
source claim

Self-correction

投稿は、/goal や Outcomes のような仕組みで、モデルに実験→測定→修正を回させる重要性を強調している。

interpretation

Verifier分離

同じエージェントの自己批評ではなく、独立コンテキストの採点者を置く。これは「気づき」ではなく「測定」の問題として扱う。

interpretation

Memory protocol

メモリはログ置き場ではない。失敗を検証済み事実に変え、一般ルールへ蒸留し、次セッションが参照する外側ループ。

元投稿が主張していること

このレポートは、Hermes の x_search / Grok によるX投稿要約を材料にしている。以下は独立検証済みの論文結果ではなく、投稿・X検索文脈からの source claim として読む。

Parameter Golf の例

16MB以内の成果物、8×H100で10分以内に良いモデルを訓練するMLエンジニアリング課題で、Claude Managed Agents + Outcomes + 9基準のRubricにより、Fable 5 が Opus 4.7 より約6倍大きく改善した、とされる。

読み方：モデル比較というより「採点・ログ・再実験がある環境で、構造変更まで踏み込めるか」の例。

Continual Learning Bench の例

SQL DBに対する逐次質問を、毎回新しいエージェントセッションで解く。共有ファイルシステムをメモリに使うと、強いモデルは「fail → investigate → verify → distill → consult」まで進む、とされる。

読み方：永続メモリは保存容量ではなく、検証・蒸留・参照のプロトコルが性能を決める。

内側ループ：自己批評ではなく、環境フィードバックで hillclimb する

01
Goal
成功条件・制約・Rubricを固定
02
Act
Agentが変更案・実験を実行
03
Measure
テスト・スコア・ログで評価
04
Verify
別コンテキストが証拠つき採点
05
Patch
次の実験だけを提案・実行
要素悪い設計良い設計
フィードバック「もっと良くして」「自己レビューして」失敗ログ、ユニットテスト、ベンチスコア、制約違反を短く返す
Rubric曖昧な品質語だけ採点基準、必須条件、減点条件、停止条件を明文化
Verifier生成者自身が雰囲気で採点別コンテキスト、読み取り中心、構造化出力、証拠行へのリンク
Iteration無制限に回す時間・コスト・改善幅・回帰閾値で止める

外側ループ：メモリは「保存」ではなく「検証済み知識への変換」

投稿の重要な示唆は、各セッションを切り離しても、共有メモリがあれば学習が蓄積するという点。ただし、生ログを保存するだけでは弱い。必要なのは、検証済み事実と一般化されたルールへの蒸留。

残すべきもの

  • 再現コマンドと結果
  • 失敗原因を確認した証拠
  • 次回も使えるルール
  • 不確実性と未検証仮説
  • 参照したファイル・行・URL

捨てる/隔離すべきもの

  • 未検証の推測
  • 一時ログの全文
  • タスク固有すぎる作業記録
  • 古くなりやすい進捗メモ
  • 秘密情報・認証情報
memory/
  facts.md          # verified only: evidence + date + command/query
  rules.md          # distilled reusable rules; short and declarative
  failures.md       # observed failures with reproduction path
  open_questions.md # hypotheses that still need tests
  receipts/         # logs, scores, screenshots, artifacts

実装ブループリント：Producer / Verifier / Memory の3点セット

役割できること禁止・制限出力
Producer Agentコード編集、実験実行、仮説生成、次アクション選択自分の成果を最終採点しない。メモリへ未検証ルールを書かない。差分、実行ログ、仮説、次の実験案
Verifier AgentRubric採点、ログ確認、テスト結果確認、証拠つき指摘原則読み取り専用。修正実行はしない。pass/fail、score、evidence、uncertainty、next check
Memory Curator失敗と事実を分け、再利用ルールへ圧縮一時進捗や古くなる数値を長期記憶に混ぜない。facts/rules/open questions の更新

最小ループの擬似コード

for i in range(max_iterations):
    candidate = producer.act(goal, constraints, prior_feedback, memory.rules)
    receipts = environment.run(candidate)
    verdict = verifier.grade(candidate, receipts, rubric)
    memory.update_verified_facts(verdict.evidence)
    if verdict.pass_ or budget.exhausted() or improvement_stalled():
        break
    prior_feedback = compact(verdict.failures, receipts.key_metrics)

何を evidence / receipts として残すか

fact

実行可能な証拠

テストコマンド、ベンチ条件、スコア、終了コード、ログ抜粋。後から同じ判断を再現できる粒度で残す。

source claim

外部主張

X投稿、ドキュメント、論文、ブログの主張。誰がいつ何を言ったかを分け、実装判断と混ぜない。

interpretation

自分たちの解釈

次の設計判断、仮説、運用ルール。根拠と不確実性を添えて、あとで破棄・修正できる形にする。

リスクと現実的な制約

コストが先に爆発する

長時間ループ、高性能モデル、GPU実験、別Verifierは高い。最初から「どこに高価なモデルを置くか」を決める。実行全体ではなく、計画・難所・採点に集中投入するのが現実的。

Verifierも間違える

VerifierがRubricを誤読すると、ループは高速に間違った方向へ進む。Verifierの出力にも evidence と uncertainty を要求し、重要判断は人間レビューで止める。

ベンチに過適合する

Parameter Golf のような明確スコア課題はループと相性がよい。一方、実務では評価関数がずれると局所最適へ向かう。proxy metric と本来目的を分けて監視する。

メモリがゴミ屋敷化する

ログ全文、未検証メモ、古い進捗が混ざると次セッションを汚染する。長期メモリには、検証済み・短い・宣言的なルールだけを昇格させる。

次にやるなら：30分 / 1日 / 本番化

30分プロトタイプ

  1. 1つの反復タスクを選ぶ
  2. Rubricを5項目にする
  3. ProducerとVerifierのプロンプトを分ける
  4. ログと採点JSONを保存する
  5. 3反復だけ回す

1日プロトタイプ

  1. 停止条件を入れる
  2. 失敗→検証済み事実→ルールのメモリ更新を実装
  3. Verifierの誤判定を人間が10件確認
  4. コスト/改善幅を可視化
  5. 次回セッションで rules.md を必ず読む

本番化チェック

  1. 権限分離と読み取り専用Verifier
  2. 秘密情報をメモリから除外
  3. 評価関数のドリフト監視
  4. 人間承認ゲート
  5. 成果物・ログ・意思決定の監査可能性

出典・限界

Claude Code was attempted but unavailable due to session limit; Hermes generated this static report directly from the compact source context and design contract.