7
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@anchor_(anchor)
in

Hermes Agent と DeepSeek Harness は何が違うのか

7
Posted at

はじめに

2026年現在、OSSのAIエージェント実装は「どのモデルを使うか」よりも 「どのハーネス（実行基盤）に乗せるか」 が選定の焦点になりつつあります。

本記事では、その中でも設計思想が対照的な2つを読み比べます。

  • Hermes Agent（Nous Research） — 自己改善ループを内蔵した「自律エージェント製品」
  • DeepSeek Harness / dsh（DeepSeek AI） — 「すべてがプラグイン」を掲げるエージェント基盤

どちらもMITライセンスのOSSですが、そもそも解こうとしている問題が違います。「どちらが優れているか」ではなく「どちらが自分の用途に合うか」を判断できるよう、公式ドキュメントの記述をベースに整理しました。

1. 30秒でわかる違い

Hermes Agent DeepSeek Harness (dsh)
開発元 Nous Research DeepSeek AI
一言でいうと 使うほど賢くなる自律エージェント 全部差し替えられるエージェント基盤
主言語 / 基盤 Python TypeScript（pnpm / vitest）+ Cordis
コア設計 AIAgent を中心とした単一ループ + レジストリ拡張 特権カーネルなしのプラグインツリー
主な入口 CLI / デスクトップ / 20以上のメッセージング / ACP（IDE） Web UI（既定 127.0.0.1:3080）/ headless
状態管理 SQLite + FTS5 セッションDB 追記専用の SessionEvent ログ
際立った機能 経験からのスキル自動生成、永続メモリ profile / bundle / patch による構成合成
成熟度 機能が広く積み上がった状態 developer preview（破壊的変更あり）
ライセンス MIT MIT

ざっくり言えば、Hermes は「完成品のエージェント」、dsh は「エージェントを組み立てるためのフレームワーク」 です。

2. Hermes Agent の特徴

2-1. 「閉じた学習ループ」が中核

Hermes の最大の差別化ポイントは、ドキュメント冒頭で真っ先に主張されている 学習ループ です。単発の会話で終わらず、以下が回ります。

  • 経験からエージェント自身がスキルを生成し、使用中にそのスキルを改善する
  • 記憶を残すよう自分自身に定期的に促す（nudge）
  • FTS5による全文検索 + LLM要約でセッションをまたいだ想起
  • Honcho による対話的ユーザーモデリング

一般的な「RAG的メモリ」ではなく、手続き的記憶（スキル）とエピソード記憶（セッション）の両方を自律的に更新していく 点が特徴的です。スキルは agentskills.io 準拠のオープン標準なので、他ツールとの持ち運びもできます。

2-2. ノートPCに縛られない実行環境

ターミナルバックエンドが local / Docker / SSH / Daytona / Singularity / Modal（＋Vercel Sandbox）と多彩で、Daytona・Modal ではアイドル時に環境がハイバネートするサーバーレス運用が可能です。「$5のVPSに常駐させて、Telegramから話しかける」という使い方が想定されています。

2-3. 「人間がいる場所」に出ていく

Telegram / Discord / Slack / WhatsApp / Signal / Matrix / Teams / 飛書 / 企業微信 / メール / SMS など 20以上のプラットフォームを単一ゲートウェイで束ねます。さらに ACP アダプタにより VS Code / Zed / JetBrains からもエディタネイティブエージェントとして扱えます。

2-4. アーキテクチャ

Entry Points  : CLI / Gateway / ACP / Batch / API Server / Python Library
      ↓
AIAgent (run_agent.py)
      ├─ Prompt Builder（stable → context → volatile の3層）
      ├─ Provider Resolution（18以上のプロバイダを api_mode に解決）
      └─ Tool Dispatch（70以上のツール / 約28ツールセット）
      ↓
Session Storage (SQLite + FTS5)   Tool Backends (Terminal / Browser / Web / MCP …)

設計原則として掲げられているのは以下です。

原則 意味
Prompt stability 会話途中でシステムプロンプトを変えない（キャッシュを壊さない）
Observable execution すべてのツール呼び出しがユーザーに見える
Interruptible API呼び出し・ツール実行を途中で中断できる
Platform-agnostic core 単一の AIAgent が CLI / gateway / ACP / batch を兼ねる
Loose coupling MCP・プラグイン等はレジストリと gating で疎結合
Profile isolation プロファイルごとに HERMES_HOME・設定・記憶・セッションを分離

「1つの強いコアがあり、その周辺を拡張点で囲う」 という、素直で読みやすい構造です。

3. DeepSeek Harness の特徴

3-1. 「特権カーネルが存在しない」

dsh のアーキテクチャドキュメントで最も重要な主張はここです。

モデルアダプタ、ツールレジストリ、セッションログ、そして エージェントループそのものまでがプラグインであり、すべて設定から差し替え可能。

つまり、パッチを当てるべき中心核が存在しません。拡張とは「他のプラグインの隣にプラグインをマウントすること」であり、各種の登録は副作用として扱われ、プラグインのアンロード時に自動的に巻き戻されます。

これは Cordis（時空間合成可能性のためのプログラミングパラダイム）に由来する設計で、Hermes の「コア + 拡張点」とは発想が根本的に異なります。

3-2. profile / bundle / patch による構成合成

起動中の dsh は、レイヤーを順に重ねて構築されたプラグインツリーです。

空のエントリリスト
  ← ① profile が列挙する bundle を順に適用
  ← ② profile の cordis.patch.yml
  ← ③ home レベルの cordis.patch.yml
  ← ④ --patch オーバーレイ
  • bundle … Cordis設定 + 実装コードの配布単位。dsh-base（モデルアダプタ、ツール、永続化、サンドボックス、承認ポリシー、認証情報、テレメトリ）が全profileの第1層。その上に dsh-web-app（ブラウザアプリ）や dsh-headless（サーバーなしのワンショット実行）が乗る
  • profile … bundle の組み合わせに名前を付けたもの。web と headless が同梱テンプレート
  • patch … idでエントリを特定し、config丸ごと置換または新規挿入

実際に何が起動しているかは以下で確認でき、表示された全エントリが自前のpatchで置換可能です。

dsh --profile web --dump-config

Nixのオーバーレイや Kubernetes の Kustomize を触ったことがあれば馴染みやすい発想でしょう。

3-3. ターンとステップ、そしてイベント

エージェントループが明示的なイベントモデルとして定義されているのも特徴です。

  • ステップ = 1回のモデルリクエスト + そこから呼ばれたツール
  • ターン = 0個以上のステップ。最初の入力を受け取る前に開き、負債がなくなったら閉じる
turn/start
  agent/pre-step        ← モデルが何を見るかを決定（reject / rewrite 可能）
  step/start
    agent/request → llm/stream → assistant/chunk* → assistant/message
    tool/call* → tools/pre-execute → tools/execute → tools/post-execute → tool/result*
  step/end
  agent/turn-stopping
turn/end

agent/pre-step・agent/request・llm/stream・tools/* は waterfall イベントで、リスナーが next() を呼ばないと下位に委譲されません。つまり プロンプト書き換えやツール実行の割り込みが、一級の拡張点として設計されているということです。

3-4. 「モデルが見たものは必ず記録されている」

セッションログは追記専用のイベント列で、deriveMessages() がそこからモデル履歴を投影します。ここに強い不変条件が置かれています。

モデルリクエストに到達したものはすべてログから再構築できなければならない。

したがって、モデル可視の入力を新設するなら SessionEventMap を拡張してログからレンダリングする必要があります。fork・resume・トランスクリプト・テレメトリ・永続化がすべて同じイベント列から派生するため、再現性とデバッガビリティが極めて高い設計です。

3-5. 能力 seam（縫い目）

dsh では「差し替え可能な能力」を Service Definition（インターフェース）/ Service Provider（実装）/ Consumer（利用側、多くはツール） の3役セットで定義します。

この設計の効き目が分かりやすい例が実行環境です。ファイルシステムとプロセスのプロバイダは同じ実行世界を共有するため、それらをリモートサンドボックスに向けるだけで Bash・PTY・LSP がまとめて移動します。プロバイダ専用のforkは不要です。

4. 観点別の比較

4-1. 拡張のしやすさ

観点 Hermes Agent DeepSeek Harness
ツール追加 tools/*.py にファイルを置き、import時に registry.register()。手動のimportリスト不要 ctx.tools に登録。schemaがプロンプト組み立てに参加
モデル追加 プロバイダレジストリに追加し api_mode を解決 ctx.llm にアダプタを登録
ループ自体の改変 コア（run_agent.py）に手を入れる領域 プラグイン差し替えで可能（ループもプラグイン）
巻き戻し 明示的な仕組みは前面に出ない 登録＝副作用、アンロードで自動撤回

カスタマイズの深さは dsh に明確な分がある一方、Hermes は「ファイルを置けば自動発見」という着手の軽さで勝ります。

4-2. すぐ使えるか

Hermes は curl | bash（またはデスクトップインストーラ）で入り、hermes setup --portal の OAuth 一発でモデルとツールゲートウェイ（Web検索・画像生成・TTS・ブラウザ）が揃います。

dsh は Node.js があれば以下でWeb UIが立ち上がります。

npx @deepseek-ai/dsh web

ただし developer preview であり、互換性を壊す変更が入ると明言されています。本番前提で採用するのは現時点では慎重になるべきです。

4-3. 記憶とコンテキストの思想

ここが最も哲学の差が出るところです。

  • Hermes … 記憶を能動的に育てる。要約による圧縮（context_compressor.py）、プロンプトキャッシュ、スキルの自己改善。「賢くなる」方向への投資
  • dsh … 記憶を正確に残す。追記専用ログ + 投影、モデル可視＝記録の不変条件。「壊れない・追える」方向への投資

Hermes の圧縮は非可逆な要約である点に注意が必要です。長時間セッションの完全な監査可能性を重視するなら dsh のログモデルのほうが適しています。

4-4. 運用形態

Hermes Agent DeepSeek Harness
常駐運用 ◎ VPS常駐 + チャット越し操作が主用途 △ Web UI / ワンショット runner 中心
チャット連携 ◎ 20以上のプラットフォーム 記載なし（プラグインで実装する領域）
IDE統合 ○ ACP（VS Code / Zed / JetBrains） Web UI が標準
定期実行 ○ cron内蔵（エージェントタスクとして） ジョブは ctx.jobs に登録する拡張ポイント
研究用途 ◎ トラジェクトリ出力（ShareGPT形式）、Atropos連携のRL学習 記載なし

5. どちらを選ぶべきか

Hermes Agent が向いているケース

  • 今すぐ動く個人用エージェントが欲しい
  • Slack / Telegram などチャットから叩ける常駐アシスタントを作りたい
  • 使うほど賢くなる永続メモリとスキル蓄積に価値を感じる
  • Python資産が多い、または RL学習用のトラジェクトリを取りたい

DeepSeek Harness が向いているケース

  • 自社製品にエージェントを組み込む（ループやツール群を自分の要件に合わせて再構成したい）
  • 監査可能性・再現性が要件（金融、医療、SIなど）
  • TypeScript / Node が主戦場のチーム
  • サンドボックスや実行基盤を自社インフラに差し替えたい

迷ったら

「エージェントを使いたい」なら Hermes、「エージェントを作りたい」なら dsh。

この一行がおおむね実態を表しています。

6. 併用という選択肢

両者は排他ではありません。実際の構成例としては、

  • Hermes をフロント（チャット、記憶、スキル蓄積）に置き、DeepSeek をモデルプロバイダとして接続する
  • dsh を製品組み込み用の基盤として評価しつつ、日常のワークフローは Hermes で回す
  • 双方とも MCP に対応しているため、社内ツールをMCPサーバーとして一度実装すれば両方から使える

MCP を共通インターフェースに据えておけば、ハーネスの乗り換えコストを下げられるのが実務上の要点です。ハーネスの選定は今後も動くと想定して、ツール側を可搬にしておくのが安全でしょう。

まとめ

Hermes Agent DeepSeek Harness
一言 学習し続ける自律エージェント 全部差し替えられる合成基盤
強み 即戦力、記憶とスキル、チャット網羅 拡張の深さ、再現性、構成の透明性
弱み コアの改変は重い、圧縮は非可逆 preview段階、組み立てが前提
誰向け エージェントを使う人 エージェントを作る人

同じ「エージェントハーネス」というカテゴリでも、Nous Research は認知（賢くなること）に、DeepSeek は構造（組み替えられること）に投資している——この対比を押さえておくと、今後出てくる類似プロダクトの位置づけも読み解きやすくなるはずです。

参考リンク

7
4
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
7
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?