עליית ה-Harness Engineering | Agent Harness Course

מה תסיים/י לדעת לעשות בפרק הזה

לפרק harness דק ל-5 רכיביו — agent loop, state management, tool execution, context compaction, ו-constraints/governance — ולמפות איזה רכיב נבנה בכל פרק בהמשך.
לנמק במספרים את טענת ה-Harness Engineering — לקשר את הקפיצה מ-52.8% ל-66.5% ב-Terminal-Bench 2.0 לשינוי ה-harness בלבד, בלי החלפת מודל.
להשוות 4 גישות runtime — Claude Agent SDK (in-process), Claude Managed Agents (hosted), Deep Agents, ו-Aden Hive — ולבחור איזו מתאימה לאיזה תרחיש.
לזהות 3 טעויות שהורגות harness ביתי — framework כבד, free-form text output, התעלמות מ-tool latency — ולנסח לכל אחת את הנגד שהקורס מלמד.
להחליט מתי אתה "מחזיק את הלולאה" ומתי אתה רק "צרכן SDK" — ולמה ההבדל הזה הוא כל ההבדל בין debug אפשרי לקופסה שחורה.

מה צריך לדעת לפני שמתחילים

מה זה agent ולולאת agent — ברמת intro: כבר ראית/הרצת סוכן שמקבל goal, קורא tools, ומחזיר תוצאה (למשל מהפרק על multi-agent patterns ב-ai-agents-guide ch13, או דרך Claude Code).
נוחות ב-Terminal — הרצת פקודות, ניווט, עריכת קבצים, וניהול env vars. בפרק הזה לא נכתוב קוד עדיין, אבל מהפרק הבא כן.
קריאה בסיסית של Python או TypeScript — הקורס משתמש ב-Claude Agent SDK, והדוגמאות יהיו ב-Python. צריך להבין loop ו-function, לא יותר.
חשבון Anthropic — לא חובה כבר עכשיו, אבל יידרש API key מפרק 2. נדבר על למה דווקא API key (ולא subscription) חשוב לאוטומציה.

מה תפיק/י בסוף הפרק

מפת Harness — דיאגרמה של 5 רכיבי ה-harness הדק + טבלה שממפה כל רכיב לפרק שבונה אותו בקורס.
טבלת השוואת Runtimes — Claude Agent SDK / CMA / Deep Agents / Aden Hive: מי מחזיק את הלולאה, רמת ה-control, ה-scaling, ומתי לבחור כל אחד.
מסמך "למה לא framework כבד" — 3 הטעויות הקלאסיות (bloat מעל 1GB, אפס observability, לולאות 6+) והנגד הדק לכל אחת.
הצהרת מיקום אישית — משפט אחד שמגדיר איפה הפרויקט שלך נמצא היום על ציר "צרכן SDK ↔ בעל harness".
רשימת 5 השאלות שתשאל/י על כל runtime לפני שתבחר/י בו לפרויקט אמיתי.

🧵 חוט הפרויקט

קודם: זה הפרק הראשון — אין פרק קודם. נקודת ההתחלה היא שאתה כבר מריץ task דרך SDK מוכן וזה "עובד", אבל הלולאה היא קופסה שחורה.

הפרק הזה: פותחים את הקופסה השחורה. מבינים למה ה-harness אחראי ל-~70% מהביצועים, ממפים את 5 הרכיבים שלו, וסוקרים את נוף הכלים — כדי שתדע/י מה אנחנו בונים מאפס ומה אנחנו לא משכפלים.

אחר כך: פרק 2 — "אנטומיה של Harness דק: בונים את לולאת ה-Agent מאפס". שם נכתוב את harness.py הראשון — לולאה מפורשת בפחות מ-150 שורות מעל ה-Claude Agent SDK.

למה הפרק הזה קיים: הסיפור של 14 הנקודות

מוטיבציהTerminal-Benchהוכחה מספרית

נתחיל בעובדה שמרסקת את האינטואיציה הראשונה של כל מי שבונה סוכנים. בפברואר 2026 פרסמה LangChain דוח שבו ציון על מבחן הסוכנים Terminal-Bench 2.0 קפץ מ-52.8% ל-66.5%. זו קפיצה של כמעט 14 נקודות אחוז — קפיצה ענקית במונחים של benchmark.

השאלה המתבקשת היא: איזה מודל חדש ומדהים הם השתמשו בו? התשובה: אותו מודל בדיוק. הם לא החליפו את המודל. הם לא שינו את ה-prompt בצורה מהפכנית. הם בנו מחדש את ה-harness — את התשתית התוכנתית שעוטפת את המודל ומריצה אותו.

זה הרגע שבו תעשיית הסוכנים הפנימה משהו שכבר היה נכון מתחת לפני השטח: רוב הכוח של סוכן לא חי במודל. הוא חי בקוד שמסביב למודל. זו הטענה המרכזית של מה שנקרא היום Harness Engineering, וההערכה הרווחת שעלתה כפרדיגמה הדומיננטית בפברואר 2026 היא ש-כ-70% מביצועי הסוכן חיים מחוץ למודל.

כדי להבין כמה זה מהפכני, שווה לזכור מאיפה באנו. בגל הקודם, ב-2023–2024, כל העניין היה prompt engineering: ניסחנו את הבקשה בצורה חכמה יותר, הוספנו "think step by step", בנינו תבניות prompt מתוחכמות. זה עבד עד גבול מסוים — ואז נתקע. הסיבה שזה נתקע היא שאי אפשר לנסח את הדרך מבעיית לולאה אינסופית. אי אפשר לבקש יפה מהמודל "אנא אל תאבד את ה-context שלך". הבעיות האלה הן מערכתיות, והפתרון להן הוא הנדסת מערכת — לא הנדסת בקשה.

זה המעבר: מ-prompt engineering (מהנדסים את הבקשה) ל-harness engineering (מהנדסים את המערכת סביב המודל). prompt engineering לא מת — הוא עדיין שכבה אחת מתוך הרבה. אבל הוא הפסיק להיות הסיפור המרכזי. הסיפור המרכזי הוא ה-runtime.

ויש כאן בשורה טובה במיוחד עבורך, אם את/ה vibe coder שכבר נוח/ה עם terminal וקוד: ה-harness הוא תוכנה, וזה התחום שלך. אתה לא צריך/ה תואר ב-machine learning כדי לבנות harness מעולה — אתה צריך/ה לדעת לכתוב לולאה נקייה, לטפל בשגיאות, לנהל state, ולחשוב על edge cases. אלה כישורי הנדסת תוכנה קלאסיים. במילים אחרות: ה-70% שחיים מחוץ למודל הם בדיוק ה-70% שאתה כבר יודע/ת לעבוד בהם. הקורס רק נותן לך את המפה הספציפית לעולם הסוכנים.

52.8% → 66.5%

Terminal-Bench 2.0 — הקפיצה שהשיגה LangChain בפברואר 2026 על ידי בנייה מחדש של ה-harness בלבד, ללא החלפת מודל. כ-14 נקודות אחוז שמגיעות מהנדסת ה-runtime, לא מה-LLM.
מקור: course.research.json — key_2026_updates.

רגע — מה זה בכלל Terminal-Bench, ולמה לסמוך עליו? זה מבחן שמודד עד כמה סוכן מסוגל לבצע משימות אמיתיות בטרמינל: לנווט במערכת קבצים, להריץ פקודות, לתקן קוד, לפתור בעיות הרצה. כלומר — בדיוק סוג העבודה שעבורה אתה בונה harness. זה לא מבחן של "כמה המודל יודע", אלא מבחן של "כמה המערכת מצליחה לסיים משימה מקצה לקצה". וזו בדיוק הנקודה: כשהמבחן בודק השלמת משימה, ולא ידע, הרכיב שזז את המחט הוא ה-harness — איך הוא מנהל את הלולאה, מתי הוא עוצר, איך הוא מתאושש מכשל. לכן הקפיצה של 14 נקודות באותו מודל היא לא אנקדוטה; היא ההוכחה הנקייה ביותר שיש לטענת ה-70%.

וכדי שלא תהיה אי-הבנה: 14 נקודות אחוז זה לא "שיפור נחמד". במונחי benchmark של סוכנים, זה כמו לדלג דור שלם של מודלים — רק שכאן לא חיכינו לדור הבא, אלא בנינו harness טוב יותר על אותו דור קיים. זו הסיבה שמשתלם לך, הקורא/ת, להשקיע את 8 הפרקים הבאים: אתה לומד/ת להוציא את ה-14 הנקודות האלה מהמערכות שלך, בעצמך.

שים לב מה זה אומר עבורך, מי שבונה. אם 70% מהביצועים נמצאים בקוד שאתה כותב — ולא במודל שאתה משלם עליו — אז כל שעה שאתה משקיע בלשפר את ה-harness שווה הרבה יותר משעה של "אולי מודל חזק יותר יציל אותי". המודל הוא קבוע. ה-harness הוא המשתנה שבשליטתך.

אבל מה זה אומר בפועל, "70% מחוץ למודל"? בוא ניקח את זה מהמופשט לקונקרטי. נניח שני סוכנים מקבלים את אותה משימה ואת אותו מודל בדיוק:

סוכן א' מריץ tools בטור, פורסר את הפלט מטקסט חופשי, ואין לו max-turns. כשקריאת tool נכשלת, הוא חוזר עליה שוב ושוב עד שנגמר ה-budget. הוא משלים אולי חצי מהמשימות.
סוכן ב' — אותו מודל בדיוק — מריץ קריאות עצמאיות במקביל, מקבל structured output שהוא יכול לסמוך עליו, ויש לו circuit breaker שעוצר לולאות. הוא משלים הרבה יותר, מהר יותר, ובזול יותר.

ההבדל בין השניים לא נגע במודל אפילו פעם אחת. כל ההבדל הוא ה-harness. זה מה ש-"70% מחוץ למודל" אומר בשפת הקוד היומיומית שלך.

✅ עשה/י עכשיו (2 דקות)

הסוכן שלך מהדוגמה הקודמת — האם הוא דומה יותר לסוכן א' או לסוכן ב'? כתוב/כתבי שורה אחת. אם התשובה היא "אין לי מושג כי הלולאה היא קופסה שחורה" — מצוין, זיהית את הבעיה שהקורס פותר.

טעות נפוצה: "מודל חזק יותר יפתור הכל"

האינטואיציה הטבעית כשסוכן נכשל היא לחכות למודל הבא. אבל Terminal-Bench הראה שאותו מודל בדיוק קפץ 14 נקודות רק משינוי ה-harness. אם הסוכן שלך נתקע, ב-2026 ההימור הנכון הוא לבדוק את הלולאה, את ניהול ה-context, ואת ה-tool execution — לא לחכות לשדרוג מודל. הכוח ב-runtime, ושם גם אתה שולט.

✅ עשה/י עכשיו (2 דקות)

חשוב/י על פעם אחרונה שסוכן שהרצת נכשל או נתקע. כתוב/כתבי במשפט אחד: האם ההסבר שלך לכישלון היה "המודל לא מספיק חכם" או "משהו בלולאה/בהרצה לא עבד"? שמור/שמרי את המשפט — בסוף הפרק נחזור אליו.

מה זה Agent Harness בכלל — וזו תוכנה, לא prompt

הגדרהמושג יסודAgent Harness

בוא נסכים על הגדרה מדויקת, כי כל הקורס נבנה עליה. Agent Harness הוא תשתית התוכנה שעוטפת LLM ומנהלת את כל מה שמסביב להרצה: את ה-state, את ביצוע ה-tools, את דחיסת ה-context, ואת ה-constraints. זו ההגדרה הרשמית שמופיעה ב-current_terminology של מחקר הקורס.

שים לב למילה החשובה: תוכנה. ה-harness הוא לא בקשה יפה למודל. הוא לא prompt מתוחכם. הוא קוד שרץ — לולאה שמחליטה מתי לקרוא למודל, פונקציות שמריצות tools, מנגנון שזוכר מה קרה בסבב הקודם, ושערים שעוצרים פעולות מסוכנות. כשהמודל אומר "אני רוצה להריץ את הפקודה ls", מישהו צריך באמת להריץ אותה, לתפוס את הפלט, ולהחזיר אותו למודל. ה-"מישהו" הזה הוא ה-harness.

וההגדרה המשלימה: Harness Engineering היא הפרקטיקה של עיצוב ואופטימיזציה של מערכות התוכנה סביב ה-LLM כדי למקסם את ביצועי הסוכן. כלומר — לא מהנדסים את הבקשה, מהנדסים את המערכת.

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

ה-harness שולח למודל את ה-goal יחד עם רשימת ה-tools הזמינים (search, read, edit).
המודל לא "מחפש" בעצמו — הוא מבקש: "הרץ search על הפונקציה הזו". ה-harness מריץ את ה-search בפועל ומחזיר את התוצאות.
המודל קורא את התוצאות, ומבקש: "קרא את הקובץ הראשון". ה-harness קורא ומחזיר.
המודל מבקש: "ערוך את השורה הזו". ה-harness מבצע את העריכה, מאמת שהיא הצליחה, ומחזיר אישור.
וכך הלאה — סבב אחר סבב — עד שהמודל אומר "סיימתי" או עד שה-harness עוצר אותו (max-turns, שגיאה, או policy gate).

שים/י לב כמה החלטות חשובות נמצאות לחלוטין מחוץ למודל: מי מריץ את ה-search? מה קורה אם הקובץ לא קיים? כמה סבבים מותר לפני שעוצרים? מה אם העריכה תמחק קוד קריטי? כל אלה הן החלטות harness — וכל אחת מהן יכולה להפיל ריצה שלמה. המודל יכול להיות מבריק, אבל אם ה-harness לא בודק שהקובץ קיים לפני שהוא קורא לו, הסוכן יקבל שגיאה, "יתבלבל", וינסה שוב ושוב. זו לא בעיית מודל. זו בעיית harness.

מסגרת החלטה: prompt engineering מול harness engineering

איך לדעת באיזו בעיה אתה מסתכל? השתמש/י בכלל הזה:

אם אתה משנה ניסוח כדי לקבל תשובה אחרת — אז זה prompt engineering. הוא חשוב, אבל הוא שכבה אחת.
אם אתה משנה מתי המודל נקרא, מה נשלח אליו בכל סבב, איך tools מורצים, או מה קורה כשמשהו נכשל — אז זה harness engineering. וזה רוב הכוח.
אם הבעיה היא "הסוכן נתקע/לולף/שכח/קרס" — אז זה כמעט תמיד harness, לא prompt. prompt לא יתקע אותך בלולאה אינסופית; harness כן.

נקודה עדינה אבל קריטית להמשך: המודל הוא stateless. הוא לא זוכר כלום בין קריאה לקריאה. כל פעם שאתה קורא ל-API, אתה שולח מחדש את כל ההיסטוריה הרלוונטית. מי שמחזיק את הזיכרון, מי שמחליט מה לשלוח ומה לא, מי שמצטבר את ה-state — זה ה-harness. המודל stateless, ה-harness stateful. נחזור לזה בפרק 2 כשנבנה את הלולאה, ובפרק 3 כשנילחם על ה-context.

יש לזה גם פן כלכלי שכדאי לקלוט כבר עכשיו: כיוון שכל סבב שולח מחדש את כל ההיסטוריה, ה-harness הוא גם מה שקובע כמה אתה משלם. harness שמנהל context בחוכמה שולח פחות tokens בכל סבב = ריצה זולה יותר. harness רשלני ששולח את כל ההיסטוריה הגולמית בכל פעם = חשבון שמתפוצח. כלומר ה-harness לא קובע רק אם הסוכן מצליח, אלא גם כמה ה-הצלחה עולה. שני הצירים — ביצועים ועלות — נשלטים מאותו מקום: הקוד שאתה כותב.

✅ עשה/י עכשיו (3 דקות)

קח/י משימה אמיתית שהרצת לסוכן (למשל "תקן את הבאג הזה ותריץ את הטסטים"). פרק/י אותה לפעולות: כמה פעמים, לדעתך, המודל נקרא? כמה tools הורצו? מי החזיק את התוצאות בין הקריאות? אם התשובה לאחרון היא "לא יודע/ת" — זה בדיוק מה שאנחנו פותחים בפרק הזה.

אנטומיה של Harness דק: 5 הרכיבים

ארכיטקטורה5 רכיביםמפת הקורס

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

רכיב 1 — Agent Loop (לולאת הסוכן)

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

למה זה הרכיב שהכי קל לטעות בו: רוב המפתחים חושבים שהלולאה היא "מובנת מאליה" ונותנים ל-SDK להריץ אותה כקופסה שחורה. אבל הלולאה היא בדיוק המקום שבו נוצרות הלולאות האינסופיות (הסוכן קורא לאותו tool שוב ושוב), שריפת ה-tokens, וההיתקעויות. מי שמחזיק את הלולאה במפורש — יכול לעצור אותה. מי שלא — רק רואה ש"זה נתקע". דוגמה מייצגת: סוכן שמנסה לקרוא קובץ שלא קיים, מקבל שגיאה, ומבקש לקרוא אותו שוב — 6 פעמים ברצף — כי אין בלולאה שום מנגנון שמזהה את החזרה. נבנה בפרק 2.

רכיב 2 — State Management (ניהול state)

מי זוכר מה קרה. רצף ההודעות — system, user, assistant, tool_result — שמצטבר בין הסבבים. כיוון שהמודל stateless, ה-state הוא אחריות ה-harness בלבד. אם תאבד אותו באמצע ריצה, הסוכן "שוכח" מה הוא עשה.

הנקודה שמפתיעה: בכל סבב, ה-harness שולח למודל מחדש את כל ההיסטוריה הרלוונטית — לא רק את ההודעה האחרונה. המודל לא "ממשיך מאיפה שהפסיק", הוא קורא הכל מההתחלה כל פעם. לכן ככל שהריצה מתארכת, כל סבב מתייקר וגדל. ניהול ה-state הוא לא רק "לזכור" — הוא להחליט מה בכלל שולחים בכל סבב. נבנה בפרק 2, ונילחם עליו בפרק 3.

רכיב 3 — Tool Execution (ביצוע tools)

איך המודל פועל על העולם. כשהמודל מבקש להריץ bash, לקרוא קובץ, או לקרוא ל-API — מישהו מבצע את זה בפועל, מאמת את הפלט, ומחזיר אותו. כאן גם נכנסים structured output, MCP לחיבורים חיצוניים, ו-parallelism.

למה זה לא טריוויאלי: המודל מחזיר טקסט. הוא לא "מריץ" כלום. כשהוא אומר "אני רוצה את הפקודה ls -la", ה-harness צריך לחלץ את הבקשה (בפורמט מובנה, לא לנחש מתוך טקסט חופשי!), להריץ אותה, לתפוס גם stdout וגם stderr, ולהחזיר את התוצאה בפורמט שהמודל מבין. אם תפרסר/י את הבקשה מטקסט חופשי — ה-harness יישבר ברגע שהמודל ינסח קצת אחרת. לכן structured output (פרק 4) הוא לא מותרות. נבנה בפרק 4.

רכיב 4 — Context Compaction (דחיסת context)

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

המלכודת שמסתתרת כאן: ה-Claude Agent SDK שומר באופן קשיח 33K tokens ל-output ול-safety, ו-compaction אוטומטי נורה כשהשימוש נוגע ב-~83.5% מהחלון. כלומר ה-history בפועל קטן ממה שנדמה, ו-decision קריטי יכול להימחק באמצע ריצה בלי שתבחר/י מה לשמר. זו ה-Compaction Buffer Trap — אחת המלכודות המסוכנות של הקורס, כי היא שקטה: אתה מגלה אותה רק כשהסוכן "שוכח" החלטה שקיבל לפני 10 סבבים. נבנה בפרק 3.

רכיב 5 — Constraints / Governance (אילוצים ושערים)

מה אסור לסוכן לעשות. שערים שחוסמים פעולות הרסניות, דורשים אישור אנושי בנקודות רגישות, ומגבילים מספר סבבים ותקציב tokens. בלי הרכיב הזה, סוכן עם גישת bash הוא rm -rf שמחכה לקרות.

למה שער דטרמיניסטי ולא "בקשה יפה": הפיתוי הוא לכתוב ב-system prompt "אל תריץ פקודות הרסניות". אבל מספיק hallucination אחד, או prompt injection אחד מתוך קובץ שהסוכן קרא, וה-bash הרסני יוצא לפועל. שער דטרמיניסטי (כמו שנבנה עם Faramesh בפרק 4) בודק את הפקודה לפני ההרצה בקוד — לא מבקש מהמודל להתנהג יפה. נבנה בפרק 4 (governance) ולאורך הקורס (limits, recovery).

#	רכיב	מה הוא עושה	נבנה בפרק
1	Agent Loop	קורא למודל, מריץ tools, חוזר עד עצירה	פרק 2
2	State Management	צובר את היסטוריית ההודעות בין סבבים	פרק 2 → 3
3	Tool Execution	מבצע tools, אוכף structured output, מחבר MCP	פרק 4
4	Context Compaction	מנהל את חלון ה-context, מונע איבוד היסטוריה	פרק 3
5	Constraints / Governance	שערים, limits, recovery — מה אסור לסוכן	פרק 4–5

שני רכיבים נוספים שמתווספים ל-harness בוגר — והם הסיבה ש"harness דק" הופך ל"צוות שעובד לבד" — הם orchestration (כמה סוכנים יחד, פרק 6) ו-memory (זיכרון מתמשך ושיפור עצמי, פרק 7). הם לא חלק מ-5 הרכיבים הבסיסיים, אבל הם הדבק שהופך harness בודד לצוות. פרק 8 מחבר את הכל ל-production.

שווה לעצור על למה דווקא 5 הרכיבים האלה, ולא 3 או 8. הם נבחרו כי כל אחד מהם הוא נקודת כשל עצמאית: harness יכול ליפול על כל אחד מהם בנפרד, ולכל אחד יש פתרון הנדסי נפרד. לולאה בלי בלם נופלת בדרך אחת (לולאה אינסופית); context לא מנוהל נופל בדרך אחרת (איבוד היסטוריה); tool בלי שער נופל בדרך שלישית (פעולה הרסנית). אם תזהה/י בעיה — היא כמעט תמיד תתמפה לאחד מ-5 הרכיבים. וזה בדיוק הכוח של המפה: היא לא רק מסבירה איך harness עובד, היא נותנת לך צ'קליסט אבחון. כשמשהו ישתבש בהמשך הקורס, השאלה הראשונה תהיה תמיד "באיזה מהחמישה זה?".

✅ עשה/י עכשיו (5 דקות) — זה ה-deliverable הראשון

צייר/י את הדיאגרמה: LLM במרכז, 5 רכיבים עוטפים אותו (loop, state, tools, context, governance). ליד כל רכיב כתוב/כתבי את מספר הפרק שבונה אותו לפי הטבלה למעלה. שמור/שמרי כ-harness-map.png או כסקיצה — זו "מפת ה-Harness" שתלווה אותך לאורך הקורס.

מבט מקרוב: איך נראה סבב אחד בלולאה

turn anatomyloopקונקרטי

לפני שנמשיך לנוף הכלים, בוא נעצור על סבב בודד (turn) בלולאה — כי זה הלב שנבנה בפרק 2, וכדאי שתחזיק/י אינטואיציה טובה עליו כבר עכשיו. סבב אחד הוא לא "המודל עונה". הוא רצף של 5 צעדים שה-harness אחראי עליהם:

צעד	מה קורה	מי אחראי
1. Build	בונים את ה-messages: system (config ה-harness) + כל ההיסטוריה עד עכשיו	harness
2. Call	שולחים למודל ומחכים לתשובה	harness ← API
3. Inspect	בודקים: האם התשובה מכילה `tool_use`? אם לא — סיימנו (stop)	harness
4. Execute	אם כן — מריצים את ה-tool בפועל, תופסים את הפלט	harness
5. Append	מוסיפים את ה-`tool_result` ל-state, וחוזרים לצעד 1	harness

שים/י לב: מתוך 5 הצעדים, המודל מעורב רק באחד וחצי (Call, וחלקית Inspect). כל השאר הוא harness. זו, בתמונה אחת, הסיבה ש-70% מהביצועים חיים מחוץ למודל — רוב העבודה בכל סבב היא קוד שאתה כותב.

ושים/י לב במיוחד לצעד 3, ה-stop condition. סוכן יודע שסיים באחת משלוש דרכים: (א) המודל החזיר תשובה סופית בלי בקשת tool; (ב) הגענו ל-max-turns; (ג) policy gate או circuit breaker עצרו אותו. אם ה-harness שלך לא מטפל בכל השלוש — יש לך באג שמחכה לקרות. הלולאה הזו, על 5 הצעדים שלה, היא בדיוק מה שנכתוב ב-harness.py בפרק 2.

✅ עשה/י עכשיו (3 דקות)

קח/י את משימת "מצא ועדכן קבצים" מהסעיף הקודם, ושרטט/י על דף את רצף הסבבים: כמה turns בערך היא תדרוש? בכל turn — איזה tool נקרא, ומה ה-tool_result שחוזר? אל תדאג/י לדיוק; המטרה היא לראות שהלולאה היא רצף, לא קריאה בודדת.

מאיפה הגיע ה-momentum: Hashimoto, LangChain, וההפנמה של 2026

רקע2026הפרדיגמה

הרעיון שה-harness חשוב מהמודל לא נולד יש מאין. הוא הצטבר במהלך 2025–2026 משני כיוונים מרכזיים, ולפי מחקר הקורס שני שמות בולטים בנרטיב הזה: Mitchell Hashimoto (מייסד HashiCorp, דמות מוכרת בקהילת ה-infrastructure) ו-LangChain. Hashimoto היה בין הקולות שהבליטו עד כמה התשתית סביב הסוכן קובעת את התנהגותו, ו-LangChain הביאה את ההוכחה המספרית עם דוח Terminal-Bench בפברואר 2026.

טעות נפוצה: לבלבל "agent SDK מוכן" עם "harness שאתה מחזיק"

הרבה מפתחים מריצים query() מתוך SDK, רואים שזה עובד, ומסיקים ש"יש להם harness". אבל אם הלולאה היא קופסה שחורה — אתה לא מחזיק את ה-harness, אתה צרכן שלו. ההבדל מתגלה ברגע שמשהו משתבש: בעל harness יודע באיזה סבב, על איזה tool, ולמה. צרכן רק רואה שזה "נתקע". הקורס הזה מעביר אותך מצד אחד של הקו לצד השני.

למה זה קרה דווקא ב-2026? כי הסוכנים יצאו מהדמו ונכנסו ל-production. ברגע שסוכן רץ על משימות אמיתיות, ארוכות, עם עלות אמיתית — כל החולשות של ה-harness הביתי הצף עלו לפני השטח: לולאות אינסופיות, איבוד context, עלויות שמתפוצצות. ה-harness הפסיק להיות פרט טכני והפך לתחום הנדסי בפני עצמו.

ההבחנה הזו — בין דמו ל-production — היא לב העניין עבורך. דמו סולח להכל: רץ פעם אחת, על משימה קצרה, ואם נכשל מריצים שוב. production לא סולח: רץ אלפי פעמים, על משימות ארוכות, עם כסף אמיתי על הקו, ובלי בן אדם שצופה בכל ריצה. כל פער ב-harness שדמו הסתיר — לולאה בלי בלם, context שנמחק, tool בלי שער — הופך ב-production לתקלה שעולה כסף או גורמת נזק. הקורס הזה הוא, במובן עמוק, הקורס שמעביר את הסוכנים שלך מ"דמו שעובד" ל"מערכת שאפשר לסמוך עליה".

אפשר לראות את ההפנמה הזו בצורה שבה Anthropic עצמה השקיעה בתשתית-סביב-המודל לאורך 2026, לפי מחקר הקורס:

פברואר 2026: השקת Claude Agent Teams לצד Claude Sonnet 4.6 — מופעי Claude מקבילים שמתקשרים בזמן אמת. כדי להוכיח את הכוח, Anthropic בנתה C compiler פעיל באמצעות 16 סוכנים מקבילים על פני 2,000 sessions. שים/י לב — זה הישג של orchestration, של ה-harness, לא של מודל בודד.
8 באפריל 2026: Claude Managed Agents ב-public beta — Anthropic לוקחת על עצמה את ה-runtime וה-sandboxing בענן.
6 במאי 2026: Claude Dreaming ב-research preview — תהליך רקע שמאחד זיכרון מ-transcripts. לפי המחקר, חברת Harvey דיווחה על שיפור פי 6 בקצב השלמת משימות אחרי הפעלתו. שוב — שיפור שמגיע מהתשתית, לא מהמודל.

הסיפור הגדול של 2026 הוא אחד: התעשייה הפסיקה לשאול "איזה מודל" והתחילה לשאול "איזה harness". זה הקורס שמלמד אותך לבנות את ה-harness הזה.

נוף הכלים: 4 גישות runtime

השוואהRuntimesהחלטה

עכשיו לחלק המעשי. כשאתה בא לבנות harness, אתה לא מתחיל מאפס מוחלט — יש כלים. אבל הם נבדלים בשאלה היסודית ביותר: מי מחזיק את הלולאה? נסקור 4 גישות, כולן מתוך מחקר הקורס.

למה השאלה "מי מחזיק את הלולאה" היא הציר המרכזי, ולא, נגיד, "מי יותר מהיר" או "מי יותר זול"? כי היא קובעת את כל השאר. מי שמחזיק את הלולאה שולט ב-context, ב-governance, וב-observability — ולכן גם בעלות וביכולת ה-debug. אם ויתרת על הלולאה, ויתרת על היכולת לענות על השאלה "למה הסוכן עשה X". לכן זו ההחלטה הראשונה, ולכן היא חוזרת בכל פרק בקורס.

1. Claude Agent SDK — in-process (אתה מחזיק את הלולאה)

הספרייה הרשמית של Anthropic ב-Python וב-TypeScript, שחושפת את לולאת הסוכן, ניהול ה-context, ותשתית ביצוע ה-tools. זה הבסיס שעליו הקורס בונה. נקודות מפתח מהמחקר:

הספרייה עצמה open-source וחינמית. אתה משלם על שימוש ב-tokens בתעריף ה-API הרגיל.
מגיעה עם 14+ tools מובנים ותומכת ב-tools מותאמים דרך MCP (Model Context Protocol).
נקראה בעבר Claude Code SDK — אם תיתקל/י בשם הישן בתיעוד או בקוד, זה אותו דבר.
חשוב לתזמון: החל מ-15 ביוני 2026, תוכניות subscription מושכות מ-credit חודשי ייעודי ל-Agent SDK (נרחיב בהמשך).

מה ה-SDK נותן לך: את שלד הלולאה, את ה-tools המובנים, ואת חיבור ה-MCP. מה הוא לא עושה בשבילך: לא מחליט במקומך את אסטרטגיית ה-context, לא בונה את ה-governance המותאם שלך, ולא נותן observability עמוק מהקופסה. בדיוק את החלל הזה — שבין מה שה-SDK נותן למה שאתה צריך ב-production — הקורס ממלא. אנחנו לא משכפלים את ה-SDK; אנחנו בונים את הרובד הדק שמעליו.

מקור רשמי: https://platform.claude.com/docs/en/agent-sdk/overview

2. Claude Managed Agents (CMA) — hosted (Anthropic מחזיקה את הלולאה)

REST API מנוהל ו-serverless שבו Anthropic מנהלת את לולאת הסוכן, את ה-execution harness, את ה-sandboxing המאובטח, ואת ה-session persistence. אתה לא כותב את הלולאה — אתה קורא ל-API והכל קורה בענן. נקודות מפתח:

השקה ב-public beta ב-8 באפריל 2026; דורש header managed-agents-2026-04-01.
מודל תמחור API-only.
ה-trade-off: נוחות ו-sandbox מנוהל — תמורת אובדן שליטה fine-grained בלולאה.

מתי CMA זוהר/ת: כשתחזוקת ה-sandbox וה-scaling של ריצות סוכן בקנה מידה הופכת ליקרה ומורכבת לבד, וכשאתה מוכן/ה לסחור שליטה תמורת תפעול פשוט. מתי לא: כשבנית governance מותאם, אסטרטגיית context ספציפית, או observability עמוק — כל אלה עוברים לניהול Anthropic, ואתה מאבד את היכולת לכוונן אותם.

מקור רשמי: https://platform.claude.com/docs/en/managed-agents/overview. נחזור ל-CMA לעומק בפרק 8, כשנקבל את החלטת ה-production.

3. Deep Agents — harness open-source מעל LangGraph

harness סוכנים בקוד פתוח שפותח על ידי LangChain מעל ה-runtime של LangGraph. מספק סוכן מוכן-לריצה, דעתני, עם planning tool, virtual filesystem, spawning של subagents, וניהול context. חינמי ו-open-source, בגרסת GA v0.6.x.

למה זה מעניין אותך גם אם לא תשתמש/י בו: Deep Agents הוא דוגמה מצוינת ל-harness דעתני שכבר עשה בשבילך החלטות ארכיטקטוניות (planning, virtual FS, subagents). הוא שימושי כשרוצים נקודת פתיחה מהירה ולא אכפת לקבל את הדעות של LangChain. אבל שים/י לב — הוא מעל LangGraph, כלומר יש שכבת abstraction נוספת. אם תרצה/י שליטה מלאה ושקיפות מלאה, תעדיף/י את ה-Claude Agent SDK הדק. הקורס מראה לך איך לבנות לבד את מה ש-Deep Agents נותן מוכן — כדי שתבין/י כל החלטה במקום לרשת אותה.

מקור: https://github.com/langchain-ai/deepagents

4. Aden Hive — multi-agent harness מונחה-תוצאה

harness רב-סוכני בקוד פתוח, מיועד לתהליכים עסקיים ב-production. הייחוד שלו: הוא מייצר את גרף הסוכנים, את קוד החיבורים, ואת מקרי הבדיקה מתוך מטרה בשפה טבעית. כולל failure capture, אבולוציה אדפטיבית, ו-nodes של human-in-the-loop. לפי המחקר, כ-10.5k כוכבים ב-GitHub.

Aden Hive מייצג גישה שונה לחלוטין: durable — סוכנים שמוגדרים בקוד עם state מתמשך, להבדיל מ-ephemeral כמו Agent Teams שחיים לאורך session אחד. ה-failure capture המובנה שלו הוא בדיוק ה-pattern שנלמד בפרק 5, וה-human-in-the-loop nodes הם הדפוס של ה-lead-enrichment pipeline שיהיה ה-capstone. גם כאן — לא נשתמש בו ישירות, אבל נבנה לבד את העקרונות שהוא מגלם, כדי שתחזיק/י אותם בידיים שלך.

מקור: https://github.com/aden-hive/hive

Runtime	מי מחזיק את הלולאה	רמת control	scaling/sandbox	מתי לבחור
Claude Agent SDK in-process	אתה	מלאה — אתה כותב את הלולאה	באחריותך (אתה מנהל sandbox ו-scaling)	כשצריך שליטה מלאה, governance מותאם, observability ספציפי — הבחירה של הקורס
Claude Managed Agents hosted	Anthropic	מוגבלת — מאבד fine-grained בלולאה	מנוהל ע"י Anthropic (serverless + sandbox מובנה)	כשתחזוקת sandbox/scaling יקרה לבד ונוח לוותר על שליטה (פרק 8)
Deep Agents open-source / LangGraph	אתה (מעל abstraction של LangGraph)	בינונית — דעתני אבל ניתן להרחבה	באחריותך, אך עם פיגומים מוכנים (planning, virtual FS)	כשרוצים סוכן דעתני מוכן-לריצה מבלי לבנות הכל מאפס
Aden Hive multi-agent / outcome-driven	אתה (graph נוצר מ-NL)	בינונית — graph מיוצר, אתה מכוונן	durable state, failure capture מובנה	תהליכים עסקיים רב-סוכניים עם human-in-the-loop ו-state מתמשך

מסגרת החלטה: in-process מול hosted

זו ההחלטה שתחזור לאורך כל הקורס. הכלל הבסיסי:

אם אתה צריך שליטה מלאה בלולאה, governance מותאם, או observability ספציפי — אז in-process (Claude Agent SDK). אתה מחזיק הכל, גם את הכאב.
אם ה-sandboxing וה-scaling יקרים מדי לתחזק לבד, ואתה מוכן לוותר על שליטה דקה — אז hosted (Claude Managed Agents).
אם אתה עדיין לומד ובונה — אז תמיד in-process קודם. אי אפשר להחליט מה לוותר לפני שבנית אותו בעצמך. לכן הקורס בונה in-process, ורק בפרק 8 שוקל מעבר.

✅ עשה/י עכשיו (7 דקות) — זה ה-deliverable השני

פתח/י את הטבלה למעלה כקובץ או גיליון משלך, והוסף/י עמודה חמישית: "מתאים לפרויקט שלי?" — מלא/י עבור כל runtime עם כן/לא/אולי ומשפט הסבר אחד. בסוף הקורס תחזור/י לטבלה הזו עם הרבה יותר ידע. שמור/שמרי כ-runtimes-comparison.

3 הטעויות שהורגות harness ביתי

Anti-patternsטעויות נפוצותהנגד הדק

עכשיו נכנסים לחלק הכי שימושי: למה harness ביתי נכשל. מחקר הקורס מזהה 3 טעויות חוזרות. לכל אחת יש "נגד" שהקורס מלמד — ואני אצביע על הפרק שבונה אותו. זה גם ה-deliverable השלישי.

טעות #1 — לשלוף framework כבד ללולאה מותאמת

הרפלקס הנפוץ: "יש בעיה מורכבת? בוא נשלוף CrewAI או abstractions כבדים של LangChain, הם עושים הכל." התוצאה לפי המחקר:

venv שמתנפח מעל 1GB — תלויות על תלויות שאתה לא צריך.
אפס observability — אתה לא רואה מה קורה בתוך ה-abstraction.
סוכן שלולף 6+ פעמים על אותו tool — נכשל, מנסה שוב, נכשל, וכך הלאה, בלי שתוכל לדבג.

הנגד הדק: לולאה מפורשת ודקה מעל ה-Claude Agent SDK שאתה מבין שורה-שורה. נבנה בפרק 2.

טעות #2 — לפרסר free-form text מהסוכן

הסוכן מחזיר טקסט חופשי, ואתה כותב קוד ש"מחפש את המספר אחרי הנקודתיים" או "מפרק את הפסקה השנייה". זה שביר מאוד: ברגע שהפורמט זז במילימטר — ה-harness נשבר.

דמיין/י שאתה מצפה לתשובה "המחיר: 49 דולר" ומפרסר את המספר אחרי הנקודתיים. עכשיו המודל מחליט פעם אחת להחזיר "המחיר הוא $49" או "49 USD" או "כ-49 דולר" — וה-parser שלך מחזיר None, או גרוע יותר, מספר שגוי. ה-harness לא קרס בקול רעש; הוא המשיך עם ערך שגוי, וזה הרבה יותר מסוכן.

הנגד הדק: לאכוף structured JSON output עם schema קשיח (למשל {"price_usd": 49}), ו-retry דטרמיניסטי — כשה-output לא תואם ל-schema, מחזירים למודל את שגיאת ה-validation ("expected integer for price_usd") ומבקשים תיקון, בלי LLM שיפוטי שני, רק לולאת תיקון מכנית. נבנה בפרק 4.

טעות #3 — להתעלם מ-tool-call latency

הסוכן מריץ קריאות tool בטור, אחת אחרי השנייה. כל קריאה מייצרת תעבורת רשת. כשהקריאות עצמאיות זו מזו — אין שום סיבה להריץ אותן בטור, אבל ה-harness הנאיבי עושה את זה ומשלם בזמן.

נניח שהסוכן צריך למשוך נתונים מ-3 endpoints שונים שאינם תלויים זה בזה — למשל GitHub, Apollo, ומסד נתונים פנימי. אם כל קריאה לוקחת 800ms, הרצה בטור = 2.4 שניות. הרצה במקביל = 800ms. בריצה עם עשרות קריאות כאלה, ההפרש הזה הופך לדקות, ולחוויית "הסוכן איטי בטירוף" שאתה לא מבין מאיפה היא באה.

הנגד הדק: להריץ קריאות tool עצמאיות במקביל (דפוס Promise.all / asyncio.gather) ולעשות caching לתוצאות לפי input hash — כי לקרוא לאותו endpoint פעמיים באותה ריצה זה בזבוז כפול של זמן ושל tokens. נבנה בפרק 4 ו-5.

הטעות	הסימפטום	הנגד הדק	נבנה בפרק
#1 framework כבד	bloat מעל 1GB, אפס observability, לולאות 6+	לולאה מפורשת ודקה מעל ה-SDK	פרק 2
#2 free-form text	parsing שביר שנשבר על כל שינוי פורמט	structured JSON + retry דטרמיניסטי	פרק 4
#3 התעלמות מ-latency	קריאות סדרתיות, תעבורת רשת עצומה, ריצה איטית	parallel tool calls + caching	פרק 4–5

טעות נפוצה: לקפוץ ישר ל-framework כבד "כי הוא עושה הכל"

זו הטעות שמשלבת את שלוש הקודמות. framework כבד באמת "עושה הכל" — כולל את הדברים הלא נכונים, מאחורי abstraction שאתה לא רואה. אתה משלם ב-bloat, באפס observability, ובלולאות אינסופיות שאי אפשר לדבג כי הקוד שמייצר אותן לא שלך. הקורס מלמד את ההפך: דק, מפורש, ובשליטתך — גם אם זה אומר לכתוב 150 שורות בעצמך.

✅ עשה/י עכשיו (3 דקות)

פתח/י קובץ why-not-heavy-framework.md והעתק/י אליו את הטבלה למעלה (3 הטעויות, סימפטום, נגד, פרק). זה ה-deliverable השלישי. תשתמש/י בו כתזכורת בכל פעם שתתפתה לשלוף abstraction כבד "כדי לחסוך זמן".

מה הקורס בונה — ומה הוא במכוון לא משכפל

גבולות גזרהמפת הקורסscope

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

מה הקורס בונה: את ה-runtime הדק מאפס — לולאה מפורשת, ניהול context, structured tools, governance, observability, recovery, ו-orchestration רב-סוכני. אתה תחזיק את הלולאה.
מה הקורס לא משכפל למטה: את בסיסי ה-Claude Agent SDK עצמו (איך מותקנת ספרייה, איך עובד API key) — נשתמש בו ככלי, לא נכתוב אותו מחדש.
מה הקורס לא נשאר ברמתו: patterns מוכנים של multi-agent עם SDKs מוכנים (כמו ב-ai-agents-guide ch13) — שם השתמשת בקופסה שחורה; כאן פותחים אותה.

תחשוב/תחשבי על זה כעל שלוש תחנות. בתחנה הראשונה השתמשת בסוכן מוכן (Claude Code, או patterns מ-ai-agents-guide) — וזה היה "קסם": הקלדת goal וזה עבד, אבל לא ידעת למה. בתחנה השלישית, היפותטית, היית בונה מודל מאפס — וזה לא רלוונטי, יש לזה ספקים. הקורס הזה הוא התחנה האמצעית: לוקחים את ה"קסם" של התחנה הראשונה ופותחים אותו, שורה-שורה, עד שהוא הופך למערכת שאתה מבין ושולט בה. בסוף הקורס, כשסוכן ייתקע — תדע/י בדיוק באיזה סבב, על איזה tool, וכמה זה עלה. זה ההבדל בין "קסם" ל"הנדסה".

במילים אחרות: הקורס יושב בדיוק במקום שבין "להשתמש ב-SDK מוכן" לבין "לכתוב מודל מאפס" — אנחנו בונים את ה-runtime שמחבר ביניהם. זה הרובד שבו חיים 70% מהביצועים.

מפת הדרך של הקורס — 8 פרקים, שכבה על שכבה

כדי שתראה/י לאן זה הולך, הנה כל הקורס במבט אחד. כל פרק מוסיף שכבה אחת ל-harness, ואף שכבה לא נזרקת — הכל מצטבר ל-capstone:

פרק	השכבה שמתווספת	הרכיב מהמפה
1 (כאן)	הפרדיגמה והמפה: למה harness, ומה 5 הרכיבים	סקירה של כולם
2	לולאת agent דקה ומפורשת מאפס, עם max-turns	loop + state
3	ניהול context מול ה-compaction buffer (33K / 83.5%)	context compaction
4	structured output, MCP, ו-governance דטרמיניסטי	tool execution + constraints
5	observability (Langfuse), failure recovery, circuit breakers	constraints + recovery
6	orchestration רב-סוכני: subagents, Agent Teams, cost control	orchestration
7	memory store ו-Dreaming לשיפור עצמי אסינכרוני	memory
8	חיווט הכל ל-production + החלטת in-process מול hosted	הכל יחד

שמור/שמרי את הטבלה הזו לצד מפת ה-Harness שציירת. ביחד הן ה-GPS של הקורס: בכל פרק תדע/י איזה רכיב אתה בונה ולמה.

מסגרת: האם אני "צרכן SDK" או "בעל harness"?

בדוק/בדקי את עצמך מול שלוש השאלות:

אם כשהסוכן נתקע אתה יודע באיזה סבב, על איזה tool, וכמה זה עלה — אז אתה בעל harness.
אם אתה יכול לשנות מתי המודל נקרא ומה נשלח אליו בכל סבב — אז אתה בעל harness.
אם אתה רק קורא ל-query() ומקבל תוצאה, בלי לדעת מה קרה באמצע — אז אתה עדיין צרכן. ובסדר גמור: זו נקודת ההתחלה. הקורס מעביר אותך לצד השני.

ההערה הרגישה-לזמן: מעבר ה-billing של 15 ביוני 2026

billingרגיש-לזמןAPI key

נקודה שחשוב להכיר כבר עכשיו, גם אם ניישם אותה בפרק 2 ו-8. החל מ-15 ביוני 2026, תוכניות subscription של Claude עוברות למודל שבו השימוש ב-Agent SDK נמשך מ-credit חודשי ייעודי ("Agent SDK credit"), בנפרד מהמכסה האינטראקטיבית.

המשמעות המעשית: ריצות אוטומטיות על subscription auth עלולות לחטוף rate limits פתאומיים אחרי התאריך הזה, אלא אם תעבור/תעברי ל-API key auth. עבור כל מי שבונה אוטומציה אמיתית — וזה כל מי שלוקח את הקורס הזה ברצינות — זו לא הערת שוליים. זו הסיבה שמפרק 2 נעבוד עם API key.

טעות נפוצה: להריץ אוטומציה על subscription ולהתפלא מ-rate limits

אם תשיק/י סוכן אוטומטי על חשבון subscription רגיל אחרי 15 ביוני 2026, הוא עלול להיעצר באמצע בגלל מגבלות שלא ציפית להן. production אוטומטי חייב API key auth (או Agent SDK credit מתוכנן מראש). זו החלטה ארכיטקטונית, לא טכנית-שולית.

למפתח/ת ישראלי/ת יש כאן שכבה נוספת: כל השירותים של Anthropic ושל LangChain מחויבים ב-USD. כשאתה מתכנן/ת תקציב לריצות סוכן עתירות-tokens, צריך לקחת בחשבון תנודות שער ILS/USD ו-VAT. ריצה אחת של צוות סוכנים יכולה לשרוף הרבה יותר tokens ממה שנדמה — וזו עוד סיבה לבחור API key auth מתוכנן מראש ולא להפתיע את עצמך בחשבון. בפרק 8 נחשב cost-per-run במפורש.

הערת freshness: מעבר ה-billing הזה הוא רגיש-לזמן ביותר. הפרטים המדויקים (גודל ה-credit, התנהגות מדויקת של rate limits) עשויים להתעדכן — אמת/י מול הדף הרשמי של Anthropic לפני שאתה מתכנן עלויות. דוגמה מייצגת: פרויקט שמריץ 50 ריצות סוכן ביום על subscription צריך להניח שיעבור ל-API key כדי לא להיחסם.

שגרת עבודה: איך לחשוב על כל harness שתפגוש

שגרת עבודהroutineהרגל

עד כאן צברנו הרבה מושגים: 5 רכיבים, 4 runtimes, 3 טעויות. כדי שכל זה לא יישאר רשימה לזכור, הנה דרך אחת קבועה לחשוב — שגרה שתפעיל/י על כל מערכת סוכנים שתפגוש/י, בלי קשר לכמה היא מורכבת. המטרה שלה היא להפוך אותך מצופה/ה פסיבי/ת ("זה עובד / לא עובד") למאבחן/ת אקטיבי/ת ("הרכיב X חסר, ושם זה ייפול"). זו הדרך שבה מהנדס/ת harness מסתכל/ת על העולם.

🔁 שגרת ה-"5 רכיבים + 2 שאלות"

בכל פעם שתיתקל/י במערכת סוכנים — שלך, של מישהו אחר, או framework חדש — הרץ/י עליה את השגרה הזו לפני שאתה כותב שורת קוד:

זהה/י את 5 הרכיבים. איפה הלולאה? מי מחזיק את ה-state? איך מורצים tools? איך מנוהל ה-context? אילו constraints קיימים? אם רכיב חסר — זו נקודת הכישלון הצפויה.
שאל/י "מי מחזיק את הלולאה?" אתה או הספרייה? אם הספרייה — אתה צרכן, וה-debug יהיה קשה.
שאל/י "מה קורה כשזה נכשל?" יש circuit breaker? יש recovery? יש observability לראות את הכישלון? אם לא — אתה עיוור.
תייג/י כל בעיה כ-prompt או harness. אם זה "נתקע/לולף/שכח/קרס" — זה harness. אל תבזבז/י זמן על שיפור prompt.
תעד/י את ההחלטה in-process מול hosted. גם אם התשובה היא "in-process בינתיים" — כתוב/כתבי למה.

✅ עשה/י עכשיו (2 דקות)

שמור/שמרי את שגרת "5 רכיבים + 2 שאלות" כ-checklist קצר בקובץ או בכלי ההערות שלך. נשתמש בה בכל פרק כשנוסיף רכיב חדש ל-harness.

תרגילים

תרגולhands-ondeliverables

תרגיל 1 — מפת ה-Harness שלך (5 הרכיבים)

מטרה: להפנים את 5 הרכיבים על ידי מיפוי שלהם לקורס.

שלבים:

צייר/י (ביד או דיגיטלי) LLM במרכז.
הוסף/י סביבו 5 תיבות: agent loop, state management, tool execution, context compaction, constraints/governance.
ליד כל תיבה כתוב/כתבי את מספר הפרק שבונה אותה (loop→2, state→2/3, tools→4, context→3, governance→4–5).
הוסף/י שתי תיבות חיצוניות: orchestration (פרק 6) ו-memory (פרק 7).

פלט צפוי: קובץ harness-map.png (או סקיצה) — דיאגרמה עם LLM במרכז, 7 תיבות מתויגות, וכל אחת נושאת מספר פרק. אתה צריך להיות מסוגל/ת להסביר בעל-פה מה כל רכיב עושה.

תרגיל 2 — טבלת השוואת Runtimes עם פסיקה אישית

מטרה: לתרגם את נוף הכלים להחלטה רלוונטית לפרויקט שלך.

שלבים:

בנה/י טבלה עם 4 שורות (Claude Agent SDK, CMA, Deep Agents, Aden Hive) ועמודות: מי מחזיק את הלולאה, control, scaling/sandbox, מתי לבחור.
מלא/י אותה מהמידע בפרק (אל תמציא/י — השתמש/י בעובדות מהטבלה למעלה).
הוסף/י עמודה חמישית: "מתאים לפרויקט שלי?" עם כן/לא/אולי + משפט הסבר.
סמן/י בעיגול את ה-runtime שאתה מהמר/ת עליו היום, וכתוב/כתבי משפט אחד למה.

פלט צפוי: קובץ runtimes-comparison (גיליון או markdown) עם 4 שורות מלאות, עמודת "מתאים לפרויקט שלי?" ממולאת, ו-runtime אחד מסומן עם נימוק. דוגמה מייצגת: "Claude Agent SDK — כן, כי אני צריך/ה שליטה מלאה בלולאה כדי לדבג למה הסוכן לולף."

תרגיל 3 — נתח harness אמיתי בשגרת "5 רכיבים + 2 שאלות"

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

שלבים:

בחר/י סוכן או workflow שאתה כבר מכיר/ה — Claude Code, סקריפט סוכן שכתבת, או דמו מ-Deep Agents/Aden Hive ב-GitHub.
הרץ/י עליו את 5 הרכיבים: לכל אחד כתוב/כתבי "קיים / חסר / קופסה שחורה".
ענה/עני על 2 השאלות: מי מחזיק את הלולאה? מה קורה כשזה נכשל?
סמן/י את הרכיב החלש ביותר — זו נקודת הכישלון הצפויה.

פלט צפוי: פסקה קצרה (5–8 שורות) או טבלה שמסווגת את 5 הרכיבים של מערכת אמיתית, מזהה מי מחזיק את הלולאה, ומצביעה על הרכיב החלש. אתה אמור/ה לסיים את התרגיל עם משפט כמו: "ב-X אין observability והלולאה היא קופסה שחורה — שם זה ייתקע ולא אדע למה."

מילון מונחים

מונחיםglossary

Agent Harness: שכבת התוכנה שעוטפת LLM ומנהלת state, ביצוע tools, דחיסת context ו-constraints. זו תוכנה שרצה, לא prompt.
Harness Engineering: הפרקטיקה של עיצוב ואופטימיזציה של מערכות התוכנה סביב ה-LLM כדי למקסם ביצועי סוכן. עלתה כפרדיגמה דומיננטית בפברואר 2026.
70% מחוץ למודל: ההערכה המרכזית של Harness Engineering — שרוב ביצועי הסוכן (כ-70%) נקבעים על ידי ה-harness, לא על ידי המודל עצמו.
Terminal-Bench 2.0: מבחן ביצועים לסוכנים. בפברואר 2026 הדגימה LangChain קפיצה מ-52.8% ל-66.5% על ידי בנייה מחדש של ה-harness בלבד, ללא החלפת מודל.
Agent Loop: לולאת הליבה: receive goal → call model → run tools → feed results → repeat-until-stop. בלעדיה אין סוכן, רק קריאה בודדת.
State Management: צבירת רצף ההודעות (system/user/assistant/tool_result) בין הסבבים. אחריות ה-harness, כי המודל stateless.
Context Compaction: תהליך סיכום או זיקוק היסטוריית השיחה כדי לפנות מקום בחלון ה-context. אם לא מנוהל נכון — מאבד היסטוריה קריטית.
Claude Agent SDK: הספרייה הרשמית של Anthropic (Python/TypeScript) שחושפת את לולאת הסוכן, ניהול ה-context, וביצוע ה-tools. open-source, חינמית כספרייה, חיוב לפי token usage. נקראה בעבר Claude Code SDK. הבסיס של הקורס.
In-Process Runtime: גישה שבה אתה מחזיק את הלולאה, ה-sandbox וה-scaling בעצמך (כמו עם Claude Agent SDK). שליטה מלאה תמורת אחריות מלאה.
Hosted Runtime: גישה שבה ספק חיצוני (כמו Claude Managed Agents) מנהל את הלולאה וה-sandbox. נוחות תמורת אובדן שליטה fine-grained.
Claude Managed Agents (CMA): REST API מנוהל ו-serverless שבו Anthropic מנהלת את לולאת הסוכן, ה-sandboxing וה-session persistence. public beta מ-8 באפריל 2026, דורש header managed-agents-2026-04-01.
Model Context Protocol (MCP): סטנדרט פתוח לחיבור מאובטח של LLMs למקורות נתונים ו-tools חיצוניים, בלי לכתוב integration ייעודי לכל אחד.
Deep Agents: harness סוכנים open-source של LangChain מעל LangGraph, עם planning tool, virtual filesystem, ו-subagent spawning.
Aden Hive: harness רב-סוכני open-source מונחה-תוצאה, שמייצר graph וקוד מתוך מטרה בשפה טבעית. כ-10.5k כוכבים ב-GitHub.
Thin Harness מול Heavy Framework: thin harness = לולאה מפורשת ודקה שאתה מבין ושולט בה. heavy framework = abstraction כבד (CrewAI/LangChain) שעושה "הכל" אבל מסתיר את הלולאה, מנפח את ה-venv, ומונע observability.

בדוק/בדקי את עצמך

בדיקה עצמית5 שאלות

5 שאלות — ענה/עני לפני שתמשיך/י לפרק 2

הקפיצה מ-52.8% ל-66.5% ב-Terminal-Bench 2.0 הושגה על ידי מה? (רמז: לא החלפת מודל) — ומה זה מלמד על איפה חי הכוח?
מנה/מני את 5 רכיבי ה-harness הדק ואת הפרק שבונה כל אחד. אם אתה תקוע על אחד — חזור/חזרי לטבלה.
מה ההבדל בין "צרכן SDK" ל"בעל harness"? תן/תני מבחן מעשי אחד שמבדיל ביניהם.
לאיזה תרחיש תבחר/י Claude Agent SDK ולאיזה Claude Managed Agents? נמק/י לפי control מול נוחות.
מהן 3 הטעויות שהורגות harness ביתי, ומה הנגד הדק לכל אחת? (רמז: framework כבד, free-form text, tool latency).

אם לא ענית/ענתה בביטחון על 4 מתוך 5 — שווה לחזור על הסעיף הרלוונטי לפני פרק 2. הפרק הבא בונה ישירות על המפה הזו.

⭐ Just One Thing

אם תיקח/י דבר אחד מהפרק הזה, שיהיה זה: כשסוכן נכשל, ההימור הנכון הוא לבדוק את ה-harness — לא לחכות למודל חזק יותר. 70% מהביצועים חיים בקוד שאתה כותב מסביב למודל. אותו מודל קפץ 14 נקודות רק משינוי ה-harness. הכוח ב-runtime, והוא בשליטתך.

סיכום הפרק וגשר לפרק הבא

סיכוםגשר

מה למדנו

70% מהביצועים מחוץ למודל. Terminal-Bench 2.0 קפץ מ-52.8% ל-66.5% רק משינוי ה-harness — אותו מודל. הכוח ב-runtime.
Agent Harness הוא תוכנה, לא prompt. הוא מנהל state, tool execution, context ו-constraints. המודל stateless; ה-harness stateful.
5 רכיבים. agent loop, state management, tool execution, context compaction, constraints/governance — וכל אחד נבנה בפרק מוגדר בקורס.
4 גישות runtime. Claude Agent SDK (in-process, הבחירה שלנו), CMA (hosted), Deep Agents, Aden Hive — והשאלה המכרעת: מי מחזיק את הלולאה.
3 טעויות הורגות-harness. framework כבד, free-form text, התעלמות מ-latency — ולכל אחת נגד דק שהקורס בונה.
ההכנה ל-production: API key auth (ולא subscription) חיוני לאוטומציה, במיוחד לאחר מעבר ה-billing של 15 ביוני 2026.

🌉 הגשר לפרק 2: עכשיו, כשיש לך את המפה — אנחנו עוברים מתאוריה למקלדת. בפרק 2, "אנטומיה של Harness דק: בונים את לולאת ה-Agent מאפס", נכתוב את harness.py הראשון: לולאת agent מפורשת בפחות מ-150 שורות מעל ה-Claude Agent SDK — goal → call model → run tools → feed back → stop, עם max-turns. נתקין את ה-SDK, נגדיר API key, נריץ hello-agent, ונחבר tool מותאם ראשון. רכיב 1 ורכיב 2 מהמפה — loop ו-state — יקרמו עור וגידים בקוד אמיתי שאתה מחזיק שורה-שורה.

צ'קליסט סיום הפרק

checklistסיום

אני יכול/ה להסביר במשפט מדויק מה זה Agent Harness — ולמה זו תוכנה, לא prompt.
אני יכול/ה לצטט את הקפיצה 52.8% → 66.5% ב-Terminal-Bench 2.0 ולהסביר שהיא הושגה ללא החלפת מודל.
אני יכול/ה למנות את 5 רכיבי ה-harness הדק מהזיכרון.
מיפיתי כל אחד מ-5 הרכיבים לפרק שבונה אותו בקורס (deliverable 1).
בניתי את מפת ה-Harness כדיאגרמה (harness-map.png).
מילאתי את טבלת השוואת ה-Runtimes עם עמודת "מתאים לפרויקט שלי?" (deliverable 2).
אני מבין/ה את ההבדל בין in-process (Claude Agent SDK) ל-hosted (CMA) ומתי לבחור כל אחד.
תיעדתי את 3 הטעויות שהורגות harness ביתי + הנגד הדק לכל אחת (deliverable 3).
אני יודע/ת להבחין בין "צרכן SDK" ל"בעל harness" ולמקם את עצמי על הציר.
הבנתי למה אוטומציה דורשת API key auth, במיוחד אחרי 15 ביוני 2026.
שמרתי את שגרת "5 רכיבים + 2 שאלות" כ-checklist לשימוש חוזר.
השלמתי את 3 התרגילים והפקתי את הפלט הצפוי לכל אחד.
עניתי בביטחון על 4 מתוך 5 שאלות הבדיקה העצמית.
חזרתי למשפט שכתבתי ב-Do-Now הראשון — האם אבחנת הכישלון שלי השתנתה מ"מודל" ל"harness"?
אני מוכן/ה לכתוב את harness.py הראשון בפרק 2.