לאחר ארבעים שעות של בניית שרת MCP שמשרת את דרישות סקירה של קוד, עמית שחרר קובץ מונח עשר דקות לעומת ארבעים שעות, אותו דבר. .claude/skills/ חוויה זו לימדה אותי משהו שאף תיעוד לא מסביר מספיק בבירור.קלוד קוד יש שלושה מנגנונים נפרדים של הרחבה, ויש להם אפס כיסוי ברגע שאתה מבין מה כל אחד באמת עושה. מאחורי שלושת המנגנונים האלה מגלים פילוסופיה אדריכלית מכוונת ששווה להבין לפני שאתה כותב קו יחיד של הגדרת. החלטות עיצוב האדריכלות מאחורי שלוש מנגנונים כל הרחבה לקוד נופלת לאחת משלושת הקטגוריות.הם קיימים כמנגנונים נפרדים משום שהם פועלים על שכבות שונות בסיסיות של המערכת.זה לא מקרי. תשובה: "איך קלאוד מקבל גישה למערכות מחוץ לגבולות התהליך שלו?" הם תוכניות נפרדות שמתקשרות עם קלאוד באמצעות JSON-RPC. פרוטוקול הנושא המודל מגדיר את תבנית החוט (שיחות כלי, קריאות משאבים, תבניות בקשות), אבל השרת עצמו הוא רק תוכנית שמדברת JSON דרך סטודיו או HTTP. הוא שומר על חיבורים משלו, מצב משלו, מחזור החיים משלו. קלאוד שולח בקשה, השרת עושה את העבודה ומשלח חזרה תגובה. MCP servers תשובה: "איך אתה מפעיל את קלאוד עם התנהגות שונה עבור משימות שונות?" סוכן תת הוא פגישה מבודדת של קלאוד עם פקודה מערכת משלה, בחירת מודל משלה, גישה לכלים משלה, וחלון הקשר משלה. Subagents תשובה: "איך אתה מדביק ידע שניתן להשתמש בו בשיחה?" מיומנות היא קובץ סימון שהופך לפקודה סלאש. כאשר הוא מתבקש, התוכן שלו מתבזבז ישירות בשיחה הנוכחית בתור הוראות. אין תהליך חדש. אין בידוד. אין קשר נפרד. רק טקסט שמגדיר את התנהגותו של קלוד בתוך הפגישה הקיימת. Skills כיצד שרתים MCP למעשה עובדים תחת הכובע פרוטוקול הנושא המודל הוא פרוטוקול JSON-RPC 2.0. כאשר Claude Code מתחיל, הוא מפעיל כל שרת MCP המוגדר בתור תהליך ילד ומקים ערוץ תקשורת דו-כיווני דרך סטודיו. כאשר קלאוד מחליט להשתמש בכלי MCP, הסדרה היא: Claude מייצר שיחת כלי עם שם וארגומנטים JSON Claude Code שולח את זה כביקוש JSON-RPC לתהליך השרת המתאים השרת מבצע את הבקשה (מחפש מסד נתונים, קורא ל-API, קורא למערכת קבצים) השרת מחזיר את התוצאה בתגובה JSON-RPC קלוד קוד מזין את התשובה בחזרה לתוך הקשר של קלוד זהו תקשורת בין תהליכים אמיתית.השרת יכול להיות כתוב בכל שפה.הוא יכול לשמור על חיבורים מתמשכים למסדי נתונים, תוצאות קח, ליישם הגבלת קצב, לאכוף בקרת גישה.זה תוכנית אמיתית עם מצב אמיתי. { "mcpServers": { "analytics": { "command": "node", "args": ["./mcp-servers/analytics.js"], "env": { "DATABASE_URL": "postgresql://localhost/analytics", "MAX_ROWS": "1000", "QUERY_TIMEOUT_MS": "5000" } }, "deploy": { "command": "./mcp-servers/deploy-server", "args": ["--environment", "staging", "--read-only"], "env": { "API_TOKEN": "${DEPLOY_TOKEN}" } } } } The ו משתנים סביבתיים לעיל אינם מאפיינים של פרוטוקול MCP. הם גבולות אבטחה ברמה של יישום שהשרת האנליטיקה מחייב באופן פנימי. זוהי נקודה אדריכלית חשובה: פרוטוקול MCP מתייחס לתקשורת, אבל השרת שלך מתייחס למדיניות. אם קלוד מבקש כל שורה בטבלה בעלת עשרת מיליון שורות, הפרוטוקול ישמח להעביר את הבקשה. MAX_ROWS QUERY_TIMEOUT_MS עבור אינטגרציות קריטיות ביצועים שבהן השרת מטפל באלפי בקשות או שומר על בריכות חיבור, Rust שווה את ההשקעה. היא מכסה את כל התהליך, החל מטיפול בפרוטוקול ועד הפצת הייצור, כולל איחוד חיבור וביטול מעולה. מדריך לבניית שרתים MCP ב-Rust שרתים MCP מרחוק באמצעות HTTP עם SSE עוקבים אחר אותו פרוטוקול, אך מחליפים סטודיו עם תחבורה HTTP. זה חשוב עבור תשתית צוות משותף, שבו דוגמה אחת של שרת MCP משרתת מפתחים מרובים, אך היא מוסיפה זקנות רשת ודורשת אימות עבור רוב הצוותים, שרתים סטודיו מקומיים פשוטים ומהירים יותר. איך סובאג'טים עובדים תחת הכובע תת-סוכנים אינם טכנולוגיה נפרדת. הם פגישות קוד קלוד עם פרמטרים מוגבלים. כשאתה מזמין תת-סוכן, קלוד קוד מתחיל שיחה חדשה עם המודל המפורט בתצורה של הסוכן. הצהרת המערכת מגיעה מהגוף של קובץ הסוכן. רשימת הכלים מסודרת רק למה שההגדרה של הסוכן מאפשרת. ובעיקר, חלון הקשר ריק מלבד הצהרת המערכת ואת המשימה שנתת לסוכן. בידוד זה יש השלכות עמוקות הן על עלות והן על איכות. לשקול פגישה דיבוג שבו אתה חוקר מסד קוד במשך עשרים דקות. חלון הקשר העיקרי שלך מכיל עשרות קריאות קבצים, תוצאות קלט, עקבות סטק, ושיחות. אם עכשיו אתה מבקש סקירה של קוד באותה הפגישה, סקירה מתרחשת בהקשר של כל רעש דיבוג. סוכן משנה מתחיל נקי. הקשר שלו מכיל רק את הצעת המערכת (קריטריוני הביקורת שלך) ואת הקבצים שביקשת ממנו לבדוק. אין רעש. אין מצב מצטבר. מאשר ביקורות הפגישה הראשית, מכיוון שהמודל מתמקד לחלוטין במשימה. טוב יותר --- name: code-reviewer description: Reviews code for quality, security, and style model: haiku tools: Read, Grep, Glob, Bash disallowedTools: Write, Edit mcpServers: - github maxTurns: 15 --- You are a code review specialist. You have read-only access to the codebase and the GitHub API. Review criteria: - No unwrap() in production code paths (use proper error handling) - All public functions have doc comments - Error types implement std::fmt::Display - No println! in library code (use tracing macros) - Integration tests exist for new API endpoints - No TODO without a linked issue number For each file, provide a pass/fail checklist and specific line references for any failures. Do not provide general advice — only specific findings. The עבור עבודה תואמת דפוס כגון בדיקת סגנון ויישום קונבנציונל, Haiku מתפקד בהשוואה ל- Opus. model: haiku The ההנחיה יוצרת גבול קשיח.אפילו אם ההנחיה של המערכת אומרת "תקן את כל הבעיות שאתה מוצא", הסוכן התחתון אינו יכול לשנות קבצים.זה מתבצע על שכבת הגישה למכשיר, לא על שכבת ההנחיה. disallowedTools: Write, Edit The מונע מפגשים של סובייקטים שנמלטים.ללא זה, סובייקט שמנתח בסיס קוד גדול עלול לחזור במשך חמישים סיבובים, ומעלות עלויות. maxTurns: 15 המתמטיקה של העלות האמיתית של מסלול מודל זה המקום שבו סוכני משנה לשלם עבור עצמם ולאחר מכן כמה. תחשבו על צוות של חמישה מפתחים, כל אחד מנוהל בערך עשר ביקורות קוד ביום באמצעות קוד קלוד. ללא סוכנים, כל ביקורות פועלות בפגישה העיקרית של אופוס. עם הצטברות הקשר מעבודות אחרות, ביקורות טיפוסיות עשויות לצרוך 15,000-25,000 טוקיני כניסה ויצרו 2,000-4,000 טוקיני כניסה. במחירים של אופוס, זה לא טריוויאלי מעל חמישים ביקורות ביום. עם תת-סוכן Haiku, אותו סקירה פועלת בחלון הקשר נקי. טוקי ההכנסה יורדים ל 3,000-8,000 (המלצה המערכת בתוספת הקוד שנבדק, אין הקשר המצטבר). ואת העלות של Haiku לכל טוקן היא נמוכה באופן דרמטי מאשר Opus. אבל יש יתרון בעלויות מתון יותר. בגלל חלונות הקשר של סובאגר הם מבודדים ונקיים, הביקורות מהירות יותר. פחות קשרי כניסה פירושו פחות זמן עיבוד. ביקורות סובאגר של Haiku בדרך כלל חוזרות תוך 2-5 שניות. אותה ביקורות בפגישה של Opus נפוחה עשויה לקחת 10-20 שניות. מעל חמישים ביקורות יומיות, וזה חסכון זמן משמעותי. למרות זאת, החלטת הנחיתה של המודל אינה תמיד ברורה. חלק מהמשימות באמת צריכות שיקול דעת ברמה של אופוס. מפגשים של דיבוג עמוקים שבהם המודל צריך לשמור על מצב מורכב על פני קבצים רבים. ניתוח ארכיטקטוני שבו המודל צריך לחשוב על השלכות המערכת כולה. משימות Refactoring שבהן המודל צריך להבין מערכות יחסים סמנטיות עדינה. אלה צריכים להישאר על אופוס, אבל בסוכנים בודדים כדי שהקשר יישאר נקי. עבור סדרה רחבה יותר של אסטרטגיות עלות, שלנו מכסה מסלול מודל לצד גישות אחרות כגון ניהול הקשר והזמנה מודעת לטוקן. Claude Code Cost Optimization Guide - מדריך לעלויות איך מיומנויות לעבוד על שכבה המובטחת מיומנויות הן המנגנון הפשוט ביותר מבחינה אדריכלית, והפשטות היא תכונה. שם התיקיה הופך לפקודה Slash. קוד ריידס Claude Code Raeds והכניס את התוכן שלו לשיחה הנוכחית. .claude/skills/ /review .claude/skills/review/SKILL.md אין תהליך. אין בידוד. אין חלון הקשר נפרד. הטקסט של המיומנות מצטרף לשיחה הקיימת שלך כאילו הכנת אותו בעצמך. כלומר המיומנויות מרוויחות מהקשר הקיימת של השיחה (קלאוד כבר יודע אילו קבצים אתה עובד על), אבל הם גם יורשים את הרעש הצטבר של השיחה. # SQL Migration Standards Review the migration files for compliance with team standards. ## Naming Conventions - Tables: plural snake_case (user_sessions, not UserSession or user_session) - Columns: singular snake_case (created_at, not CreatedAt) - Indexes: idx_{table}_{columns} (idx_user_sessions_user_id) - Foreign keys: fk_{table}_{referenced_table} (fk_orders_users) ## Safety Requirements - All CREATE INDEX must use CONCURRENTLY - ALTER TABLE ADD COLUMN must include a DEFAULT for non-nullable columns - No DROP COLUMN without a preceding release that stops reading the column - All migrations must be reversible (provide both up and down) ## Query Patterns - Use EXISTS instead of IN for subqueries - Use COALESCE instead of CASE WHEN ... IS NULL - Avoid SELECT * in application code - Always specify column lists in INSERT statements Current schema for reference: $(cat db/schema.sql) Migration to review: $ARGUMENTS The סינטקס מבצעת פקודה shell בזמן ההזמנה ומדביקה את היציאה.זה נותן יכולות דינמיות מוגבלות.הן יכולות לכלול תוכן קובץ, משתנים סביבתיים, או יציאת פקודה, אבל הן לא יכולות לשמור על חיבורים או לבצע פעולות חיצוניות מרובות שלבים.הפקודה shell פועלת פעם אחת, היציאה שלה נלקחת והטקסט הסטטי הזה הופך לחלק מההזמנה. $(cat db/schema.sql) The משתנה מקבל הכל לאחר הפקודה slash. יינתן לעבור למסלול הקובץ, המאפשר לך להפנות את המיומנות לקבצים ספציפיים. $ARGUMENTS /migration db/migrations/20260311_add_sessions.sql $ARGUMENTS מיומנויות הן חזקות בדיוק בגלל שהן פשוטות.כל אחד יכול לכתוב אחת.לקבוצות שבהן לא מפתחים צריכים לקודד את המומחיות שלהם, מכסה כיצד מהנדסים QA, מנהלי מוצר וסופרים טכניים ליצור מיומנויות יעילות מבלי לגעת בקוד. מיומנויות לצוותים שאינם טכניים מתי לא להשתמש בכל מנגנון (אנטי דפוסים) הבנת מה כל מנגנון עושה היטב היא רק חצי מהתמונה; לדעת מתי להימנע מכל אחד מונע את הטעויות שעשיתי בהתחלה. מערכת MCP Server Anti-Pattern אם המידע לא משתנה בין הפניות ולא מגיע ממערכת חיצונית, זה מיומנות.ראיתי צוותים בונים שרתים MCP שמחזירים סטנדרטים של קוד החברה, תיעוד API, אפילו מדריכים לסגנון. Do not build an MCP server to serve static content. Claude Code כבר יש את כלי Bash. אם "האינטגרציה" שלך פועלת בפקודה CLI ופרסיקה את היציאה, אינך זקוק לשרת MCP. מיומנות שמורה לקוד להשתמש ב- Bash עם פקודות ספציפיות היא פשוטה יותר. לא כל החיצוני זקוק לשרת MCP. אם קלוד יכול להפעיל פקודה CLI באמצעות Bash, זה פשוט יותר מאשר בניית ושמירה על שרת MCP. CLIs (באמצעות כלי Bash) הם נהדרים עבור זרימות עבודה מקומיות של סוכן יחיד. Do not build an MCP server when a Bash tool call would suffice. משרתים MCP נחוצים כאשר אתה צריך ביצוע מרחוק, רישיון קנה מידה, חיבורים מתמשכים, או פעולות מדינה. או לרוץ משרתים MCP מרוויחים את המורכבות שלהם כאשר סוכנים מרובים או משתמשים צריכים גישה משותפת, כאשר אתה צריך בקביעות רישיונות מפורשות, או כאשר האינטגרציה דורשת שמירה על מצב בין בקשות מרובות. git log cargo test שרת MCP שמבצע SQL אקראי נגד ייצור הוא נשק מטען. כל שרת צריך לאכוף את זמני השאילתה של השאילתה, גבולות שורה, גישה רק לקריאה במידת הצורך, ואימות כניסה.הפרוטוקול לא יגן עליך. Do not build an MCP server without safety boundaries. סוכנים אנטי-פטנטים סובאג'נטים זוהרים לעבודה חוזרת ומומחה.אם אתה צריך לעשות משהו פעם אחת, פשוט לעשות את זה בפגישה העיקרית.התפקיד העליון של יצירת ותחזוקה של קובץ הגדרת סוכן אינו שווה את זה עבור עבודה אקזוטית. Do not create a subagent for a one-off task. כמה משימות באמת דורשות שיקול דעת חזק יותר. ניסיתי לנהל ניתוח ארכיטקטוני על הייקו פעם אחת. הוא זיהה בעיות ברמת פני השטח, אך פספס תלות מעגלית שאופוס תפס מיד. הייקו הוא מדהים עבור תואמות דפוסים ויישום רשימות בדיקה. הוא נאבק עם משימות הדורשות שיקול דעת רב-שלבים על פני קבצים רבים. Do not route everything to Haiku to save money. תת-סוכן שמזמין תת-סוכן אחר שמזמין ת-סוכן שלישי הוא אנטי-דפוס. כל שכבה מוסיפה עיכוב ומסתירה את העבודה בפועל. אם אתה צריך כל כך הרבה תזמורת, לערוך מחדש את הגישה שלך. בדרך כלל התשובה היא תת-סוכן אחד עם גישה למשרתים ומומחיות מרובים של MCP, לא שרשרת של תת-סוכנים. Do not create deeply nested subagent chains. מיומנויות אנטי-פטרנס "לבדוק את שיעור שגיאות הייצור" כמדריך מיומנות יוביל את קלאוד למטריקים הלוסיננטיים.אם המשימה דורשת נתונים מחוץ לעידתו של קלאוד, תזדקק לשרת MCP (או לסוכן משני עם גישה MCP). Do not write skills that require external data. התוכן של מיומנות נזרק לחלון הקשר. מיומנות של 5,000 מילים צורכת תוויות על כל הזמנה. שמור על מיומנויות ממוקדות. להדביק אותו בתנאי במקום להדביק אותו ישירות במיומנות. Do not write skills that are too long. $(cat reference.md) מיומנות פועלת בהקשר הנוכחי.אם ההקשר הנוכחי מזוהה עם עבודה לא קשורה, היעילות של המיומנות יורדת.משימות הדורשות שטח נקי (ביקורות, ניתוח, יצירת תיעוד) משרתות טוב יותר על ידי סובאג'נטים שמתחילים בחלון הקשר החדש. Do not use skills for tasks that need isolation. מודל ההרכב בייצור שלושת המנגנונים אינם חלופיים; הם שכבות שמרכיבות.הבנת דפוסי ההרכב היא מה שמפריד מערכת עבודה מאחת אלגנטית. סובאג'נט יכול להיות MCP שרתים מיועדים אליו.זה יוצר גישה מגוונת. סובאג'נט קוד-ביקורת יכול לגשת ל- API של GitHub דרך שרת MCP של GitHub אבל לא יכול לגעת במסד הנתונים שלך או צינור הפצה. הסוכן התחתון של הנתונים-אנליסט מעלה את מיומנויות הסטנדרטים של sql, כך שכל ניתוח עוקב אחר קונבנציונאות השם של הצוות שלך ודפוסי השאילתה מבלי שהסוכן התחתון של האנליסט צריך את ההסכמים האלה במדריך המערכת שלו. ניתן לתת ל-subagent גישה לשרת MCP של GitHub (לכן הוא יכול לקרוא פרסומים ותגובות) תוך אישור כתיבה ועריכה (לכן הוא לא יכול לשנות קבצים מקומיים). בהגדרת הייצור שלנו על פני 8 תוספי שוק, המיקום נראה כך: Layer 3: Skills (Team Knowledge) /review — code review checklist /migration — database migration standards /deploy-check — pre-deployment verification steps /sql-standards — SQL naming and query conventions /api-design — REST endpoint design patterns Layer 2: Subagents (Specialised Behaviour) code-reviewer (Haiku, read-only, GitHub MCP, review skill) debugger (Opus, full access, all MCP servers) database-analyst (Sonnet, read-only, PostgreSQL MCP, sql-standards skill) deploy-checker (Sonnet, read-only, deploy + analytics MCP, deploy-check skill) doc-writer (Haiku, read-only, no MCP, style-guide skill) Layer 1: MCP Servers (External Connections) analytics-db — PostgreSQL metrics database deploy-pipeline — deployment API wrapper github — GitHub API for PRs and issues content-api — CMS for documentation publishing postgresql — application database (read-only) כל סוכן מכין בדיוק את שרתי ה-MCP והכישורים הדרושים לו, ברמה המודל שמתאימה למורכבות המשימה שלו. הבדיקה משתמשת ב-Sonnet משום שהיא צריכה לדון בהכנות ההפצה בין מקורות נתונים מרובים. הבדיקה משתמשת ב-Haiku משום שהכתיבה הטכנית היא בעיקר תואמת דפוס עם מדריך לסגנון. לקבלת הפרטים המלאים על איך שכבות אלה עובדים יחד, המדריך שלנו על דוגמה נוספת היא תבנית ההרכב המלאה, ובמיוחד עבור תבנית הסוכן התחתון, מכסה את כל שדות החזית עם דוגמאות. תוספים, שרתים MCP ומיומנויות כארכיטקטורה שכבה מדריך בנייה של קלאוד סוכן תפקיד ההחלטה לאחר שנה של בניית תוספים הייצור, ההחלטה היא פונקציה טהורה של מה שאתה צריך: def choose_mechanism(need): if need.requires_external_data or need.has_side_effects: return "MCP Server" if need.requires_different_model or need.requires_tool_restrictions or need.benefits_from_isolation: return "Subagent" if need.is_reusable_knowledge or need.is_workflow_template: return "Skill" if need.is_complex: return "Subagent + MCP Server + Skill" # compose all three אם אתה מוצא את עצמך בונים שרת MCP שמחזיר טקסט סטטי, לעצור.זה מיומנות.אם אתה כותב מיומנות שאומר "לחקור את מסד הנתונים," לעצור.זה שרת MCP.אם אתה מפעיל פגישות Opus יקרות לבדיקות שגרתיות, לעצור.זה סובאג'נט על Haiku. מה השתנה לנו לפני שהבנו את המשולש, היו לנו שרתים MCP שעושים את העבודה של מיומנויות, מיומנויות מנסות לעשות את העבודה של שרתים MCP, ואין סובאגנטים בכלל. לאחר ההרחבה: 34+ מיומנויות מקודדות את ההסכמים של צוותינו באמצעות סקירת קוד, עבודת מסד נתונים, הפצה, תיעוד ועיצוב API. חמישה סופר-אגנים מתמודדים עם משימות מיוחדות בנקודת המחיר הנכונה עם בקרת גישה הנכונה. עלויות החודשיות ירדו באופן משמעותי.איכות הביקורת השתפרה כי סובאג'נטים מתחילים בהקשר נקי.מועצות הצוות הפכו עקביות כי מיומנויות לאכוף אותם באותו אופן עבור כל מפתחים.השרתים MCP הפכו פשוטים יותר כי הם הפסיקו לנסות להיות הכל; הם פשוט גשר למערכות חיצוניות ולא יותר. משולש ההרחבה אינו מסגרת תיאורטית.זה כלי מעשי שמונע ממך לבנות את הדבר הלא נכון.זה, בהתחשב בכך שבניתי את הדבר הלא נכון שלוש פעמים לפני שמצאתי את זה, שווה לדעת על זה.
