Hermes Agentの会話が長くなった時に守るもの｜context compressionを運用へ入れる

長い会話が壊れる時、最初に失うのは会話そのものではありません。作業の目的、変更してはいけない範囲、未完了の確認事項です。エラー全文や大きな検索結果が何度も残り、肝心の判断が後ろへ押し出されます。

Hermes Agent には長いセッションを圧縮する仕組みがあります。ただし、圧縮は会話を短くするだけの機能ではありません。何を要約に残し、何をファイルや skill へ逃がし、どの時点で手動確認するかを決めて初めて、数時間の調査や複数日にまたがる実装で使えます。

前回完了時から今回完了後まで

前回の「Hermes Agentのcronをつなぐ｜context_fromで前の結果を安全に引き継ぐ」では、別の定期 job へ渡す出力の境界を扱いました。今回は 1 つのセッションの中で、会話が長くなった後にも判断を残す境界を扱います。

時点	状態
前回完了時	job間では必要な短い結果だけをcontext_fromで渡せます
今回開始時	1つの会話では調査結果、tool出力、指示が同じ履歴に積み上がります
今回完了後	圧縮の発火条件と手動確認点を決め、重要事項を別の永続先へ残せます

短い質問だけを処理するなら、この章は飛ばして構いません。長いログを読む、複数のファイルを直す場面で必要です。翌日に同じ作業を再開する場合にも役立ちます。

圧縮は記憶の代わりではありません

圧縮後の会話には、すべての原文が同じ粒度で残るわけではありません。公式ドキュメントでは、標準のContextCompressorは要約を使う圧縮エンジンです。つまり、手順や決定を会話だけへ置くと、後の要約で細部は薄くなる可能性があります。

私は次の 3 種類を分けます。

残すもの	置き場所	例
その場で消えてよい観測	会話	一時的な検索結果、読み終えたログ
次の手順で使う事実	project内の短い文書	対象branch、失敗したテスト、未適用の修正
毎回守る手順	skillまたはAGENTS.md	テスト順、秘密を表示しない規約、公開前の確認

「この URL を後で読む」「このファイルは触らない」「PR を作る前に build を通す」といった情報は、圧縮に任せません。作業が終わる前に、短い引き継ぎ文書か既存の skill へ移します。

2段の安全網を知る

Hermes Agent には、通常の会話処理と gateway 側の保護に、それぞれ圧縮の層があります。標準設定では、agent 内のContextCompressorがコンテキスト長の 50％で動く主系です。gateway のセッション hygiene は 85％で動く安全網です。

[新しいメッセージ]
        |
        v
[gateway session hygiene]
  大きくなり過ぎた会話を事前に検査する
        |
        v
[agent ContextCompressor]
  providerのtoken使用量を見て通常の圧縮を行う
        |
        v
[tool呼び出しと応答]
        |
        v
[要約 + 直近の会話]

50％と 85％は、どちらか一方を二重に実行するための値ではありません。前者は正確な token 使用量を扱う通常経路です。後者は、長時間放置した chat や gateway 再起動のあとに、過大な入力を送らないための保護です。

この違いを知らずに 50％を 85％へ寄せると、通常の圧縮が遅れます。逆に gateway を早くし過ぎると、同じ会話を必要以上に圧縮しやすくなります。まず標準値を変えず、圧縮後に何が不足したかを観察する方が安全です。

変更前に現在値を読む

設定を変える時は、ファイルを直接書き換える前に、現在の解決値を確認します。compression.thresholdは会話全体のうち、圧縮を考え始める割合です。

hermes config get compression.enabled
hermes config get compression.threshold
hermes config get compression.target_ratio
hermes config get context.engine

設定済みなら、各行に値が表示されます。未設定の項目は導入版により表示が異なるため、空の値を見て独自のキーを足さないことが大切です。公式の設定リファレンスで項目名を照合してから変更します。

標準のエンジンを明示するだけなら、次の設定です。

hermes config set context.engine compressor
hermes config set compression.enabled true

compressorは組み込みの圧縮エンジンです。別の context engine plugin を入れただけでは有効になりません。context.engineへその名前を設定した時だけ、plugin 側の実装が選ばれます。

手動圧縮の前に書くべき4行

会話が長くなった時、いきなり/compressを実行しません。先に、次の 4 行を会話へ送るか、project の作業メモへ書きます。

目的: PR #番号の失敗原因を直す
確定事項: migrationは変更しない
未完了: integration testの失敗を再現する
次の確認: 修正後にpnpm testとbuildを実行する

番号やコマンドは、実在するものだけへ置き換えます。仮の ID を残すと、後で検索しても対象を見つけられません。秘密、Cookie、環境変数の値はここへ書きません。

その後に/compressを使います。これは会話履歴を要約し、コンテキスト使用量を下げる操作です。圧縮直後は「何を残したか」を 1 回だけ確認し、次の作業を始めます。長い会話で圧縮を何度も繰り返すなら、決定事項を会話から skill やファイルへ移す時期です。

大きなtool出力を会話へ積まない

圧縮の前にできる対策があります。数万文字のログや HTML をそのまま会話へ返さず、必要なエラー行、対象ファイル、終了コードだけに絞ります。

pnpm test > /tmp/test.log 2>&1
printf 'exit=%s\n' "$?"

このコマンドはテストの全文を一時ファイルへ保存し、画面には終了コードだけを出します。失敗時は/tmp/test.logから該当箇所を読みます。読んだ内容を会話へ貼る時も、最初のエラーと関連する数十行に留めます。

ただし、失敗ログを隠して原因を推測してはいけません。要点だけを渡すのは、原文を捨てることではありません。再確認できる保存先を残し、必要なら原文へ戻れるようにします。

よくあるつまずき

症状	先に確認すること	対応
圧縮後に作業目的が曖昧になる	目的と未完了事項を会話だけに置いていないか	圧縮前に短い引き継ぎを作り、永続先へ残します
同じログが何度も送られる	tool出力の量と再読回数	終了コードと必要行だけを会話へ出し、原文はファイルで保持します
圧縮が失敗して会話が進まない	provider障害、認証、timeout	設定を変える前に失敗通知とログを確認し、会話を無理に続けません
pluginを入れたのに挙動が変わらない	context.engineの値	plugin名を明示したか、組み込みcompressorのままかを確認します
重要な規約が毎回消える	規約の置き場所	project固有はAGENTS.md、繰り返す手順はskillへ移します

圧縮が失敗したからといって、設定値をすぐ小さくする必要はありません。公式仕様では、要約の失敗や timeout には cooldown と回復経路があります。まず provider の失敗か、会話の入力が過大か、設定の誤りかを分けます。

変更を小さく検証する

運用中の会話で閾値を大きく動かす前に、1 つの設定だけを変えます。変更後は現在値を再読して、意図したキーだけが反映されたかを確認します。

hermes config set compression.threshold 0.50
hermes config get compression.threshold

期待する確認結果は0.50です。ここで確認できるのは設定値であり、圧縮の成功ではありません。長い実作業を 1 回行った後、圧縮後にも目的、未完了、禁止事項が保たれたかを見ます。

圧縮は品質ゲートを置き換えません。コード修正ならテスト、記事なら frontmatter と build、公開なら review のように、成果物ごとの検証は別に実行します。会話が短くなっても、成果物が正しいとは限らないからです。

会話を短くして、判断を長く残す

長いセッションを安全に使う鍵は、圧縮を避けることではありません。消えてよい観測と、次の判断へ必要な事実を分けることです。

agent 内の圧縮は日常的な負荷を引き受け、gateway の安全網は大きな失敗を避けます。その上で、人が守るべき目的、禁止事項、未完了だけを短く明文化します。これなら会話が数回圧縮されても、作業は迷子になりません。

一次情報

資料	確認した内容
Context Compression and Caching	標準engine、agent側50％とgateway側85％の2層、pluginの選択方法
Hermes Agent Configuration	compressionとcontext.engineの設定、圧縮失敗時の回復に関する仕様
Tips & Best Practices	/compress、長い会話でcontext fileとskillを使い分ける考え方
Context Files	project固有のAGENTS.mdとglobalなSOUL.mdの役割