企业官网建设流程全解析

最前線の Harness 設計を読み解く：Pi・Claude Code・Codex・DeepSeek を5サブシステムで比較する

【免费下载链接】learn-harness-engineeringHarness engineering beginner tutorial, from 0 to 1项目地址: https://gitcode.com/gh_mirrors/le/learn-harness-engineering

本記事は、Learn Harness Engineering の「最前線の Harness 設計を読み解く」セクション全体を、講義で扱った5サブシステム（指示・ツール・環境・状態・フィードバック）と、コンテキスト継続性・初期化・検証・可観測性・ハンドオフ・ループといった中核メカニズムのフレームワークで通読するための技術ガイドです。Pi、Claude Code、Codex、DeepSeek Harness という4つの実在製品が「同じ中核メカニズムをチームごとにまったく異なる形で実装している」ことを突き合わせて理解し、最終的に自分のプロジェクトへ取り入れられる設計判断を抽出できるようになります。

このセクションが何を問いかけているか

このセクションの目的は、製品の機能紹介ではありません。モデルの推論能力の高さやベンチマークスコア、「この agent に何ができるか」といった一般的な紹介は意図的に扱いません。それらはモデル層・プロダクト層の問題だからです。ここで読み解くのはharness、つまり「モデルの重みパラメータ以外のすべて」—— モデルを取り巻くエンジニアリング基盤（指示、ツール、環境、状態、フィードバックの5サブシステム）が、最先端の実在製品でどのように設計されているか、ただその一点です。

この視点には明確な根拠があります。講義01で述べられているように、モデルの能力が高いことと、実行が信頼できることは同じではありません。同じモデルでも、異なる harness に置けばパフォーマンスに一桁もの差が生じることがあります。講義が説明するのは「どうあるべきか」であり、これらの製品が答えるのは「トップチームが実際にどうしているか」です。各製品は独立した設計判断の集合であり、並べて比較すると、同じ課題に対してまったく異なる解答が存在することが見えてきます。

前提となるフレームワーク：harness の5サブシステム

製品の設計を読む前に、比較の座標軸となるフレームワークを確認します。講義02「Harness とは実際に何か」 は、harness を5つのサブシステムとして定義します。キッチンの5つの機能領域に例えられます。

このフレームワークの中心的な考え方は、「マニュアルではなく地図を与える」「細かく管理するのではなく制約を与える」「コンポーネントを一つずつ削除して限界貢献を定量化する」の3点です。フィードバックサブシステムの具体例として、講義02は次のような検証コマンドの書き方を示しています。

Verification commands: - Tests: pytest tests/ -x - Type check: mypy src/ --strict - Lint: ruff check src/ - Full verification: make check (includes all above)

講義02には、このフレームワークをコードで確認できる実例も付属しています。

• harness-vs-no-harness.ts：同じタスク実行を harness あり・なしで並べ、ルール（認証付きエンドポイントにはテスト必須、スコープ外タスクはブロック）と検証が「見逃されていた問題」をどう検出するかを対比します。
• minimal-harness-loop.ts：エージェントの本質が「推論 → ツール実行 → 観察 → 再推論」の while ループであることを示す最小実装です。
• harness-components.md：システムプロンプト、AGENTS.md、bash ツール、起動スクリプト、停止フック、評価ループなど、ローカルリポジトリで作業するコーディングエージェントの harness 構成要素一覧です。いずれかの要素を変更すると実質的なエージェントが変わります。

講義02の実話も、このフレームワークの説得力を示します。あるチームが GPT-4o で約2万行の TypeScript + React アプリに取り組み、harness を段階的に追加するだけで成功率が20%（空のキッチン）→ 60%（AGENTS.md 追加）→ 80%（検証コマンド追加）→ 80〜100%（進捗ファイル導入）と変化しました。モデルは一度も変えていません。より高価な食材を買ったのではなく、キッチンを適切に整理しただけというのが、このセクション全体の前提です。

4製品の設計思想の俯瞰

このセクションが取り上げる4製品は、それぞれが harness に対する異なる立場を体現しています。

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

これらを「足し算」と「引き算」で整理する見方もあります。Claude Code はメモリ・permissions・subagent をコアへ組み込む足し算、Codex はコアをできるだけ抑制してリポジトリ規約とコンテキストエンジニアリングへ責任を移す引き算です。Pi は何も代わりに決めないことを選び、決定権を拡張点へ委ねます。DeepSeek Harness はその先の**「harness を OS にする」**設計です。

製品別に読む：4つの設計判断の詳細

以下、各製品の詳細です。本セクションの4記事（Pi・Claude Code・Codex・DeepSeek）の内容を、5サブシステムの観点から要約します。

Pi：最小コア + プログラム可能な拡張

Pi の公式の位置づけは "minimal agent harness"（最小限の agent harness）です。「最強の coding agent」ではなくharnessという言葉に自らの立場を定めています。ホームページの "Ask Pi to build what you want, or install a package that does it your way" という言葉どおり、コアを意図的に小さくし、決定権を利用者へ戻します。Pi は harness を4層のカスタマイズ可能な要素に分解しています。

• Extensions：ライフサイクルイベントに接続する TypeScript hooks。runtime レベルのプログラム可能なインターフェースです。
• Skills：指示とツールを含み、オンデマンドで読み込まれる能力パッケージ。progressive disclosure を採用します。
• Prompt templates：再利用可能な Markdown prompt。/nameと入力すると展開されます。
• Themes：TUI の外観です。

この階層化そのものが一つの harness 設計です。「モデルに何を見せるか、いつ見せるか」をコアへハードコードせず、ルールと拡張へ完全に委ねています。

指示サブシステムでは、AGENTS.md をグローバル（~/.pi/agent/AGENTS.md）→ 親ディレクトリを上へ順にたどる → 現在のディレクトリ（./AGENTS.md、CLAUDE.md にも対応）の順に読み込み、SYSTEM.md でプロジェクト単位のデフォルト system prompt を replace / append できます。これは「リポジトリを唯一の事実源にする」原則の実践であり、講義04「単一の巨大な指示ファイルが失敗する理由」を「最小のコア + ファイル分割 + オンデマンド読み込み」で回避する設計です。

状態とコンテキストの領域は、Pi が最も細かく分解したところです。

1. Compaction をプログラム可能にする：コンテキスト上限に近づくと古いメッセージを自動要約しますが、その戦略自体をカスタマイズできます。トピック単位の compaction、コードを認識した要約、要約専用モデルの指定が可能で、デフォルトでは分割点より後の直近約2万 token を保持し、それより前を "context handoff" に要約して段階的に連鎖させます。
2. Dynamic context：Extensions が各推論の前にメッセージを注入し、履歴をフィルタリングし、RAG や長期メモリを構築できます。コンテキストが満杯になってから compaction するのではなく、情報が入る前に何を入れるか決められます。
3. Session tree：sessions はツリーとして保存され、/treeで履歴上の任意のノードへ戻って続行できます。要約だけで無理につなぐのではなく、構造化された履歴のリプレイでセッションをまたぐ継続性を確保します。分岐は HTML へエクスポートや gist での共有も可能です。

ツールサブシステムのうち、Extensions は Pi で最も重要な設計判断です。単に「設定スイッチを渡す」のではなく、runtime 内部のイベントインターフェースをすべて公開しています。メモリを追加したいならagent/pre-stepで注入し、動作を記録したいなら session イベントを購読し、モデルへのリクエストを変更したいならagent/requestに hook します。公式の用途例には、危険なコマンドの阻止（permissions のゲート）、タスク切り替え時のコード状態の checkpoint、.envなどパスの書き込み禁止、モデルへ渡す前のツール出力の変更、外部（ファイル監視 / Webhook / CI）からのメッセージ注入が挙げられます。

フィードバックと検証について、Pi 自体に強制的なテストゲートは組み込まれていません（検証コマンドは利用者が AGENTS.md に記載します）。しかしコミュニティの harness（pi-agent-harness）は Extensions によってフィードバックループを構造化しています。PROGRESS.mdのローリングエントリを維持するsession-summary、session から教訓を集めてLESSONS.mdへ蓄積するextract-patterns、token 使用量やコストを記録するtelemetryが代表的です。VISION.md（目標）・PROGRESS.md（進捗）・LESSONS.md（教訓）・STANDARDS.md（標準）をすべて Markdown ファイルとしてセッションをまたいで永続化するこのパターンは、講義が推奨する「リポジトリを唯一の事実源にする + 進捗ファイル + ハンドオフ」と完全に一致します。

Claude Code：完全な agent 実行環境

Anthropic は『Effective harnesses for long-running agents』で、信頼性の源泉はモデルではなく harness であり、agent は「モデルの外側」で制約される必要があると述べています。Claude Code はこの考え方を製品化した例であり、階層化メモリ、5段階 compaction、permissions、hooks、subagent、session 永続化といった、講義に登場するほぼすべての中核メカニズムが完全に製品化されています。

指示サブシステムの特徴は、scope ごとに階層化されたメモリ体系です。公式ドキュメントによれば、各セッションはまっさらなコンテキストウィンドウから始まり、2種類のメカニズムでセッションをまたいで知識を持ち越します。CLAUDE.md ファイル（ユーザーが書く指示）と auto memory（Claude 自身が書くメモ）です。CLAUDE.md は読み込み順が広いものから狭いものへ4種類に分類されます。

• 組織ポリシーレベル：IT/DevOps が一元管理する企業レベルの規約（例：/etc/claude-code/CLAUDE.md）。
• ユーザーレベル~/.claude/CLAUDE.md：プロジェクトをまたぐ個人の好みとルール。
• プロジェクトレベル./CLAUDE.mdまたは./.claude/CLAUDE.md：プロジェクト構造・技術スタック・検証コマンドを記載し、リポジトリで共有する事実源。
• ローカルレベル./CLAUDE.local.md：プロジェクト内での個人的な好み。通常は.gitignoreに追加して commit しません。

さらに、サブディレクトリ内の CLAUDE.md は起動時には読み込まれず、Claude がそのディレクトリのファイルを読むときに初めてコンテキストに入るオンデマンド読み込み、および Claude がユーザーの修正や好みに基づいて自発的にメモを書くauto memory（リポジトリ単位で共有、worktree をまたいで有効、各セッションでは先頭200行または25KBまで読み込み）があります。「具体的な指示ほど後からコンテキストへ入る」ため、プロジェクトの指示はユーザーの指示より後に現れます。これは講義04に対する製品レベルの回答です。

コンテキストサブシステムの要は、単なる「満杯になったら要約する」仕組みではなく、5段階の compaction pipelineです。まず可逆的な pruning（冗長なツール結果の除去）を行い、次に構造化して抽出し、最後に初めて不可逆的な LLM 要約を使う多段階の漏斗で、過度な compaction を防ぐ circuit breaker も備えます。これを支えるのが追記型 session ストレージです。すべての履歴をhistory.jsonlへ追記し、/resumeによる復元と fork 分岐をサポートします。ハンドオフが保証されるのは「記憶力が高いから」ではなく、「ストレージ層が追記型でリプレイ可能だから」です。

ツールサブシステムは4種類の拡張メカニズムに分かれ、それぞれが異なる問題を解決します。

• Skills：SKILL.mdで記述する手続き的知識。トリガーワードで自動読み込みされ、progressive disclosure を採用します。「何かをどう行うか」というドメイン知識向け。
• MCP：JSON-RPC プロトコルで外部システムへ接続する標準インターフェース。「モデルの手を外部世界へ届かせる」ためのもの。
• hooks：PreToolUse/PostToolUse/Stopなどのライフサイクルイベントへ接続する決定論的なスクリプト。
• plugin / subagent：複雑なタスクを専門化した agent へ分割して実行する仕組み。

重要な設計は責務の分離です。CLAUDE.md は「何であるか」、Skills は「どう行うか」、MCP は「どこへ接続するか」、hooks は「いつ強制するか」を担います。これらの層を混同すると（たとえば MCP が担うべきことを CLAUDE.md に書くと）、コンテキスト漏れが起きます。

フィードバックと検証は3つの経路で実装されます。

1. permissions システム（決定論的な制約）：全操作を一つずつ確認するのではなく、7種類のモードと ML ベースの分類器で、低リスク操作は許可し高リスク操作はポリシーに従って確認・拒否します。講義07の「agent に境界を明確にする」を prompt ではなく runtime で強制します。
2. hooks（早すぎる完了宣言の防止）：PostToolUsehook はツール実行後にチェックを強制して結果をコンテキストへ書き戻せ、Stophook は agent が完了を宣言するときに介入します。Anthropic は agent が自信満々に自らの成果を称賛する（"confidently praised their work"）ことを観察しており、モデルの自己評価を信頼せず決定論的なチェックを注入します。これは講義09のテーマへの回答です。
3. subagent（コンテキストの分離）：各 subagent の対話記録は独立した sidechain ファイルに保存され、親 agent のコンテキストを膨張させません。タスクの分割と同時にコンテキスト汚染も分離します。

可観測性と session 永続化の面では、追記型の完全な記録（history.jsonl）に加え、/compact・/clear・/initという明示的コマンドで状態を能動的に管理できます。特に/initは「agent が作業前に毎回初期化する」（講義06）を一つのコマンドにしたもので、コードベースを自動分析してビルドコマンド・テスト手順・プロジェクト規約を含む最初の CLAUDE.md を生成します。

Codex：リポジトリを唯一の事実源に、AGENTS.md は目次ページ

OpenAI の『Harness Engineering』という記事自体が、Codex を使って製品を開発した経験のまとめです。したがって Codex の harness 設計を読み解くことは、その記事の背後にあるエンジニアリング実践を読み解くことでもあります。Codex の思想は次の一文に要約できます。リポジトリを唯一の事実源（repository as the system of record）にし、AGENTS.md は目次ページにとどめる。エンジニアリングの価値は、環境を設計し、意図を表現し、フィードバックループを構築することにある。

指示サブシステムで最も影響力のある設計は、「AGENTS.md は百科事典ではなく目次ページ」という原則です。単一の巨大な指示ファイルは機械的なチェック（カバレッジ・更新状況・所有者・相互リンク）に適さず、現実との乖離を避けられません。AGENTS.md は約100行程度に抑え、収まらない内容はdocs/ディレクトリへ分割して agent がオンデマンドで読みます。これを支える原則は、実装を細かく管理せず、不変条件を強制することです（"don't micromanage the implementation; focus on invariants"）。AGENTS.md には違反できない厳格な制約と検証コマンドだけを記載し、具体的な実装方法はモデルへ任せます。これは講義02の「細かな指示ではなく制約を与える」に直接対応します。

コンテキストエンジニアリングは4つの戦略にまとめられます。

• Write（外へ書き出す）：コンテキストをウィンドウの外側へ永続化します。結論はドキュメントへ、状態はファイルへ書き、対話内だけに残しません。
• Select（中へ選び入れる）：必要な token だけをウィンドウへ取り込みます。AGENTS.md で案内し、ファイルをオンデマンドで読み、リポジトリ全体を詰め込みません。
• Compress（圧縮する）：本当に重要な情報を残します。自動 compaction と手動の/compactがあり、compact_promptをカスタマイズできます。
• Isolate（分離する）：コンテキストを異なる境界へ切り分けます。フロントエンドの subagent がバックエンドのデータベース schema を見ることがないように、subagent でタスクごとのコンテキストを分離します。

環境コンテキストの細かな工夫としては、環境が変化したときだけ変更されたフィールド（CWD、git branch、ファイルシステム）を出力し、毎回完全なシステムコンテキストを貼り直さない実装（build_environment_update_item）が知られています。これは「コンテキスト内で重複 token を増やさない」ためのエンジニアリングです。

ツールと境界の面で、Codex には2つの中核メカニズムがあります。

1. git worktree による環境分離：各タスクを独立した git worktree で実行し、ローカルの可観測性スタック（ログ・メトリクス・トレース）と組み合わせて、各変更を独立した環境で検証します。これは講義07の「agent に各タスクの境界を明確にする」の物理的な実装であり、境界を指示でお願いするのではなく環境分離で強制します。
2. コアレベルの subagent：spawn_agent/wait_agentはコアレベルのツールです。モデルが明示的に subagent を作成し、独立した session 履歴とツールセットを与えて結果を待ちます。subagent は親の AGENTS.md の指示を継承しますが独自のコンテキストで動作し、設定は.codex/agents/*.tomlに置いて異なるモデルと指示を指定できます。各 subagent は明確な境界を持つ作業単位であり、講義12の「ハンドオフ」の考え方も体現しています。

フィードバックサブシステムでは、AGENTS.md に検証コマンドを明記し、「正しくできたことをどう確認するか」をリポジトリの一部にすることが最も強調されています。テスト、CI、ドキュメント、可観測性設定のすべてを Codex が生成し、そのすべてが実行可能な検証経路になります。強力だが信頼できないモデルへの解決策は、モデルの自発性を祈ることではなく、検証経路を harness のデフォルトコンポーネントにすることです。加えて approval policies と plan mode は、高リスク操作の前に計画を提示して承認を求めることで、「タスク境界」と「人間の決定権」を runtime の制御として実装します。

DeepSeek Harness：Everything is a Plugin

DeepSeek Harness（コマンド名dsh）は、公式定義をAgent = Model + Environment + Tools + Stateとしています。これまでの3製品の分析が「harness をどう設計すべきか」という問いだったのに対し、DeepSeek Harness はさらに大胆な問いを投げかけます。harness は特定のモデルから切り離され、独立した runtime になれるのか。その答えは「できる」であり、アーキテクチャドキュメントはEvery part of the product is a plugin, including the model adapter, the tool registry, the session log, and the agent loop itself（製品のすべての部分が plugin。モデル adapter、ツール registry、session log、さらには agent loop 自体も含む）と説明しています。これは「モデルの重みパラメータ以外のすべてが harness」という言葉を最も徹底して実践した設計です。harness が独立したものであるなら、独立した OS にしてしまおう、というわけです。

アーキテクチャの中核は3つあります。

1. Capability Seam：能力を Service として表し、ほぼすべての能力を3層に分けます。

Service Definition ↓ Service Provider ↓ Consumer

ファイルシステムを例にすると、FS Service の下に Local FS / E2B FS / Remote FS という複数の Provider があり、上位には統一された file tools として公開されます。Shell、Subprocess、Sandbox、Web、LLM、SubAgent も同じ構造です。capability seam は「インターフェースを宣言する Service Definition、それを実装する Service Provider、それを使用する Consumer（通常はモデル向けツール）」という3つの役割を持つ交換可能な能力です。これは「agent は具体的なツールに依存すべきか、能力インターフェースに依存すべきか」という長年の問題への解答で、後者を選びます。Provider を交換してもモデルに公開されるツールの形は変わりませんが、環境は完全に変わります。講義の観点では、ツールサブシステムがインターフェースとして標準化されたことを意味します。

2. Event Pipeline：内部は単純な「LLM → ツール → LLM」ではなく、各段階が plugin から監視できるイベントポイントになっています。

turn/start → claim input → assemble（system prompt / context / tools） → agent/pre-step → step/start → LLM request（agent/request）→ llm/stream → assistant/message → tool/call → tools/pre-execute（permission / guard / policy / hook） → tools/execute → tools/post-execute → tool/result → step/end → next turn

この設計の最大の利点は、多くの機能が agent loop 自体を変更せずに実装できることです。ツール実行前のセキュリティチェックならtools/pre-executeを監視し、メモリ追加ならagent/pre-stepで注入し、動作記録なら session イベントを購読し、モデルへのリクエスト変更ならagent/requestに hook し、推論継続の判断ならagent/turn-stoppingを監視します。講義11「エージェントの動作を可観測にする」と比べてさらに先へ進んでおり、「ログを追加する」のではなくループの各段階をイベントポイントにすることで、可観測性・permissions・メモリ・ポリシーをすべてリスナーとしてループへ接続し、ループ内にハードコードしません。

3. Session Event Log と "Model-visible means logged"：append-only（追記専用）の Session Event Log があり、非常に強力なエンジニアリング上の制約を定めています。

Model-visible means logged.Anything that reaches a model request must be reconstructable from the log, and a runtime invariant asserts it.

（モデルから見えるものは、すべて記録される。モデルへのリクエストに届くものはすべてログから再構築可能でなければならず、runtime invariant がそれを強制する。）

つまり可観測性は後から補うログではなく、harness の第一原則です。モデルのコンテキストへ入るものはデフォルトでログに残るべきであり、append-only というストレージ設計は session の状態をリプレイ可能にします。これは講義11・講義12の「各 session の終了時にクリーンな状態を残す」をエンジニアリングで保証します。

横断比較：同じ中核メカニズム、異なる実装

4製品を5サブシステムのフレームワークにマッピングすると、各製品の設計判断の違いが際立ちます。

コンテキスト継続性とハンドオフに注目すると、実装の多様性がよくわかります。Claude Code は追記型ストレージ + resume/fork、Pi は session tree による構造化履歴のリプレイ、Codex は状態をファイルへ書き出す規約、DeepSeek Harness は append-only ログによる再構築可能性——同じ「セッションをまたぐ継続性」という課題に、4つの異なる解答があります。

読み方のガイド

このセクションを最大限に活用するための推奨ルートは、各記事の末尾にある「講義のフレームワークへのマッピング」と「参考にしたい設計」の2セクションを活かすことです。製品設計を講義の概念へすばやく置き換え、自分のプロジェクトへ直接取り入れられるようにするための仕掛けです。

1. まず講義の前半、特に講義02「Harness とは実際に何か」を読み、5サブシステムのフレームワークを確立します。
2. このセクションへ戻り、4製品の記事（Pi・Claude Code・Codex・DeepSeek）を、各記事の「講義のフレームワークへのマッピング」表を軸に読み比べます。
3. 各記事末尾の「参考にしたい設計」から、自分のプロジェクトに取り入れる設計判断を選びます。
4. 理論を実践に移すなら、プロジェクト01「ベースライン vs 最小 harness」 で最小 harness をゼロから構築するのが自然な次のステップです。

参考にしたい設計（横断まとめ）

4製品の記事から、特に汎用性の高い設計判断を横断的に整理します。

1. compaction 戦略をプラグ可能にする（Pi）：コンテキストの compaction はハードコードされたパラメータではなく、交換可能な戦略インターフェースにすべきです。
2. 硬い要約の代わりに session tree を使う（Pi）：セッションをまたぐ復元は「前回の要約」に頼る必要はありません。構造化された履歴のリプレイのほうが状態サブシステムとして信頼できる場合があります。
3. prompt cache を意識する（Pi）：Skills をオンデマンドで読み込み、すべてのルールを一度に system prompt へ詰め込まないことは、コンテキストエンジニアリングであると同時にコストエンジニアリングです。
4. 指示を一つのファイルに積み上げず、scope ごとに階層化する（Claude Code）：ディレクトリ単位の CLAUDE.md は「近くで読み込む」美しい実装です。
5. compaction は段階的な漏斗にする（Claude Code）：最初に可逆的な処理、その後に不可逆的な処理。最初から全文を要約してはいけません。
6. hooks で決定論的なチェックを行う（Claude Code）：早すぎる完了宣言を防ぐには、prompt でお願いするのではなく runtime で強制します。
7. subagent のコンテキストを分離する（Claude Code / Codex）：タスクと同時にコンテキストも分割し、subtask の結果でメインループを汚染させないようにします。
8. session ストレージを追記型かつリプレイ可能にする（Claude Code / DeepSeek Harness）：ハンドオフは記憶に頼らず、ストレージ層で保証します。
9. AGENTS.md を目次ページとして書く（Codex）：約100行に抑え、docs/ 内の詳細を参照させ、機械的にチェックできるようにします。
10. 環境コンテキストは差分だけを渡す（Codex）：各ターンで変更されたフィールドだけを出力し、完全なシステムコンテキストを繰り返し貼りません。
11. ループの各段階をイベントポイントにする（DeepSeek Harness）：permissions、メモリ、ポリシー、ログをループ内にハードコードせず、リスナーとして接続します。
12. capability seam を標準化する（DeepSeek Harness）：具体的なツールではなく能力インターフェースに依存すれば、モデルから見えるツールのインターフェースに影響を与えず環境全体を交換できます。
13. Model-visible means logged（DeepSeek Harness）：モデルから見えるものをすべて記録し、可観測性を「追加の長所」ではなく「第一原則」にします。

さらに深く学ぶためのリポジトリ内リソース

本記事の内容は、以下のリポジトリ内ドキュメント・コードから直接確認できます。

• セクション入口：docs/ja/harness-designs/index.md
• 製品別分析：Pi ｜ Claude Code ｜ Codex ｜ DeepSeek Harness
• フレームワークの基礎：講義02「Harness とは実際に何か」（harness-vs-no-harness.ts・minimal-harness-loop.ts・harness-components.md 付属）
• 関連講義：指示の分割と不変条件（講義03・講義04）、セッション継続性とクリーンな状態（講義05・講義12）、境界と検証（講義07・講義09・講義10）、可観測性とループ（講義11・講義13）
• 実践課題：プロジェクト01「ベースライン vs 最小 harness」

各製品の詳細な主張（compaction の分割点、event pipeline のイベント名、capability seam の3層定義など）は、それぞれの記事末尾の「参考資料（原文 / ソースコード）」に明記された公式ドキュメント・公開ソースコードから確認できます。本記事の表や要約は、それらを講義の5サブシステムという共通の座標軸で再編成したものです。

【免费下载链接】learn-harness-engineeringHarness engineering beginner tutorial, from 0 to 1项目地址: https://gitcode.com/gh_mirrors/le/learn-harness-engineering