צוות בוטים בגרוק בוט: המדריך המלא לבנייה, הרשאות ושגרות

מה חשוב לדעת על צוות בוטים בגרוק בוט, בקצרה?

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

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

מה ההבדל בין בוט מנהל לבוטים מבצעים?

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

בגרוק בוט כמה בוטים יכולים לעבוד במקביל, לשלוח הודעות זה לזה, לחלוק הקשר בצ'אטים קבוצתיים ולהעביר בעלות על משימה, כך שלא צריך לנתב כל דבר ידנית [1]. היכולת הזו לא קובעת מי אחראי על מה. את זה קובעים במבנה.

מה עושה הבוט המנהל:

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

מה עושה בוט מבצע:

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

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

מה כותבים בכתב המינוי של כל בוט?

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

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

תבנית לכתב מינוי בצוות (להעתקה):

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

שלושה דברים שכדאי לבדוק בכתב מינוי:

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

את השיטה הקבועה של המשימה, השלבים, כללי ההחלטה והתוצר, שומרים כמיומנות (Skill). מיומנות טובה כוללת גם "מה דורש אישור" [3], והיא זמינה לכל הבוטים בחשבון [3].

איך קובעים הרשאות ושערי אישור לצוות בוטים?

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

מה המערכת נותנת:

• כשפעולה דורשת אישור, השיחה מציגה את הפעולה המוצעת ואת הקלט שלה, ואפשר לאשר פעם אחת, לאשר תמיד לפי כלל, או לחסום [4].
• אישור חל על הפעולה המוצעת, לא על עבודה שכבר בוצעה. לא מאשרים פעולה שלא ברור מה היעד שלה ומה ההשפעה [4].
• בוט פועל בשם המשתמש המחובר ולא יכול לקבל יותר גישה ממנו [4]. לכן הגישה של הצוות כולו היא לכל היותר הגישה של מי שמפעיל אותו.
• שכבת Auto Review בודקת פעולות מסוכנות לפני שהן רצות, ואפשר להוסיף כללים אישיים כמו "לשאול לפני כל מייל חיצוני" [4].
• בהתחברות, אימות דו שלבי, CAPTCHA או תשלום, הבוט מעביר את השליטה לאדם ולא עוקף את הבדיקה [2].

מה מוסיפים בנוהל, מעבר למערכת:

• מסלול אישור אחד. בוט מבצע ← בוט מנהל ← אדם. בוט מבצע לא פונה לאדם ישירות, וכך כל הבקשות מגיעות מסודרות ובמקום אחד.
• גישה מינימלית וחשבון ייעודי. מחברים לכל מערכת רק את מה שהתפקיד צריך, ועדיף בחשבון ייעודי [5].
• שער אישור לפני כל פעולה בלתי הפיכה [5]. בקורס יש שיעור שלם על "בוט וצוות אנושי: מי מאשר מה" [5].
• בנייה במצב מושהה. בוט שבונה קמפיין או שינוי בונה הכול במצב כבוי, והפעלה היא החלטה נפרדת של אדם.

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

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

מה התיעוד אומר:

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

איך עושים את זה בפועל:

• תיקייה לכל לקוח או עסק, בתוך התיקייה המשותפת /workspace, שבה התיעוד ממליץ לשמור קבצים קבועים בתיקיות פרויקט ברורות [2].
• כלל כתוב בכתב המינוי: "מידע של לקוח אחד לא נכנס לתוצר של לקוח אחר". בבוט שמשרת כמה עסקים, כותבים את זה במפורש לכל עסק.
• מקורות לפי תיקייה. כל טענה בתוצר מפנה לקובץ מקור בתיקייה של אותו לקוח, וכך קל לבדוק שלא נכנס מידע מבחוץ.
• חשבון נפרד כשההפרדה חייבת להיות אמיתית, למשל לקוח עם מידע רגיש. זו ההפרדה היחידה שהיא גבול אבטחה [1][2].
• ניקוי בסוף פרויקט: להשהות שגרות, להתנתק מאתרים, להסיר תוספים ולמחוק קבצים רגישים מ /workspace [4].

איך מגדירים שגרות ודיווח לצוות בוטים?

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

מה המערכת נותנת:

• מיומנות היא סט הוראות לשימוש חוזר, ושגרה מריצה אותה בזמן קבוע או אחרי אירוע. מתחילים ממשימה חד פעמית, מייצבים, שומרים כמיומנות, ורק אז מתזמנים [3].
• בוט אחד יכול להחזיק עד 50 שגרות, והאפליקציה שומרת את 20 ההרצות האחרונות של כל שגרה [3].
• הרצת בדיקה מבצעת עבודה אמיתית: גולשת, משנה קבצים וקוראת לכלים מחוברים. לכן בודקים עם קלט בטוח, ופעולות כתיבה נשארות מאחורי אישור [3].
• שגרות רצות גם כשהמחשב האישי סגור [3].

כללים שאנחנו עובדים לפיהם:

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

מה הטעויות הנפוצות בבניית צוות בוטים?

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

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

איך נראה צוות בוטים אמיתי, במקרה המבחן של הצוות של יעקב צדק?

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

המבנה (לפי קבצי הצוות, בלי מזהים):

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

ארבעה רגעים מהשבוע הזה:

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

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

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

מאיפה מתחילים אם רוצים לבנות צוות כזה?

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

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

מה שואלים הכי הרבה על צוות בוטים בגרוק בוט?

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

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

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

מה ההבדל בין מיומנות לשגרה? מיומנות היא איך עושים משימה. שגרה היא מתי בוט מסוים מריץ אותה, לפי זמן או אירוע.

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

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

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

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

על אילו מקורות המדריך מבוסס?

1. תיעוד רשמי של גרוק בוט, סקירה כללית: https://docs.x.ai/grok-bot/overview (נקרא 10.10.2026)
2. תיעוד רשמי, המחשב והאפליקציות: https://docs.x.ai/grok-bot/computer-and-apps (נקרא 10.10.2026)
3. תיעוד רשמי, מיומנויות ושגרות: https://docs.x.ai/grok-bot/skills-routines-and-automations (נקרא 10.10.2026)
4. תיעוד רשמי, אבטחה, אישורים ו Auto Review: https://docs.x.ai/grok-bot/security (נקרא 10.10.2026)
5. עמוד קורס הווידאו גרוק בוט ב tzedek.me: כתב מינוי, גישה מינימלית, שער אישור, ריצות קבועות, ופרק "להגדיל" (צוות בוטים, יומן ריצות, בוט וצוות אנושי). עותק שמור מ 9.10.2026.
6. מקרה המבחן: קבצי הצוות של יעקב צדק (רשימת תפקידים ונוהל אישורים) ועבודת הצוות בשבוע של 9 עד 10 באוקטובר 2026. בלי מזהים, סכומים או נתונים פנימיים.