סוכן לעומת עובד — המדריך המלא

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

מדריך יסודות — Agents vs Employees

זיכרון · יוזמה · תזמון · היררכיה · פקודות · יוזקייסים

ההבדל היסודי — שני מודלים שונים לחלוטין#

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

זיכרון — ההבדל הכי קריטי שיש#

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

כשאתה פותח שיחה חדשה עם סוכן Antigravity, הוא לא זוכר:

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

ויזואליזציה: כמה זיכרון יש לכל אחד?#

ארבעה סוגי זיכרון שיש לסוכן — ואיך בונים אותם#

Rules — תמיד פעיל#

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

Skills — on demand#

מה זה: ידע מקצועי שהסוכן טוען רק כשרלוונטי למשימה.
מה שמים: סגנון מותג, עיצוב, SEO, פרודקשן, API ספציפי.
דוגמה: "brand-voice" נטענת כשכותבים תוכן. "deploy-to-vercel" נטענת כשמפרסים.
מיקום: .agent/skills/[שם-skill]/SKILL.md

Context — סטטוס שוטף#

מה זה: "מה קורה עכשיו" — מצב הפרויקט, מה הושלם, מה הבא.
מה שמים: סטטוס עבודה, החלטות שהתקבלו, TODO, היסטוריה קצרה.
חשוב: מתעדכן בסוף כל שיחה. זה ה"דף הסיכום" שהסוכן קורא בפתיחה.
קובץ: .agent/context.md

Notes — ידע ספציפי#

מה זה: מידע שלא מתאים ל-Skill ולא ל-Rules — לקוחות, פרטי אינטגרציה, החלטות עבר.
מה שמים: "לקוח X לא אוהב שמשתמשים ב-Y". "ה-API של Z מחזיר שגיאה כשמעבירים מערך ריק".
מיקום: .agent/notes/[נושא].md

יוזמה — מי מתחיל את העבודה?#

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

זה לא חיסרון — זו תכונה. הסוכן עושה בדיוק מה שאמרת לו, לא יותר. אין פרשנויות, אין "נראה לי שהתכוונת ל...", אין יוזמה שיכולה לשבש תוכניות.

אז מי מפעיל את הסוכן?#

טבלת השוואה מלאה#

תזמון — מה אפשרי ומה לא#

זו אחת השאלות הכי נפוצות: "אפשר לגרום לסוכן לפעול לבד כל שני בבוקר?" התשובה: כן — גם מתוך Antigravity עצמו (/schedule), וגם בעזרת כלים חיצוניים.

מה Antigravity לא יכול לעשות#

• בלי תזמון שהגדרתם (/schedule או כלי חיצוני), הסוכן לא יתחיל לעבוד בלי שמישהו יפתח שיחה
• אין התראות דחיפה — הוא לא יתריע על כלום אם לא רצה

מה אפשרי — 4 שיטות לתזמון#

בנוסף לשיטות החיצוניות שלהלן, הדרך הישירה היא הפקודה המובנית /schedule.

שיטה 1 — Make / Zapier (הכי פשוט)#

יוצרים Automation שרץ בשעה קבועה. ה-Automation שולח בקשה ל-Antigravity דרך API (אם חשוף) או פותח שיחה בדפדפן דרך כלי automation.
מתאים ל: תהליכים שחוזרים על עצמם — "כל ראשון ב-7:00 בבוקר הפעל /weekly-content".

שיטה 2 — Claude Code עם Cron#

Claude Code יכול לרוץ על שרת עם cron job. הסקריפט פותח שיחה עם Antigravity ומריץ workflow בשעה קבועה.
מתאים ל: מי שנוח עם CLI ורוצה שליטה מלאה.

# crontab - כל יום ראשון בשעה 8:00
0 8 * * 1 /usr/local/bin/run-agent-workflow.sh weekly-content

שיטה 3 — Webhook + Trigger#

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

שיטה 4 — ידנית מתוזמנת (הכי פשוט לבינתיים)#

פותחים שיחה פעם בשבוע ומריצים /weekly-content. הסוכן עושה את כל השאר לבד. לא אוטומטי לחלוטין — אבל הרבה יותר מהיר מלעשות את הכל ידנית.

מתי סוכן מתאים ומתי לא#

יוזקייס 1 — צוות תוכן#

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

למה סוכנים מתאימים: התהליך קבוע. הפלט מוגדר. Brand Voice ניתנת לכימות.

יוזקייס 2 — צוות פיתוח#

בעיה שפותרת: בניית פיצ'ר שלם — מ-spec לקוד לבדיקות לפריסה — בלי לנהל כל שלב ידנית.

למה סוכנים מתאימים: Antigravity בנוי לזה. הסוכן קורא קוד קיים, כותב, בודק, מריץ — כל זה בתוך הכלי עצמו.

ההבדל הגדול ביחס לצוות תוכן: בפיתוח, הסוכן פועל על קבצים אמיתיים ורץ בדפדפן. הוא לא רק כותב — הוא גם מריץ ובודק. זה הופך את ה-Feedback Loop להרבה יותר מהיר.

יוזקייס 3 — צוות מחקר#

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

יוזקייס 4 — סוכן יחיד (הכי נפוץ)#

לא כל משימה צריכה צוות. רוב הזמן — סוכן אחד עם Skills טובות עושה את העבודה.

היררכיית תיקיות — הסטנדרט שעובד#

המבנה שלמטה עובד לכל סוג פרויקט — שנה רק את תכולת ה-Skills, לא את המבנה.

my-project/
├── .agent/                     # הכל שמתחיל ב-dot = נסתר מהעין, גלוי לסוכן
│   │
│   ├── rules.md               # ← קרא בכל שיחה. חוקי ברזל.
│   ├── context.md             # ← קרא בכל שיחה. עדכן בסוף כל שיחה.
│   │
│   ├── skills/                # ← נטענות on-demand לפי המשימה
│   │   ├── brand-voice/
│   │   │   └── SKILL.md
│   │   ├── design-system/
│   │   │   └── SKILL.md
│   │   ├── deploy-config/
│   │   │   └── SKILL.md
│   │   └── [skill נוספות לפי הצורך]/
│   │       └── SKILL.md
│   │
│   ├── workflows/             # ← מופעלות ב-/פקודה
│   │   ├── create-post.md     # /create-post
│   │   ├── weekly-batch.md    # /weekly-content
│   │   └── deploy.md          # /deploy
│   │
│   └── notes/                 # ← ידע ספציפי שלא מתאים ל-Skills
│       ├── integrations.md    # פרטי API, tokens
│       └── decisions.md       # החלטות שהתקבלו ולמה
│
├── src/                       # קוד הפרויקט עצמו
├── drafts/                    # עבודה בתהליך (תוכן / מחקר)
├── approved/                  # מאושר, לא נגע
└── published/                 # פורסם — ארכיון

פקודות — ממציאים או שיש ספרייה?#

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

מה קיים בתיעוד הרשמי של Google#

Antigravity מגיע עם כמה פקודות מובנות שעובדות בלי הגדרה:

מה הקהילה בנתה — ספרייה חלקית#

ב-github.com/rmyndharis/antigravity-skills יש לא רק Skills אלא גם workflow patterns נפוצים:

מה ממציאים — לפי הפרויקט שלך#

כל משימה שחוזרת יותר מ-3 פעמים — כדאי להפוך אותה ל-Workflow. הפורמט פשוט:

# Workflow: /[שם-הפקודה]
## Input נדרש: [מה צריך לקבל]
## שלב 1 — [תיאור]
[מה לעשות]
[Skills לטעון]
[Artifact מה להוציא]
## שלב 2 — [תיאור]
[מה לעשות]
...

מה Google מתכנן להוסיף (לפי ה-Roadmap הרשמי)#

• Workflow Marketplace — ספרייה רשמית של Workflows מאושרים על ידי Google
• Skill Store — מקום מרכזי להורדת Skills ולשיתוף
• Built-in Scheduler — תזמון מובנה כבר קיים היום דרך הפקודה /schedule
• Cross-Agent Communication — פרוטוקול תקשורת מובנה בין סוכנים

טעויות נפוצות — איך אנשים נשברים עם סוכנים#

המודל המנטלי הנכון#

חשבו על סוכן כמו קבלן מומחה שמגיע לפרויקט בלי רקע קודם.

כשקבלן טוב מגיע לעבודה:

• הוא מסתכל על התוכניות שנתת לו (= Skills + Rules)
• הוא שואל מה המצב הנוכחי (= context.md)
• הוא עושה בדיוק מה שנאמר לו — לא יותר, לא פחות
• בסוף כל יום הוא מדווח מה עשה ומה הבא (= עדכון context.md)
• מחר הוא חוזר — ואם לא תתן לו את התוכניות שוב, הוא לא יזכור אותן

השוואה אחת ששווה אלף מילים#

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

מה לקחת מהמדריך הזה#

סוכן הוא לא עובד מהיר יותר. הוא כלי אחר לחלוטין — עם יתרונות ומגבלות שונות.

✅ סוכן לא זוכר בין שיחות — context.md הוא הפתרון
✅ סוכן לא יוזם — Workflows ותזמון (/schedule או כלי חיצוני) הם הפתרון
✅ סוכן לא "מבין" — Skills טובות הן הפתרון
✅ כמה סוכנים = Workspaces נפרדים
✅ פקודות: חלק מובנות בGoogle, חלק מהקהילה, חלק תמציאי לבד
✅ תזמון: הפקודה המובנית /schedule, או כלים חיצוניים (Make/Zapier/Cron)

כשמנהלים סוכן נכון — הוא לא תחליף לעובד. הוא כלי שמגביר את מה שאתם עושים.