連載「Hermes Agent を読み解く」全10回
はじめに — コアを書き換えずに伸ばす
前回までで Hermes の「素のまま」の能力は見尽くした。だが実運用では、自分の環境に合わせて能力を足したくなる。Hermes はコア本体を改造させずに拡張する経路を複数用意している——プラグイン、スキル、フック、プロファイル、Cron。今回はこの拡張運用と、最後に「学習データ製造機」としての一面を覗く。
1. プラグイン規約
プラグインは 4 つのソースから読まれる。
- bundled — Hermes に同梱
-
user — ユーザーの
~/.hermes/配下 - project — プロジェクトディレクトリ
- pip — pip でインストールされたパッケージ
各プラグインは plugin.yaml（メタ情報）と register(ctx)（登録関数）を持つ。読み込みは kind 別——モデルプロバイダ、プラットフォーム、メモリ、ツールなど種別ごとに、適切なレジストリへ振り分けられる。第1回で見た 28 モデルプロバイダや 8 プラットフォームも、この仕組みで差し込まれている。
register(ctx) の ctx（PluginContext）が差せるものは多彩だ（hermes_cli/plugins.py）。register_tool / register_platform / register_command（slash コマンド）/ register_cli_command（hermes <sub>）/ register_memory_provider / register_web_search_provider / register_image_gen_provider / register_video_gen_provider / register_browser_provider / register_tts_provider / register_transcription_provider / register_context_engine / register_skill / register_hook——つまりコアのほぼ全レイヤに、改造なしで差し込み口がある。
とりわけ強力なのが hook。register_hook(name, callback) で、VALID_HOOKS（plugins.py:128）に定義されたライフサイクルの要所へ介入できる。確認できた主なフック: pre_tool_call / post_tool_call（ツール実行の前後。pre_tool_call からはツールをブロックもできる）、transform_tool_result / transform_terminal_output / transform_llm_output（出力の書き換え）、on_session_start（セッション開始）、pre_approval_request（承認要求への介入）など。挙動を「外側から」曲げられる正規の経路だ。
2. スキル（宣言的）と curator
スキルはプラグインと違い、コードではなく宣言的だ。markdown + YAML フロントマターで書かれた手順書で、~/.hermes/skills に置く。第5回の skills_list / skill_view / skill_manage から扱える。
肝は progressive disclosure（段階的開示）。スキルの全文を最初から context に積むのではなく、まず一覧（名前 + 説明）だけを見せ、必要になったら skill_view で本文を読み込む。context を節約しつつ、膨大なスキル群を抱えられる。
スキルが増えすぎたら curator が自動で整理する（agent/curator.py）。具体的な既定値はこうだ:
- 実行間隔
DEFAULT_INTERVAL_HOURS = 24 * 7（7 日ごと） -
DEFAULT_STALE_AFTER_DAYS = 30（30 日触れられないと stale 判定） -
DEFAULT_ARCHIVE_AFTER_DAYS = 90（90 日で archive 候補） -
自動削除はしない——archive のみで、archive は復元可能（
curator.py:17） - 補助クライアント（auxiliary）で動き、メイン会話の prompt cache には一切触れない（
curator.py:19）
掃除はするが消しはしない、という安全側に倒した設計だ。加えて skills_guard が不正なスキルの読み込みを防ぐ。第10回のセキュリティにつながる防御だ。
3. Obsidian / PKM 実践
ここは私自身が日常的に使っている領分なので具体的に書く。Hermes には obsidian スキルがあり、汎用のファイルツール（第5回の read_file / write_file / search_files）と組み合わせると、Obsidian vault を PKM（Personal Knowledge Management）基盤として扱える。
実践的な構成はこうだ。cron で日次ジャーナルを自動生成する——毎朝、前日の会話ログやタスクボードの状態を Hermes に要約させ、vault の日次ノートに追記する。obsidian スキルがノートのフォーマット規約（フロントマター、リンク記法）を知っているので、人手で整える手間が要らない。私の Mac Studio 上のローカル LLM とこの仕組みを組むと、外部に何も送らず手元だけで知識が蓄積されていく。
4. Hooks / Profiles / Cron
-
Hooks — ライフサイクルの要所（セッション開始 / 終了、ツール実行前後など）やシェルコマンドにフックを差せる。ただし
--accept-hooksは要注意——フックは任意コードを走らせうるので、信頼できないフック定義を無検証で受け入れるのは危険（第10回） -
Profiles —
HERMES_HOMEを切り替えることで、設定・状態・資格情報をプロファイル単位で分離できる。仕事用と個人用、本番と検証、といった使い分けに効く - Cron — スケジューラ。§3 の日次ジャーナルのような定期実行を担う
HERMES_HOME によるプロファイル分離は、第10回の「terminal バックエンド隔離」とも関わる。プロファイルを分ければ資格情報の混線も防げる。
5. RL・データ生成の側面
最後に、見落とされがちな一面。Hermes は単なる実行エージェントではなく、学習データの製造機でもある。
- batch_runner（1,321 行）— 多数のタスクをバッチ実行（multiprocessing、チェックポイント付き）
- mini_swe_runner（731 行）— SWE（ソフトウェアエンジニアリング）タスクを local/docker/modal で実行
- trajectory_compressor（1,508 行）— エージェントの行動軌跡（trajectory）を学習用に圧縮
合わせて約 3,560 行が「実行」ではなく「データ生成」のための道具立てだ。
これらは強化学習（RL）や教師あり学習向けの軌跡データを量産するための道具立てだ。第5回で「TOOLSETS がバッチ用に確率分布を持つ」と書いたのを思い出してほしい——多様なツール構成をサンプリングしながらタスクを大量に走らせ、その軌跡を集めて学習に回す。Nous Research がモデルを訓練する組織であることを踏まえると、Hermes Agent が「製品」であると同時に「データ生成基盤」でもある二面性が見えてくる。