EverMind-AI/EverOS は、AI エージェントとチャット アプリケーションの長期メモリ用のオープンソース Python フレームワークです。その目標は、別のチャットボットを作成することではなく、会話、エージェントの実行軌跡、およびファイル知識を、構造化され、取得可能で、進化するメモリ層に整理することです。
最も興味深いのはストレージ設計です。EverOS はメモリをブラック ボックス データベースにロックせず、真実のソースとして Markdown を使用します。直接開いたり、編集したり、grep したり、Git バージョン管理を使用したり、Obsidian で表示したりすることもできます。
それはどのような問題を解決しますか?
エージェントの「記憶」の多くは、実際には短期的なコンテキストにすぎません。
- 今日は話しましたが、明日は忘れてしまいました。
- あるツールは知っていても、別のツールは知らない。
- ユーザーの好み、プロジェクトの経験、失敗事例はすべてチャット履歴に散在します。
- RAG はファイルを検索できますが、「経験したこと」を保存できない場合があります。
- メモリ システムが複雑なデータベースに依存すると、小規模チームのメンテナンス コストが増加します。
EverOS が実現したいのは、長期記憶ベースの軽量化です。ユーザー側の記憶とエージェント側の記憶を分離します。ユーザーにはプロフィール、エピソード、事実、見通しがあります。エージェントにはケースとスキルがあります。これは単に「文章を覚える」ということではなく、人、仕事、経験、プロセスを少しずつ積み重ねていくことです。
技術的な構造
EverOS の中心原則は README に明確に記載されています。
- 真実の情報源としてのマークダウン: すべての記憶は最終的に
.mdファイルに格納されます。 - 軽量 3 ピース ストレージ: Markdown + SQLite + LanceDB;
- EverAlgo はメモリ取得アルゴリズムを担当し、EverOS はオーケストレーションと永続性を担当します。
ストレージのレイアウトは大まかに次のとおりです。
|
|
Markdown は真実の情報源であり、SQLite は状態とキュー用であり、LanceDB はベクトル、BM25、およびスカラー フィルター用です。この組み合わせは、MongoDB、Elasticsearch、Milvus、Redis、Kafka ファミリ バケットよりもはるかに軽量であり、個人の開発者や小規模チームにより適しています。
クイックスタート
インストールは非常に簡単です。
|
|
初期設定:
|
|
次にサービスを開始します。
|
|
EverOS のエンドポイント スタックは OpenAI プロトコルと互換性があり、OpenAI、OpenRouter、vLLM、Ollama、DeepInfra などのサービスに接続できます。対応する BASE_URL と .env の API キーを調整するだけです。
画像、PDF、オーディオ、Office ドキュメントなどの非テキスト コンテンツを処理する場合は、マルチモーダル拡張機能をインストールできます。
|
|
Office ドキュメントの変換は LibreOffice に依存しています。 LibreOffice がないと、PDF、画像、音声などには影響しませんが、.doc、.docx、.ppt、.pptx、.xls、.xlsx などの Office ファイルは処理できません。
どのシナリオが適していますか?
EverOS は次のアプリケーションに適しています。
- AI プログラミング アシスタントは、プロジェクトの合意事項、落とし穴の記録、一般的なプロセスを長期間記憶します。
- マルチエージェントのコラボレーション中に長期記憶を共有します。
- パーソナル チャット アシスタントは好み、経験、長期的な目標を記憶します。
- 企業の内部知識アシスタントが文書知識と会話経験を一緒に蓄積します。
- 科学調査、データ分析、運用などのタスクでは、セッション全体でケースを継続的に蓄積する必要があります。
- メモリをクラウド プラットフォームに完全に任せるのではなく、ローカル ファイルに置きたい。
単純な FAQ を行うだけの場合には適していません。 FAQ 通常の RAG で十分です。 EverOSの価値は、単に静的なデータを検索するのではなく、「使えば使うほどメモリが厚くなる」という点にあります。
境界を使用する
長期記憶は美しく聞こえますが、いくつかの落とし穴もあります。
- 記憶違いは忘れることよりも危険であり、記憶を取り戻すには手動による検証が必要です。
- ユーザーのプライバシーと機密情報は、表示、削除、エクスポート可能でなければなりません。
- エージェントは、記憶が存在するからといって古い結論を盲目的に信頼することはできません。
- マルチユーザー、マルチプロジェクト、マルチエージェントの分離を明確に設計する必要があります。
- Markdown が編集可能であることの利点は、インデックス同期を手動で変更する必要があることも意味します。
したがって、EverOS は直接最終製品として考えるよりも、インフラストラクチャとして考えるのが適切です。どのような内容を記憶できるか、いつ記憶するか、どれくらいの期間記憶するか、誰が読むことができるか、間違っている場合はどのように修正するかなど、アプリケーション層で決定する必要があります。
まとめ
EverOS の設計は非常に満足のいくものです。Markdown を真実のソースとして使用し、SQLite と LanceDB をインデックスとして使用し、ブラック ボックス データベースから長期メモリを読み取り可能、変更可能、バージョン管理可能なファイル システムに戻します。
AI エージェント、パーソナル アシスタント、プログラミング アシスタント、またはマルチエージェント プラットフォームに取り組んでいて、「セッション終了時の記憶喪失」の問題に遭遇したことがある場合は、EverOS を検討する価値があります。これは万能の頭脳ではありませんが、メモリ オペレーティング システムの非常に実用的なプロトタイプを提供します。