תוכן עניינים
איך סוף סוף קיבלנו אייג'נטים שזוכרים בין בראנצ'ים
הפרויקט Beads של Steve Yegge פותר את בעיית הזיכרון המתמשך שכולנו מתמודדים איתה כשאנחנו עובדים עם AI coding agents. במקום שה-agents ישכחו הכל כשחלון ההקשר מתמלא או כשאנחנו עוברים בראנצ'ים, הריפו Beads שומר את המחשבות של ה-agent ואת תלויות המשימות כקבצים עם ווירסניינג ישירות בתוך ה-Git repository שלנו.
הבעיה שכולנו מכירים טוב מדי
כולנו חווינו את התסכול הזה. אנחנו מתחילים סשן קידוד עם ה-AI agent שלנו, הוא מבין את המשימה, מתקדם יפה, כותב קוד, מעדכן קבצים. ואז 50 אינטראקציות אחר כך, ה-agent שכח לגמרי את ההחלטות הארכיטקטוניות שקיבלנו ביחד לפני חצי שעה. הוא שואל אותנו להסביר דברים שכבר כיסינו. הוא מציע גישות שדחינו במפורש קודם.
אנחנו מנסים פתרונות שונים. אנחנו מדביקים הכל לקבצי markdown כדי לעקוב אחרי התוכנית, אבל הקבצים האלה מתיישנים ויוצאים מסנכרון עם המציאות. אנחנו מסתמכים על היסטוריית צ'אט, אבל זה זמני ולא שורד כשאנחנו סוגרים את הסשן או עוברים לבראנץ' אחר. אנחנו מנסים מסדי נתונים חיצוניים לזיכרון, אבל לשמור אותם מסונכרנים עם מצב ה-Git האמיתי שלנו הופך לבעיה בפני עצמה. ה-agents שלנו בעצם יש להם רק זיכרון לטווח קצר, ואנחנו בסופו של דבר הופכים להיות הדיסק הקשיח החיצוני, מזכירים להם הקשר באופן ידני.
מסתבר שהבעיה המרכזית היא שהזיכרון של ה-agent חי בנפרד מה-versioning של הקוד שלנו. כשאנחנו עושים בראנץ' לקוד כדי לנסות ניסוי, ההקשר של ה-agent לא עושה בראנץ' איתו. כשאנחנו עושים מרג' לקוד מבראנצ'ים שונים, ההבנה של ה-agent לא עוברת מרג'. אנחנו מאבדים את הנימוק מאחורי החלטות, את יחסי התלות בין משימות, ואת ההקשר ההיסטורי של מה ניסינו ולמה.
איך Beads עובד - Git כמסד נתונים לזיכרון
הריפו Beads לוקח גישה שונה מהיסוד על ידי התייחסות ל-Git עצמו כשכבת ההתמדה (persistence layer) לזיכרון של ה-agent. כל המחשבות, התוכניות ותלויות המשימות של ה-agent נשמרות כקבצי JSONL (JSON Lines) בתיקייה `.beads/` בתוך הפרויקט שלנו. תחשבו על זה כמו לתת ל-agent שלנו מחברת מעבדה שעוברת ווירסניינג יחד עם הקוד שהוא מייצר.
כשאנחנו עושים בראנץ' לקוד כדי לנסות פיצ'ר חדש, אנחנו אוטומטית עושים בראנץ' לכל ההקשר וגרף המשימות של ה-agent איתו. כשאנחנו עושים מרג' לשינויי קוד, אנחנו עושים מרג' גם לזיכרון של ה-agent. ההבנה של ה-agent לגבי מה שהוא עושה הופכת לחלק מדרגה ראשונה של ה-repository שלנו, לא מערכת חיצונית נפרדת שאנחנו צריכים לשמור בסנכרון.
התחלה מהירה
ככה אנחנו מתחילים עם Beads:
# התקנת Beads
pip install beads-ai
# אתחול בפרויקט שלנו
cd our-project
beads init
# עכשיו ה-agent יכול ליצור ולעקוב אחרי משימות
beads task create "Implement user authentication"
beads task create "Add password hashing" --parent bd-a1b2
# צפייה בגרף המשימות
beads graphדוגמה אמיתית - ריפקטורינג רב-שלבי
נגיד שאנחנו עושים ריפקטורינג מורכב שמשתרע על כמה סשנים:
# סשן 1: ה-agent יוצר את התוכנית
beads task create "Refactor database layer" --id bd-db01
beads task create "Extract connection pooling" --parent bd-db01
beads task create "Add migration scripts" --parent bd-db01
beads task create "Update all queries" --parent bd-db01 --blocked-by bd-db02
# אנחנו עושים קומיט לתוכנית הזו עם הקוד
git add .beads/
git commit -m "Planning database refactor"
# סשן 2 (למחרת): ה-agent ממשיך בדיוק מאיפה שעצרנו
beads task list --open
# מציג את גרף התלויות המלא, יודע מה חוסם מה
# אנחנו עושים בראנץ' כדי לנסות גישה אחרת
git checkout -b alternative-approach
# התיקייה .beads/ עושה בראנץ' גם - הקשר ה-agent מבודד
# אחר כך אנחנו עושים מרג' חזרה
git checkout main
git merge alternative-approach
# Beads עושה מרג' לעדכוני משימות בלי קונפליקטים הודות ל-IDs מבוססי-hashפיצ'רים טכניים מרכזיים
- מזהים ללא קונפליקטים (Zero-Conflict IDs) - משתמש במזהים מבוססי-hash כמו `bd-a1b2` במקום מספרים רציפים. מסתבר שזה אומר שמספר agents או בראנצ'ים יכולים ליצור משימות במקביל, וכשאנחנו עושים מרג', אין התנגשויות של IDs. תחשבו על זה כמו commit hashes של Git - הם מתוכננים להיות ייחודיים גם כשנוצרים באופן עצמאי.
- גרף תלויות (Dependency Graph) - שומר על יחסי הורה-ילד ותלויות חוסמות בין משימות. ה-agent שלנו באמת מבין שמשימה A חוסמת משימה B, ולא ינסה להשלים את B עד שA תסתיים. הקטע המדליק הוא שזה הרבה יותר מתוחכם מרשימת todo שטוחה.
- מנגנון דחיסה (Compaction) - מה שנקרא 'דעיכת זיכרון סמנטית' (semantic memory decay). משימות סגורות עוברות סיכום כדי לפנות מקום בחלון ההקשר, אבל הנימוק וההחלטות נשמרים בצורה דחוסה. תחשבו על זה כמו איך שהמוח שלנו מגבש זיכרונות לטווח קצר לאחסון לטווח ארוך.
- תשתית בלתי נראית (Invisible Infrastructure) - משתמש בקאש SQLite מקומי לשאילתות מהירות בעוד שמקור האמת נשאר קבצי ה-JSONL. דימון ברקע שומר על הקאש מסונכרן. אנחנו מקבלים ביצועים ברמת מסד נתונים בלי באמת להריץ שרת מסד נתונים.
- מצב חשאי (Stealth Mode) - אנחנו יכולים להשתמש ב-Beads כדי לעקוב אחרי המחשבות וההחלטות שלנו גם כשאנחנו עובדים בלי agent, או לעקוב אחרי מה שה-agent עושה בלי שהוא מודע לזה. זה שימושי לניהול משימות אישי או לאובזרבביליטי.
מתי להשתמש ב-Beads לעומת פתרונות זיכרון אחרים
כלים כמו LangChain memory modules או vector databases הם מעולים לחיפוש סמנטי על שיחות קודמות. הם מצטיינים בשאילתות מסוג "על מה דיברנו לגבי authentication?". הריפו Beads משרת מטרה שונה - זה על שמירת מצב משימות מובנה ויחסי תלות שצריכים לשרוד branching ו-merging.
אנחנו נשתמש ב-Beads כשאנחנו עושים עבודת הנדסה רב-סשנית ומורכבת שבה ה-agent צריך לשמור על תוכנית קוהרנטית לטווח ארוך. אנחנו נשתמש במערכות זיכרון מסורתיות כשאנחנו צריכים retrieval סמנטי על שיחות היסטוריות. בפרקטיקה, אנחנו עשויים להשתמש בשניהם - Beads למעקב אחרי משימות/תלויות, וזיכרון וקטורי להקשר שיחה.
אם אנחנו כבר מרוצים מכלי מעקב משימות חיצוניים כמו Linear או Jira והם משתלבים טוב עם זרימות העבודה של ה-agent שלנו, Beads עשוי להיות יותר מדי. אבל אם אנחנו רוצים שהזיכרון של ה-agent יהיה חלק נייטיב של ה-versioning של בסיס הקוד שלנו, זו גישה משכנעת.
בעיניי - האם אשתמש בזה?
לעניות דעתי, זה פותר פער אמיתי בתשתית ה-AI agents שלנו. הרעיון לעשות versioning לזיכרון של agent יחד עם הקוד הוא אלגנטי ופותר בעיות אמיתיות שאנחנו מתמודדים איתן בעבודה רב-סשנית עם agents. מערכת ה-IDs מבוססי-hash היא חכמה - זו אותה תובנה שגורמת ל-distributed version control לעבוד, מיושמת על ניהול משימות.
היוזקייסים שאני הכי נרגש לגביהם: פרויקטי ריפקטורינג ארוכי-טווח שבהם אנחנו עובדים עם agent על פני ימים או שבועות, בראנצ'ים ניסיוניים שבהם אנחנו רוצים הקשר agent מבודד, ותרחישי code review שבהם אנחנו רוצים לשמר את הנימוק מאחורי שינויים. היכולת לראות את תהליך החשיבה של ה-agent בהיסטוריית ה-Git לצד שינויי הקוד שהוא עשה היא באמת בעלת ערך.
המגבלה שצריך לשים לב אליה: זה דורש משמעת. אנחנו צריכים באמת להשתמש במבנה גרף המשימות במקום פשוט לפרומפט את ה-agent בחופשיות. זה overhead נוסף במהלך הפלואו. אבל לעבודת הנדסה רצינית שבה אנחנו צריכים agents לשמור על תוכניות קוהרנטיות לטווח ארוך, ה-overhead הזה משתלם.
אני מתכנן לנסות את Beads בפרויקט הריפקטורינג הגדול הבא שלנו. היכולת לעשות branch להקשר של agent עם הקוד, ולעשות merge לשניהם ביחד, מרגישה כמו האבסטרקציה הנכונה. קישור לריפו: Beads ב-GitHub