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

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

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

עכשיו הגיע הזמן להפוך את הסוכנים הבודדים לצוות.

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

ההבדל הקריטי מ-Subagents שלמדנו בפרקים 3-4: Subagents הם עובדים שמקבלים משימה, מבצעים, ומדווחים רק ל-parent שלהם. הם לא יודעים על קיומם של subagents אחרים ולא יכולים לדבר ביניהם. Agent Teams הם צוות שמשתף פעולה — כל Teammate רואה את רשימת המשימות המשותפת, יכול לשלוח הודעות ל-Teammates אחרים, ויכול לתאם עם חברי הצוות בלי לעבור דרך ה-Lead.

הפיצ'ר שוחרר עם Claude Opus 4.6 בפברואר 2026 ומושבת כברירת מחדל. כדי להפעיל אותו, צריך להגדיר environment variable:

// בקובץ settings.json
{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

// או כ-environment variable
export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

דרישת גרסה מינימלית: Claude Code v2.1.32 או מאוחר יותר. בדקו עם claude --version.

בדיקה מהירה שהפיצ'ר עובד: אחרי שהפעלתם את ה-env var, פתחו Claude Code ובקשו: Create a team with 2 teammates to analyze this project. אם הפיצ'ר מופעל, תראו Claude מתחיל לפרק את המשימה ולהפעיל Teammates. אם הוא מבצע הכל לבד — בדקו שה-env var נטען נכון.

ה-Agent Teams UI: ברגע שצוות פעיל, ה-UI של Claude Code משתנה. תראו:

• Task list — רשימת משימות עם status (pending / in_progress / completed) ושם ה-Teammate המוקצה
• Teammate status — כל Teammate מראה active / idle / completed
• Navigation — Shift+Down ו-Shift+Up לעבור בין Teammates, Shift+Right לחזור ל-Lead
• Messages — הודעות בין Teammates מופיעות כ-chat entries בתוך ה-task list

עלויות Agent Teams — מה לצפות: הנה benchmark ממוצע מניסיונות שלנו:

המלצה: התחילו עם 2-3 Teammates. אל תקפצו ל-5 — ה-coordination overhead גדל אקספוננציאלית. רוב המשימות שמתאימות לצוות עובדות מצוין עם 3 Teammates + Lead.

הדפוס Lead + Teammates

הארכיטקטורה של Agent Teams מבוססת על דפוס פשוט וחזק: Lead + Teammates.

ה-Lead הוא הסוכן שאתם מדברים איתו — זה אותו Claude Code שפתחתם בטרמינל. הוא מקבל את המשימה הגדולה מכם, מפרק אותה לתת-משימות, ומחלק אותן ל-Teammates. כל Teammate הוא מופע Claude Code עצמאי לחלוטין — עם context window נפרד, גישה מלאה לכלים (Read, Write, Bash, Grep, WebSearch), וגישה לאותו filesystem.

זרימת העבודה:

1. אתם נותנים ל-Lead תיאור של המשימה הגדולה ומבנה הצוות שאתם רוצים
2. ה-Lead יוצר task list משותפת, משייך משימות ל-Teammates, ומפעיל אותם
3. כל Teammate עובד על המשימה שלו באופן עצמאי — מריץ כלים, קורא קבצים, כותב קוד
4. Teammates יכולים לשלוח הודעות אחד לשני או ל-Lead
5. כש-Teammate מסיים, הוא מסמן את המשימה כ-completed ותופס את המשימה הבאה
6. ה-Lead מסנתז את כל התוצאות לתשובה אחת קוהרנטית

שני מצבי תצוגה:

• In-process (ברירת מחדל): כל ה-Teammates רצים בתוך הטרמינל הראשי. השתמשו ב-Shift+Down כדי לעבור בין Teammates. עובד בכל טרמינל.
• Split panes: כל Teammate מקבל חלון נפרד ב-tmux או iTerm2. רואים את כולם בו-זמנית. דורש tmux מותקן.

להגדרת מצב התצוגה, הוסיפו ל-~/.claude.json:

{
  "teammateMode": "in-process"  // או "tmux" ל-split panes
}

Plan Approval — שכבת בטיחות: למשימות רגישות, אפשר לדרוש מ-Teammate לתכנן לפני שהוא מבצע. ה-Teammate כותב תוכנית, שולח אותה ל-Lead, וה-Lead מאשר או מבקש שינויים. דוגמה:

Spawn an architect teammate to refactor the authentication module.
Require plan approval before they make any changes.
Only approve plans that include test coverage.

מאיפה Teammates לומדים את ההקשר? Teammates טוענים אוטומטית את אותו project context כמו session רגיל: CLAUDE.md, MCP servers, skills. הם גם מקבלים את ה-spawn prompt מה-Lead. אבל הם לא יורשים את היסטוריית השיחה של ה-Lead — זו נקודה חשובה. צריך לתת לכל Teammate מספיק context ב-spawn prompt.

מחזור החיים של צוות: הנה מה שקורה מאחורי הקלעים כשאתם מפעילים Agent Team:

1. Initialization: ה-Lead קורא את ה-prompt שלכם, מזהה שצריך צוות, ויוצר task list בפורמט JSON פנימי. כל task מכיל: תיאור, Teammate מוקצה, תלויות, ו-status.
2. Spawn: ה-Lead מפעיל כל Teammate כ-process נפרד (או tmux pane). כל Teammate מקבל system prompt עם: תיאור התפקיד, ה-task list המשותפת, הרשאות (אילו קבצים הוא עובד עליהם), ו-constraints (timeout, model).
3. Execution: כל Teammate עובד באופן עצמאי. הוא קורא קבצים, כותב קוד, מריץ פקודות — בדיוק כמו session רגיל של Claude Code. ההבדל: הוא יכול לשלוח הודעות לצוות דרך ה-task list.
4. Communication: כש-Teammate מסיים task או צריך עזרה, הוא מעדכן את ה-task list. ה-Lead וה-Teammates האחרים רואים את העדכון ויכולים להגיב.
5. Synthesis: כשכל ה-tasks מסומנים completed, ה-Lead קורא את כל התוצאות ומסנתז אותן לתשובה אחת קוהרנטית. הסינתזה אינה הדבקה — ה-Lead מבין את הקשרים, מזהה סתירות, ובונה נרטיב אחיד.
6. Cleanup: ה-Teammates נסגרים (או נשארים אם אתם רוצים להמשיך). tmux sessions צריכות ניקוי ידני.

הדגמה מלאה — צוות סקירת קוד:

# הפעלת צוות מהטרמינל
> Create an agent team to review the latest PR changes.
  - Security reviewer: check for injection vulnerabilities, auth bypass, data exposure
  - Performance reviewer: check for N+1 queries, memory leaks, unoptimized loops
  - Test reviewer: check for untested edge cases and missing error handling tests
  Have each reviewer write findings to review-notes.md under their section.
  Synthesize a final review summary with severity ratings.

מה קורה אחרי שנותנים את ה-prompt הזה:

• ה-Lead מזהה 3 תפקידים ויוצר task list עם 3 tasks
• 3 Teammates נוצרים — כל אחד עם prompt ממוקד
• Security reviewer פותח את הקבצים, מחפש patterns מסוכנים
• Performance reviewer מנתח queries, loops, ו-memory patterns
• Test reviewer בודק test coverage ו-edge cases
• כל אחד כותב ל-review-notes.md תחת הכותרת שלו
• ה-Lead מסנתז את כל הממצאים לדו"ח אחד עם Critical / Warning / Info

טיפ: prompts שעובדים טוב עם צוותים: היו ספציפיים. במקום "review the code", כתבו בדיוק מה כל Teammate צריך לחפש, באילו קבצים, ומה הפלט הצפוי. ככל שה-prompt יותר מדויק — ככה הצוות יותר יעיל.

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

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

הכלל הבסיסי: כל Teammate צריך תת-משימה עצמאית, מוגדרת היטב, עם קלט ברור ופלט צפוי. אם Teammate B צריך לחכות לתוצאה של Teammate A — זה סימן שצריך pipeline (פרק 6), לא צוות.

ה-task list המשותפת מנהלת את התיאום. לכל משימה יש שלושה מצבים:

• pending — מחכה להקצאה
• in_progress — Teammate עובד עליה
• completed — הושלמה בהצלחה

משימות יכולות להיות תלויות במשימות אחרות — משימה pending עם תלויות לא-פתורות לא ניתנת ל-claim עד שהתלויות מסומנות completed. ה-Lead יכול להקצות משימות ספציפית, או ש-Teammate תופס את המשימה הבאה הפנויה בעצמו (self-claim). Task claiming משתמש ב-file locking כדי למנוע מצב שבו שני Teammates תופסים את אותה משימה.

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

תבנית team-plan.md:

# Team Plan: [Task Name]
## Date: YYYY-MM-DD
## Budget Ceiling: $XX / XX minutes timeout

### Team Structure
- Lead: Synthesizer (Opus)
- Teammate 1: [Role] (Model) — files: [file1, file2]
- Teammate 2: [Role] (Model) — files: [file3, file4]
- Teammate 3: [Role] (Model) — files: [file5, file6]

### Task List
1. [ ] [Task 1 description] — assigned to Teammate 1
2. [ ] [Task 2 description] — assigned to Teammate 2
3. [ ] [Task 3 description] — assigned to Teammate 3
4. [ ] Synthesis — assigned to Lead (depends on 1,2,3)

### File Ownership (CRITICAL: no overlaps!)
| Teammate | Owned Files | Read-Only Files |
|----------|------------|----------------|
| TM1      | src/api/   | src/types/     |
| TM2      | src/ui/    | src/types/     |
| TM3      | tests/     | src/api/, src/ui/ |

### Success Criteria
- All tasks completed within budget
- No file conflicts
- Output passes [specific check]

### Fallback Plan
- If TM fails: Lead completes their task sequentially
- If budget exceeded: Stop, use partial results

למה ה-manifest חשוב: בלי מסמך מסודר, ה-Lead ממציא חלוקת משימות "on the fly" — ולפעמים מחלק לא אופטימלית (שני Teammates על אותם קבצים, או משימה גדולה מדי ל-Teammate אחד). המסמך כופה עליכם ועל ה-Lead לחשוב מראש.

Competing Hypotheses Debugging

זה ה-use case הרוצח של Agent Teams — ולטעמי, הסיבה הכי משכנעת להשתמש בצוותים.

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

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

Users report the app exits after one message instead of staying connected.
Spawn 5 agent teammates to investigate different hypotheses.
Have them talk to each other to try to disprove each other's theories,
like a scientific debate. Update the findings doc with whatever
consensus emerges.

כל Teammate מתמקד בתחום שלו — Frontend, Backend, Database, Caching, Network — ולא רק חוקר את התיאוריה שלו, אלא גם מנסה להפריך את התיאוריות של האחרים. זו לא רק חקירה מקבילית — זה ויכוח מדעי.

למה זה עובד טוב יותר מחקירה סדרתית:

• אין anchoring: כל Teammate מתחיל עם מחשבה נקייה, ללא הטיה מחקירות קודמות
• מהירות: 3 חקירות במקביל = מציאת הבעיה ב-1/3 מהזמן (בממוצע)
• עמידות: גם אם Teammate אחד הולך לכיוון שגוי, האחרים ממשיכים לחקור
• ויכוח מסנתז: ה-Lead מקבל ממצאים מכמה זוויות ויכול לזהות את ההשערה ששרדה את הביקורת

דוגמה מעשית — באג בחנות אונליין:

משתמשים מדווחים שהסל שלהם מתרוקן אחרי 5 דקות. הצוות:

• Teammate 1 (Frontend): "חקור אם session storage ב-browser מתאפס — בדוק cookies, localStorage, sessionStorage timing"
• Teammate 2 (Backend): "חקור אם session timeout בצד השרת מוגדר ל-5 דקות במקום 30 — בדוק Redis TTL"
• Teammate 3 (Infrastructure): "חקור אם load balancer מפזר בקשות לשרתים שונים בלי sticky sessions — כל request מגיע לשרת אחר שלא מכיר את הסשן"

עלות מול ערך: Competing Hypotheses עולה בערך פי 3 מחקירה בודדת (3 Teammates = 3 context windows). אבל אם החקירה הבודדת לוקחת שעה ועולה $2, הצוות לוקח 20 דקות ועולה $6. ב-ROI, חסכתם 40 דקות של זמן מפתח — שעולות הרבה יותר מ-$4.

מתודולוגיית Competing Hypotheses — 5 שלבים:

1. הגדרת הבעיה (2 דקות): תארו את הסימפטום בצורה ברורה. "משתמשים מדווחים שהסל מתרוקן אחרי 5 דקות" — לא "יש באג בסל". ככל שהתיאור יותר ספציפי, ככה ה-Teammates יותר ממוקדים.
2. יצירת השערות (3 דקות): כתבו 3+ השערות, כל אחת בתחום שונה. כללו: סימפטומים צפויים אם ההשערה נכונה, וקבצים/לוגים לבדיקה. תרגול: חשבו על 3 השערות לפני שמפעילים את הצוות — אל תתנו ל-Lead להמציא.
3. הפעלת הצוות (1 דקה): צרו prompt מובנה שמציין בדיוק: מה הבעיה, מה כל Teammate חוקר, ושהם צריכים לנסות להפריך את ההשערות של האחרים.
4. ניטור (5-15 דקות): צפו ב-Teammates עם Shift+Down. בדקו שכל אחד עובד בכיוון הנכון ולא נתקע. אם Teammate נעצר — נדנדו או החליפו כיוון.
5. סינתזה (2 דקות): ה-Lead מסכם: איזו השערה אושרה, מה הראיות, מה ה-root cause, ומה ה-fix המומלץ. בקשו שיכלול גם "מה למדנו" — לתיעוד עתידי.

תבנית prompt ל-Competing Hypotheses:

## Bug Report
[תיאור הסימפטום בצורה ברורה]

## Hypotheses
1. [Frontend]: [תיאור — מה לבדוק, סימפטומים צפויים]
2. [Backend]: [תיאור — מה לבדוק, סימפטומים צפויים]
3. [Infrastructure]: [תיאור — מה לבדוק, סימפטומים צפויים]

## Instructions
Create an agent team with 3 teammates, one per hypothesis.
Each teammate should:
- Investigate their hypothesis thoroughly
- Document evidence (code, logs, config) supporting or refuting
- Challenge the other teammates' findings
- Update the shared findings doc

Lead: synthesize and identify the most likely root cause.

מתי לא להשתמש ב-Competing Hypotheses: כשהבאג ברור (stack trace מצביע ישירות), כשיש רק השערה אחת סבירה, או כשהמערכת קטנה מדי להצדיק 3 Teammates. במקרים כאלה — סוכן יחיד מספיק.

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

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

בעבודה סדרתית (מפתח אחד, סוכן אחד), זה אומר: קודם Frontend, אחר כך Backend, אחר כך DB migration, ואז infrastructure. כל שלב דורש context switch. עם Agent Team, כל שכבה מטופלת במקביל:

Create an agent team to add a "user type" field to the application.
- Frontend teammate: add the UI dropdown to user profile at src/components/Profile.tsx
- Backend teammate: implement the API endpoint and validation at src/api/users.ts
- Database teammate: create the migration at db/migrations/
- Lead: ensure the API contract is consistent between frontend and backend

מפתח ההצלחה: ה-Contract Document. לפני שמפעילים את הצוות, הגדירו "חוזה" (API spec פשוט) שכל Teammate עובד לפיו. למשל:

// contract: user-type-api.md
PATCH /api/users/:id
Body: { "user_type": "admin" | "editor" | "viewer" }
Response 200: { "id": "...", "user_type": "admin", "updated_at": "..." }
Response 400: { "error": "Invalid user_type" }

Database: users.user_type VARCHAR(20) NOT NULL DEFAULT 'viewer'
Frontend: dropdown options ["admin", "editor", "viewer"]

ה-Lead בודק שהפלטים של כל Teammate תואמים ל-contract: שה-Frontend שולח את הפורמט הנכון, שה-Backend מקבל ומחזיר כצפוי, שה-DB migration תואמת.

3 סוגי contracts שכדאי להגדיר מראש:

טיפ מעשי: שמרו את ה-contract כקובץ בפרויקט (למשל docs/contracts/user-type.md). ציינו את הנתיב ב-prompt של הצוות. ככה ה-Teammates קוראים אותו אוטומטית ועובדים לפיו — ואתם יכולים לעקוב אחרי שינויים ב-Git.

דפוס "Contract-First Development" עם Agent Teams:

1. כתבו contract ידנית (או בקשו מ-Claude לכתוב draft)
2. הפעילו צוות שעובד לפי ה-contract
3. ה-Lead מוודא שכל output תואם ל-contract
4. אם יש סתירה — ה-Lead מחזיר ל-Teammate לתיקון, לא משנה את ה-contract

גישה זו מונעת את הבעיה הכי נפוצה ב-cross-layer changes: שכל שכבה עושה את שלה בצורה מעט שונה, ובסוף הכל לא מתחבר. ה-contract הוא ה-"source of truth" שכולם עובדים לפיו.

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

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

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

1. משימות מחקר נרחבות: כמה Teammates מחפשים מידע ממקורות שונים בו-זמנית — אחד בודק documentation, אחד GitHub issues, אחד Stack Overflow. תוצאה: מחקר מקיף ב-1/3 מהזמן.
2. סקירות קוד מקבילות: Teammate לאבטחה, Teammate לביצועים, Teammate ל-test coverage — כל אחד מתמקד בעדשה אחת. תוצאה: סקירה שלמה שסוקר יחיד היה מפספס חלקים ממנה.
3. דיבוג Competing Hypotheses: מספר Teammates חוקרים את אותה בעיה מזוויות שונות (ראו סעיף 5.4). תוצאה: מציאת באג מהירה בלי anchoring bias.
4. שינויים חוצי-שכבות: Frontend + Backend + DB + Infra במקביל (ראו סעיף 5.5). תוצאה: פיצ'ר חוצה-שכבות מוכן בזמן של שכבה אחת.
5. יצירת תוכן: מחקר + outline + draft + עריכה בשלבים חופפים. תוצאה: תוכן איכותי מהר יותר.

3 מצבים שבהם צוותים לא עוזרים:

• משימות סדרתיות: כשכל שלב תלוי בקודם — pipeline עדיף (פרק 6). דוגמה: "Research → Plan → Write → Review" — כל שלב צריך את הפלט של הקודם, אין מה לעשות במקביל.
• משימות קטנות: תקורת התיאום (יצירת צוות, task list, synthesis) גדולה מהתועלת. כלל אצבע: אם משימה לוקחת פחות מ-5 דקות לסוכן יחיד — אל תיצרו צוות.
• חשיבה עמוקה חד-קווית: ניתוח ארכיטקטוני מורכב שדורש רצף מחשבות ארוך — סוכן Opus יחיד עדיף. פיצול יפגע באיכות כי כל Teammate רואה רק חלק מהתמונה.
• סביבה לא מוכנה: אם הפרויקט בלי Git, בלי מבנה תיקיות ברור, או בלי tests — תקנו את הבסיס לפני שמשתמשים בצוותים. צוות על codebase מבולגן ייצר עוד בלגן.

חישוב ROI מהיר: לפני הפעלת צוות, עשו חישוב פשוט:

# ROI Calculator
team_cost = num_teammates * avg_cost_per_teammate  # $
team_time = max_teammate_time + synthesis_time     # minutes
solo_cost = avg_cost_per_solo_run                  # $
solo_time = total_sequential_time                  # minutes

time_saved = solo_time - team_time                 # minutes
cost_diff = team_cost - solo_cost                  # $
developer_hourly = 200  # ש"ח/שעה (ממוצע ישראלי)
value_of_time_saved = (time_saved / 60) * developer_hourly

# אם value_of_time_saved > cost_diff × 4 (exchange rate) → שווה
# דוגמה: חסכתם 30 דקות = 100 ש"ח. עלות נוספת: $4 = 16 ש"ח. ROI: 6x

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

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

1. Flat Team (צוות שטוח)

כל ה-Teammates שווי מעמד — ה-Lead רק מתאם ומסנתז. מתאים למחקר, סקירות, ואיסוף מידע מכמה מקורות.

Create a flat team with 3 researchers:
- Teammate 1: research React 19 new features from official docs
- Teammate 2: research community adoption and migration guides
- Teammate 3: research performance benchmarks and comparisons
Synthesize findings into a comprehensive report.

2. Specialist Team (צוות מומחים)

כל Teammate מומחה בתחום ספציפי — Frontend, Backend, Testing, DevOps. מתאים לשינויים חוצי-שכבות (Cross-Layer).

Create a specialist team for adding the payment feature:
- Frontend specialist: UI components at src/components/Payment/
- Backend specialist: API routes at src/api/payments/
- Database specialist: migration at db/migrations/
- QA specialist: test cases at tests/payments/
Use Sonnet for Frontend and QA, Opus for Backend.

3. Adversarial Team (צוות יריבותי)

Teammate אחד מיישם ואחר מבקר ומנסה "לשבור". כמו code review מובנה בתהליך. מתאים למשימות קריטיות לאיכות ואבטחה.

Create an adversarial team for the auth refactor:
- Builder: refactor authentication using JWT + refresh tokens
- Critic: review the builder's code for security vulnerabilities,
  edge cases, and race conditions. Challenge every design decision.
Require the builder to address each critique before marking done.

4. Hierarchical Team (צוות היררכי)

Lead מאציל ל-sub-leads שמאצילים הלאה — למשימות מאוד גדולות. השתמשו בזהירות — העלות גבוהה, התיאום מורכב, ולרוב 3-4 Teammates מספיקים.

בחירת מבנה צוות — סיכום מהיר:

Adversarial Team לעומק — מתי ואיך:

Adversarial Team הוא המבנה הכי ייחודי כי הוא מנצל מתח יצירתי בין שני Teammates. ה-Builder מיישם, ה-Critic מחפש בעיות. זה לא "סקירה אחרי" — זה סקירה מתמשכת שמתרחשת במקביל לפיתוח.

דוגמה מעשית: צריך לכתוב endpoint חדש שמטפל ב-file upload. ה-Builder כותב את הקוד. ה-Critic בודק בזמן אמת: "מה קורה עם קובץ של 10GB? מה קורה עם filename שמכיל ../../etc/passwd? מה קורה אם שני משתמשים מעלים קובץ עם אותו שם?" — ה-Builder צריך לטפל בכל ביקורת לפני ש-task נסגר.

Prompt pattern ל-Adversarial Team:

Create a 2-member adversarial team:
- Builder: Implement [feature]. Write clean, tested code.
- Critic: Review every change the Builder makes. Focus on:
  * Security: injection, auth bypass, path traversal
  * Edge cases: empty input, huge input, concurrent access
  * Error handling: what happens when [dependency] is down?
  * Performance: is this O(n^2) when it should be O(n)?

The Builder must address EVERY critique before marking done.
The Critic must verify the fix, not just accept it.

תוצאה טיפוסית: הקוד שיוצא מ-Adversarial Team הוא חזק יותר מקוד שעובר code review רגיל, כי הביקורת קורה בזמן הכתיבה — לא אחרי. בתרגולים שלנו, Adversarial Teams תפסו בממוצע 2-3 באגי אבטחה שסוכן יחיד פספס — כולל path traversal, missing input validation, ו-race conditions ב-database writes. המחיר: ~$4-6 במקום ~$2 — אבל בהתחשב בעלות של באג אבטחה ב-production, זה ROI מצוין.

מתי להשתמש ב-Adversarial: authentication, payment processing, file handling, database migrations, API endpoints שפונים ל-public internet. בקיצור — כל קוד שנגיש לעולם החיצוני או שמטפל בנתונים רגישים.

הנחיות גודל צוות:

• 2 Teammates — למשימות ממוקדות (adversarial, builder+reviewer)
• 3-4 Teammates — רוב המשימות (research, cross-layer, debugging)
• 5+ Teammates — לעיתים רחוקות מוצדק (diminishing returns)
• 5-6 tasks per teammate — שומר על כולם פרודוקטיביים

הקצאת מודלים: לא כל Teammate חייב להריץ את אותו מודל. הקצו Sonnet ל-Teammates רוטיניים (סקירת קוד, איסוף מידע) ו-Opus ל-Lead ול-Teammates שצריכים judgment (ארכיטקטורה, אבטחה).

טבלת הקצאת מודלים מומלצת:

דוגמה: עלות צוות 4-Teammates

• Lead (Opus): ~$2.00
• Security Reviewer (Opus): ~$1.50
• Performance Reviewer (Sonnet): ~$0.30
• Test Reviewer (Sonnet): ~$0.20
• סה"כ: ~$4.00 — מול 45 דקות של developer review שעולות הרבה יותר

אנטי-פטרן: כל Teammates על Opus. שגיאה נפוצה שמשלשת את העלות בלי תועלת ממשית. 70% מהמשימות עובדות מעולה עם Sonnet. שמרו Opus רק למשימות שדורשות judgment — אבטחה, ארכיטקטורה, סינתזה.

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

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

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

תרחיש 2: הצלחה חלקית. אם 2 מתוך 3 Teammates הצליחו — ה-Lead יכול לסנתז תוצאה שימושית מהנתונים החלקיים. זה יתרון משמעותי על פני סוכן יחיד שנכשל = 0 תוצאה.

תרחיש 3: Lead נעצר לפני סיום. לפעמים ה-Lead מחליט שהצוות סיים לפני שכל המשימות באמת הושלמו. הפתרון: אמרו ל-Lead להמשיך, או הנחו אותו לחכות ל-Teammates.

Wait for your teammates to complete their tasks before proceeding.

תרחיש 4: Teammates תקועים. Teammate שנתקע לא סופר tasks completed — זה חוסם משימות תלויות. בדקו את הפלט שלו (Shift+Down), נתבו מחדש, או בקשו מה-Lead לנדנד (nudge) אותו.

תרחיש 5: קונפליקט בין Teammates. שני Teammates מגיעים למסקנות סותרות — למשל, Security reviewer אומר "צריך rate limiting" ו-Performance reviewer אומר "rate limiting מאט את ה-API". ה-Lead צריך לשקלל ולתת החלטה. זה בדיוק ה-value של ה-Lead — הוא רואה את כל התמונה.

Error Handling Checklist לצוותים:

דפוס הצלחה: "Graceful Degradation". תכננו כל צוות כך שתוצאה חלקית עדיין שימושית. אם 2 מתוך 3 reviewers סיימו — דו"ח עם 2 עדשות עדיף מחוסר דו"ח. אם Database teammate נכשל אבל Frontend ו-Backend הצליחו — אפשר להריץ את ה-DB migration בנפרד.

ה-Fallback to Sequential pattern: אם צוותים לא יציבים עבורכם (שגיאות חוזרות, תוצאות לא עקביות), תמיד אפשר לחזור לריצה סדרתית של אותן משימות עם סוכן יחיד. צוותים הם כלי, לא דוגמה — אם הכלי לא מתאים, אל תכריחו אותו.

Best Practices לניהול שגיאות בצוותים:

1. הגדירו timeout לכל Teammate. ברירת המחדל היא ללא הגבלה — וזה מסוכן. Teammate שנתקע יבזבז טוקנים ללא סוף. הגדירו 10-15 דקות כ-timeout סביר.
2. הגדירו budget ceiling. מספר טוקנים מקסימלי לכל Teammate. אם Teammate חורג — הוא נעצר ומחזיר תוצאות חלקיות. עדיף תוצאה חלקית מחריגה בעלות.
3. שמרו logs. בקשו מכל Teammate לכתוב לקובץ log ייעודי (למשל debug/teammate-1.log). ככה תוכלו לנתח ריצות שנכשלו אחרי.
4. הריצו dry-run לפני production. הפעילו את הצוות על משימה קטנה ולא-קריטית קודם. בדקו שהחלוקה עובדת, שאין קונפליקטים, ושהעלות סבירה.
5. תעדו הכל. אחרי כל ריצת צוות: מה עבד, מה לא, כמה עלה, כמה זמן לקח, מה תשנו בפעם הבאה. הדוקומנטציה הזאת שווה זהב.

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

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

דוגמה: CI Review Team

חישוב ROI:

• עלות: 3 reviewers = ~$1.50-3.00 per PR (Opus security + 2x Sonnet)
• חיסכון: 15-30 דקות עבודת reviewer אנושי per PR
• ROI: עם 50 PRs בשבוע, חוסכים ~12-25 שעות reviewer. בעלות שכר ישראלית טיפוסית — זה עולה הרבה פחות מ-$150 בטוקנים לשבוע.

מימוש ב-Agent SDK: השתמשו ב-SDK (Python או TypeScript) מתוך GitHub Actions workflow כדי ליצור ולנהל את הצוות. הגדירו כל reviewer כ-subagent type ב-.claude/agents/ וה-team script יוצר צוות שמשתמש בהם.

GitHub Actions workflow ל-Team Review:

# .github/workflows/team-review.yml
name: Claude Team Review
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  team-review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Get PR diff
        id: diff
        run: |
          git diff origin/main...HEAD > pr_diff.txt
          echo "diff_file=pr_diff.txt" >> $GITHUB_OUTPUT

      - name: Setup Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.12'

      - name: Install SDK
        run: pip install claude-agent-sdk

      - name: Run Team Review
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: python ci_review_team.py ${{ steps.diff.outputs.diff_file }}

      - name: Post Review Comment
        uses: actions/github-script@v7
        with:
          script: |
            const fs = require('fs');
            const review = fs.readFileSync('review-output.md', 'utf8');
            github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: context.issue.number,
              body: review
            });

עלות חודשית לפי פעילות:

* בנפח גבוה, אפשר להוריד עלות עם caching ו-model routing (Sonnet לPRs קטנים, Opus רק לPRs גדולים/מורכבים).

מימוש מלא — Agent SDK script ל-CI Review Team:

# ci_review_team.py — Agent SDK implementation
from claude_agent_sdk import Agent
import json

async def run_ci_review_team(pr_diff: str, pr_files: list[str]):
    """Run a 3-reviewer team on a PR."""

    # 1. Security reviewer (Opus for deep judgment)
    security_agent = Agent(
        model="claude-opus-4-6",
        system_prompt="""You are a security reviewer. Focus ONLY on:
        - SQL injection, XSS, CSRF
        - Authentication bypass
        - Data exposure (PII leaks)
        - Insecure defaults
        Rate each finding: CRITICAL / WARNING / INFO"""
    )

    # 2. Performance reviewer (Sonnet for pattern matching)
    perf_agent = Agent(
        model="claude-sonnet-4-6",
        system_prompt="""You are a performance reviewer. Focus ONLY on:
        - N+1 database queries
        - Memory leaks and unbounded growth
        - Unoptimized loops (O(n^2) when O(n) possible)
        - Missing caching opportunities
        Rate each finding: CRITICAL / WARNING / INFO"""
    )

    # 3. Test coverage reviewer (Sonnet)
    test_agent = Agent(
        model="claude-sonnet-4-6",
        system_prompt="""You are a test coverage reviewer. Focus ONLY on:
        - Untested edge cases
        - Missing error handling tests
        - Integration test gaps
        - Flaky test patterns
        Rate each finding: CRITICAL / WARNING / INFO"""
    )

    # Run all 3 in parallel
    import asyncio
    results = await asyncio.gather(
        security_agent.run(f"Review this PR diff:\n{pr_diff}"),
        perf_agent.run(f"Review this PR diff:\n{pr_diff}"),
        test_agent.run(f"Review this PR diff:\n{pr_diff}")
    )

    # Synthesize with Lead (Opus)
    lead = Agent(model="claude-opus-4-6")
    synthesis = await lead.run(f"""
    Combine these 3 review results into ONE PR comment:

    Security: {results[0].text}
    Performance: {results[1].text}
    Tests: {results[2].text}

    Format: ## Security / ## Performance / ## Tests
    Sort findings by severity (CRITICAL first).
    """)

    return synthesis.text

הסקריפט הזה מריץ 3 reviewers במקביל ומסנתז לתגובת PR אחת. עלות: ~$2-4 לכל PR, בהנחת PR בינוני (500 שורות diff). חיסכון: 15-30 דקות של reviewer אנושי.

שימוש ב-Hooks לאכיפת איכות: Agent Teams תומכים ב-3 hooks:

• TeammateIdle — כש-Teammate עומד להפוך ל-idle. Exit code 2 שולח feedback ומחזיר אותו לעבודה.
• TaskCreated — כשמשימה נוצרת. Exit code 2 מונע יצירה עם feedback.
• TaskCompleted — כשמשימה מסומנת completed. Exit code 2 מונע סגירה עם feedback — "you missed the SQL injection in line 42."

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

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

כיוון 1: צוותים פרסיסטנטיים (Persistent Teams). היום כל ריצת צוות מתחילה מ-0 — Teammates לא זוכרים ריצות קודמות. בעתיד, צוותים ישמרו context בין sessions — כמו צוות אמיתי שמגיע למשרד יום אחרי יום ויודע מה קרה אתמול.

כיוון 2: צוותים חוצי-codebases. היום כל Teammates עובדים על אותו filesystem. בעתיד, Teammate אחד יכול לעבוד על microservice A ואחר על microservice B — כל אחד ב-repo אחר, עם תיאום דרך API contracts.

כיוון 3: צוותים מעורבים אנושי-AI. החזון: Lead ארכיטקט (אנושי) מנחה צוות של AI developers שמיישמים, בודקים, סוקרים, ומפרסמים — עם ה-lead האנושי מאשר decisions points קריטיים.

מגבלות הנוכחיות — מה צריך לדעת:

כיוון 4: מודלים מעורבים (Mixed Models). היום כל Teammate רץ על מודל שאתם בוחרים. בעתיד, ה-Lead יחליט אוטומטית איזה מודל להקצות לכל Teammate לפי סוג המשימה — Opus למשימות judgment, Sonnet למשימות routine, Haiku לבדיקות מהירות.

כיוון 5: Team Templates. במקום להגדיר צוות מאפס בכל פעם, תוכלו ליצור team templates — "Security Review Team", "Feature Development Team", "Research Team" — ולהפעיל אותם בפקודה אחת עם הפרמטרים הרלוונטיים.

מה לעשות עכשיו:

• התנסו בצוותים על משימות לא-קריטיות — תפתחו אינטואיציה
• בנו templates לצוותים שעובדים לכם — שמרו prompts שהצליחו
• מדדו ROI — אל תניחו שצוותים טובים יותר, בדקו
• תעדו הכל — כל ריצה עם: זמן, עלות, תוצאה, prompts. ככה תדעו מה עובד
• הכירו את ה-hooks — TeammateIdle, TaskCreated, TaskCompleted הם quality gates בחינם

Troubleshooting: 5 בעיות נפוצות בצוותים ראשונים

ה-Takeaway: Agent Teams הוא פיצ'ר שמשנה את האופן שבו מפתחים חושבים על AI — ממשימה-בודדת למערכת-מרובת-סוכנים. גם אם היום זה research preview, הדפוסים שתלמדו כאן — task decomposition, role design, synthesis, error recovery — ישרדו כל API change. אלה מיומנויות ארכיטקטורה, לא מיומנויות CLI. ובפרק הבא — נלמד לבנות pipelines סדרתיים שלוקחים את הרעיונות האלה לרמה הבאה.