有能なエージェントは、プロジェクトの慣例、好みの対応スタイル、環境にインストールされているツール、すでに下に置かれた決定、デフォルトではない間違いを覚えている必要があります。実際の問題は、「エージェントはすべてを記憶できるか?」ということはありません。
メモリは、長時間実行されるエージェント作業の制御層です
優れた記憶システムは、繰り返しの説明を減らします。悪い記憶システムは、古い仮定、隠れたリスク、および混乱を招く動作を生み出します。
AI エージェントを初めてテストするときは、通常、ツールの使用に焦点を当てます。閲覧できるのでお願いします? コードを実行できるのでしょうか? ターミナル横断のことはできるのでお願いします? ファイルを書き込むことはできますか? これらは重要ですが、主要なボトルネックではありません。 3 回目または 4 回目のセッションのそのうち、より難しい問題が現れます。それがあること、チームが特定のコピーパターンを避けていること、SEO ブリーフが固定構造にコマンドが必要であることを伝えます。
永続メモリが必要で、すべてのタスクでコンテキストを手動でリハイドレートする必要があります。 古い表示を貼り付けるか、長いプロンプト テンプレートを維持するか、繰り返しの修正を許可するどれかです。どれもうまく拡張できません。ユーザー、環境、エージェントが学習した動作コンテキストに関するコンパクトな情報が保存されます。 これは、トランスクリプト全体を無償データベースにダンプし、検索がする機能を期待するのとは違います。
エルメスのエージェントが実際に覚えていること
ヘルメスは永続記憶を 2 つの実際的なカテゴリに分類します。 1 つ目はエージェントの記憶です。環境、プロジェクト、慣習、ワークフロー、学んだ教訓に関するメモです。ここには、リポジトリが pnpm を使用していること、特定の Makefile で意図テストが実行されている、またはステージング サーバーが当然以外の SSH ポートを必要としている場合によって保存される場合があります。 2 つ目はユーザーの記憶です。好み、コミュニケーション スタイル、期待、役割、ワークフローの習慣です。
すべてのメモリが同じ役割を果たしているわけではないため、この区別は重要です。ユーザーの好みがコミュニケーションを形成する必要があります。プロジェクトの事実が実行を形作る必要があります。完了したタスクのメモは、やり直しを防ぐ必要があります。ツールによる回避策により、今後のデバッグ時間が短縮されるはずです。
User memory = how to work with me Project memory = how this environment works Task memory = what already happened Searchable log = what we may need to find later External memory = what should scale beyond local notes
これが、「メモリを増やす」ことが自動的に優れているわけではない理由です。会話のあらゆる詳細が永続的な指示になると、エージェントは騒々しくなります。目標は完全に思い出すことではありません。目標は有用な継続性です。
有界メモリが制限ではない機能である理由
一見すると、厳選された小規模なメモリ ストアは制限が厳しいように見えます。実際には、これによりメモリの衛生状態が改善されます。多くのチームが犯す間違いは、エージェントのメモリを倉庫のように扱うことです。これらには、会議メモ、生のログ、長いコード スニペット、顧客のトランスクリプト、および曖昧なリマインダーが保存されます。その後、エージェントは技術的に関連しているが運用上役に立たないフラグメントを取得します。さらに悪いことに、古い情報を最新のものとして扱う可能性があります。
エルメスの境界付きメモリ設計は、エージェントを圧縮に向かわせます。完全なデバッグセッションを保存する代わりに、レッスンを保存する必要があります。
Bad memory: On Tuesday, we debugged the deployment script for two hours... Good memory: Project deploys to staging with `make deploy-staging`; required env vars are in `.env.staging.local`; do not use production credentials during test deploys.
2 番目のエントリは短く、より安全で、より便利です。不必要なナラティブを保持することなく、次回何をすべきかをエージェントに伝えます。エージェントの動作コンテキストにメモリが注入されるため、これは実際の作業にとって重要です。そこに保存されているものはすべて、将来の決定に影響を与える可能性があります。記憶が肥大化したり、古くなったり、矛盾したりすると、エージェントの動作は低下します。コンパクトなメモリ層により、「常に利用可能な」コンテキストがクリーンに保たれます。
コアメモリ、セッション検索、外部プロバイダー
3 つのメモリ層: 常に利用可能な事実のための厳選されたコアメモリ、エピソードを思い出すためのセッション検索、およびスケールのための外部プロバイダー。
レイヤー 1: 厳選されたコアメモリ
コア メモリには、エージェントが常に知っておくべき事実が含まれています。これには、永続的な設定、安定したプロジェクトの慣例、環境の事実、および繰り返される修正が含まれます。
User prefers draft articles in a natural Medium tone, with short paragraphs, practical examples, and no exaggerated marketing claims. Project `content-pipeline` uses Python 3.11, Poetry, Playwright, and a local SQLite queue. Run tests with `poetry run pytest`.
これらのエントリはトランスクリプトではありません。これらは圧縮された運用知識です。
レイヤ2：セッション検索
すべての細部が永続的な記憶に値するわけではありません。場合によっては、エージェントは以前のディスカッションを見つけるだけで済みます。そのためには、セッション検索の方が適しています。 3 週間前に、特定のデータベースの移行が遅れた理由をエージェントに伝えたと想像してください。これは、将来のすべてのプロンプトに永続的に挿入する必要はないかもしれません。しかし、「移行について何を決めたのですか?」と尋ねると、エージェントは過去のセッションを検索し、関連するやり取りを取得できる必要があります。この区別は重要です。コアメモリは、デフォルトで動作を形成する必要がある事実のためのものです。セッション検索はエピソードを思い出すためのものです。
レイヤ 3: 外部メモリプロバイダー
エルメスは外部メモリプロバイダーもサポートしています。ここで、メモリはよりスケーラブルで特殊なものになります。プロバイダーに応じて、エージェントはセマンティック検索、ユーザーモデリング、バックグラウンド同期、メモリ抽出、またはプロバイダー固有のツールを使用できます。これは、エージェントが個人の生産性からチームのワークフローに移行する場合に役立ちます。コンパクトなローカルメモリとセッション検索であれば、1人の開発者でも問題ないかもしれません。コンテンツチーム、リサーチグループ、またはチーム運用は、概要、キャンペーン、ユーザー規定、プロジェクト履歴、定期的なワークフロー全体にわたる広範なリコールが必要な場合があります。アーキテクチャの問題は、何がローカルに保持する必要があるのか、何が検索可能になる必要があるのか、何がメモリプロバイダーによって管理する必要があるのかということです。
実践的なワークフロー: メモリを使ったSEOコンテンツエージェント
エルメスエージェントを使ってSEOコンテンツワークフローをサポートします。エージェントはトピックを調査し、概要を作成し、記事の下書きを作成し、内部リンクの機会をチェックし、CMSブランドの音声を使用し、クリックベイトを避け、製品について自然に配慮し、箇条書きを多用せず、内部リンクのルールを先に、短いセグメント落を使用し、統計をでっち上げないでください。数回のセッションの後、これは煩わしくなります。数十回のセッションの後、ワークフローに隠れた負担がかかります。
記憶があれば、エージェントは安定したルールを永続化する必要があります。 ユーザーは海外のテクノロジー読者向けに SEO 記事を書きます。 スタイル: 分析的、実用的、短い段落、誇示大広告なし、偽の統計なし、キーワードの埋め込みなし。
ヘルメス型記憶は、継続性とエージェント推論に強いです。 EasyClaw すべてのアクションをカスタム API 統合に変換する概要、コンテンツ ワークフローがデスクトップ ツール、CMS インターフェイス、スプシート、リサーチ タブ、公開ステップ間を移動する必要がある場合に、より適切になります。 実際のコンテンツ運用では、これらのツールを「一方が他方を置き換える」とは考えません。 EasyClaw は、見積が存在した後に発生する煩雑なアプリケーション間作業 (コンテンツの CMS への移動、書式設定のチェック、メタデータの準備、ツール間での公開タスクの調整など) の実行に役立ちます。
重要なのは、すべてを保存しないようにすること。 SEO ワークフローの場合、優れた記憶エントリには次のものが含まれる可能性があります。 ブランドの声 — 明確でプロフェッショナルな、海外のテクノロジー ユーザーであり、誇張された主張はありません。 H2、第三者結論で主なキーワードを自然に残します。完全一致キーワードの繰り返しの詰め込みを避けます。これらの記憶はコンパクトで耐久性があり、行動を検討します。
保存してはいけないもの
最も過小評価されている記憶機能は忘れることです。一時忘れない記憶システムは限界になります。 古い設定、一時的なデバッグ事実、期限切れのキャンペーンの詳細、または古いプロジェクトの前提条件が保存される場合があります。エージェントのワークフローでは、ユーザーが依存していることに気付いていない可能性があるため、古いメモリはメモリがないことよりも悪い場合がよくあります。生のログ、完全な記事の下書き、一時ファイルパス、1回限りのブラウザの状態、または簡単に再発見できる事実は保存しないでください。機密の認証情報は保存しないでください。 「ユーザーはSEOが好き」「プロジェクトは重要だ」などの消去な記憶を保存しないでください。
より良いテストは、「この事実は、エージェントが将来のセッションで完全な会話を必要とせずに、より適切な決定を下すのに役立ちますか?」というものです。答えが「いいえ」の場合、それはセッション履歴、プロジェクトドキュメント、またはどこにも属していません。
作業を自動化する前にメモリポリシーを設計する方法
Hermes Agent のメモリ機能を多用する前に、単純なメモリ ポリシーを定義します。これは複雑である必要はありません。偶発的な混乱を防ぐ必要があるだけです。 4 つのカテゴリを使用します。まずは、安定したユーザー設定 (トーン、フォーマット、技術的な深さ、言語設定、繰り返し期待される内容される) を保存します。ユーザーが同じ動作をする 2 再修正した場合、それはおそらくメモリに保存されます。 4 番目に、今後のエラーを防ぐレッスンを保存します。 ローカル環境の異常が原因でコマンドが失敗することを回避する場合は、回避策を保存します。 それ以外はすべて慎重に行う必要があります。
# Check active memory provider hermes memory status # Configure external memory provider hermes memory setup # Disable external provider when testing local-only behavior hermes memory off
正確なプロバイダーの選択は、ワークフローによって異なります。シングルユーザーのローカルセットアップの場合、内蔵メモリとセッション検索で十分な場合があります。チーム規模、マルチプロファイル、またはクロスセッションのパーソナライゼーションの場合は、複雑さを増しても外部プロバイダーを利用する価値があるかもしれません。
エージェントワークフローの簡単な記憶計算書
何かがメモリに属するかどうかを決定するときに私が使用する実際的な決定フローは次のとおりです。
flowchart TD
A[New information appears] --> B{Will it matter in future sessions?}
B -- No --> C[Do not save]
B -- Yes --> D{Is it stable or repeated?}
D -- No --> E[Keep in session history]
D -- Yes --> F{Is it compact and safe?}
F -- No --> G[Summarize, redact, or skip]
F -- Yes --> H{Does it guide behavior?}
H -- No --> E
H -- Yes --> I[Save to memory]これにより、メモリの動作が維持されます。重要なのは、事実をそれ自体のために記憶しないことです。重要なのは、今後の行動を改善することです。
パフォーマンスのトレードオフ: 常時オンのコンテキストとオンデマンドのリコール
ただし、それはコンテキストも消費し、あらゆる応答に影響を与えます。オンデマンドのリコールは、エージェントが必要な場合にのみ検索するため、よりクリーンです。コアメモリには、セッションごとに料金を考える価値のある小さな事実セットが含まれている必要があります。セッション検索は、以前のディスカッションのロングテールを維持する必要があります。
「プロジェクトはアップロード前にカスタム画像圧縮スクリプトを使用します」は、読まれる公開タスクに影響を考慮する場合、コアメモリに保存される可能性があります。分類が適切であればあるほど、主観性は考えられます。
業界関連性: メモリがパーソナルアシスタントを超えて重要な理由
AI エージェントがチャットからオペレーションに移行しているため、メモリが重要になっています。ソフトウェア チームでは、記憶はエージェントがプロジェクトの規則、ローカル環境、繰り返し発生するエラー、および以前の実装上の決定を理解するために役立ちます。コンテンツ チームでは、ブランドの声、編集ルール、キーワード戦略、出版ワークフローが記憶に保存されます。顧客の業務では、プライバシーとガバナンスが慎重に心がけている限り、メモリはエージェントがケース、エスカレーションルール、顧客固有の設定全体での継続性を維持するのに役立ちます。
よくあるパターンは継続性です。実際の仕事は単一のプロンプトではありません。これは、関連数日または数週間続けて決定するのです。のメモリ機能の真の価値です。これらにより、解決策は完璧なプロンプトに依存することが少なくなります。毎回ユーザーに操作コンテキストの再説明を強制する代わりに、解決策は重要な部分を引き継ぎます。
リスク: 記憶は目に見えないプロンプトになる可能性があります
メモリを便利にするのと同じ機能が、危険にもなります。 メモリは、非表示のプロンプトのように機能します。 ユーザーが検査、編集、または一時立てを行うことができない場合、エージェントが特定の動作をする理由を理解できない可能性があります。ガバナンスが重要である理由です。ユーザーは、エージェントが保存した内容を定期的に確認する必要があります。チームはどのカテゴリを許可するか編集する必要があります。機密情報は報酬するか編集する必要があります。古いプロジェクトの事実が変更された場合は、更新する必要があります。運用環境で使用する場合は、カジュアルなチャット履歴ではなく、メモリを構成のように設定します。読み取り可能、編集可能、監査可能であり、意図的に保守できる必要があります。
エルメス魅力記憶の機能の上手な使い方
エルメスの記憶を活用する最善の方法は、小さなことから始めることです。すべてのプロバイダーに接続し、すべてのセッションを保存することから始めないでください。内蔵メモリ層から始めます。エージェントにあなたの安定した設定と 1 つまたは 2 つのプロジェクトの規則を覚えてもらいます。次に、今後のセッションが改善されるかどうかを観察します。エージェントが同じ間違いを繰り返す場合は、修正を追加します。同じ設定の詳細が繰り返し必要な場合は、保存してください。記憶が古くなった場合は、矛盾したメモを追加するのではなく、置き換えてください。基本的なループが機能したら、エピソードを思い出すためのセッション検索を追加します。これは、エージェントが常任の指示に従う必要がある場合ではなく、エージェントが以前の決定を検索する必要がある場合に使用します。その場合にのみ、外部メモリプロバイダーを検討してください。これらは価値がありますが、構成とガバナンスの層がさらに追加されます。記憶システムが強力であればあるほど、何を記憶すべきか、どのように取得すべきか、そして誰がそれを変更できるのかを定義することがより重要になります。
結論: 正しいことを覚えておいてください
Hermes Agentのメモリ機能は、AIワークフロー設計の広範な変化を示唆しています。勝利するエージェントは、すべてを目的に維持するエージェントではありません。これを使用して、永続的な設定、プロジェクトの慣例、繰り返しの修正、将来の間違いを防ぐための教訓を保存します。生の詳細を検索可能な履歴に保存します。ワークフローの拡張が本当に必要な場合にのみ、外部メモリ本格的なエージェントワークフローを構築しているチームの場合、自動化を拡大する前にメモリを設計する必要があります。そうしないと、エージェントは強力ですが継続性がなくなり、動作は可能ですが継続性を維持できる可能性があります。