Agent Mode — המנוע שמתחת למכסה

למה Agent Mode משנה את חוקי המשחק

דמיינו שאתם יושבים ב-VS Code ומבקשים מ-Copilot: "תבנה לי REST API לניהול משתמשים עם TypeScript ו-Express, כולל validation, error handling וטסטים." לפני Agent Mode, Copilot היה נותן לכם קטע קוד בצ'אט ואומר "הנה, תעתיקו." עכשיו? הוא יוצר את הקבצים, כותב את הקוד, מריץ את הטסטים, רואה ששניים נכשלים, מתקן את הבאגים, ומריץ שוב — עד שהכל ירוק.

זה לא "צ'אט משודרג." זה סוכן אוטונומי (Agent) שמפעיל כלים, מקבל feedback מהסביבה, ומתקן את עצמו בלולאה. וההבנה של הלולאה הזו — איך היא עובדת, מתי היא מועילה, ומתי היא מסוכנת — היא ההבדל בין מפתח שמשתמש ב-Copilot לבין מפתח ששולט בו.

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

Agent Mode הושק בפברואר 2025 כ-preview ב-VS Code, והפך ל-Generally Available עד מרץ 2026 בכל סביבות הפיתוח העיקריות: VS Code, JetBrains, Eclipse ו-Xcode. מאז שהושק, הוא הפך לצורת העבודה הדומיננטית — לפי GitHub, יותר מ-70% מהאינטראקציות עם Copilot Chat כיום הן ב-Agent Mode. זה לא רק שדרוג ל-Copilot — זה שינוי פרדיגמה בדרך שמפתחים עובדים. במקום "כתוב לי קוד, אני אבדוק," המודל הוא "תבנה, תבדוק, ותתקן — אני אפקח."

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

הלולאה האגנטית — 6 שלבים שחוזרים על עצמם

הלולאה האגנטית (Agentic Loop) היא הלב של Agent Mode. בכל פעם שאתם שולחים פרומפט ל-Agent Mode, מופעל מנגנון של 6 שלבים שחוזרים על עצמם עד שהמשימה הושלמה — או עד שהסוכן מגיע לגבול.

בואו נפרק כל שלב:

שלב 1: קלט (Input)

אתם כותבים פרומפט. זה יכול להיות פשוט ("הוסף logging לפונקציה הזו") או מורכב ("בנה מערכת authentication מלאה עם JWT"). הסוכן מקבל את הפרומפט יחד עם הקשר (Context) — הקובץ הפתוח, קבצים רלוונטיים שהמערכת זיהתה, היסטוריית השיחה, וקבצי הוראות כמו copilot-instructions.md.

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

שלב 2: תכנון (Plan)

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

למשל, אם ביקשתם "הוסף route חדש ל-API," הסוכן יחליט: קודם לקרוא את קובץ ה-routes הקיים, לראות את המבנה, ליצור את ה-route החדש באותו סגנון, לוודא שיש import מתאים, ולהריץ את הטסטים. כל זה קורה לפני שנכתבת שורת קוד אחת.

שלב 3: בחירת כלי (Tool Selection)

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

• כלי קריאה: readFile לקריאת קובץ, listDirectory לסריקת תיקייה
• כלי כתיבה: editFiles לעריכת קבצים, createFile ליצירת קבצים חדשים
• כלי הרצה: runInTerminal להרצת פקודות, getTerminalOutput לקריאת פלט
• כלי חיפוש: codebase לחיפוש סמנטי, textSearch לחיפוש טקסט, fileSearch לחיפוש קבצים

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

שלב 4: ביצוע (Execute)

הסוכן מפעיל את הכלי ומבצע את הפעולה. כאן זה תלוי ברמת האישור (Approval Level) שלכם — בברירת מחדל, הוא יבקש רשות לפני פעולות מסוימות (כמו הרצת פקודות בטרמינל). במצב auto-approve, חלק מהפעולות ירוצו ללא אישור. במצב YOLO, הכל רץ אוטומטית.

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

שלב 5: בדיקה (Evaluate)

אחרי כל ביצוע, הסוכן בודק את התוצאה. הוא מחפש שגיאות syntax, כשלונות build, טסטים שנכשלו, שגיאות לינט, או פלט שגוי מהטרמינל. הבדיקה מתבצעת בכמה ערוצים במקביל: הסוכן קורא את הודעות השגיאה מה-editor (Problems panel), את פלט הטרמינל, ואת תוצאות הטסטים. אם הכל תקין — אפשר להמשיך לשלב הבא בתוכנית או להציג את התוצאה. אם יש בעיה — ממשיכים לשלב 6.

שלב 6: תיקון עצמי (Self-Correction)

הסוכן מנתח את השגיאה, מחליט מה לתקן, וחוזר לשלב 2 — תכנון מחדש. זה תיקון עצמי (Self-Correction) — היכולת של הסוכן לזהות שמשהו השתבש ולנסות דרך אחרת. המנגנון הזה ממשיך עד שהמשימה הושלמה בהצלחה או עד שנגמרו הניסיונות (ברירת מחדל: 25 בקשות לסבב).

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

מעבר מלא דרך הלולאה — דוגמה צעד אחר צעד

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

"צור מודול logging שמדפיס הודעות צבעוניות לקונסול, תומך ברמות debug/info/warn/error, וכולל timestamp. תוסיף טסט."

סה"כ: 8 tool calls, 2 סיבובים של הלולאה, ~30 שניות — ותוצאה עובדת עם טסטים ירוקים. זה מה שהלולאה האגנטית עושה בפועל.

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

שלושת המצבים: Ask, Edit ו-Agent — מתי משתמשים בכל אחד

GitHub Copilot ב-VS Code מציע שלושה מצבי עבודה שונים. ההבדל ביניהם הוא לא רק ב"כמה חכם" Copilot — אלא במה מותר לו לעשות. בחירת המצב הנכון חוסכת זמן, טוקנים, וטעויות.

Ask Mode — מצב שאל

Ask Mode (מצב שאל) הוא צ'אט טהור. אתם שואלים, Copilot עונה — אבל הוא לא משנה אף קובץ. זה המצב המתאים כשאתם:

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

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

Edit Mode — מצב עריכה

Edit Mode (מצב עריכה) הוא "כירורגיה מדויקת." אתם בוחרים אילו קבצים לערוך, נותנים הוראות, ו-Copilot מציע שינויים — אבל אתם מאשרים כל שינוי בנפרד. זה המצב המתאים כשאתם:

• יודעים בדיוק מה צריך לשנות ובאיזה קובץ
• עובדים על קוד ישן (brownfield) ורוצים שליטה מלאה
• רוצים לשפר כמה שורות בלי ש-Copilot יגע בשאר
• צריכים שינוי טכני מדויק (rename, extract function)

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

Agent Mode — מצב סוכן

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

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

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

השוואה מעשית: אותה בקשה בשלושה מצבים

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

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

מה קורה מאחורי הקלעים: הטוקנים והעלות

נקודה שחשוב להבין: כל מצב צורך כמות שונה של טוקנים. ב-Ask, הסוכן שולח בקשה אחת ומקבל תשובה אחת — צריכה מינימלית. ב-Edit, יש כמה סבבים של הצעה ואישור. ב-Agent Mode, כל tool call הוא בקשה נפרדת למודל — וזה מצטבר מהר.

למה זה חשוב? כי Copilot עובד עם מערכת Premium Requests (בקשות פרמיום). בחשבון Copilot Pro יש מכסה חודשית של בקשות premium, ו-Agent Mode צורך יותר בקשות לכל משימה. הנקודה החשובה: רק הפרומפטים שאתם שולחים נספרים כבקשות premium — ה-tool calls האוטומטיים של הסוכן לא נספרים בנפרד. אבל כל סבב של הלולאה שבו הסוכן "מדבר" אתכם (מציג תוצאות, שואל שאלות) נספר.

המשמעות המעשית: אל תשתמשו ב-Agent Mode על משימה שמספיק לה Ask, כי אתם מבזבזים בקשות premium על overhead מיותר. ולהפך — אל תנסו לעשות ב-Ask מה ש-Agent Mode עושה בקלות, כי תבזבזו זמן שלכם בהעתקה ידנית ובדיקות.

Plan Mode — לתכנן לפני לבצע

אחד הדברים שמפתחים מנוסים לומדים מהר הוא ש-Agent Mode עובד הכי טוב כשנותנים לו לתכנן לפני שהוא מתחיל לכתוב קוד. ל-Copilot יש כלי ייעודי לזה: Plan Mode (מצב תכנון).

מה Plan Mode עושה

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

איך להפעיל

יש שתי דרכים:

• בחרו Plan מתפריט ה-agents בראש חלון הצ'אט
• כתבו /plan ואחרי זה את תיאור המשימה

מתי להשתמש ב-Plan Mode

• משימות מורכבות — refactoring של מודול שלם, מעבר לפריימוורק חדש, שינוי ארכיטקטורה
• כשלא בטוחים בהיקף — רוצים לראות מה הסוכן מתכנן לגעת בו לפני שהוא מתחיל
• code review מקדים — לבדוק את הגישה לפני הביצוע, לוודא שההיגיון נכון
• עבודת צוות — להראות לעמיתים מה מתוכנן לפני שמריצים, לקבל אישור על הגישה
• לימוד — לראות איך Copilot חושב על בעיה, גם אם אתם מתכננים לפתור אותה בעצמכם

מה תוכנית ביצוע כוללת

כשאתם מריצים /plan, Copilot מייצר מסמך מובנה שכולל:

• סקירה כללית — מה המשימה ומה הגישה המוצעת
• רשימת קבצים מושפעים — אילו קבצים יישרתו, יערכו, או יימחקו
• שלבי ביצוע מפורטים — כל שלב עם הסבר מה יקרה ולמה
• תלויות — אם שלב X תלוי בשלב Y
• בדיקות מוצעות — איך לוודא שהכל עובד אחרי הביצוע

אתם יכולים לענות על התוכנית: "נראה טוב, תתחיל" או "שנה את שלב 3, במקום X תעשה Y." הסוכן מתעדכן ומתחיל לבצע. אם יש שלב שנראה לכם מסוכן או מיותר — אמרו "דלג על שלב 4" והסוכן יתאים את התוכנית. זו שליטה שאין לכם ב-Agent Mode רגיל — שם הסוכן מחליט בעצמו.

Plan Mode מול Agent Mode רגיל: ב-Agent Mode רגיל, התכנון קורה "בראש" של הסוכן — אתם לא רואים אותו. הסוכן פשוט מתחיל לעבוד. ב-Plan Mode, התכנון הופך לשקוף — אתם רואים את כל השלבים לפני שקורה משהו. הבחירה ביניהם תלויה במידת הביטחון שלכם: אם אתם סומכים על הסוכן — Agent רגיל. אם אתם רוצים לסקור קודם — Plan.

רמות אישור — מ-manual עד yolo

אחד הדברים שמבדילים משתמש מתקדם ממתחיל הוא ההבנה שיש לכם שליטה מלאה על מה Agent Mode מורשה לעשות בלי לשאול. ב-Copilot יש שלוש רמות אישור (Approval Levels), וכל אחת מתאימה למצב אחר.

רמה 1: Manual — אישור ידני (ברירת מחדל)

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

מתאימה ל: קוד production, פרויקטים רגישים, משתמשים חדשים ב-Agent Mode.

רמה 2: Auto-Approve — אישור אוטומטי בררני

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

ההגדרות הרלוונטיות ב-settings.json של VS Code:

{
  // אישור אוטומטי לכלים ספציפיים
  "chat.tools.autoApprove": {
    "readFile": true,
    "codebase": true,
    "listDirectory": true
  },

  // אישור אוטומטי לפקודות טרמינל לפי דפוס
  "chat.tools.terminal.autoApprove": {
    "/^npm test/": true,
    "/^npm run lint/": true,
    "/^git status/": true,
    "/^rm /": false,
    "/^git push/": false
  }
}

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

רמה 3: YOLO Mode — הכל אוטומטי

YOLO Mode (מצב ילו) מאשר הכל — כל כלי, כל פקודת טרמינל, בלי לשאול. אפשר להפעיל אותו בשתי דרכים:

// ב-settings.json — מפעיל את YOLO גלובלית
{
  "chat.tools.global.autoApprove": true
}

// או בצ'אט — מפעיל לסשן הנוכחי בלבד
/yolo

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

איך Copilot מחליט מה דורש אישור

גם בלי שתגדירו כלום, Copilot מפריד בין פעולות "בטוחות" ו"רגישות":

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

ההיגיון ברור: פעולות שיכולות לשנות מצב (כתיבה, הרצה) דורשות אישור. פעולות שרק קוראות מידע — לא. ההגדרות שלכם ב-settings.json דורסות את ברירות המחדל האלה.

טיפ למפתחים ישראלים

אם אתם עובדים בסטארטאפ ישראלי טיפוסי — סביר שיש לכם כמה סביבות: development, staging, production. הגדרו Workspace Settings (לא User Settings) שונים לכל סביבה. בפרויקט ה-development אפשר להרשות יותר, בפרויקט ה-production — רק manual. ב-VS Code, Workspace Settings דורסים את ה-User Settings, אז אתם יכולים להיות נדיבים בברירת מחדל ומגבילים בפרויקטים ספציפיים.

איך ליצור Workspace Settings

כדי שההגדרות יהיו ספציפיות לפרויקט (ולא גלובליות לכל VS Code), צרו תיקיית .vscode/ בשורש הפרויקט ובתוכה קובץ settings.json:

// .vscode/settings.json — הגדרות ספציפיות לפרויקט
{
  // פרויקט production: הכל manual
  "chat.tools.autoApprove": {},
  "chat.tools.terminal.autoApprove": {},
  "github.copilot.chat.agent.maxRequests": 25
}

לעומת זאת, ב-User Settings (שחלים על כל הפרויקטים) אפשר להיות נדיבים יותר:

// User settings — ברירת מחדל לכל הפרויקטים
{
  "chat.tools.autoApprove": {
    "readFile": true,
    "codebase": true,
    "listDirectory": true,
    "fileSearch": true
  },
  "chat.tools.terminal.autoApprove": {
    "/^npm test/": true,
    "/^npm run lint/": true,
    "/^git status/": true
  }
}

ההיררכיה: Workspace Settings דורסים User Settings. אז הפרויקט עם .vscode/settings.json ריק יחסום את ה-auto-approve הגלובלי. זו הדרך הנכונה לנהל בטיחות — ברירת מחדל נוחה, עם override מגביל לפרויקטים רגישים. שימו לב: הגדרות Workspace נשמרות ב-git (תיקיית .vscode/), כך שהן חלות על כל הצוות. אם מישהו בצוות מגדיר YOLO ב-workspace settings — כל הצוות מקבל את זה. וודאו שיש הסכמה צוותית על רמת האישור לפני שמכניסים את ההגדרות ל-repo.

תיקון עצמי — איך Copilot מזהה שגיאות ומתקן

אחד המנגנונים החזקים ביותר של Agent Mode הוא תיקון עצמי (Self-Correction). במקום להציג לכם קוד שבור ולהגיד "הנה, תתקנו" — הסוכן מנסה לתקן בעצמו.

מה מפעיל את מנגנון התיקון?

הסוכן מזהה בעיות בחמישה ערוצים:

1. שגיאות Syntax — הקוד לא מתקמפל. הסוכן רואה את הודעת השגיאה מה-editor ומתקן.
2. כשלון Build — npm run build נכשל. הסוכן קורא את הפלט, מזהה את הבעיה, ומתקן.
3. טסטים שנכשלים — npm test מחזיר failures. הסוכן קורא את דוח הטסטים ומתקן.
4. שגיאות Lint — ESLint או כלי דומה מדווח על בעיות. הסוכן מתקן לפי הכללים.
5. פלט טרמינל שגוי — פקודה שהורצה מחזירה שגיאה. הסוכן קורא את ה-error ומתאים את הגישה.

איך זה נראה בפועל

דמיינו שביקשתם מהסוכן ליצור פונקציה שמטפלת ב-API call. הסוכן:

1. כותב את הפונקציה
2. מריץ את הטסט
3. רואה שהטסט נכשל — חסר import של axios
4. מוסיף את ה-import
5. מריץ שוב — הטסט עובר
6. ממשיך למשימה הבאה

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

דוגמה מעשית: תיקון עצמי בפעולה

הנה תרחיש אמיתי שממחיש את התהליך:

גבולות התיקון העצמי

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

// settings.json — שינוי מגבלת ניסיונות
"github.copilot.chat.agent.maxRequests": 50

לזהות: תיקון עצמי טוב מול לולאה

ההבדל בין תיקון עצמי מוצלח ללולאה אינסופית הוא דק אבל חשוב:

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

חלון ההקשר — מה Copilot רואה ומה לא

כדי לקבל תשובות טובות מ-Agent Mode, חשוב להבין מה הסוכן רואה. הוא לא רואה את כל הפרויקט בבת אחת — הוא עובד בתוך חלון הקשר (Context Window) מוגבל.

מה נכנס לחלון ההקשר

גודל החלון

גודל חלון ההקשר תלוי במודל שנבחר:

• GPT-4o: 64,000 טוקנים (הסטנדרט)
• Claude Sonnet/Opus: עד 128,000-200,000 טוקנים
• דגמים חדשים: חלק מגיעים עד 192,000 טוקנים

נשמע הרבה? קחו בחשבון ש-30-40% שמור לפלט (Reserved Output) — מקום שהמערכת מקצה מראש כדי שהסוכן יוכל לכתוב תשובות ארוכות בלי שייחתך באמצע. ושכל כלי שהסוכן מפעיל מוסיף מידע לחלון — פלט טרמינל, תוכן קבצים, תוצאות חיפוש. בפרויקט גדול עם הרבה קבצים, החלון יכול להתמלא מהר מאוד.

חשבון פשוט

בואו נעשה חשבון: עם חלון של 64,000 טוקנים ו-40% שמור לפלט, נשארים לכם כ-38,000 טוקנים לקלט. קובץ TypeScript ממוצע הוא כ-500-1,000 טוקנים. אם הסוכן קורא 10 קבצים, מריץ 5 פקודות, ויש לכם 15 הודעות בשיחה — החלון כמעט מלא. לכן חשוב לנהל את ההקשר בצורה מודעת.

מה קורה כשנגמר המקום

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

אסטרטגיות לניהול הקשר אפקטיבי

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

אסטרטגיה 1: שיחות קצרות וממוקדות. במקום שיחה אחת ארוכה עם 30 הודעות, פתחו שיחה חדשה כל 5-8 הודעות. כל שיחה חדשה מתחילה עם חלון הקשר נקי. זה במיוחד חשוב כש-Agent Mode קורא הרבה קבצים — כל קובץ נשאר בזיכרון עד שהחלון מתמלא.

אסטרטגיה 2: כוונו את הסוכן במקום שיחפש. במקום "מצא את הבאג בפרויקט" (שגורם לסוכן לסרוק 50 קבצים), כתבו "הבאג ב-#file:src/api/users.ts — ה-validation לא עובד על email ריק." התחביר #file: מכוון את הסוכן ישירות לקובץ הנכון וחוסך טוקנים יקרים.

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

אסטרטגיה 4: השתמשו בקובץ instructions. מידע שנמצא ב-copilot-instructions.md נטען אוטומטית בכל שיחה חדשה — כך שאתם לא צריכים לחזור עליו. כל מה שרלוונטי תמיד (tech stack, coding standards, כללים) שייך בקובץ instructions, לא בפרומפט.

לולאות אינסופיות — זיהוי ושבירה

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

למה לולאות קורות

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

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

סימני אזהרה — איך מזהים לולאה

שימו לב לארבעה סימנים:

1. אותו קובץ נערך שוב ושוב — הסוכן חוזר לאותו קובץ בלי התקדמות
2. אותה שגיאה חוזרת — הפלט מראה את אותה הודעת שגיאה אחרי כל תיקון
3. הסוכן "חושב" יותר מ-2 דקות — ללא פלט חדש
4. הסוכן מוסיף ומסיר את אותו קוד — flip-flop בין שתי גרסאות

4 שיטות לשבירת לולאה

פרומפטים שעובדים — איך לדבר עם Agent Mode

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

כלל 1: מהכללי לספציפי

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

כלל 2: פרקו משימות גדולות

במקום לבקש "תבנה אפליקציה מלאה", חלקו ל-3-5 פרומפטים. הסוכן עובד טוב יותר על חתיכות ממוקדות. למשל, במקום "בנה מערכת e-commerce מלאה" — בקשו: (1) "בנה את מודל המוצר עם TypeScript types", (2) "הוסף CRUD routes למוצרים", (3) "הוסף authentication middleware", (4) "כתוב טסטים ל-API". כל בקשה ברורה, מוגבלת, ומייצרת תוצאה שאפשר לבדוק לפני שממשיכים.

למה זה עובד? שלוש סיבות: (1) כל פרומפט מייצר פחות tool calls, כך שיש פחות סיכוי ללולאות; (2) חלון ההקשר לא מתמלא מהר; (3) אם משהו נשבר, קל לזהות מה נשבר כי עשיתם דבר אחד בכל פעם.

כלל 3: הימנעו מעמימות

אל תכתבו "תשפר את הקוד הזה" — Copilot לא יודע מה "שיפור" אומר בשבילכם. כתבו: "תוסיף error handling לכל ה-async functions ותשנה את ה-naming convention ל-camelCase." ככל שהפרומפט ספציפי יותר, התוצאה מדויקת יותר — וצריכה פחות סיבובי תיקון.

כלל 4: ספקו דוגמאות

אם יש לכם פורמט ספציפי שאתם רוצים — תנו דוגמה. הסוכן מצטיין ב-pattern matching — אם הוא רואה דוגמה, הוא ימשיך באותו סגנון. "הוסף logging בפורמט: [TIMESTAMP] [LEVEL] message — {context}" ברור הרבה יותר מ-"הוסף logging."

כלל 5: השתמשו בקבצי הוראות

במקום לכתוב את אותן הוראות בכל פרומפט, צרו קובץ .github/copilot-instructions.md בפרויקט שלכם. הסוכן קורא אותו אוטומטית בכל שיחה. זה כמו "חוקת הבית" של הפרויקט — כללים שתקפים תמיד. מה לכלול: tech stack, coding standards, naming conventions, דפוסים שחשוב לשמור, וקבצים שאסור לגעת בהם.

# copilot-instructions.md
## Project Context
This is a TypeScript Express API with PostgreSQL.

## Coding Standards
- Use async/await, never callbacks
- All functions must have JSDoc comments
- Use zod for input validation
- Error responses follow RFC 7807 format

## Testing
- Use vitest for unit tests
- Every new function needs a test
- Mock external API calls

תבנית לפרומפט אפקטיבי

הנה תבנית שאפשר להשתמש בה כנקודת פתיחה לכל בקשה מורכבת ב-Agent Mode:

## מטרה
[תיאור כללי של מה שרוצים להשיג]

## דרישות ספציפיות
1. [דרישה ראשונה]
2. [דרישה שנייה]
3. [דרישה שלישית]

## מגבלות
- אל תשנה את [קובץ/מודול ספציפי]
- השתמש ב-[ספרייה/pattern ספציפי]

## בדיקות
- הרץ [פקודת טסט] ווודא שהכל ירוק
- בדוק ש-[תנאי ספציפי] מתקיים

## דוגמה לפלט רצוי
[דוגמת קוד או תיאור של התוצאה הצפויה]

התבנית הזו מכסה את כל מה שהסוכן צריך: מטרה ברורה, דרישות מפורטות, מגבלות מפורשות, קריטריוני הצלחה, ודוגמה. לא כל פרומפט צריך את כל הסעיפים — למשימה פשוטה מספיקה שורה אחת ברורה. אבל ככל שהמשימה מורכבת יותר, יותר סעיפים יעזרו. אפשר לשמור את התבנית כ-snippet ב-VS Code כך שתהיה זמינה במהירות בכל פעם שפותחים שיחה חדשה עם Agent Mode. מפתחים רבים יוצרים כמה תבניות — אחת לפיצ'רים חדשים, אחת לתיקון באגים, אחת לרפקטורינג.

## מטרה
הוסף rate limiting ל-Express API שלנו

## דרישות ספציפיות
1. השתמש ב-express-rate-limit
2. הגבל ל-100 בקשות לדקה לכל IP
3. הוסף response header שמראה כמה בקשות נשארו
4. נתיב /api/health פטור מ-rate limiting

## מגבלות
- אל תשנה את middleware הקיימים ב-app.ts
- הוסף כ-middleware נפרד בקובץ חדש

## בדיקות
- הרץ npm test ווודא שכל הטסטים עוברים
- הוסף טסט שבודק שאחרי 100 בקשות מקבלים 429

## דוגמה לפלט רצוי
{ "error": "Too many requests", "retryAfter": 60 }

מעבר ממצב למצב — זרימת עבודה מומלצת

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

1. התחילו ב-Ask: "איך הכי נכון לממש rate limiting בפרויקט Express?" — הבינו את הגישה.
2. עברו ל-Agent + Plan: /plan הוסף rate limiting לפי מה שהסברת — סקרו את התוכנית.
3. אשרו ל-Agent: "התוכנית נראית טובה, תתחיל" — תנו לסוכן לעבוד.
4. אם צריך תיקון נקודתי: עברו ל-Edit — "שנה את הערך ל-200 בקשות לדקה במקום 100."

המעבר בין מצבים הוא מהיר — פשוט בוחרים מהתפריט הנפתח בראש חלון הצ'אט. אל תתביישו לשלב מצבים — זו בדיוק הדרך שמשתמשים מתקדמים עובדים. שימו לב: כשעוברים מצב באמצע שיחה, ההקשר של השיחה נשמר. כלומר, אם שאלתם ב-Ask "מה הגישה הנכונה ל-authentication?" ואז עברתם ל-Agent ואמרתם "עכשיו תממש את מה שהסברת" — הסוכן זוכר את השיחה הקודמת ומשתמש בה כהקשר. זה חיסכון משמעותי בזמן ובטוקנים, כי לא צריכים לחזור על ההקשר.

טבלת סיכום: מתי להשתמש בכל מצב — גרסה מורחבת

הטבלה הזו מסכמת את כל מה שלמדתם בפרק. שמרו אותה בהישג יד — היא אחד מה-deliverables המרכזיים.