המדריך המלא ל-שכבת האוטונומיה, רשת שעובדת לבד
איך גורמים לרשת סוכנים לפעול לבד 24/7, בבטחה, עם אישור-אנושי לכל מהלך מסוכן
רשת סוכנים שמדברת זה עם זה זה התחלה. רשת שגם פועלת לבד, מקבלת משימה, מבצעת, מאמתת שהצליחה, ומתקנת את עצמה כשמשהו נשבר, זו שכבת האוטונומיה. המדריך הזה מתאר את הספינה החיה שרצה אצלי (אלעד) על שרת פרטי: תור-משימות עמיד (SQLite) שמחזיק כל בקשה גם אם המחשב כבוי, Worker שמושך משימה אחת, מבצע, ומת (קל לדבג, אין דליפות זיכרון), Firewall שחוסם כל פעולה מסוכנת עד אישור-אנושי בלחיצת-כפתור, שכבת אימות-על-תוצאה (verify-on-result) שבודקת שהמשימה באמת הצליחה ולא רק 'רצה', יומן-תוצאות (outcome ledger) שמודד כל מהלך, אורקל (Oracle) ששבועית מבקר את עצמו וכותב הצעות-תיקון, ובשכבה הגבוהה ביותר, מבצע ריפוי-עצמי שמיישם תיקון בעצמו (כבוי כברירת-מחדל, נדלק רק כשסומכים עליו). מעל הכל יושב שער-מודלים (gateway) עם תקרת-עלות של 5 דולר ליום, ו-CRM + דשבורד שמראים את כל זה במבט אחד. אצלכם, אותו דפוס בדיוק הופך אוסף בוטים שמחכים להוראה למערכת שעובדת בשבילכם בזמן שאתם ישנים.
מה המדריך מכסה
מה זה שכבת-אוטונומיה?
ההבדל בין סוכן שמגיב לבין רשת שיוזמת ומבצעת לבד
אוטונומיה היא השכבה שגורמת לרשת הסוכנים לפעול מעצמה, לקבל משימה, לבצע, לאמת, ולתקן, בלי שאדם יעמוד מאחורי כל צעד. בניגוד ל-תזמור (שעוסק באיך סוכנים מתאמים ביניהם), האוטונומיה עוסקת באיך הרשת פועלת לבד בבטחה. שלושת העמודים שלה: עמידוּת (התור מחזיק משימות גם כשהכל כבוי), אמינוּת (אימות-על-תוצאה במקום 'הפקודה רצה'), ובטיחוּת (Firewall שעוצר כל מהלך מסוכן עד אישור-אנושי).
תור-המשימות + Worker, הלב הפועם
משימה נכנסת לתור עמיד, Worker מושך אחת, מבצע, ומת
הלב של האוטונומיה הוא תור-משימות עמיד: כל בקשה, מאלעד בוואטסאפ, מסוכן אחר, מ-cron מתוזמן, נכתבת לתור על השרת (אצלי SQLite, פשוט וחסין). מעליו רץ Worker שמופעל כל דקה (systemd timer): הוא מושך את המשימה הבאה, מבצע אותה, מדווח תוצאה, ומת. הדפוס של 'תהליך חד-פעמי' (pull→execute→die) הוא ההפך מ-bot ארוך-חיים: קל לדבג, אין דליפות זיכרון, וכל ריצה מתחילה נקייה.
Firewall + אישור-בקליק, אוטונומיה עם בלם
פעולה בטוחה רצה לבד; מהלך מסוכן ממתין לאישור-אנושי
הפחד הגדול מסוכן אוטונומי הוא 'מה אם יעשה משהו בלתי-הפיך?'. ה-Firewall הוא התשובה: לכל סוג-משימה יש דירוג-בטיחות. משימה בטוחה (לסכם, לסווג, לדווח, לקרוא) רצה לבד מיד. משימה מסוכנת (לשלוח מייל ללקוח, לפרסם פוסט, לבצע תשלום, למחוק) נחסמת, היא נכנסת ל-תור-אישורים, ואלעד מקבל התראה ומאשר או דוחה בלחיצת-כפתור אחת. כך מקבלים אוטונומיה אמיתית בלי לוותר על השליטה.
אימות-על-תוצאה, 'רצה' זה לא 'הצליח'
שלב נפרד שמוכיח שהמשימה באמת השיגה את היעד
הטעות הקלאסית באוטומציה: להניח ש'הפקודה לא קרסה' = 'המשימה הצליחה'. בפועל הרבה כשלים שקטים, מייל שנשלח לכתובת שגויה, פוסט שעלה ריק, סקריפט שרץ אבל לא עשה כלום. שכבת verify-on-result מפרידה בין ביצוע לבין אימות: אחרי שה-Worker מבצע, שלב נפרד בודק ראיה אובייקטיבית שהיעד הושג. רק אם האימות עובר, המשימה מסומנת 'בוצע'. אחרת, 'נכשל', והיא חוזרת לטיפול.
שומר-התוצר, 'רץ' זה לא 'ייצר'
שכבת-שמירה שבודקת שכל עבודה מתוזמנת באמת ייצרה תוצר
אימות-על-תוצאה בודק משימה אחת ברגע שהיא רצה. אבל יש כשל ערמומי יותר: עבודה מתוזמנת שרצה כל יום, מסיימת בלי שגיאה, ולא מייצרת שום דבר. הלוג ירוק, המערכת 'בריאה', ובפועל אף קובץ לא נכתב ואף רשומה לא נוצרה. שומר-התוצר (output-guardian) הוא שכבת-שמירה נפרדת שסוגרת בדיוק את החור הזה: הוא עובר על כל העבודות המתוזמנות ובודק לא 'האם התהליך רץ?' אלא 'האם נוצר תוצר אמיתי?', קובץ שקיים, רשומה שנכתבה, דוח שנשלח. אם עבודה 'רצה בהצלחה' אבל התוצר חסר, נשלחת התראה. יש לזה מדריך מלא משלו: שומר-התוצר.
יומן-התוצאות + מפת-המערכת, מודדים כל מהלך
מקור-אמת אחד שמודד מה עבד, מה נכשל, וכמה זה עלה
כדי שמערכת תשתפר היא צריכה לדעת איך היא מתפקדת. יומן-התוצאות (outcome ledger) רושם כל מהלך: מה בוצע, האם האימות עבר, כמה זמן לקח, כמה עלה. מעליו יושבת מפת-המערכת (system-map), מקור-אמת מוצהר אחד שמתאר כל רכיב ברשת, מי הבעלים שלו, ומה דירוג-הבטיחות שלו. שילוב השניים נותן את ה-'אות-shelfware': רכיב שהוכרז אבל אף פעם לא רץ בהצלחה, דגל מיידי שמשהו לא מחובר.
ריפוי-עצמי, המערכת מבקרת ומתקנת את עצמה
אורקל כותב הצעת-תיקון; בשכבה הגבוהה, מבצע מיישם אותה לבד
השכבה המתקדמת ביותר: מערכת שמתחזקת את עצמה. אצלי זה עובד בכמה דרגות. דרגה ראשונה, האורקל (Aurora) עובר שבועית על היומן והמפה, מזהה סחיפה וכשלים, וכותב הצעת-תיקון (fix_proposal) שמגיעה לאישור-אנושי. דרגה גבוהה יותר, מבצע ריפוי-עצמי (apply_remediation) שיכול ליישם תיקון בעצמו, אבל הוא כבוי כברירת-מחדל ונדלק רק כשסומכים עליו לסוג-תקלה מסוים. במקביל, שומר-ידע (brain_maintain) מתחזק את מקור-האמת, index, פערים, וקוהרנטיות, כך שגם המוח-הארגוני לא נרקב.
שער-המודלים + בקרת-עלות, אוטונומיה לא חופשייה
כל קריאת-LLM עוברת שער אחד עם תקרה יומית של $5
מערכת שפועלת לבד 24/7 יכולה גם לשרוף כסף לבד 24/7. שער-המודלים (gateway) הוא נקודת-מעבר אחת לכל קריאות-ה-LLM ברשת: הוא בוחר מודל (חינמי קודם, Gemini/מקומי, מודל-חזק רק כשצריך), מודד כל קריאה, ואוכף תקרת-עלות יומית (אצלי 5 דולר). אם מתקרבים לתקרה, מורידים למודלים זולים יותר או עוצרים פעולות לא-קריטיות. כך אוטונומיה נשארת בת-קיימא כלכלית.
אינטגרציה, איך מאמצים את זה אצלכם
מתחילים מתור פשוט, מוסיפים שכבת-בטיחות רק כשנותנים 'ידיים'
כמו בכל המדריכים, לא בונים את כל שכבת-האוטונומיה ביום הראשון. הסדר חשוב: קודם תור + Worker (עמידוּת), אחר-כך Firewall ברגע שהסוכן מקבל 'ידיים' אמיתיות, אחר-כך אימות ומדידה, ורק בסוף, ריפוי-עצמי. כל שכבה נכנסת בטוחה-כברירת-מחדל ונדלקת בהדרגה. הכל מתחבר לשאר הרשת: ה-Delegator הוא שער-הכניסה, ה-דשבורד מראה מצב-חי + כפתורי-אישור, וה-תזמור מספק את שכבת-התיאום שמעליה הכל יושב.
