ארגז הכלים המלא — כל כפתור מוסבר

30 כלים, שולחן עבודה אחד

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

Agent Mode של GitHub Copilot עובד בדיוק ככה. יש לו כ-30 כלים מובנים (Built-in Tools), מחולקים ל-8 קבוצות. כל כלי עושה משהו ספציפי — יוצר קבצים, מריץ פקודות בטרמינל, מחפש קוד, גולש באינטרנט, ועוד. המודל שמפעיל את Agent Mode (ה-Tool Picker — בורר הכלים) מנתח את הפרומפט שלכם ובוחר אוטומטית אילו כלים להפעיל.

אבל הנה הנקודה הקריטית: יותר כלים לא אומר ביצועים טובים יותר. GitHub עצמם גילו שצמצום מ-40 כלים ברירת מחדל ל-13 כלי ליבה שיפר את הדיוק ב-7% וקיצר את זמן התגובה ב-400 מילישניות. פחות רעש = בחירות טובות יותר.

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

לפני שנצלול, בואו נבין את המבנה. הכלים מחולקים ל-8 קבוצות (Tool Sets), וכל קבוצה מכילה כלים שעושים דברים דומים. אפשר להפעיל ולכבות קבוצה שלמה בלחיצה אחת, או לשלוט בכל כלי בנפרד. הקבוצות הן:

1. #edit (4 כלים) — יצירה ועריכה של קבצים ותיקיות. הכלים שמשנים את הקוד בפועל.
2. #execute (5 כלים) — הרצת פקודות בטרמינל, טסטים, tasks מוגדרים, ו-cells ב-notebooks.
3. #read (6 כלים) — קריאת תוכן קבצים, שגיאות ESLint/TypeScript, ופלט טרמינל. העיניים של הסוכן.
4. #search (6 כלים) — חיפוש סמנטי, מילולי, שם קובץ, הפניות, ושינויי Git.
5. #browser (1 כלי) — דפדפן מובנה מבוסס Playwright לגלישה, צילומי מסך, ובדיקות UI.
6. #vscode (6 כלים) — שליטה בעורך עצמו: הרחבות, פקודות, שאלות הבהרה, ו-scaffolding.
7. #web (1 כלי) — שליפת תוכן מכתובות אינטרנט כ-Markdown.
8. #agent (1 כלי) — הפעלת תת-סוכן (subagent) בהקשר מבודד לניהול משימות מורכבות.

בנוסף, יש 3 כלים עצמאיים שלא שייכים לקבוצה: #selection (קריאת הבחירה בעורך), #todos (מעקב משימות), ו-#newWorkspace (יצירת workspace חדש). סך הכל — כ-30 כלים. נעבור על כל קבוצה ביסודיות.

Configure Tools — לוח הבקרה

יש שתי דרכים לשלוט בכלים של Agent Mode. הראשונה היא Configure Tools — תפריט קבוע שמגדיר אילו כלים זמינים לסוכן בכל שיחה. השנייה היא תחביר # (Hash Syntax) — רמז חד-פעמי שמכוון את הסוכן לכלי ספציפי בפרומפט בודד.

Configure Tools — הגדרה קבועה

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

• Checkbox — פעיל/כבוי. מסומן = הסוכן יכול להשתמש בו
• שם הכלי — למשל edit/createFile או search/codebase
• תיאור קצר — מה הכלי עושה
• מקור — Built-in, MCP Server, או Extension

שינויים ב-Configure Tools הם לכל שיחה חדשה. אם כיביתם כלי, הוא יישאר כבוי עד שתפעילו אותו מחדש. שימו לב שכלים שמגיעים מ-MCP servers מופיעים בנפרד מהכלים המובנים — בדרך כלל עם אייקון שונה או קטגוריה נפרדת. כלי MCP לא מסומנים כברירת מחדל, כלומר גם אם התקנתם MCP server, הכלים שלו לא יהיו זמינים לסוכן עד שתסמנו אותם בדיאלוג.

טיפ למפתחים ישראלים: אם אתם עובדים בסטארטאפ עם מספר סביבות (development, staging, production), כדאי ליצור תצורות כלים שונות לכל סביבה. למשל, ב-development הפעילו את כל הכלים כולל browser ו-execute. ב-staging כבו את browser וב-production — אם בכלל משתמשים — השאירו רק read ו-search.

תחביר # — רמז חד-פעמי

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

• #search/codebase — "חפש בקוד את כל הפונקציות שמטפלות בתשלומים"
• #edit/createFile — "צור קובץ README.md עם תיאור הפרויקט"
• #execute/runInTerminal — "הרץ את הטסטים ותגיד לי מה נכשל"

ההבדל הקריטי: Configure Tools קובע מה זמין. # מכוון מה עדיף. גם אם כלי פעיל ב-Configure Tools, הוספת # לפרומפט אומרת לסוכן "עדיף שתשתמש דווקא בכלי הזה." גם אם לא הוספתם #, הסוכן עדיין יכול לבחור כל כלי פעיל.

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

תרחיש מעשי: אתם עובדים על debug ורוב הכלים כבויים חוץ מ-execute, read ו-search. פתאום אתם צריכים שהסוכן יצור קובץ — אבל edit כבוי. במקום ללכת ל-Configure Tools ולהפעיל אותו (מה שישפיע על כל הסשן), פשוט כתבו בפרומפט: #edit/createFile צור קובץ debug-log.txt. הסוכן ישתמש ב-createFile הפעם, וב-פרומפטים הבאים הוא יחזור להתמקד בכלי ה-debug שהגדרתם ב-Configure Tools.

תחבירים מתקדמים של #:

• #edit — מפנה לכל קבוצת Edit (כל 4 הכלים)
• #edit/createFile — מפנה לכלי ספציפי בקבוצה
• #search/codebase #read/problems — אפשר לשלב כמה כלים בפרומפט אחד
• #web/fetch — מפנה לכלי fetch בקבוצת web

כל פעם שמקלידים #, VS Code מציג autocomplete עם כל הכלים הזמינים. אפשר להקליד חלק מהשם ולבחור. זה הרבה יותר מהיר מלפתוח Configure Tools בכל פעם.

שאלה נפוצה: מה קורה כש-# מפנה לכלי כבוי? אם כיביתם כלי ב-Configure Tools אבל כתבתם #edit/createFile בפרומפט, הכלי לא יופעל. Configure Tools הוא "שער הכניסה" — אם כלי כבוי שם, שום # לא יעזור. חשבו על זה כמו מנעול — Configure Tools נועל את הדלת, ו-# מצביע על איזו דלת פתוחה לעבור דרכה קודם.

טיפ מקצועי: אם אתם עובדים הרבה עם # syntax, למדו את הקיצורים. #cb יציע אוטומטית #search/codebase, #rf יציע #read/readFile. ההשלמה האוטומטית מבוססת על fuzzy match — לא חייבים לכתוב את השם המלא.

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

קבוצת Edit — יצירה ועריכה

קבוצת #edit היא לב הפעילות של Agent Mode. כאן נמצאים הכלים שיוצרים ומשנים קבצים בפרויקט. יש 4 כלים:

editFiles הוא הכלי הנפוץ ביותר — כמעט כל פרומפט שדורש שינוי קוד עובר דרכו. כשהסוכן קורא לכלי הזה, VS Code מציג לכם diff — השוואה בין המצב הנוכחי לשינוי המוצע. השורות שנמחקו מסומנות באדום, והשורות החדשות בירוק. אתם יכולים לאשר (Accept), לדחות (Reject), או לערוך ידנית לפני אישור.

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

Undo Last Edit — אם אישרתם שינוי ומיד התחרטתם, לחצו על כפתור Undo Last Edit בסרגל הכלים של הצ'אט. זה מחזיר את הקובץ למצב שלפני העריכה האחרונה. שימו לב שזה שונה מ-Ctrl+Z הרגיל — Undo Last Edit מחזיר את כל השינויים שנעשו בפעולת editFiles אחת, גם אם הם כוללים מספר שורות בכמה מקומות בקובץ.

createDirectory יכול ליצור גם תיקיות מקוננות. אם ביקשתם "צור תיקייה src/components/auth/hooks", הוא יצור את כל שרשרת התיקיות — גם אם src לא קיימת. זה חוסך פרומפטים מרובים כשבונים מבנה פרויקט מאפס. שימו לב: createDirectory יוצר תיקיות ריקות. הוא לא יוצר קבצים בתוכן — לזה תצטרכו createFile. בפועל, כש-Copilot בונה מבנה פרויקט, הוא קורא ל-createDirectory ואז ל-createFile עבור כל קובץ.

editNotebook מיועד לעבודה עם Jupyter Notebooks (.ipynb). אם אתם עובדים עם data science או machine learning, הכלי יודע להוסיף cells חדשים, לשנות קוד ב-cells קיימים, ולשנות את סוג ה-cell (קוד/מרקדאון). מפתחים שלא עובדים עם notebooks יכולים לכבות את הכלי הזה בבטחה.

קבוצת Execute — הרצה ובדיקות

קבוצת #execute היא הידיים של Agent Mode — כאן הוא לא רק כותב קוד, אלא מריץ אותו, בודק תוצאות, ומתקן. יש 5 כלים:

נקודה חשובה על אישורים: פקודות טרמינל דורשות אישור כברירת מחדל. כשהסוכן רוצה להריץ npm install, תראו הודעה שמבקשת את אישורכם עם הפקודה המלאה שמוצגת לכם לסקירה. ב-Autopilot Mode (מצב yolo, כפי שלמדתם בפרק 1) הפקודות רצות אוטומטית — אבל זכרו: רק בפרויקטי פיתוח, לעולם לא ב-production.

testFailure הוא כלי שלא מריץ טסטים בעצמו, אלא אוסף מידע על טסטים שנכשלו. בדרך כלל הסוכן קודם מריץ את ה-test suite עם runInTerminal, ואז משתמש ב-testFailure כדי לקבל את השם המלא של הטסט שנכשל, את הודעת השגיאה, ואת ה-stack trace. המידע הזה מספיק לסוכן כדי לאתר את הבעיה ב-codebase ולתקן אותה. זו הסיבה שכלי Execute וכלי Read עובדים יד ביד — execute מריץ, read קורא את התוצאה, execute מריץ שוב.

getTerminalOutput קורא את הפלט האחרון מהטרמינל. זה שונה מ-terminalLastCommand שנמצא בקבוצת Read: getTerminalOutput אוסף פלט בזמן אמת אחרי הרצת פקודה, בעוד ש-terminalLastCommand קורא את הפקודה + הפלט שלה מתוך היסטוריית הטרמינל. בפועל, הם משלימים זה את זה.

createAndRunTask שונה מ-runInTerminal באופן משמעותי. בעוד ש-runInTerminal מריץ פקודה חד-פעמית, createAndRunTask יוצר הגדרת VS Code Task — task מוגדר שנשמר ואפשר להריץ שוב ושוב. זה שימושי לתהליכים חוזרים כמו build, test, lint, או deploy. Task מוגדר יכול לכלול configuration כמו working directory, environment variables, ו-problem matchers שמקשרים שגיאות בפלט לקבצים ספציפיים. אם יש לכם tasks.json מוגדר בפרויקט, הסוכן ישתמש בו. אם אין — הוא ייצור אחד.

runNotebookCell מיועד ל-Jupyter Notebooks. הוא מריץ cell ספציפי וקורא את התוצאה — כולל טקסט, טבלאות, גרפים, ושגיאות. שימושי במיוחד ל-data science ו-machine learning: "הרץ את ה-cell שמאמן את המודל ותגיד לי מה ה-accuracy". הסוכן מריץ, קורא את הפלט, ויכול להציע שיפורים. אם אתם לא עובדים עם notebooks — כבו את runNotebookCell וגם את editNotebook, getNotebookSummary, ו-readNotebookCellOutput. זו כבר חיסכון של 4 כלים שמפחית רעש.

קבוצת Read — קריאה ואבחון

קבוצת #read היא העיניים של Agent Mode. בלי כלים אלה, הסוכן עיוור — הוא לא יכול לראות מה יש בקבצים, מה השגיאות, או מה הפלט בטרמינל. יש 6 כלים:

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

בואו נראה את הרצף המלא: (1) הסוכן קורא קובץ עם readFile, (2) עורך אותו עם editFiles, (3) בודק שגיאות עם problems, (4) אם יש שגיאות — חוזר לשלב 2 ומתקן. הרצף הזה חוזר עד שאין שגיאות או עד שהסוכן מגיע למגבלת ניסיונות (בדרך כלל 3-5 ניסיונות). זו בדיוק הלולאה האגנטית שלמדתם בפרק 1, רק עכשיו אתם רואים אותה דרך הכלים הספציפיים.

terminalSelection הוא כלי ייחודי — הוא קורא טקסט שסימנתם (selected) בטרמינל. למה זה שימושי? נגיד שהרצתם פקודה ארוכה והפלט כולל 200 שורות. אתם רוצים שהסוכן יתמקד רק בשורות השגיאה. סמנו את השורות הרלוונטיות בטרמינל ושלחו: "מה אומרת השגיאה הזו ואיך מתקנים?" — הסוכן ישתמש ב-terminalSelection כדי לקרוא רק את מה שסימנתם.

קבוצת Search — חיפוש וניווט

קבוצת #search היא אחת הקבוצות החשובות והמבלבלות ביותר. יש 6 כלים — ו-3 מהם עושים "חיפוש" אבל באופן שונה לחלוטין. הבנת ההבדל ביניהם חוסכת המון תסכול.

למה usages שונה מ-textSearch? שניהם מחפשים מופעים של מילה, אבל usages מבוסס על LSP (Language Server Protocol) — הוא מבין את המשמעות של הקוד, לא רק את הטקסט. אם יש לכם משתנה בשם user ופונקציה בשם getUser, usages על getUser ימצא רק קריאות לפונקציה — לא מופעים של המילה "user" במקומות אחרים. textSearch היה מוצא הכל. לכן ל-refactoring תמיד עדיף usages, ולחיפוש כללי של מחרוזת (כמו TODO או API key) עדיף textSearch.

changes הוא כלי שימושי במיוחד לסוף יום עבודה. שלחו: "מה שיניתי מאז ה-commit האחרון? תן סיכום" — הסוכן ישתמש ב-changes כדי לקרוא את ה-diff ויספק סיכום ברור. שימושי גם ל-code review — "בדוק את השינויים שלי ותן הערות".

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

Browser ו-Web — חלון לעולם

רוב המפתחים לא יודעים שיש ל-Copilot Agent Mode דפדפן מובנה. כלי ה-#browser (במצב experimental) מאפשר לסוכן לגלוש באתרים, לצלם מסך, ללחוץ על כפתורים, למלא טפסים, ואפילו לטפל בדיאלוגים — והכל מבוסס על Playwright, ספריית האוטומציה של Microsoft.

#browser — דפדפן אמיתי

מה שהכלי יודע לעשות:

• ניווט — פתיחת URL, ניווט אחורה וקדימה
• צילום מסך — screenshot של הדף כולו או אלמנט ספציפי
• אינטראקציה — לחיצה, הקלדה, hover, גרירה
• קריאת תוכן — שליפת טקסט מהדף
• טיפול בדיאלוגים — alert, confirm, prompt

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

#web/fetch — שליפת תוכן

הכלי fetch שונה מ-browser. הוא לא פותח דפדפן — הוא פשוט שולף תוכן מ-URL ומחזיר אותו כטקסט (Markdown). שימושי למקרים כמו:

• קריאת דוקומנטציה מ-URL — "שלוף את ה-API docs מהכתובת הזו"
• בדיקת תוכן JSON endpoint — "שלוף את התשובה מ-/api/health"
• קריאת README מ-GitHub

ההבדל: browser = דפדפן אמיתי עם JavaScript, אינטראקציה, צילומי מסך. fetch = שליפת טקסט בלבד, מהיר וקל.

מתי browser ומתי fetch? אם אתם צריכים לראות מה קורה בדף — אלמנטים ויזואליים, ממשק, CSS, אנימציות — השתמשו ב-browser. אם אתם צריכים רק תוכן טקסטואלי מ-URL — דוקומנטציה, API response, HTML סטטי — השתמשו ב-fetch. Browser צורך יותר משאבים ואיטי יותר, אז אל תשתמשו בו כשמספיק fetch.

הערה חשובה: כלי ה-browser הוא עדיין experimental, כלומר הוא יכול לעבוד מצוין או לא לעבוד בכלל, תלוי בגרסת VS Code ובהגדרות. אם הוא לא מופיע ב-Configure Tools, ייתכן שצריך להפעיל feature flag ב-settings. במקרים כאלה, MCP server של Playwright (שמגיע מותקן כברירת מחדל ב-coding agent) יכול לספק פונקציונליות דומה.

שימוש מעשי לצוותי פיתוח בישראל: הרבה סטארטאפים ישראלים בונים SaaS עם frontend ו-backend. Browser tool מאפשר לכם לבנות פיצ'ר, להריץ את השרת, לגלוש לדף, לצלם מסך, ולשלוח לסוכן "תקן את הלייאוט". הכל בלי לצאת מ-VS Code.

דוגמה מעשית: נניח שאתם בונים דף נחיתה לסטארטאפ ישראלי. הדף מוכן אבל יש בעיית RTL — הטקסט מיושר לא נכון. שלחו ל-Agent Mode: "גלוש ל-localhost:3000, צלם מסך, ותקן את כל בעיות ה-RTL". הסוכן ישתמש ב-browser כדי לגלוש ולצלם, יזהה את הבעיות ויזואלית (כן, המודל "רואה" את צילום המסך), ואז ישתמש ב-editFiles כדי לתקן את ה-CSS. אחרי התיקון, הוא יגלוש שוב ויצלם מסך חדש כדי לוודא. הלולאה האגנטית בגרסת UI.

הגבלות של fetch: כלי web/fetch מוגבל על ידי הגדרות ב-~/.copilot/config. אפשר להגדיר allowed_urls (רשימת כתובות מורשות) ו-denied_urls (כתובות חסומות). כברירת מחדל, הגישה פתוחה, אבל ארגונים יכולים לצמצם — למשל לאפשר גישה רק לדוקומנטציה פנימית ול-APIs ספציפיים.

קבוצת VS Code — שליטה בעורך

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

הכלי askQuestions הוא מעניין במיוחד. בפרק 1 למדתם שהסוכן לפעמים "מנחש" ומתחיל לפעול. עם askQuestions, הוא יכול לעצור ולשאול: "אתה רוצה React או Vue?", "צריך TypeScript או JavaScript?", "איזה port?" — ורק אחרי שאתם עונים, הוא ממשיך.

runCommand הוא כלי חזק שלא מקבל מספיק תשומת לב. הוא יכול להריץ כל פקודת VS Code — כמו Format Document, Toggle Word Wrap, Open Settings, ואפילו פקודות של הרחבות מותקנות. אם יש פקודה שאתם מריצים ידנית מה-Command Palette, הסוכן יכול לעשות את זה עבורכם. למשל: "פרמט את כל הקבצים הפתוחים לפי Prettier" — הסוכן ישתמש ב-runCommand כדי להפעיל את Format Document על כל קובץ.

getProjectSetupInfo שימושי כשמתחילים פרויקט חדש. הכלי מספק מידע על scaffolding — איך לאתחל פרויקט מסוג מסוים. "איך מקימים פרויקט Next.js עם TypeScript?" — הסוכן ישתמש בכלי הזה כדי לקבל את הפקודות ואת מבנה הקבצים הנכון, ואז ישתמש ב-execute ו-edit כדי ליצור הכל בפועל.

Sub-agent ו-Todos — ניהול משימות מורכבות

#agent/runSubagent — הקשר מבודד

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

כלי Sub-agent (תת-סוכן) עושה בדיוק את זה. הסוכן הראשי יוצר סוכן משנה עם הקשר מבודד (Isolated Context) — חלון הקשר נפרד ונקי. התת-סוכן מבצע את המשימה, ומחזיר רק תוצאה מסוכמת. כל העבודה הביניים — קריאת קבצים, חיפושים, ניתוחים — נשארת אצל התת-סוכן ולא מזהמת את ההקשר הראשי.

למה בידוד הקשר חשוב? נניח שאתם שואלים את הסוכן "חקור 3 ספריות ל-form validation ב-React." בלי subagent, הסוכן קורא דוקומנטציה של 3 ספריות, פותח 12 קבצים, שולף 6 דפי web — וכל המידע הזה נשאר ב-context window שלו. עכשיו, כשתשאלו את השאלה הבאה ("עכשיו תממש form עם הספרייה שבחרת"), יש לסוכן עומס אדיר של מידע לא רלוונטי שמאט ומבלבל. עם subagent, כל המחקר קרה "בחדר נפרד". הסוכן הראשי קיבל רק מסקנה של 5 שורות — וההקשר שלו נשאר נקי ומוכן לעבודה.

איך subagent נראה ב-UI? כש-Copilot מפעיל subagent, תראו בצ'אט בלוק ממוזער (collapsed) שכתוב עליו שם המשימה ומצב ההתקדמות (למשל "Reading files..."). אם תלחצו עליו — הוא ייפתח ותוכלו לראות את כל הפעולות שהתת-סוכן עשה. זה נותן לכם שקיפות מלאה בלי עומס.

4 תרחישים שבהם subagent שווה זהב:

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

הגדרות מתקדמות של subagent: אם אתם בונים custom agents (סוכנים מותאמים — נלמד לעומק בפרקים מתקדמים), אפשר להגדיר subagent עם user-invocable: false כדי שיהיה זמין רק כתת-סוכן ולא מהתפריט הראשי. אפשר גם להגדיר disable-model-invocation: true כדי למנוע מהסוכן הראשי לשלוח עבודה אליו אוטומטית — רק בקריאה מפורשת. עומק הקינון המקסימלי הוא 5 רמות — subagent בתוך subagent בתוך subagent וכו' — כדי למנוע לולאות אינסופיות.

#todos — מעקב התקדמות

כלי todos מאפשר לסוכן ליצור רשימת משימות ולעקוב אחרי ההתקדמות. כשאתם שולחים משימה מורכבת — "בנה API עם 5 endpoints" — הסוכן יוצר todo list עם כל השלבים ומסמן כל אחד שהושלם. זה גם עוזר לכם לראות מה כבר נעשה ומה נשאר.

ה-todos מוצגים כ-tree view בצד — כל משימה עם checkbox שמתמלא בירוק כשהיא מושלמת. זה במיוחד שימושי כשהסוכן עובד על משימה ארוכה (10+ דקות) — אתם יכולים לראות בזמן אמת איפה הוא נמצא. אם הסוכן נתקע, אתם יכולים לראות מה הצעד האחרון שעבד ולעזור לו.

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

#selection — כלי עצמאי נוסף שקורא את מה שנבחר (selected) בעורך. אם סימנתם בלוק קוד ושלחתם פרומפט, הסוכן יקרא אוטומטית את הבחירה שלכם. זה חוסך את הצורך להעתיק-הדביק קוד לתוך הצ'אט.

#newWorkspace — יוצר workspace חדש לחלוטין. שימושי כשאתם רוצים שהסוכן יבנה פרויקט מאפס בתיקייה חדשה ונקייה. הכלי פותח חלון VS Code חדש עם workspace ריק. זה שימושי במיוחד כשמנסים ליצור POC (הוכחת היתכנות) מבלי "לזהם" את הפרויקט הנוכחי — הסוכן בונה הכל ב-workspace נפרד, ואם הניסוי מצליח, אתם מעתיקים את הקוד לפרויקט הראשי.

MCP, Extensions וכלים חיצוניים — מה ההבדל?

עד כאן דיברנו על כלים מובנים (Built-in) — הכלים שמגיעים עם Copilot מהקופסה. אבל יש עוד שני סוגים של כלים שתראו ב-Configure Tools:

3 שכבות של כלים

MCP (Model Context Protocol) הוא תקן פתוח שמגדיר איך לחבר מקורות מידע וכלים חיצוניים ל-AI. במילים פשוטות — זה "שקע חשמל תקני" שמאפשר לכל שירות חיצוני להתחבר ל-Copilot. GitHub MCP Server, למשל, מאפשר לסוכן ליצור issues, לפתוח PRs, ולקרוא repositories — ישירות מהצ'אט. Playwright MCP מאפשר גלישה אוטומטית, ויש MCP servers למסדי נתונים (PostgreSQL, MongoDB), לשירותי ענן (AWS, GCP), ולכלי צד שלישי (Slack, Jira, Linear).

ההגדרה נעשית בקובץ .vscode/mcp.json בפרויקט שלכם, או בהגדרות VS Code הגלובליות. כל MCP server מוגדר עם שם, פקודת הפעלה, וארגומנטים. אחרי ההגדרה, הכלים שלו מופיעים ב-Configure Tools — אבל זכרו, לא מסומנים אוטומטית.

Extension Tools — כשאתם מתקינים הרחבת VS Code שתומכת ב-Copilot, היא יכולה להוסיף כלים לתפריט הכלים. למשל, הרחבת Python מוסיפה כלים שקשורים לסביבות וירטואליות ו-Jupyter, והרחבת Docker מוסיפה כלים לניהול containers. ההבדל מ-MCP: extensions מותקנים מה-Marketplace של VS Code ומנוהלים דרך Extension Manager. הם לא דורשים קובץ הגדרה נפרד — ברגע שההרחבה מותקנת, הכלים שלה מופיעים אוטומטית.

איך לזהות מאיפה כלי מגיע? פתחו Configure Tools. כלים מובנים מופיעים בדרך כלל בקטגוריה "Built-in" או בלי תגית מיוחדת. כלי MCP מופיעים עם שם ה-MCP server, למשל "github (MCP)" או "playwright (MCP)". כלי extensions מופיעים עם שם ההרחבה. הזיהוי חשוב כי אם כלי MCP לא עובד, הבעיה היא בהגדרת ה-MCP server — בדקו את קובץ .vscode/mcp.json ואת הלוגים של השרת. אם כלי extension לא עובד, הבעיה היא בהרחבה עצמה — עדכנו אותה או בדקו את ה-output panel של ההרחבה.

טבלת פתרון בעיות מהירה:

מה כדאי להתקין קודם? לרוב המפתחים הישראלים שעובדים עם TypeScript/JavaScript, ה-MCP servers הכי שימושיים הם: GitHub MCP (לעבודה עם issues ו-PRs ישירות מהצ'אט), ו-Playwright MCP (לבדיקות UI). אם אתם עובדים עם מסד נתונים, שווה להוסיף את ה-MCP server הרלוונטי — זה מאפשר לסוכן לבצע queries ישירות. נלמד על MCP לעומק בפרק 5.

אסטרטגיה: קבוצות כלים לפי משימה

עכשיו כשאתם מכירים את כל הכלים, הגיע הזמן לשאלה האמיתית: למה שנכבה כלים?

כפי שציינו בפתיחה, GitHub עצמם גילו שצמצום מ-40 כלים ל-13 כלי ליבה:

• שיפר את Tool Use Coverage (דיוק בחירת כלי) מ-87.5% ל-94.5%
• קיצר את זמן התגובה ב-400 מילישניות בממוצע
• הוריד את Time to First Token ב-190 מילישניות

הסיבה פשוטה: ה-Embedding-Guided Routing (ניתוב מבוסס הטמעות) צריך לסרוק את כל הכלים הזמינים ולהחליט מה רלוונטי. כשיש 40 כלים, הוא צריך לבחון את כולם, לחשב relevance score לכל אחד, ולבחור. כשיש 13 — ההחלטה מהירה וברורה יותר. פחות כלים = פחות רעש = החלטות טובות יותר = תגובה מהירה יותר.

בנוסף, GitHub משתמשים ב-Adaptive Tool Clustering (קיבוץ כלים אדפטיבי) — הם מקבצים כלים דומים ומציגים למודל רק את הקטגוריה הרלוונטית, לא את כל הכלים. זה מפחית עוד יותר את העומס. אבל גם עם הקיבוץ האוטומטי, כיבוי כלים שלא צריך עוזר.

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

איך לשמור קבוצות כלים בפרויקט

אם אתם חוזרים שוב ושוב על אותו סוג משימה, שווה לשמור את קבוצת הכלים בקובץ custom agent. יוצרים קובץ .github/copilot-agents.yml (או .github/agents/) ומגדירים agent עם רשימת כלים ספציפית. למשל:

עבור agent בשם "debugger", מגדירים tools: ["execute/runInTerminal", "execute/testFailure", "read/readFile", "read/problems", "search/codebase", "edit/editFiles"]. בפעם הבאה שתרצו debug, פשוט בחרו את ה-agent "debugger" — וכל הכלים כבר מוגדרים. לא צריך לסמן checkboxes כל פעם.

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