ツールとツールセット

使えるツール
ツールセットの使い方
ツールの実行結果に付く注記
ターミナルの実行先
設定
シェルの起動ファイルと、対話なしのコマンド
Docker を使う場合
SSH を使う場合
Singularity／Apptainer
Modal（サーバーレスのクラウド）
Vercel Sandbox
コンテナに割り当てる資源
コンテナの安全対策
背後で走るプロセスの管理
sudo への対応

ツールはエージェントの能力を広げる関数です。用途ごとのツールセットにまとめられていて、プラットフォームごとに有効・無効を切り替えられます。

使えるツール

Hermes には幅広い組み込みツールが最初から登録されています。ウェブ検索、ブラウザの自動操作、ターミナルの実行、ファイル編集、記憶、委任、定時タスク、Home Assistant などです。

大まかな分類は次のとおりです。

分類	例	説明
ウェブ	`web_search`、`web_extract`	ウェブを検索し、ページの中身を取り出します。
X 検索	`x_search`	xAI の組み込み Responses ツール `x_search` を使って X（Twitter）の投稿やスレッドを検索します。xAI の認証情報（SuperGrok の OAuth または `XAI_API_KEY`）が必要で、既定では無効です。`hermes tools` → 🐦 X (Twitter) Search から有効にしてください。
ターミナルとファイル	`terminal`、`process`、`read_file`、`patch`	コマンドを実行し、ファイルを操作します。
ブラウザ	`browser_navigate`、`browser_snapshot`、`browser_vision`	文字と画像の両方に対応した、対話的なブラウザ自動操作です。
メディア	`vision_analyze`、`image_generate`、`text_to_speech`	複数の形式にまたがる解析と生成です。
エージェントの段取り	`todo`、`clarify`、`execute_code`、`delegate_task`	計画づくり、確認、コードの実行、サブエージェントへの委任です。
記憶と呼び出し	`memory`、`session_search`	セッションをまたぐ記憶と、過去のセッションの検索です。
自動化	`cronjob`	定時タスクの作成・一覧・更新・一時停止・再開・実行・削除ができます。外部への配信は cron 自身の配信機能、`hermes send` コマンド、ゲートウェイの通知が担っていて、エージェントが呼べるツールはありません。
外部連携	`ha_*`、MCP サーバーのツール	Home Assistant、MCP、その他の連携です。

コードから自動生成した確かな一覧は、組み込みツール一覧とツールセット一覧にあります。

ツールセットの使い方

# Use specific toolsets
hermes chat --toolsets "web,terminal"

# See all available tools
hermes tools

# Configure tools per platform (interactive)
hermes tools

よく使うツールセットには web、search、terminal、file、browser、vision、image_gen、skills、tts、todo、memory、session_search、cronjob、code_execution、delegation、clarify、homeassistant、messaging、spotify、discord、discord_admin、debugging、safe があります。

すべてのツールセットはツールセット一覧にまとまっています。hermes-cli、hermes-telegram といったプラットフォーム別の組み合わせや、mcp-<server> のように動的に作られる MCP のツールセットも載っています。

ツールの実行結果に付く注記

エージェントのやり取りを読むときに知っておくと役立つ振る舞いがいくつかあります。

シグナルによる終了は言葉で説明されます。 ターミナルのコマンドがシグナルで止められたとき、結果には数字だけでなく人が読める注記が付きます。たとえば終了コード -9／137 は「terminated by signal 9: SIGKILL — often the kernel OOM killer on memory exhaustion, or an explicit kill -9」と説明され、セグメンテーション違反、異常終了、SIGTERM、パイプの切断、CPU やファイルサイズの上限超過も同じように名前が付きます。負の数（サブプロセスの流儀）は断定的に書かれますが、シェルの 128+signum の慣習はアプリが正当にその値で終了することもあるため「usually」と留保付きです。
UTF-16 のテキストファイルは拒否されず、変換されます。 read_file は UTF-16 を検出し（BOM またはバイト並びからの推測で、どちらのエンディアンでも。Windows のメモ帳や PowerShell の > によるリダイレクトでよく生じます）、バイナリ扱いにせず UTF-8 に直して表示します。結果には変換したことを知らせる但し書きが入り、patch／write_file による編集は UTF-8 で書き戻されます。10 MB を超えるファイルと、本当にバイナリのファイルは、これまでどおりバイナリとして読み込みを断ります。

ターミナルの実行先

ターミナルのツールは、いくつかの環境でコマンドを実行できます。

実行先	説明	向いている場面
`local`	手元の端末で実行します（既定）	開発、信頼できる作業
`docker`	隔離されたコンテナ	安全性、再現性
`ssh`	離れたサーバー	隔離、エージェントを自分のコードから遠ざける
`singularity`	HPC 向けコンテナ	クラスタ計算、root 権限なし
`modal`	クラウドでの実行	サーバーレス、規模の拡大
`daytona`	クラウドのサンドボックス環境	消えずに残る遠隔の開発環境
`vercel_sandbox`	Vercel Sandbox のクラウド microVM	スナップショットでファイルが残るクラウド実行

設定

# In ~/.hermes/config.yaml
terminal:
  backend: local    # or: docker, ssh, singularity, modal, daytona, vercel_sandbox
  cwd: "."          # Working directory
  timeout: 180      # Command timeout in seconds

シェルの起動ファイルと、対話なしのコマンド

エージェントがターミナルを呼ぶとき、シェルは対話なしで動きます。TTY はなく、プロンプトの前に人もいません。普段の端末では気づかないような重い初期化や対話を前提とした初期化があると、エージェントが実行するすべてのコマンドが壊れたり、ひどく遅くなったりします。

重い初期化（nvm、各種バージョン管理、ネットワークに触れるプロンプト）: よくある nvm.sh の読み込みは*すべての*シェル起動に目に見える遅れを足しますし、エージェントは何度もシェルを起動します。数秒かかる rc ファイルは、ちょっとした git status すらタイムアウトの危険にさらします。
TTY を前提とした処理: .bashrc や .zshrc の中で入力を求めたり、tmux／screen に接続したり、read を呼んだり、メニューを表示したりするものは、対話なしのシェルを止めてしまいます。コマンドが延々と終わらないように見えて、最後にタイムアウトします。
無条件の出力: rc ファイルが echo でバナーを出すと、エージェントが解析しなければならないコマンドの出力すべてが汚れます。

対処は、多くのディストリビューションが .bashrc の先頭にすでに入れている標準的な番人です。対話なしのシェルなら早めに抜け、重いものや対話が要るものはその下に置きます。

# ~/.bashrc — keep this guard near the top
case $- in
  *i*) ;;      # interactive: continue
  *) return;;  # non-interactive: stop here
esac

# heavy/interactive init goes BELOW the guard
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"

zsh を使っている場合は、ログイン時だけの設定を .zprofile に、対話時だけの設定を .zshrc に置いてください。.zshenv は対話なしを含むすべてのシェルで読まれるので、中身は最小限に保ちます。rc ファイルでしか PATH に入らないツールがどうしても必要なら、PATH の設定だけを番人より*上*に書くか（パスの設定は軽いものです）、実行ファイルを ~/.local/bin にシンボリックリンクしてください。

自分の端末では動くのに、エージェントのターミナルのコマンドだけが止まったりすぐタイムアウトしたりするなら、まず疑うべきはシェルの初期化です。

Docker を使う場合

terminal:
  backend: docker
  docker_image: python:3.11-slim

長く生きるコンテナがひとつ、プロセス全体で共有されます。 Hermes は最初に使うときに長寿命のコンテナをひとつ起動し（docker run -d ... sleep infinity）、ターミナル、ファイル、execute_code のすべての呼び出しを docker exec でその同じコンテナに通します。作業ディレクトリの移動、入れたパッケージ、環境変数の変更、/workspace に書いたファイルは、ツールを呼ぶたびに引き継がれます。/new、/reset、delegate_task のサブエージェントをまたいでも、Hermes のプロセスが生きているあいだは保たれます。コンテナは終了時に停止・削除されます。

つまり Docker を使う場合、コマンドごとに新しいコンテナが立つのではなく、消えずに残るサンドボックスの仮想マシンのように振る舞います。一度 pip install foo すれば、そのセッションのあいだはずっと使えます。cd /workspace/project すれば、以後の ls はそのディレクトリを見ます。動作の詳しい流れと、Hermes を再起動しても /workspace と /root を残すかどうかを決める container_persistent の設定については、設定 → Docker Backend をご覧ください。

SSH を使う場合

安全性の面でおすすめです。エージェントが自分のコードを書き換えられなくなります。

terminal:
  backend: ssh

# Set credentials in ~/.hermes/.env
TERMINAL_SSH_HOST=my-server.example.com
TERMINAL_SSH_USER=myuser
TERMINAL_SSH_KEY=~/.ssh/id_rsa

Singularity／Apptainer

# Pre-build SIF for parallel workers
apptainer build ~/python.sif docker://python:3.11-slim

# Configure
hermes config set terminal.backend singularity
hermes config set terminal.singularity_image ~/python.sif

uv pip install modal
modal setup
hermes config set terminal.backend modal

Vercel Sandbox

pip install 'hermes-agent[vercel]'
hermes config set terminal.backend vercel_sandbox
hermes config set terminal.vercel_runtime node24

認証には VERCEL_TOKEN、VERCEL_PROJECT_ID、VERCEL_TEAM_ID の3つすべてが必要です。このアクセストークンによる設定が、Render、Railway、Docker などのホストで Hermes を配備し長く動かし続けるための正式な道です。使えるランタイムは node24、node22、python3.13 で、遠隔側の作業場所の起点は既定で /vercel/sandbox です。

手元での一度きりの開発なら、Hermes は短命な Vercel の OIDC トークンも受け付けます。

VERCEL_OIDC_TOKEN="$(vc project token <project-name>)" hermes chat

Vercel のプロジェクトと紐づいたディレクトリからなら、次のように書けます。

VERCEL_OIDC_TOKEN="$(vc project token)" hermes chat

container_persistent: true にすると、同じタスクのあいだはサンドボックスが作り直されてもファイルの状態が Vercel のスナップショットで引き継がれます。ここには Hermes が同期した認証情報、スキル、キャッシュのファイルも含まれることがあります。ただしスナップショットは、動いているプロセス、PID の空間、同じサンドボックスとしての同一性までは保ちません。

背後で走らせるターミナルのコマンドは、Hermes が手元以外の環境で使う共通の流れに従います。サンドボックスが生きているあいだは、起動・状態確認・待機・ログ・停止が通常のプロセスのツールで動きますが、片づけや再起動のあとに切り離されたプロセスを Vercel から復帰させる仕組みは用意していません。

container_disk は未設定のままにするか、共通の既定値 51200 にしてください。Vercel Sandbox でディスク容量を独自に指定することは対応しておらず、診断や環境の作成に失敗します。

コンテナに割り当てる資源

コンテナを使うすべての実行先について、CPU、メモリ、ディスク、状態を残すかどうかを設定できます。

terminal:
  backend: docker  # or singularity, modal, daytona, vercel_sandbox
  container_cpu: 1              # CPU cores (default: 1)
  container_memory: 5120        # Memory in MB (default: 5GB)
  container_disk: 51200         # Disk in MB (default: 50GB)
  container_persistent: true    # Persist filesystem across sessions (default: true)

container_persistent: true のときは、入れたパッケージ、ファイル、設定がセッションをまたいで残ります。

コンテナの安全対策

コンテナを使う実行先はすべて、次の締め付けを効かせた状態で動きます。

ルートのファイルシステムは読み取り専用（Docker）
Linux のケーパビリティはすべて剥奪
権限の昇格を禁止
PID の上限（256 プロセス）
名前空間の完全な分離
作業場所は書き込み可能なルート層ではなくボリュームで保持

Docker については terminal.docker_forward_env で環境変数の受け渡しを明示的に許可できますが、渡した変数はコンテナ内のコマンドから見えるので、そのセッションに対しては公開されたものとして扱ってください。

背後で走るプロセスの管理

プロセスを背後で起動し、あとから操作できます。

terminal(command="pytest -v tests/", background=true)
# Returns: {"session_id": "proc_abc123", "pid": 12345}

# Then manage with the process tool:
process(action="list")       # Show all running processes
process(action="poll", session_id="proc_abc123")   # Check status
process(action="wait", session_id="proc_abc123")   # Block until done
process(action="log", session_id="proc_abc123")    # Full output
process(action="kill", session_id="proc_abc123")   # Terminate
process(action="write", session_id="proc_abc123", data="y")  # Send input

PTY モード（pty=true）にすると、Codex や Claude Code のような対話的な CLI ツールも動かせます。

sudo への対応

sudo が必要なコマンドでは、パスワードの入力を求められます（そのセッションのあいだは保持されます）。~/.hermes/.env に SUDO_PASSWORD を設定しておくこともできます。