mcpField
M
memoweft

memoweft

ローカル
github.comメモリ・ナレッジ62 日前に更新

memoweft について

MemoWeftは、AIアプリケーション向けのローカル優先メモリエンジンです。生のエビデンス、派生オブジェクト、出典、権限を分けて保持し、MCP経由で根拠の追跡や訂正・忘却を管理できます。

主な機能

  1. 01エビデンス、Worldオブジェクト、出典を分離
  2. 02改訂、訂正、撤回に対応
  3. 03権限と忘却フローを管理
  4. 04ポータブルなメモリデータ
  5. 05Worldを書き換えない決定的な想起

活用シーン

  1. 01AIアプリケーションで追跡可能なユーザーメモリを保存
  2. 02保存情報を訂正または撤回
  3. 03権限に応じてメモリと出典を取得

MCP 対応

MCP サーバーとして、MemoWeftのメモリを参照・管理するための5種類の読み取りツールと3種類の制御された書き込みツールをクライアントに提供します。

設定

ローカルサーバーの設定はどのクライアントでも共通です。コピーしてクライアントの MCP 設定ファイルに貼り付けてください。

mcp.json · 共通設定
{
"mcpServers": {
"memoweft-memoweft": {
"command": "npx",
"args": [
"-y",
"@memoweft/mcp-server"
],
"env": {
"MEMOWEFT_DB_PATH": "<MEMOWEFT_DB_PATH>"
}
}
}
}
起動コマンドnpx -y @memoweft/mcp-server
設定が必要な環境変数
MEMOWEFT_DB_PATHPath to the MemoWeft database file (or ':memory:' for an ephemeral in-memory database). Required.

ローカルサーバーにはマシン上の実行環境(Node.js 18 以上など)が必要です。設定ファイルの場所はクライアントごとに異なります。

パッケージ
npm@memoweft/mcp-server0.2.3

ツール

8

掲載時のツール一覧 · 2 週間前に更新

パラメーター型必須説明
querystringはい知識を呼び出すためのクエリ。
explainbooleanいいえ各認知の出典チェーン(支持/反証する証拠)を含めます。クラウドアクセスが制限された証拠は認可メタデータのみ保持され、要約は表示されません。
subjectIdstringいいえ呼び出し対象の主体。既定では設定済みの主体です。
contentTypesarrayいいえ内容タイプがこの許可リストに含まれる認知のみを呼び出します(例:"preference"、"goal")。省略すると、すべてのタイプが対象になります。

詳細

MemoWeft

MemoWeft は、AI アプリケーション向けのローカルファーストなメモリエンジンです。Evidence、派生した World オブジェクト、来歴、リビジョン、修正、撤回、権限の状態、ポータブルデータを別々のレコードとして保持するため、ホストは何を、なぜ記憶しているのかを説明できます。

简体中文

パッケージの提供内容

ルートの npm パッケージは TypeScript ライブラリです。py/ プロジェクトは Python 版 MemoWeft 2.0 の実装で、本番環境用の Hermes プロバイダー、Trust サービス、Portable v4、DSH RPC v2 が含まれています。また、ソースツリーには Memory Experience アプリも含まれていますが、このアプリはルートの npm tarball には組み込まれていません。

Python ディストリビューションは、hermes_agent.memory_providers エントリーポイントグループに memoweft プロバイダーを公開します。パッケージのメタデータ、ソースマニフェスト、インストール後の動作は、それぞれ別の証拠レイヤーであり、個別に検証する必要があります。

TypeScript パッケージのインストール

公開済みの npm リリースには npm install memoweft を使用してください。Node 24 には SQLite が組み込まれています。Node 20 と Node 22 では、オプションの better-sqlite3 ドライバーを使用します。

リポジトリの候補バージョンは、最新の公開済みパッケージより新しい場合があります。ローカルビルドの成功や tarball のハッシュだけでは、レジストリへの公開を証明できません。

メモリーの契約

MemoWeft は、以下の境界を明確に保ちます。

  • 生のユーザーコンテンツは、来歴と権限を伴う正確な Evidence として保持されます。
  • 保存されたメモリを忘れる要求は、記憶された事実の否定ではありません。形成時にはそのコマンドの項目を除外しますが、独立した事実の記述は引き続き対象になります。別途許可された忘却フローが完了するまで、生の Evidence はそのまま保持されます。事実を明確に否定する記述は、引き続き撤回の根拠になります。
  • ソースに紐付いた訂正は、その後の no_change の後に、適用済みレシート、現在の置換項目、正確な根拠範囲、提示されたプロジェクションが一致する場合にのみ完了とみなされます。同じメッセージ内のその他の訂正、記憶要求、未カバーの未知の事実は未完了のままです。ソースが共通であることだけでは完了の証明になりません。共有台帳は、逐語的な MemoryLoop Evidence レコードも受け付けますが、その文章や JSON コンテンツが形成の根拠レコードや訂正完了の証明になることはありません。
  • セグメントまたは引用によって選択された形成命題は、名前、呼びかけ方、数値、日付を保持した逐語的な Evidence から導出されます。形成ペイロードでは、既存の細かな segments と並んで、文章全体を保持する sentences が提供されます。根拠として、同じトピックの主張全体を選ぶ sentence_id、または独立した節を選ぶ segment_id を明示できます。これらは代替となるソース範囲です。Core は選択されていない範囲を拡張せず、重複する選択を拒否します。ユーザーとの関係が明示された人物は、名前だけの属性や第三者の属性ではなく、Relationship レコードとして分類されます。解釈 JSON またはコンパイラーのフィールドが無効な場合、ジョブが書き込みなしで確定する前に、具体的なコンパイラーエラーを添えてモデルに一度だけ書き直しを要求します。永続的なモデルチェックポイントは最初の応答、エラー、書き直しの結果を保持します。復旧時に、予約済みまたは完了済みの書き直しが繰り返されることはありません。デフォルトの DSH HTTP ルートは response_format: {"type": "json_object"} を要求します。Core の検証では引き続き、必須フィールドと Evidence による裏付けを確認します。宣言的なソースの後にモデルが no_change を返した場合も、最初の結果を保持したうえで、同じくチェックポイントに記録して一度だけ再検討します。イベントの暦日付は、選択されたソース内の曖昧さのない明示的な数値日付から正規化されます。相対的または曖昧な日付では、推測した occurred_at 値を設定せず、元の時間表現を保持します。推論のみのモデル出力は、解釈として使用されず、書き直しへのフィードバックにも含まれません。
  • Entity、Relationship、Event、Cognition、Evaluation レコードは、正式な World オブジェクトです。
  • 確認では、権限の対象となる直近4件の会話ターンを参照できます。コンパイラーは、永続化されたメッセージ ID と照合してアシスタントの提案が正確であることを検証し、ユーザーの確認を Evidence として保持します。提案の参照は、既存の根拠/削除グラフに加わります。ソースクエリでは元の両方が公開されます。ユーザーが明示的に言い直した内容は逐語的に保持され、同一人物について直前にある一意の提案を文脈として保持できる場合があります。アシスタントの文章がユーザーの Evidence になることはありません。confirmed を通じて提案を取り込むには、選択範囲と短い返信全体の両方に、既知の肯定表現、または肯定表現と提案内の完全な文字どおりの値が含まれている必要があります。偶発的な文字の重なりや、否定の前で切り取られた肯定表現は該当しません。その他の明示的なユーザーによる言い直しには stated を使用します。ルールと監査を参照してください。Yes, do that. や 好 のように行動を指示する同意には、選択された主張自体が行動の提案である必要があります。隣接する申し出によって事実の推測を確認することはできません。確認の説明には選択された主張のみを引用しますが、来歴にはアシスタントのターン全体を保持します。過去の行動を指す短い中国語の表現は、明示的な同意の前に置くことができます。その完全な文字どおりのトピックと行動動詞が、選択された提案と一致する必要があります。返信全体に対する否定チェックも引き続き適用されます。限定された文法と制限については、確認ルールに記載されています。
  • World 項目の忘却は、同じアカウント内の別のソースが現在の World に照らして解釈中の場合、formation_in_progress として一時停止します。プレビューと実行には同じチェックが適用され、古い確認も対象になります。未確認の訂正ソースを推測したり消去したりすることはありません。形成が確定した後、所有者は新たにプレビューを取得します。実行中ジョブのソースすべてを対象とする明示的に確認済みのバッチであれば、引き続きそれらを一括で消去し、遅れて到着するワーカーをフェンスできます。その他のアカウントや、まだ開始されていない無関係なジョブには影響しません。
  • ホストは、既存の model_context_dependencies 境界フィールドまたは link_interaction_dependencies を通じて、実際の想起依存関係をアシスタントのターンに紐付けます。事実を忘れると、依存する対話コンテキストのコピー全体が推移的に消去されますが、元のアプリケーションのチャットには触れません。依存関係の完全なキャプチャがないレガシーコピーは、完全な元の事実/正規化された事実(表現形式と所有者を指す代名詞の正規化を含む)を使ってアカウント内で照合され、同じ忘却プレビューに表示されます。コンテンツを含まないコンテキスト ID と保持されたソース ID は、再生を防ぐ仕組みとして機能し、Portable v4 でも保持されます。どちらの復元順序でも、消去済みのコピーが古い生存コピーより優先されます。エクスポート時に単語がスクラブされることはありません。削除状態を一度も受け取っていないデータベースに復元された単独の過去のバックアップは、この方法では無効化できません。
  • 忘却プレビューは forget_scope を返します。クライアントはこの値を確認済みプランとともに保持し、delete_evidence/delete_world_item の payload.forget_scope に変更せず送信する必要があります。この値は、アカウント、対象、World のリビジョン、影響を受けるコンテキスト ID/コミットメント ID とその内容を紐付けます。無関係な追加項目があっても、確認済みの対象セットは無効になりません。既存の書き込みロック下でスナップショットが変更されていた場合は forget_scope_changed を返して拒否します。トークンなしでコンテキストを変更するレガシー呼び出しは、ロールバックされて forget_scope_required になります。拒否された場合は、再度プレビューを取得して新しい確認とコマンド ID を取得してください。実行時にトークンを黙って更新してはいけません。forget_scope_fence: 1 はこの契約を示します。さらに forget_batch: 1 は、preview_forget と既存の削除コマンドペイロードで additional_targets(1〜31件の正確な {target_kind, target_id} オブジェクト)をサポートします。主対象とこれらの対象は、1つのプレビュー、アカウント、リビジョン、スコープトークン、トランザクション、レシートを共有します。プレビューには結合されたカスケードが表示され、トークンは影響を受けるすべてのコンテキストコピーに加え、対象の順序付きリストにも紐付けられます。スコープの欠落、対象/コンテキストの変更、ソースの拒否があった場合は、バッチ全体がロールバックされます。重複するリビジョンチェーンは一度だけ消去されます。先行するソースによって削除されたオブジェクトを理由に、残りのソースや拒否チェックが省略されないよう、明示された各対象の完全なリビジョンチェーンとソースセットは、カスケード書き込みの前にすべて収集されます。不完全な以前のバッチプレビューの認証情報は拒否されます。新たに完全なプレビューを取得して確認してください。単一対象の認証情報に変更はありません。最初に確認したトークンを保持してください。対象ごとの更新や、ホスト側のキューは不要です。既存の単一対象の呼び出しに変更はありません。同じスコープには evidence.preceding_ai_context のコピーも含まれます。プレビュー項目では、これらは object_kind=evidence_context、item_type=preceding_ai_context として識別されます。成功時のレシートの affected_ids には、それらの Evidence ID も含まれます。コンテキストのみのクリーンアップでは独立した生の Evidence が保持され、プレビューのソース削除用 evidence_ids リストには追加されません。Portable の消去マーカーは、コンテンツを含まない元のコンテキストフィンガープリントを保持します。再利用されたセッション名/エピソード名を持つ別のローカル ID も、このフィンガープリントと照合する必要があり、照合されたすべての ID が同じ推移的カスケードに加わります。
  • 同じソーススナップショットと準備済み検索インデックスに対する想起は決定論的であり、World への書き込みは行いません。 保留中の明示的な一人称の好みの引用は、変更後の値に以前の活動名詞が含まれていなくても、一人称の好みを尋ねる質問に添えることができます。これらは逐語的な暫定ユーザーコンテキストとして保持され、合成されたスロット、置換リンク、正式な World 項目にはなりません。この限定的な代替処理は、三人称の記述、引用されたタスク、質問を候補にしません。既存のアカウント、宛先の権限、経過時間、サイズ、削除の各ゲートは引き続き適用されます。形成が確定すると、既存の経路を通じて正式な想起が保留中の引用に置き換わります。 Python は、現在のソースで裏付けられた自己命名の主張と受理済みの別名を同一人物に紐付けます。以前の中立的な名前が正規名のままでも同様です。この紐付けを確立できるのは、現在有効で宛先から読み取り可能な別名の来歴のみです。I am Martin Mark.、I'm Martin Mark.、我是林晓。 のように、完全で肯定的な自己紹介も対象になります。質問、否定、引用された発言、名前の人物の友人または同僚であるという記述は対象外です。想起時には、ソースから直接得られた一人称の節を紐付けます。対象の欠落、トピックのラベル、所有者の視点だけでは、事実が所有者に関するものだと証明できません。他人を所有格で説明する記述や、第三者の見解の報告は、元の帰属を保持します。曖昧な名前は未解決のままにし、名前と想起される事実にはそれぞれ別個にソース権限を適用します。 Python の想起では、権限のあるローカル CPU の意味候補を優先して順位付けし、エンコーダーが利用できない場合は文字どおりの想起を保持します。さらに、タイムスタンプ付きの正確なユーザーソース引用を最大5件、2600文字以内で別途追加します。ソース権限、人物の分離、削除ゲートが引き続き優先されます。メインメモリの上限は引き続き5項目/600文字です。所有者についての質問には、元の帰属と日付を付けて、現在有効なソース付きプロフィール項目を最大18件/1800文字まで返すこともできます。選択された依存関係 ID には、これらの項目と、引用されたすべてのソース(evidence 参照)が含まれます。忘却時に依存する応答も消去されるよう、ホストはこれらの参照をアシスタントのコンテキスト依存関係に保持します。形成では具体的な詳細と、新しい状態からそのソースで裏付けられた先行状態へのリンクを保持します。忘却では Core のソースコピーと派生コンテキストが削除されます。忘れられたメモリや撤回済み/削除済みのソースが、メイン想起、プロフィール、元ソースの各ウィンドウを通じて復活することはありません。設定と制限を参照してください。 短く自然な訂正は、権限の対象となる先行項目のトピックを通じて取得できます。描画および選択されるのは現在の後継項目のみです。過去の好みの値が表示されるのは、履歴に関する質問、または明示的に保持された人物 ID の照会の場合に限られ、「過去のメモリ」と表示されます。
  • Python の形成では、明示的で長期にわたる目標や計画を、ソースに基づく意図(preference)として扱い、その表現、動機、条件、数量を保持します。計画が実行されたとは断定しません。完了、放棄、状態の変更が報告された場合は、supersedes_cognition_id(または supersedes_relationship_id)で現在の先行項目を指定します。期限の経過や沈黙から進捗を確定することはできません。自然な変更では履歴が保持され、明示的な誤りでは訂正経路が保持されます。アトミックな書き込みの前に、欠落、読み取り不可、他者所有、すでに置換済み、不適合の対象を、上書きとしての置換が拒否します。形成で提示されるのは現在の対象のみです。許可された古い表現は、先行項目のコンテキストとして別途利用できます。 過去の値に戻すと、その値を持つソースに基づく新たな状態発生が作成され、線形な A → B → A の履歴が保たれ、最新の発生が現在の状態になります。古い Evidence が複製されることはありません。決定論的チェックでは、ソースの所有権、別の肯定的な目標節を伴わない、直接否定された目標動詞、明示的な第三者の所有格の目標主体を検査します。条件や開始日は、目標の有効性を損ないません。その他の意味上の適格性は、解釈モデルが判断します。同じ関係性の言い換えでは、ソースにある人物、対象人物、関係性の種類を使って現在の発生を支持し、引用はそれぞれ保持されます。
  • DSH の想起プレビューでは、未完了の形成から得られた、権限でフィルタリングされた正確なユーザー引用 recent_evidence も公開されます。これは正式な World 項目とは分けて保持されます。この読み取り専用のブリッジは、既存の Evidence と会話のライフサイクルを使用し、直近24時間かつ受理済みの32ターンから最大4件の引用/800文字を取得し、形成が正常に完了すると消えます。アシスタントの主張をコピーしたり、削除済みの会話コンテキストを再作成したりすることはありません。ホストはこれらの引用に「暫定」と明示し、正式なメモリと区別して保持する必要があります。短く明示的な訂正では、受理済みの直近4ターン以内であれば、会話をまたいで先行するユーザーの引用を引き継ぐことができます。繰り返された数量や明示的な数値/時間の参照は、次元が一致する必要があります。競合する候補は、correction_status: "ambiguous" とともにまとめて返され、クエリで選択されたトピックに割り当てられることはありません。一意の候補の組み合わせには preceding_text/preceding_evidence_id を使用し、曖昧な候補群には preceding_candidates を使用します。どちらも既存の引用予算内でアトミックに収まります。ターンの完了を契機に形成が直ちに開始されます。キューの容量とフォアグラウンド優先度はホストが管理します。
  • 好み/状態の後継エンティティが示すのは、変更後の値ではなく対象です。値に誤ってトピックのラベルが付けられた場合、この契約に沿って既存の永続的なコンパイラー書き直しが一度だけ行われます。フェンス付き Apply では、元と同じアカウント、同じ対象、ユーザー Evidence の各チェックが引き続き適用されます。
  • 1つの明示的な訂正で、名前付きの複数の Cognition 対象を1つの決定論的な後継項目に置き換えることができます。同一で、コンパイラーが根拠を確認した訂正項目のうち、根拠範囲が同じものだけがその後継項目を共有できます。通常の重複形式、繰り返された対象、無関係なトピックラベルは引き続き拒否されます。各先行項目は、それぞれ固有の訂正台帳と、共有後継項目への遷移を保持します。訂正トピックには、権限の対象となる先行項目の表現を再利用できます。
  • query_jobs は、未解決の明示的な formation_requests も返します。ワーカーの結果が no_change であるだけで、拒否された訂正が正常扱いになることはありません。retry_formation は、リクエスト ID を使用して既存のソース再処理操作を再利用し、拒否済みの終端状態を保持したまま、設定済みのワーカーを起動します。想起プレビューでは、直近の引用の取得期間とは別に、権限でフィルタリングされた pending_corrections が公開されます。ホストはこれにより、古い事実にも訂正保留中のラベルを付けられます。履歴の来歴には successor_provenance が含まれ、どちらの先行項目からでも訂正ソースを説明できます。モデルの来歴に変更はありません。
  • 訂正、撤回、忘却、アーカイブ、ミュート、権限の変更では、永続的なレシートが生成されます。
  • Python の correct_world_item は、オプションの payload.source(message_id、session_id、完全な逐語的 content、一意で逐語的な節/文の quote、および任意の timestamp/preceding_ai_context)を受け付ける場合、correction_source: true を通知します。ホストは実際のメッセージ ID を指定し、モデルは引用のみを選択します。訂正とその後の DSH 境界では、同じソースの起点、Evidence、提示された命題の正規化を再利用します。完全なソース内の独立した事実は、通常の形成で引き続き利用できます。source を指定しない呼び出しでは、既存の明示的編集の契約が維持されます。元メッセージの来歴を送る前に、ホストはこの機能の有無を確認する必要があります。 訂正リクエストの本文はコマンドテーブルにコピーされません。完全なリクエストハッシュが、引き続きリプレイ/競合のチェックを担います。実際の文面は、消去可能な Evidence に保持されます。ソースを再利用する際は、既存の権限と要求された権限のうち、より厳しい方が適用されます。読み取り不能または推論不能なソースは、既存の正式な Apply 経路で拒否されます。 オプションのソースメタデータは、省略または null にしても、既知の既存値は否定されません。実際のメッセージが届く前に受理された訂正では、既存のサポート台帳ペイロードに、保留中のメタデータフィールド名のみが保持されます。後で取り込まれる実際の時刻/コンテキストは、World Job とともにアトミックに紐付けられます。記録時刻を代替値として使っても、明示的なメッセージ時刻の主張にはなりません。一度提供された後に、実際のタイムスタンプやアシスタントコンテキストが競合する場合は引き続き拒否されます。元の内容、メッセージ ID、権限、コマンドのリプレイに関する紐付けも維持されます。
  • Python の World 項目の忘却では、既存のコマンドトランザクション内で、corrects/supersedes の完全なリビジョンチェーンをたどり、過去のソースと派生コピーを消去します。読み取り専用の忘却プレビューでも同じ消去経路を使用し、確認前に完全なカスケードを一覧表示します。ホストはデフォルトで元のチャットメッセージを保持します。
  • 共有アシスタント対話では、元の履歴と明示的なメモリ依存関係が保持されます。モデルへのプロジェクションでは、推移的な再利用を含め、未解決または現在有効でなくなった依存関係が除外されます。履歴へのプロジェクションには、引き続きソース権限が適用されます。
  • Portable バンドルにはバージョンが付与され、検証および適用前の計画が行われ、競合チェックも実施されます。
  • Hermes のホストイベントとユーザーへの表示は、Core のビジネス上の終端状態とは別のものです。

Formation の再起動時の復旧

デフォルトの Python World ワーカーは、ジョブを取得する前に、固有のローカル OS ライフタイムロックを保持します。起動時には、ライフタイムが失われたジョブの取得を直ちに無効にします。ロックを保持しているプロセス(同じプロセス内の別のワーカーを含む)が稼働中であれば、更新可能な 5 分間のリースが維持されます。従来の PID 所有者は、プロセスが存在しないことを明確に確認できた場合にのみ再取得されます。不明な所有者やカスタム所有者については、リースベースの復旧が維持されます。PID の再利用は、従来の所有者に限り、保守的に扱われます。新しい所有者は PID に依存しません。

再起動または正常なシャットダウンでは、元のジョブを返し、中断された取得を払い戻し、トークン/世代を 1 つの SQLite トランザクションで無効にします。保存済みのモデルチェックポイントは再利用されます。World Apply、来歴、リビジョン、終端レコードはアトミックにコミットされるため、中断されたトランザクションはロールバックされ、すでに適用済みのジョブが再取得されることはありません。シャットダウンでは、モデルの応答を待つ前に取得済みのジョブを返します。DSH は、スレッドを最大 250 ms、復旧用書き込みロックを最大 200 ms 待機します。データベースがビジー状態の場合、ホストは Core を終了でき、起動時に取得済みのジョブが復旧されます。

推論の応答が失われた場合に再実行すること(プロバイダーへの課金が再度発生する可能性はありますが、外部ツールによる効果は再発生しません)を選択できるのは、DSH の純粋な解釈ルートのみです。汎用プロセッサーでは、従来どおりディスパッチ状態が不明な場合の終端処理ルールが適用されます。復旧中のジョブが pending/processing の間、復旧情報 restart_recovered/shutdown_recovered は worker.last_error_type に保持されます。これにより、ホストは復旧が進行中であることを表示しつつ、失敗した試行として扱わずに済みます。スキーマのマイグレーションも、リースの短縮もありません。

観測ソースのライフサイクル

DSH RPC v2 は、チャットの取り込みとは独立して、型付きの観測証拠リビジョン、ソース権限の変更、実際の取り下げを受け付けます。リコールでは、ローカルまたはクラウドの宛先に応じて、各ソースとその派生データをフィルタリングできます。TypeScript Core では、同等の観測 DTO とライフサイクルメソッドが提供されます。バージョン、同意、有効性、削除のセマンティクスについては、観測 RPC コントラクトを参照してください。

信頼境界

ローカル優先であっても、データがマシンの外に出ないという意味ではありません。モデルのルート、ストレージパス、同意フロー、認証、認可、暗号化、バックアップ、ログ記録のポリシーは、ホストが選択します。MemoWeft の権限フィールドが制約するのは、形式化された経路です。任意のホストコードがセキュリティ境界になるわけではありません。

MemoWeft は MIT License の下でライセンスされています。

コメント

MCP は初めてですか?

プロトコルの概要から最初のサーバーの導入まで、よくある疑問にまとめて答えます。

AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。