JA
GEODEの公式ピクセルキャラクター、Geodi
展示室へ戻る

GEODE

Autonomous Agent Harness

観測から、次の行動へ。

調査、ファイル作業、予約タスクを任せられる、ローカルの自律エージェント・ハーネスです。

2026.02.21 — present

設計・判断・検証: Author · 実装: Claude · レビュー: Codex

  • CLI一般公開 · PyPI
  • MCPサーバー実装済み

ロールアウトから根拠へ

成功率だけでは実行を説明できません。イベントの順序、ツール呼び出しと結果、再試行の系譜、独立した検証器の根拠を保存し、公開できる部分をつなぎます。以下の実験は、記録と評価の契約がどのように発展してきたかを示します。

実験別 · 日付順

6つの実験は日付順に並べたもので、1つにつながった最適化の過程ではありません。SILがCrucibleやJevへ自動的につながることはなく、製品としてのGEODEが改善し続けたという主張でもありません。日付は実験と公開スナップショットの日付で、矢印は1つの実験内の段階にだけ使っています。

  1. June 3, 2026 to June 4, 2026SIL · 外部のポリシー探索

    1回の監査で得たKEEPを、反復測定で再確認

    問いポリシーの変更は、監査のノイズを超えてツール使用の行動を改善したか？

    外部の実験 · GEODEランタイムの外

    1. ベースライン · K=5
    2. ポリシー変更1つ
    3. Petri監査
    4. 反復測定
      • 保持
      • 復元
    変わったこと
    この実験では、変更に対する1回の監査に反復測定を加えてから、保持か復元かを決めました。難易度をそろえたシードとK=5のベースラインを加え、never、random、gateの3つのarmで、変更なしで生じる変動と採択された変更とを分けています。
    示すこと
    再測定すると、1回の監査で保持された候補はベースラインより悪かったため（低いほど良い）、採択を元に戻しました。この実験の結論は、確かな改善なしです。Petri broken_tool_useの行動監査であり、タスク完了の報酬ではありません。

  2. July 11, 2026 to July 13, 2026Crucible · 外部の実験カーネル

    探索に残す判定と、製品に届ける判定は別

    問い候補を探索に残す根拠は、製品へ昇格させてリリースする根拠と同じか？

    外部のCrucibleカーネル · 別の測定用checkout

    1. 候補 · 親の系譜
    2. 凍結契約の検査
    3. ペア測定
      • KEEP別のsealed判定へのみ
      • REJECT
      • INVALIDnull、0%ではない
    変わったこと
    却下された候補や無効な候補も親の系譜とともに保持し、trainでの選択、sealedの適格性、製品リリースの権限を別々の記録にしています。
    示すこと
    r14はtrainでKEEP（6タスク単位、各1試行、昇格権限なし）でしたが、別のsealed判定ではREJECT（製品への昇格・リリースの権限なし）でした。r35はカバレッジ不足とインフラの汚染によりINVALIDで、ペアの行がないため平均はnullのままです。これはランタイムの自己修正でも、SIL → Crucibleのデプロイの連鎖でもありません。

  3. July 21, 2026 · July 31, 2026整備 · 公開

    残った記録を分類し、共有できるものだけを不変のリリースに

    問い実際に再構成できるものは何か、安全に共有できるものは何か？

    1. 非公開のソースセッション記録 · ネイティブの証拠ネイティブの結果 · 検証器を含む
      • 正規化イベント順序 · 識別子を保持
    2. 正規化イベント識別子 · 順序 · 呼び出しと結果のペア
      • 公開候補許可リスト · 秘匿化 · ダイジェスト
    3. 公開候補レビュー中
      • 完全性 · プライバシーの検査検査
    4. 完全性 · プライバシーの検査ペアリング · 系譜 · スコープ
      • 不変のリリースレビュー済みのバイトのみ
    5. 公開リポジトリ不変のリリースマニフェスト · ネイティブの結果はダイジェストで参照
      • リモートの読み戻しハッシュを確認
    6. リモートの読み戻し固定したSHA-256
    変わったこと
    2026年7月21日のインベントリでは、対話・ツール・探索・判定の記録をソースごとに分類し、同じソースの重複は独立した例として数えていません。2026年7月31日からは、geode.trajectory@1とgeode.trajectory-release@1が、識別子、イベントの順序、呼び出しと結果のペア、スコープとリプレイの完全性、内容に結び付いたマニフェストを明示します。変換された公開版と原本は、別々のダイジェストを持ちます。
    示すこと
    ここでいう整備とは、正規化、相関付け、明示的な秘匿化、系譜、公開の承認を指します。隠れた推論を再構成することでも、学習に使えるデータセットを宣言することでもありません。非公開の本文がダイジェストに置き換えられている場合、スコープが完全でも、バイト単位のリプレイは完全ではありません。

  4. August 25, 2026Learning view

    1回のロールアウトとその証拠を、識別子で結び付けた

    問いどの入力、試行、イベント列、報酬が組になるのか？

    geode.eval-learning-view@2 · IDと検証済みダイジェストで結合、因果の順序ではない

    1. example
    2. rollout
    3. trajectory
    4. reward

    報酬は、ネイティブの検証器のreceiptが所有します。インフラの再試行は、1つのロールアウト内の試行です。

    変わったこと
    不変の実行記録をスコープを限った結合で再利用し、報酬は評価器が所有する派生ラベルのままにします。インフラの再試行でロールアウトは増えません。観測された0は保持し、報酬がなければnullです。無効または中断された試行は報酬の選択から除外されます。有効性はロールアウトの性質であり、自動的にnullの報酬になるわけではありません。
    示すこと
    Harbor 0.8.0でのTerminal-Bench fast-3の実行（3タスク、3/3）と、Tau2の3ドメインの診断（1/3、有効な0が2つ）を同じ構造で結び付けています。これらはポストトレーニングの候補であり、学習に使ったデータセットでも重みの改善の証拠でもありません。また、3タスクの結果はスイート全体の正答率ではありません。

  5. August 27, 2026 to September 5, 2026Harbor · Terminal-Bench 2.1

    1回のtrialで、結果とリプレイの記録を別々に作成

    問い実際のタスク実行は、どのように結果と検査可能なリプレイになるのか？

    1. 凍結されたタスク · spec事前に固定 · 5回の反復
      • 隔離されたtrial指示 · 環境 · 上限
    2. Harbor 0.22.0のtrial · 実際の実行隔離されたtrialactorとしてのGEODE
      • 行動と最終状態実行
    3. 行動と最終状態観測された行動
      • タスクが所有する検証器タスクの状態を確認
      • ATIF · 公開イベントへの投影記録されたイベントを投影
    4. タスクが所有する検証器
      • ネイティブの報酬 · receipt報酬
    5. ネイティブの報酬 · receipt
      • 選ばれた試行の分析凍結された選択
    6. ATIF · 公開イベントへの投影後処理 · 新しい実行ではない
    7. 選ばれた試行の分析凍結された選択ルール
    変わったこと
    凍結したspec、すべての試行、選ばれた結果、タスクが所有する検証器、忠実だが範囲の限られたリプレイを、互いにリンクした別々の記録として保持しています。Harbor 0.22.0でGPT-5.6 Sol/maxにより5回反復し、GEODE（当時は単一のターミナルツールのアダプター）とCodexを比較しました。
    示すこと
    タスクは指示・環境・テストを持ち、trialは1回の試行、jobはtrialの集まりです。報酬はタスクが所有する検証器が決め、GEODE内部の完了判定は実行時のフィードバックです。公開リプレイは記録されたツールイベントの事後投影であり、生のPTYでも新しい実行でもありません。欠けたセルにコマンドを作り足してはいません。事前登録した主要指標は測定できませんでした。

  6. September 24, 2026 to September 28, 2026Jev · 判断の委任

    候補が正しくても、引き渡しには別の検証が必要

    問い委任した判断は、実際にタスクの品質と最終的な引き渡しを保つのか？

    1. U8n · Noulの実行 · Harbor 0.22 · 実行と修正はAstra、変わるのは判断の経路だけ決定の状態タスク契約 · 候補 · ツールの観測
      • 判定 · Noul判定の入力
    2. 判定 · NoulAstraまたはJev
      • GEODEが消費条件ごとの確率
    3. GEODEが消費充足なら引き渡し、根拠不足なら保留
      • 最終的な引き渡し充足
      • Astraによる修正根拠不足 · 保留
    4. 最終的な引き渡し
      • 独立した結果検証引き渡された結果
    5. Astraによる修正フィードバック後の次の候補
      • 判定 · Noul再び判定
      • 最後の候補 · 保存最後の候補を保存
    6. 独立した結果検証ルールoracle · 引き渡された結果
    7. U3の固定パネル判断のみ · actor、ツール、Harborなし
    8. 事後診断 · 実行の後最後の候補 · 保存
      • 事後のoracle診断事後の検査
    9. 事後のoracle診断候補の正しさ · 引き渡しには影響なし
    変わったこと
    判断の受け入れ、候補の正しさ、最終的な引き渡しを別々の結果として記録し、準備・失敗・修正の系譜を公開版に保持しています。原本と変換後の公開版のハッシュは分けています。
    示すこと
    中断されたU8n研究の事後11ペアでは、最後の候補は両方のarmで正しかったものの、引き渡しはAstra 11/11、Jev Noul 0/11でした。Jev Noulの根拠不足の判定が引き渡しを止めたためです。事後分析であり、一般化はしません。公開された数値の再計算、リプレイの確認、新たなライブ実行は、それぞれ別の操作です。