【免费下载链接】learn-harness-engineeringHarness engineering beginner tutorial, from 0 to 1项目地址https://gitcode.com/gh_mirrors/le/learn-harness-engineering点击查看免费下载このガイドは、本リポジトリdocs/ja/resources/が提供する「日本語リソースライブラリ」の全体像と使い方を解説します。ライブラリは、コースで学んだハーネスエンジニアリングの手法を、実リポジトリへそのままコピーできるテンプレートと短いリファレンスに変換したものです。この記事を読み終えると、Codex・Claude Code などのコーディングエージェントに、セットアップ・進捗・スコープを毎回推測させず、複数セッションにまたがって安定して作業を続けさせるための最小構成4ファイルと、大規模運用向けの高度パックを組み立てられるようになります。このライブラリが解決する問題いつ使うかリソースライブラリは、次のような状況で最初に参照すべき場所として設計されていますdocs/ja/resources/index.md。作業が複数セッションにまたがる機能が多く、途中で放置されやすいエージェントが早すぎる完了宣言をしがち起動手順を毎回探し直している要するに、「毎回ゼロから推測させずにエージェントに働いてもらいたい」ときにここから始めます。これは講義docs/ja/lectures/で扱う長期実行エージェントの失敗モードコールドスタートの混乱、スコープの拡散、早すぎる完了宣言などを、ファイルと運用ルールという具体的な成果物で直接解決するためのパッケージです。失敗モードと成果物の対応マップライブラリ内のreference/method-map.mdは、長期実行コーディングエージェントの最も一般的な失敗モードを「最初に修正すべき成果物」へマッピングした表を提供しています。失敗モード実践でどう見えるか主要な修正補助成果物コールドスタートの混乱新しいセッションがセットアップとステータスの再発見に大部分の時間を費やすリポジトリをシステム・オブ・レコードにするclaude-progress.mdスコープの拡散エージェントが複数の機能を開始し、どれもきれいに完了しないアクティブスコープを制限するfeature_list.json早すぎる完了エージェントがコード編集後に完了を主張するが、実行可能な証拠の前完了を証拠に紐付けるclean-state-checklist.md脆弱な起動毎セッションがプロジェクトの起動方法を再学習するセットアップと検証を標準化するinit.sh弱い引き継ぎ次のセッションが何が検証済み・壊れている・次なのか判断できない明示的な引き継ぎで終了するsession-handoff.md主観的なレビューレビュー品質が好みや記憶に依存する固定カテゴリで出力を評価するevaluator-rubric.md運用原則は明快です「観測された失敗モードを直接解決する最小の成果物を追加する」こと、そして「すべての信頼性問題を1つのグローバル指示ファイルにテキストを詰め込んで解決しようとしない」ことです。最小パック最初にコピーする4つのファイルtemplates/index.mdは、まず以下の4ファイルをプロジェクトルートへコピーすることを推奨します。この4つだけでも、多くのエージェントワークフローは目に見えて安定します。AGENTS.mdまたはCLAUDE.mdルート指示feature_list.json機能状態claude-progress.md進捗ログinit.shブートストラップスクリプト以降では、各ファイルの役割と中身を、リポジトリ内の実ファイルを参照しながら解説します。AGENTS.mdセッション開始時に最初に読まれるルート指示templates/AGENTS.mdは「このリポジトリは長時間実行されるコーディングエージェント作業用に設計されている」という前提を明記し、目標を「生のコード出力の最大化」ではなく「次のセッションが推測なしに続けられる状態でリポジトリを残すこと」と定義します。スタートアップワークフローコードを書く前に実行pwdで作業ディレクトリを確認するclaude-progress.mdで最新の検証済み状態と次のステップを読むfeature_list.jsonを読み、最優先の未完了機能を選択するgit log --oneline -5で最近のコミットを確認する./init.shを実行する新しい作業を始める前に必要なスモークまたはエンドツーエンド検証を実行する特に重要なのは「ベースライン検証が既に失敗している場合、まずそれを修正する。壊れた開始状態の上に新しい機能作業を積み上げないこと」というルールです。ワーキングルール一度に一つの機能に取り組むコードを追加しただけで機能を完了とマークしないブロッカーが狭範囲のサポート修正を強制しない限り、選択した機能スコープ内に変更を留める実装中に検証ルールを黙って変更しないチャットサマリーより永続的なリポジトリ成果物を優先する必須成果物feature_list.json機能状態の真実の情報源、claude-progress.mdセッションログと現在の検証済みステータス、init.sh標準の起動・検証パス、session-handoff.md大きなセッション用のオプションのコンパクトな引き継ぎ。完了の定義すべて true のときのみ完了ターゲット動作が実装されている必要な検証が実際に実行された証拠がfeature_list.jsonまたはclaude-progress.mdに記録されているリポジトリが標準起動パスから再起動可能であるセッション終了時claude-progress.mdとfeature_list.jsonを更新し、未解決リスクやブロッカーを記録し、安全な状態になったら説明的なメッセージでコミットし、次のセッションがすぐ./init.shを実行できるようリポジトリをきれいに残します。CLAUDE.mdClaude Code 向けの同型ルート指示templates/CLAUDE.mdは構造は AGENTS.md と同じですが、Claude の指示スタイルに合わせた形式です。Codex やその他のエージェントにはAGENTS.mdを、Claude Code と作業する場合はCLAUDE.mdを使用しますtemplates/index.md。こちらは「速度よりも、信頼性のある完了、セッション間の継続性、明示的な検証を優先する」と明文化し、毎セッション開始時の運用ループpwd→claude-progress.mdを読む →feature_list.jsonを読む →git log --oneline -5→./init.sh→ ベースライン確認を定義します。追加ルールとして「未完了の作業を隠すために機能リストを書き直さない」「タスクが完了したように見せるためにテストを削除または弱体化させない」「リポジトリ成果物をシステム・オブ・レコードとして使用する」が挙げられ、完了ゲートは「必要な検証が成功し、結果が記録された後にのみ機能をpassingに移行できる」と定められています。feature_list.json機能状態の機械可読トラッカーtemplates/feature_list.jsonは、エージェントが実装する必要がある全機能と、そのステータス・検証ステップ・証拠を機械可読な JSON で保持する機能トラッカーです。テンプレートの構造は以下の通りです。{ project: replace-with-project-name, last_updated: YYYY-MM-DD, rules: { single_active_feature: true, passing_requires_evidence: true, do_not_skip_verification: true }, status_legend: { not_started: Work has not begun., in_progress: The feature is the current active task., blocked: Work cannot continue until a documented blocker is resolved., passing: Required verification has passed and evidence is recorded. }, features: [ { id: chat-001, priority: 1, area: chat, title: Create a new conversation, user_visible_behavior: A user can click New Chat and see a fresh empty conversation., status: not_started, verification: [ Open the app., Click New Chat., Verify a new conversation appears in the sidebar., Verify the main panel shows an empty conversation state. ], evidence: [], notes: } ] }ルール上、passingは「検証が実行され、証拠が記録された」場合のみ認められ、blockedは文書化されたブロッカーが解決されるまで作業が継続できない状態を意味します。verificationは人間が実行可能なステップ列として書き、evidenceに実際の実行記録を蓄積します。このテンプレートが実プロジェクトでどう運用されるかは、projects/project-03/solution/feature_list.jsonが良い実例です。project-03マルチセッション継続性の演習ソリューションでは、各機能にid・name・description・status・evidence・testedAtを記録し、例えばgrounded-qa機能ではstatus: passとともに「QaService.ask()がIndexingService.getAllChunks()からチャンクを取得し、キーワード重複でスコアリングし、上位2件を引用documentId/documentTitle/chunkIndex/excerptとして返す。信頼度は引用ありで 0.85、なしで 0.30」という具体的な証拠が記録されています。これは「証拠付きでなければ完了しない」というルールを実際の成果物レベルで体現しています。claude-progress.mdセッションログと現在の検証済みステータスtemplates/claude-progress.mdは進捗ログです。毎セッションこのファイルに書き込み、新しいセッションは最初にこれを読みます。テンプレートには「現在の検証済み状態」リポジトリルート・標準起動パス・標準検証パス・現在の最優先未完了機能・現在のブロッカーと「セッションログ」日付・目標・完了・検証実行・記録された証拠・コミット・更新された成果物・既知のリスク・次の最適ステップの枠が用意されており、セッション001、002…と追記していく設計です。init.sh標準の起動・検証パスtemplates/init.shは、依存関係のインストール、検証、開始コマンドの表示を一度に実行するブートストラップスクリプトです。テンプレートの実装を確認すると、set -euo pipefailでエラー時に即停止し、スクリプト自身の場所を基準にROOT_DIRを解決した上で、次の3つのコマンドを配列で定義しています。#!/usr/bin/env bash set -euo pipefail ROOT_DIR$(cd $(dirname ${BASH_SOURCE[0]}) pwd) cd $ROOT_DIR # Replace these commands with the correct commands for your repository. INSTALL_CMD(npm install) VERIFY_CMD(npm test) START_CMD(npm run dev) echo Working directory: $PWD echo Syncing dependencies ${INSTALL_CMD[]} echo Running baseline verification ${VERIFY_CMD[]} echo Startup command printf %q ${START_CMD[]} printf \n if [ ${RUN_START_COMMAND:-0} 1 ]; then echo Starting the app exec ${START_CMD[]} fi echo Set RUN_START_COMMAND1 if you want init.sh to launch the app directly.設計上のポイントは3つあります。場所非依存BASH_SOURCE[0]からROOT_DIRを解決してcdするため、どのディレクトリから実行しても正しく動きます。検証が必須インストール後に必ずベースライン検証既定ではnpm testを実行します。壊れた開始状態の上に機能作業を積み上げない、という AGENTS.md のルールを機械的に強制します。起動は明示的既定では起動コマンドを表示するだけに留め、RUN_START_COMMAND1が設定された場合のみexecでアプリを起動します。これにより、セッション開始時の誤起動を防ぎつつ、必要なときだけ起動できます。プロジェクトのコマンド・パス・機能名・検証ステップに合わせて内容を編集して使います。次の段階で追加するファイルプロジェクトが成長したら、以下のファイルを追加します。session-handoff.mdコンパクトな引き継ぎメモtemplates/session-handoff.mdは、大きなセッション向けのオプションのコンパクトな引き継ぎです。「現在検証済み」現在動いているもの・実際に実行された検証、「このセッションでの変更」追加されたコード・インフラやハーネスの変更、「壊れているまたは未検証」既知の欠陥・未検証パス・次セッションへのリスク、「次の最適ステップ」最優先の未完了機能・なぜ次なのか・何が合格とみなされるか・そのステップ中に変更してはならないもの、「コマンド」起動・検証・フォーカス済みデバッグコマンドのセクションで構成されます。clean-state-checklist.mdセッション終了前のチェックリストtemplates/clean-state-checklist.mdは、各セッション終了前に実行するチェックリストです。標準起動パスがまだ機能する標準検証パスがまだ実行される現在の進捗が進捗ログに記録されている機能状態が実際に合格しているものと未検証のものを反映している半完了のステップが未記録のまま残っていない次のセッションが手動修復なしに継続できるevaluator-rubric.mdエージェント出力のスコアカードtemplates/evaluator-rubric.mdは、実装後に最終承認前に使用する評価ルーブリックです。主観的なレビューを防ぐため、固定カテゴリで 0〜2 点を付けます。カテゴリ質問スコア (0-2)ノート正確性実装された動作は要求された機能に一致しているか検証必要なチェックが証拠付きで実際に実行されたかスコープ規律セッションは選択された機能スコープ内に留まったか信頼性結果は修復なしに再起動や再実行に耐えるか保守性コードとドキュメントは次のセッションにとって十分明確か引き継ぎ準備新しいセッションがリポジトリ成果物のみから作業を続けられるか判定は「承認 / 修正 / ブロック」の3段階で、必須フォローアップとして「欠落している証拠」「必要な修正」「次回のレビュートリガー」を記録します。quality-document.md品質スナップショットtemplates/quality-document.mdは、各プロダクトドメインとアーキテクチャレイヤーの品質スナップショットを記録するドキュメントです。エージェントと人間の両方が、コードベースのどこが強いか・どこに作業が必要かを素早く理解できるようにします。評価スケールは Aすべての検証合格・クリーンなアーキテクチャから D動かない・重大な構造的問題まで4段階で、プロダクトドメインドキュメントインポート、管理、インデックス、QA フロー、根拠付き回答などとアーキテクチャレイヤーメインプロセス、Preload、Renderer、Servicesの2軸で評価し、変更履歴を記録します。更新頻度は「各重要セッションの後、または新しい作業フェーズを開始する前」です。リファレンスノートreference/reference/index.mdは、テンプレートを「緩いファイルの集まり」ではなく「動作するハーネス」として使うための方法ノートです。4つの内部リファレンスが用意されています。reference/method-map.md一般的な長期実行の失敗モードを、最初に対処する成果物やポリシーにマッピング前述の表reference/initializer-agent-playbook.md機能作業が始まる前にイニシャライザーが残すべきものreference/coding-agent-startup-flow.md後のコーディング実行用の固定セッション開始フローreference/prompt-calibration.mdルート指示を肥大化・脆弱化させずにシャープに保つ方法推奨読書順はmethod-map.md→initializer-agent-playbook.md→coding-agent-startup-flow.md→prompt-calibration.mdの順です。ここでの「主要記事」リストは意図的に絞られており、ハーネスを「モデル周りの実行システムエージェントループ、ツール実行、サンドボックス、状態、コンテキスト、検証、終了、オーケストレーション、オブザーバビリティ」と定義した上で、OpenAI と Anthropic の3本の記事をコースの骨格として位置づけています。高度パックopenai-advanced/ への移行openai-advanced/index.mdは、OpenAI の「Harness engineering: leveraging Codex in an agent-first world」記事で説明されている、よりオピニオネイトされたリポジトリ構造をコピー可能なスターターファイルとしてパッケージしたものです。最小ハーネスでは不十分になり、リポジトリが以下を必要とする場合に使用します。短いルーティングスタイルのAGENTS.mdリポジトリ内の持続的なシステム・オブ・レコードドキュメントアクティブおよび完了した実行計画明示的なプロダクト、信頼性、セキュリティ、フロントエンドポリシーファイルプロダクトドメインとアーキテクチャレイヤーによる品質スコアリングモデルに適した参照資料フォルダーアーキテクチャ、ナレッジキャプチャ、ランタイム検証のための標準運用手順SOPopenai-advanced/repo-template/index.md配下のスターターパックは、以下の構造を反映しています。AGENTS.md ARCHITECTURE.md docs/ ├── design-docs/ │ ├── index.md │ └── core-beliefs.md ├── exec-plans/ │ ├── active/ │ ├── completed/ │ └── tech-debt-tracker.md ├── generated/ │ └── db-schema.md ├── product-specs/ │ ├── index.md │ └── new-user-onboarding.md ├── references/ │ ├── design-system-reference-llms.txt │ ├── nixpacks-llms.txt │ └── uv-llms.txt ├── DESIGN.md ├── FRONTEND.md ├── PLANS.md ├── PRODUCT_SENSE.md ├── QUALITY_SCORE.md ├── RELIABILITY.md └── SECURITY.md導入方法は以下の通りです。リポジトリがまだ小規模な場合は、最小パックから始めるより強固な構造が必要になったら、repo-template/のファイルを自身のリポジトリにコピーするAGENTS.mdは短く保つ。より深いドキュメントへのルーターとして扱い、百科事典としては扱わない品質、信頼性、計画ドキュメントは、独立したクリーンアップの日ではなく、通常の作業の一部として更新する生成された成果物と外部参照は明示的に保持し、エージェントがチャット履歴に頼らずに見つけられるようにするopenai-advanced/sops/index.mdフォルダーは、記事の図をステップバイステップの運用手順に変換した SOP ライブラリで、レイヤードドメインアーキテクチャのセットアップ、目に見えないナレッジのリポジトリへのエンコード、ローカルオブザーバビリティスタックとフィードバックループワークフロー、UI 作業のための Chrome DevTools 検証ループなどが含まれます。設計原則は5つです。短いエントリポイント、深くリンクされたドキュメントリポジトリをシステム・オブ・レコードとして扱う機械的チェックは記憶されたルールに勝る計画と品質履歴はコードの隣に置くクリーンアップと単純化は第一級の責務このパックは意図的にオピニオネイトされていますが、盲目的にコピーするのではなく、プロジェクトに合わせて適応させるべきものです。ライブラリ全体構成と移行パスライブラリは3つのディレクトリで構成されます。templates/実際のリポジトリにコピーするテンプレートreference/方法メモ、起動フロー、失敗モードのマップopenai-advanced/高度なリポジトリ雛形、システム・オブ・レコードドキュメント、エージェントファーストガバナンステンプレート移行判断の目安はシンプルです。リポジトリが複数ドメイン、アクティブな計画、品質スコア、信頼性ポリシーを持つ長期運用システムに育ったら、最小パックを無理に拡張するのではなく、openai-advanced/パックへ移行してください。実プロジェクトでの運用例本リポジトリの演習プロジェクトも、この最小パックを実際に運用しています。例えばprojects/project-03/solution/にはfeature_list.json・claude-progress.md・session-handoff.md・clean-state-checklist.md・init.shが揃っており、前述の通りfeature_list.jsonには各機能のstatusとevidenceが日時付きで記録されています。同様にprojects/project-06/solution/も、feature_list.json・claude-progress.md・session-handoff.md・clean-state-checklist.md・evaluator-rubric.md・init.shを保持しており、ルート指示AGENTS.md/CLAUDE.mdから完了判定、評価ルーブリックまで一貫したハーネスが構築されています。これらは、テンプレートを実プロジェクトへ展開する際の具体的な参照例として役立ちます。まとめ日本語リソースライブラリは、「指示を長くする」のではなく「リポジトリ成果物をシステム・オブ・レコードにする」ことで、複数セッションのエージェント作業を安定させるための実用的なツールセットです。まず最小パック4ファイルルート指示、機能トラッカー、進捗ログ、起動スクリプトをコピーし、プロジェクトの成長に合わせて引き継ぎ・クリーン状態チェックリスト・評価ルーブリックを追加し、大規模化したらopenai-advanced/パックへ移行する——この段階的な導入フローが、リポジトリを「推測のない再開可能な状態」に保つ最短経路です。赞分享【免费下载链接】learn-harness-engineeringHarness engineering beginner tutorial, from 0 to 1项目地址https://gitcode.com/gh_mirrors/le/learn-harness-engineering点击查看免费下载相关推荐「Hello アルゴリズム」用語集ガイド全15章の重要用語を英語・日本語の対訳で整理する「Hello アルゴリズム」用語集ガイド全15章の重要用語を英語・日本語の対訳で整理する 本書日本語版 hello algo の付録には、登場する重要な用教程文档示例工程教育learn-harness-engineering Project 06完全なエージェント harness を構築する — ランタイム観測性・クリーン状態・ablation 検証の総合実践ガイドlearn harness engineering Project 06完全なエージェント harness を構築する — ランタイム観測性・クリーン状態・alearn-harness-engineering 講義 01強いモデルは信頼できる実行を意味しない——Harness がエージェントの成否を決めるlearn harness engineering 講義 01強いモデルは信頼できる実行を意味しない——Harness がエージェントの成否を決める 本講義は创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考