Agent Memory Bridge

簡体字中国語

コーディングエージェント向けのMCPネイティブなメモリ層であり、実際のセッションを再利用可能なエンジニアリングメモリへと変換します。

Codex向けに構築されています。

Agent Memory Bridgeは、通常チャット履歴から失われてしまう以下の情報をキャプチャします：

• 持続的な決定事項

• 既知の修正方法

• セッションをまたいだ引き継ぎ

• 再利用可能な注意点（gotchas）

• コンパクトなドメイン知識

核となる考え方はシンプルです。メモリ層を小さく、信頼性が高く、検証可能な状態に保ち、上位レベルのオーケストレーションをその上に構築することです。

興味深いのは単なる永続化ではなく、自動的なメモリの形成です：

• セッションは再利用可能な learn になる

• 繰り返される失敗は gotcha になる

• レッスンの集まりはコンパクトな domain-note になる

なぜこれが存在するのか

ほとんどのエージェントメモリシステムは、以下の3つのパターンのいずれかに陥ります：

• 特定のアプリやモデルの中にメモリが閉じ込められている

• 検索の基本が証明される前に、重厚なホスト型インフラを必要とする

• 再利用可能な運用知識ではなく、トランスクリプトをそのままダンプしている

Agent Memory Bridgeは、より狭い道を選択しました：

• 最初からMCPネイティブであること

• ローカルファーストなランタイム

• 重厚なインフラではなく、SQLite + FTS5を採用

• セッションの痕跡から再利用可能なメモリへの自動昇格

これは単なるストレージではありません。メモリ形成のパイプラインです：

session -> summary -> learn -> gotcha -> domain-note

ポジショニング

Agent Memory Bridgeは意図的に範囲を絞っています。

SDK、ダッシュボード、コネクタ、マルチサーフェスアプリケーションのサポートを備えたより広範なメモリプラットフォームを求める場合は、OpenMemoryやMem0のようなプロジェクトの方がその形に近いでしょう。

このプロジェクトは意図的に異なります：

1. 汎用的なノートストレージではなく、コーディングエージェントのワークフローのために構築されています。

2. MCPのインターフェースを意図的に store と recall のみに絞っています。

3. 要約を最終成果物として扱うのではなく、生のセッション出力を機械可読なコンパクトなメモリに昇格させます。

4. デフォルトでローカルファーストかつ検証可能です。

より詳細なポジショニングについては、docs/COMPARISON.md を参照してください。

仕組み

ランタイムには4つの主要なパーツがあります：

1. MCPサーバー

   • store と recall を公開

2. ウォッチャー

   • Codexのロールアウトファイルを監視

   • session-seen、checkpoint、closeout を書き込み

3. リフレックス（反射）

   • 要約を learn、gotcha、signal に昇格

4. 統合

   • 繰り返し発生する learn や gotcha レコードをドメインノートに合成

これにより、システムを理解しやすく保ちます：

• 生のセッションは最終的なメモリではない

• 要約は最終的なメモリではない

• 持続的なメモリは機械優先である

• 合成は昇格後に行われる

クイックスタート

要件：

• Python 3.11+

• MCPが有効なCodex

• FTS5サポートを備えたSQLite

1. インストール

python -m venv .venv
.\.venv\Scripts\Activate.ps1
pip install -e .[dev]

2. ブリッジ設定の作成

config.example.toml を以下にコピーします：

$CODEX_HOME/mem-bridge/config.toml

推奨設定：

• ライブのSQLiteデータベースは各マシン上でローカルに保持する

• 必要に応じて、共有プロファイルやソースボルトをNASや共有ストレージに保持する

• 真のマルチマシンでのライブ書き込みが必要になった場合に、ホスト型バックエンドへ移行する

3. CodexにMCPサーバーを登録

$CODEX_HOME/config.toml に以下を追加します：

[mcp_servers.agentMemoryBridge]
command = "D:\\path\\to\\agent-memory-bridge\\.venv\\Scripts\\python.exe"
args = ["-m", "agent_mem_bridge"]
cwd = "D:\\path\\to\\agent-memory-bridge"

[mcp_servers.agentMemoryBridge.env]
CODEX_HOME = "%USERPROFILE%\\.codex"
AGENT_MEMORY_BRIDGE_HOME = "%USERPROFILE%\\.codex\\mem-bridge"
AGENT_MEMORY_BRIDGE_CONFIG = "%USERPROFILE%\\.codex\\mem-bridge\\config.toml"

4. サービスの開始

MCPサーバーを開始します：

.\.venv\Scripts\python.exe -m agent_mem_bridge

バックグラウンドのブリッジサービスを実行します：

.\.venv\Scripts\python.exe .\scripts\run_mem_bridge_service.py

1サイクルのみ実行します：

$env:AGENT_MEMORY_BRIDGE_RUN_ONCE = "1"
.\.venv\Scripts\python.exe .\scripts\run_mem_bridge_service.py

オプションのスタートアップインストール：

.\scripts\install_startup_watcher.ps1

オプション：ローカルDockerイメージのビルド

docker build -t agent-memory-bridge:local .
docker --context desktop-linux run --rm -i agent-memory-bridge:local

コンテナのエントリポイントは、python -m agent_mem_bridge でstdio MCPサーバーを開始します。

コアAPI

MCPのインターフェースは意図的に小さく設計されています：

• store

• recall

一般的な store フィールド：

• namespace

• content

• kind

• tags

• session_id

• actor

• title

• correlation_id

• source_app

一般的な recall フィールド：

• namespace

• query

• kind

• tags_any

• session_id

• actor

• correlation_id

• since

• limit

一般的な名前空間

• project:<workspace>

• global

• domain:<name>

• チームが必要とするインポートされたプロファイル名前空間

フレームワークはプロファイルに依存しません。特定のオペレータープロファイルを上に重ねることは可能ですが、ブリッジ自体は特定のペルソナやプロトコルに縛られません。

日常的な使用

意図されている階層構造は以下の通りです：

• システムレベルのオペレータープロファイル

• システムレベルのメモリ基盤：agentMemoryBridge

• プロジェクトローカルのオーバーライド：AGENTS.md

スタートアッププロトコルは docs/STARTUP-PROTOCOL.md に文書化されています。

要約すると：

1. グローバルな運用メモリを呼び出す

2. 関連する専門メモリを呼び出す

3. ワークスペースが存在する場合は project:<workspace> を呼び出す

4. イシューのような作業については、外部検索の前にローカルメモリと注意点を確認する

5. 呼び出された実装の詳細を信頼する前に、ライブコードを検査する

便利なコマンド

テストの実行：

.\.venv\Scripts\python.exe -m pytest

stdioスモークテストの実行：

.\.venv\Scripts\python.exe .\scripts\verify_stdio.py

ベンチマークの実行：

.\.venv\Scripts\python.exe .\scripts\run_benchmark.py

ブリッジのヘルスチェックの実行：

.\.venv\Scripts\python.exe .\scripts\run_healthcheck.py --report-path .\examples\healthcheck-report.json

最新のロールアウトからチェックポイントを強制実行：

.\.venv\Scripts\python.exe .\scripts\sync_now.py

プロジェクト構造

リポジトリは意図的に小さく保たれています：

src/agent_mem_bridge/   canonical implementation
scripts/                operational entrypoints
tests/                  verification
docs/                   design and roadmap
examples/               sanitized demo artifacts

重要なファイル：

• src/agent_mem_bridge/server.py

• src/agent_mem_bridge/storage.py

• src/agent_mem_bridge/watcher.py

• src/agent_mem_bridge/reflex.py

• src/agent_mem_bridge/consolidation.py

• src/agent_mem_bridge/service.py

設計上の選択

小さなMCPインターフェース

ブリッジは store と recall のみを公開します。これにより、契約が安定し、統合が容易になります。

ローカルファーストなランタイム

共有ネットワークストレージ上のSQLiteは信頼性の罠となるため、ライブDBはデフォルトでローカルに保持されます。

機械優先のメモリ

エージェントが主な読者であるため、メモリは以下を優先します：

• コンパクトなフィールド

• 安定したタグ

• 低いトークンコスト

洗練された散文よりもこれらを優先します。

階層的な昇格

システムは以下のように上方への移動を試みます：

• summary

• learn

• gotcha

• domain-note

生の要約を最終成果物として扱うのではなく、昇格させていきます。

ステータス

現在の基盤は機能しています：

• CodexでのMCP自動読み込み

• プロジェクトおよびセッションの同期

• 呼び出し優先のワークフロー

• リフレックスによる昇格

• 初回パスのドメイン統合

現状確認とロードマップ：

• docs/PRODUCTION-STATUS.md

• docs/ROADMAP.md

プロファイルのインポート

フレームワークはインポートされたオペレータープロファイルをホストできますが、フレームワーク自体はプロファイルに依存しない状態を維持します。

ドキュメント

• README.zh-CN.md

• CONTRIBUTING.md

• AGENTS.md

• docs/COMPARISON.md

• docs/STARTUP-PROTOCOL.md

• docs/MEMORY-TAXONOMY.md

• docs/PROMOTION-RULES.md

• docs/MODEL-ROUTING.md

• docs/ROADMAP.md

ライセンス

MIT。LICENSE を参照してください。