6.6 זרימות רב סוכן הרצאה

הגענו להרצאה האחרונה של הפרק, וכאן נחבר את כל מה שלמדנו. ראינו tools חיצוניים דרך MCP, sub-agents שמבודדים עבודה, הוקים שאוכפים משמעת, וskills שאורזות זרימות. עכשיו נשאל את השאלה הגדולה: איך מנצחים על משימה שגדולה מדי בשביל agent אחד? התשובה היא זרימות רב-agent - orchestration של כמה agents שעובדים יחד. נדבר על תכנון-ואז-ביצוע בקנה מידה גדול, על נקודות ביקורת לסקירה, ועל הסיכונים שבאוטונומיה - ואיך נשארים בשליטה. זו הרצאה על שיטת עבודה יותר מאשר על תחביר.

למה agent אחד לא מספיק - the scaling problem

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

זרימה רב-agent פותרת את שתי המגבלות בעיקרון אחד: חלק וכבוש. מפרקים את המשימה הגדולה לתת-משימות עצמאיות, כל אחת מקבלת sub-agent עם context טרי, וagent מתזמר (orchestrator) מרכיב את התוצאות.

המבנה הבסיסי - orchestrator and workers

הדפוס הנפוץ הוא מתזמר ועובדים. הagent הראשי הוא המתזמר: הוא מחזיק את התמונה הגדולה, מחלק עבודה, ומסנתז. העובדים הם sub-agents, כל אחד עם משימה תחומה.

+------------------ orchestrator ------------------+
|  holds the overall plan and the big picture               |
|                                                          |
|   +--- Worker A ---+  +--- Worker B ---+  +-- Worker C --+
|   | auth module    |  | DB module      |  | API module   |
|   | fresh context  |  | fresh context  |  | fresh context |
|   +----------------+  +----------------+  +--------------+
|          |                   |                   |       |
|          v                   v                   v       |
|       summary              summary              summary  |
|                                                          |
|   the orchestrator synthesizes the three summaries into one picture |
+----------------------------------------------------------+

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

תכנון-ואז-ביצוע - plan then execute

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

• שלב התכנון: קודם, הagent חוקר ומייצר תוכנית - אילו תת-משימות יש, באיזה סדר, ומה התלויות ביניהן. בשלב הזה אף שורת קוד לא נכתבת. Claude Code תומך בזה עם מצב תכנון (plan mode), שבו הagent חוקר בקריאה בלבד ומציג תוכנית לפני שהוא נוגע בקוד.
• שלב הביצוע: רק אחרי שאישרתם את התוכנית, הagent מבצע אותה, תת-משימה אחר תת-משימה.

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

דפוס מומלץ: בקשו מהagent לכתוב את התוכנית לקובץ (למשל PLAN.md), עברו עליה, תקנו, ורק אז אמרו לו להתחיל. כשהתוכנית בקובץ, גם הsub-agents יכולים לקרוא ממנה את החלק שלהם.

נקודות ביקורת - review checkpoints

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

יש שתי דרכים לנקודות ביקורת:

• ביקורת אנושית: אחרי כל תת-משימה גדולה, הagent עוצר ומציג מה עשה. אתם מאשרים או מתקנים. זה איטי יותר אבל בטוח.
• ביקורת אוטומטית: sub-agent ייעודי לסקירה (למשל code-reviewer מהרצאה 6.3) בודק את העבודה של agent אחר. שילוב חזק: עובד מבצע, סוקר בודק, והמתזמר מחליט אם להמשיך.

אפשר לאכוף נקודות ביקורת גם עם הוקים. הוק על אירוע Stop שמריץ בדיקות ולא נותן לagent לסיים כל עוד הן אדומות, הוא נקודת ביקורת אוטומטית שאי אפשר לדלג עליה. כאן כל הtools של הפרק מתחברים: MCP מביא נתונים, sub-agents מבודדים עבודה, הוקים אוכפים, וskills מתקננות את התהליך.

דוגמה: בניית פיצ'ר - worked example

בואו נראה איך זה נראה בפועל עבור פיצ'ר בינוני. נניח "הוסף מערכת התראות למשתמשים":

1. planning (plan mode)
   the agent investigates the codebase, writes PLAN.md:
   - notifications schema in the DB
   - endpoint for creating and reading
   - UI component
   - tests
   -> you review the plan and approve it

2. parallel execution (sub-agents)
   - Worker A: adds the schema and the migration
   - Worker B: writes the endpoints
   (B depends on A, so it runs after it; UI can run in parallel)

3. review checkpoint
   - the code-reviewer agent reviews the code from A and B
   - the Stop hook runs the tests

4. synthesis
   the orchestrator assembles everything, runs integration tests, and reports back to you

שימו לב לתלויות: לא הכל רץ במקביל. תת-משימות תלויות רצות בסדר, ורק עצמאיות רצות יחד. זיהוי התלויות הוא בדיוק מה שקורה בשלב התכנון.

sub-agents מול צוותי agents - subagents vs teams

כדאי להבחין בין שתי צורות של ריבוי agents ב-Claude Code, כי הן מתאימות למשימות שונות:

• סוכני משנה - subagents: עובדים בתוך סשן אחד. הagent הראשי מאציל, מקבל סיכומים, ומסנתז. זה מה שראינו בהרצאה 6.3, וזה המנגנון הבסיסי לרוב הזרימות.
• צוותי agents וagents רקע - agent teams: לריבוי סשנים עצמאיים שרצים במקביל, כל אחד עם הcontext שלו, שאפשר לנטר ממקום אחד. זה מתאים למקבילות מתמשכת שחורגת מcontext window בודד.

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

נקודת מפתח לגבי תקשורת בין agents: החל מגרסאות אחרונות, sub-agent מתייחס להודעות מהagent ששיגר אותו כהכוונת משימה רגילה, כולל תיקוני מסלול תוך כדי. אבל שתי מגבלות תמיד בתוקף - שום הודעה מagent אחר אינה נחשבת לאישור הרשאה מטעמכם, ושום הודעה מagent לא יכולה לשנות את הגדרות ההרשאה או ה-CLAUDE.md. רק מערכת ההרשאות או ההודעות שלכם מעניקות אישור. זו הגנה חשובה: גם בזרימה אוטונומית, אתם נשארים השער האחרון להחלטות רגישות.

עומק ההאצלה - nesting depth

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

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

הסיכונים - the risks

כוח מביא אחריות. זרימה רב-agent אוטונומית טומנת סיכונים אמיתיים שחייבים להכיר:

• סחף ממטרה - drift: ככל שהagent רץ יותר זמן בלי בקרה, כך גדל הסיכוי שהוא ייסחף מהכוונה המקורית. תת-משימה שהובנה מעט שגוי מתפשטת לכל מה שבא אחריה.
• הגברת שגיאות - error amplification: אם המתזמר מעביר לעובד context שגוי, כל העובדים בונים על בסיס פגום. שגיאה אחת בתכנון הופכת לעשר שגיאות בביצוע.
• גודש בcontext: אירוני, אבל אם כל sub-agent מחזיר סיכום ארוך, הcontext של המתזמר מתמלא בדיוק כמו שרצינו למנוע. סיכומים חייבים להיות קצרים.
• עלות ואיבוד שקיפות: הרבה agents במקביל עולים יותר, וקשה יותר לעקוב מה כל אחד עושה. קל לאבד את התחושה מה בדיוק קורה.

איך נשארים בשליטה - staying in control

הנה הכללים המעשיים לשמור על שליטה בזרימה רב-agent:

• תכננו לפני שמבצעים, תמיד. אשרו את התוכנית בכתב.
• הגבילו את היקף כל sub-agent. משימה תחומה עם context ברור נסחפת פחות.
• הגבילו tools. agent חוקר צריך להיות קריאה בלבד. תנו הרשאות כתיבה רק למי שחייב.
• הכניסו נקודות ביקורת. אל תתנו לזרימה לרוץ שעה בלי עצירה. עדיף לבדוק אחרי כל שלב.
• דרשו סיכומים קצרים. אמרו במפורש לsub-agents להחזיר מסקנה תמציתית, לא דוח מלא.
• התחילו קטן. לפני שמאצילים מערכת שלמה, נסו זרימה של שני-שלושה agents ובדקו שהיא מתנהגת כצפוי.

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

איך זה נראה ב-Claude Code - in practice

בואו נחבר את הרעיונות לפעולות קונקרטיות בtool. זרימה רב-agent טיפוסית מורכבת מהצעדים האלה:

• נכנסים למצב תכנון: מבקשים מ-Claude תוכנית לפני ביצוע. הוא חוקר בקריאה בלבד ומציג תוכנית. אתם מאשרים או מתקנים לפני שנוגעים בקוד.
• מבקשים מקבילות מפורשת: "חקור את שלושת המודולים במקביל בsub-agents נפרדים". Claude משגר sub-agents, ואתם רואים אותם בפאנל מתחת לשורת הפקודה.
• מנטרים תוך כדי: הפאנל מראה כל agent ואת מצבו. אפשר לפתוח agent, לראות את התמליל שלו, ואף לשלוח לו הודעת תיקון תוך כדי ריצה.
• מוסיפים אכיפה: הוק Stop שמריץ בדיקות, וagent code-reviewer שסוקר. אלה נקודות הביקורת האוטומטיות.

השילוב הזה הוא בדיוק הסינתזה של הפרק. כל tool שלמדנו תורם את חלקו: MCP מרחיב את הtools שהעובדים יכולים להשתמש בהם, sub-agents מבודדים את העבודה הרועשת, skills מתקננות את התהליכים החוזרים, והוקים אוכפים את המשמעת. אף אחד מהם לבדו לא פותר משימה גדולה, אבל ביחד הם מאפשרים לכם לתזמר עבודה שהיא הרבה מעבר למה שagent בודד יכול.

סיכום

בהרצאה הזו למדנו:

• agent אחד נתקל בשתי מגבלות במשימה גדולה: context window מתמלא, והמיקוד נפגע. זרימה רב-agent פותרת בחלק וכבוש.
• הדפוס המרכזי הוא מתזמר ועובדים: הagent הראשי מחזיק את התמונה הגדולה ומחלק עבודה לsub-agents עם context טרי, שכל אחד מחזיר רק סיכום.
• תכנון-ואז-ביצוע: קודם תוכנית כתובה (עם plan mode או קובץ PLAN.md) שאתם מאשרים, ורק אז ביצוע. תוכנית היא חוזה שזול לתקן לפני שמושקעת עבודה.
• נקודות ביקורת מונעות בזבוז: ביקורת אנושית אחרי כל שלב גדול, agent סוקר ייעודי, או הוק Stop שמריץ בדיקות. כאן כל tool הפרק מתחברים.
• מזהים תלויות: תת-משימות תלויות רצות בסדר, עצמאיות רצות במקביל.
• הסיכונים: סחף ממטרה, הגברת שגיאות, גודש בcontext מסיכומים ארוכים, ועלות ואיבוד שקיפות.
• שליטה: תכננו לפני ביצוע, הגבילו היקף וtools לכל agent, הכניסו נקודות ביקורת, דרשו סיכומים קצרים, והתחילו קטן. אוטונומיה היא "שגר, בדוק, תקן מוקדם" - לא "שגר ושכח". השיפוט נשאר באחריותכם.