HarnessRouterがエージェント実行を標準化

エージェント製品の構築は通常、プロセスを起動して出力を読む小さなアダプターから始まる。だが製品がライブの進捗、セッションの継続性、ファイルのアップロードとダウンロード、アクセスルール、明確なキャンセル経路を必要とすると、それでは済まなくなる。エラーも、プロバイダーの障害、権限拒否、制限時間、ファイル欠如、キャンセルされたタスクを切り分けられるだけの構造が必要だ。最初のハーネスの隣に2つ目を追加すれば、それらのマッピングをすべて再構築して維持することになる。だからこそUHPは、両方の連携が従える単一のタスクライフサイクルを定義している。

UHPは2種類のルーティングを明確に区別する。モデルルーティングは推論レイヤー内で行われ、価格、レイテンシ、コンテキスト長、可用性、実測品質に基づいてエンドポイントを選ぶが、アプリケーションまたはハーネスが依然としてエージェントループを担う。ハーネスルーティングはタスクを担うランタイムを選び、ツール、スキル、ワークスペース、権限、イベントストリームが変わり得る。製品は両方のレイヤーを使うことがあり、UHPではmodelフィールドがモデルを選び、metadata.harness_idが構成済みハーネスを選ぶ。

HarnessRouterは、Harness IDを読み取って選択されたランタイムを起動し、出力をUHPのイベント、レスポンス、セッション、ファイル、エラーとして記録するセルフホスト型UHPサーバーだ。DockerイメージにはConsole、Gateway、Runnerが含まれ、名前付きの/dataボリュームを使い、公開するポートはConsoleのみ。セルフホストガイドにはCodex、Claude Code、Hermes、DeepSeek Harness、Gemini CLI、OpenCode、Qwen Code、Cline、Gooseなどのバックエンドが記載されている。プロトコルはタスクライフサイクルを標準化するが、ハーネスの挙動を同じにはしない。したがってチームにとって現実的な問いは、作業を投入して結果を確認する単一の共通手段が、提供したいランタイムをカバーするのに十分かどうか、そしてローカルの分離モデル——コンテナではなく別々のOSユーザーとワークスペース——がエージェントのデプロイ方法に合うかどうかだ。プロジェクトはApache 2.0ライセンスで、仕様、スキーマ、適合性テストを提供している。