agent-memory

エージェントメモリ

インテリジェントな意思決定機能を備えた、AI エージェント向けの永続的なセマンティックメモリです。

🚀 作成者： TheProdSDE

---

問題点

ほとんどのAIメモリシステムは、過去のコンテキストを取得して、すべてのプロンプトに挿入します。 その結果、トークンが無駄になり、応答に一貫性がなくなり、古くなった回答や誤った回答をエージェントが盲目的に 再利用してしまいます。

Agent Memoryは意思決定レイヤーを追加します。

flowchart TD
    A[User Query] --> B[Resolve Memory]
    B --> C[Decision Engine]
    C -->|High confidence match| D[🔄 Replay — return stored answer]
    C -->|Moderate match| E[📋 Restore — inject as context]
    C -->|Needs validation| F[✅ Verify — validate before reuse]
    C -->|No match| G[❌ None — answer from scratch]

    style D fill:#0d47a1,color:#fff
    style E fill:#e65100,color:#fff
    style F fill:#1b5e20,color:#fff
    style G fill:#b71c1c,color:#fff

すべてのresolve()は、取得したチャンクだけではなく、スコア付きで説明可能な根拠とともに明示的なアクションを返します。 敵対的評価では、罠となるクエリに対して**34/36（94%）**を達成しています。失敗した2件もVERIFYを返す（慎重な判断）ため、誤ったREPLAYは行いません。ベンチマークをご覧ください。

---

コンテキストの劣化 — 解決できることと、できないこと

コンテキストの劣化とは、コンテキストウィンドウが埋まるにつれてLLMの精度が低下することです。トークン上限に達する ずっと前から起こります。古くなったチャンク、無関係な検索結果、際限なく続く会話履歴は、トークンを無駄にするだけではありません。 回答も積極的に劣化させます（「中間部での見失い」、指示の逸脱、妨害情報への過敏さ）。

コンテキストの劣化には2つの原因があります。Agent Memoryが対処するのは1つ目で、2つ目にはモデル 自体以外のものでは対処できません。

1. コンテキストに入る内容 — 制御可能で、このSDKが担う役割です：

劣化の原因	Agent Memoryでの仕組み
無関係なメモリがすべてのプロンプトに挿入される	意思決定レイヤー — 本当に一致するものがない場合、NONEは挿入を拒否します（敵対的な罠クエリで34/36を達成。失敗した2件は安全側に倒してVERIFYを返します）
セッション中の履歴が際限なく増える	PagedMemory — コンテキスト内バッファを固定し、古いターンを呼び出し用ストレージに移して、クエリごとに戻します（MemGPT形式の階層）
長時間のコーディングセッションにおける指示の逸脱	RESTOREは、クエリで必要になったときに、関連する規約をコンテキストの終わり近くに新たに挿入します
古い事実が気付かれないまま再利用される	VERIFY + カスタム検証コールバック + TTLによる期限切れ + 半減期による時間減衰
適応しないリマインダー	mark_correct() / mark_wrong() — 信頼度学習により、役立ち続けるメモリの評価を上げ、訂正されたメモリの評価を下げます
セッション終了時に知識が失われる	from_conversation()は、会話のターンから長期的に保持すべき事実を抽出し、ストアに保存します

2. すでにコンテキスト内にあるトークンに対するモデルの注意 — 外部からは制御できません。 長いコンテキストにおける注意の劣化は、モデルの特性です。メモリレイヤーでそれを変えることはできません。 Agent Memoryが行うのは、モデルがそもそも劣化する領域に入ることがほとんどないよう、コンテキストを小さく関連性の高い状態に保つことです。

率直な説明： Agent Memoryは、エージェントシステムにおけるコンテキストの劣化のうち、制御可能な主な原因である コンテキスト汚染を防ぎます。モデルの注意の動作を変えるものではなく、エージェントが履歴を手動で連結するのではなく、 resolve() / PagedMemoryを通じてコンテキストを渡す場合にのみ効果があります。

---

比較

現在、resolve() が 1 回の呼び出しで行う処理を実現するには、3 つのツールを連携させる必要があります。 再生用のセマンティックキャッシュ（GPTCache）、コンテキスト用のメモリレイヤー（Mem0 / Zep）、そして検証用の独自の鮮度判定ロジックです。読み取り時に、メモリを使うかどうか、またどのように使うかを判断する既存のツールはありません。

他のプロジェクトに関するセルは、それぞれのソースまたはドキュメントに基づく機能チェックです（mem0 は 2026-09-27 に確認）。測定した挙動ではありません。❔ は、機能がないという意味ではなく、まだテストしていないことを示します。修正は歓迎します。出典についてはdocs/comparison.md、レビュー手順についてはベンチマーク RFCをご覧ください。

機能	Mem0	Zep / Graphiti	Letta (MemGPT)	GPTCache	Agent Memory
読み取り時の判断（再生 / 注入 / 検証 / スキップ）	❌ 常に注入	❌ 常に注入	⚠️ LLM が自己管理	⚠️ 再生のみ	✅ REPLAY / RESTORE / VERIFY / NONE
判断ごとの説明可能なスコア	❌	❌	❌	❌	✅ decision.explain()
セマンティックな回答キャッシュ（LLM の呼び出しをスキップ）	❌	❌	❌	✅	✅
読み取り時の鮮度保護	⚠️ 書き込み側での更新 + expiration_date	✅ 時系列グラフ	❌	⚠️ 削除のみ	✅ VERIFY + TTL + 信頼度の減衰
公開済みの敵対的なトラップクエリ評価	❔ 見つからず	❔ 見つからず	❔ 見つからず	❔ 見つからず	✅ 34/36（94%）
メモリ操作あたりの LLM / API 呼び出し数	1 回以上	1 回以上	1 回以上	0	0
モデルアセットをインストール／キャッシュした後のローカル実行（API キー不要）	⚠️ セルフホスト可能。抽出には LLM が必要	⚠️ サーバー + LLM が必要	⚠️ 操作ごとに LLM が必要	✅	✅ SQLite + ローカル ONNX
ページ分けされたコンテキスト階層（MemGPT 形式）	❌	❌	✅	❌	✅ memory.paged()

ホスト型またはモデルを利用する構成では、メモリ操作ごとに LLM または埋め込み API への往復が追加されることがあるため、レイテンシにはプロバイダー、モデル、ネットワークのコストが含まれます。正確なレイテンシは各プロジェクトの構成によって異なります。このリポジトリでは、あらゆる環境に当てはまる 100ms–2s の下限値は公開していません。Agent Memory は SQLite のみのモードでプロセス内で解決します。測定されるレイテンシはコーパスの形状とキャッシュの状態によって異なります（パフォーマンスとストレステストの詳細を参照）。

検索については、クリーンリリース版の検索プロキシ測定値を以下に公開しています。 エンドツーエンドの精度（LLM の回答生成 + 評価。Mem0 と Zep が公開しているもの）については、まだ測定していない数値を掲載していません。この段階はロードマップの次の項目です。 → 機能マトリックスとトレードオフ（他のツールが優れている点を含む）の全容：docs/comparison.md

LongMemEval（ICLR 2025）でのベンチマーク結果

LongMemEval は、会話履歴検索のベンチマークです。これらの結果は、Agent Memory の RESTORE／検索層を測定するものであり、REPLAY、VERIFY、TTL、またはエンドツーエンドの回答正確性を測定するものではありません。各質問は、その質問の検索対象データを含む個別の SQLite ストアに対して実行されます。集計された取り込み件数は、検索対象の単一ストアのサイズではありません。すべての取り込みで、LLM 呼び出しはゼロ、API 料金は $0 です。

• LongMemEval_S（独立した約48セッションの検索対象データ500件。全実行で合計124Kのターンペアエントリー）：ローカル ONNX 埋め込みでセッション Recall@5 が98.1%、語彙検索のみでは96.0%、語彙検索の p50 は10.04ms、セマンティック検索の p50 は19.56msです。レポートには p90／p95／p99 および実行リソースの測定値も含まれています。

• LongMemEval_M（独立した約500セッションの検索対象データ500件。検索対象の各ストアに約2,500件のターンペアエントリー）：語彙検索でセッション Recall@5 が87.0%、p50 は12.05msです。公式のクリーニング済み再リリースとターンペアインデックスを使用しています。論文のオリジナルリリースにおけるセッションインデックスのベースラインとは直接比較できません。

完全な方法論、タイプ別の表、対象範囲に関する注記（このベンチマークで検証することと、しないこと）、および否定的な結果については、ベンチマークレポート をご覧ください。セマンティックな _S の結果は、uv run python benchmarks/longmemeval/run_retrieval.py --semantic で再現できます。

プロトタイプではなく、実際のソフトウェアです

以下のすべての主張は、このリポジトリから再現できます。

• 敵対的な意思決定品質評価で34/36（94%）。不正解の2件は安全側に失敗します（VERIFY を行い、誤った REPLAY は行いません） — agent-memory eval（方法論）
• LongMemEval の検索プロキシ：Recall@5 が98.1%（_S、セマンティック）・87.0%（_M、語彙検索） — 独立した検索対象データ500件。エンドツーエンドの比較でも論文のベースラインとの直接比較でもありません。完全なレポート
• 最大1,000,000件の合成データ投入済みワークロードに対応する再現可能なストレステストハーネス。パフォーマンスに関する主張を公開する前に、JSON 出力を保存してください（方法論）
• ストレステストのベンチマークグラフ： 10K、100K、1M件のエントリーを対象にした語彙 FTS5 実行について、レイテンシのパーセンタイル、シードのスループット、リソース使用量、アクションの内訳、キャッシュ率／意思決定率を示します。ワークロードと保存済みの結果 JSON はストレステストに記載されています。
• 25のテストモジュールにわたる412件のテスト — 意思決定品質、並行処理、4つすべてのバックエンド、MCP サーバー、アダプターを対象とし、すべてのプッシュで CI により実行されます
• PyPI および公式の MCP Registry で公開されています
• REST API、Streamlit ダッシュボード、CLI、LangChain／LlamaIndex アダプターに加え、メモリの読み取り／書き込みおよび意思決定操作に対応する非同期版も同梱しています

---

使用する場面 — 実際のユースケース

ユースケース	メモリなしの場合	Agent Memory を使う場合	削減効果
1 日に 1 万件の同一 FAQ クエリに対応するサポートボット	クエリのたびに LLM 呼び出しが 1 回発生します	リクエストの約 75％が再利用可能なメモリに一致する場合、一致した内容を LLM 呼び出しなしで REPLAY できます	LLM コストを削減できる可能性があります。ご自身のワークロードで測定してください
セッションごとにプロジェクトの規約を導き出し直すコーディングエージェント	規約を「思い出す」ために、セッションごとに LLM 呼び出しを 2～5 回無駄にします	一度保存した規約は、以降の各セッションで最初のクエリから REPLAY／RESTORE されます	再導出のオーバーヘッドがありません
複数のセッションにわたって知識を蓄積するリサーチエージェント	各セッションは何もない状態から始まり、同じ情報源を再読します	事実や要約がコンテキストとして RESTORE されます	セッションをまたいで知識を保持できます
同じ手順を繰り返し回答する顧客オンボーディングボット	常に回答を生成します	信頼度の高いワークフローは、そのまま REPLAY されます	一貫した同一の回答
高コストな API 呼び出しのツール出力キャッシュ	毎回、外部 API を呼び出します	結果は TTL 付きで保存され、TTL 内は REPLAY し、期限後に再度呼び出します	外部 API コストを削減できます
再生前に事実を検証する必要があるポリシー準拠エージェント	古いデータによる、気付かれない幻覚のリスクがあります	requires_verification=True を設定すると、関連する一致項目は VERIFY に振り分けられ、スコアの低い一致項目は NONE を返します	監査可能性と安全性

Agent Memory が実際にコストを削減する場面

GPT-4o の呼び出し 1 回のコストは約 $0.005 です。1 日に 50,000 件のクエリに対応し、繰り返し率が 70％のサポートエージェントの場合：

• メモリなし：50,000 × $0.005 = $250/日
• Agent Memory を使用：LLM 呼び出し 15,000 回 + キャッシュミス = $75/日
• 削減額：約 $175/日（約 $64k/年）
• 削減額は、繰り返し率と受信したクエリが以前に保存したクエリにどれほど類似しているかによって異なります。ご自身のパイプラインで測定してください。

ポリシーで許可されている場合、REPLAY によって LLM 呼び出しを回避できます。レイテンシとコストの差は、ローカルのワークロード、プロバイダー、モデル、ネットワークによって異なります。ご自身のパイプラインで両方の経路を測定してください。

ユースケースに適していますか？

適しているケース：

• エージェントがセッションをまたいで、同じ質問や類似した質問に回答する
• 古くなる可能性がある、事実に基づく回答（価格、上限、ポリシー）がある
• 複数のエージェントやサービスでナレッジベースを共有する
• 監査証跡が必要で、どのメモリが、なぜ回答したかを把握したい

適していないケース：

• ファイル群を対象とするドキュメント RAG → その用途にはベクトルデータベースを使用してください
• アプリケーションの信頼できる唯一の情報源であるデータベースを置き換える
• 類似したクエリを繰り返すことがないエージェント

---

主な機能

機能	内容
意思決定エンジン	resolve() は毎回 REPLAY / RESTORE / VERIFY / NONE を返します。暗黙的に注入されることはありません
説明可能性	decision.explain() で、コンポーネントごとのスコア（セマンティック、鮮度、信頼度、使用状況）を確認できます
ハイブリッド検索	BM25 FTS5 + オプションのベクトル KNN + RRF による統合。高速かつ正確です
4 つのバックエンド	SQLite（デフォルト、セットアップ不要）・ChromaDB・Redis・PostgreSQL
フレームワークアダプター	LangChain と LlamaIndex 向けの BaseMemory をそのまま利用できます
MCP サーバー	Model Context Protocol 経由で Cursor、Claude Code、VS Code と連携します
REST API	9 つのエンドポイントと Swagger UI を備えた FastAPI サーバー
ダッシュボード	Streamlit UI。統計情報、メモリーブラウザー、リアルタイムの resolve サンドボックスを利用できます
マルチエージェント	複数のエージェント間で SHARED / NAMESPACED / ISOLATED メモリーを利用できます
信頼度の学習	イベント駆動型の信頼度更新と半減期による時間的減衰
メモリーグラフ	関係エッジ、経路探索、クラスター、PageRank による重要度
ページ分割されたコンテキスト	MemGPT 形式の階層：コンテキスト内バッファー → リコール → アーカイブ。クエリごとにワーキングセットを制限します
会話の蒸留	from_conversation() がターンから事実、好み、エンティティを自動抽出します
非同期 API	aremember、aresolve、alist、… — メモリーの読み書きや意思決定操作に非同期版が用意されています
TTL と状態	自動期限切れ、アーカイブ、類似した重複の統合

→ 機能の全リファレンス：docs/features.md

---

パフォーマンス

レイテンシー、CPU 使用率、メモリー使用量は、コーパス、クエリの分布、キャッシュの状態、埋め込みモード、マシン、オペレーティングシステムによって異なります。付属のハーネスでは再現可能な合成ワークロードを使用していますが、本番環境の SLA を保証するものではありません。

現在の語彙ベース FTS5 ベンチマークの結果とグラフは、元の JSON とともにストレステストの方法に保存されています。コマンド、ワークロードの範囲、結果の解釈方法については、こちらをご覧ください。

---

利用に適したケース

Agent Memory を使うケース：

• 過去のやり取りをすべてのプロンプトに注入せずに、エージェントに記憶させたい場合
• メモリーをいつ使うか（回答をそのまま再利用するか、コンテキストとして注入するか、先に検証するか）を明示的に制御したい場合
• メモリーに異なる信頼レベルがある場合（ユーザーの好み、古くなっている可能性のある事実、ツールの出力など）
• 複数のプロセス、サービス、またはエージェントで同じメモリーストアを共有する場合
• 監査証跡が必要な場合 — 再利用された各回答は、スコアの内訳とともに特定の保存エントリーまで追跡できます

次の用途には適しません：

• ドキュメント RAG（ファイルコーパスの検索） — その用途にはベクトルデータベースを使ってください。Agent Memory はクエリ→回答の経験を保存します
• データベースの置き換え — アプリケーションの信頼できる唯一のデータではなく、一時的なエージェントの知識を保存します

---

クイックスタート

pip install agent-memory-sdk

from agent_memory import Memory, MemoryAction

memory = Memory(persist_dir=".agent_memory")

# Store once after a good answer
memory.remember(
    "How do I reset my password?",
    "Go to Settings → Security → Reset Password.",
    type="conversation", tags=["auth"],
)

# Decide before every LLM call
decision = memory.resolve("How do I reset my password?")

if decision.action == MemoryAction.REPLAY:
    return decision.response          # exact match — no LLM call needed

if decision.action == MemoryAction.RESTORE:
    context = memory.format_restore_context(decision)
    return call_llm(query, system_extra=context)

# VERIFY or NONE — validate or answer fresh

→ 統合パターンと API の全リファレンス：docs/usage.md

---

ローカルセットアップ

オプション 1 — SQLite（依存関係なし、まずはこちらを推奨）

pip install agent-memory-sdk

# Store something
agent-memory remember "How do I reset my password?" \
  "Go to Settings → Security → Reset Password." \
  --type conversation --tags auth,faq

# Ask the exact question back → REPLAY (no LLM call needed)
agent-memory resolve "How do I reset my password?"
# ✅ REPLAY   confidence: 0.88
# response: Go to Settings → Security → Reset Password.

# Ask a paraphrase → RESTORE (inject as context, don't answer verbatim)
agent-memory resolve "I forgot my password"
# 📋 RESTORE  confidence: 0.77
# [1] score=0.77  How do I reset my password? → Go to Settings → …

# See what's stored
agent-memory stats

オプション 2 — Redis または Postgres バックエンド

# Spin up the services
docker compose -f docker-compose.dev.yml up -d

# Install the backend extra
pip install "agent-memory-sdk[redis]"      # or [postgres]

# Use it
agent-memory --backend redis remember "API limit" "1000 req/min" --type fact
agent-memory --backend redis resolve "What is the rate limit?"

オプション 3 — Streamlit ダッシュボード（視覚的な探索）

pip install "agent-memory-sdk[dashboard]"

# Seed demo data (optional)
python scripts/seed_demo.py --data-dir .agent_memory

# Open the dashboard
AGENT_MEMORY_DIR=.agent_memory agent-memory-dashboard
# → http://localhost:8501

オプション 4 — 開発環境 / ソースからのセットアップ

git clone https://github.com/TheProdSDE/agent-memory-sdk.git
cd agent-memory-sdk
python -m venv .venv && source .venv/bin/activate
pip install -e ".[dev]"
make test          # run all tests
make check         # lint + type check

---

ダッシュボード

メモリーの探索、resolve サンドボックスのテスト、統計情報の監視に使える、インタラクティブな Streamlit ダッシュボードです。

統計情報 — KPI とグラフ	メモリー — 検索可能なテーブル

Resolve → REPLAY	Resolve → VERIFY

pip install "agent-memory-sdk[dashboard]"
AGENT_MEMORY_DIR=.agent_memory agent-memory-dashboard   # → http://localhost:8501

# Seed demo data (optional — run only when you want it)
python scripts/seed_demo.py --data-dir .agent_memory

MCP サーバー

Agent Memory は MCP Registry で公開されています。手動でのセットアップは不要で、MCP 対応クライアントならどれでもインストールできます。

MCP クライアントへの追加

Cursor — プロジェクトの .cursor/mcp.json、または全体設定の ~/.cursor/mcp.json に追加します。

{
  "mcpServers": {
    "agent-memory": {
      "command": "uvx",
      "args": ["agent-memory-sdk"]
    }
  }
}

Claude Desktop — ~/Library/Application Support/Claude/claude_desktop_config.json（macOS）または %APPDATA%\Claude\claude_desktop_config.json（Windows）に追加します。

{
  "mcpServers": {
    "agent-memory": {
      "command": "uvx",
      "args": ["agent-memory-sdk"]
    }
  }
}

Claude Code — プロジェクトの .claude/settings.json に追加します。

{
  "mcpServers": {
    "agent-memory": {
      "command": "uvx",
      "args": ["agent-memory-sdk"]
    }
  }
}

初回実行時に uvx がパッケージをインストールするため、pip install は不要です。

カスタム保存先

{
  "mcpServers": {
    "agent-memory": {
      "command": "uvx",
      "args": ["agent-memory-sdk"],
      "env": {
        "AGENT_MEMORY_DIR": "/path/to/your/memory",
        "AGENT_MEMORY_COLLECTION": "my_project"
      }
    }
  }
}

変数	デフォルト	説明
AGENT_MEMORY_DIR	~/.agent_memory	永続的な SQLite ストアのディレクトリ
AGENT_MEMORY_COLLECTION	agent_memories	コレクション名（コレクションごとに DB を作成）

公開されるツール

ツール	機能
resolve_memory	メモリーを取得し、信頼度スコアと推論を添えて、明確な判断（再生／復元／検証／なし）を返します
remember_memory	クエリと応答のペアを、任意のタグ、種類、スコープ、信頼度、TTL とともに保存します
list_memories	スコープとアーカイブのフィルターに対応した、保存済みメモリーのページ分割リストを返します
get_memory_by_id	ID で単一のメモリー項目を取得します
forget_memory	メモリーを完全に削除します
archive_memory	メモリーをアーカイブします（取得対象から除外しますが、削除はしません）
consolidate_memories	類似したメモリーを統合し、要約項目を作成します

→ MCP のセットアップガイドと Docker 設定：docs/mcp.md

---

インテグレーション

中核となるのは agent-memory-sdk で、すべてのインテグレーションは Memory に処理を委譲します。

インテグレーション	追加でインストールするもの	例
コア SDK（SQLite）	(なし)	basic_usage.py
LangChain BaseMemory	[langchain]	langchain_integration.py
LlamaIndex BaseMemory	[llamaindex]	llamaindex_integration.py
Redis バックエンド	[redis]	redis_backend.py
PostgreSQL バックエンド	[postgres]	postgres_backend.py
マルチエージェント分離	(なし)	multi_agent.py
FastAPI REST サーバー	[api]	rest_api.py
信頼度 + グラフ	(なし)	confidence_and_graph.py
ベンチマークハーネス	(なし)	benchmark_harness.py

→ 各インテグレーションのセットアップ手順とコードスニペット：examples/README.md

---

技術スタック

コンポーネント	技術
言語	Python 3.10+
ストレージ	SQLite · ChromaDB · Redis · PostgreSQL
取得	BM25 FTS5 + Vector KNN + RRF 融合
インターフェース	MCP · FastAPI · Streamlit · CLI
アダプター	LangChain BaseMemory · LlamaIndex BaseMemory
検索 DSA	ブルームフィルター（NONE 高速パス）· 動的 IDF ストップワード · RRF 融合
テスト	pytest（収集されたテスト 412 件）· ruff · mypy
CI/CD	GitHub Actions — テストマトリックス 3.10–3.13 → リリースゲート → PyPI

API キーは不要です。すべてローカルで動作します。

---

ドキュメント

ドキュメント	内容
docs/usage.md	統合パターン、API リファレンス、MemoryEntry / MemoryDecision のフィールド
docs/features.md	決定アクション、ハイブリッド検索、タイプ、スコープ、TTL、グラフ、マルチエージェント
docs/mcp.md	Cursor、Claude Code、VS Code 向け MCP サーバーのセットアップ、Docker 設定
docs/cli.md	CLI コマンド、REST API サーバー、ダッシュボードの起動、評価データセット形式
docs/roadmap.md	リリース済みの全機能、今後の予定、GitHub Project ボード
docs/release.md	CI による自動リリースプロセス、バージョン管理、ロールバック
docs/architecture.md	検索パイプライン、スコアリングポリシー、システム設計
docs/comparison.md	Redis、mem0、Zep、LangMem、LlamaIndex、MemGPT との機能比較
docs/stress-testing.md	方法論を含む 10K / 100K / 1M のレイテンシベンチマーク
docs/benchmarks.md	評価結果と再現コマンド
docs/why-decision-layer.md	このプロジェクトが解決するために存在する障害モード
examples/README.md	実行可能な全サンプルの一覧
CONTRIBUTING.md	開発環境のセットアップ、テストコマンド、PR チェックリスト

---

ステータスとロードマップ

v0.5.0 までに計画されていた機能はすべてリリース済みです。 今後の予定は**GitHub Project →**で確認できます。

→ docs/roadmap.md

リリース

タグをトリガーとし、CI による完全なゲートを設けています：git tag v0.x.y && git push origin v0.x.y

→ docs/release.md

---

コントリビューション

開発環境のセットアップ、テストコマンド、PR チェックリストについては、**CONTRIBUTING.md**を参照してください。

---

引用

Agent Memory SDK またはそのベンチマークスイートを研究、記事、プロジェクトで使用する場合は、 GitHub の**「このリポジトリを引用」**ボタンを使って、このリポジトリを引用してください。

再現可能なベンチマーク比較を行うには、 正確な SDK バージョン、ベンチマークデータセットのバージョン、 設定、および Git コミットを明記してください。

---

ライセンス

Apache-2.0 — LICENSEを参照してください。

---

サポート

• 課題： GitHub Issues
• ディスカッション： GitHub Discussions
• メール： [email protected]

---

Agent Memory はエージェントの判断を支援します：リプレイ → 復元 → 検証 → 無視

TheProdSDE が ❤️ を込めて開発

mcp-name: io.github.theprodsde/agent-memory