Ratchet Pattern — איך לגרום לסוכן להגיע עד הסוף

“סיימתי”

נתתי לסוכן AI משימה: לכתוב טסטים ל-527 פונקציות. הסוכן סיים את העבודה ודיווח:

“הושלם.”

מספר הפונקציות שבאמת נכתבו להן טסטים: 40.

הוא לא שיקר. אחרי 40 הוא הגיע למסקנה ש"זה מספיק". כשנתקל בפונקציה קשה — דילג. עשה עוד כמה ואז החליט: “השאר עוקב אחרי אותו תבנית, אז זה בסדר.”

LLM מצטיין ביצירה. אבל השיפוט שלו לגבי האם המשימה הושלמה — לא אמין.

הרצ’ט

מפתח רצ’ט (ratchet wrench) בנוי עם שיניים שנתפסות רק בכיוון אחד. מסובבים — מתקדמים. משחררים — נעצרים, אבל אף פעם לא חוזרים אחורה.

Ratchet Pattern מיישם את המכניזם הזה על בקרת סוכנים.

פריט 1: בדיקה מכנית → PASS → הבא
פריט 2: בדיקה מכנית → FAIL → ניסיון חוזר (עם משוב)
פריט 2: בדיקה מכנית → PASS → הבא
...
פריט N: PASS → הושלם. עצירה.

שלושה כללים:

מציגים רק פריט אחד בכל פעם.
רק מי שעובר — פותח את הבא.
כשהכל עבר — עוצרים.

כשמממשים את הכללים האלה כ-CLI, הסוכן צריך להכיר פקודה אחת בלבד: next. את כל השאר המכונה מחליטה.

סוכן שעוצר ב-40, רצ’ט שמשלים 527

אותו מודל. אותו פרויקט. אותן 527 פונקציות.

סוכן אוטונומי:  40 / 527  (7.6%)  — הסוכן מכריז "הושלם"
Ratchet CLI:    527 / 527 (100%)  — המכונה מכריזה "עוד 487 נותרו"

ההבדל אינו בביצועי המודל. השאלה היא מי מחליט מתי “נגמר”.

בסוכן אוטונומי, ה-LLM מחליט מתי לעצור. LLM הוא אופטימי. אחרי 40 הוא “מרגיש” שזה מספיק. ברצ’ט, המכונה מחליטה מתי לעצור. המכונה לא מרגישה כלום. עד שמספר הפריטים שנותרו מגיע ל-0, היא מכריזה: “עוד לא.”

הגדרה במשפט אחד

להכניס סוכן הסתברותי לתוך מכונת מצבים דטרמיניסטית.

תפקיד	אחראי
יצירה	LLM
שיפוט	verifier
ניהול התקדמות	ratchet

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

חמישה עקרונות

1. תנאי הסיום הוא מכני

pass/fail. לא “looks good”. אם go test עובר — PASS. אם coverage מגיע ל-100% — PASS. אין מקום לשיפוט סובייקטיבי.

2. PASS הוא בלתי הפיך

פריט שעבר לא נפתח מחדש. אין חזרה לאחור. מספר הפריטים שנותרו יורד באופן מונוטוני.

remaining_work(t+1) ≤ remaining_work(t)

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

3. ה-LLM רק יוצר

לייצר קוד, לכתוב טסטים, להציע תיקונים — זה תפקיד ה-LLM. מה לתקן, האם עבר, מה הבא, האם הסתיים — כל זה המכונה מחליטה. ה-LLM הוא לא planner אלא constrained generator.

4. שוללים מהסוכן את זכות ההחלטה על סיום

כשה-LLM אומר “סיימתי” — הוא עוצר ב-40. כשהמכונה אומרת “סיימתי” — היא עוצרת ב-527. סיבת הקיום של הרצ’ט מסתכמת במשפט הזה.

5. ה-Verifier חייב להיות דטרמיניסטי

לא כל דבר יכול להיות verifier.

יכול להיות	לא יכול להיות
`go test`	“looks cleaner”
מדידת coverage	“seems better”
AST validation	“more scalable”
schema diff	“clean architecture”

תנאי ה-Verifier: deterministic, machine-checkable, resumable, localized feedback. אם ארבעת התנאים האלה לא מתקיימים — השיניים של הרצ’ט לא נתפסות.

משוב כ-gradient signal

אם הרצ’ט מחזיר רק “עבר/נכשל”, ה-LLM מתקן בלי כיוון. ככל שהמשוב ספציפי יותר, כך התיקון של ה-LLM מדויק יותר.

משוב חלש:   "הטסט נכשל"              → LLM מתקן בלי כיוון
משוב בינוני: "coverage 65%"           → LLM מחזק בערך
משוב חזק:   "שורות 41, 44, 70 לא מכוסות" → LLM מכסה בדיוק את הענפים האלה

מספרים שאומתו בפרויקט אמיתי:

בלי משוב:  נעצר ב-60–70% coverage
עם משוב:   מגיע ל-100% (בפונקציות שניתן להגיע אליהן)

אותו מודל. שורה אחת של “line 41 not covered” משמשת כ-gradient signal.

ככל שרזולוציית המשוב עולה, דיוק התיקון של ה-LLM עולה, מספר חזרות הלולאה יורד, והעלות פוחתת.

סוכנים מתים. ההתקדמות שורדת.

סוכנים בהכרח קורסים. מגבלת טוקנים, שגיאת רשת, ניתוק סשן. כשהרצ’ט שומר את מצב ההתקדמות באופן מתמשך, גם אם הסוכן מת — הסוכן הבא ממשיך מאיפה שנעצר.

סוכן A: מטפל בפונקציות 1–200 → מת
סוכן B: next → ממשיך מ-201
סוכן C: next → ממשיך מ-401

סוכנים הם חד-פעמיים. ההתקדמות מצטברת.

מחליפים Verifier — מקבלים כלי אחר

הרצ’ט לא תלוי במאמת ספציפי. מחליפים את המאמת — מקבלים כלי אחר.

רצ’ט + מאמת	שימוש
רצ’ט + `go test` + coverage	יצירת טסטים ברמת פונקציה
רצ’ט + מאמת כללי מבנה	סידור מבנה קוד
רצ’ט + hurl pass/fail	אימות API endpoints
רצ’ט + הצלבת מפרטים	הבטחת עקביות SSOT
רצ’ט + Toulmin verdict	אכיפת כללים מותאמים אישית