מה זה תת-סוכן, ולמה חלון-הקשר נפרד הוא הרכיב המרכזי
דפוס תת-סוכן (Subagent Pattern) הוא תבנית-ארכיטקטורה שבה סוכן-AI ראשי, במקום לבצע משימת-משנה בעצמו בתוך אותה שיחה, מפעיל "תת-סוכן" (Subagent) — עותק-נפרד של סוכן, עם חלון-הקשר (Context Window) משלו, שמקבל תיאור-משימה ממוקד, פועל באופן עצמאי, ומחזיר לסוכן הראשי רק תקציר-תוצאה. הרעיון המרכזי: משימות-ביניים שדורשות הרבה "רעש" — תוצאות-חיפוש ארוכות, קריאת-קבצים מרובה, יומני-שגיאות, פלט-כלים מפורט — עלולות להציף את ההקשר של הסוכן הראשי בפרטים שלעולם לא ישמשו שוב, ולדחוק החוצה מידע חשוב יותר שנאסף קודם בשיחה. כשהמשימה מבוצעת בתוך תת-סוכן נפרד, כל ה"רעש" הזה נשאר בחלון-ההקשר של תת-הסוכן ולא מגיע כלל לסוכן הראשי — רק המסקנה הסופית עוברת הלאה, בדרך-כלל בכמה משפטים בלבד. זה שונה מהותית מפיצול-עבודה בין כמה סוכנים ששותפים לאותה שיחה או לאותו מרחב-הקשר משותף: תת-סוכן הוא ישות חד-פעמית, לרוב אפמרית, שנוצרת לצורך משימה ספציפית ונעלמת (או ממשיכה ברקע) לאחר שדיווחה בחזרה, ואינה שומרת זיכרון עצמאי בין הפעלה להפעלה אלא אם הוגדר לה זיכרון-חיצוני מפורש.
הבסיס: "LeadResearcher" ותת-הסוכנים במחקר-הרב-סוכני של Anthropic
הדוגמה המתועדת והמצוטטת ביותר לדפוס הזה מופיעה בפוסט ההנדסי של Anthropic מיוני 2025, "איך בנינו את מערכת המחקר הרב-סוכנית שלנו": סוכן-מוביל בשם LeadResearcher מפרק שאילתת-מחקר מורכבת, ואז מפעיל 3–5 תת-סוכנים (Subagents) במקביל, כל אחד עם חלון-הקשר נפרד משלו וגישה ל-3 כלים או יותר בו-זמנית. הפוסט מנסח את התועלת המרכזית במפורש: תת-סוכנים "מאפשרים דחיסת-מידע (compression) בזכות פעולה מקבילית עם חלונות-הקשר עצמאיים משלהם" — כלומר כל תת-סוכן סופג בעצמו את כל הפרטים הטכניים של תת-המשימה שלו, ומעביר ל-LeadResearcher רק את התמצית, לא את הגלם. לאחר שכל תת-הסוכנים מסיימים, הסוכן המוביל מסנתז את התוצאות ומחליט אם דרוש עוד סבב-מחקר, לפני העברה לסוכן-ציטוטים (CitationAgent) שמעצב את התשובה הסופית. המספרים המדויקים של אותו ניסוי (שיעור-ההשבחה, יחס-צריכת-הטוקנים, אחוזי-הקיצור בזמן-הריצה) מפורטים בערך הנפרד דפוס מתזמר-עובדים, שמתמקד ברמת-הזרימה הכוללת של אותה מערכת; הערך הזה מתמקד במנגנון-הבידוד של תת-הסוכן הבודד עצמו.
איך זה עובד בפועל: תת-סוכנים ב-Claude Code
ביישום מוצרי מוחשי, Claude Code (סביבת-הפיתוח מבוססת-הסוכן של Anthropic) הופך את דפוס-תת-הסוכן לתכונת-מוצר מוגדרת: מפתח יכול להגדיר תת-סוכן בקובץ-תצורה עם שם, תיאור-תפקיד, פרומפט-מערכת משלו, ורשימת-כלים מותרת (Read, Grep, Bash וכו') ורמת-הרשאות עצמאית. כשהסוכן הראשי נתקל במשימה שמתאימה לתיאור של תת-סוכן קיים — למשל "סקירת-קוד" או "חיפוש בקוד-המקור" — הוא יכול להאציל אליו את המשימה, בין אם אוטומטית לפי התאמת-תיאור, בקריאה מפורשת בשם ("@agent-code-reviewer"), או בהפעלת שיחה שלמה כתת-סוכן ייעודי. תת-הסוכן מקבל הקשר-פתיחה משלו (פרומפט-מערכת, תיאור-המשימה, לעיתים סטטוס-הגרסה של הפרויקט וכישורים מוטענים-מראש) אבל, וזה קריטי, אינו מקבל את היסטוריית-השיחה המלאה של הסוכן הראשי, קבצים שכבר נקראו, או זיכרון-האוטומטי של השיחה הראשית — רק את מה שהוגדר לו במפורש. קיימת גם הבחנה בין תת-סוכני-חזית, שחוסמים את השיחה הראשית עד לסיום, לבין תת-סוכני-רקע, שרצים במקביל להמשך העבודה ומדווחים ב"התראת-השלמה" נפרדת כשהם מסיימים — והסוכן הראשי ממתין לה בסבלנות אם נשאל על ההתקדמות. יכולות מובנות כמו תת-סוכן "Explore" (חיפוש-קוד בלבד, בלי הרשאת-כתיבה) ממחישות איך הגבלת-כלים לתת-סוכן משמשת גם ככלי-בטיחות וגם כאמצעי-מיקוד; ותוצאה שמוחזרת מתת-סוכן מסומנת במפורש כ"פלט תת-סוכן" ונסרקת לזיהוי-הוראות-נסתרות, כדי שתוכן זדוני שהתת-סוכן נתקל בו במהלך עבודתו לא יוכל "להתחזות" להוראה מהמשתמש עצמו כלפי הסוכן הראשי. תצורות-תת-סוכן ניתנות להגדרה גם ברמת-הפרויקט וגם ברמת-המשתמש (כך שאפשר לעשות בהן שימוש-חוזר בין פרויקטים שונים), והתיעוד הרשמי מציין במפורש שאחת המטרות המרכזיות בבחירת-מודל לכל תת-סוכן היא "שליטה בעלויות על-ידי ניתוב משימות למודלים מהירים וזולים יותר" כמו Haiku, כשהמשימה עצמה לא דורשת את המודל החזק-ביותר הזמין.
למה לא פשוט להוסיף עוד הוראות לפרומפט אחד: יתרונות ומחיר
היתרון המרכזי של דפוס תת-הסוכן הוא ניהול-הקשר: חלון-ההקשר של כל מודל-שפה מוגבל בגודלו, ומידע רב מדי — גם אם רלוונטי רגעית — מוריד את איכות ההיגיון לאורך שיחה ארוכה, תופעה המוכרת בשם "דעיכת-הקשר" (Context Rot). הפרדת עבודת-חיפוש או ניתוח מסיבית לתת-סוכן נפרד, שמחזיר רק תמצית, שומרת את ההקשר הראשי נקי לאורך זמן ומאפשרת לשיחה להימשך הרבה יותר בלי לאבד התמצאות. יתרון נוסף הוא בקרת-הרשאות ואכיפת-אחריות: תת-סוכן יכול לקבל גישה מוגבלת בהרבה מהסוכן הראשי — רק קריאת-קבצים, בלי הרשאת-רשת, בלי אפשרות למחוק — מה שמצמצם את שטח-הפגיעה אם משהו משתבש, ומאפשר שימוש-חוזר בתצורות מוגדרות היטב בין פרויקטים שונים. עם זאת, המחיר הוא כפול: עלות-חישוב (כל תת-סוכן מריץ קריאות-מודל עצמאיות משלו על הקשר-הפתיחה שלו, ולכן משימה מפוצלת לכמה תת-סוכנים עשויה לצרוך פי-כמה טוקנים ממה שהיא הייתה צורכת בסוכן בודד), וסיכון-תיאום — תת-סוכן שמבין את המשימה שלו באופן שונה מהכוונה המקורית עלול להחזיר תוצאה שלמה-כלפי-עצמה אך לא-מדויקת ביחס למטרה הרחבה יותר, ורק כשהסוכן הראשי מנסה לשלב את כל התוצאות יחד הטעות מתגלה — לעיתים מאוחר מדי בתהליך.
הבדל מדפוסים קרובים: תזמור-סוכנים, מערכת-רב-סוכנית, ודפוס מתזמר-עובדים
דפוס תת-הסוכן קרוב אך לא זהה למספר מונחים שכנים. "תזמור-סוכנים" (Agent Orchestration) ו"מערכת רב-סוכנית" (Multi-Agent System) מתארים את התמונה הרחבה — איך כמה סוכנים, בכלל, עובדים יחד ומי מנהל את הזרימה ביניהם, ומה קורה כשסוכן אחד תלוי בתוצר של סוכן אחר; דפוס-תת-הסוכן הוא הרכיב הממוקד יותר בתוך התמונה הזו: יחידת-הפעלה בודדת שמאופיינת בחלון-הקשר מבודד, כלים מוגבלים, והחזרת-תקציר בלבד — בין אם היא חלק ממערכת-תזמור מורכבת ובין אם היא הפעלה חד-פעמית ומבודדת של סוכן ל"משימת-צד" קטנה בתוך שיחה רגילה, בלי שום מנגנון-תזמור רב-שכבתי מסביב. "דפוס מתזמר-עובדים" (Orchestrator-Worker Pattern) קרוב עוד יותר — הוא בדיוק הדפוס שבו Anthropic משתמשת בתת-סוכנים בפועל, כלומר תת-הסוכן הוא "לבנת-הבניין" שממנה בנוי דפוס-המתזמר-עובדים, אך תת-סוכן יכול לשמש גם מחוץ להקשר של פירוק-משימה-דינמי-ומקבילי — למשל הפעלה בודדת, ליניארית, של תת-סוכן יחיד למשימת-חיפוש ממוקדת, בלי שום "תזמור" רב-שלבי מסביב. במילים אחרות: תת-סוכן הוא תשובה לשאלה "איך יחידת-עבודה בודדת נשארת מבודדת ומרוכזת", בעוד תזמור-סוכנים, מערכת-רב-סוכנית ומתזמר-עובדים עונים על השאלה הרחבה יותר של "איך כמה יחידות כאלה מתואמות ביניהן".
הקשיים ההנדסיים: כשל-מתרבה וצורך בתיעוד-מפורט
הפוסט של Anthropic מתעד גם את הקשיים ההנדסיים של הדפוס, לא רק את היתרונות: מערכת מרובת-תת-סוכנים היא "סטוכסטית" — גם שינוי קטן בפרומפט-הפתיחה עשוי לגרום להבדלי-התנהגות גדולים במורד-הזרם, ותקלה בתת-סוכן בודד עלולה "להתרבות" (cascading) ולפגוע בתוצאה הסופית בלי שהסוכן הראשי בהכרח מזהה את המקור. בגלל זה Anthropic מדגישה חשיבות של תיעוד-מפורט (tracing) לאורך כל שרשרת-ההאצלה — לא רק לוג של הסוכן הראשי, אלא גם של כל תת-סוכן בנפרד — כדי שדיבוג בדיעבד יהיה אפשרי בכלל כשמשהו לא מתנהג כצפוי בתוך שרשרת ארוכה של הפעלות מקוננות. אתגר נוסף שהפוסט מציין: תיאום-בין-תת-סוכנים חייב הנחיה מפורשת וממוקדת, אחרת תת-סוכנים נוטים "לכפול" עבודה זה של זה — למשל, שני תת-סוכנים שחוקרים את אותה שאלה מזוויות דומות מדי, ומבזבזים תקציב-חישוב על אותו מידע פעמיים — בעיה שנפתרת בעיקר על-ידי ניסוח-קפדני של גבולות-האחריות של כל תת-סוכן מראש, בפרומפט-ההאצלה עצמו, ולא בדיעבד אחרי שהתוצאות כבר חזרו.
שכבות-קינון, רשימת-אחים, ולמה תת-סוכנים לא יכולים ליצור שרשרת אינסופית
מימושים מוצריים של הדפוס נאלצים להתמודד עם שאלה מעשית שלא קיימת בתיאור-התיאורטי הפשוט: מה קורה אם תת-סוכן עצמו רוצה להפעיל תת-סוכן משלו? ב-Claude Code, לדוגמה, הדבר אפשרי — תת-סוכן יכול להאציל תת-משימה לתת-סוכן נוסף, וכך נוצרת שרשרת-קינון (nesting) של כמה רמות — אבל המערכת מגבילה במפורש את עומק-הקינון המרבי (ברירת-המחדל בתיעוד הנוכחי היא עד שלוש רמות מתחת לשיחה הראשית), כדי למנוע מצב שבו תת-סוכן מפעיל תת-סוכן שמפעיל תת-סוכן ללא-סוף, שיצרוך משאבי-חישוב באופן בלתי-נשלט. תוספת-תכנון נוספת היא "רשימת-אחים" (Sibling Roster) — רשימה של תת-הסוכנים המקבילים-האחרים שפועלים באותו רגע, שנמסרת לתת-סוכן כחלק מהקשר-הפתיחה שלו כשיש בידיו כלי-שליחת-הודעות, כדי שיוכל לפנות אליהם ישירות ולא רק לדווח חזרה כלפי מעלה.