דילוג לתוכן
תפריט

המוצר

פתרונות

אינטגרציות

מפתחים

שפה

פתרונות

זיכרון אחד לסוכנים של כולם

מפעילים שרת זיכרון אחד על מחשב שצוות הפיתוח מנהל. הסוכנים יכולים למצוא החלטות קודמות בפרויקטים שלמשתמשים שלהם יש גישה אליהם.

לפני פיילוט בצוות

מתחילים בפרויקט ללא מידע רגיש ועם מפעיל שיתחזק את השרת, החשבונות, העדכונים והגיבויים. לפני שמזמינים חברי צוות, בודקים מי יכול לקרוא ולכתוב בפרויקט.

התוכנה חינמית. את המחשב והניהול שלו מספקים בעצמכם; ספקי מודלים בענן הם אפשרות נוספת ומחייבים דרך החשבונות שלכם.

תכנון פריסה וגיבויים

שרת אחד שכולם מפנים אליו

קובץ בינארי אחד, עם קובץ SQLite אחד ותיקיית markdown. אין sidecar, אין מסד נתונים וקטורי ואין שום דבר שצריך לסנכרן.

Claude Code

Codex

Cursor

Gemini CLI

שרת ai-memory אחד

ויקי הפרויקט

  • שיתוף ידע בתוך פרויקט

    משתמשים עם גישה לפרויקט יכולים לקרוא את הדפים שלו. סשן Codex של אדם אחד יכול למצוא בעיה שסשן Claude Code של חבר צוות תיעד בשבוע שעבר.

  • גלוי כבר בשאילתה הבאה

    הערה של חבר צוות יכולה להופיע בחיפוש הבא או בתדריך הסשן של משתמשים עם גישה לפרויקט. סשנים פעילים לא מופרעים.

  • כל שילוב של סוכנים

    כל אחד נשאר עם הסוכן שהוא אוהב. כל קריאה לזיכרון מזהה את הפרויקט לפי תיקיית הסשן, כך שסשנים מקבילים לא מתערבבים.

היום הראשון של מפתח חדש

מקבלים מפתח, מפנים את הסוכן אל השרת, ושואלים את הפרויקט מה קרה בו לאחרונה.

קבלת מפתח API

הפניה לשרת

תעדכן אותי

חיפוש בוויקי

היום הראשון

  • שואלים את הפרויקט

    "תעדכן אותי" מחזיר תקציר של העבודה האחרונה. "דיברנו כבר על לוגיקת ה-retry?" מחזיר את דף ההחלטה ואת הסשנים שמאחוריו.

  • הוויקי הוא בסיס ידע חי

    סשנים מוסיפים הערות אוטומטית, ב-markdown עם היסטוריית git. להוראות מחייבות כדאי לשמור תיעוד שעבר בדיקה, ולאמת החלטות חשובות מול המקורות שלהן.

  • משלים את התיעוד הכתוב שלכם

    הדפים נבנים מתוך סשנים ומעוצבים כך שסוכנים ישלפו אותם. משאירים את ה-README ואת מסמכי הארכיטקטורה שנכתבו ביד, ונותנים לוויקי להחזיק את הסיבות ואת הדרכים ללא מוצא.

התקציר הוא טקסט עם ספק LLM ונתונים מובנים בלעדיו. עם --enable-web אפשר לעיין בוויקי בדפדפן; root יכול גם לבדוק הצעות עריכה ממתינות.

ידע משותף, העברות אישיות

העברת מקל (handoff) היא סיכום שמור של עבודה שלא הושלמה. דפי הפרויקט משותפים למשתמשים עם גישה; ההעברה שייכת למי שהשאיר אותה.

הידע משותף

למקל יש בעלים

  • ההעברה הממתינה שלכם מגיעה לסשן הבא שלכם. חבר צוות שמפעיל סוכן באותו repository לא מקבל אותה ולא צורך אותה.
  • מעבירים shared: true כשרוצים לפרסם מקל למי שימשיך את העבודה.
  • שני אנשים שעורכים את אותו דף יוצרים שרשרת גרסאות. הכתיבה המאוחרת הופכת לעדכנית והקודמת נשארת נגישה. אין merge ושום דבר לא נהרס.
  • משבצות אישיות אופציונליות מחזיקות את "על מה אני עובד עכשיו" ולא נכנסות לתדריך הצוותי. הן כבויות כברירת מחדל.
מה אומרים לסוכן
# אישי כברירת מחדל: רק הסשן הבא שלכם מקבל אותו
"שמור הקשר לסשן הבא."

# מפרסמים אחד בכוונה: memory_handoff_begin with shared: true
"שמור handoff משותף, כדי שמי שימשיך את זה מחר יקבל אותו."

סוכנים יכולים לשלוח הודעות בין פרויקטים

הסוכן ב-repository של ה-frontend צריך endpoint מה-repository של ה-API. הוא שולח בקשה שעומדת בפני עצמה ל-inbox של הפרויקט ההוא, והסשן הבא שם מושך אותה. הודעה נתפסת פעם אחת, פרויקט היעד חייב להיות קיים מראש, ו-inbox מחזיק לכל היותר 256 הודעות ממתינות. איך ההודעות עובדות.

חשבונות, מפתחות וביקורת, בלי מסלול בתשלום

יכולות הצוות נמצאות באותו קובץ בינארי ברישיון MIT, כמו כל השאר.

  • חשבון על שם כל אדם

    הוסיפו אנשים בפקודה אחת. השבתת חשבון מסיימת גישה דרך הדפדפן ומשאירה את הדפים. מפתחות API שהמשתמש הנפיק לעצמו יש לבטל בנפרד.

  • מפתחות API לכל מחשב

    כל אדם יכול להחזיק כמה מפתחות עם תוויות, אחד לכל מחשב נייד או סוכן. רוטציה של מפתח דוחה את הישן מיד.

  • ייחוס בכל כתיבה

    כל דף רושם את המחבר שלו, וממשק ה-web מראה מי ערך אותו. זהות המחבר אף פעם לא מסננת מי יכול לקרוא.

  • יומן ביקורת של כל שינוי

    כתיבות נרשמות עם המזהה של המחבר. admission webhooks רואים מי הפועל ויכולים לדחות פעולה.

עדיין לא מתועדים מסך או פקודה לעיון ביומן הביקורת, אז צריך לתכנן על שאילתות מול הטבלה audit_log בקובץ ה-SQLite. מדריך המשתמשים ב-GitHub מכסה תפקידים, כניסה עם סיסמה ורוטציה של מפתחות.

שרת אחד מטפל בכ-700 כתיבות בשנייה, וזה מספיק לכמה מאות סוכנים פעילים. כך זה נמדד.

הקמה לצוות שלכם

דף ההתקנה עובר על זה שלב אחר שלב: מרימים שרת אחד, נותנים מפתח לכל אחד ומכוונים אליו את הסוכנים.

שאלות ותשובות

אפשר לחלוק שרת ai-memory אחד בין כמה מפתחים?

כן. שרת אחד מחזיק את הוויקי והסוכנים מתחברים אליו. פרויקטים פתוחים כברירת מחדל; אפשר להגביל חשבונות משתמשים במסד הנתונים באמצעות הרשאות פרויקט. העברות נשארות אצל מי שיצר אותן, אלא אם שותפו במפורש.

שימוש צוותי דורש מסלול בתשלום?

לא. חשבונות אישיים, מפתחות API, ייחוס ויומן הביקורת הם חלק מהקובץ הבינארי בקוד פתוח.

אפשר להגביל פרויקט או דף לחלק מהמשתמשים?

אפשר להגביל פרויקט שלם לחשבונות משתמשים במסד הנתונים. root, יוצר הפרויקט ומשתמשים שקיבלו הרשאה שומרים על הגישה; הרשאת כתיבה כוללת קריאה. לדפים בודדים בפרויקט אין הרשאות נפרדות. בפריסה עם trusted-proxy יש לאכוף גישה ב-proxy.

בכמה מפתחים שרת אחד יכול לעמוד?

תקרת הכתיבה שנמדדה היא כ-700 כתיבות בשנייה על דיסק מקומי מהיר, והפרויקט מפרש את זה ככמה מאות סוכנים שפעילים במקביל. המספר מודד את שכבת האחסון, ודיסקים ברשת יהיו איטיים יותר.

תנו לסוכנים של הצוות זיכרון אחד.

חינם ובקוד פתוח. חשבונות, מפתחות ויומן הביקורת כלולים.