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

ב-22 באוקטובר 2026 פרסם צוות ה-Applied AI של Anthropic מאמר שהולך נגד הכיוון של רוב מי שבונה סוכנים היום. השורה המרכזית: בכמה פריסות ארגוניות שהצוות השווה, סוכן אחד עם סקילים עקף לעיתים קרובות גם פרומפט ענק אחד וגם מערכת של סוכני משנה, באיכות, ולרוב גם בעלות ובזמן לכל משימה.

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

למה כולם בונים צוות סוכנים מלכתחילה?

כי זה נראה כמו הארגון. כל צוות בחברה אחראי על מוצר אחד, אז כל צוות בונה סוכן משלו, וצוות פלטפורמה מרכזי בונה מתזמר מעל כולם. Anthropic קוראת לזה בשם המוכר: חוק קונווי (Conway’s law): ארכיטקטורת הסוכנים הופכת לעותק של המבנה הארגוני.

על הנייר זה הפתרון הפשוט ביותר. בפועל, לפי המאמר, הוא מייצר חמש בעיות שחוזרות שוב ושוב:

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

מה Anthropic מציעה במקום?

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

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

ומה עם הבעיה שבגללה פיצלו מלכתחילה, קונטקסט נפוח? בשביל זה יש חשיפה הדרגתית. הסוכן רואה רק תיאור קצר של כל סקיל ושל כל כלי, והתוכן המלא נטען רק כשצריך אותו: סקילים לידע, ו-tool search לכלים. Anthropic מביאה דוגמה מהבית: את פרומפט המערכת של קלוד קוד למודלים המתקדמים היא קיצצה ביותר מ-80%, בין השאר בזכות טעינה הדרגתית של סקילים וכלים. (על המחיר של סקיל שנטען בכל סבב, ראו את הטיפ על עלות הסקילים.)

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

מתי סוכני משנה עדיין התשובה הנכונה?

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

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

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

איך עוברים לסוכן אחד בלי לשבור את מה שעובד?

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

1. סט בדיקות (eval) קודם לכל. סט אחד מקצה לקצה, בבעלות צוות מרכזי, ולצידו סטים קטנים שכל צוות שולח עם הסקיל שלו. גם עשר דוגמאות זהב מספיקות כדי להתחיל. כל עוד יש מתזמר, מודדים גם אם הוא בחר בסוכן הנכון. אחרי האיחוד, מודדים אם הסוכן טען את הסקיל הנכון או קרא לכלי הנכון.
2. ממזגים זוגות צמודים. סוכנים שתמיד רצים ביחד, נוגעים באותם נתונים או מזינים זה את זה הם המועמדים הראשונים. אם חלק משמעותי מהתנועה הוא סוכן אחד ומיד אחריו השני, זה זוג.
3. קוראים לסוכן משנה ככלי. כשאחד משלושת התנאים מתקיים ומשאירים סוכן, הסוכן הראשי קורא לו ככלי וממשיך להחזיק את השיחה. זה צעד ראשון טוב כי אין צורך לשכתב אף סוכן, ומקבלים ציון בסיס. העברה מלאה של השיחה מוצדקת רק כשסוכן המשנה חייב לדבר עם המשתמש ישירות.
4. מאחדים אחד-אחד. ההוראות של סוכן המשנה הופכות לסקיל, הקריאות שלו ל-API הופכות לכלים ב-MCP, ומשווים את הציון עם ובלי. סוכן נשאר סוכן רק אם הגרסה המאוחדת יצאה גרועה יותר.

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

מה הופך לכלי ומה לסקיל?

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

• כלי: כשהסוכן צריך לבצע פעולה, לקרוא נתונים חיים ממערכת או להחזיר תוצאה במבנה קבוע. מקבצים כלים לפי כוונת המשתמש ולא כלי לכל נקודת API, כי לפי Anthropic מעבר ל-30 עד 50 הגדרות כלים בפרומפט, בחירת הכלי מתחילה להידרדר. גם הרשאות עוברות לכלי: הכלי בודק מה המשתמש רשאי לראות ומחזיר סירוב שהמודל יכול לקרוא, כך שלולאה אחת משרתת משתמשים עם הרשאות שונות.
• סקיל: כשהסוכן צריך לדעת איך צוות מסוים עובד, הצעדים, הכללים ושיקולי הדעת שישבו קודם בפרומפט של סוכן המשנה. כל צוות נשאר בעלים של הסקילים שלו, וצוות מרכזי קטן מחזיק את פרומפט המערכת ואת האיכות מקצה לקצה.
• מאגר ידע: מדיניות, הגדרות מדדים ומפרטי מוצר שהסוכן צריך רק לפעמים. הם יושבים מאחורי כלי חיפוש או כקבצי עזר בתוך סקיל. מה שלא עושים: קוד ששולף ומדביק אותם לפרומפט מראש.

אם כבר יש לכם הרבה כלים ב-MCP, הטיפ על tool search מסביר איך עובדת טעינה נדחית של הגדרות כלים, ומה זה עושה ל-cache.

איך מריצים את ערכת ההגירה בקלוד קוד?

עם המאמר Anthropic פרסמה ב-GitHub את single-agent-loop-kit, ברישיון Apache-2.0. בלב הערכה יש סקיל לקלוד קוד שעובר על הקוד של המערכת שלכם, בלי תלות בפריימוורק מסוים. השימוש פשוט:

git clone https://github.com/anthropics/single-agent-loop-kit
cp -r single-agent-loop-kit/skill <your-repo>/.claude/skills/single-agent-loop

ואז פותחים את קלוד קוד בריפו של הסוכן וכותבים לו Run the single-agent-loop skill. הוא מתחיל במיפוי, ועוצר כדי להציג המלצה לכל סוכן משנה: לאחד, למזג, לקרוא לו ככלי או להשאיר. משם הוא עובד לפי התוכנית שינוי אחד בכל פעם, עם ריצת בדיקות והשוואה לכל שינוי, ואתם מחליטים מה נשאר. הוא עוצר תמיד באותן נקודות, כולל לפני כל ריצה בתשלום, עם הערכת טוקנים.

רוצים לראות את זה לפני שנוגעים במערכת אמיתית? בערכה יש דוגמה מוכנה, סוכן תמיכה עם נתב ושישה סוכני משנה, ובדיקת “צנרת” שלא צריכה מפתח API ולא עולה כלום. הסקיל גם מפנה לפקודות שכבר קיימות בקלוד קוד: ‎/claude-api build-eval‎ לבניית סט הבדיקות, ‎/claude-api hillclimb‎ לשיפור תיאור של סקיל או כלי כשהאיחוד יוצא חלש, ‎/claude-api prompt-audit‎ לאיתור הוראות שנכתבו למודלים ישנים, ‎/claude-api cost-optimize‎ לקיצוץ עלויות, ו-‎/skill-doctor‎ כדי לראות כמה כל סקיל עולה וכמה משתמשים בו.

איפה זה הברקה ואיפה זה סיכון אמיתי?

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

• אין מספרים מפורטים. “כמה פריסות ארגוניות” ו”לעיתים קרובות” הם לא מחקר. המספר הקשיח היחיד במאמר הוא פי שניים במהירות אצל לקוח אחד. גם בריצת הדוגמה שבערכה, Anthropic מחקה את התוצאות המדודות מהתיעוד.
• הערכה עצמה מודה במגבלות. לפי ה-README היא “מימוש לדוגמה” שאינו מתוחזק ואינו מקבל תרומות. שלבי המיזוג והתחזוקה לא הורצו על מודל אמיתי, והיא לא נוסתה על אף מערכת מלבד הדוגמה.
• סוכן אחד הוא נקודת כשל אחת. הדוגמה מהמאמר עצמו, סוכן שענה לבד במקום לשאול, היא בדיוק הסיכון. בלי סט בדיקות שמכסה כל שרשרת, איחוד יכול לשבור תהליך בשקט.
• זה מאמר של ספקית. חשיפה הדרגתית, tool search וסקילים הם יכולות של הפלטפורמה של Anthropic. הלוגיקה תקפה גם מחוץ לה, אבל שווה לזכור מי כותב.

ומי שמשתמש בקלוד קוד לבד, בלי מערכת ארגונית? המאמר מדבר על סוכנים שארגונים בונים על Claude Platform, אבל המבחן שלו מתאים גם לסוכני משנה שמגדירים ב-‎.claude/agents‎. אם סוכן משנה לא עונה על אף אחד משלושת התנאים, סביר שסקיל יעשה את אותה עבודה בלי לאבד קונטקסט בדרך. על מתי סוכן משנה כן מוצדק בעבודה היומיומית, ראו את המדריך לסוכני משנה.

שורה תחתונה

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

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