DeepSeek Harness Worktrees：初回利用ガイド
DeepSeek-V4 Team · 2026年10月14日 · 17 min read
別のチェックアウトは、すでに編集中のファイルを移動せずにエージェントに変更を試させたい場合に役立ちます。DeepSeek Harness dsh-v0.2.1-alpha.2（2026 年 10 月 9 日リリース）は、そのための実験的な Git Worktrees プラグインを追加します。これはブランチとチェックアウトを作成し、呼び出しセッションの作業ディレクトリを変更します。
このチュートリアルでは、バージョン固定プラグインガイド を使用して、小さな作業で動作を確認します。ワークツリーを作成し、ドキュメントを 1 箇所変更し、検証して戻ります。これはドキュメントベースのワークフローであり、Harness デスクトップアプリケーションをテストしたという主張ではありません。コード形式で記載したツール呼び出しの例はエージェント呼び出しを説明するものであり、シェルに貼り付けるコマンドではありません。
プラグイン有効化前にリポジトリを確認
試用専用のリポジトリまたは、現在の変更を理解しているプロジェクトを使用してください。ワークツリーランタイム要件 は、ファイルシステムプロバイダーが使用する実行環境で Git 2.45 以降と Node を指定しています。リモート環境の場合、ラップトップ上のバージョンだけではその要件を満たすとは限りません。
リポジトリルート、現在のブランチ、現在のコミット、および短い Git ステータスを求めることから始めます。次の読み取り専用コマンドで確認できます。
git --version
node --version
git rev-parse --show-toplevel
git branch --show-current
git rev-parse HEAD
git status --short空のブランチ名はデタッチド HEAD を意味する可能性があります。ブランチをでっち上げるのではなく、それを記録してください。空でないステータスは自動的に失敗を意味するわけではありませんが、コミット済みベースラインの外に作業が存在することを意味します。新しいタスクにそれらの変更が必要かどうかを判断してください。必要な場合、ワークツリーがそれらをコピーすると想定する代わりに、先に適切なコミットを準備してください。
プラグインはステージ済み、未ステージ、未追跡、または無視されたファイルをコピーしません。したがって、ソースチェックアウトが正常に実行されても、依存関係、ローカル環境ファイル、および生成された出力は存在しない可能性があります。
図はドキュメント化されたコピー境界を表しており、アプリケーションのスクリーンショットではありません。両方のチェックアウトは共有 Git 管理を使用します。別々のファイルでも履歴が独立するわけではありません。
Git Worktrees を有効化し小タスクを選択
Plugins → Official → Git Worktrees を開き、スイッチを有効にします。固定プラグインガイドによると、オプションバンドルは出荷されるすべてのプロファイルでオフになっています。これはワークツリーランタイムと作成ツールを一緒にロードします。
最初のタスクでは、依頼する作業の範囲を絞ってください。ドキュメント修正用のワークツリーを作成し、そのディレクトリとベースラインを表示し、編集前に待機します。docs-worktree-trial のような新しい未使用のブランチ名を要求してください。同じ名前が相対チェックアウトディレクトリにも使用されるため、短く内容の分かる名前にすると後での検査が容易になります。
作成呼び出しは次の形式です。
create_worktree({ name: "docs-worktree-trial", from: "HEAD" })from はローカルで解決される必要があります。ホスティングウェブサイト上で見えるリモートブランチ名は、そのオブジェクトがこのリポジトリで利用できない場合は不十分です。この操作は不足しているオブジェクトを取得せず、サブモジュールを初期化せず、パッケージをインストールしません。失敗した作成を再試行する前に、不足している前提条件を確認し、個別に対応してください。
変更前に返されたディレクトリを検証
成功した呼び出しは path、branch、baseCommit、repositoryRoot を返します。これら 4 つの値を一緒に保持してください。サブシステムリファレンス は、セッションがディレクトリを変更する前に Git 設定が完了することを指定しています。
デフォルトの宛先は現在のチェックアウト下の .agents/worktrees/<name> です。セッションがリンクされたチェックアウトで開始される場合、そのチェックアウトが新しいプールのソースルートになります。返された正規パスを、別のセッションから記憶されたパスで置き換えないでください。
| 返されたフィールド | 検証内容 |
|---|---|
path |
セッションは現在このチェックアウト内です |
branch |
要求した新しいブランチです |
baseCommit |
意図したローカル開始リビジョンです |
repositoryRoot |
開始したチェックアウトを識別します |
エージェントに現在のディレクトリからルート、ブランチ、コミットチェックを再度実行するよう依頼してください。それらを作成結果と比較してください。通常のリポジトリは意図した開始コンテンツを持つべきですが、ランタイムはリポジトリローカルな置換参照がチェックアウトされたコンテンツに影響する可能性があることに留意しています。コミット識別子だけでは、変更予定のファイルを検査する代わりにはなりません。
1 箇所編集し差分を検証
既存の README 段落を選択し、事実関係を一つ補足するよう依頼してください。依存関係のアップグレードやリポジトリ全体のフォーマッターから始めるのは避けてください。これらは大きな差分を生成し、ディレクトリの誤りを発見しにくくします。
編集後、現在のブランチと変更を検証してください。
git branch --show-current
git status --short
git diff --check
git diff -- README.mdタスクで異なるファイルを変更する場合は、実際のファイル名を使用してください。最後のコマンドは未ステージの変更を示します。エージェントが編集をステージした場合、ステージされた差分も検証してください。クリーンな git diff --check は空白エラーのみをチェックします。文章が正しいことや、プロジェクトをビルドできることまでは確認できません。
変更内容に応じて、必要最小限のプロジェクトチェックを実行してください。コマンド、ディレクトリ、結果を記録してください。ドキュメントのみの変更の場合、無関係なテストスイートを実行するよりも、レンダリングされたテキストを読む方が有用な場合があります。
図の番号は、作成、戻り値の確認、編集、差分確認、元の場所への移動の順です。保持されたブランチとディレクトリは、統合またはクリーンアップについて後で決定する必要があります。
元のディレクトリへ戻り、レビューに必要な情報を残す
戻るには、エージェントに元の絶対チェックアウトパスで working_directory を呼び出すよう依頼してください。例えば、サンプルパスを記録した repositoryRoot に置き換えます。
working_directory({ cd: "/absolute/path/to/original-checkout" })現在のディレクトリを再度検証してください。離脱は変更をマージせず、チェックアウトを削除せず、そのブランチを削除しません。Git Worktrees プラグインを無効にしても、既存のワークツリーはそのまま残ります。一方、組み込みの working-directory ツールは利用可能なままです。
統合方法を決める前に差分をレビューしてください。通常のリポジトリワークフローに従ってコミットおよびマージ、またはチェリーピックしてください。チェックアウトが不要になったら、そのステータスを検査し、変更を保存した後に Git の通常のワークツリー削除プロセスを使用してください。ダーティなチェックアウトに対するデフォルトの対応として強制削除は避けてください。
ブランチを繰り返し作成せずに失敗を診断
既存のブランチまたはチェックアウトパスはエラーを引き起こします。別の名前を試す前に既に存在するものを検査してください。特にキャンセル後は、設定失敗により部分的なアーティファクトが残され、その場所が報告される可能性があります。名前を繰り返し生成すると、どのチェックアウトに残したい変更があるかが不明確になります。
パーミッションエラーは異なります。作成には、既存のサンドボックスポリシーが宛先および共有 Git メタデータへの書き込みを許可している必要があります。プラグインはそれらの権限を拡大しません。設定を変更する前に拒否された場所を特定してください。
最後に、保存された Git LFS ポインターまたは暗号化されたブロブは、チェックアウトが設定された clean、smudge、および process フィルターをスキップするため、展開されないまま残る可能性があります。実ファイルの取得や復号は別々の操作として扱ってください。チェックアウトは有効でも、タスクが必要な実行環境が不足している可能性があります。
返された4項目の記録を、確認済みの差分やテスト結果と一緒に保存してください。エージェントがどのディレクトリまたはベースラインを使用したか推測せずに、演習を再開するのに十分な文脈になります。より広範なリリースおよび SDK 変更については、alpha.2 アップグレードガイド を参照してください。