Agent Teams — צוותי סוכנים ומערכות מרובות סוכנים

מסוכן בודד לצוות סוכנים

עד עכשיו כל מה שעשינו בקורס הזה היה עם סוכן בודד. בפרק 1 הרצנו Claude Code ב-headless mode — סוכן אחד שמבצע משימה אחת ומחזיר תוצאה. בפרק 2 שלחנו אותו לעבוד ב-GitHub Actions — עדיין סוכן אחד, רק באוטומציה. בפרקים 3 ו-4 בנינו סוכנים מתוכנתים עם ה-SDK ב-Python וב-TypeScript — כל סוכן לבד בעולם שלו, מטפל במשימה ממוקדת.

זה עובד מעולה למשימות ממוקדות. אבל מה קורה כשהמשימה גדולה מדי לסוכן אחד?

תחשבו על סטארטאפ ישראלי שצריך להוסיף תמיכה באמצעי תשלום חדש — למשל Apple Pay. צריך לשנות את ה-Frontend (כפתור תשלום חדש, טופס, validation), את ה-Backend (endpoint חדש, business logic, אינטגרציה עם Apple), את ה-Database (מיגרציה, סכמה חדשה, שדות נוספים), ואת ה-Infrastructure (environment variables, secrets, deployment config). סוכן בודד יכול לעשות את כל זה — אבל סדרתית. קודם ה-Frontend, אחר כך ה-Backend, אחר כך ה-Database, אחר כך ה-Infrastructure. זה לוקח שעה-שעתיים כשסוכן אחד עושה הכל ברצף. מה אם ארבעה סוכנים יעבדו על ארבע השכבות במקביל?

Agent Teams (צוותי סוכנים) — זה הפיצ'ר הניסיוני (research preview) של Claude Code שבדיוק מאפשר את זה. כמה מופעי Claude עובדים כצוות: אחד מוביל (Lead), האחרים עובדים במקביל (Teammates), וה-Lead מסנתז הכל לתשובה אחת קוהרנטית. זה לא רק "הרצת כמה סוכנים ברקע" — זה מערכת מתואמת שבה הסוכנים יכולים לדבר ביניהם.

ההבדל הקריטי מ-Subagents שלמדנו בפרקים קודמים: ב-Subagents, כל child agent מדווח רק ל-parent שלו — הוא לא יכול לדבר עם children אחרים. זו תקשורת חד-כיוונית: Parent שולח משימה, Child מחזיר תוצאה, Parent ממשיך. ב-Agent Teams, ה-Teammates יכולים לתקשר ישירות ביניהם, לשתף ממצאים, ולתאם עבודה בצורה עצמאית. זה ההבדל בין מנהל שמאציל לעובדים (subagents) לבין חדר פיתוח שבו מפתחים משתפים פעולה (teams).

בואו נראה את שלוש הגישות שלמדנו בקורס — בטבלה אחת:

הדפוס Lead + Teammates

הארכיטקטורה של Agent Teams מבוססת על דפוס פשוט וחזק: Lead + Teammates. ה-Lead הוא הסוכן שאתם מדברים איתו — זה אותו Claude Code שפתחתם בטרמינל. הוא מקבל את המשימה הגדולה מכם, מפרק אותה לתת-משימות, ומחלק אותן ל-Teammates. כל Teammate עובד בצורה עצמאית בחלון הקשר שלו (context window נפרד), עם גישה מלאה ל-tools — קריאת קבצים, כתיבה, הרצת פקודות, ואפילו חיפוש באינטרנט. כשכולם מסיימים, ה-Teammates מדווחים ל-Lead, וה-Lead מסנתז את הכל לתשובה אחת שחוזרת אליכם.

זרימת התקשורת נראית כך:

אתם → Lead → Teammates (עובדים במקביל) → Lead (סינתזה) → אתם

בואו נראה איך זה עובד בפועל עם דוגמה קונקרטית. נניח שאתם אומרים ל-Claude Code (עם Teams מופעל): "תעשה ריפקטורינג למערכת ה-authentication שלנו." ה-Lead לא נכנס מיד לקוד — הוא מפרק את המשימה:

• Teammate 1 (Code Reviewer): "סקור את הקוד הנוכחי של ה-authentication בתיקיית src/auth/ — תמצא חולשות, code smells, תלויות ישנות, ודפוסים בעייתיים. צור דוח בקובץ code-review-report.md."
• Teammate 2 (Researcher): "תחקור best practices עדכניים ל-authentication ב-2026 — JWT rotation, OAuth 2.1, passkeys, אימות דו-שלבי. אל תערוך קבצים — רק צור best-practices-report.md."
• Teammate 3 (Architect): "תעצב את הארכיטקטורה החדשה — API contracts, data flow, migration path מהקוד הנוכחי לחדש. התייחס לדוחות של Teammates 1 ו-2 כשהם מוכנים. צור new-architecture.md."

שלושת ה-Teammates מתחילים לעבוד במקביל. Teammate 1 סורק קבצים עם Grep ו-Read, Teammate 2 חוקר עם WebSearch, Teammate 3 מתחיל לתכנן ארכיטקטורה על בסיס מה שכבר יודע. כשהדוחות של 1 ו-2 מוכנים (בתור קבצים על ה-filesystem), Teammate 3 יכול לקרוא אותם ולשלב ממצאים.

כשכולם מסיימים, ה-Lead מקבל שלושה דיווחים ומסנתז: "על בסיס הסקירה של Teammate 1 שמצא שהטוקנים לא מסתובבים וה-password hashing משתמש ב-MD5, המחקר של Teammate 2 שממליץ על JWT rotation עם refresh tokens וpasskeys כ-MFA, ותכנון הארכיטקטורה של Teammate 3 — הנה תוכנית מיגרציה בת 4 שלבים."

הנקודה החשובה: ה-Lead יכול גם להקצות מחדש משימות. אם Teammate 2 מדווח שלא מצא מידע מספיק על passkeys, ה-Lead יכול לשלוח אותו לכיוון אחר ("תתמקד רק ב-JWT ו-OAuth"), או להעביר את המשימה ל-Teammate אחר. זו לא מערכת "fire and forget" — ה-Lead מנהל באופן אקטיבי.

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

חלוקת משימות ותיאום

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

גבולות ברורים הם הכל. אם Teammate A צריך את הפלט של Teammate B כדי להתחיל — זה לא צוות, זה Pipeline (פרק 6). צוות עובד כשהמשימות מקביליות באמת. דוגמה טובה: שלושה Teammates שכל אחד סוקר חלק אחר של הקוד. דוגמה גרועה: Teammate 1 בונה API, Teammate 2 מחכה ל-API של Teammate 1 כדי לבנות Frontend שמתחבר אליו.

שיתוף נתונים בין Teammates — היתרון וגם הסיכון

ה-Teammates עובדים על אותו filesystem. זה יתרון ענק — הם יכולים לקרוא את קבצי הפלט של אחרים, לעיין בקוד הקיים, ולגשת לכל מה שיש ב-repository. אבל זה גם אומר שקונפליקטים אפשריים. אם שני Teammates עורכים את אותו קובץ — אחד ידרוס את השני בלי אזהרה, ולא תראו הודעת שגיאה.

הפתרון: דפוס ה-Manifest. ה-Lead (או אתם, ב-prompt) יוצר קובץ team-plan.md שמתעד בבירור: מי עושה מה, באילו קבצים כל Teammate עובד, ומה הפלט הצפוי. ה-Teammates קוראים את ה-manifest ויודעים לא לגעת בקבצים של אחרים. זה כמו גבולות גזרה בצבא — כל יחידה יודעת בדיוק איפה שלה ואיפה של אחרים.

# Team Plan: Authentication Refactoring
# Created by Lead on 2026-03-24

## Objective
Refactor the authentication system to use JWT rotation
and add passkey support.

## Lead Role
- Synthesize all findings into migration plan
- Resolve conflicts between teammate recommendations
- Final output: migration-plan.md

## Teammate 1: Code Reviewer
- Focus: Review current auth implementation
- Files (READ ONLY): src/auth/**, src/middleware/auth.ts
- Output: code-review-report.md
- DO NOT edit any source files

## Teammate 2: Research
- No file editing -- web search only
- Research: JWT rotation, OAuth 2.1, passkeys
- Output: best-practices-report.md

## Teammate 3: Architecture
- Files (WRITE): docs/architecture/**
- Output: new-architecture.md
- Reference reports from Teammates 1 and 2

## Conflict Prevention
- Only Teammate 3 writes to docs/
- Teammates 1 and 2 write ONLY to project root
- No teammate edits src/ files in this phase

שימו לב לסעיף Conflict Prevention ב-manifest. זה הסעיף הכי חשוב. בלעדיו, ב-50% מהמקרים (הערכה מניסיון) יהיה קונפליקט כלשהו — Teammate שעורך קובץ שלא שלו, או שניים שכותבים לאותו מיקום.

תקשורת מעבר ל-filesystem

מעבר לקבצים, ה-Teammates יכולים גם לתקשר ישירות דרך מנגנון ה-Teams. זה אומר ש-Teammate 3 (הארכיטקט) יכול לשאול את Teammate 1 (ה-Code Reviewer) שאלה ספציפית: "מצאת תלויות במודול X?" בלי לעבור דרך ה-Lead. זה היתרון המרכזי על Subagents — ב-subagents, כל תקשורת חייבת לעבור דרך ה-parent.

Competing Hypotheses Debugging

זה ה-use case הרוצח של Agent Teams — ולטעמי, הסיבה הכי משכנעת להשתמש בצוותים. כשיש לכם באג ואתם לא יודעים איפה לחפש, רוב המפתחים מתחילים לחקור סדרתית: קודם בודקים ב-Frontend, לא מוצאים כלום, עוברים ל-Backend, בודקים 20 דקות, לא מוצאים, עוברים ל-Database — ואז מגלים שהבעיה הייתה ב-caching layer. שעה אחת, שליש ממנה בזבוז מוחלט.

Competing Hypotheses (השערות מתחרות) הופך את הגישה הזו על הפנים. במקום לחקור סדרתית, שלושה Teammates חוקרים את אותו באג מזוויות שונות במקביל:

• Teammate 1 (Frontend Investigator): "תחקור אם זו בעיית Frontend rendering — בדוק את ה-DOM, state management, event handlers, API calls מצד הלקוח."
• Teammate 2 (Backend Investigator): "תחקור אם זו בעיית Backend API — בדוק את ה-endpoint, middleware, request parsing, response format, error handling."
• Teammate 3 (Data Investigator): "תחקור אם זו בעיית Database או Data — בדוק את ה-queries, indexes, caching layer, data consistency, migration issues."

שלושתם חוקרים בו-זמנית. כל אחד סורק קבצים, מריץ grep, בודק logs, מזהה דפוסים חשודים. Teammate 2 מוצא שה-API מחזיר נתונים מ-cache ישן כי ה-cache invalidation שבור. Teammates 1 ו-3 לא מצאו בעיות משמעותיות בתחומים שלהם. ה-Lead מסנתז: "Teammate 2 מצא שה-API מחזיר נתונים מ-Redis cache שלא עודכן אחרי write. Teammates 1 ו-3 לא מצאו בעיות. הבאג ב-caching layer — ספציפית ב-cache invalidation logic."

הזמנים: במקום שעה של חקירה סדרתית, מצאנו את הבעיה ב-20 דקות. העלות: בערך פי 3 מחקירה בודדת — שלושה Teammates = שלוש ריצות מקביליות. אבל פי 3 ב-$1-2 זה $3-6, ופי שליש בזמן זה 40 דקות חסכון. בישראל, שעת מפתח עולה 150-300 ש"ח — אז 40 דקות שנחסכו שוות 100-200 ש"ח. ה-ROI ברור.

הפורמט המומלץ ל-Competing Hypotheses prompt

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

I have a bug: users report that their profile changes
don't persist after refresh. This started 3 days ago
after a deploy.

Investigate using 3 competing hypotheses in parallel:

Hypothesis A (Frontend):
The form might not be sending the data correctly.
- Check: src/components/ProfileForm.tsx
- Check: src/hooks/useProfileUpdate.ts
- Look for: missing await, incorrect API URL,
  state not updating after submit, form not
  reading input values correctly

Hypothesis B (Backend):
The API might receive data but not save it properly.
- Check: src/api/routes/profile.ts
- Check: src/api/middleware/validation.ts
- Look for: missing fields in validation schema,
  errors silently caught and swallowed,
  wrong table/collection name

Hypothesis C (Database/Cache):
The save might work but reads return stale data.
- Check: src/db/queries/profile.ts
- Check: src/cache/redis-client.ts
- Look for: cache invalidation not happening on write,
  read replica lag, stale TTL settings,
  wrong cache key pattern

For each hypothesis, report:
1. Did you investigate thoroughly? (yes/no)
2. Did you find an issue? (yes/no + description)
3. What evidence supports your finding?
4. Confidence level (low/medium/high)
5. Suggested fix if applicable

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

תיאום חוצה-שכבות

אפליקציות מודרניות מורכבות מכמה שכבות (layers): Frontend (UI), Backend (API, logic), Database (data), ו-Infrastructure (config, deployment). כשצריך להוסיף פיצ'ר חדש שחוצה כמה שכבות — למשל, אמצעי תשלום חדש, שדה פרופיל חדש, או סוג משתמש חדש — צריך לגעת בכל אחת מהן. עם סוכן בודד, העבודה סדרתית ומתישה. עם צוות, כל שכבה מטופלת במקביל.

הנה דוגמה קונקרטית בהקשר ישראלי. סטארטאפ ב-fintech שמוסיף תמיכה ב-Apple Pay:

התפקיד הקריטי של ה-Lead: לוודא עקביות בין השכבות. ה-Frontend Teammate בונה UI שמצפה ל-endpoint POST /api/payment/apple-pay עם body בפורמט מסוים. ה-Backend Teammate בונה POST /api/payments/apple — URL אחר! בלי ה-Lead שמוודא שה-API contracts תואמים — כל Teammate יבנה את שלו ובסוף שום דבר לא יתחבר.

# API Contract: Apple Pay
POST /api/payment/apple-pay
Request: { token: string, amount: number, currency: "ILS" }
Response 200: { transactionId: string, status: "success" }
Response 400: { error: string, code: string }
DB Column: transactions.payment_method = "apple_pay"

היתרון בזמן: שינוי חוצה-שכבות עם סוכן בודד לוקח בממוצע פי 3-4 יותר זמן מצוות. הסיבה: הסוכן צריך להחליף הקשר (context switch) בין שכבות — לקרוא קוד Frontend, לזכור את ה-schema, לעבור ל-Backend, לחזור ל-Frontend כדי לוודא עקביות. צוות עובד במקביל — 4 שכבות בזמן של שכבה אחת, פלוס תקורת תיאום של ה-Lead.

מתי צוותים מנצחים סוכן יחיד

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

5 מצבים שבהם צוותים מנצחים

1. משימות מחקר נרחבות. כמה Teammates מחפשים במקורות שונים בו-זמנית. Teammate 1 סורק את ה-docs הרשמיים, Teammate 2 חופש ב-codebase הפנימי, Teammate 3 בודק GitHub issues ו-Stack Overflow. ה-Lead מסנתז ממצאים מכל המקורות לתשובה אחת מקיפה. סוכן יחיד היה מחפש מקור אחרי מקור — הצוות מחפש בכולם במקביל.

2. סקירות קוד מקיפות (Code Review). צריכים לסקור PR גדול? Teammate 1 בודק אבטחה (vulnerabilities, injection, auth), Teammate 2 בודק ביצועים (N+1 queries, memory, re-renders), Teammate 3 בודק נגישות (ARIA labels, keyboard navigation, contrast). כל אחד מומחה בתחום שלו. יחד — סקירה מקיפה שמכסה 3 ממדים, לא רק אחד.

3. Competing Hypotheses Debugging (ראינו בסעיף 5.4). כשלא יודעים איפה הבאג ויש 3 כיוונים אפשריים — שלושה חוקרים במקביל מוצאים מהר יותר מחוקר אחד שבודק אחד-אחד.

4. שינויים חוצי-שכבות (ראינו בסעיף 5.5). Frontend + Backend + Database + Infrastructure בו-זמנית, עם contract document ו-Lead שמוודא עקביות.

5. יצירת תוכן מורכב. Teammate 1 חוקר מקורות, Teammate 2 כותב טיוטה על בסיס research ראשוני, Teammate 3 עורך ומשפר — שלבים חופפים שלא חייבים להיות סדרתיים לחלוטין. ה-Lead מרכיב את הגרסה הסופית.

4 מצבים שבהם צוותים לא עוזרים (ועלולים להזיק)

1. משימות עם תלויות סדרתיות. אם שלב B תלוי בפלט של שלב A — צריך Pipeline (פרק 6), לא Team. Team מניח שכולם יכולים לעבוד במקביל. אם יש תלות — צוות לא רק שלא עוזר, אלא מבזבז טוקנים על Teammates שמחכים.

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

3. חשיבה עמוקה על נושא אחד. עיצוב ארכיטקטורה, כתיבת אלגוריתם מורכב, קבלת החלטה אסטרטגית — אלה משימות שדורשות "Single-threaded deep reasoning." סוכן אחד עם Opus ו-effort גבוה עדיף על שלושה Teammates עם Sonnet. לפצל חשיבה עמוקה ל-3 חלקים רק מדלל את העומק.

4. תקציב מוגבל. צוות של 3 Teammates עולה לפחות פי 3 מסוכן יחיד (ולפעמים פי 4-5 עם תקורת תיאום). אם אתם מוגבלים בטוקנים או בתקציב חודשי, סוכן יחיד עם prompt מדויק יותר אפקטיבי מצוות שחורג מהתקציב.

עיצוב מבני צוות אפקטיביים

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

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

מבנה 1: Flat Team (צוות שטוח)

מה זה: כל ה-Teammates הם peers (שווי מעמד) — אין היררכיה ביניהם. ה-Lead רק מתאם את החלוקה ומסנתז את התוצאות, הוא לא "מנהל." מתי: משימות מחקר, סקירה, review, ו-Competing Hypotheses — כל מקום שבו כל Teammate בודק זווית שונה של אותה בעיה בלי תלות באחרים. דוגמה: סקירת קוד מקיפה — security reviewer, performance reviewer, accessibility reviewer — כולם peers, ה-Lead מרכיב את הממצאים. עלות: נמוכה-בינונית — אין תקשורת בין Teammates, רק דיווח ל-Lead.

מבנה 2: Specialist Team (צוות מומחים)

מה זה: כל Teammate הוא מומחה בתחום ספציפי — Frontend Expert, Backend Expert, Database Expert, DevOps Expert. מתי: שינויים חוצי-שכבות שדורשים מומחיות שונה בכל שכבה — כל Teammate "מדבר את השפה" של השכבה שלו ויודע את ה-patterns שלה. דוגמה: הוספת פיצ'ר שחוצה Frontend + Backend + DB — כל Teammate עובד בשכבה שלו, ה-Lead מוודא עקביות דרך contract document. עלות: בינונית — יש צורך ב-contract document ובתיאום מה-Lead.

מבנה 3: Adversarial Team (צוות יריבותי)

מה זה: Teammate אחד מיישם ואחר מבקר ומנסה "לשבור". כמו code review מובנה בתוך הצוות. מתי: משימות שבהן איכות קריטית — קוד אבטחה, לוגיקה פיננסית (חישוב מע"מ, עמלות, המרת מטבע), ממשקי API ציבוריים, הרשאות ו-access control. דוגמה: Teammate 1 כותב middleware להרשאות, Teammate 2 מקבל את הקוד ומנסה למצוא דרכים לעקוף את ההרשאות, ה-Lead מוודא שכל הפידבק טופל. עלות: בינונית-גבוהה — Teammate 2 חלקית תלוי ב-Teammate 1 (צריך לחכות לגרסה ראשונה).

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

מבנה 4: Hierarchical Team (צוות היררכי)

מה זה: ה-Lead מאציל ל-sub-leads שכל אחד מנהל Teammates משלו. שכבה נוספת של ניהול. מתי: משימות ענקיות בלבד — למשל, ריפקטורינג של מערכת שלמה עם 10+ מודולים. אזהרה: השתמשו בזה בזהירות רבה מאוד. העלות גבוהה (כל sub-lead = context window נוסף = טוקנים נוספים), התיאום מורכב, והתוצאות לא תמיד מצדיקות את ההשקעה. ברוב המקרים, צוות שטוח או מומחים עדיף. אם המשימה באמת ענקית — שקלו /batch שמריץ עד 30 workers ב-worktrees נפרדים.

הקצאת מודלים — ניצול חכם של תקציב

לא כל ה-Teammates צריכים את אותו מודל. זה כמו בצוות פיתוח אמיתי — הארכיטקט הבכיר צריך להיות חזק (Opus), אבל ה-QA שבודק test coverage יכול להיות junior (Sonnet). ה-Lead ו-Teammates קריטיים (אבטחה, סינתזה, ארכיטקטורה) — Opus 4.6. Teammates שעושים עבודה מובנית ושגרתית (סריקה, בדיקות, שאילתות פשוטות) — Sonnet 4.6 מספיק. זה יכול לחסוך 40-60% מעלות הצוות בלי ירידה משמעותית באיכות.

טיפול בשגיאות וריקברי בצוות

מה קורה כש-Teammate נכשל? בניגוד לסוכן יחיד שפשוט מחזיר שגיאה ואתם צריכים לנסות שוב — בצוות יש אפשרויות ריקברי (recovery) יותר מתוחכמות. ה-Lead מקבל דיווח כישלון ויכול להקצות מחדש, לעקוף, או לעבוד עם תוצאות חלקיות. בואו נעבור על התרחישים.

תרחיש 1: Teammate יחיד נכשל

ה-Lead מקבל: "Teammate 2 failed — API rate limit error." מה האופציות? (א) הקצאה מחדש: ה-Lead מעביר את המשימה ל-Teammate אחר שעדיין לא עמוס. (ב) עקיפה: ה-Lead ממשיך בלי Teammate 2 ומסנתז מ-Teammates 1 ו-3 בלבד — עם הערה שהסקירה חלקית. (ג) ניסיון נוסף: ה-Lead מחכה רגע ושולח את Teammate 2 לנסות שוב.

תרחיש 2: הצלחה חלקית — 2 מתוך 3

זה התרחיש הנפוץ ביותר. 2 מתוך 3 Teammates הצליחו. ה-Lead לא חייב להפיל הכל — הוא יכול לסנתז תוצאה שימושית ממה שיש. למשל: Security Reviewer הצליח, Performance Reviewer הצליח, Coverage Reviewer נפל. ה-Lead יגיד: "הנה סקירת אבטחה וביצועים מלאה. סקירת coverage לא הושלמה — מומלץ להריץ ידנית עם jest --coverage." תוצאה חלקית שימושית עדיפה על כישלון מוחלט.

תרחיש 3: Teammate תקוע — עובד יותר מדי זמן

Teammate עובד כבר 10 דקות על משימה שצריכה לקחת 3. הוא "תקוע" — אולי נכנס ללולאה, אולי קורא קבצים אינסופיים. ה-Lead יכול לסיים אותו (terminate) ולדווח על תוצאות חלקיות. הגדרת timeout לכל Teammate מונעת סיטואציות שבהן צוות שלם — ואתם — מחכים ל-Teammate אחד איטי.

דפוס Fallback to Sequential — ה-Plan B שלכם

אם Teams לא יציב (זכרו — עדיין research preview), תמיד צריך להיות נתיב גיבוי: הריצו את אותן משימות סדרתית עם סוכן יחיד. יותר איטי, אבל אמין ב-100%. הכלל: אף פעם אל תשלחו צוות לעבודה קריטית בלי שיש לכם Plan B. מה ה-Plan B? סדרת prompts לסוכן יחיד שעושות את אותן 3 משימות אחת-אחת. זה לוקח 3x זמן, אבל עובד תמיד.

צוותי סוכנים ב-CI/CD

אחד היישומים המעשיים ביותר של Agent Teams הוא סקירת PR אוטומטית מקיפה. בפרק 2 למדנו איך Claude Code עובד ב-GitHub Actions כ-reviewer יחיד — תופס באגים, מציע שיפורים, מפרגן על קוד טוב. עכשיו אנחנו מדברים על צוות reviewers — כל אחד מתמחה בתחום אחר, וביחד הם נותנים סקירה שאף reviewer יחיד לא יכול לתת.

הרעיון פשוט: כש-PR נפתח, ה-CI pipeline מפעיל צוות של 3 reviewers + Lead synthesizer:

• Security Reviewer (Opus) — מחפש vulnerabilities, SQL injection, XSS, authentication gaps, hardcoded secrets, insecure dependencies. זה חייב להיות Opus — פספוס אבטחה עולה יותר מטוקנים.
• Performance Reviewer (Sonnet) — מחפש N+1 queries, unnecessary re-renders, missing indexes, memory leaks, O(n^2) loops, missing caching. Sonnet מספיק כי patterns הם ידועים ומובנים.
• Coverage Reviewer (Sonnet) — בודק שכל שינוי מכוסה בטסטים, מזהה edge cases חסרים, מציע טסטים נוספים. גם כאן Sonnet מספיק.

ה-Lead Synthesizer (Opus) לוקח את שלושת הדוחות ומרכיב תגובת PR אחת קוהרנטית. לא 3 תגובות נפרדות שמבלבלות את המפתח — תגובה אחת מסודרת עם sections: "Security Findings," "Performance Findings," "Coverage Gaps." המפתח מקבל review מקיף ומאורגן.

יישום עם Agent SDK — מהפרקים הקודמים

ב-CI pipeline, אתם משתמשים ב-Agent SDK (Python מפרק 3 או TypeScript מפרק 4) כדי לתזמר את הצוות פרוגרמטית. זה לא שימוש אינטראקטיבי ב-Claude Code — זה קוד אוטומציה שמפעיל סוכנים, מקבל תוצאות, ומפרסם תגובה.

# Conceptual pipeline structure (Python pseudocode)
# Based on patterns from Chapter 3 (Agent SDK Python)

import asyncio
from agent_sdk import Agent

async def review_pr(pr_diff: str, file_list: list[str]):

    # Stage 1: Run 3 specialized reviewers in parallel
    security = Agent(
        model="opus-4.6",
        instructions="You are a security reviewer. Focus ONLY on vulnerabilities.",
        tools=["Read", "Grep"]
    )
    performance = Agent(
        model="sonnet-4.6",
        instructions="You are a performance reviewer. Focus ONLY on bottlenecks.",
        tools=["Read", "Grep"]
    )
    coverage = Agent(
        model="sonnet-4.6",
        instructions="You are a coverage reviewer. Identify missing tests.",
        tools=["Read", "Grep", "Bash"]
    )

    # Run all 3 in parallel
    results = await asyncio.gather(
        security.run(f"Review this PR for security issues:\n{pr_diff}"),
        performance.run(f"Review this PR for performance issues:\n{pr_diff}"),
        coverage.run(f"Review this PR for test coverage gaps:\n{pr_diff}"),
    )

    # Stage 2: Lead synthesizes into one coherent review
    lead = Agent(model="opus-4.6", instructions="Synthesize reviews.")
    final = await lead.run(f"""
        Combine these 3 reviews into ONE cohesive PR comment:
        ## Security: {results[0].text}
        ## Performance: {results[1].text}
        ## Coverage: {results[2].text}
        Format: markdown with severity labels (Critical/Warning/Info).
    """)

    # Stage 3: Post to GitHub
    github.post_pr_comment(pr_number, final.text)

שימו לב: הקוד משתמש ב-asyncio.gather כדי להריץ את 3 ה-reviewers במקביל — בדיוק כמו שלמדנו בפרק 3. כל reviewer הוא Agent נפרד עם מודל ו-instructions ספציפיים. ה-Lead Synthesizer מקבל את 3 הדוחות ומרכיב תגובה אחת.

הטרייד-אוף: 3x-4x מעלות review יחיד, אבל תופס סוגי בעיות שסוכן יחיד מפספס. review יחיד בדרך כלל מתמקד בנושא אחד (או סוקר ברמת שטח). צוות של 3 מומחים מכסה 3 ממדים לעומק. בפרויקט עם 10+ מפתחים שמוציאים PRs יומי — ההשקעה מצדיקה את עצמה. בפרויקט יחיד עם PR בשבוע — כנראה שלא.

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

Agent Teams נכון להיום (מרץ 2026) הוא research preview — פיצ'ר ניסיוני שמושבת כברירת מחדל. Anthropic עובדים עליו באופן פעיל, ויש כמה כיוונים מרתקים בהתפתחות.

לאן זה הולך — 3 כיוונים

צוותים פרסיסטנטיים (Persistent Teams): היום כל ריצת צוות מתחילה מאפס — ה-Teammates לא "זוכרים" מה היה בפעם הקודמת. בעתיד, צוותים ישמרו ידע בין sessions. ה-Security Reviewer "יזכור" מה הוא מצא בסקירה הקודמת ויתמקד בקוד חדש. זה ידרוש מנגנון persistent memory מובנה — משהו שמזכיר את Auto-Memory שיש כבר ב-Claude Code, אבל ברמת צוות.

צוותים חוצי-repos (Cross-Repository Teams): היום הצוות עובד על repository אחד. בעתיד, Teammate 1 יעבוד ב-frontend repo, Teammate 2 ב-backend repo, ו-Teammate 3 ב-infrastructure repo — כולם מתואמים. זה רלוונטי לארגונים עם monorepo, ועוד יותר לארגונים עם microservices.

צוותים עם בני אדם (Human-in-the-Loop Teams): החזון הגדול — "צוות הנדסת AI" שבו המוביל הוא אדם (ארכיטקט, tech lead), וה-Teammates הם סוכני AI שמיישמים, בודקים, סוקרים, ופורסים. האדם מגדיר כיוון ומקבל החלטות אסטרטגיות, ה-AI מבצע את העבודה הטקטית. זה כבר קורה חלקית עם Remote Control (שלמדנו שהושק בפברואר 2026) — אדם שמנהל session מהטלפון בזמן שסוכנים עובדים.

מגבלות של היום — מה צריך להשתפר

• תקורת תיאום: כל message בין סוכנים עולה טוקנים. ככל שהצוות גדול יותר, התקורה משמעותית יותר — ולפעמים 20-30% מהעלות הכוללת הולכת רק על "שיחה" בין סוכנים.
• שכפול הקשר: כל Teammate מקבל context window נפרד. אם כולם צריכים להכיר את אותו קוד (500 שורות), ה-context מועתק 3 פעמים — 1,500 שורות של קריאה "מיותרת" (מבחינת עלות).
• תוצאות לא-דטרמיניסטיות: אותו צוות עם אותו prompt עלול לתת תוצאות שונות בכל ריצה — כי ה-Lead מחלק אחרת, ה-Teammates חוקרים בסדר שונה, ומוצאים ממצאים שונים. לדיבוג וסקירה זה בסדר. לתהליכים שצריכים להיות reproducible — זה בעייתי.
• חוסר תמיכה ב-resume: /resume ו-/rewind לא משחזרים Teammates שהיו באמצע עבודה. אחרי חידוש session, ה-Lead עלול לנסות לשלוח הודעות ל-Teammates שכבר לא קיימים. מגבלה נוספת: סטטוס משימות יכול לפגר — לפעמים Teammate מסיים משימה אבל לא מסמן אותה כ-completed, מה שחוסם משימות תלויות.
• עלות: צוות של 3 עולה לפחות פי 3 מסוכן יחיד — ולפעמים פי 4-5 עם תקורה. זה מגביל את השימוש למשימות שבאמת מצדיקות את ההשקעה.

מה אפשר לעשות כבר עכשיו

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

• לנסות עם משימות לא-קריטיות — סקירות, מחקר, דיבוג. לא לשלוח צוות לשנות קוד production ביום ראשון.
• לפתח אינטואיציה לפירוק משימות — הכישור של "איך לפצל בעיה גדולה לחלקים עצמאיים" שימושי גם בלי Teams. זה עוזר עם subagents, עם /batch, ועם עבודה עם צוותים אנושיים.
• לבנות team templates לתחום שלכם — מבנים, תפקידים, prompts — כדי שכשהפיצ'ר יתייצב ויעבור ל-stable, תהיו מוכנים עם templates מוכנים שכבר בדקתם.