概要
Hermes Agent は、Nous Research によって構築された自己改善型 AI エージェントです。組み込みの学習ループを備えており、経験からスキルを作成し、知識を能動的に永続化します。複数のメッセージングプラットフォーム、あらゆる LLM プロバイダーをサポートし、さまざまなバックエンドで実行できます。
README プレビュー
\n \n\n\n# Hermes Agent ☤\n\n\n \n \n \n \n \n\n\n**The self-improving AI agent built by [Nous Research](https://nousresearch.com).** It's the only agent with a built-in learning loop — it creates skills from experience, improves them during use, nudges itself to persist knowledge, searches its own past conversations, and builds a deepening model of who you are across sessions. Run it on a $5 VPS, a GPU cluster, or serverless infrastructure that costs nearly nothing when idle. It's not tied to your laptop — talk to it from Telegram while it works on a cloud VM.\n\nUse any model you want — [Nous Portal](https://portal.nousresearch.com), [OpenRouter](https://openrouter.ai) (200+ models), [NVIDIA NIM](https://build.nvidia.com) (Nemotron), [Xiaomi MiMo](https://platform.xiaomimimo.com), [z.ai/GLM](https://z.ai), [Kimi/Moonshot](https://platform.moonshot.ai), [MiniMax](https://www.minimax.io), [Hugging Face](https://huggingface.co), OpenAI, or your own endpoint. Switch with `hermes model` — no code changes, no lock-in.\n\n\nA real terminal interfaceFull TUI with multiline editing, slash-command autocomplete, conversation history, interrupt-and-redirect, and streaming tool output.\nLives where you doTelegram, Discord, Slack, WhatsApp, Signal, and CLI — all from a single gateway process. Voice memo transcription, cross-platform conversation continuity.\nA closed learning loopAgent-curated memory with periodic nudges. Autonomous skill creation after complex tasks. Skills self-improve during use. FTS5 session search with LLM summarization for cross-session recall. Honcho dialectic user modeling. Compatible with the agentskills.io open standard.\nScheduled automationsBuilt-in cron scheduler with delivery to any platform. Daily reports, nightly backups, weekly audits — all in natural language, running unattended.\nDelegates and parallelizesSpawn isolated subagents for parallel workstreams. Write Python scripts that call tools via RPC, collapsing multi-step pipelines into
FAQ (5)
トラブル対応Linux上で'hermes desktop'が'ENOENT: no such file or directory, rename electron -> Hermes'で失敗するのはなぜですか？
エラーは、ユーザーごとのElectronダウンロードキャッシュ内の破損したElectron配布zipファイルが原因で発生します。キャッシュファイルを削除して、ビルドを再実行してください。
- Linuxの場合: rm ~/.cache/electron/electron-v*.zip（または特定のバージョン、例: rm ~/.cache/electron/electron-v40.9.3-linux-x64.zip）
- macOSの場合: rm ~/Library/Caches/electron/*.zip
- カスタムキャッシュを使用するmacOSの場合: XDG_CACHE_HOMEまたはELECTRON_CACHEが設定されている場合はそれに従ってください。
破損したzipを削除した後、'hermes desktop'を再度実行してください。ビルドは正常なElectron配布を再ダウンロードし、正常に完了します。これは#39127で追跡されている既知の問題です（自己修復キャッシュパージ）。
トラブル対応Hermes tui_gateway での 'result of groups.log violates its wire contract' エラー（display_name/profile での RoomActor extra_forbidden）の修正方法
原因: tui_gateway/contracts/groups_bot_relay.py の RoomActor コントラクトモデルは extra="forbid" で kind と id のみを宣言しているが、プロデューサーである gateway/hosted_room_discussion.py の _member_actor() は profile、display_name、connection_id も出力する。actor 辞書は state.db に actor_json としてそのまま永続化され、すべての groups.log ページで再生されるため、メンバーが作成したすべてのイベントでバリデーションエラーが再発生する（HERMES_TEST_ISOLATION=1 環境下では ContractViolation が送出される）。
修正: gateway/hosted_rooms.py の _OPTIONAL_ACTOR_FIELDS に合わせて、RoomActor にオプションフィールドを宣言する:
class RoomActor(Result):
kind: str
id: str
profile: str | None = None
display_name: str | None = None
connection_id: str | None = Noneその後、scripts/gen_gateway_contracts.py を実行して（tui_gateway/AGENTS.md の記載に従い）コントラクト成果物を再生成し、apps/shared/src/gateway-contract.generated.ts と gateway-contract.openrpc.json を更新する。issue #118067/profiles.list（ProfileRow に previous_names が不足していた問題）と同じ修正パターンであり、そちらはコミット 9a4a598bfcd で修正済み。オプションとして、_member_actor() 形式の辞書が RoomActor のバリデーションを通過することを検証する不変条件テストを追加する。
トラブル対応Hermes Desktop が Windows で「We couldn't reach the update server」と表示されるのはなぜですか？また、それを修正するにはどうすればよいですか？
このメッセージは誤解を招くものです — 通常、ネットワーク障害ではありません。
公式ブートストラップインストーラーで作成された Windows インストールでは、git はパッケージマネージャーのツールストア（%LOCALAPPDATA%\hermes\tools\git-<ver>-win32-x64）にのみインストールされますが、Desktop の resolveGitBinary() はその場所を一切検索しません。Git for Windows がインストールされておらず、PATH 上にも git がない場合、アップデートチェックは head-unavailable（"Could not read the installed revision."）で失敗し、UI はそれをサーバー到達性の問題として誤って表示します。
真の原因を確認する方法：%HERMES_HOME%\source-checks\<install_id>.json を開いてください — "error": "head-unavailable" と "currentSha": null が記載されていれば、git が見つからなかったということです（ネットワークの問題ではありません）。
回避策（いずれか1つ）：
1. アプリが検索するパスと管理対象の git が一致するようにジャンクションを作成します。コマンドプロンプト（PowerShell ではなく）で：
mklink /J "%LOCALAPPDATA%\hermes\git" "%LOCALAPPDATA%\hermes\tools\git-2.53.0+3-win32-x64"
（バージョンフォルダー名はお使いのインストールに合わせて調整してください）、その後アプリを再起動します。
2. Git for Windows をインストールする（C:\Program Files\Git または %LOCALAPPDATA%\Programs\Git へ）か、git を PATH に追加してください — どちらの場所もリゾルバーによって検索されます。
同じインストール形態では、これは他の Desktop git 機能（ワークツリー、レビュー、ブランチ操作）にも影響することに注意してください。恒久的な修正には、apps/desktop/electron/main.ts の resolveGitBinary() を更新し、%LOCALAPPDATA%\hermes\tools\git-* ストアを検索するようにする必要があります。
トラブル対応Hermes Desktopアプリでチャットのスクロールバーが後ろに戻るのはなぜですか？
これはuseThreadScrollAnchorロジック（thread-virtualizer.tsx）における既知のバグです。ResizeObserverの解除条件が中間スクロールイベントで誤作動し、sticky-bottom動作が一時的に解除されます。修正は既にPR #38221にマージされており、Hermes Desktop v0.15.2に含まれる予定です。それまでは回避策として、composerのリサイズを最小限に抑える（例えば、suggestion chipsを閉じる、大きなcode block re-rendersを避ける）か、手動でスクロールを最下部に保ってください。
トラブル対応なぜHermes disk-cleanupはcron/jobs.jsonを削除するのですか、そしてそれをどうやって止められますか？
これは、古いtracked.jsonエントリ（cron分類修正前のHermesバージョンによるもの）がcron/jobs.jsonを"cron-output"とラベル付けしている場合に発生し、その結果、disk-cleanupが14日後にそれを削除します。削除を防ぐには、手動でtracked.jsonファイル（~/.hermes/disk-cleanup/tracked.json）を編集し、cron/jobs.jsonまたはcron/ディレクトリのエントリを削除してください。その後、Hermesを再起動してください。新しいバージョン（コミットd473e7c93以降）ではそのようなエントリの追加は回避されますが、古いエントリは手動でクリアする必要があります。