AIエージェント Harness設計 比較
エージェントの実装アーキテクチャでハーネス設計を比較する。
1 概要
Claude Code
Anthropic — claude-code
開発者向けCLIエージェント。TypeScript/Bunランタイム上でReact+Inkターミナルを描画し、ReActループで40以上のツールを操作する。IDE統合（VS Code/JetBrains）とMCPプロトコル対応。
TypeScript + Bun
Hermes Agent
Nous Research — hermes-agent
自己改善型の汎用エージェント。Telegram/Discord/Slack/WhatsApp/Signal/QQ等のマルチプラットフォームに対応し、スキル生成・学習ループ・プラグインエコシステムを備える。
Python + Node
NemoClaw
NVIDIA — NemoClaw (Alpha)
OpenClaw/OpenShell上に構築されたセキュリティ重視のオーケストレーション層。Hardened Blueprint、Landlock/Seccomp隔離、K8s Pod、L7プロキシ等の多層防御でエージェントを安全に実行する。
TypeScript + Python
OpenClaw
OpenClaw Community — openclaw
プライバシー重視のローカルファーストAIアシスタント。20+チャンネル統合・131拡張機能・53スキル・音声ウェイクワード・Canvas UIを持つ多機能パーソナルエージェント基盤。
TypeScript + Node.js
2 アーキテクチャ概観図
各エージェントの階層構造をレイヤー図で比較。上がユーザー入力、下がインフラ層。
各エージェントのネット公開情報およびGitHubソースコードを graphify で知識グラフ解析し整理したものです。
Claude Code
Hermes Agent
NemoClaw
OpenClaw
3 12コアモジュール比較
Akshay Pachaar「The Anatomy of an Agent Harness」（Daily Dose of Data Science）で定義された11コンポーネントに、「初期化」を加えた12コアモジュールに沿って、claude-code / hermes-agent / NemoClaw の3大エージェントの実装アーキテクチャでハーネス設計を比較する。ハーネス設計は概念として理解しやすい一方、実際に自分のエージェントを設計・実装する段階ではどう具体化すればよいかイメージしにくいことが多い。そこで、実際に人気を集めているエージェントの実装を参照し、各モジュールが現実のコードでどのように表れるかを具体的に示すことにした。
1 オーケストレーションループ (ReAct Cycle) ▶
| 観点 | Claude Code | Hermes Agent | NemoClaw | OpenClaw |
|---|---|---|---|---|
| ループ実装方式 | ReActループで推論とツール実行を繰り返す。ループ内でメッセージ履歴・ツール実行コンテキストを管理し、ガードレール発動やユーザー中断などの終了条件を監視する | ループ本体は単純なwhileループ。ループ冒頭でコンテキスト圧縮の要否を判定し、必要なら補助モデルで要約してから本体推論に進む。複数LLMプロバイダー（Anthropic/Gemini/OpenAI/Codex）の応答形式を統一的に処理する変換層を挟む | 自身はReActループを持たない。YAMLマニフェストで定義されたエージェントプロセスを起動し、HTTPエンドポイントへの定期的なヘルスプローブで生死を監視するだけ。推論はコンテナ内のエージェントに完全委譲 | Gateway制御プレーンがチャンネルからのイベントを受信し、ルーターがエージェントセッションへディスパッチ。各エージェントはPlugin SDK経由でモデルを呼び出しReActループを実行。コア自体はエージェントロジックを持たずイベントバスとして機能する |
| 終了条件 | 最終回答 / 最大ターン数超過 / トークン予算枯渇 / ガードレール発動 / ユーザー中断 | 最終回答 / コスト予算上限 / エラー連続 / ユーザー中断 | エージェントプロセス正常終了 / ヘルスプローブ連続失敗 / Blueprint定義の終了条件成立 | セッション終了コマンド / チャンネル切断 / エージェントプロセス終了 / タイムアウト設定 |
| 状態の受け渡し方法 | ターンごとにメッセージ履歴・ツール実行結果を積み上げてモデルに渡す。Gitコミットが暗黙のチェックポイントとして機能する | 会話履歴リストをミュータブルに追記する方式。ただしコンテキスト圧縮時は履歴を再構成するため、圧縮前後の境界がログに記録される | サンドボックスの状態をJSONファイルに永続化。複数のCLIプロセスが同時に読み書きする際はmkdirのアトミック性を使ったファイルシステムロックで排他制御 | セッション単位の状態をGatewayが一元管理。チャンネルアダプタがメッセージを正規化してエージェントへのイベントとして注入。セッション再開時も同一状態から継続できる設計 |
2 ツールシステム (Tools) ▶
| 観点 | Claude Code | Hermes Agent | NemoClaw | OpenClaw |
|---|---|---|---|---|
| ツール種別 | 40以上を内蔵。シェル実行・ファイル編集・コード検索・Webアクセス・サブエージェント起動など開発者向け操作全般 | 40以上を内蔵。ターミナル・ファイル操作・ブラウザ・各チャットプラットフォーム送受信・画像生成・タスク委譲・定期実行など | ネットワークポリシー管理・認証情報操作・サンドボックス監視に特化。汎用ツールはコンテナ内のエージェントに委ねる | Plugin SDK経由で動的ロード。131拡張機能（チャンネルアダプタ・モデルプロバイダー・メディア生成・音声・ブラウザ等）と53スキルを提供。MCPサーバーも拡張機能として統合可能 |
| 動的ツール追加 | MCPプロトコルで外部サーバーのツールを実行時に取得し、内蔵ツールとマージして一本のリストとしてモデルに提示 | エージェントが過去の実行経験からスキル（ツール定義）を自動生成・保存。次回から再利用可能になる自己拡張型の仕組み | YAMLマニフェストに列挙されたツールのみ有効化。ポリシーパイプラインが5段階（deny list → プロファイル → プロバイダー → エージェント → サンドボックス）でフィルタリング | pnpmパッケージとしてインストール可能。Plugin APIで新規拡張機能を開発・追加。スキルはSKILL.mdで定義したMarkdownドキュメントからロード。実行時のホットリロード対応 |
| 並列実行 | 副作用がない読み取り専用ツールは並列起動可。ファイル変更を伴う操作は逐次実行 | 実行バックエンドをLocal/Docker/Modalから選択。各バックエンドが独立した隔離環境でツールを動かす | サンドボックスPod単位で完全隔離。Pod間はK8s内部ネットワークのみで通信 | マルチエージェントルーティングにより複数セッションを並列実行。GatewayがWorkerスレッド管理。チャンネル別の独立した実行コンテキストを保証 |
3 メモリアーキテクチャ (Memory) ▶
| 観点 | Claude Code | Hermes Agent | NemoClaw | OpenClaw |
|---|---|---|---|---|
| 構造 | ファイルベースのメモリシステム。軽量インデックス（MEMORY.md）は常にコンテキストに読み込まれ、詳細はトピック別ファイルに分けて管理。インデックスは容量を厳守し必要なファイルだけをオンデマンドで読み込む | ターン開始前に全プロバイダーから記憶を取得し「これは背景情報です」というフェンスタグで囲んでコンテキストに注入。ターン完了後に非同期で全プロバイダーへ書き戻す。内蔵1件＋外部1件の最大2プロバイダー構成（ツール定義の肥大化防止） | 独自メモリ機構を持たない。サンドボックス再構築時にワークスペースファイルをバックアップ／リストアする仕組みのみ | context-engine/モジュールによるセッション永続化。active-memory拡張機能でアクティブメモリ管理。memory-host-SDKでサードパーティのメモリプロバイダーも統合可能。チャンネル別・エージェント別のセッション分離を実現 |
| 信頼性の扱い | 「メモリはヒントであり真実ではない」が原則。コードや設定を変更する前に必ず現在のファイルを読んで記憶と照合する | 1つのプロバイダーへの書き込みが失敗しても他のプロバイダーはブロックされない。失敗は黙って無視し次回ターンで再試行 | マニフェストに定義されたstate_dirsのみ対象。それ以外のファイルはバックアップ対象外 | セッションファイルシステム（~/.openclaw/agents/）への永続化。チャンネル切断後もセッション状態を保持し再接続時に復元。メモリプロバイダー書き込み失敗は個別にハンドリング |
💡 メモリ仕組みの詳細解説
🟠 Claude Code — ヒント型メモリ
メモリは「事実」ではなく「ヒント」として扱われます。MEMORY.mdのインデックスは常にコンテキストに載りますが、1項目あたり約150字に厳格に制限されています。これにより、大量の記憶がトークンを圧迫する問題を防ぎます。
詳細はTier 2（トピックファイル）に格納され、必要な時だけ読み込まれます（オンデマンドロード）。さらに検索専用のTier 3（生テキスト）が存在し、参照はするが常時ロードはしません。
⚠️ なぜファイル照合が必要か：コードやファイルを変更する前に、必ず現在のファイルを読んで記憶と照合します。メモリが古い情報を指している場合でも、実ファイルが正として機能するためです。
🟣 Hermes Agent — フェンスタグ注入型メモリ
ターン開始前にすべてのプロバイダーから記憶を取得し、「これは背景情報です」というフェンスタグで囲んでコンテキストに注入します。これにより、モデルが「記憶」と「現在の会話」を混同しないよう設計されています。
最大2プロバイダー（内蔵1件＋外部1件）に制限されており、これはツール定義の肥大化を防ぐための意図的な制約です。ターン完了後は非同期で全プロバイダーへ書き戻します。
⚠️ 非同期write-backのリスク：書き込み失敗は黙って無視（silent fail）されます。1つのプロバイダーが失敗しても他はブロックされませんが、次回ターンまで記憶が更新されません。
🟢 NemoClaw — メモリレス設計（委譲型）
NemoClawは独自のメモリ機構を一切持ちません。サンドボックス再構築時にワークスペースファイルをバックアップ・リストアするだけです。これはセキュリティ分離の哲学に基づく意図的な設計です。
エージェントの記憶管理はすべてOpenClaw（またはコンテナ内のエージェント）に委譲されます。NemoClaw自身はメモリを「知らない」ことで、メモリへの不正アクセスや改ざんのリスクを排除します。
✅ セキュリティ上の利点：メモリを持たないことで攻撃面積を最小化。サンドボックス外への記憶漏洩リスクがゼロです。
🔵 OpenClaw — ゲートウェイ型セッション永続化
context-engineモジュールがセッションを永続化し、active-memory拡張機能でアクティブメモリを管理します。さらにmemory-host-SDKでサードパーティのメモリプロバイダーも統合可能です。
チャンネル別・エージェント別のセッション分離が実現されており、Telegramでの会話とDiscordでの会話が混ざることはありません。~/.openclaw/agents/に永続化されます。
✅ チャンネル別分離の利点：20以上のプラットフォームを横断しても、各チャンネルの会話コンテキストが独立して保持されます。
4 コンテキスト管理 (Context Management) ▶
| 観点 | Claude Code | Hermes Agent | NemoClaw | OpenClaw |
|---|---|---|---|---|
| 圧縮アルゴリズム | コンテキスト使用量が閾値を超えると自動的に古いターンを要約・圧縮する（オートコンパクト）。APIエラー発生時にも縮小処理を行う。重複するツール結果はキャッシュして排除する | 5段階パイプライン。①ツール結果を1行に圧縮②先頭N件と末尾20K相当のトークンを保護し、中間部分のみ要約対象に③補助モデルが「アクティブタスク・完了済み操作・残作業」等のテンプレートで構造化要約④API規約上ペアでなければならないツール呼び出し/結果が孤立しないようスタブで補完⑤要約に「これは背景情報です」の免責文を付与 | 独自の動的コンテキスト管理を持たない。YAMLで定義されたエージェント設定が静的なシステムプロンプトとして固定 | Gatewayはセッション境界の管理のみ担当。コンテキスト圧縮・管理は各モデルプロバイダー拡張機能に委譲。Anthropicプロバイダーならプロンプトキャッシングを活用、OpenAIプロバイダーなら独自の圧縮戦略を適用する分散アプローチ |
| アンチスラッシング | コンパクション実行後は再実行されないようガード条件を設ける。サブエージェントへのトークン予算引き継ぎに対応 | 直近2回の圧縮でそれぞれ10%未満しかトークンが減らなかった場合は次回圧縮をスキップ。無駄な補助モデル呼び出しを防ぐ | N/A | 各モデルプロバイダー実装に依存。プロバイダーごとの最適化に委任する設計のため、フレームワーク側のアンチスラッシング機構は持たない |
| 重要情報の配置 | プロンプトの先頭と末尾に配置（中間位置の情報が忘れられやすい「Lost in the Middle」問題への対策） | 圧縮時に末尾トークン予算を確保することで、最新のユーザーリクエストが必ず非圧縮領域に残るよう設計 | Blueprint定義内に静的配置 | エージェントごとに設定可能なシステムプロンプトで固定情報を管理。スキル定義（SKILL.md）とmemory-host-SDKによる動的コンテキスト注入で補完 |
📊 トークン消費の比較と圧縮アルゴリズムの詳細
コンテキスト圧縮によるトークン削減率の比較
🟠 Claude Code26〜54%削減（推論精度95%以上維持）
🟣 Hermes Agent動的（アンチスラッシング制御付き）
🟢 NemoClaw0%（静的・圧縮なし）
🔵 OpenClawプロバイダー依存（Prompt Caching活用）
🔄 アンチスラッシング（Anti-thrashing）とは？
コンテキスト圧縮を何度繰り返しても、トークン削減量がほとんど増えない状態に陥ることをスラッシング（thrashing）と呼びます。
❌ スラッシングが起きると...
- 補助モデルへのAPIコストが無駄に発生
- レイテンシが増加してユーザー体験が悪化
- 削減量より圧縮コストの方が大きくなる
✅ Hermesの対策：
直近2回の圧縮でそれぞれ10%未満しかトークンが削減されなかった場合、次回の圧縮をスキップします。
5 プロンプト構築 (Prompt Construction) ▶
| 観点 | Claude Code | Hermes Agent | NemoClaw | OpenClaw |
|---|---|---|---|---|
| 構築方式 | 階層的アセンブリ: システム指示 → ツール定義 → 開発者指示 → ユーザー指示（CLAUDE.md） → 会話履歴。各層は独立して差し替え可能 | モデルごとに応答フォーマット（function_call、tool_use、XMLタグなど）が異なるため、プロバイダー別変換層を通してから統一フォーマットに正規化。スキルの前処理（引数の型変換など）も同層で実行 | YAMLマニフェストからエージェント定義を読み込み、起動時に固定のシステムプロンプトとして設定。動的な追加は行わない | 各エージェントのシステムプロンプトは設定ファイルで定義。Plugin SDKが30以上のモデルプロバイダーAPIの差異を吸収し、統一インターフェースを提供。エージェント設定でプロバイダーを切り替えても同一のプロンプト構造を維持 |
| 動的要素 | メモリ記憶・スキル定義・サブエージェント共有コンテキストを毎ターン評価して必要なものだけ追記 | スキル定義をモデル固有のツールスキーマ形式に変換してから追加。複数プロバイダーを切り替えても同じスキルが使えるよう抽象化 | マニフェストファイルに記載されたエージェント情報から静的ロード。実行時に変化しない | スキル定義（SKILL.md）とmemory-host-SDKによる動的コンテキスト注入。チャンネル別の文脈情報（送信者・グループ・タイムスタンプ等）をアダプタが自動付加。MCPサーバーが提供するツール定義も動的にマージ |
6 出力パース (Output Parsing) ▶
| 観点 | Claude Code | Hermes Agent | NemoClaw | OpenClaw |
|---|---|---|---|---|
| 方式 | APIのネイティブtool_calls形式を使用。構造化出力が必要な箇所ではモデルに特定のツールを呼ばせることで任意のスキーマに準拠した出力を得る | プロバイダーごとに応答形式が異なる（function_call JSON、tool_use XMLなど）ため、受信後に統一の内部形式へ変換。さらにthinkingブロックの署名管理も担う（プロバイダーが異なると署名が無効になるため除去） | コンテナ内のエージェントに委譲。起動前のバリデーションで設定の整合性のみチェック | チャンネルアダプタがエージェント出力を各プラットフォームのメッセージ形式に変換。Canvas出力はA2UIプロトコルで専用UIにレンダリング。音声出力はTTSエンジン（ElevenLabs/Azure Speech等）へ転送 |
| スキーマ違反時 | スキーマパース失敗時は再試行ループ。ツールのスキーマが未取得の場合はその旨をヒントとして付加してモデルに再生成を促す | 実行の軌跡を記録しておき、ツール実行でエラーが起きた場合はエラー内容をそのままモデルへのフィードバックとして次ターンに渡す | 起動前チェックで設定ファイルの形式を検証。起動後のエラーはHTTPヘルスプローブで検知し自動再起動 | チャンネルアダプタのエラーハンドリングで対処。送信失敗は自動リトライ。プラットフォーム固有の文字数制限や添付ファイル制限はアダプタ層で吸収し自動分割 |
7 状態管理 (State Management) ▶
| 観点 | Claude Code | Hermes Agent | NemoClaw | OpenClaw |
|---|---|---|---|---|
| インメモリ状態 | ツール権限・モデル選択・MCPサーバー状態など推論ループが参照する情報を一元管理。UIは必要な部分だけ参照し、無関係な変更では更新されない | YAMLプロファイルで環境ごとの設定を管理。認証情報は複数アカウントのプールから選択し、APIリクエスト時に動的に割り当て（認証情報のハードコードを避ける） | サンドボックスの登録情報（エージェント名・モデル・プロバイダー・ポリシー）をJSONに永続化。複数プロセスからの同時アクセスはmkdirのアトミック性を利用したファイルロックで制御 | Gateway制御プレーンがセッション・チャンネル・ツール・イベントの状態を一元管理。Manifest駆動の設定システムで宣言的に状態を定義。複数ノード（iOS/Android/macOS）のデバイスペアリング状態もGatewayが追跡 |
| チェックポイントと復元 | Gitコミットが暗黙のチェックポイント。任意の時点にロールバック可能。ツール実行前後のファイルスナップショットで差分を追跡し、コスト超過時の調査に使用 | セッション開始・終了時に状態を保存。前回セッションから会話を再開可能。実行軌跡も保存されエラー調査に活用 | Snapshotからサンドボックスをリストア。サンドボックス再構築時もワークスペースファイルが保全される | ~/.openclaw/配下にエージェント設定・認証情報・セッション履歴を永続化。Gateway再起動後も全セッション状態を復元。クラッシュ前のチャンネル接続は自動で再確立 |
8 エラー処理 (Error Handling) ▶
| 観点 | Claude Code | Hermes Agent | NemoClaw | OpenClaw |
|---|---|---|---|---|
| エラー分類とリカバリ | エラーを種類で区別。①一時的エラー（ネットワーク断絶など）→exponential backoffで自動リトライ。②ツール実行失敗→エラー内容をモデルに返して自己修正を促す。③ユーザー修正が必要なエラー→実行を一時停止してユーザーに確認。④予期しないエラー→セッション終了 | レート制限エラーを専用に追跡し、リトライ間隔を動的に調整。HTTP 429を受信すると待機時間を記録し次回リクエスト時に参照。さらに複数アカウントのプールから別の認証情報を選んでフォールバック | 起動前チェックで設定ファイルの整合性と接続可能性を検証（SSRFリスクのあるURLも事前に拒否）。実行中はHTTPヘルスプローブで定期的に生死確認し、応答がなければリカバリスクリプトを実行して再起動 | チャンネルアダプタレベルのエラーは自動リトライ。モデルプロバイダーエラーはフォールバック設定で別プロバイダーへ切り替え。Gateway自体のクラッシュはプロセス管理（pm2/systemd等）で再起動。チャンネル別のエラー通知設定で問題を適切なチャンネルへエスカレート |
| エスカレーション機構 | 最大出力トークン不足時は段階的に上限を拡張して再試行。停止フックがブロックを返した場合も自動でクエリを再実行 | 補助クライアントのフォールバックチェーン：OpenRouter → Nous Portal → カスタムエンドポイント → Codex → Anthropic直接の順に試行。HTTP 402（支払い上限）を受信すると次のプロバイダーへ自動切り替え | ヘルスプローブ（HTTP GET）が失敗するとリカバリスクリプトを実行。スクリプトはまずHTTPエンドポイントに疎通確認し、既に動いていれば何もせず終了する冪等設計 | 複数モデルプロバイダーへのフォールバックチェーンを設定ファイルで宣言的に定義。モデルフェイルオーバー機能でプロバイダー障害を自動検知し次のプロバイダーへ切り替え。OTEL/Prometheusによる診断メトリクスでエスカレーション履歴を追跡 |
9 ガードレール (Guardrails & Safety) ▶
| 観点 | Claude Code | Hermes Agent | NemoClaw | OpenClaw |
|---|---|---|---|---|
| 入力段 | ツール実行前にpre-toolフックを実行し、その結果に基づいて許可・拒否・修正を決定。フックが許可を返した場合のみclassifierによる追加チェックとユーザー確認ダイアログへ進む | メッセージ受信時にプラットフォーム識別情報・個人情報などの機密パターンを検出して置換（レダクション）。さらにSSRFリスクのあるURLへのリクエストを事前にブロック | Blueprintの完全性をダイジェスト（ハッシュ値）で検証し、改ざんされたBlueprintの実行を防止。ネットワークポリシーで送信先ドメインを事前に許可リスト管理 | DMペアリング認証で未知の送信者をブロック。グループID許可リストでチャンネルアクセスを制御。プラグインAPIの権限スコープで拡張機能の操作範囲を限定。Webhookは署名検証で不正リクエストを拒否 |
| 実行段 | シェルコマンドをASTとして解析し、危険なコマンドパターン（rm -rf /、sudo suなど）を構文レベルで検出。ファイルアクセス前に保護対象パスかどうかを判定 | 危険と判断された操作はTelegramやSlackのインタラクティブボタンでリアルタイム承認を要求。Tirithセキュリティスキャナーで依存パッケージの脆弱性も評価 | Linuxのlandlockでファイルシステムアクセスをホワイトリスト制御、seccompでシステムコールを制限。K8sネットワーク名前空間でコンテナ間通信を物理的に遮断 | Docker/SSH/OpenShellサンドボックスモードで非メインセッションを分離。Manifest駆動のポリシー設定でエージェント別の権限を宣言的に定義。セキュリティスキャンはCIで実施 |
| 出力段 | ツールごとに個別のallow/denyリストを持ち、高リスク操作（ファイル削除・外部送信など）は自動承認対象から除外して毎回ユーザー確認を必須化 | ファイル書き込み先がシステム重要ディレクトリでないか判定。メッセージング送信はグループIDの許可リストで制御し、許可されたチャンネル以外への誤送信を防ぐ | バックアップ・リストア時に認証情報ファイル（credentials.jsonなど）を自動除外してサンドボックス外への漏洩を防止。L7プロキシでHTTPトラフィックをフィルタリング | チャンネルアダプタがコンテンツフィルタリング。認証情報は~/.openclaw/credentials/に分離保存し、エージェントへの直接露出を防ぐ。Canvas出力はサンドボックス化されたWebView内でレンダリング |
| 設計哲学 | 「AIが何をするか決め、ハーネスが許可するか判断する」関心の分離。推論と安全性チェックを独立させることでモデルのアップグレードに影響されない | プラットフォームごとに異なる承認UIを持ちながら、承認ロジック自体は共通パイプラインで管理。アプリケーション層での多層防御 | インフラ層（OS・カーネル・ネットワーク）で強制。アプリケーションコードにセキュリティバグがあっても物理的に侵害できない多層防御 | 「デフォルトでローカルファースト、プライバシー重視」。メインセッションはフル権限、非メインセッションはサンドボックス化というハイブリッドアプローチ。自己ホスト型でデータが外部に出ない |
セキュリティ/パーミッションモデル比較
Claude Code: 多層コード解析承認
Hermes: 多層パイプライン
NemoClaw: 同心円多層防御
OpenClaw: エコシステム統合型防御
10 検証ループ (Verification Loops) ▶
| 観点 | Claude Code | Hermes Agent | NemoClaw | OpenClaw |
|---|---|---|---|---|
| 変更検証 | ツール実行前後のファイル差分を記録。トークン消費を上限付きで追跡し、予算超過時に処理を中断 | 実行チェックポイントを定期保存し、失敗時にその時点から再開可能。コスト予算を事前設定し、超過したらエージェントを停止。実行軌跡（各ターンの入出力と結果）をログとして保持 | Blueprintファイルのハッシュ値を起動前に検証し、ビルド成果物と照合。改ざんが検出された場合は起動を拒否。実行中はHTTPエンドポイントへの定期的なプローブでインフラレベルの生死を確認 | QA拡張機能（qa-channel/qa-lab/qa-matrix）によるE2Eテスト。Vitest単体テストと並行E2Eテストランナーを組み合わせ。Blacksmithテストボックスによる広範なCI統合。OpenTelemetry/Prometheusで運用メトリクスを収集 |
| 検証の種類 | ルールベース検証（テスト実行・リンター）とビジュアル検証（スクリーンショット撮影）とLLM-as-judge（結果をモデルに評価させる）の3種を組み合わせ可能 | コスト予算に基づく量的検証が主体。軌跡ログを使ったデバッグ時の品質確認 | 暗号学的完全性検証（ビルドの改ざん防止）とインフラ可用性監視に特化。コンテンツレベルの検証はエージェント側に委任 | 自動化QAチャンネルによるエンドツーエンド動作検証。DiscordラウンドトリップテストやParallels smoke testで実チャンネル統合を確認。ヒープリークテストでメモリ健全性も継続監視 |
11 サブエージェントオーケストレーション ▶
| 観点 | Claude Code | Hermes Agent | NemoClaw | OpenClaw |
|---|---|---|---|---|
| サブエージェント起動方式 | Agentツールでサブエージェントを起動。Gitのworktree機能を使って完全に分離したファイルシステム上で動作させることも可能（リグレッションリスクのある実験的変更向け） | タスク委譲ツールを呼び出すと新しいエージェントセッションが開始される。完了後、委譲結果をメモリプロバイダーへ通知することで親エージェントのコンテキストが更新される。ACPプロトコルを経由すれば外部の異種エージェントへも委譲可能 | Blueprintの定義に基づいて複数のサンドボックスPodを起動する。各PodはK8sのワークロードとして管理され、独立したライフサイクルを持つ。Pod間の通信はK8s内部ネットワーク経由のみ | マルチエージェントルーティングでinbound channelを複数の分離されたエージェントワークスペースへ振り分け。ルーター設定で振り分けルールを宣言的に定義。ワークスペース単位の権限分離でエージェント間の干渉を防止 |
| エージェント間通信 | 親→子はコンテキストで初期タスクを渡し、子→親はツール実行結果として返す | ACPプロトコル（標準化されたエージェント間通信仕様）でメッセージをやり取り。外部エージェントに対してもローカルツール呼び出しと同じインターフェースで操作できる | K8sクラスタの内部DNSとサービスを使ったネットワーク通信。外部ネットワークはポリシーで制限 | Gatewayの内部イベントバス経由で通信。チャンネルをまたいだルーティングは設定で宣言的に定義。ACPプロトコルも拡張機能として追加可能 |
| 隔離強度 | Worktreeオプション使用時はgit worktreeによりファイルシステムが物理的に分離。通常のサブエージェントは同一ファイルシステムを共有 | 実行バックエンドに依存（Dockerを選ぶと完全隔離、Localなら共有） | K8s Pod + ネットワーク名前空間 + Landlock/Seccompの組み合わせで最も強固な隔離 | エージェントごとに独立したセッションとワークスペース。サンドボックスモード（Docker/SSH/OpenShell）で更に強固な分離も選択可能。デフォルトはセッション単位の論理的分離 |
12 初期化 (Initialization) ▶
| 観点 | Claude Code | Hermes Agent | NemoClaw | OpenClaw |
|---|---|---|---|---|
| 起動シーケンス | 設定ファイルのロード → MCPサーバー接続 → 推論エンジン起動。CLAUDE.mdが存在すれば自動的にシステムプロンプトに追記 | プロファイルYAMLを解決 → 実行環境（Local/Docker/Modal）を検出 → 利用可能なLLMプロバイダーを優先度順に選択 → エージェントループ起動 | インタラクティブなウィザードで推論エンドポイントを設定 → BlueprintのYAMLをパースして有効性を検証 → サンドボックスPodを生成 → HTTPプローブでエージェントの起動を確認 | 対話的ウィザード（openclaw wizard）でプロバイダー・チャンネル・権限を設定 → Gateway起動 → 設定済み拡張機能を自動ロード → チャンネルアダプタが各サービスへ接続 → デバイスペアリングを確立 |
| 設定の柔軟性 | ユーザー設定（~/.claude/settings.json）とプロジェクト設定（.claude/settings.json）の2層構造。CLAUDE.mdはプロジェクトの任意ディレクトリに置け、サブディレクトリごとに異なる指示を持てる | YAMLプロファイルで環境別設定を管理。CLIフラグで実行時に特定プロファイルを指定可能。プロバイダー選択や実行バックエンドも切り替えられる | Blueprint YAMLに全設定を集約。エージェントの種類・使用モデル・ネットワークポリシー・認証情報のマウント先をすべてここで宣言的に定義 | ~/.openclaw/設定ディレクトリと環境変数の2層。チャンネル・エージェント・拡張機能をYAML/JSONで宣言的に設定。ホットリロード対応でGateway再起動なしに設定変更を反映可能 |
12コアモジュール出典：
Akshay Pachaar「The Anatomy of an Agent Harness」— Daily Dose of Data Science（2026年3〜4月）
— 11コンポーネント + 7アーキテクチャ決定。「初期化」モジュールはYouTube動画「Agent Harness十二大模块完全解析」が追加。
