Grok Bot

Grok Bot הוא לא “צ׳אט עם AI”. הוא יותר קרוב לעובד דיגיטלי קבוע. לכל Bot יש שם, תפקיד, שיחה משלו והקשר שנבנה לאורך זמן. הוא יכול לעבוד על מחשב ענן, לפתוח דפדפן, להשתמש בקבצים, לעבוד מול אפליקציות, לבקש ממך אישור כשצריך, ולחזור רק כשהוא נתקע או כשהוא צריך החלטה.

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

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

בוט טוב מתחיל מתפקיד, לא מטכנולוגיה. אם התיאור שלו הוא “תעזור לי בהכל”, הוא יאסוף זיכרון לא שימושי ויטעה יותר. אם התיאור שלו הוא “כל שבוע תכין רשימת סיכוני לקוחות ממקורות X, Y, Z ותעצור לפני כל פנייה ללקוח”, הוא מתחיל להתנהג כמו יחידת עבודה אמיתית.

1. שם — שם שמזכיר תפקיד: Lead Research, Bug Repro, Expense Review, Content QA.
2. אחריות — משפט אחד שמגדיר מה הוא owns ומה הוא לא owns.
3. מקורות — אילו קבצים, אתרים, מערכות, תיקיות או חיבורים מותר לו לקרוא.
4. פלט — איך נראית מסירה טובה: טבלה, דוח, טיוטות, קבצים, קישורים, החלטות.
5. גבול אישור — מה חייב לעצור אצלך: שליחה, פרסום, מחיקה, רכישה, שינוי בפרודקשן.
6. מדיניות חסר — מה עושים כשאין נתונים: כותבים לא ידוע, לא מאלתרים.

שם: Lead Research
תפקיד: למצוא 10 חברות רלוונטיות בשבוע ולבנות עליהן דוח החלטה.
מקורות מותרים: CRM, אתר החברה, LinkedIn ציבורי, חדשות ציבוריות.
פלט: טבלה עם שם חברה, למה רלוונטית, מקור, איש קשר אפשרי, סיכון.
אסור בלי אישור: לשלוח הודעה, להוסיף ליד ל-CRM, לשנות סטטוס, לקנות דאטה.
כשאין ראיה: כתוב לא ידוע והמשך לפריט הבא.

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

• התחברת ל-Gmail במחשב הבוטים? אל תניח שרק Bot אחד יכול להשתמש בזה.
• שמרת קובץ סודי ב-/workspace? זה קובץ משותף לכל הבוטים של אותו חשבון.
• בוט אחד למד routine? בדוק מי הבעלים שלו ומה ההרשאות לפני שמפעילים קבוע.
• כמה בוטים יכולים לעבוד במקביל, אבל זה לא כמה גבולות אבטחה נפרדים.

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

כלל אישור מומלץ לבוט:

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

Grok Build הוא הזרוע הטכנית. הוא עובד כמו סוכן קידוד בטרמינל: קורא את הקבצים, מציע תוכנית, מריץ כלים, עורך, בודק, ומשאיר סשן שניתן להמשיך. במכונה הזו נבדק grok 1.0.5 והפקודה זמינה תחת ‎~/.grok/bin/grok.

# בדיקה
grok --version
grok doctor

# התחברות
grok login

# סשן אינטראקטיבי
grok

# סשן עם משימה פתיחה
grok "תקן את הבאג בטופס ההרשמה והריץ בדיקה"

Headless mode הוא המקום שבו Grok Build נהיה אוטומציה. במקום לפתוח TUI, שולחים פרומפט אחד ומקבלים פלט. זה מתאים לבדיקות דיף, סיכום יומי, יצירת דוח, smoke test או עבודה שחוזרת מצנרת.

grok -p "סקור את הדיף וסמן סיכוני אבטחה" \
  --always-approve \
  --output-format json \
  --cwd <dir> \
  --max-turns 6 \
  --deny "Bash(rm -rf *)"

grok -p "בדוק אם יש TODO קריטיים" --output-format json
grok -p "הסבר את הארכיטקטורה" --output-format streaming-json
grok agent stdio

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

grok -p "Review the API changes" \
  --permission-mode dontAsk \
  --allow "Bash(git *)" \
  --allow "Read" \
  --deny "Bash(rm -rf *)" \
  --sandbox strict

Grok Build קורא הוראות פרויקט מקבצים כמו AGENTS.md, Agents.md, CLAUDE.md ותיקיות rules תואמות. זה אומר שאם אתה עובד בריפו שמכיל כללים, הסוכן מקבל אותם כחלק מההקשר. זו גם הסיבה שצריך לכתוב הוראות קצרות וברורות, לא מגילות.

grok inspect
grok sessions list
grok --resume <session-id>
grok -c
grok export <session-id> output.md

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

xAI מחברת ל-Grok גם שכבת מדיה דרך Imagine API. לפי התיעוד הרשמי, היא כוללת יצירת תמונות, עריכת תמונות עם עד 3 תמונות רפרנס, יצירת וידאו, image-to-video, reference-to-video, עריכת וידאו והארכת וידאו. זה אומר ש-Grok לא חייב להיות רק סוכן טקסט או קוד; הוא יכול להיות חלק מצנרת קריאייטיב.

# תמונה דרך API
curl -X POST https://api.x.ai/v1/images/generations \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $XAI_API_KEY" \
  -d '{
    "model": "grok-imagine-image-2.0",
    "prompt": "A clean product hero image for an AI automation guide"
  }'

# וידאו: מתחילים בקשה ואז עושים polling
REQUEST_ID=$(curl -s -X POST https://api.x.ai/v1/videos/generations \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $XAI_API_KEY" \
  -d '{
    "model": "grok-imagine-video-1.5",
    "prompt": "Slow camera push into a futuristic AI dashboard",
    "duration": 8
  }' | jq -r '.request_id')

curl -s https://api.x.ai/v1/videos/$REQUEST_ID \
  -H "Authorization: Bearer $XAI_API_KEY" | jq

אחרי שבוט ביצע משימה כמה פעמים בצורה יציבה, אפשר להפוך את הדרך הזו ל-skill או routine. זה המקום שבו Grok Bot מתחיל להיות “מערכת”, לא רק עוזר. אבל שגרה גרועה עושה נזק מהר יותר, אז מגדירים אותה כמו חוזה עבודה.

כל יום חול ב-08:00, הרץ את Daily customer-risk skill על רשימת החשבונות הנוכחית.
החזר watch list עם קישורים למקורות.
אל תפנה ללקוחות.
אם מקור הנתונים לא זמין, דווח failure ואל תשתמש בדאטה ישן.
עצור לפני כל שינוי ב-CRM ובקש אישור.

• תמיד לבדוק Test run לפני הפעלה קבועה.
• להגדיר אזור זמן במפורש.
• להגדיר מה נחשב הצלחה ומה נחשב failure.
• להגדיר no-data policy ו-stale-data policy.
• להחזיק לוג פעולות ומקורות לכל החלטה חשובה.
• לעצור אישור לפני שליחה, רכישה, מחיקה, פרסום ושינוי בפרודקשן.

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

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

אתה Bot קבוע לתפקיד הבא: [כתוב כאן את התפקיד].

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

מקורות מותרים:
- [מקור 1]
- [מקור 2]
- [תיקייה / מערכת / אתר]

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

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

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

• יש לבוט שם ותפקיד צר.
• ברור אילו מקורות מותר לקרוא.
• ברור אילו פעולות אסורות בלי אישור.
• המשימה הראשונה היא read-only או draft-only.
• אין סודות מיותרים בתיקיית העבודה.
• אם עובדים עם CLI, הוגדרו allow/deny rules או sandbox מתאים.
• אם יש routine, בוצעה Test run עם קלט בטוח.
• אם יש פרסום או שליחה, הם נעצרים לאישור אנושי.
• אם חסר מקור, הבוט כותב לא ידוע ולא משלים לבד.