כשסוכני AI מצטרפים לחדרי Yjs, שלוש הנחות נשברות
הוספת LLM כ-peer מסוג first-class ב-Yjs היא מהלך ארכיטקטוני חכם. עם זאת, היא שוברת את ההנחות השקטות שערמת שיתוף הפעולה (collaboration stack) שלכם מניחה לגבי סימטריה בין ה-peers.
רוב המערכות מניחות שכל ה-peers פועלים במהירות אנושית. כשסוכן AI מייצר 3,000 מילים בדקה, הוא שובר שלושה תחומים מרכזיים: תפוקה (throughput), בעלות על undo, וקצב ה-presence.
הנה איך לתקן אותם.
- מניעת Write Starvation
במודל CRDT, אין שרת מרכזי שיגביל (throttle) את הלקוחות. סוכן יכול להציף את מחזור הסנכרון בכתיבות בלתי פוסקות. זה "מרעיב" משתמשים אנושיים מהחלק שלהם בחלון ההתכנסות (convergence window). הדבר מוביל לעיכוב בסמן (cursor lag) ולעדכונים שאובדים.
הפתרון שייך לשכבת האפליקציה, לא לשכבת ה-transport. השתמשו ב-token bucket בין ה-LLM stream לבין ה-Yjs write כדי להגביל את מהירות הסוכן.
• הגדירו קיבולת עבור פעולות בתור (queued operations). • הגדירו קצב מילוי (refill rate) כדי להשאיר את הסוכן מתחת לסף ה-"הרעבה" של בני אדם.
- בידוד היסטוריית ה-Undo
אם סוכן חולק origin עם משתמש, Ctrl+Z הופך לבלגן. אי אפשר להבחין בין טעות אנושית לבין הצעה של AI.
תנו לסוכן origin משלו. השתמשו ב-UndoManager נפרד עבור הסוכן.
• ה-UndoManager של המשתמש עוקב רק אחרי פעולות אנושיות. • ה-UndoManager של הסוכן מטפל בפעולות ספציפיות ל-AI. • הציגו "דחת הצעה AI" ככפתור UI נפרד במקום לקשור אותו ל-Ctrl+Z ברירת המחדל.
- איחוד (Coalesce) עדכוני Presence
סוכן AI מייצר שינויי מיקום מהר יותר ממה שאדם יכול לראות. שידור (Broadcasting) של כל שינוי בודד יוצר רעש במחזור הרינדור (render cycle) שלכם.
עליכם לנהל את ה-presence של הסוכן בצורה שונה:
• אגרו (Coalesce) עדכוני awareness במרווח זמן קבוע במקום עבור כל פעולה. • הוסיפו שדה type למצב ה-awareness (למשל, type: 'agent'). • השתמשו ב-type הזה כדי להורות לשכבת הרינדור להתייחס לסמן בצורה שונה.
תבנית ה-agent-as-peer היא הדרך הנכונה לבנות. האתגר הוא להפוך את ההנחות שלכם למפורשות. אל תתייחסו להגבלת קצב (rate limiting), בידוד undo ואיחוד presence כמקרי קצה. התייחסו אליהם כדרישות ליבה.
מקור: https://dev.to/norfolkd/when-an-ai-agent-joins-your-yjs-room-three-assumptions-break-50h8