- הבנה מלאה של מודל ה-Subagent — מתי Claude משתמש בו ולמה
- לפחות 2 סוכנים מותאמים אישית עובדים בתיקיית
.claude/agents/ - סוכן Security Reviewer מוגדר — סוכן Read-Only שסורק קוד
- סוכן Content Pipeline מוגדר — סוכן שיוצר תוכן בעברית
- ידע מעשי בהרצה מקבילית — כמה סוכנים עובדים בו-זמנית
- שליטה בכל שדות ה-Frontmatter — כולל memory, isolation, permissionMode
- תכנית עלויות — מודל, effort, maxTurns מותאמים לתקציב
- הבנת הקשר בין Agents ל-Skills — איך לחבר ביניהם
- תוכלו להסביר את מודל ההאצלה (Delegation Model) ולמה חלון הקשר הנפרד של סוכן חשוב
- תוכלו ליצור סוכן מותאם אישית מאפס — Frontmatter + Body — ולהפעיל אותו בפרויקט
- תוכלו לבחור את המודל הנכון (Haiku/Sonnet/Opus) ואת הגדרות ה-effort וה-maxTurns לפי סוג המשימה והתקציב
- תוכלו להעריך מתי להאציל לסוכן ומתי לעשות לבד (כלל 5 הדקות)
- תוכלו להריץ סוכנים במקביל ולבנות Orchestrator Pattern לביקורת מקיפה
- פרקים קודמים: פרק 1 (Hooks) — הבנת settings.json, lifecycle events, ו-Hook configuration. ההוקים שבנית בפרק 1 ישמשו גם בתרגילים כאן
- כלים נדרשים: Claude Code מותקן (v2.1+), מסוף Terminal, פרויקט קיים עם קבצי קוד (לצורך סוכן ביקורת)
- זמן משוער לפרק: 90-120 דקות (כולל בניית 2 סוכנים מותאמים ותרגילים)
בפרק הקודם בנית מערכת Hooks — השכבה הדטרמיניסטית שמפעילה פקודות אוטומטית בכל אירוע. בפרק הזה אתה מוסיף את השכבה השנייה: Agents — מופעים עצמאיים של Claude שמבצעים משימות שלמות בשבילך, כשההוקים שבנית שומרים עליהם. בפרק הבא (MCP) ניתן לסוכנים האלה גישה לכלים חיצוניים: מסדי נתונים, API-ים, ושירותי צד שלישי.
מה הם Subagents ואיך הם עובדים
סוכן-משנה (Subagent) הוא מופע נפרד ועצמאי של Claude שנוצר על ידי השיחה הראשית שלכם כדי לטפל במשימה ממוקדת. חשבו על זה כמו לשלוח עובד לחדר נפרד לחקור נושא ולחזור עם דוח — אתם לא רואים את כל התהליך שלו, רק את התוצאה הסופית.
הנקודה הקריטית: כל Subagent מקבל חלון הקשר (Context Window) משלו. הוא לא חולק את ההקשר של השיחה הראשית. זה אומר שהוא מתחיל עם תיאור המשימה בלבד ופרטי סביבה בסיסיים (כמו תיקיית העבודה), לא עם ה-System Prompt המלא של Claude Code. הסוכן קורא קבצים, מריץ פקודות, עורך קוד, ובסוף מחזיר סיכום לשיחה הראשית.
למה זה חשוב? כי החקירה של הסוכן לא מזהמת את ההקשר שלכם. אם סוכן קרא 50 קבצים וניסה 10 גישות שונות — אתם רואים רק את המסקנה. ההקשר היקר שלכם נשאר נקי ומרוכז.
זה גודל חלון ההקשר המקסימלי ב-Opus 4.6 (Max/Team/Enterprise, מרץ 2026). כל Subagent מקבל חלון משלו — מה שאומר שסוכנים מרובים מרחיבים את קיבולת העבודה שלכם פי כמה. גם ב-auto-compaction, סוכנים נדחסים ב-~95% קיבולת כברירת מחדל (ניתן לשנות עם CLAUDE_AUTOCOMPACT_PCT_OVERRIDE).
מודל ההאצלה — The Delegation Model
הדרך הטובה ביותר להבין Subagents היא דרך מטאפורה ארגונית:
- אתם ה-CEO (השיחה הראשית). אתם מגדירים את המשימה ומקבלים את התוצאה.
- הסוכנים הם ראשי מחלקות. כל אחד מקבל תדרוך (Brief), עובד באופן עצמאי, ומחזיר דוח.
- אתם לא צריכים לראות את הישיבות הפנימיות שלהם. מספיק שהדוח הסופי טוב.
סוכנים יכולים לרוץ במקביל: Claude יכול ליצור כמה Subagents בו-זמנית כשהמשימות עצמאיות אחת מהשנייה. זה חוסך זמן אמיתי.
האצלה אוטומטית ומפורשת
Claude מאציל משימות לסוכנים בצורה אוטומטית, על סמך שלושה פרמטרים: תיאור המשימה בבקשה שלכם, שדה ה-description בהגדרות הסוכן, וההקשר הנוכחי. אם רוצים שClaude יפעיל סוכן באופן פרואקטיבי, כדאי לכלול את הביטוי "use proactively" בתיאור הסוכן.
אפשר גם להפעיל סוכנים באופן מפורש בשלוש דרכים:
- שפה טבעית: הזכירו את שם הסוכן בבקשה —
"Use the security-reviewer agent to check my code" - @-mention: הקלידו
@ובחרו את הסוכן מהרשימה (כמו @-mention לקבצים). זה מבטיח שהסוכן הספציפי הזה ירוץ. - --agent flag: הפעלה של כל הסשן כסוכן —
claude --agent security-reviewer. ה-System Prompt של הסוכן מחליף את ברירת המחדל.
סוכנים לא יכולים ליצור סוכנים נוספים. אין "סוכן-נכד". זה בכוונה — כדי למנוע רקורסיה אינסופית ועלויות שיוצאות משליטה. רק השיחה הראשית שלכם (או סוכן שרץ כ-main thread עם --agent) יכולה ליצור סוכנים.
הטעות: כתיבת description: "agent for stuff" או השארת תיאור גנרי.
למה זה מפתה: אתה רוצה להתחיל מהר ולבדוק שהסוכן עובד — תיאור טוב נראה לא חשוב.
מה לעשות במקום: ה-description הוא מה ש-Claude משתמש בו כדי להחליט מתי להפעיל את הסוכן אוטומטית. תיאור גרוע = Claude לא מפעיל כשצריך, או מפעיל כשלא צריך. כתבו תיאור של 1-2 משפטים שמסביר בדיוק מה הסוכן עושה ומתי להשתמש בו.
פתחו שיחה חדשה של Claude Code בפרויקט קיים. בקשו: "Explore the project structure and tell me how the modules are organized". שימו לב לתצוגה — תראו שכלי "Agent" מופעל עם תיאור המשימה. זה Subagent מסוג Explore שנוצר אוטומטית כדי לחקור את הפרויקט בלי לזהם את ההקשר שלכם.
סוגי סוכנים מובנים
Claude Code מגיע עם כמה סוגי סוכנים מובנים. אתם לא צריכים להגדיר אותם — הם פועלים אוטומטית כשהמצב מתאים:
| סוג סוכן | מודל | כלים זמינים | מתי Claude בוחר בו | דוגמת בקשה |
|---|---|---|---|---|
| Explore | Haiku (מהיר, low-latency) | כלי קריאה בלבד (Read, Grep, Glob — חסום: Write, Edit) | מיפוי קוד, חיפוש קבצים, הבנת מבנה. Claude מציין רמת יסודיות: quick / medium / very thorough | "Understand how the payment flow works" |
| Plan | יורש מהשיחה הראשית | כלי קריאה בלבד (חסום: Write, Edit) | מצב Plan — מחקר רקע לפני הצגת תוכנית | "Plan a refactoring of the database layer" |
| General-Purpose | יורש מהשיחה הראשית | כל הכלים — קריאה, כתיבה, Bash, Web | משימות מורכבות שדורשות גם חקירה וגם עריכה | "Refactor the auth module to use JWT" |
| Bash | יורש | הרצת פקודות Terminal בהקשר נפרד | כשצריך להריץ פקודות ארוכות בלי לחסום את השיחה | (מופעל אוטומטית) |
Claude בוחר אוטומטית את סוג הסוכן המתאים לפי הבקשה שלכם. שימו לב ש-Explore משתמש ב-Haiku (מהיר וזול), בעוד Plan ו-General-Purpose יורשים את המודל של השיחה הראשית. זה שיקול עלות חשוב.
כשClaude מפעיל Subagent, תראו בתצוגת הכלים (Tool Call Display) את הכלי "Agent" עם תיאור המשימה. זה הסימן שמופע נפרד עובד ברקע. כשהסוכן מסיים, התוצאה מוחזרת לשיחה הראשית שלכם. אם רוצים להריץ סוכן ברקע בזמן שאתם ממשיכים לעבוד — לחצו Ctrl+B.
סוכנים מובנים לעומת סוכנים מותאמים
הסוכנים המובנים הם "ברירת מחדל" — Claude בוחר אותם אוטומטית. אבל ה-Power Move האמיתי הוא ליצור סוכנים מותאמים אישית שמוגדרים בדיוק לצרכים שלכם: עם מודל ספציפי, כלים מוגבלים, הנחיות מפורטות, זיכרון מתמשך, ותקציב קבוע מראש. על זה נדבר עכשיו.
נסו את שלושת סוגי הסוכנים בפועל. פתחו Claude Code בפרויקט ובקשו: "Map all the API endpoints in this project" — שימו לב שClaude מפעיל Explore agent (רץ על Haiku). אחר כך: "Plan how to add user authentication" — עכשיו Plan agent. שימו לב לזמן הביצוע ולכמות הפלט — Explore מהיר יותר כי הוא על Haiku.
יצירת סוכנים מותאמים — תיקיית .claude/agents/
סוכנים מותאמים אישית מוגדרים כקבצי Markdown (.md) בתיקיית .claude/agents/. כל קובץ = סוכן אחד. שם הקובץ (בלי .md) הופך למזהה הסוכן. רק שני שדות הם חובה: name ו-description.
ארבע רמות של סוכנים — סדר עדיפויות
סוכנים יכולים להגיע מארבעה מקומות. כשיש כמה סוכנים עם אותו שם, הרמה הגבוהה יותר מנצחת:
| מיקום | עדיפות | תחולה | דוגמה |
|---|---|---|---|
--agents CLI flag |
1 (גבוהה ביותר) | סשן נוכחי בלבד | JSON שמועבר בפתיחת Claude Code |
.claude/agents/ (בפרויקט) |
2 | רק הפרויקט הזה | סוכן בדיקות ספציפי לפרויקט |
~/.claude/agents/ (Global) |
3 | כל פרויקט, בכל שיחה | סוכן ביקורת אבטחה אישי |
Plugin agents/ directory |
4 (נמוכה ביותר) | רק כש-Plugin פעיל | סוכן שמגיע עם Plugin מהמרקטפלייס |
מבנה קובץ סוכן
כל קובץ סוכן מורכב משני חלקים:
- Frontmatter (בתוך
---) — הגדרות טכניות ב-YAML: שם, תיאור, מודל, כלים, מגבלות - Body (אחרי ה-Frontmatter) — הנחיות מפורטות ב-Markdown שהופכות ל-System Prompt של הסוכן
דוגמה בסיסית — קובץ .claude/agents/code-reviewer.md:
---
name: code-reviewer
description: Reviews code for quality, readability, and best practices
tools: Read, Glob, Grep
model: sonnet
---
# Code Reviewer Agent
You review code for quality and best practices.
## What to check
- Naming conventions
- Function length (flag >50 lines)
- Error handling
- Code duplication
## Output format
Provide a structured report with:
1. Summary (1-2 sentences)
2. Issues found (severity: high/medium/low)
3. Recommendations
שם הקובץ הוא code-reviewer.md, ולכן המזהה של הסוכן הוא code-reviewer. שימו לב שבגרסה הנוכחית (מרץ 2026) אפשר לכתוב כלים כרשימה מופרדת בפסיקים (Read, Glob, Grep) ולא רק כמערך JSON.
קונבנציות שמות
השתמשו בשמות תיאוריים עם מקפים: security-reviewer.md, test-runner.md, content-writer.md, deploy-checker.md. שם הקובץ צריך לתאר את התפקיד של הסוכן, לא את הטכנולוגיה שלו.
סוכנים נטענים בתחילת הסשן. אם יצרתם סוכן חדש תוך כדי עבודה (הוספתם קובץ .md ידנית), הריצו /agents כדי לטעון אותו מיידית — בלי לסגור ולפתוח סשן. עריכת קובץ קיים? ההפעלה הבאה כבר תשתמש בגרסה המעודכנת.
צרו את תיקיית הסוכנים בפרויקט שלכם וכתבו סוכן ראשון:
- הריצו:
mkdir -p .claude/agents - צרו קובץ
.claude/agents/hello-agent.mdעם התוכן הבא:--- name: hello-agent description: A simple test agent that greets the user model: haiku maxTurns: 3 --- You are a friendly greeting agent. When invoked: 1. Read the project's package.json or main config file 2. Identify the project name 3. Return a greeting: "Hello from [project name]!" - הפעילו:
claude --agent hello-agent - ודאו שאתם מקבלים ברכה עם שם הפרויקט. אם כן — התיקייה עובדת.
הפקודה /agents — ניהול אינטראקטיבי
מלבד יצירה ידנית של קבצי .md, Claude Code מציע ממשק אינטראקטיבי מלא לניהול סוכנים: הפקודה /agents.
הריצו /agents בסשן כדי:
- לראות את כל הסוכנים הזמינים (מובנים, אישיים, פרויקטיים, ו-Plugin)
- ליצור סוכן חדש — עם הגדרה מודרכת או עם Claude שמייצר בשבילכם
- לערוך הגדרות סוכן קיים — כלים, מודל, הרשאות
- למחוק סוכנים מותאמים
יצירה עם Claude — Generate with Claude
אפשרות Generate with Claude מאפשרת לתאר את הסוכן בשפה טבעית, ו-Claude ייצר את ה-Frontmatter וה-System Prompt בשבילכם. הנה התהליך:
- בחרו Create new agent → Personal (Global) או Project
- בחרו Generate with Claude
- תארו מה הסוכן צריך לעשות:
"A code improvement agent that scans files and suggests improvements for readability and performance" - בחרו כלים, מודל, וצבע רקע (כדי לזהות סוכנים שונים ויזואלית)
- הגדירו memory scope אם רוצים זיכרון מתמשך
- שמרו — הסוכן זמין מיידית
לרשימה מלאה מה-CLI בלי להיכנס לסשן אינטראקטיבי: claude agents (בלי /).
הריצו /agents בסשן. עברו על הרשימה — תראו את הסוכנים המובנים (Explore, Plan, General-Purpose) ואת ה-hello-agent שיצרתם. נסו Create new agent → Generate with Claude ותארו סוכן: "A linter agent that checks code style". ראו איך Claude מייצר את הכל בשבילכם.
Agent Frontmatter — כל השדות
ה-Frontmatter הוא ה"מוח" של הסוכן. כאן אתם מגדירים מי הוא, מה הוא יכול לעשות, וכמה חבל אתם משחררים לו. הנה כל השדות שזמינים נכון למרץ 2026:
| שדה | חובה? | מה עושה | ערכים אפשריים | דוגמה |
|---|---|---|---|---|
| name | כן | מזהה ייחודי — אותיות קטנות ומקפים | טקסט | security-reviewer |
| description | כן | מתי Claude צריך להאציל לסוכן הזה. Claude משתמש בתיאור כדי להחליט | טקסט חופשי | Reviews code for security vulnerabilities |
| model | לא | איזה מודל הסוכן משתמש בו | opus, sonnet, haiku, מזהה מלא, או inherit |
sonnet |
| tools | לא | רשימה לבנה — רק הכלים האלה מותרים. ללא הגדרה = יורש הכל | רשימת שמות כלים | Read, Grep, Glob |
| disallowedTools | לא | רשימה שחורה — כלים חסומים. מוסר מהרשימה הירושה או מ-tools | רשימת שמות כלים | Bash, Write |
| effort | לא | עומק החשיבה. דורס את הגדרת הסשן | low, medium, high, max (Opus 4.6 בלבד) |
high |
| maxTurns | לא | מספר מקסימלי של תורות. מונע סוכנים שרצים ללא סוף | מספר שלם | 25 |
| hooks | לא | Hooks ספציפיים לסוכן — פועלים רק כשהסוכן הזה רץ | אובייקט hooks (PreToolUse, PostToolUse, Stop) | ראו פרק 1 |
| memory | לא | זיכרון מתמשך בין סשנים. הסוכן שומר תובנות בתיקייה ייעודית | user, project, local |
project |
| permissionMode | לא | איך הסוכן מטפל בבקשות הרשאה | default, acceptEdits, dontAsk, bypassPermissions, plan |
acceptEdits |
| skills | לא | Skills שנטענים לקונטקסט הסוכן בהתחלה. התוכן המלא מוזרק | רשימת שמות skills | api-conventions, error-handling |
| mcpServers | לא | שרתי MCP זמינים לסוכן. אפשר inline (מוגדר כאן) או הפנייה לשרת קיים | רשימה של שרתים | ראו פרק 3 |
| background | לא | האם הסוכן תמיד רץ ברקע | true / false |
true |
| isolation | לא | בידוד בסביבת Git Worktree נפרדת. הסוכן מקבל עותק מבודד של הריפו | worktree |
worktree |
The Agent Blueprint — מודל מנטלי
חשבו על כל שדה כחלק ממבנה:
- name + description = הזהות — מי הסוכן ולמה הוא קיים
- model + effort = המוח — כמה חכם ועמוק הוא חושב
- tools + disallowedTools = הידיים — מה הוא מורשה לעשות
- maxTurns = הרצועה — כמה חופש פעולה יש לו
- hooks = מעקות הבטיחות — מה קורה אוטומטית סביב הפעולות שלו
- memory = הזיכרון — מה הוא שומר מסשן לסשן
- permissionMode = רמת האוטונומיה — כמה אישורים הוא צריך ממכם
- isolation = הסביבה — האם הוא עובד על אותו ריפו או על עותק מבודד
tools לעומת disallowedTools — מתי להשתמש בכל אחד
יש שתי גישות להגבלת כלים:
| גישה | מתי להשתמש | דוגמה |
|---|---|---|
| tools (רשימה לבנה) | כשאתם רוצים רק כלים ספציפיים. בטוח יותר. | tools: Read, Grep — סוכן שיכול רק לקרוא |
| disallowedTools (רשימה שחורה) | כשאתם רוצים הכל חוץ מ... כמה כלים מסוכנים. | disallowedTools: Bash, Write — הכל חוץ מהרצת פקודות וכתיבת קבצים |
אם מציינים גם tools וגם disallowedTools, סדר הפעולה הוא: קודם disallowedTools מוסר כלים מהרשימה הזמינה, ואז tools נפתר מתוך מה שנותר. כלי שמופיע בשניהם יוסר. ברוב המקרים עדיף לבחור גישה אחת ולהיצמד אליה.
הגבלת סוגי סוכנים שהסוכן יכול להפעיל
כשסוכן רץ כ-main thread (עם --agent), הוא יכול ליצור סוכני-משנה. כדי להגביל אילו סוכנים הוא מורשה ליצור, השתמשו בסינטקס Agent(agent_type) בשדה tools:
---
name: coordinator
description: Coordinates work across specialized agents
tools: Agent(worker, researcher), Read, Bash
---
הסוכן coordinator יכול ליצור רק worker ו-researcher. בלי Agent ברשימת tools — הסוכן לא יכול להפעיל סוכנים כלל.
חזרו לסוכן hello-agent.md שיצרתם קודם ושדרגו אותו: הוסיפו tools: Read, Glob ו-effort: low. הפעילו שוב ושימו לב שהסוכן עדיין עובד אבל מהיר יותר (בגלל effort נמוך) ולא יכול לערוך קבצים.
דוגמה מלאה: Security Reviewer
בואו נבנה סוכן אמיתי שתוכלו להשתמש בו מחר בבוקר. סוכן Security Reviewer סורק קוד ומחפש פגיעויות אבטחה — בלי לשנות שום דבר. זה הדגם הקלאסי של סוכן Read-Only.
צרו את הקובץ .claude/agents/security-reviewer.md:
---
name: security-reviewer
description: Reviews code for security vulnerabilities, injection attacks, auth issues, and data exposure. Use proactively after code changes.
model: opus
effort: high
tools: Read, Grep, Glob, Bash
maxTurns: 25
---
# Security Reviewer Agent
You are a security-focused code reviewer. Your job is to find
vulnerabilities, NOT to fix them. Report findings, never edit files.
## What to Check
### Critical (Severity: HIGH)
- SQL injection: raw queries, string interpolation in SQL
- XSS: unescaped user input in HTML/templates
- CSRF: missing tokens on state-changing endpoints
- Hardcoded secrets: API keys, passwords, tokens in source code
- Authentication bypass: routes without auth middleware
- Path traversal: user-controlled file paths
### Important (Severity: MEDIUM)
- Insecure dependencies: known CVEs in package.json/requirements.txt
- Missing rate limiting on sensitive endpoints
- Overly permissive CORS configuration
- Sensitive data in logs (passwords, tokens, PII)
- Missing input validation
### Advisory (Severity: LOW)
- Deprecated crypto functions
- Missing security headers (CSP, HSTS, X-Frame-Options)
- Debug mode enabled in production config
- Verbose error messages exposing internals
## Output Format
For each finding, report:
1. **File**: exact path and line number
2. **Severity**: HIGH / MEDIUM / LOW
3. **Issue**: what you found
4. **Risk**: what could happen if exploited
5. **Remediation**: how to fix it (description only, do not edit)
End with a summary table: total findings by severity.
למה הבחירות האלה?
- model: opus — ביקורת אבטחה דורשת חשיבה עמוקה. לא כדאי לחסוך כאן.
- effort: high — רוצים שהסוכן באמת יחפור. לא "סקירה מהירה".
- tools: Read, Grep, Glob, Bash — קריאה + חיפוש + הרצת פקודות (למשל
git diffכדי לראות שינויים אחרונים). שימו לב: אין Write ו-Edit — הסוכן לא יכול לערוך קבצים. זה בכוונה: סוכן ביקורת צריך לדווח, לא לתקן. - maxTurns: 25 — ביקורת אבטחה יסודית דורשת הרבה קריאת קבצים. 25 תורות מספיקות לפרויקט בגודל בינוני.
- "Use proactively" ב-description — מעודד את Claude להפעיל את הסוכן מיוזמתו אחרי שינויי קוד.
איך להפעיל
אפשרות 1 — בפתיחת שיחה:
claude --agent security-reviewer
ואז תכתבו: "Review the auth module for security issues"
אפשרות 2 — @-mention מתוך שיחה קיימת:
@"security-reviewer (agent)" scan the API routes for injection vulnerabilities
אפשרות 3 — שפה טבעית. Claude יבחר את הסוכן אוטומטית אם ה-description מתאים: "Run a security audit on src/api/"
הנה דוגמה לפלט אופייני של הסוכן:
## Security Review: src/api/
### Finding 1 (HIGH)
**File:** src/api/users.js:47
**Issue:** SQL injection via string interpolation
**Risk:** Attacker can dump/modify the entire database
**Remediation:** Use parameterized queries instead of template literals
### Finding 2 (MEDIUM)
**File:** src/middleware/cors.js:12
**Issue:** CORS origin set to "*" (wildcard)
**Risk:** Any domain can make authenticated requests
**Remediation:** Whitelist specific allowed origins
### Summary
| Severity | Count |
|----------|-------|
| HIGH | 1 |
| MEDIUM | 3 |
| LOW | 2 |
צרו את קובץ security-reviewer.md בתיקיית .claude/agents/ של הפרויקט שלכם. העתיקו את הקוד מלמעלה (או התאימו אותו לפרויקט שלכם). הפעילו אותו עם claude --agent security-reviewer ובקשו: "Scan the entire project for security issues". קראו את הדוח שהוא מייצר. גם אם הוא לא מוצא בעיות קריטיות — הסוכן עובד.
דוגמה מלאה: Content Pipeline — סוכן תוכן בעברית
הדוגמה השנייה היא סוכן שמתמחה ביצירת תוכן שיווקי בעברית. בניגוד לסוכן האבטחה שהוא Read-Only, סוכן התוכן כותב — אבל עם כללים ברורים.
צרו את הקובץ .claude/agents/content-writer.md:
---
name: content-writer
description: Creates, reviews, and polishes Hebrew marketing content following brand guidelines
model: sonnet
effort: medium
tools: Read, Write, Edit, WebSearch
maxTurns: 15
memory: project
---
# Content Writer Agent
You create Hebrew marketing content. Follow these rules strictly.
## Hebrew Writing Standards
- Technical terms stay in English: SEO, CPC, ROI, CTA, API
- Explanatory text in natural Hebrew -- not "translation Hebrew"
- Short sentences (max 20 words)
- Active voice: "תשתמשו ב-X" instead of "ניתן להשתמש ב-X"
- Professional but accessible tone
## Content Types You Handle
- Blog posts (800-1500 words)
- Ad copy (headlines + descriptions)
- Email campaigns (subject + body)
- Landing page text (hero, features, CTA)
- Social media posts
## Process for Each Content Piece
1. Check your agent memory for brand voice guidelines
2. Read existing content for tone matching (if available)
3. Research the topic via WebSearch (if needed)
4. Write the draft
5. Self-review: check grammar, tone, CTA presence
6. Save to the specified file
7. Update agent memory with any new brand patterns
## Quality Checklist
- [ ] No machine-translation artifacts
- [ ] Technical terms in English with Hebrew explanation on first use
- [ ] Clear CTA in every piece
- [ ] Under word limit
- [ ] Consistent brand voice
בחירות עיצוב שונות מהסוכן הקודם
| הגדרה | Security Reviewer | Content Writer | למה? |
|---|---|---|---|
| model | opus | sonnet | כתיבת תוכן לא דורשת את רמת החשיבה של ביקורת אבטחה. Sonnet מספיק ועולה פחות |
| effort | high | medium | כתיבה צריכה להיות "טבעית", לא "מחושבת מדי" |
| tools | Read-Only + Bash | Read + Write + WebSearch | סוכן תוכן חייב לכתוב ולחפש מידע |
| maxTurns | 25 | 15 | כתיבת פוסט לוקחת פחות איטרציות מסריקת אבטחה |
| memory | --- | project | סוכן תוכן צובר הבנה של ה-Brand Voice לאורך זמן |
הפעלת Security Reviewer עם Opus ו-effort: high עולה בערך $0.50-2.00 להרצה. Content Writer עם Sonnet ו-effort: medium עולה $0.10-0.30. ההפרש משמעותי כשמריצים סוכנים בתדירות גבוהה. התאימו את המודל למשימה — לא כל סוכן צריך Opus.
צרו את קובץ content-writer.md בתיקיית .claude/agents/. התאימו את ה-"Hebrew Writing Standards" ל-Brand Voice של העסק שלכם. הפעילו עם: claude --agent content-writer ובקשו: "Write a blog post intro (200 words) about why small businesses need SEO in 2026. In Hebrew." — בדקו שהפלט עומד בכללים שהגדרתם.
Agent Memory — זיכרון מתמשך בין סשנים
אחת הפיצ'רים העוצמתיים ביותר בסוכנים מותאמים הוא זיכרון מתמשך (Persistent Memory). בלי memory — כל הפעלה של סוכן מתחילה מאפס. עם memory — הסוכן שומר תובנות, דפוסים, ותגליות לתיקייה ייעודית, ומשתמש בהן בהפעלות הבאות.
שלושה סקופים של זיכרון, לפי רוחב השימוש: user (כל הפרויקטים), project (פרויקט ספציפי, ניתן לשיתוף ב-Git), local (פרויקט ספציפי, פרטי).
| Scope | מיקום | מתי להשתמש |
|---|---|---|
| user | ~/.claude/agent-memory/<agent-name>/ |
תובנות רלוונטיות לכל הפרויקטים (דפוסים כלליים, Best Practices) |
| project | .claude/agent-memory/<agent-name>/ |
ידע ספציפי לפרויקט, ניתן לשיתוף דרך Version Control |
| local | .claude/agent-memory-local/<agent-name>/ |
ידע ספציפי לפרויקט שלא צריך להיכנס ל-Git |
איך זה עובד בפועל
כשמפעילים memory:
- ה-System Prompt של הסוכן כולל הנחיות לקריאה וכתיבה לתיקיית הזיכרון
- 200 השורות הראשונות של
MEMORY.mdנטענות אוטומטית לקונטקסט - כלי Read, Write, Edit מופעלים אוטומטית כדי שהסוכן יוכל לנהל את הזיכרון שלו
שימוש אפקטיבי
הדרך הטובה ביותר לבנות זיכרון סוכן:
- לפני משימה: בקשו מהסוכן "Review your memory for relevant patterns before starting"
- אחרי משימה: בקשו "Save what you learned to your memory"
- ב-System Prompt: הוסיפו הנחייה כמו:
"Update your agent memory as you discover patterns, library locations, and key architectural decisions"
לאורך זמן, הזיכרון בונה בסיס ידע שהופך את הסוכן ליעיל יותר בכל הפעלה.
הוא מאפשר שיתוף ידע דרך Git — כל חבר בצוות נהנה מהתובנות שהסוכן צבר. השתמשו ב-user רק לידע רחב שחוצה פרויקטים, וב-local לידע שלא צריך להיכנס ל-Version Control.
הרצה מקבילית של סוכנים
אחת היכולות החזקות ביותר של Subagents היא הרצה מקבילית (Parallel Execution). כשהמשימות עצמאיות, Claude יכול ליצור כמה סוכנים בו-זמנית ולחכות שכולם יסיימו.
שלושה סוכנים שכל אחד לוקח 30 שניות — רצים במקביל ב-30 שניות סה"כ, לא 90. אותן עלויות, שליש מהזמן. הרצה מקבילית היא תמיד עדיפה כשהמשימות עצמאיות.
דוגמה: ביקורת PR מקיפה
נניח שאתם רוצים לבדוק Pull Request מכמה זוויות. במקום לבדוק אותו סדרתית (אבטחה, אחר כך ביצועים, אחר כך סגנון), בקשו:
Review this PR for: security issues, test coverage, and code quality.
Run all three reviews in parallel.
Claude ייצור שלושה סוכנים — אחד לכל היבט — שרצים בו-זמנית. כל סוכן מחזיר דוח עצמאי, ו-Claude מסנתז את שלושת הדוחות לתשובה אחת.
הפקודה /simplify — דוגמה מובנית
Claude Code מגיע עם Skill מובנה בשם /simplify שמדגים בדיוק את הדפוס הזה. כשמפעילים /simplify, הוא:
- מזהה את הקבצים שהשתנו לאחרונה
- מפעיל 3 סוכני ביקורת במקביל:
- סוכן Code Reuse — מחפש דפוסים שמופיעים בכמה מקומות ובודק אם כבר קיימות פונקציות עזר שמטפלות בלוגיקה הזו
- סוכן Code Quality — קורא את הקוד כמו Reviewer: שמות משתנים, פירוק פונקציות, בהירות
- סוכן Efficiency — מחפש הקצאות מיותרות, לולאות כפולות, ופעולות שאפשר לאגד
- מסנתז את שלושת הדוחות
- מתקן אוטומטית את הבעיות שנמצאו
הפקודה /batch — מקביליות בסקלה
הדרגה הבאה היא /batch: Skill שיכול ליצור עד 30 סוכנים עצמאיים, כל אחד ב-Git Worktree מבודד. כל סוכן מממש את היחידה שלו, מריץ טסטים, ופותח Pull Request. /batch מפעיל אוטומטית /simplify על השינויים לפני ה-commit.
עיצוב משימות להרצה מקבילית
הכלל הקריטי: אם סוכן B צריך את הפלט של סוכן A — הם חייבים לרוץ סדרתית. אם הם עצמאיים — תמיד מקביל.
| מצב | מקביל או סדרתי? | הסבר |
|---|---|---|
| ביקורת אבטחה + ביקורת ביצועים + ביקורת סגנון | מקביל | כל אחד בודק היבט שונה באופן עצמאי |
| תכנון ארכיטקטורה → מימוש | סדרתי | המימוש תלוי בתוכנית |
| כתיבת בדיקות ל-3 מודולים שונים | מקביל | כל מודול עצמאי |
| ניתוח דרישות → יצירת Spec → מימוש | סדרתי | כל שלב תלוי בקודם |
כשסוכנים מסיימים, התוצאות שלהם חוזרות לשיחה הראשית. הרצת סוכנים רבים שכל אחד מחזיר דוח מפורט יכולה לצרוך הרבה קונטקסט. אם צריכים מקביליות גבוהה שחורגת מחלון ההקשר — שקלו Agent Teams שנותנים לכל עובד קונטקסט עצמאי לחלוטין.
נסו את /simplify בפרויקט שלכם. ערכו קובץ כלשהו (אפילו שינוי קטן), ואז הריצו /simplify. שימו לב שלושת הסוכנים רצים במקביל — תראו שלושה כלי "Agent" פעילים בו-זמנית. קראו את הדוח המסונתז.
Background Agents — סוכנים ברקע
סוכנים יכולים לרוץ בשני מצבים:
- Foreground (ברירת מחדל) — חוסם את השיחה עד שהסוכן מסיים. בקשות הרשאה ושאלות עוברות אליכם ישירות.
- Background — רץ במקביל בזמן שאתם ממשיכים לעבוד. לפני ההפעלה, Claude מבקש את כל ההרשאות שהסוכן יצטרך מראש.
שלוש דרכים לשלוח סוכן לרקע:
- בקשו מ-Claude:
"Run this in the background" - לחצו Ctrl+B בזמן שסוכן רץ
- הגדירו
background: trueב-Frontmatter — הסוכן תמיד ירוץ ברקע
אם סוכן ברקע נכשל בגלל הרשאות חסרות, אפשר להפעיל סוכן חדש ב-Foreground עם אותה משימה כדי לנסות שוב עם אישורים אינטראקטיביים.
אם סוכן ברקע צריך לערוך קבצים בלי להתנגש עם העבודה שלכם, הגדירו isolation: worktree ב-Frontmatter. הסוכן מקבל עותק מבודד של הריפו ב-Git Worktree נפרד. אם הוא לא שינה כלום, ה-Worktree נמחק אוטומטית.
Agent Teams — שיתוף פעולה בין מופעים (ניסיוני)
Agent Teams הם הצעד הבא מעבר ל-Subagents. במקום מודל "בוס-עובד" (השיחה הראשית שולחת סוכנים שמדווחים חזרה), Teams מאפשרים שיתוף פעולה בין עמיתים — עם תקשורת דו-כיוונית, רשימת משימות משותפת, ותיאום עצמי.
Agent Teams הם ניסיוניים נכון למרץ 2026. הם מושבתים כברירת מחדל ויש להם מגבלות ידועות: אין Session Resumption ל-teammates, סטטוס משימות עלול לפגר, Shutdown יכול להיות איטי, וצוות אחד בלבד לכל סשן.
הפעלה
כדי להפעיל Agent Teams, הגדירו את משתנה הסביבה ל-1 — דרך ה-Shell או דרך settings.json:
// settings.json
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}
ההבדל בין Subagents ל-Teams
| תכונה | Subagents (האצלה) | Teams (שיתוף פעולה) |
|---|---|---|
| מודל | בוס → עובד | מוביל (Lead) + עמיתים (Teammates) |
| תקשורת | חד-כיוונית: סוכן מדווח להורה | דו-כיוונית: עמיתים שולחים הודעות ישירות אחד לשני |
| קונטקסט | כל סוכן מבודד, תוצאות חוזרות ל-Main | כל עמית עצמאי לגמרי |
| תיאום | ה-Main Agent מנהל הכל | רשימת משימות משותפת + Self-Coordination |
| שימוש | משימות מוגדרות היטב שרק התוצאה חשובה | חקירות פתוחות, השוואת גישות, דיון בין היפותזות |
| עלות | נמוכה יותר: תוצאות מסוכמות חזרה | גבוהה יותר: כל Teammate הוא מופע Claude נפרד |
מתי Teams ולא Subagents?
- Teams: כשהמשימה פתוחה וצריכים "דיון" בין גישות שונות — "חקור שלוש ארכיטקטורות והשווה", "Debug בעיה שיכולה להיות ב-Frontend או Backend או DB"
- Subagents: כשהמשימה מוגדרת היטב — "בדוק אבטחה", "כתוב בדיקות", "פרמט קוד"
מצבי תצוגה
שני מצבים:
- In-Process (ברירת מחדל) — כל ה-Teammates רצים בטרמינל הראשי. Shift+Down מחליף בין Teammates. עובד בכל טרמינל.
- Split Panes — כל Teammate בחלון נפרד (דורש tmux או iTerm2). אפשר לראות את כולם במקביל.
ארכיטקטורה
כל צוות מורכב מ:
- Team Lead — הסשן הראשי שיוצר את הצוות ומתאם
- Teammates — מופעי Claude Code נפרדים
- Task List — רשימת משימות משותפת שכל אחד יכול לתפוס
- Mailbox — מערכת הודעות לתקשורת בין סוכנים
ברוב המקרים, Subagents מספיקים ועולים פחות. Teams כדאיים רק כשאתם צריכים שמופעים שונים ישתפו מידע ביניהם תוך כדי עבודה. גודל צוות מומלץ: 3-5 Teammates עם 5-6 משימות לכל אחד. אם כל סוכן עובד עצמאית — Subagents עדיפים.
מתי להשתמש בסוכנים ומתי לעשות לבד
סוכנים הם כלי עוצמתי, אבל לא כל משימה צריכה אחד. הנה ה-Framework שיעזור לכם להחליט:
כלל 5 הדקות
אם המשימה דורשת יותר מ-5 דקות של חקירה ושיח עם Claude — שלחו סוכן. אם פחות — עשו בעצמכם בשיחה הראשית.
| סיטואציה | החלטה | הסבר |
|---|---|---|
| צריך לשנות שם משתנה ב-3 קבצים | לבד | 30 שניות, לא שווה להפעיל סוכן |
| צריך למפות את כל ה-API Endpoints בפרויקט | סוכן | דורש קריאה של הרבה קבצים — יזהם את ההקשר |
| צריך לתקן Bug מוגדר | לבד | שליטה צמודה חשובה בתיקון |
| צריך ביקורת אבטחה על מודול שלם | סוכן | משימה מורכבת, מתאימה לסוכן מומחה |
| צריך לכתוב 5 פוסטים לבלוג | 5 סוכנים במקביל | כל פוסט עצמאי, הרצה מקבילית חוסכת זמן |
| צריך להבין קוד Legacy של 10,000 שורות | סוכן Explore | חקירה ענקית שתבלע את ההקשר שלכם |
| שאלה מהירה על משהו שכבר בהקשר | /btw | רואה את כל ההקשר, בלי כלים, תשובה לא נשמרת בהיסטוריה |
Decision Framework מלא
ענו על שלוש שאלות:
- האם המשימה מייצרת פלט כבד שלא צריך בהקשר הראשי? אם כן → סוכן (שומר על ההקשר נקי)
- האם אני צריך שליטה צמודה על כל צעד? אם כן → לבד (סוכנים עובדים עצמאית)
- האם יש כמה משימות עצמאיות? אם כן → סוכנים במקביל (חוסך זמן)
אם התשובה לשאלה 1 היא "כן" ולשאלה 2 "לא" — סוכן הוא הבחירה הנכונה. אם 2 הוא "כן" — עשו בעצמכם.
ניתוח עלות-תועלת
הפעלת Subagent עולה בין $0.01 (Haiku, משימה פשוטה) ל-$2.00 (Opus, סריקה מורכבת), תלוי במודל ובמורכבות. אם ההפעלה חוסכת לכם 5 דקות של חקירה ידנית — זה שווה. אם המשימה לוקחת 10 שניות — עשו בעצמכם. שקלו גם Skills כחלופה: הם רצים בהקשר הראשי (לא מבודד) ולא צורכים קונטקסט נוסף.
The Orchestrator Pattern — בניית תזמורת
דפוס ה-Orchestrator הוא הרמה הגבוהה ביותר של עבודה עם סוכנים. במקום לשלוח סוכן בודד למשימה, השיחה הראשית שלכם הופכת למתזמר שמפרק עבודה גדולה לחלקים, מקצה סוכנים מתאימים לכל חלק, ומסנתזת את התוצאות.
ארבעת השלבים של הדפוס
פירוק המשימה (Decompose)
הגדירו את המשימה הגדולה ופרקו אותה לתת-משימות עצמאיות. דוגמה: "בצע ביקורת קוד מלאה" → ביקורת אבטחה, ביקורת ביצועים, ביקורת סגנון, בדיקת כיסוי טסטים.
בחירת סוכנים (Select)
בחרו את הסוכן המתאים לכל תת-משימה. השתמשו במודל הנכון: Haiku לבדיקות פשוטות, Sonnet לניתוח, Opus לחשיבה עמוקה. אם אין סוכן מותאם — השתמשו בסוכן מובנה.
הרצה (Launch)
הפעילו את הסוכנים — במקביל כשהמשימות עצמאיות. בקשו מ-Claude: "Run these four agents in parallel and collect their reports."
סינתזה (Synthesize)
כשכל הסוכנים מסיימים, סנתזו את התוצאות בשיחה הראשית. פתרו קונפליקטים (סוכן אחד אומר לתקן X, אחר אומר להשאיר), מיזגו המלצות, וייצרו דוח סופי.
דוגמה מלאה: "בצע ביקורת קוד לפרויקט"
Audit this codebase comprehensively. Spawn these agents in parallel:
1. security-reviewer: scan for vulnerabilities
2. An explore agent: map all external dependencies and their versions
3. A general agent: run the test suite and report coverage
4. content-writer: review all user-facing strings for quality
Collect all four reports and synthesize into one audit document
with prioritized recommendations.
התוצאה: ארבעה סוכנים רצים במקביל, כל אחד בחלון הקשר משלו, ובסוף אתם מקבלים דוח אחד מסונתז עם סדר עדיפויות.
Chain Subagents — שרשרת סוכנים
לא כל תזמורת חייבת להיות מקבילית. אפשר גם לשרשר סוכנים — כל סוכן מסיים ומעביר את התוצאות לבא אחריו:
Use the code-reviewer subagent to find performance issues,
then use the optimizer subagent to fix them
Claude משתמש בתוצאות הסוכן הראשון כקונטקסט לסוכן השני. זה מתאים לתהליכים סדרתיים כמו: ביקורת → תיקון → אימות.
Resume — המשכת סוכן קיים
כל סוכן מקבל Agent ID. אפשר לחדש סוכן שסיים במקום ליצור אחד חדש מאפס. הסוכן המחודש שומר את כל ההיסטוריה שלו:
Continue that code review and now analyze the authorization logic
Claude משתמש ב-SendMessage עם ה-Agent ID כדי להעיר את הסוכן. תעתוקי סוכנים נשמרים ב-~/.claude/projects/{project}/{sessionId}/subagents/.
צרו שני סוכנים מותאמים אישית בתיקיית .claude/agents/:
- סוכן "reader" —
reader.mdעםtools: Read, Grep, Glob,model: haiku. תפקידו: לקרוא ולנתח קוד, להחזיר דוח. - סוכן "writer" —
writer.mdעםtools: Read, Write, Edit,model: sonnet. תפקידו: ליצור תוכן או קוד חדש.
הפעילו את שניהם על אותו קובץ (הראשון מנתח, השני משפר) ושימו לב איך כל אחד עובד אחרת.
ניהול עלויות סוכנים
כל סוכן הוא מופע נפרד עם חלון הקשר משלו — מה שאומר שעלויות ה-Token מוכפלות עם כל סוכן. בחירת המודל היא המנוף הגדול ביותר:
זה ההפרש בעלות בין סוכן Opus לסוכן Haiku לאותה משימה. Opus עולה ~$0.50-2.00, Haiku עולה ~$0.01-0.05. בחרו בחכמה. Agent Teams עולים עוד יותר — כל Teammate הוא מופע Claude נפרד, ועלות הטוקנים עולה ליניארית עם מספר ה-Teammates.
מדריך בחירת מודל לפי סוג משימה
| מודל | עלות לכל הפעלה | מתאים ל... | דוגמאות |
|---|---|---|---|
| Haiku | $0.01-0.05 | משימות רוטיניות ופשוטות | הרצת טסטים, בדיקת פורמט, grep-and-report, Explore |
| Sonnet | $0.10-0.50 | ניתוח, יצירת תוכן, תכנון | ביקורת קוד, כתיבת תוכן, ניתוח ארכיטקטורה |
| Opus | $0.50-2.00 | חשיבה עמוקה ומורכבת | ביקורת אבטחה, Refactoring מורכב, החלטות ארכיטקטורה |
maxTurns — הרצועה שמונעת סוכנים בורחים
תמיד הגדירו maxTurns — במיוחד לסוכנים יקרים. בלי מגבלה, סוכן Opus יכול לרוץ ולרוץ עד שנגמר לו הקונטקסט, ותשלמו על כל Token.
| סוג סוכן | maxTurns מומלץ | הסבר |
|---|---|---|
| Test Runner (Haiku) | 5 | מריץ טסטים ומדווח — לא צריך יותר |
| Content Writer (Sonnet) | 15 | מחפש, כותב, ועורך — צריך מספיק מרחב |
| Security Reviewer (Opus) | 25 | סורק הרבה קבצים לעומק — צריך חופש פעולה |
הטעות: הגדרת model: opus לכל סוכן כי "אופוס הכי טוב".
למה זה מפתה: Opus באמת נותן תוצאות טובות יותר ב-benchmarks. אתה רוצה את הטוב ביותר.
מה לעשות במקום: Haiku טוב מספיק ל-80% מהמשימות הרוטיניות (grep, format check, test run), ועולה 15 פעמים פחות. התחילו עם model: haiku, ושדרגו רק אם התוצאה לא מספקת. סוכן Security Reviewer? Opus. סוכן שמריץ טסטים? Haiku. החיסכון יצטבר לאלפי שקלים בחודש.
הטעות: יצירת סוכן בלי maxTurns — והסוכן רץ ורץ עד שנגמר לו ה-context window.
למה זה מפתה: אתה רוצה לתת לסוכן חופש פעולה. אם תגביל אותו, הוא עלול לסיים לפני שמצא תשובה.
מה לעשות במקום: תמיד הגדירו maxTurns. התחילו עם 10-15 לסוכנים כלליים. סוכן שמסיים מוקדם — הגדילו. סוכן שרץ יותר מדי — הקטינו. זה הרבה יותר בטוח מלתת חופש מלא.
מעקב עלויות
השתמשו בפקודה /cost כדי לראות את ההוצאה המצטברת כולל כל הפעלות הסוכנים. בדקו אותה באופן קבוע בזמן עבודה עם הרבה סוכנים. ב-Statusline (שורת הסטטוס בתחתית), אפשר לראות גם חלונות Rate Limit של 5 שעות ו-7 ימים.
התחילו תמיד עם Haiku. אם התוצאה לא מספיק טובה — שדרגו ל-Sonnet. אם עדיין לא — Opus. ברוב המקרים, Haiku או Sonnet מספיקים. תחסכו כסף רציני לאורך זמן.
הריצו /cost בשיחה הנוכחית שלכם. צלמו מסך. עכשיו הפעילו סוכן (אפילו את hello-agent שיצרתם) והריצו שוב /cost. שימו לב כמה עלות הסוכן הוסיף. ככה תדעו כמה כל הפעלה באמת עולה.
סוכנים ו-Skills — החיבור
זה המקום שבו הכל מתחבר. Skills מגדירים מה לעשות. Agents מגדירים איך לעשות. כשאתם מחברים ביניהם, אתם יוצרים שילובים עוצמתיים.
שני כיוונים של חיבור
יש שני כיוונים לחיבור בין Skills ו-Agents:
- Skill שמפעיל Agent — ב-Skill, שדה
context: forkמפעיל את הסוכן שמצוין בשדהagent. ההנחיות של ה-Skill מוזרקות לסוכן. - Agent שטוען Skills — בסוכן, שדה
skillsב-Frontmatter טוען Skills לתוך הקונטקסט של הסוכן. התוכן המלא מוזרק, לא רק זמין להפעלה.
כיוון 1: Skill שמפעיל Agent
# File: .claude/commands/security-check.md
---
name: security-check
description: Run a full security audit
agent: security-reviewer
context: fork
---
Scan the following paths for security vulnerabilities:
- src/api/
- src/auth/
- src/middleware/
Focus on injection attacks and authentication bypass.
Report findings with severity levels.
כשמריצים /security-check, Claude:
- מוצא את ה-Skill
security-check - רואה שהוא מציין
agent: security-reviewerעםcontext: fork - מפעיל את הסוכן
security-reviewerעם ההנחיות של ה-Skill - הסוכן רץ בבידוד (Forked Context) — לא מזהם את השיחה הראשית
כיוון 2: Agent שטוען Skills
---
name: api-developer
description: Implement API endpoints following team conventions
skills:
- api-conventions
- error-handling-patterns
---
Implement API endpoints. Follow the conventions and patterns
from the preloaded skills.
הסוכן מקבל את התוכן המלא של כל Skill ישירות לקונטקסט שלו. שימו לב: סוכנים לא יורשים Skills מהשיחה הראשית — צריך לציין אותם במפורש.
למה החיבור הזה חזק?
- הפרדת אחריות: ה-Skill מגדיר את המשימה הספציפית, הסוכן מגדיר את הכלים, המודל, והמגבלות
- שימוש חוזר: אפשר ליצור כמה Skills שמשתמשים באותו Agent, או Agent אחד שמשרת כמה Skills
- בידוד: הסוכן רץ ב-Forked Context — ההקשר של השיחה הראשית נשאר נקי
- ידע מוטמע: Skills שנטענים לסוכן נותנים לו Domain Knowledge מבלי שיצטרך לגלות אותו
ספרייה של Skills + Agents
| Skill (פקודה) | Agent (סוכן) | מה עושה |
|---|---|---|
/security-check |
security-reviewer |
סריקת אבטחה על נתיבים ספציפיים |
/write-post |
content-writer |
כתיבת פוסט בלוג בעברית |
/pre-deploy |
security-reviewer |
בדיקת אבטחה לפני פריסה (אותו סוכן, Skill אחר) |
/review-pr |
code-reviewer |
ביקורת קוד על PR פתוח |
בפרק הזה ראינו את הצד של הסוכנים — איך Skills מפעילים אותם ואיך סוכנים טוענים Skills. בפרק 4 נלמד את הצד של ה-Skills — איך ליצור, לשתף, ולנהל אותם. ביחד הם יוצרים מערכת אוטומציה שלמה.
צרו Skill פשוט שמפעיל את סוכן ה-security-reviewer שיצרתם:
- צרו תיקייה:
mkdir -p .claude/commands - צרו קובץ
.claude/commands/quick-security.md:--- name: quick-security description: Quick security scan agent: security-reviewer context: fork --- Scan src/ for hardcoded secrets and SQL injection only. Return a one-paragraph summary. - בשיחה, הקלידו
/quick-securityובדקו שהסוכן מופעל.
מילון מונחים
| מונח | הסבר |
|---|---|
| Subagent (סוכן-משנה) | מופע נפרד של Claude שנוצר על ידי השיחה הראשית לביצוע משימה ממוקדת. פועל בחלון הקשר עצמאי ומחזיר סיכום |
| Context Window (חלון הקשר) | כמות הטקסט ש-Claude יכול "לזכור" בשיחה. כל סוכן מקבל חלון משלו — מה שמרחיב את קיבולת העבודה הכוללת |
| Frontmatter | בלוק YAML בתחילת קובץ Markdown (בתוך ---) שמגדיר מטא-דאטה: שם, מודל, כלים, מגבלות, זיכרון, הרשאות |
| Parallel Execution (הרצה מקבילית) | הפעלת כמה סוכנים בו-זמנית על משימות עצמאיות. חוסך זמן בלי לעלות יותר |
| maxTurns | מגבלה על מספר ה"תורות" (הלוך-חזור) של סוכן. מונע סוכנים שרצים ללא סוף ועולים הרבה |
| Agent Teams (צוותי סוכנים) | תכונה ניסיונית (v2.1.32+) שמאפשרת לכמה מופעי Claude לעבוד כעמיתים עם תקשורת דו-כיוונית, רשימת משימות משותפת, ו-Mailbox |
| Orchestrator Pattern (דפוס המתזמר) | דפוס שבו השיחה הראשית מפרקת עבודה גדולה, מקצה סוכנים, ומסנתזת תוצאות |
| Forked Context (הקשר מסועף) | כשסוכן רץ בבידוד — עם עותק של ההקשר אבל בלי להשפיע על השיחה הראשית |
| Agent Memory (זיכרון סוכן) | תיקייה מתמשכת שהסוכן משתמש בה לצבור ידע בין סשנים. שלושה scopes: user, project, local |
| Effort Level | עומק החשיבה של המודל: low (מהיר, זול), medium (ברירת מחדל), high (עמוק, יקר), max (Opus 4.6 בלבד) |
| Isolation (Worktree) | הגדרה שגורמת לסוכן לרוץ ב-Git Worktree מבודד — עותק נפרד של הריפו שמונע התנגשויות |
| Background Agent | סוכן שרץ ברקע בזמן שאתם ממשיכים לעבוד. מופעל עם Ctrl+B, בקשה בשפה טבעית, או background: true |
| @-mention (הזכרה) | הפעלת סוכן ספציפי מתוך שיחה על ידי הקלדת @ ובחירת הסוכן. מבטיח שהסוכן הזה ירוץ |
Frameworks להחלטות — סיכום
אם צריך לחקור קוד בלי לשנות → Explore Agent (Haiku, מהיר)
אם צריך תוכנית עבודה → Plan Agent (יורש מודל)
אם צריך לבצע שינויים → General-Purpose Agent (יורש מודל, כל הכלים)
אם צריך סריקה מתמחה (אבטחה, תוכן, ביצועים) → Custom Agent
אם המשימה פשוטה ורוטינית (פורמט, grep, טסטים) → model: haiku ($0.01-0.05)
אם המשימה דורשת ניתוח או יצירה (ביקורת, תוכן, תכנון) → model: sonnet ($0.10-0.50)
אם המשימה דורשת חשיבה עמוקה (אבטחה, ארכיטקטורה, refactoring) → model: opus ($0.50-2.00)
Subagents (האצלה): המשימה מוגדרת היטב, התוצאה ידועה מראש, כל סוכן עובד עצמאי.
Teams (שיתוף): המשימה פתוחה, צריכים "דיון" בין גישות, סוכנים צריכים לשתף מידע תוך כדי עבודה.
Skills (הקשר ראשי): הנחיות ניתנות לשימוש חוזר שרצות בהקשר הראשי — לא צריכות בידוד.
שגרת עבודה — Agents בשוטף
בנוסף לשגרת ה-Hooks מפרק 1, סוכנים הם לא "דבר שמגדירים פעם" — הם כלי עבודה יומיומי. הנה שגרה מומלצת:
| תדירות | מה לעשות | זמן משוער | סוכן מומלץ |
|---|---|---|---|
| כל PR | הריצו /simplify או סוכן Code Reviewer |
2-5 דקות | code-reviewer (Sonnet) |
| יומי | בדיקת עלויות עם /cost — ודאו שאתם בתקציב |
30 שניות | (ידני) |
| שבועי | סריקת אבטחה על קוד חדש שנכתב השבוע | 5-10 דקות | security-reviewer (Opus) |
| שבועי | עדכון סוכנים — שפרו הנחיות בהתאם לתוצאות, בדקו Agent Memory | 10 דקות | (ידני — עריכת .md + קריאת MEMORY.md) |
| חודשי | ביקורת מלאה עם Orchestrator Pattern — אבטחה + ביצועים + איכות | 15-30 דקות | ריבוי סוכנים במקביל |
| חודשי | בדיקת עלויות מצטברות — האם המודלים נבחרו נכון? | 5 דקות | (ידני) |
תרגילים מעשיים
בנו סוכן ביקורת קוד שמותאם לפרויקט הספציפי שלכם:
- צרו קובץ
.claude/agents/my-reviewer.md - ב-Frontmatter:
model: sonnet,effort: medium,tools: Read, Grep, Glob, Bash,maxTurns: 20,memory: project - ב-Body, כתבו הנחיות ספציפיות לפרויקט שלכם:
- קונבנציות שמות (camelCase? snake_case?)
- דפוסים מועדפים (Factory? Repository? Hooks?)
- דברים שהסוכן צריך לדגלל (פונקציות ארוכות מ-X שורות, קבצים בלי טסטים)
- הפעילו על קובץ אמיתי בפרויקט
- קראו את הדוח — האם ההנחיות שכתבתם משתקפות בביקורת?
- עדכנו את ההנחיות ונסו שוב. בקשו מהסוכן: "Save what you learned to your memory"
זמן משוער: 20 דקות. תוצאה: סוכן ביקורת שמכיר את הסטנדרטים של הפרויקט ושומר ידע מסשן לסשן.
בנו תזמורת שמריצה שלושה סוכנים במקביל:
- ודאו שיש לכם את
security-reviewer.mdו-my-reviewer.mdמתרגיל 1 - צרו סוכן שלישי:
test-checker.md—model: haiku,tools: Read, Bash, Glob,maxTurns: 5. ההנחיות: "Run the test suite and report: total tests, passing, failing, coverage percentage" - בשיחה חדשה, בקשו מ-Claude:
"Run these three agents in parallel on the src/ directory: security-reviewer, my-reviewer, and test-checker. Synthesize their reports into one summary." - שימו לב ל: זמן ביצוע, העלות (בדקו עם
/cost), ואיכות הדוח המסונתז
זמן משוער: 15-20 דקות. תוצאה: דוח ביקורת מקיף שנוצר בשליש מהזמן.
בנו סוכן שמשלב Hooks מפרק 1:
- צרו סוכן
safe-editor.md— סוכן שעורך קוד אבל עם מעקות בטיחות - ב-Frontmatter, הוסיפו:
hooks: PostToolUse: - matcher: "Edit|Write" hooks: - type: command command: "./scripts/run-linter.sh" - תנו לסוכן הנחיות ספציפיות: "Always run tests after making changes"
- הפעילו את הסוכן ובקשו ממנו לבצע שינוי קטן בקובץ
- ודאו שה-Hook מתפעל: הקובץ צריך לעבור Linting אוטומטי אחרי כל עריכה
זמן משוער: 15-20 דקות. תוצאה: סוכן שמשלב אוטומציה (Hooks) עם אינטליגנציה (Agent).
חשבו תקציב חודשי לשימוש בסוכנים:
- רשמו כמה PRs אתם פותחים בשבוע בממוצע — זה מספר הפעלות code-reviewer
- רשמו כמה פעמים בשבוע אתם צריכים ביקורת אבטחה
- רשמו כמה פוסטים/תכנים אתם מייצרים בחודש
- חשבו: (מספר הפעלות * עלות ממוצעת למודל) * 4 שבועות
- האם התקציב סביר? אם לא — איפה אפשר להחליף Opus ב-Sonnet או Sonnet ב-Haiku?
זמן משוער: 10 דקות. תוצאה: אומדן עלויות חודשי ריאליסטי עם תוכנית אופטימיזציה.
צרו סוכן אחד מותאם בתיקיית .claude/agents/ שרלוונטי לעבודה היומיומית שלכם. זה יכול להיות Code Reviewer, Security Scanner, Content Writer, או כל דבר אחר. הנקודה היא לחוות את ההבדל בין לעבוד עם Claude ישירות לבין להאציל לסוכן מתמחה. ברגע שתראו סוכן חוזר עם דוח מפורט בלי שנגעתם בהקשר — תבינו למה זה משנה את הכל.
בדוק את עצמך — האם עברת את פרק 2?
ענו על 5 השאלות האלה. אם אתם יכולים לענות על 4 מתוך 5 — אתם מוכנים לפרק הבא.
- למה חלון הקשר הנפרד של Subagent הוא יתרון ולא חיסרון? (רמז: הסוכן לא מזהם את ההקשר הראשי — אתה רואה רק את המסקנה, לא 50 קבצים שהסוכן קרא)
- איך תחליט אם לשים סוכן ב-.claude/agents/ (פרויקט) או ב-~/.claude/agents/ (גלובלי)? (רמז: פרויקטי = ספציפי כמו code-reviewer עם סטנדרטים של הפרויקט. גלובלי = כללי כמו security-reviewer שרלוונטי לכל פרויקט)
- למה maxTurns חשוב גם לאיכות וגם לתקציב? (רמז: maxTurns מונע סוכן שרץ ללא סוף ועולה הרבה, אבל maxTurns נמוך מדי יגרום לסוכן לסיים לפני שהוא מצא תשובה)
- מתי כדאי להריץ סוכנים במקביל ומתי בסדרה? (רמז: מקביל כשעצמאיים — security + code review + tests. סדרתי כשסוכן B צריך את הפלט של A)
- איך Hooks מפרק 1 ו-Agents מפרק 2 עובדים ביחד? (רמז: Hooks באים ב-Frontmatter של Agent, PostToolUse Hook יכול להריץ linter אחרי כל עריכה שהסוכן עושה)
אם נתקעתם — גללו חזרה לסעיף הרלוונטי. הנקודה היא להבין, לא לזכור.
צ'קליסט — סיכום פרק 2
- מבין מה זה Subagent ואיך חלון ההקשר הנפרד שלו עובד
- מכיר את הסוכנים המובנים: Explore (Haiku), Plan (inherit), General-Purpose (inherit, כל הכלים)
- יצרתי תיקיית
.claude/agents/בפרויקט שלי - יש לי לפחות סוכן מותאם אחד עובד (Security Reviewer או Content Writer)
- מבין את כל שדות ה-Frontmatter: name, description, model, tools, disallowedTools, effort, maxTurns, hooks, memory, permissionMode, skills, mcpServers, background, isolation
- יודע את ההבדל בין
tools(Allowlist) ל-disallowedTools(Blocklist) ואיך הם עובדים ביחד - מכיר את /agents — הפקודה לניהול אינטראקטיבי של סוכנים
- הרצתי סוכנים במקביל (לפחות /simplify) וראיתי את הדוח המסונתז
- מבין מתי להשתמש בסוכן ומתי לעשות לבד (כלל 5 הדקות)
- מכיר את Orchestrator Pattern — פירוק, בחירה, הרצה, סינתזה
- יודע לבחור מודל לסוכן לפי סוג המשימה (Haiku/Sonnet/Opus)
- מגדיר
maxTurnsלכל סוכן כדי לשלוט בעלויות - בדקתי עלויות עם
/costלפני ואחרי הפעלת סוכן - מכיר את הקשר בין Agents ל-Skills — שני כיוונים: Skill שמפעיל Agent ו-Agent שטוען Skills
- מבין Agent Memory — שלושה scopes: user, project, local
- מודע ל-Agent Teams (ניסיוני) וההבדל מ-Subagents
- מכיר Background Agents — הרצה ב-Ctrl+B או background: true
- יש לי שגרת עבודה מתוכננת לשימוש בסוכנים
סיכום הפרק
התובנה המרכזית של הפרק: אתה לא חייב לעשות הכל בעצמך. Subagents מאפשרים לך להאציל משימות שלמות למופעי Claude עצמאיים — כל אחד עם חלון הקשר משלו, כלים מוגדרים, ותקציב שליטה. מה שהשתנה: במקום לעבוד בשיחה אחת ארוכה שצורכת context, עכשיו יש לך "צוות" של סוכנים מתמחים שעובדים במקביל ומחזירים תוצאות נקיות. הקונספט שמחבר את הפרק הזה לפרק הקודם: Hooks (פרק 1) אוכפים כללים דטרמיניסטיים, ו-Agents (פרק 2) מבצעים משימות אינטליגנטיות — כשהם עובדים ביחד (Hooks בתוך Agent Frontmatter), יש לך אוטומציה שהיא גם חכמה וגם אמינה. בפרק הבא נעבור ל-MCP — שיתן לסוכנים שלך גישה לעולם החיצוני.