最前線の Harness 設計を読み解く

このセクションでは、講義で扱った harness の理論を、現在最先端の実在する製品と一つずつ照らし合わせます。各製品について注目するのは、ただ一つ、その harness がどのように設計されているかです。つまり、モデルを取り巻くエンジニアリング基盤である、指示、ツール、環境、状態、フィードバックという5つのサブシステムと、コンテキスト継続性、初期化、検証、可観測性、ハンドオフ、ループといった中核メカニズムを見ていきます。

モデルの推論能力が高いか、特定のベンチマークスコアが優れているか、あるいは「この agent に何ができるか」といった一般的な紹介は、意図的に扱いません。それらはモデル層やプロダクト層の問題です。ここで読み解くのは harness、つまりモデルの重みパラメータ以外のすべてです。

なぜ読み解く価値があるのか

講義01で述べたように、モデルの能力が高いことと、実行が信頼できることは同じではありません。同じモデルでも、異なる harness に置けば、パフォーマンスに一桁もの差が生じることがあります。しかし、講義が説明するのは「どうあるべきか」であり、これらの製品が答えるのは「トップチームが実際にどうしているか」です。

各製品は、それぞれ独立した設計判断の集合です。並べて比較すると、同じ中核メカニズムが、チームごとにまったく異なる形で実装されていることがわかります。

• Pi は、harness を最小限のコアとプログラム可能な拡張として構成し、「最小限の system prompt + オンデマンド読み込み」でコンテキストエンジニアリングを行います。
• Claude Code は、harness を完全な実行環境として構成します。階層化メモリ、5段階の compaction、permissions、hooks、subagent を備えています。
• Codex は、harness の思想を徹底しています。リポジトリを唯一の事実源とし、AGENTS.md は目次ページにとどめ、worktree で環境を分離します。
• DeepSeek Harness は、harness 自体をモデルから独立した runtime として定義します。Everything is a Plugin という設計です。

記事一覧

• Pi の harness 設計を読み解く：最小限のコア + プログラム可能な拡張により、コンテキストエンジニアリングを system prompt の外側まで広げます。
• Claude Code の harness 設計を読み解く：階層化メモリ、5段階の compaction、permissions と hooks を備えた、完全な agent 実行環境です。
• Codex の harness 設計を読み解く：リポジトリを唯一の事実源とし、AGENTS.md を目次ページとして使い、環境分離とフィードバックループを構築します。
• DeepSeek Harness の設計を読み解く：Everything is a Plugin。agent ループそのものを交換可能な plugin にします。

読み方

まず講義の前半、特に講義02：Harness とは実際に何かを読み、5つのサブシステムのフレームワークを理解してから、ここに戻って実際の製品がこれらのメカニズムをどう実装しているかを見ることをおすすめします。

各記事の末尾には「講義のフレームワークへのマッピング」と「参考にしたい設計」という2つのセクションがあります。製品設計を講義の概念へすばやく置き換え、自分のプロジェクトへ直接取り入れやすくするためのものです。