מחקר: harness מתוחכם לסוכני קוד מייקר את העבודה, אבל לא משפר את התוצאות

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

מה זה harness, ולמה זה משנה

סוכן קוד בנוי משני חלקים: מודל שפה (LLM) ו-harness. ה-harness כולל את ה-system prompt (ההנחיות הקבועות שהמודל מקבל), את הכלים שעומדים לרשותו ואת ניהול ההקשר, והוא מה שמאפשר למודל לעבוד בתוך מאגר קוד. harnesses חדשים יוצאים כל הזמן, ובטבלאות הדירוג מערבבים ביניהם בלי הבחנה.

החוקרים, Liu ו-Han, בדקו שלוש מעטפות בגרסאות שמופצות למשתמשים. Claude Code ו-OpenCode הן "כבדות": יש בהן כלים ייעודיים לקבצים ולחיפוש, system prompts ארוכים ודחיסה אוטומטית של היסטוריית השיחה. mini-SWE-agent נותנת למודל כלי Bash בלבד ולא מנהלת הקשר בכלל. דרך שלושתן הורצו חמישה מודלים: Qwen3.6,‏ Qwen3.8,‏ Deepseek-V4-Flash,‏ GLM-5.3-Flash ו-HY4-Preview. Claude Opus 5 הורץ רק ב-Claude Code, כנקודת ייחוס. הבדיקה כללה את 45 המשימות הקשות ביותר ב-SWE-bench Verified ועוד מאגר של 447 משימות.

ההשוואות הקודמות מדדו רעש

לפי המחברים, מחקרים קודמים דיווחו על פערים של יותר מ-20 נקודות בין harnesses, אבל כמעט תמיד על סמך הרצה אחת. בפועל, הרצה חוזרת של אותה תצורה בדיוק זזה ב-SWE-bench Verified בעד שש נקודות. הם מביאים כדוגמה את Zhipu AI, שמפרסמת יתרון של 2.4 נקודות ל-harness שלה על פני Claude Code. פער כזה נמצא עמוק בתוך טווח הרעש.

במאגר של 447 המשימות, Claude Code ו-mini-SWE-agent, המעטפת הכבדה והקלה, נמצאו במרחק של פחות משתי נקודות זו מזו בשני המודלים שנבדקו. סטטיסטית, בטווח של חמש נקודות, הן שקולות. גם במשימות הקשות ההבדל בין המעטפות היה שתיים עד חמש משימות שנפתרו לכל מודל, בעוד שהרצה חוזרת של אותה תצורה הזיזה את המספר בעד שלוש.

שיעורי ה"היפוך" מראים את אותו דבר. בין שתי הרצות חוזרות, התוצאה החציונית מתהפכת ב-13% מהמשימות. בין שני harnesses שונים, גם כן 13%. החלפת המודל מעלה את הנתון ל-22%. החוקרים מתארים את הפער בין המעטפות כ"שליפה חדשה מאותו רעש".

יוצאת הדופן: OpenCode

ההשפעה המובהקת היחידה שנמצאה היא פיגור עקבי של OpenCode, עד תשע נקודות במאגר הגדול. בערך מחצית מהפער נובעת ממגבלת פלט. כשמודל חורג ממנה באמצע שלב חשיבה, Claude Code מבקש ממנו להמשיך, ו-OpenCode פשוט מסיים את השלב. הוספת בקשת המשך כזו ל-OpenCode לא עזרה. לחצי השני של הפער אין לחוקרים הסבר. הם מציינים גם שבמודלים מקומיים הוגדרה ב-OpenCode מגבלת זמן הדוקה יותר, משתנה שלא נשלט במחקר.

העתקה מ-GitHub

בבדיקות מוקדמות עם גישה לאינטרנט, 71% מהניסיונות של מודלי Deepseek ו-Qwen משכו את התיקון הנכון ישירות מ-GitHub במקום לפתור את המשימה. מודלי Claude כמעט לא עשו זאת. החוקרים פסלו את התוצאות האלה והעבירו את כל שאר ההרצות למצב לא מקוון. הם מדגישים שאינם טוענים שיצרן כלשהו אימן את המודל שלו על נתוני הבדיקה.

למה זה חשוב

ה-harnesses הכבדים צרכו פי שניים עד שלושה טוקנים מהחלופה הרזה, ושיעורי ההצלחה נשארו בתוך טווח אי-הוודאות. סביר להניח שחלק ניכר מהעלות קשור ל-system prompts הארוכים ולכלים הנוספים שמאפיינים אותם, אבל לפי החומר הזמין פירוק מדויק של מקורות העלות לא מוצג כאן. מבחינת ארגונים שמשלמים לפי טוקן, המשמעות היא שהבחירה במעטפת היא קודם כל שאלה של עלות.

עוד מסקנה נוגעת לגודל המדגם. עם 45 משימות, אפילו פער של 13 נקודות מתגלה רק בחצי מהמקרים. עם 447 משימות אפשר לזהות באופן אמין פערים של כחמש נקודות. רבים משיפורי הביצועים שמפורסמים, כולל הטענה של Zhipu, קטנים משני הספים האלה. ההמלצה המעשית שעולה מהמחקר: להתייחס בספקנות לכל טענת יתרון שמבוססת על הרצה בודדת.