【第1部】Hermes Agentから始まったローカル・マルチエージェント基盤
一体のAgentを、二体の異種LLMによる討議へ広げる
はじめに
はじめまして。今回が、初めての技術ブログですが、書いているうちに書くことも増え、3部作としてまとまりつつあります。今回は第一部となります。
普段は社内で、AIに関する技術検証やサービス開発に取り組んでいます。
AIをめぐる技術の変化は速く、動向を追うだけでなく、実際に環境を構築して確かめることも大切だと感じています。
今回紹介する環境も、最初から完成図を描き、その通りに構築したものではありません。出発点は、NVIDIA DGX Spark上に、一体のHermes Agentを準備したことでした。
まずはローカルLLMを使ったAgent環境を動かしてみる。そこから、Hermes Agentとの対話を重ねながら、推論モデルを更新し、異なるモデルを追加し、やがて複数のAgentが議論する構成へと発展していきました。
この連載では、LLMへ状態、Tool、Policy、実行制御を加える層を Harness、複数のAgent Harnessを一段上から束ねる層を Meta-Harness としました。
LLM
└─ 推論を担う
Hermes Agent / Harness
└─ 推論、Tool実行、観測のループを回す
Omnigent / Meta-Harness
└─ 複数AgentのSession、役割、受け渡し、統合を扱う
ただし、ユーザーが見るUIから最奥のLLMまでの間に、Harnessが一層だけ存在するとは限りません。実際のAgentシステムでは、UI、アプリケーション、Meta-Harness、Agent Harness、推論Runtimeが重なることがあります。
この多層性は、Policy、交換可能性、障害分離をもたらします。一方、各層でSession準備、入力検査、Dispatch、応答回収、出力検査、記録が行われれば、その時間は最終応答へ積み上がります。
Harnessが多いほど安全になるとは限らない。責任境界が見えないHarnessは、遅延と複雑さを増やします。
1. Hermes Agentとは何か
Hermes Agentは、LLMへ質問を送るだけのチャット画面ではありません。目的に応じてToolを選び、結果を受け取り、次の判断へつなげるAgent Harnessです。
当初は、Ollama上のQwen3.6-27Bを利用する一体のHermes Agentから始めました。Agentは手順や変更案を提示し、人間が内容を確認して実行します。構築を支援するAgentと対話しながら、そのAgent自身が利用する環境を変えていく点が、従来の手順書とは異なりました。
図. HermesAgentのCLI
2. Qwen3.8-27bへの更新と、Reasoning時間
Hermes Agentへ、Qwen3.8-27bを使えるようにしたいと相談しました。Agentは既存のOllama環境を前提に、モデル導入、接続先変更、起動確認に必要な作業を整理しました。
今回試した範囲では、Qwen3.8-27bの最終回答の品質には手応えがありました。一方、最終回答へ至るまでのReasoningに時間を要する場面もありました。
ここで注意したいのは、ユーザーが感じる遅延をモデルだけに帰属できないことです。
総応答時間
= UI・通信
+ Session準備
+ AgentへのDispatch
+ LLMのReasoning <---- 一要素に過ぎない。
+ Tool実行
+ 応答回収
+ Moderator統合
+ Policy評価
+ Trace・Memory処理
+ UIへの返却
Qwen3.8のReasoning時間は一要素です。回答が生成済みでも、Harnessが回収、統合、検査、表示を終えていなければ、ユーザーにはまだ処理中に見えます。
したがって、正確には「Qwen3.8が遅い」ではなく、最終回答までの経路のどこが時間を使っているかをEnd-to-Endで観測する必要があると考えました。
その上で、軽い確認や反論まで同じ深さのReasoningを使う必要があるのか、Hermes Agentへ相談しました。これが二体目のAgentを用意するきっかけになりました。
3. 置き換えず、役割を分ける
Qwen3.8-27bを軽量モデルへ全面的に置き換えるのではなく、深い分析と素早い別視点を分担させることにしました。
Gemma側には、llama.cpp上の gemma-4-26B-A4B-it-MXFP4_MOE を利用しました。26BクラスのMixture of Expertsモデルを、指示応答向け・MXFP4量子化の形で使う構成です。
二つの推論プロセスとモデル設定は分けますが、DGX SparkのGPUと統合メモリは共有します。完全隔離ではなく、管理と切り分けをしやすくするための「制御しやすい分離」です。
4. OmnigentによるSessionベースの討議
二体を用意しただけでは、回答が二つ並ぶだけです。そこで、Meta-HarnessであるOmnigentを使いました。
OmnigentはAgentをSessionとして扱い、Moderatorが各Sessionへ依頼を送り、結果を回収し、別Sessionへ渡して統合します。
当時確認したDebate例はGPTとClaudeを使う構成でしたが、Omnigentへ先に接続していたQwen3.8へ「ローカルの二体のHermesを議論させたい」と相談し、調整案を作ってもらいました。
独立したSessionを維持したまま、Moderatorがメッセージを仲介することが、討議の実体です。これにより、Omnigentに最初から専用Debateとして用意されていなかったローカルモデルも、Hermes Agentとして討議フローへ参加できました。
以下は、Omnigent上で、「この環境についてqwenとgeminiで相談してわかりやすく説明してください。」とするとそれぞれの意見が出力され、相違点や、まとめが最終的に出力されます。
図. OmnigentのGUI
5. 「育成」ではなく「検証・改善可能」
現在の仕組みは、モデルが自律的に重みを書き換えるRSI(再帰的自己改善)ではありません。
そのため、「育成可能」よりも 検証・改善可能なAI × Harness と表現する方が、現在の到達点に合います。
Agentが自分で賢くなる基盤ではなく、Agentの働き方を検証し、改善を積み重ねられる基盤。
結び
一体のHermes Agentから始まり、モデル更新、役割分担、二体目の追加、Sessionベースの討議へ進みました。
Agentと対話しながら、Agentが働くためのHarnessを組み上げる。
次に、二体のHermesへRikAI2との接続を相談すると、MCPでTool化する案が生まれました。第2部では、その接続を扱います。
次回
【第2部】知性に新しい能力をつなぐ
動いていたREST API接続を、RikAI2-MCP Toolへ広げる
リンク