בניית מהדר C עם צוות של מופעי Claude מקביליים
פורסם ב-5 בפברואר, 2026
הטלנו על Opus 4.6 באמצעות צוותי סוכנים (Agent Teams) לבנות מהדר C (C Compiler), ואז (בעיקר) הלכנו. הנה מה שזה לימד אותנו על העתיד של פיתוח תוכנה אוטונומי.
נכתב על ידי Nicholas Carlini, חוקר בצוות אמצעי ההגנה (Safeguards) שלנו.
ערכתי ניסויים עם גישה חדשה לפיקוח על מודלי שפה שאנחנו קוראים לה "צוותי סוכנים" (Agent Teams).
בצוותי סוכנים, מספר מופעים של Claude עובדים במקביל על בסיס קוד משותף ללא התערבות אנושית פעילה. גישה זו מרחיבה באופן דרמטי את היקף מה שניתן להשיג עם סוכני מודלי שפה גדולים (LLM).
כדי לבחון זאת בתנאי קיצון, הטלתי על 16 סוכנים לכתוב מהדר C מבוסס Rust, מאפס, המסוגל להדר את ליבת Linux (Linux Kernel). במהלך כמעט 2,000 סשנים של Claude Code ובעלות API של 20,000 דולר, צוות הסוכנים הפיק מהדר בן 100,000 שורות קוד שיכול לבנות את Linux 6.9 על x86, ARM ו-RISC-V.
המהדר הוא תוצר מעניין כשלעצמו, אך אני מתמקד כאן במה שלמדתי על תכנון מסגרות עבודה (Harnesses) לצוותי סוכנים אוטונומיים שרצים לאורך זמן: כיצד לכתוב בדיקות שמשאירות סוכנים על המסלול ללא פיקוח אנושי, כיצד לבנות את העבודה כך שמספר סוכנים יוכלו להתקדם במקביל, והיכן גישה זו מגיעה לתקרה שלה.
אפשור ריצה ממושכת של Claude
תשתיות סוכנים קיימות כמו Claude Code דורשות ממפעיל להיות מקוון וזמין לעבודה משותפת. אם מבקשים פתרון לבעיה ארוכה ומורכבת, המודל עשוי לפתור חלק ממנה, אך בסופו של דבר הוא ייעצר ויחכה לקלט נוסף — שאלה, עדכון סטטוס, או בקשה להבהרה.
כדי לעורר התקדמות מתמשכת ואוטונומית, בניתי מסגרת עבודה שמכניסה את Claude ללולאה פשוטה (אם ראיתם את Ralph-loop, זה אמור להיראות מוכר). כשהוא מסיים משימה אחת, הוא מיד עובר לבאה. (הריצו את זה בקונטיינר, לא על המחשב האמיתי שלכם).
#!/bin/bash
while true; do
COMMIT=$(git rev-parse --short=6 HEAD)
LOGFILE="agent_logs/agent_${COMMIT}.log"
claude --dangerously-skip-permissions \
-p "$(cat AGENT_PROMPT.md)" \
--model claude-opus-X-Y &> "$LOGFILE"
done
בפרומפט הסוכן, אני אומר ל-Claude איזו בעיה לפתור ומבקש ממנו לגשת לבעיה על ידי פירוקה לחלקים קטנים, מעקב אחר מה שהוא עובד עליו, הבנה מה לעבוד עליו בהמשך, ולמעשה להמשיך עד שזה מושלם. (בנקודה האחרונה, ל-Claude אין ברירה. הלולאה רצה לנצח — אם כי במקרה אחד, ראיתי את Claude מריץ pkill -9 bash בטעות, ובכך הורג את עצמו ומסיים את הלולאה. אופס!).
הרצת Claude במקביל
הרצת מספר מופעים במקביל יכולה לטפל בשתי חולשות של מסגרת עבודה חד-סוכנית:
סשן אחד של Claude Code יכול לעשות רק דבר אחד בכל רגע נתון. במיוחד ככל שהיקף הפרויקט מתרחב, ניפוי שגיאות במספר בעיות במקביל הוא הרבה יותר יעיל.
הרצת מספר סוכני Claude מאפשרת התמחות. בעוד מספר סוכנים מוקצים לפתרון הבעיה עצמה, סוכנים מתמחים אחרים יכולים להיות מופעלים (למשל) לתחזוקת תיעוד, שמירה על איכות קוד, או פתרון תת-משימות מתמחות.
המימוש שלי ל-Claude מקבילי הוא בסיסי ביותר. נוצר מאגר git חשוף חדש, ולכל סוכן מוקם קונטיינר Docker עם המאגר מותקן ב-/upstream. כל סוכן משבט עותק מקומי ל-/workspace, וכשהוא מסיים, דוחף מהקונטיינר המקומי שלו ל-upstream.
כדי למנוע משני סוכנים לנסות לפתור את אותה בעיה בו-זמנית, מסגרת העבודה משתמשת באלגוריתם סנכרון פשוט:
Claude "נועל" משימה על ידי כתיבת קובץ טקסט ל-current_tasks/ (למשל, סוכן אחד עשוי לנעול את current_tasks/parse_if_statement.txt, בעוד אחר נועל את current_tasks/codegen_function_definition.txt). אם שני סוכנים מנסים לתפוס את אותה משימה, מנגנון הסנכרון של git מכריח את הסוכן השני לבחור אחרת.
Claude עובד על המשימה, ואז מושך מ-upstream, ממזג שינויים מסוכנים אחרים, דוחף את השינויים שלו, ומסיר את הנעילה. קונפליקטים של מיזוג (Merge Conflicts) שכיחים, אך Claude חכם מספיק כדי להתמודד עם זה.
לולאת יצירת הסוכנים האינסופית משגרת סשן חדש של Claude Code בקונטיינר טרי, והמחזור חוזר על עצמו.
זהו אב-טיפוס מחקרי מוקדם מאוד. עדיין לא יישמתי שום שיטה אחרת לתקשורת בין סוכנים, וגם לא אני אוכף שום תהליך לניהול יעדים ברמה גבוהה. אני לא משתמש בסוכן תזמור (Orchestration Agent).
במקום זאת, אני משאיר לכל סוכן Claude להחליט כיצד לפעול. ברוב המקרים, Claude תופס את "הבעיה הבאה הברורה ביותר". כשהוא תקוע בבאג, Claude לעיתים קרובות ישמור מסמך מתעדכן של גישות שנכשלו ומשימות שנותרו. במאגר ה-git של הפרויקט, אפשר לעבור על ההיסטוריה ולצפות בו תופס נעילות על משימות שונות.
לקחים מתכנות עם צוותי סוכני Claude
מסגרת העבודה מריצה את Claude בלולאה, אך הלולאה שימושית רק אם Claude יכול לזהות כיצד להתקדם. רוב המאמץ שלי הושקע בתכנון הסביבה סביב Claude — הבדיקות, הסביבה, המשוב — כך שיוכל להתמצא בלעדיי. אלה הגישות שמצאתי כמועילות ביותר בעת תזמור מספר מופעי Claude.
כתבו בדיקות באיכות גבוהה ביותר
Claude יעבוד באופן אוטונומי לפתרון כל בעיה שאתן לו. לכן חשוב שמאמת המשימות יהיה כמעט מושלם, אחרת Claude יפתור את הבעיה הלא-נכונה. שיפור מסגרת הבדיקות דרש מציאת חבילות בדיקות מהדר באיכות גבוהה, כתיבת מאמתים וסקריפטי בנייה עבור חבילות תוכנה בקוד פתוח, וצפייה בטעויות ש-Claude עשה, ואז תכנון בדיקות חדשות בהתאם לדפוסי הכשל שזיהיתי.
לדוגמה, לקראת סוף הפרויקט, Claude החל לשבור לעיתים קרובות פונקציונליות קיימת בכל פעם שמימש תכונה חדשה. כדי לטפל בכך, בניתי צינור אינטגרציה רציפה (Continuous Integration) ויישמתי אכיפה מחמירה יותר שאפשרה ל-Claude לבדוק את עבודתו טוב יותר כך שקומיטים חדשים (Commits) לא יוכלו לשבור קוד קיים.
שימו את עצמכם בנעליים של Claude
נאלצתי להזכיר לעצמי כל הזמן שאני כותב את מסגרת הבדיקות הזו עבור Claude ולא עבור עצמי, מה שאומר לחשוב מחדש על הרבה הנחות שלי לגבי האופן שבו בדיקות צריכות לתקשר תוצאות.
לדוגמה, כל סוכן מושלך לתוך קונטיינר טרי ללא הקשר, ויבלה זמן משמעותי בהתמצאות, במיוחד בפרויקטים גדולים. עוד לפני שמגיעים לבדיקות, כדי לעזור ל-Claude לעזור לעצמו, כללתי הנחיות לתחזק קבצי README ומסמכי התקדמות מפורטים שצריכים להתעדכן לעיתים קרובות עם הסטטוס הנוכחי.
גם שמרתי בראש את העובדה שלמודלי שפה יש מגבלות מובנות, שבמקרה הזה היה צריך לתכנן סביבן. אלה כוללות:
זיהום חלון ההקשר (Context Window Pollution): מסגרת הבדיקות לא צריכה להדפיס אלפי בייטים חסרי תועלת. לכל היותר, היא צריכה להדפיס כמה שורות פלט ולרשום את כל המידע החשוב לקובץ לוג כך ש-Claude יוכל למצוא אותו בעת הצורך. קבצי הלוג צריכים להיות קלים לעיבוד אוטומטי: אם יש שגיאות, Claude צריך לכתוב ERROR ולשים את הסיבה באותה שורה כך ש-grep ימצא אותה. זה עוזר לחשב מראש סטטיסטיקות סיכום מצטברות כך ש-Claude לא יצטרך לחשב אותן מחדש.
עיוורון זמן (Time Blindness): Claude לא יכול לדעת מה השעה, ואם משאירים אותו לבד, הוא ישמח לבלות שעות בהרצת בדיקות במקום להתקדם. מסגרת העבודה מדפיסה התקדמות הדרגתית לעיתים רחוקות (כדי להימנע מזיהום ההקשר) וכוללת אפשרות ברירת מחדל --fast שמריצה מדגם אקראי של 1% או 10%. המדגם הזה הוא דטרמיניסטי לכל סוכן אך אקראי בין מכונות וירטואליות, כך ש-Claude עדיין מכסה את כל הקבצים אך כל סוכן יכול לזהות רגרסיות בצורה מושלמת.
הפכו מקביליות לקלה
כשיש הרבה בדיקות נכשלות שונות, המקביליות היא טריוויאלית: כל סוכן בוחר בדיקה נכשלת שונה לעבוד עליה. אחרי שחבילת הבדיקות הגיעה לשיעור הצלחה של 99%, כל סוכן עבד על הידור של פרויקט קוד פתוח קטן אחר (למשל, SQLite, Redis, libjpeg, MQuickJS, Lua).
אך כשהסוכנים התחילו להדר את ליבת Linux, הם נתקעו. שלא כמו חבילת בדיקות עם מאות בדיקות בלתי-תלויות, הידור ליבת Linux היא משימה אחת עצומה. כל סוכן נתקל באותו באג, תיקן את הבאג, ואז דרס את השינויים של האחרים. ל-16 סוכנים שרצים לא הייתה תועלת כי כולם היו תקועים בפתרון אותה משימה.
הפתרון היה להשתמש ב-GCC כאורקל מהדר תקין מקוון (Online Known-Good Compiler Oracle) להשוואה. כתבתי מסגרת בדיקות חדשה שהידרה באופן אקראי את רוב הליבה באמצעות GCC, ורק את הקבצים הנותרים עם מהדר ה-C של Claude. אם הליבה עבדה, הבעיה לא הייתה בתת-הקבוצה של הקבצים של Claude. אם היא נשברה, אפשר היה לצמצם עוד על ידי הידור מחדש של חלק מהקבצים עם GCC. זה אפשר לכל סוכן לעבוד במקביל, לתקן באגים שונים בקבצים שונים, עד שמהדר Claude יכול היה להדר את כל הקבצים. (אחרי שזה עבד, עדיין היה צורך להפעיל טכניקות ניפוי דלתא (Delta Debugging) כדי למצוא זוגות קבצים שנכשלו ביחד אך עבדו בנפרד.)
תפקידי סוכנים מרובים
מקביליות גם מאפשרת התמחות. קוד שנכתב על ידי מודלי שפה גדולים ממש-מחדש לעיתים קרובות פונקציונליות קיימת, ולכן הקצאתי סוכן אחד לאחד כל קוד כפול שימצא. סוכן אחר מיניתי אחראי על שיפור ביצועי המהדר עצמו, ושלישי הפכתי לאחראי על פלט קוד מהודר יעיל. ביקשתי מסוכן נוסף לבקר את התכנון של הפרויקט מנקודת המבט של מפתח Rust, ולבצע שינויים מבניים בפרויקט כדי לשפר את איכות הקוד הכוללת, וסוכן אחר לעבוד על תיעוד.
בחינת קיצון של גבולות צוותי סוכנים
פרויקט זה תוכנן כמדד יכולות (Capability Benchmark). אני מעוניין לבחון בתנאי קיצון את גבולות מה שמודלי שפה גדולים יכולים בקושי להשיג היום, כדי לעזור לנו להתכונן למה שמודלים ישיגו באופן אמין בעתיד.
השתמשתי בפרויקט מהדר ה-C כמדד לאורך כל סדרת המודלים Claude 4. כפי שעשיתי עם פרויקטים קודמים, התחלתי בניסוח מה שרציתי: מהדר מייעל מאפס ללא תלויות, תואם GCC, מסוגל להדר את ליבת Linux, ומתוכנן לתמוך במספר קצוות אחוריים (Backends). בעוד שציינתי כמה היבטים של התכנון (למשל, שצריך להיות לו ייצוג ביניים SSA (SSA IR) כדי לאפשר מספר מעברי אופטימיזציה), לא נכנסתי לפרטים כיצד לעשות זאת.
מודלי Opus 4 קודמים בקושי היו מסוגלים להפיק מהדר פעיל. Opus 4.5 היה הראשון לחצות סף שאפשר לו להפיק מהדר פעיל שיכול לעבור חבילות בדיקות גדולות, אך הוא עדיין לא היה מסוגל להדר פרויקטים גדולים אמיתיים. המטרה שלי עם Opus 4.6 הייתה שוב לבחון את הגבולות.
הערכה
במהלך כמעט 2,000 סשנים של Claude Code על פני שבועיים, Opus 4.6 צרך 2 מיליארד טוקני קלט ויצר 140 מיליון טוקני פלט, בעלות כוללת של מעט פחות מ-20,000 דולר. בהשוואה אפילו לתוכניות Claude Max היקרות ביותר, זה היה פרויקט יקר במיוחד. אך הסכום הכולל הוא חלק קטן ממה שהיה עולה לי לייצר זאת בעצמי — שלא לדבר על צוות שלם.
זה היה מימוש בחדר נקי (Clean-Room Implementation — מימוש ללא גישה למימושים קיימים; ל-Claude לא הייתה גישה לאינטרנט בשום שלב במהלך הפיתוח); הוא תלוי רק בספרייה הסטנדרטית של Rust. המהדר בן 100,000 השורות יכול לבנות ליבת Linux 6.9 הניתנת לאתחול על x86, ARM ו-RISC-V. הוא גם יכול להדר את QEMU, FFmpeg, SQLite, postgres, redis, ויש לו שיעור הצלחה של 99% ברוב חבילות בדיקות המהדר, כולל חבילת הבדיקות הקיצונית של GCC (GCC Torture Test Suite). הוא גם עובר את מבחן הלקמוס האולטימטיבי של המפתחים: הוא יכול להדר ולהריץ את Doom.
עם זאת, למהדר יש מגבלות. אלה כוללות:
חסר בו מהדר x86 של 16 סיביות שנחוץ לאתחול Linux ממצב אמיתי (Real Mode). לשם כך, הוא פונה ל-GCC (מהדרי x86_32 ו-x86_64 הם שלו עצמו).
אין לו אסמבלר ומקשר (Assembler and Linker) משלו; אלה הרכיבים האחרונים ש-Claude התחיל לאוטמט והם עדיין מעט בעייתיים. סרטון ההדגמה הופק עם אסמבלר ומקשר של GCC.
המהדר בונה בהצלחה פרויקטים רבים, אך לא את כולם. הוא עדיין לא תחליף ישיר (Drop-in Replacement) למהדר אמיתי.
הקוד המיוצר אינו יעיל במיוחד. אפילו עם כל האופטימיזציות מופעלות, הוא מפיק קוד פחות יעיל מ-GCC עם כל האופטימיזציות מכובות.
איכות קוד ה-Rust סבירה, אך רחוקה מהאיכות שמתכנת Rust מומחה עשוי להפיק.
המהדר המתקבל הגיע כמעט לגבולות היכולות של Opus. ניסיתי (חזק!) לתקן כמה מהמגבלות שלעיל אך לא הצלחתי לחלוטין. תכונות חדשות ותיקוני באגים שברו לעיתים קרובות פונקציונליות קיימת.
כדוגמה מאתגרת במיוחד, Opus לא היה מסוגל ליישם מחולל קוד x86 של 16 סיביות הנדרש לאתחול למצב אמיתי של 16 סיביות. בעוד המהדר יכול להפיק x86 תקין של 16 סיביות דרך קידומות ה-opcode 66/67, הפלט המהודר המתקבל הוא מעל 60KB, הרבה מעבר למגבלת הקוד של 32K שנאכפת על ידי Linux. במקום זאת, Claude פשוט "מרמה" כאן ופונה ל-GCC בשלב זה (זה נכון רק עבור x86. עבור ARM או RISC-V, מהדר Claude יכול להדר לבד לחלוטין.)
קוד המקור של המהדר זמין. הורידו אותו, עברו על הקוד, ונסו אותו על פרויקטי ה-C האהובים עליכם. מצאתי באופן עקבי שהדרך הטובה ביותר להבין מה מודלי שפה יכולים לעשות היא לדחוף אותם עד הגבול, ואז לחקור היכן הם מתחילים להישבר. בימים הקרובים, אמשיך לגרום ל-Claude לדחוף שינויים חדשים אם תרצו לעקוב אחר הניסיונות המתמשכים של Claude להתמודד עם מגבלות אלה.
מבט קדימה
כל דור של מודלי שפה פותח דרכי עבודה חדשות איתם. מודלים מוקדמים היו שימושיים להשלמת טאבים בסביבות פיתוח (IDE). תוך זמן קצר, מודלים יכלו להשלים גוף פונקציה מתוך מחרוזת התיעוד שלה (Docstring). ההשקה של Claude Code הביאה סוכנים לזרם המרכזי ואפשרה למפתחים לתכנת בזוגות עם Claude. אך כל אחד מהמוצרים הללו פועל תחת ההנחה שמשתמש מגדיר משימה, מודל שפה רץ למשך מספר שניות או דקות ומחזיר תשובה, ואז המשתמש מספק המשך.
צוותי סוכנים מראים את האפשרות ליישם פרויקטים שלמים ומורכבים באופן אוטונומי. זה מאפשר לנו, כמשתמשים בכלים אלה, להיות שאפתניים יותר עם המטרות שלנו.
אנחנו עדיין בתחילת הדרך, ופיתוח אוטונומי לחלוטין כרוך בסיכונים אמיתיים. כשאדם יושב עם Claude במהלך הפיתוח, הוא יכול להבטיח איכות עקבית ולתפוס שגיאות בזמן אמת. עבור מערכות אוטונומיות, קל לראות בדיקות עוברות ולהניח שהעבודה הושלמה, כשזה כמעט אף פעם לא המצב. עבדתי בעבר בבדיקות חדירה (Penetration Testing), ניצול פגיעויות במוצרים שיוצרו על ידי חברות גדולות, והמחשבה על מתכנתים שפורסים תוכנה שמעולם לא אימתו אישית היא דאגה אמיתית.
אז, בעוד הניסוי הזה מרגש אותי, הוא גם משאיר אותי עם תחושת אי-נוחות. בניית המהדר הזה הייתה מהדברים הכי כיפיים שעשיתי לאחרונה, אך לא ציפיתי שזה יהיה בכלל אפשרי כל כך מוקדם ב-2026. ההתקדמות המהירה הן במודלי שפה והן במסגרות שאנחנו משתמשים בהן לאינטראקציה איתם פותחת את הדלת לכתיבת כמות עצומה של קוד חדש. אני מצפה שהיישומים החיוביים יעלו במשקלם על השליליים, אך אנחנו נכנסים לעולם חדש שידרוש אסטרטגיות חדשות כדי לנווט בו בבטחה.

Reactions: פילפלית, אמא של :-), 07:00 ומשתמש 1 נוסף4 //