EverOS レビュー: Markdown を正本にしたローカル優先エージェント記憶層

EverOS が埋めようとしている穴はどこにあるか

エージェントに長期記憶を持たせる方法は、大きく二つに割れている。ベクトルデータベースやマネージドサービスに会話を流し込み、検索 API 経由で取り出す方式と、プロンプトに直近の履歴を貼り続ける方式である。前者は中身が見えず、後者はセッションをまたぐと消える。EverOS が狙うのはその中間で、記憶の実体を人が読める Markdown ファイルとしてディスクに置き、検索用の索引をその脇に従属させる。README の比較表では、他ライブラリの保存先を「API、ベクトル、グラフ、ダッシュボード、あるいはデータベースの状態」と表現し、EverOS 自身は「正本となる .md ファイル」だと対置している。想定読者は、自分のマシン上でエージェントを動かし、記憶の中身をエディタで開いて直したい人、そして複数のアプリやツールの間で同じ記憶を持ち回りたい人である。

Markdown・SQLite・LanceDB の三層と、書き込みが伝播する経路

構成は README によれば Markdown、SQLite、LanceDB の三部作で、MongoDB、Elasticsearch、Redis は不要と明記されている。データの流れはデモの説明にある ingest、extract、index、recall の四段階で捉えられる。会話やファイルが取り込まれ、そこから記憶として残すべき内容が抽出され、Markdown として書き出され、SQLite と LanceDB の索引に反映され、検索で引き戻される。注目したいのは、索引が正本ではないと割り切っている点だ。README の表には「.md ファイルを編集すれば cascade watcher が同期する」とあり、外部エディタでの手直しが一次操作として扱われる。索引を消しても Markdown から再構築できるという前提が読み取れる。もう一つの軸が記憶の持ち主の分離である。ユーザー側の episodes と profile、エージェント側の cases と skills がそれぞれ第一級の面として並び、検索は user_id、agent_id、app_id、project_id、session_id で直交的に絞り込む。アプリ単位やテナント単位で切るのではなく、複数の識別子の組み合わせで同じ記憶空間を切り分ける設計だ。

reflection は何を書き換えるのか

README の比較表で EverOS が他と最も違うと主張しているのが reflection である。説明は「セッション間でエピソードのクラスタを統合し、プロファイルとスキルを洗練させるオフラインの記憶進化」とされている。つまり検索のたびに読み出すだけでなく、セッションが終わった後にバックグラウンドで記憶そのものを再編する処理が入る。エピソードが溜まると似たものをまとめ、プロファイルを更新し、エージェント側のスキルを磨く。ここは設計上の利点であると同時に、最も慎重に扱うべき部分でもある。Markdown が正本である以上、reflection は人の書いたファイルを機械が書き換える処理になる。Git で版管理していれば差分は追えるが、その差分が意図した統合なのか誤った要約なのかを判定する仕組みについては、README からは読み取れない。記憶の自動統合を許容できるかどうかは、用途によって判断が分かれるところだ。

動かすまでに打つコマンドと、書く設定キー

前提は Python 3.12 以降と OpenRouter の API キー一つである。インストールは uv pip install everos、あるいは pip install everos。キーなしで挙動を確かめたい場合は everos demo を実行し、覚えてほしい内容を入力してから関連する質問をすると、ingest から recall までの流れが観察できると README は説明している。本設定は everos init で、これにより ~/.everos/everos.toml と ~/.everos/ome.toml が生成される。everos.toml を開くとモデル名と OpenRouter の URL は既に入っており、空の api_key だけを差し替える。キーは [llm] セクションの model、api_key、base_url の三つで、既定のモデルは openai/gpt-4.1-mini、base_url は https://openrouter.ai/api/v1 である。記憶の置き場所を変えたい場合は everos init --root <path> を使い、以降のコマンドにも同じ --root を渡す。起動は everos server start で、別のターミナルから curl http://127.0.0.1:8000/health を叩き、"status":"ok" を確認する。この最小構成では capabilities.llm が true になり、embedding と rerank は設定するまで false のままだと README は述べている。

embedding と rerank が既定で無効である意味

Tier 1 の構成で keyword search だけが有効になっている点は、見落とすと期待を裏切られる。README の Quick Start は「キーワード検索で記憶を引き出す」と書き、embedding と rerank は false のままだと明言する。つまり最初に動かした状態では、意味の近さで拾う検索ではなく語の一致で拾う検索になる。記憶の表現が質問の言い回しとずれている場合、取りこぼしが起きる。ここは導入判断の分かれ目で、キーワード検索で足りる用途なら設定は軽く済むが、言い換えを跨いだ想起を期待するなら embedding と rerank を有効化する追加設定が要る。README の提示範囲ではその設定手順の詳細までは示されておらず、docs.evermind.ai を参照する形になっている。加えて、LLM 呼び出しが OpenRouter 経由である以上、記憶の抽出と reflection のたびに外部 API へ内容が送られる。ローカル優先という語から完全なオフライン動作を連想すると、そこはずれる。

RAG パイプラインとの違い、あるいは別物である理由

比較対象として分かりやすいのは、文書をチャンクに割ってベクトル化し、質問に近い断片をプロンプトに詰める一般的な RAG の構成である。あちらは原本が文書のままで、ベクトル索引は検索のためだけの副産物であり、索引を捨てれば検索はできなくなるが原本は無傷だ。EverOS も Markdown を正本とする点では同じ姿勢に見えるが、決定的に違うのは reflection の存在である。RAG は検索しかしない。EverOS は記憶を統合し、プロファイルとスキルを書き換える。原本が更新される。さらにユーザー側とエージェント側という二つの面を最初から持ち、user_id や agent_id で直交的に切る。RAG の索引が「文書を引くためのもの」なのに対し、EverOS の記憶は「エージェントが育つための土台」として扱われる。同じ検索技術を使っていても、何を保存の単位とするかが根本的に異なる。

向かない場面と、導入前に決めておくべきこと

第一に、複数の利用者を厳格に分離するサービスにはそのままでは使いにくい。記憶がローカルのファイルツリーに平置きされ、識別子による絞り込みは検索時の条件であって保存時の境界ではない。テナント分離を保存層で保証したい要件とは噛み合わない。第二に、記憶の中身を人間が読む予定がないシステムでは、Markdown 正本という利点がほぼ働かない。読み書きできることが前提の設計なので、読まないなら索引だけを持つ構成のほうが単純になる。第三に、reflection による自動統合を許容できない用途。監査や法務のように記憶の改変履歴そのものが問題になる場面では、オフラインでの書き換えは負担になる。導入前に確認したいのは、api_key 設定後に capabilities の embedding と rerank が true になるか、記憶ルートを既定の ~/.everos から動かすか、そして reflection が生む Markdown の差分を Git で追うのか捨てるのかである。ライセンスは Apache-2.0 で、特許条項を含む寛容な条件だが、これは法的助言ではない。同梱の NOTICE や依存パッケージの条件は別途確認する必要がある。

編集部の結論

自分が読める形で記憶を保持したい個人開発者や、複数のエージェントで同じ記憶を共有したい小規模チームには、Markdown 正本という方針が効く場面がある。逆に、複数テナントを厳密に分離する必要があるサービスや、記憶の内容を人間が一切読まない前提のシステムには向かない。導入前に確認すべきは、~/.everos/everos.toml の api_key を設定した状態で capabilities の embedding と rerank が true になるか、そして reflection が書き換えた Markdown を Git でどう扱うかを決めておくことである。

公式情報源

1. EverMind-AI/EverOS on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases