תהליכים דינמיים: מתי להפעיל עשרות סוכנים במקביל ב-Claude Code

למה התהליכים הדינמיים מבלבלים גם משתמשים ותיקים?

מי שכבר עובד עם סביבת העבודה של Claude Code מכיר לא מעט דרכים לחלק עבודה: סקילים שחוזרים על מתכון קבוע, תתי-סוכנים שעובדים בצד כדי לא ללכלך את השיחה הראשית, וצוותי סוכנים שמדברים ביניהם. יחד עם השקת Opus 4.8 נוספה שכבה חדשה, התהליכים הדינמיים (Dynamic Workflows), והשאלה הראשונה שכמעט כולם שואלים היא פשוטה: במה זה שונה ממה שכבר יש?

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

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

מה קורה מאחורי הקלעים כשמפעילים תהליך דינמי?

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

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

// Simplified illustration of a dynamic workflow
const skills = await listSkills();          // e.g. 41 skill files

const reviews = await parallel(skills.map(s => () =>
  agent(`Grade ${s.name}: clarity, frontmatter, triggers`,
        { model: 'haiku' })
));

const report = await agent(
  `Rank all skills worst to best and suggest one fix each:
   ${JSON.stringify(reviews)}`,
  { model: 'opus' }
);
return report;

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

רוחב מול עומק: מתי /goal ומתי תהליך דינמי?

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

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

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

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

כמה עולה תהליך דינמי, ומה שורף את התקציב?

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

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

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

איך מריצים תהליך דינמי ראשון בלי להישרף?

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

Set up a dynamic workflow that audits my Claude Code skills
in two places: ~/.claude/skills and ./.claude/skills.
Grade each skill on clarity, frontmatter (pass/fail) and
trigger quality, and give the single highest-value fix.
Run every grader on Haiku. One final agent ranks all skills
worst to best and writes an HTML report.

my-project/
  .claude/
    skills/
    workflows/
      skill-audit.js
      feature-ranking.js

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

האם התהליכים הדינמיים נועדו לגרום לנו לשרוף טוקנים?

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

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

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

חמש תובנות על התהליכים הדינמיים

סיכום: איפה התהליכים הדינמיים נכנסים לארגז הכלים?

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

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

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