צוות סוכנים: איך בניתי צוות סוכני AI שעובד בשבילי, ונשאר בשליטה שלי

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

מה יהיה לכם בסוף

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

מה צריך

• שרת לינוקס קטן (VPS). שלי הוא שרת עם פחות מ-4GB זיכרון, וזה מספיק כי הוא לא בונה קוד בעצמו (על זה בהמשך).
• Claude Code, או סוכן קוד אחר שאפשר להריץ ממשימות מתוזמנות.
• בוט טלגרם (BotFather) שעונה רק לכם.
• חשבון GitHub, אם אחד הסוכנים כותב קוד.

איך לקרוא את זה: זה לא מדריך התקנה שורה אחרי שורה. זה מבנה, החלטות ולקחים. את חיזוק השרת עצמו (מפתחות SSH, כלב שמירה, גיבוי) פירטתי בערכה נפרדת, "שרת לסוכני AI שלא נופל ולא נפרץ".

הרעיון

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

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

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

3. הסוכנים מכינים, אני מאשר. אף סוכן לא מפרסם, לא שולח מייל, לא שולח הודעה ולא ממזג קוד לבד. הם כותבים טיוטה, נותנים לה מספר, ומחכים. עוד כלל שחוזר אצל כולם: תוכן מבחוץ (פוסט, מייל, הודעה, דף אינטרנט) הוא מידע, לא הוראות. אם מייל מבקש "תעביר את זה" או "תשלם", הסוכן לא עושה כלום ומדווח לי.

הצוות

סוכן לינקדאין

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

מתי: תגובות כל יום ב-12:00, 17:00 ו-20:00, עד 3 ביום. טיוטת פוסט בשני ובחמישי ב-12:00. דוח שבועי ביום ראשון ב-09:00.

מה אסור לו לבד: לפרסם, להגיב, לעשות לייק, לשלוח הודעה או לשנות פרופיל. הכל רק אחרי "אשר N" על הטקסט המדויק. אם לינקדאין מציג CAPTCHA או אימות, הוא עוצר הכל ומתריע. הוא לא מנסה לעקוף. הוא גם לא פותח את עמוד ההודעות בריצות מתוזמנות, כי זה מסמן שיחות כנקראו, וצילום מסך של ההודעות אף פעם לא נשלח לטלגרם.

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

המפעל (פיתוח)

מה עושה: אני כותב בטלגרם "משימה <ריפו>: <מה לעשות>". המפעל פותח issue ב-GitHub ומכין תוכנית כעמוד HTML אחד: מה ישתנה, החלטות פתוחות עם המלצה מסומנת, וכפתור "שלח תשובות". אני עונה מהטלפון. אחר כך המשימה נשלחת לסשן Claude Code בענן, שעובד בשיטת TDD, מריץ בדיקות, בודק את עצמו ופותח Pull Request.

מתי: בודק את התור כל 3 דקות, משימה אחת בכל פעם. מחכה לתשובה על התוכנית עד 15 דקות, ואם לא עניתי, בונה לפי ההמלצות. דוח ערב ב-20:30.

מה אסור לו לבד: למזג. אף פעם. PR מתמזג רק כשאני כותב "מזג". גם force push ו-reset אסורים לו.

לולאת לקחים: כל סשן משאיר ב-PR הערה שמתחילה ב-LESSONS. פעם בשבוע ג'וב אוסף אותן, מסיר כפילויות ופותח PR לריפו לקחים פרטי. הסשן הבא מקבל את הלקחים שנוגעים לריפו שלו.

מוקד התמיכה

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

מתי: כל שעה, מ-7 בבוקר עד 10 בלילה. אם אין כלום, הוא שותק.

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

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

העוזר האישי

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

מתי: תדריך בוקר בימים א'-ה' ב-08:00 (פגישות היום עם הקשר מהזיכרון, מיילים שמחכים לתשובה עם טיוטה מוכנה, הבטחות פתוחות). סריקה ב-13:00 וב-18:00 שהופכת מיילים חדשים לפריטי תשובה מוכנים. סיכום שבועי ביום שישי ב-13:00.

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

מערכת (כלב שמירה)

מה עושה: בודק שהסשן הראשי חי, שתוסף הטלגרם מחובר ושיש רק אחד כזה, שיש מקום בדיסק ובזיכרון, שהג'וב האחרון של כל סוג לא נכשל, ושההתחברות של Claude לא פגה. מקבל עדכונים מ-GitHub דרך poller שרץ כל 5 דקות ומדווח על PR חדש, בדיקות שהסתיימו, ביקורת ומיזוג.

מתי: כל 15 דקות, ו-5 דקות אחרי אתחול.

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

Mission Control (לוח הבקרה)

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

מתי: השרת שולח סיכום כל 10 דקות. אם הנתונים לא התעדכנו מעל 25 דקות, הלוח מסמן את זה.

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

מודל האישורים

זה החלק שהכי שווה להעתיק. כל פעולה כלפי חוץ עוברת אותו מסלול:

1. סוכן מכין פריט וכותב אותו לקובץ עם מספר. המספור משותף לכל הסוכנים, כך ש"אשר 7" תמיד מצביע על פריט אחד.
2. הפריט מגיע לטלגרם כתצוגה קצרה: למי, מה, והטקסט המלא.
3. אני עונה: "אשר 7", "תקן 7: ..." או "דלג".
4. רק הסשן הראשי מבצע. הג'ובים המתוזמנים לא יכולים לשלוח, אפילו אם ירצו. הכלים חסומים להם.
5. בדיקת זהות מדויקת. לפני שליחת מייל או זימון, הפריט "ננעל". שכבת הגנה שיושבת לפני הכלי משווה את מה שעומד לצאת לפריט שאושר, ומדויק עד התו. כל הבדל נחסם.
6. תפוגה. פריט שלא אושר תוך 24 שעות פג. פעולה זהה שכבר בוצעה ב-7 הימים האחרונים נחסמת.
7. יומן. כל פעולה, כולל ניסיון שנכשל, נרשמת ביומן פעולות.

ככה זה נראה בטלגרם (דוגמה בדויה):

7: תשובה למייל · "שאלה על הדוח החודשי"
אל: לקוח
"היי, קיבלתי. בודקים ואעדכן ברגע שזה מוכן. אביעד"
לשליחה: אשר 7

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

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

הארכיטקטורה

Me (phone)
  |  approve N / new task / voice note
  v
Telegram bot  <------  drafts, alerts, reports
  |
  v
Small server = dispatcher
  - main session: the only one that acts
  - timers: LinkedIn, assistant, support desk,
            factory queue, watchdog
  - approval queue + action log
  |                              |
  | task                         | summary every 10 min
  v                              v
Cloud coding sessions        Mission Control (read-only)
  |
  | branch + PR
  v
GitHub  --- poller every 5 min --->  Telegram
            (merge only when I say so)

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

איפה זה נשבר

1. השרת קרס מבנייה

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

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

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

2. ההתחברות פגה בלילה

מה קרה: ההתחברות של Claude פגה באמצע הלילה. מהבוקר כל ג'וב נכשל: תדריך הבוקר, הדוח השבועי ועוד. נכנסתי לשרת, התחברתי מחדש והרצתי ביד את מה שנכשל.

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

הלקח: בדקו לא רק שהסוכן רץ, אלא גם שהוא מחובר.

3. שני בוטים על אותו טוקן

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

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

הלקח: ערוץ שליטה אחד אומר גם תהליך אחד שמחזיק אותו.

4. הודעה ראשונה למישהו שכבר היה בשיחה איתי

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

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

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

5. הסשן בענן בחר שם branch משלו

מה קרה: ביקשתי מהסשן שם branch מסוים. הוא דחף ל-branch אחר, עם שם שהוא יצר. הכלים שחיפשו את ה-PR לפי השם הצפוי לא מצאו אותו.

התיקון: מחפשים PR לפי ריפו וזמן, לא לפי שם ה-branch. לפני משימת המשך, עוברים ל-branch האמיתי של ה-PR.

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

6. קישור הכניסה לא עבד מטלגרם

מה קרה: קישור הכניסה ללוח הבקרה עבד בדפדפן, אבל כשפתחתי אותו מטלגרם קיבלתי 404. העוגייה הוגדרה כ-SameSite=Strict, והפניה רגילה מקישור חיצוני נחשבת עדיין כניסה מאתר אחר, אז הדפדפן לא שלח את העוגייה.

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

הלקח: תבדקו את הדרך שבה באמת תשתמשו בדבר, במקרה שלי מהטלפון ומטלגרם, לא רק את הדרך הנוחה לבדיקה.

7. תיקון כפול

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

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

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

8. קובץ מצורף גדול מדי לאישור מדויק

מה קרה: אישרתי מייל עם PDF מצורף. הבדיקה המדויקת צריכה את כל הפריט בקריאה אחת, והקובץ בקידוד היה גדול מדי לעבור כך. המייל לא נשלח.

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

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

איך מתחילים: שבוע אחד

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

יום 1: בוט טלגרם שעונה רק לכם

למה: זה ערוץ השליטה. אם הוא פתוח לכל אחד, כל השאר לא משנה.

מה עושים: פותחים בוט ב-BotFather, ומגדירים שהוא מקבל הודעות רק מה-chat_id שלכם. הטוקן נשמר בקובץ עם הרשאות מוגבלות, לא בקוד.

בדיקה: הודעה מחשבון אחר לא מקבלת תשובה ולא מפעילה כלום.

יום 2: סוכן אחד שרק מכין

למה: כדי ללמוד מה הסוכן עושה טוב לפני שנותנים לו לעשות משהו.

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

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

יום 3: תור אישורים

למה: זה הלב של כל המערכת.

מה עושים: כל טיוטה מקבלת מספר יומי. "אשר N" מפעיל את הביצוע, רק מהסשן שמחובר לטלגרם. הביצוע משווה את מה שיוצא לטיוטה שנשמרה, מסרב לטיוטה בת יותר מ-24 שעות, ומסרב לטיוטה שכבר בוצעה.

בדיקה: "אשר" על טיוטה של אתמול נדחה. "אשר" כפול על אותה טיוטה נדחה בפעם השנייה.

יום 4: יומן פעולות ומתג עצירה

למה: כשמשהו מוזר קורה, צריך לדעת מה קרה ולעצור הכל בהודעה אחת.

מה עושים: כל ביצוע, כולל כישלון, נרשם בשורה ביומן. פקודת /pause יוצרת קובץ שכל ג'וב מתוזמן בודק לפני שהוא מתחיל, ו-/resume מוחקת אותו.

בדיקה: אחרי /pause, הג'וב הבא מדלג ורושם שדילג.

יום 5: כלב שמירה

למה: הסוכן ייפול. השאלה היא אם תדעו על זה בעוד רבע שעה או בעוד שלושה ימים.

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

בדיקה: עוצרים את הסוכן ביד, ותוך סבב אחד מגיעה הודעה אחת.

ימים 6-7: מריצים ומתקנים

למה: הכללים האמיתיים נכתבים מהטעויות.

מה עושים: מאשרים, מתקנים, מדלגים. כל תיקון שלכם ("לא לכתוב ככה", "לא לפנות לזה") נכנס לקובץ תיקונים שהסוכן קורא לפני כל טיוטה.

בדיקה: אחרי שבוע, הטעות שתיקנתם ביום 3 לא חוזרת.

ואחר כך: עוד סוכן, עם אותו תור, אותו יומן ואותו כלב שמירה.

בסוף

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

עוד פלייבוקים וערכות: gindiinnovation.com/playbooks. לחיזוק השרת (כניסה עם מפתח, כלב שמירה, גיבוי, תקרות זיכרון), הערכה "שרת לסוכני AI שלא נופל ולא נפרץ".

הבהרה

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

ומה הלאה

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