Compartment: ניהול זיכרון מוצפן לסוכני AI באופן מקומי
גלו איך Compartment שומר על זיכרון הסוכן מוצפן במכונה שלכם ללא תקשורת רשת. המדריך מנתח את מודל האיומים, השלכות אובדן מפתח הגישה והתנהגות הכלי בגרסה 4.6.0.
במה שונה Compartment
Compartment הוא מאגר זיכרון לסוכנים (agent memory store) השומר כל רשומה כשהיא מוצפנת על המכונה שיצרה אותה, ולעולם אינו מתקשר עם שירות רשת. שתי בחירות מבדילות אותו משאר התחום של זיכרון לסוכנים. הכספת (vault) היא קובץ חתום יחיד שרק סיסמת הגישה שלכם פותחת, ושלב ה-embedding רץ מקומית, כך שטקסט הזיכרון לעולם אינו נשלח לשום מקום כדי להפוך לוקטור. גרסה 4.6.0 פורסמה ב-10 באוגוסט 2026, הרישיון הוא Apache-2.0, וההתקנה מתבצעת מ-PyPI.
זוהי טענה בנוגע למודל איומים, ולכן מדריך זה מתייחס אליה ככזו. הצפנה במנוחה (encryption at rest) בשילוב עם תכנון לא מקוון (offline design) מגנים על רשימה ספציפית של דברים. הם מותירים דברים אחרים חשופים, ופער זה הוא המקום שבו נמצאות בעיות ה-day two.
מדריך זה עוקב אחר התיעוד והערות השחרור של הפרויקט עצמו, כפי שנקראו ב-11 באוגוסט 2026. Compartment מפיץ יישום שולחן עבודה, פריט בשורת התפריטים ב-macOS ואייקון באזור ההתראות ב-Windows, לצד כלי שורת הפקודה שלו, ולא ניתן להפעיל את הנחיית סיסמת הגישה מתוך קונטיינר אוטומטי. התייחסו למה שבא בהמשך כאל התנהגות מתועדת, לא כאל התנהגות שנמדדה כאן. הריצו זאת על מכונה פנויה לפני שתפקידו בידיו מידע אמיתי כלשהו.
מה באמת מגן הצפנה במנוחה (Encryption at Rest)
הכספת חתומה באמצעות XChaCha20-Poly1305, צופן AEAD (הצפנה מאומתת עם נתונים נלווים), ומשבצות המפתח (keyslots) המכילות את מפתח האב עטופות ב-Argon2id, פונקציית גיבוב סיסמאות שתוכננה להיות איטית ולצרוך זיכרון רב. מכאן נובעים שני דברים. עותק של הקובץ על דיסק גנוב, בגיבוי ישן או מצורף לכרטיס תמיכה הוא רצף בתים ותו לא. בנוסף, ביט אחד שהתהפך גורם לכישלון האימות בעת פתיחת הקובץ, כך ששחיתות נתונים הופכת לשגיאה גלויה במקום לתוצאה שגויה.
וקטורי ההטמעה (embedding vectors) מוצפנים גם הם, וזה חשוב יותר מכפי שזה נשמע. הטמעה אינה גיבוב. מחקרים על היפוך הטמעות הצליחו לשחזר מקטעי טקסט קריאים מתוך הוקטור בלבד, לכן אינדקס וקטורי בטקסט גלוי שיושב לצד מסד נתונים מוצפן קרוב להשארת מסד הנתונים פתוח. Compartment לא כותבת אינדקס בטקסט גלוי לדיסק.
מחיקה היא מחיקה אמיתית. כל רשומה נושאת מפתח משלה, ו-compartment forget --shred משמיד את המפתח הזה, כך שאת הטקסט המוצפן שנותר מאחור לא ניתן לפענח על ידי איש, כולל אתכם. השוו זאת לשורה שנמחקת מקובץ מסד נתונים, שלרוב נשארת קריאה בדפים פנויים עד שמשהו דורס אותה.
עבודה במצב לא מקוון (Offline) היא החצי השני. שום דבר לא מועלה לרשת, לכן אין חשבון ספק שמחזיק את הזיכרונות שלכם ואין מפתח API שעלול לדלוף.
מה Compartment אינו מאבטח
ההגנה נעצרת בגבול ה-vault, וגבול זה קרוב יותר ממה שהוא נראה.
הסוכן קורא טקסט גלוי. תהליך ה-Recall מפענח זיכרון ומעביר את הטקסט לסוכן. אם הסוכן הוא מודל מאוחסן (hosted model), הזיכרון עובר לספק המודל בתוך ה-prompt הבא, בדיוק כמו כל דבר אחר בחלון ההקשר. הצפנה במנוחה (encryption at rest) מגנה על הקובץ, אך אינה מגנה על השליפה. לכן, הכללים ב-מניעת דליפת סודות לסוכני AI אינם משתנים גם כשהמאגר מוצפן: סיסמה שנשמרה כזיכרון היא סיסמה שהגדרת להדבקה אוטומטית בתוך prompt.
vault לא נעול במכונה פעילה הוא פרוץ. הערות האבטחה של הפרויקט מציינות זאת במפורש. בזמן שה-vault לא נעול, מפתח האב הראשי (master key) וקבוצת העבודה נמצאים ב-RAM. Python אינה יכולה להבטיח שחוצץ (buffer) ינוקה, וקובץ swap או תמונת hibernation עלולים לכתוב את הזיכרון הזה לדיסק. תוכנה זדונית שרצה תחת המשתמש שלך לעולם לא צריכה לפצח את הצופן, כיוון שהיא יכולה פשוט לבקש את המידע מה-vault שכבר פתוח.
זהות הקורא היא הצהרתית. ניתן להגביל מרחבי שמות (namespaces) לפי קורא, אך שם הקורא מגיע מתהליך המארח. לכן, מארח שמשקר לגבי שמו מקבל את ההרשאות שהוא טוען להן. הרשאות מרחב שמות הן כלי ארגוני, ולא גבול אבטחה כנגד תוכנה מקומית עוינת.
גריסה (shredding) אינה מגיעה לעותקים. forget --shred משמיד את המפתח בתוך הקובץ הנוכחי. גיבוי שבוצע לפני הגריסה עדיין מכיל את הרשומה, ועדיין ניתן לפתיחה באמצעות סיסמת הגישה של אותו יום.
סיסמת גישה חלשה מסיימת את הדיון. Argon2id הופך כל ניחוש ליקר מבחינה חישובית, אך הוא אינו מגן על סיסמה שמופיעה ברשימת מילים נפוצות.
התקנת Compartment מגרסה נעולה
Compartment דורש Python 3.11 או גרסה חדשה יותר. הפרויקט מתקדם במהירות, עם שלושים גרסאות ב-PyPI נכון ל-10 באוגוסט 2026, לכן יש לנעול את הגרסה במקום להסתמך על הגרסה העדכנית ביותר ביום ההתקנה.
python3 --version
pip install "compartment==4.6.0"
compartment --version
compartment initcompartment --version אמור להציג את הגרסה שנעלת. אם ה-shell משיב compartment: command not found, ספריית ההתקנה אינה ב-PATH שלך; ברוב המערכות, הספרייה הזו היא ~/.local/bin. pipx install compartment==4.6.0 ו-uv tool install compartment==4.6.0 מונעים זאת על ידי ניהול נתיבים עצמאי.
compartment init מבקש סיסמה פעמיים ואינו מציג דבר על המסך. סיסמה זו היא המפתח היחיד. הפרויקט אינו מייצר סיסמה או ביטוי שחזור, וזאת בכוונה: אין שום פרט זיהוי שהתוכנה מחזיקה ואתה לא.
בדוק את התוצאה לפני חיבור רכיבים כלשהם אליה.
compartment statusכספת תקינה מדווחת שהיא פתוחה (unlocked). אם היא מדווחת שהיא נעולה (locked), הרץ את compartment unlock והזן את הסיסמה. אתחול נועל אותה מחדש, כיוון שפרט הזיהוי ששומר עליה פתוחה תלוי בסוד שנוצר בכל עליית מערכת. ב-macOS, הפקודה compartment unlock --keychain מאפשרת הישרדות לאחר אתחול על ידי שמירת פרט הזיהוי ב-keychain של המערכת.
היכן נשמר הנתונים בפועל
ה-vault המוגדר כברירת מחדל הוא ~/.compartment/memory.vault. ניתן להפנות למיקום אחר באמצעות --vault PATH בכל פקודה, או באמצעות משתנה הסביבה COMPARTMENT_VAULT.
קובץ יחיד זה מהווה את כלל המאגר. הוא נפתח בכותרת המכילה את גרסת הפורמט ואת ה-keyslots של Argon2id, לאחר מכן מגיע ה-payload המוצפן, ולבסוף רשומות יומן (journal entries) שמתווספות ככל שנוצרים זיכרונות חדשים. כל רשומת יומן מתוחמת על ידי האורך שלה ועל ידי CRC (בדיקת יתירות מחזורית) של אורך זה, כך שפעולת כתיבה שנקטעה עקב קריסה מזוהה כרשומה קטועה ולא נקראת כנתונים תקינים. תהליך הדחיסה (compaction) מבצע סריאליזציה ל-vault, כותב קובץ זמני, מבצע לו fsync, ולאחר מכן משנה את שמו למיקום הקובץ המקורי; המשמעות היא שקורא לעולם לא ייתקל ב-vault שנכתב בחלקו בלבד.
התוצאה המועילה: סקריפט גיבוי מעתיק נתיב אחד בלבד. התוצאה הלא נוחה: לא ניתן להריץ עליו grep, ולא ניתן לתקן אותו בעורך טקסט. אם ברצונכם בזיכרון שניתן לקרוא באמצעות cat ולבצע לו commit ל-git, ה-קבצי הזיכרון המקומיים הפשוטים של Memmy מציעים את הפשרה ההפוכה. שתי הגישות סבירות, בהתאם לשאלה האם האיום שממנו אתם חוששים הוא גניבת מחשב נייד או כלי עבודה שמתקלקל.
הפקודה compartment uninstall מסירה את התוכנה אך שומרת על ה-vault. השתמשו ב---purge רק כאשר אתם מתכוונים לכך במפורש.
חיבור לסוכן
פקודה אחת מחברת לקוח נתמך.
compartment integrate --list
compartment integrate claudeעבור Claude Code, הפקודה כותבת רכיב שרת MCP (פרוטוקול הקשר מודל) ו־hook מסוג PostToolUse לתוך ~/.claude/settings.json, תוך גיבוי הקובץ תחילה, מתקינה מיומנות /compartmentalize תחת ~/.claude/skills/, ומוסיפה בלוק מנוהל ל־~/.claude/CLAUDE.md המורה לסוכן ש-Compartment מחליף את הזיכרון מבוסס הקבצים שבו השתמש עד כה. יש לאשר את שני החלקים:
compartment hook status
compartment recentכדי לרשום את השרת באופן ידני:
claude mcp add --scope user compartment -- \
compartment --vault ~/.compartment/memory.vault --caller claude-code serveכל מארח אחר התומך ב-MCP יכול להשתמש באותו שרת עם שם קורא משלו.
{ "mcpServers": { "compartment": {
"command": "compartment",
"args": ["--vault", "/path/to/memory.vault",
"--caller", "your-agent-name", "serve"] } } }יש להעניק לכל מארח ערך --caller שונה. זהו התווית שמתועדת בלוג הביקורת והמפתח שלפיו נכתבות הרשאות ה-namespace, לכן שם משותף הופך את שניהם לחסרי תועלת.
אם Claude Code כבר כתב עובדות לקובצי הזיכרון שלו, compartment import-claude --dry-run יציג מה יועבר לפני ביצוע הפעולה. קראו תחילה את מה Claude Code שומר בקובצי הזיכרון שלו, כיוון שייבוא של הערות שנצברו במשך שנה לתוך כספת חדשה הוא הדרך שבה מאגר זיכרון מתמלא בפריטים שאף אחד לא התכוון לשמור.
מהי מהירותו של כספת מקומית
אלו הנתונים שהפרויקט מפרסם עבור כספת בגודל אישי. הם מגיעים מהתיעוד שלו, ולא מהרצה שבוצעה כאן.
The data behind this chart
[
{
"label": "Store one memory, end to end",
"latency_ms": 40
},
{
"label": "Embed one memory, bundled model",
"latency_ms": 25
},
{
"label": "Hybrid search, median",
"latency_ms": 11.6
},
{
"label": "Vector search at 20k records, p95",
"latency_ms": 0.68
}
]אחסון זיכרון אחד מוערך ב-40 מילי-שניות, וחיפוש וקטורי בקרב עשרים אלף רשומות מוערך ב-0.68 מילי-שניות עבור האחוזון ה-95. הטיעון של הפרויקט לשמירה על זיכרון מקומי הוא אריתמטי: סבב תקשורת רשת יחיד (round trip) ל-API של זיכרון מאוחסן עולה לעיתים קרובות יותר מהחציון של 11.6 מילי-שניות של חיפוש היברידי מלא כאן.
שני פרטי תכנון מסבירים את נתוני החיפוש. מתחת לעשרים אלף רשומות, Compartment משווה את השאילתה מול כל וקטור, כך שהשליפה מדויקת מעצם המבנה ולא מקורבת. מעל כמות זו, המערכת עוברת לשימוש ב-HNSW (hierarchical navigable small world), אינדקס מקורב שמקריב מעט דיוק בשליפה לטובת מהירות. הכספת גם מתעדת את ה-hash מסוג SHA-256 של מודל ה-embedding ומסרבת להיפתח תחת מודל שונה, כיוון שניתן להשוות וקטורים משני מודלים שונים ללא הופעת שגיאה, אך התוצאות שמתקבלות יהיו חסרות משמעות.
גיבויים, והעותק שתוכלו לפתוח גם בשנה הבאה
כספת נעולה היא קובץ נייד אחד, לכן העברתה היא פעולת העתקה פשוטה.
compartment lock
scp ~/.compartment/memory.vault other-machine:
compartment --vault memory.vault unlockנעלו את הכספת תחילה. העתקה בזמן שהסוכן כותב עלולה לתפוס רשומה ביומן באמצע תהליך הוספה; אף ש־CRC framing מאפשר לקורא לדלג על אותו מקטע קטוע, הזיכרון שבתוכו אובד. compartment lock --sign חותם את הקובץ באמצעות manifest מסוג Ed25519, כך שהמכונה המקבלת יכולה לוודא שהעותק הגיע בשלמותו מבלי להחזיק בסיסמה.
מכיוון שהקובץ כבר חתום, אחסון ענן רגיל הוא יעד קביל עבורו. זו הנקודה שבה הצפנה במנוחה (encryption at rest) משתלמת ישירות: יעד הגיבוי לעולם אינו רואה את הזיכרון.
שתי אזהרות. פעולת Shredding אינה מגיעה לגיבויים; רשומה שהצפנתם בשיטת shred היום תישאר קריאה בעותק של השבוע שעבר לכל מי שמחזיק בסיסמה של השבוע שעבר. כמו כן, compartment export --plaintext כותב את כל הכספת ללא הצפנה; זהו הכלי הנכון למעבר למערכת אחרת, אך הקובץ הלא נכון להשאיר בתוך ~/Downloads.
שמרו מספר מצומצם של עותקים וציינו עליהם תאריכים. מאגר זיכרונות הופך לנטל ברגע שאיש אינו מנקה אותו, וזהו הטיעון ב-מדוע זיכרונות סוכן ישנים מרעילים בשקט את השליפה.
ניהול מפתחות, החלפה (rotation) ואימות דו-שלבי
compartment rekey
compartment 2fa enable
compartment 2fa statusrekey משנה את סיסמת הגישה על ידי הצפנה מחדש של מפתח המאסטר בתוך ה-keyslot של הקובץ הנוכחי. עותקים ישנים שומרים על הסיסמה הישנה, כיוון שהבתים הללו נחתמו לפני השינוי ואין מנגנון שחוזר אחורה לערוך אותם. בצעו החלפה גם לעותקים, או קבלו את העובדה שסיסמה שבוטלה עדיין פותחת קבצים מסוימים.
2fa enable מוסיף קובץ מפתח (keyfile) כגורם אימות שני, המשולב עם סיסמת הגישה במהלך גזירת המפתח, כך ששניהם נדרשים כדי לפתוח את הכספת. פעולה זו גם מכפילה את כמות הפריטים שניתן לאבד. שמרו את קובץ המפתח מחוץ למכונה שמחזיקה את הכספת.
עבור סקריפטים ו-CI (אינטגרציה רציפה), ניתן להעביר את סיסמת הגישה דרך משתנה הסביבה COMPARTMENT_PASSPHRASE, בעוד ש-unlock --passphrase-stdin קורא אותה מתוך צינור (pipe). העדיפו שימוש בצינור. משתנה סביבה הוא קריא על ידי תהליכים אחרים השייכים לאותו משתמש, והוא נוטה להופיע בלוגים של משימות.
היסטוריית הביקורת משורשרת באמצעות hash, ו-compartment audit verify סורק אותה ומדווח על הקישור השבור הראשון. הריצו פקודה זו לאחר כל שחזור, שכן זהו השלב שבו קובץ שנקטע בשקט חושף את עצמו.
מה קורה כשמאבדים את סיסמת הגישה
שום דבר לא קורה, וזהו התכנון המקורי. אין אפשרות לאיפוס, אין ביטוי שחזור, ואין כתובת לפנות אליה, כיוון שלא קיים עותק של המפתח מחוץ לזיכרון שלך ולקובץ המפתח האופציונלי. הכספת נשארת קובץ של בתים שנראים אקראיים.
לכן, תוכנית השחזור אינה מיועדת לכספת. היא מיועדת לסיסמת הגישה. תעדו אותה במנהל סיסמאות ביום שבו אתם מריצים את compartment init. לאחר מכן בצעו בדיקה: נעלו את הכספת, פתחו אותה באמצעות מה שרשמתם בלבד, ורק לאחר שזה עובד, תנו לסוכן להתחיל למלא אותה.
Compartment או שרת זיכרון
Compartment מתוכנן כמכונה בודדת. שיתוף נתונים משמעו העתקת הקובץ הנעול, או ייצוא וייבוא שלו. אין תמיכה בכתיבה בו-זמנית, לכן אם מחשב נייד ותחנת עבודה יצביעו על אותו קובץ, הם ידרסו זה את עבודתו של זה.
כאשר כמה מכונות זקוקות לאותו זיכרון בו-זמנית, מדובר בבעיה של שרת. המדריך שרת זיכרון Mem0 בהתקנה עצמית על גבי VPS מספק לכך מענה: נקודת קצה אחת, לקוחות רבים, וזיכרון ששורד מעבר לשימוש במחשב הנייד. יש לציין את העלות בבירור. השרת מריץ תהליך שיכול לקרוא את הנתונים שהוא מאחסן, לכן מודל האיומים שלכם כולל כעת את ה-VPS ואת כל מי שיכול לגשת ל-API שלו.
בחרו בהתאם לאובדן שאתם באמת חוששים ממנו. אם החשש הוא מגניבת מחשב נייד או מספק שקורא את ההערות שלכם, הכספת המקומית המוצפנת היא הפתרון החזק יותר. אם החשש הוא מסוכן ששוכח הכל ברגע שאתם מחליפים מכונה, השרת הוא הפתרון המתאים.
FAQ
מה ההצפנה של Compartment מגינה עליו בפועל?
היא מגינה על הקובץ. הכספת חתומה ב-XChaCha20-Poly1305, חריצי המפתחות (keyslots) עטופים ב-Argon2id, וגם וקטורי ההטמעה (embedding vectors) מוצפנים. לכן, דיסק שנגנב או גיבוי ישן מכילים רק בתים ללא כל תוכן קריא. ההגנה אינה תקפה לכספת פתוחה במכונה פעילה, כיוון שמפתח המאסטר נמצא ב-RAM כל עוד הכספת פתוחה. כמו כן, ההצפנה אינה שולטת באופן שבו סוכן (agent) משתמש בזיכרון לאחר שהשליפה מחזירה אותו כטקסט גלוי.
אם Compartment במצב לא מקוון, האם הזיכרונות שלי חסויים מפני ספק המודל שלי?
רק עד לרגע השליפה. האחסון והחיפוש מתבצעים ללא רשת, ומודל ההטמעה רץ מקומית, כך ששום מידע לא עוזב את המכונה בזמן הכתיבה. בזמן הקריאה, הסוכן מקבל טקסט גלוי; אם מדובר במודל מאוחסן (hosted model), הזיכרון נכנס ל-prompt ועובר לספק כמו שאר חלון ההקשר (context window). לעולם אין לשמור פרטי הזדהות כזיכרון.
מה קורה אם אאבד את סיסמת ה-Compartment שלי?
הכספת אינה ניתנת לשחזור, וזה מכוון. Compartment אינה מייצרת seed או ביטוי שחזור, ואינה מחזיקה שום פרט הזדהות שאינו אצלך, לכן אין מה לאפס. שמרו את הסיסמה במנהל סיסמאות, החזיקו כל קובץ מפתח ל-2FA מחוץ למכונה שבה מאוחסנת הכספת, וודאו שאתם מצליחים לפתוח עותק לפני שאתם שומרים בכספת מידע שחשוב לכם.
האם שתי מכונות יכולות לשתף כספת Compartment אחת?
לא בו-זמנית. כספת נעולה היא קובץ נייד יחיד, והדרך המתועדת היא לנעול אותה, להעתיק אותה, ואז לפתוח אותה במכונה השנייה באמצעות --vault. אין תמיכה בגישה מקבילית, לכן כתיבה של שתי מכונות לאותו קובץ תגרום לאובדן זיכרונות. השתמשו בשרת זיכרון כאשר יש צורך בכך.