ほとんどのエージェントツールは依然として単一の会話を中心に構築されています。1つのエージェント、1つのタスク、1つのターミナル、1つの監視対象ストリーム。小規模なタスクには適していますが、本格的なエンジニアリング作業には不向きです。

Herdrが興味深いのは、この点を作業のデフォルト形状として扱っている点です。

最もシンプルな説明は次の通りです。Herdrはコーディングエージェント向けのtmuxです。より正確には、既存のターミナル内で動作するエージェントマルチプレクサです。各エージェントに本物のPTYを与え、作業が発生しているプロセスを維持し、エージェントの状態を表示し、CLIとローカルソケットAPIを公開します。

この区別は重要です。Herdrはもう一つのデスクトップエージェントアプリではありません。コードとターミナルが存在する場所で実行するバイナリです。サーバー、Mac Mini、VM、デスク下の開発機などです。ノートPCを閉じたり、デタッチしたり、後でsshで戻って再アタッチしたり、電話からでも可能です。ターミナルウィンドウが終了しても作業は失われません。

スループット問題

コーディングエージェントは作業開始のコストを変えました。1つのエージェントにバグの調査を依頼し、もう1つに失敗するテストの作成を依頼し、もう1つにマイグレーションプランのドラフトを依頼することができます。ボトルネックは監督です。

問題は、通常のターミナルが監督を理解しないことです。tmuxやZellijは永続性とペインを提供しますが、エージェントがブロックされているか、作業中か、完了か、アイドル状態か、3画面前に質問を表示した後にただ座っているだけかを知りません。デスクトップアプリはしばしばエージェントの状態をより良く理解しますが、ワークフローはGUIを持つマシンに縛られます。ワークツリーオーケストレーターは並列タスクを調整できますが、通常はワークフローを所有したがります。

Herdrは有用な中間地点に位置します。ターミナルモデルに加えてエージェント認識を備えています。

パフォーマンスの乗数は魔法ではありません。4つの実用的な特性から来ています。

  1. 複数のエージェントがそれぞれ独自のシェル、ログ、プロンプト、プロセス状態を持つ本物のPTYで実行されます。
  2. Herdrはセマンティック状態をまとめるため、どのエージェントがブロックされているか、作業中か、完了か、アイドル状態かを確認できます。
  3. サーバーがペインを所有するため、セッションはクライアントのデタッチ、ノートPCのスリープ、ターミナルの終了から生き残ります。
  4. CLIとソケットAPIにより、スクリプトやエージェントが直接マルチプレクサを制御できます。

4番目のポイントが私が最も重視する点です。3つのペインを監督する人間は有用です。ヘルパーエージェントを開始し、出力を読み、状態遷移を待ち、結果を統合できるエージェントこそが複合効果の始まりです。

Herdrのドキュメントはこの点について明確に述べています。ソケットAPIはワークスペース、タブ、ペイン、エージェントを管理できます。推奨されるパスはまずCLIラッパーを使い、その後直接のリクエストレスポンス制御やサブスクリプションのために生のソケットAPIを使用することです。また、HERDR_ENV=1で保護されたエージェントスキルファイルもあり、エージェントにペイン内からHerdrの使い方を教えます。

具体的なワークフロー

スタッフエンジニアがリファクタリングを監督する状況を想像してください。内部クライアントの置き換え、テストの調整、デプロイメントの確認。これを分割します。

1つのスーパーバイザーが計画とレビューを所有します。3つのペインを作成します。

herdr

Enter fullscreen mode Exit fullscreen mode

Herdr内で、ペインを分割してエージェントを開始できます。

split=$(herdr pane split --current --direction right --no-focus)
api_pane=$(printf '%s\n' "$split" | jq -r '.result.pane.pane_id')

herdr agent start api-change --kind codex --pane "$api_pane"
herdr agent prompt api-change "Replace the legacy client in the API layer. Keep the diff minimal."

Enter fullscreen mode Exit fullscreen mode

次にさらに2つのエージェントを開始します。

test_split=$(herdr pane split --current --direction down --no-focus)
test_pane=$(printf '%s\n' "$test_split" | jq -r '.result.pane.pane_id')

herdr agent start tests --kind codex --pane "$test_pane"
herdr agent prompt tests "Add or update tests for the new client behavior."

deploy_pane=$(herdr pane split --current --direction right --no-focus | jq -r '.result.pane.pane_id')
herdr agent start deploy-review --kind codex --pane "$deploy_pane"
herdr agent prompt deploy-review "Review config, deploy scripts, and rollback implications."

Enter fullscreen mode Exit fullscreen mode

スーパーバイザーはターミナルをポーリングする代わりに状態を待ちます。

herdr agent wait api-change --until blocked --timeout 120000
herdr agent read api-change --source recent-unwrapped --lines 80

Enter fullscreen mode Exit fullscreen mode

または通常のプロセス出力の場合。

herdr pane run w1:p3 "just test --watch"
herdr pane wait-output w1:p3 --regex "passed|failed" --timeout 120000

Enter fullscreen mode Exit fullscreen mode

人間はレベルを上げます。diffのレビュー、ブロックされたエージェントへの回答、悪いアプローチの拒否、テストの判断、本番環境への影響範囲を止めることです。

並列性とゼロコンテキスト損失

並列性だけでは不十分です。5つのターミナルを開くのは簡単です。昼食後にそれらを理解可能な状態に保つのが難しい部分です。

Herdrが機能するのは、並列実行と永続性と状態を組み合わせているためです。エージェントがブロックされた場合、その状態が可視になります。レビュー中に別のエージェントが完了した場合、検査されるまで完了とマークされます。sshが切断された場合でも、サーバーはペインとプロセスを所有し続けます。

永続性がなければ、各追加エージェントがオーバーヘッドを追加します。永続的なペインと状態があれば、オーバーヘッドは減少します。リポジトリ、仮説、または戦略ごとに1つのエージェントを実行し、必要になったときだけ注意を払うことができます。

比較とトレードオフ

Herdrはメンタルモデルの点でtmuxやZellijに最も近いです。永続的なペインとリモート再アタッチを提供しますが、エージェント状態とエージェント向けの制御面を追加します。すでにtmuxを使用している場合、そのレイヤーのために若いツールを採用することになります。

デスクトップエージェントアプリと比較すると、Herdrは洗練度が劣りますが、エンジニアリング作業がどこで行われるかについてより正直です。作業用ボックス上のターミナルマルチプレクサは、ノートPCを閉じても生き残ります。

ワークツリーオーケストレーターと比較すると、Herdrは意見が少ないです。タスク割り当て、ワークツリーのライフサイクル、レビューフロー、マージポリシーを所有する製品が必要な場合は、オーケストレーターを使用してください。エージェント、シェル、テストウォッチャー、ログ、スーパーバイザースクリプトが共存する柔軟なランタイムが必要な場合は、Herdrの方が適切な形状です。

実際のリスクがあります。並列エージェントは並列の影響範囲を意味します。広範なバイパス権限を持つエージェントを実行する場合、それらはすべて同時に悪い編集を行う可能性があります。gitの規律、小さなプロンプト、分離されたワークツリー、diffレビュー、テストファーストのチェックが必要です。

最も強く推奨するのは経験豊富なエンジニアです。誰でも数個のペインを開くことはできますが、APIは作業を分割し、境界を定義し、パッチをレビューし、疑わしい変更に気づく方法を知っている人に報酬を与えます。

私の見解

現在の世代のコーディングエージェントは、モデル品質だけでなく制限されています。ランタイムの人間工学によって制限されています。

シングルチャットエージェントのワークフローは、すべてのタスクを線形に感じさせます。実際のエンジニアリング作業は、調査、テスト、レビュー、失敗した試み、ログ、決定のグラフです。Herdrの賭けは、正しいインターフェースはより美しいチャットウィンドウではないということです。永続性、状態、APIを備えたターミナルネイティブのランタイムです。

Herdrは判断力、コードレビュー、センスを置き換えることはありません。デフォルトで全てのエンジニアを3倍速くすることはありません。しかし、すでにエージェントを精力的に使用しているエンジニアにとって、複数のワークストリームをコンテキストを失うことなく生き続け、可視化し、制御し続けることができます。

それがスループットの源泉です。1つのエージェントがチームであるかのように装うのではなく、1人のエンジニアに多くのエージェントに対する合理的な制御面を与え、それを規律を持って使用することから来ます。

参考文献

私のプロジェクトをテストするために、Railwayを使用しています。開始時に$20 USDが必要な場合は、このリンクを使用してください。