Hermes Agent Wiki 非公式・日本語wiki

インストール

目次

Hermes Agent は 2 分もかからずに動く状態になります。

手早く導入する

macOS / Windows のデスクトップ版パッケージ

お使いのプラットフォーム向けのパッケージを Hermes の公式サイトからダウンロードします。

  • Windows: ダウンロードした .appinstaller を Windows アプリ インストーラーで開きます。

署名済みの MSIX バンドルがインストールされ、更新の取得元も記録されます。 Microsoft Store 版のパッケージは Store 側の管理になり、これとは別です。

  • macOS: DMG を開き、Hermes.app をアプリケーションフォルダーにコピーします。ZIP 版の

配布物には、自動アップデーターが使う署名済みのアプリが入っています。

パッケージ版には、エージェント本体、Python、対応する依存パッケージ、ビルド済みの 画面一式が同梱されています。初回起動時にこの基本の実行環境をビルドすることはありません。ただし、プロバイダーへの接続や 任意で追加する連携機能には、引き続きネットワーク接続が必要な場合があります。

Hermes-Setup というブートストラップ用のインストーラーは別物です。こちらはソースを ダウンロードしてインストールし、デスクトップアプリをビルドします。Hermes Desktop をご覧ください。

リモート専用のデスクトップ版を別にダウンロードする形はありません。別の端末にある Hermes のバックエンドを デスクトップ版から使うには、上のパッケージのどれかを入れてから、Settings → Gateways で接続します。 リモートバックエンドへの接続 をご覧ください。

Hermes Desktop を使わない場合

Hermes Desktop なしでコマンドライン版だけを入れるときは、次を実行します。

Linux / macOS / WSL2

curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

Windows（ネイティブ）

PowerShell で実行します。

iex (irm https://hermes-agent.nousresearch.com/install.ps1)

コマンドライン版だけを入れたあとで Hermes Desktop も導入して起動したくなったら、次を実行するだけです。

hermes desktop

Android / Termux

aarch64 の Android 端末では Termux の APT パッケージを使います。 pkg install hermes-agent を実行する前に、署名付きのリポジトリを設定してください。 デスクトップ / サーバー向けのスクリプトは、Termux でのインストール手段ではありません。

ソースからのインストーラーが行うこと

スクリプトはソースをクローンし、uv を用意したうえで、依存パッケージの準備を PM に任せます。PM は、バージョンを固定した Python、Node.js、npm、ripgrep、FFmpeg を用意します。ソースからの インストールでは Python の all extra が選ばれます。任意の extra がすべて入るわけではありません。 PM は既定でブラウザ用とコンピュータ操作用のツールも入れます。agent-browser と、バージョンを固定した Chromium、それに cua-driver（コンピュータ操作のドライバー。macOS、Windows、glibc の Linux が対象）です。 ダウンロードに失敗してもインストールそのものは最後まで進み、再試行用のコマンドが表示されます。 既定のブラウザドライバー（Browser Use CLI の中核である browser-harness）はふつうの Python の依存パッケージなので、 デスクトップアプリを含め、どのインストールにも最初から入っています。 そのほかの任意ツールは、それぞれの機能ごとのインストール手順で入れます。

新しくインストールすると最新の安定版リリースが入り、以後 hermes update もそのチャンネルを追いかけます（更新を参照してください）。代わりに main の最新を入れたい場合は、POSIX では --channel main、Windows では -Channel main を渡します （ワンライナーの場合は、先に HERMES_INSTALL_CHANNEL=main を設定します）。

ブラウザ用ツールを入れたくない場合は、POSIX では --skip-browser、Windows では -SkipBrowser を渡します。コンピュータ操作のドライバーなら --skip-computer-use / -SkipComputerUse です。Hermes はこれらの選択を覚えていて、あとのインストールや hermes update でも入れ直しません。入れたくなったら hermes pm install agent-browser か hermes pm install cua-driver を実行すると、ツールが入り、この選択も取り消されます。

スクリプトは起動用のランチャーを作り、データディレクトリを用意します。対話モードで実行した場合は、 セットアップとゲートウェイの設定も続けて始まります。POSIX の --non-interactive、Windows の -NonInteractive を付けると、入力が必要な段階を飛ばします。任意で付けられる --include-desktop / -IncludeDesktop を指定すると、デスクトップ版をソースからビルドします。

ターミナルで実行すると、スクリプトは手順ごとに 1 行の進行状況を表示し、git・uv・各ビルドの 出力は Hermes のデータディレクトリ配下の logs/install.log に書き出します。 失敗した手順があると、その出力の最後の数行とログのパスが表示されます。CI（CI または GITHUB_ACTIONS が設定されている環境）、出力をリダイレクトしている場合、--verbose / -Verbose、 HERMES_INSTALL_VERBOSE=1 のいずれかでは、すべての出力をそのまま流します。

インストール先の構成

方法 コードの場所 CLI の起動口 ユーザーデータの既定の場所
POSIX 用のソーススクリプト ~/.hermes/hermes-agent/ ~/.local/bin/hermes のラッパー ~/.hermes/
Windows 用のソーススクリプト %LOCALAPPDATA%\hermes\hermes-agent\ %LOCALAPPDATA%\hermes\bin\ %LOCALAPPDATA%\hermes\
デスクトップ版パッケージ インストールしたアプリのパッケージ内 パッケージ同梱のランチャー、Windows ではアプリ実行エイリアス プラットフォームごとの既定の Hermes データディレクトリ
Docker /opt/hermes/ イメージのエントリーポイントと hermes のシム マウントした /opt/data/
Termux APT $PREFIX/lib/hermes-agent/ $PREFIX/bin/ 内のシンボリックリンク ~/.hermes/

ユーザーデータの場所は HERMES_HOME で決まります。POSIX 用スクリプトの --dir は、ソースの チェックアウト先をそれとは別に指定します。Windows では -HermesHome と -InstallDir を使います。 POSIX 用スクリプトを root で実行しても、自動で FHS 配置になるわけではありません。 ソースの場所を明示しない限り、root のホームディレクトリが使われます。

PM のツール置き場と、インストールごとの Python の世代は、それぞれ別に管理され、残る期間も異なります。 置き場所は パッケージ管理 をご覧ください。 アプリのインストールを直す目的で、データのルートディレクトリを削除しないでください。

インストールしたあと

シェルを読み込み直せば、そのまま会話を始められます。

source ~/.bashrc   # or: source ~/.zshrc
hermes             # Start chatting!

あとから個別の設定を変えたいときは、それぞれ専用のコマンドを使います。

hermes model          # Choose your LLM provider and model
hermes tools          # Configure which tools are enabled
hermes gateway setup  # Set up messaging platforms
hermes config set     # Set individual config values
hermes config get     # Inspect individual config values
hermes setup          # Or run the full setup wizard to configure everything at once

前提条件

POSIX 用のソーススクリプトを使うには、Git、curl、tar、SHA-256 のチェック用ツールを用意してください。 Windows では、Git が入っていなければ、バージョンを固定した Git for Windows のアーカイブを自動で用意できます。 スクリプトは常に、検証済みの固定版の uv をダウンロードします。PATH にすでにある uv は使いません。

現在の公式のインストールは Python 3.14 で動きます。pyproject.toml にある >=3.11,<3.15 という広めの範囲は、古い Python のインストールでもアップデーターを 動かせるようにして、PM が 3.14 へ切り替えるまでをつなぐためのものです。3.11〜3.13 で現在の 実行環境が動くことを約束するものではありません。PM が使うツールのバージョンは pm/lock.json で決まります。システムに入っている任意のバージョンの Node を、 インストール先の実行環境として採用することはありません。

ソースからビルドする場合は、ネイティブのコンパイラーとプラットフォームの開発用ライブラリが必要になることがあります。 Electron をソースからビルドするなら、Node のネイティブモジュール用の要件も加わります。これらの ビルド用の前提条件は、完成品のデスクトップ版パッケージを入れる場合には当てはまりません。 Linux の Chromium には、ディストリビューションが提供するシステムライブラリも必要です。

glibc の Linux では、PM が管理する Node.js が libatomic.so.1 にリンクしています。 最小構成の Debian、Ubuntu、RHEL 系のイメージには、このライブラリが入っていません。 ライブラリが見つからないときは、インストーラーと hermes update がディストリビューションのパッケージを入れます （apt と zypper では libatomic1、dnf/yum と apk では libatomic、pacman では gcc-libs）。 root で動いていればパッケージマネージャーをそのまま実行し、そうでなければ sudo -n で実行します。 対話的に実行した場合は、依存関係を入れる前に sudo のパスワードを 1 回だけ尋ねます。 --non-interactive で実行した場合は、何も尋ねません。インストールを実行できなかったときは、 見つかったパッケージマネージャー用の正確なコマンドがエラーに表示されます。

手動インストール / 開発者向けインストール

ソースをチェックアウトして使う場合は、まず PM を使った開発の流れをご覧ください。 環境の有効化、日々使うコマンド、依存パッケージの更新、現時点でのブートストラップの制限をまとめています。 テスト用の環境とチェックは、別ページの 開発環境のセットアップ で扱っています。

sudo なしの環境 / システムサービス用ユーザーでのインストール

ソースからのインストーラーは、実際にサービスを動かすユーザーで実行してください。そのユーザーのホーム、ツール置き場、 設定、ランチャーは、すべてそのユーザーの持ち物である必要があります。

  1. 管理者として、ソースからのビルドに必要な前提条件と、使うブラウザのバックエンドが必要とする

Linux のライブラリを入れます。

  1. サービス用ユーザーとして、通常のインストーラーを実行します。
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash
  1. 実際のランチャーがあるディレクトリを、サービス用ユーザーのシェル環境に追加します。
export PATH="$HOME/.local/bin:$PATH"
  1. そのアカウントで hermes doctor を実行します。インストールされたラッパーを使い、

venv/bin/hermes のようなパスを直接書いて呼ばないでください。

  1. ログアウトしても止まらない Linux のユーザーサービスにするには、管理者として lingering を有効にします。
sudo loginctl enable-linger SERVICE_USER

現在のソースからのインストーラーは、Playwright の --with-deps ステップを実行しません。 Node.js 用の libatomic（前提条件を参照）を除けば、システムのパッケージも入れません。PM が管理するのはツールのバイナリで、 システムライブラリは管理者が用意します。sudo を使えないサービス用ユーザーには、 管理者に実行を頼むための正確な libatomic のコマンドが表示されます。 ブラウザ自動化 と メッセージングゲートウェイ をご覧ください。

困ったときは

症状 対処
hermes: command not found シェルを読み込み直す（source ~/.bashrc）か、PATH を確認する
API key not set hermes model を実行してプロバイダーを設定するか、hermes config set OPENROUTER_API_KEY your_key を実行する
更新後に設定が失われた hermes config check を実行してから hermes config migrate を実行する

さらに詳しく調べたいときは hermes doctor を実行してください。何が足りないのか、どう直せばよいのかを具体的に教えてくれます。

シンボリックリンクにしたホームディレクトリと外部ストレージ

Hermes は、HERMES_HOME 自体をシンボリックリンクにする使い方にも、ホーム直下のディレクトリをリンクにする使い方にも対応しています。 hooks・skills・sessions・logs も対象です。ホームの初期化では、 すでにあるディレクトリのリンクはそのまま残り、リンク先のディレクトリ （および logs/curator のようなその配下）の権限は持ち主の設定に任せます。

リンク先が見つからない、アクセスできない、ディレクトリではない、のいずれかだった場合、初期化は止まり、 パスとリンク先を書いたストレージのエラーになります。Hermes はリンクを差し替えたり、足りないリンク先を 作ったりはしません。外付けや NAS のボリュームが外れているときにそれをやると、ローカルのディスクへ データを書いてしまうからです。表示されたリンクを確かめ、マウントし直すかリンク先を直し、アクセス権を 確認してからやり直してください。意図してドットファイルの置き場を新しくするなら、目的のストレージが 使える状態だと確かめたうえで、自分で作ってください。

hermes doctor はこの失敗を、YAML の不備ではなくストレージの問題として報告します。 いまの config.yaml はそのまま残してください。ディレクトリが使えない状態は hermes setup では直りません。これは ディレクトリが使えるかどうかの確認であって、マウントの監視ではありません。 ディレクトリが存在することは、目的のボリュームがマウントされている証拠にはならないからです。

インストール方法の自動判別

更新を誰が担うかは、データの置き場所だけでなく、実際に動いているインストールによって決まります。 ソースのチェックアウトは、Hermes が管理する Git 経由の更新を使います。デスクトップ版パッケージ、Docker、 Nix、Termux のパッケージは、それぞれのパッケージ側の更新の仕組みを使い続けます。 hermes doctor は、どの方法でインストールされたかを表示します。パッケージが管理するファイルを変更する前に、 更新とアンインストール をご覧ください。