מהו ‘תור’ (Turn) ב-reins? תמונה: נוצרה בידי בינה מלאכותית

מי שהפקיד אי פעם עבודה גדולה בידי סוכן בינה מלאכותית מכיר את זה. הלולאה קורסת תמיד באותה נקודה: הרגע שבו המודל מכריז מעצמו “סיימתי” — כשבפועל זה לא נגמר.

reins הוא framework של Quest CLI שלוקח את סמכות הכרזת ההשלמה מהבינה המלאכותית ומוסר אותה למכונה. הוא מפצל רשימת עבודה לפריטים בודדים כמו קווסטים במשחק, נותן אותם לבינה המלאכותית אחד-אחד, ומכריע “האם זה גמור?” לא לפי מילתה של הבינה המלאכותית אלא בבדיקת מכונה. ובלבו יושבת יחידה קטנה ששמה תור (turn).

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

  • שער (gate) — בודק שסורק הגשה באופן מכני ופוסק PASS או FAIL. לא התרשמות של אדם, ולא הערכה עצמית של הבינה המלאכותית.
  • Ratchet — גלגל שיניים המסתובב בכיוון אחד בלבד. אנו משתמשים בו במשמעות שפריט שננעל במעבר לעולם אינו נפתח מחדש.

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

ששת יסודות הליבה של Reins Engineering

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

בשושלת של הנדסת פרומפטים (בחירת המילים) → הנדסת קונטקסט (אספקת ההקשר) → הנדסת harness (הקמת הגדרות), Reins הוא המושכות הקובעות את הכיוון. ההנדסה הזו מורכבת משישה יסודות.

#יסודבשורה אחתמשפט קנוני
1השלמה בשיפוט מכונהתנאי ההשלמה חייב להיות כזה שמכונה יכולה לענות עליו כן/לא, והמכונה היא ששופטת — הבינה המלאכותית נושלת מהסמכות להחליט שסיימה“השלמה נשפטת על ידי השער, לא נטענת”
2משוב דטרמיניסטיעובדות, לא דעות — “היכן, מה היה צריך להיות, מה היה בפועל” הופך לאות שמצביע על התיקון“תן לו דעות והוא יחניף; תן לו עובדות והוא יתקן”
3קונטקסט מכוון (מדריך + דוגמאות)אם המשוב הוא אות תיקון, המדריך והדוגמאות הם אותות כיוון — אף אחד מהם אינו יכול להחליף את השני“צוואר הבקבוק אינו האינטליגנציה אלא הקונטקסט”
4Ratchet Pattern (נעילת חוזה)פריט שעבר הוא בלתי-משתנה; העבודה הנותרת רק מתכווצת — הסיום מובטח על ידי המבנהremaining(t+1) ≤ remaining(t)
5התמדת התקדמותההתקדמות חיה מחוץ לתהליך (על הדיסק) — גם אם הבינה המלאכותית מתה, ההתקדמות נשארת“Agents are disposable; progress is cumulative.”
6הגנת גבינה (שערי דומיין)גם בדיקת מכונה נופלת לתחבולות אם היא בוחנת רק את הקליפה — השער חייב לאמת מחדש את העובדות האמיתיות של הדומיין שלו“לשער יש דומיין”

זה בסדר אם מונחי הטבלה עדיין מרגישים זרים. התור הוא היחידה הקטנה ביותר שבה ששת אלה נפגשים בתוך מחזור יחיד, ולכן מעקב אחרי תור אחד עד סופו מפגיש את כל ששת היסודות, כל אחד במקומו. אם משרטטים את המפה מראש: compose, הצעד הראשון של התור, מרכיב את הקונטקסט המכוון ואת המשוב הדטרמיניסטי; judge מוסר את פסק דין המכונה (הגנת הגבינה היא איכות התכנון של אותו שער); record נועל את ה-ratchet ומתמיד את ההתקדמות.

מהו Reins Turn?

Reins Turn הוא יחידת הביצוע הקטנה ביותר של reins, שבה ניסיון אחד על פריט קווסט אחד מסתיים כיצירה → שיפוט → רישום. לולאה אינה אלא חזרה של תורים, והתקדמות של קווסט אינה אלא הצטברות של תורים. ולכן ההגדרה נכנסת בשורה אחת.

Turn N = ה-Attempt הרשום ה-N. מה שלא נרשם אינו תור.

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

ההגדרה האחת הזו היא השורש של כל תכונה שתבוא — אי-תלות בדרייבר, עמידות להפעלה מחדש, יכולת ביקורת. לעת עתה, הניחו לשמות רק לחלוף. נפגוש כל אחד מהם שוב במקומו הראוי.

תור אחד הוא בדיוק ארבעה צעדים

תור עובר ארבעה צעדים לפי הסדר. לצעדים שמות באנגלית, אבל מה שהם עושים פשוט — מרכיבים (compose), יוצרים (generate), שופטים (judge), רושמים (record).

צעדמה הוא עושהתכונה
① composeקורא את רישום כל התורים הקודמים (ה-Log) ומרכיב את הפרומפט עבור ה-LLMפונקציה טהורה
② generateקורא ל-LLM פעם אחת כדי לייצר את התוצרהצעד ההסתברותי היחיד
③ judgeהשער פוסק על התוצר (PASS / REVIEW / FAIL)דטרמיניסטי
④ recordמחיל את פסק הדין על ה-ratchet ושומר לדיסקהצעד הבלתי הפיך היחיד

“פונקציה טהורה” פירושה שאותו קלט מניב תמיד את אותו פלט בלי תופעות לוואי אחרות, ו"בלתי הפיך" פירושו שמשבוצע — אין דרך חזרה. ואז ליבת הטבלה נגלית — מבין ארבעת הצעדים, רק ② הסתברותי, ורק ④ בלתי הפיך. היצירה אינה יכולה לשפוט, והשיפוט אינו יכול ליצור. אי-הוודאות של הבינה המלאכותית כלואה בתא אחד, וההחלטה שאין ממנה חזרה — בתא אחר.

כדאי לציין בחירת תכנון מוזרה אחת. מפל ארבעת הצעדים הזה אינו ממומש כשתי ערכות של קוד Go. הוא מוגדר במסמך יחיד קריא לאדם בשם pkg/cli/turn.md (מסמך TANGEUL), מוטמע בבינארי (go:embed) ומפוענח בזמן ריצה. המקור הקנוני של “איך תור רץ” אינו קוד אלא מסמך קריא — הסיבה לבחירה הזו חוזרת בסוף המאמר.

① compose — הקונטקסט מגיע רק מה-Log

ה-Log הוא הפנקס, השמור על הדיסק, שבו נרשם כל תור עד כה. והקלט להרכבת הפרומפט של תור N הוא בדיוק דבר אחד: ה-Log הזה. מצב שמסתתר אי-שם בזיכרון התוכנית ונעלם כשהתהליך מת — דבר כזה אינו קיים.

לפרומפט המורכב מה-Log יש שלוש שכבות.

  • מה לעשות — מה חייב להיווצר עבור הפריט הזה (הוראות הכתיבה וקונטקסט האימות)
  • מדריך — פרומפט המערכת הגלובלי, ובנוסף, אם התור הקודם היה FAIL, ההנחיה עבור החוק שגרם לו (המדריך פר-חוק)
  • זנב משוב — העובדות של ה-FAIL הקודם. “היכן, מה היה צריך להיות, מה היה בפועל”

בשפת ששת היסודות שלמעלה, המדריך הוא הקונטקסט המכוון וזנב המשוב הוא המשוב הדטרמיניסטי. שניהם מורכבים באופן מכני מה-Log, בכל תור.

יש חוק אחד עדין אך חשוב. מה ש-compose לוקח כנקודת ייחוס אינו ה-Attempt האחרון אלא ה-Attempt האחרון שנשפט (judged) — שהגיע עד פסק דין. גם אם שגיאת יצירה כמו נפילת שרת LLM נדחקת באמצע, מה שהניסיון החוזר רואה אינו את הודעת שגיאת התשתית אלא את המשוב מבוסס-העובדות של ה-FAIL הקודם. תקלות תפעוליות אינן מזהמות את הקונטקסט של העבודה.

② generate — ה-LLM רק יוצר

הפרומפט המורכב נשלח ל-backend של ה-LLM בקריאה יחידה. לא משנה אם ה-backend הוא HTTP API‏ (ollama/xai/gemini) או כלי שורת פקודה (claude/grok/codex/geminicli). כך או כך, תפקידו קבוע: יוצר. ה-framework אינו חושף שום API שדרכו ניתן להעניק ל-LLM סמכות PASS. זה לא שה-framework “בחר לא להעניק” את סמכות השיפוט — אין דרך להעניק אותה. כך יסוד 1 מבין השישה (השלמה בשיפוט מכונה) הופך למבנה.

אפילו הבחירה באיזה backend להשתמש מחושבת מחדש מה-Log בכל תור. פריט שממשיך להיכשל במודל ברירת המחדל נשלח מעלה למודל חזק יותר (אסקלציה), וגם ההחלטה הזו נקראת מתוך ה-Log בכל תור — “מבין החוקים שגרמו ל-FAILים בעבר, האם יש יעד אסקלציה?” אין מתג שנשאר דלוק אי-שם, אין משתנה מקומי בתוך הלולאה. אותה תוכנית, אותו Log — אותו backend נבחר. התכונה של התנהגות זהה גם אחרי שהורגים את התהליך ומפעילים אותו מחדש — עמידות להפעלה מחדש — מגיעה בחינם.

③ judge — רק השער שופט

מי שפוסק על התוצר הוא השער. שער הוא אוסף של חוקי גילוי הפרות. כל חוק מופעל (fire) כשהוא מוצא את הבעיה שעליה הוא אחראי, ומשאיר אחריו עובדה אחת — היכן (Where), מה היה צריך להיות (Expected), מה היה בפועל (Actual).

הצבירה דטרמיניסטית. אם ולו חוק Fail אחד הופעל — FAIL. אחרת, אם חוק Review הופעל — REVIEW (אזור אפור שאדם יבדוק). אם דבר לא הופעל — PASS. אותה הגשה, אותם חוקים — תמיד אותו פסק דין. אין כאן בודק שתשובתו משתנה בכל פעם ששואלים.

בדומיינים מורכבים שבהם חוקים משתרגים זה בזה — כשהפרה אחת מרוקנת בדיקה אחרת ממשמעות — אפשר להעלות את פסק הדין לגרף טיעונים (toulmin), ולהעביר את היגיון השיפוט עצמו למסמך בר-ביקורת (gate.md). תהיה הצורה אשר תהיה, דבר אחד אינו משתנה: השופט הוא מכונה.

④ record — הצעד הבלתי הפיך היחיד

מחילים את פסק הדין על ה-ratchet, שומרים לדיסק, ומייצאים (export) את הפריטים שהסתיימו. זו הנקודה האחת בתור שאין ממנה חזרה.

  • PASS / REVIEW / SKIPPED / BLOCKED → נעילה. ה-ratchet חד-כיווני; הוא אינו מסתובב לאחור.
  • FAIL → מונה הניסיונות (Tries) גדל ב-1 והפריט נשאר TODO. בהגיעו למספר הניסיונות המרבי (ברירת מחדל 3), הוא ננעל כ-DONE. גם “הפריט הזה לא עובד בדרך הזו” הוא צורה של סיום — לפריט תקוע אחד אסור להחזיק את כל הלולאה כבת ערובה לנצח.
  • שגיאת יצירה → היא נרשמת ב-Log כ-Attempt (העקבות של מה שקרה נשמרות), אבל היא אינה צורכת ניסיון. שרת LLM שנופל אינו אשמת הפריט; זו תקלה תפעולית. אם התקלה נמשכת, אמצעי בטיחות נפרד עוצר את הלולאה (עצירה אחרי N כשלי יצירה רצופים — circuit breaker).

רק עם הצעד הזה קיים ה-Log שה-compose של התור הבא יקרא. record הוא סיום התור והמחולל של התור הבא.

כישלון הוא עובדה, לא דעה

באיזו צורה FAIL חוזר — זה המפתח לכך שתור מתכנס (מתקרב לתשובה עם כל ניסיון חוזר). לא דעה כמו “האיכות קצת חסרה”, אלא זה:

FAIL. root cause = who-anchor-present
  Fact: where=who.anchors expected="source substring" actual="סגן המנהל יוסי כהן"

הקריאה פשוטה. איזה שדה (where), מה היה צריך להיות (expected — מחרוזת שקיימת בפועל במקור), מה היה בפועל (actual). מיקום + ערך צפוי + ערך בפועל. עבור ה-LLM זה משוב שאין בו למי להחניף — מספרים ומיקומים אינם רגשות. העובדה המובנית הזו היא שמובילה מודל חנפן לא לוויכוח אלא להתכנסות.

ובונוס אחד מעל לכך. טקסט ה-FAIL שמוזן למודל הוא בדיוק אותו רינדור כמו המחרוזת המודפסת על המסך כשאדם מריץ את פקודת submit (feedback parity). המשוב שאדם רואה והמשוב שהמודל רואה לעולם אינם מתפצלים. התעלומה של “מה בכלל נשלח לבינה המלאכותית שגרם לה לתקן כך?” נעדרת מבנית.

שלוש נקודות כניסה, תור אחד

נקרא למי שמניע את התור דרייבר. ל-reins יש שלושה: next, שבו אדם מקבל את הפרומפט ישירות; submit, שבו אדם מגיש את התוצאה; וה-loop האוטומטי חסר-ההשגחה. אבל אלה אינם שלושה מימושים נפרדים. הם שלוש נקודות כניסה לאותו מסמך תור. מה שמפריד בין ידני לאוטומטי הוא בדיוק חוק אחד בתוך המסמך.

התכונה המעשית שזה מניב: החליפו דרייבר באמצע קווסט — והפרומפט נשאר זהה בית-אחר-בית. הריצו את ה-loop האוטומטי אתמול, תנו לאדם לקחת פיקוד עם next היום — בהינתן אותו מצב Log, יוצא אותו פרומפט. זה אפשרי כי הקונטקסט מגיע רק מה-Log (ראינו זאת בצעד ①), וזו תכונה מוכחת, לא תקווה — מבחן זהב של החלפת דרייברים (driver-swap golden test) מאמת זהות בתים בהשוואת פלטים בין דרייברים.

מעקב אחרי תור אחד עד הסוף

התיאוריה נגמרה. נצפה בתור אמיתי אחד מההתחלה ועד הסוף. זהו פריט אחד בקווסט שמחלץ כתובות אימייל ממסמכים, בניסיונו השני, אחרי שהתור הקודם נכשל ב-FAIL עם “אינו פורמט אימייל תקין”.

[בדיקת כניסה לתור]  האם הפריט TODO? האם נותרו ניסיונות? → ממשיכים
① compose      מציאת ה-Attempt האחרון שנשפט (judged) ב-Log → FAIL, סיבה = email-format
               מדריך = הפרומפט הגלובלי + ההנחיה של חוק email-format
               פרומפט = מה לעשות + "FAIL. Fact: where=email
                        expected='valid email format' actual='kim at example'"
② generate     קריאת LLM → {"email":"kim@example.com", ...}
③ judge        סריקת חוקים: email-format עובר, source-lacks-email עובר, freemail עובר
               → אף חוק Fail לא הופעל → PASS
④ record       ה-ratchet ננעל (בלתי הפיך) → Attempt #2 נרשם → נשמר → export

המודל, שקיבל את עובדת הכישלון הקודם (“kim at example אינו פורמט אימייל תקין”), תיקן בדיוק את אותה נקודה; השער אישר את המעבר; ה-ratchet נעל. הפריט הזה הוא כעת PASS לנצח. התור הבא מדלג עליו, והעבודה הנותרת רק מתכווצת. כשכל פריט מגיע למצב סיום (PASS, REVIEW או מיצוי הניסיונות המרבי), הלולאה נגמרת. לא “כשהבינה המלאכותית מרגישה שסיימה” אלא כשהפריטים הנותרים מגיעים לאפס. ההתכנסות מובטחת על ידי המבנה.

Loop Engineering — התעשייה נתנה שם לאותה בעיה

ביוני 2026 קיבל שם השינוי באופן שבו מטפלים בסוכנים. Peter Steinberger כתב, “You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents” (אל תתנו יותר פרומפטים לסוכני קוד. תכננו לולאות שנותנות פרומפטים לסוכנים שלכם), ומוקדם יותר באותו חודש Boris Cherny מ-Anthropic, שבנה את Claude Code, אמר באירוע, “I don’t prompt Claude anymore. I have loops running… My job is to write loops” (אני כבר לא נותן פרומפטים ל-Claude. יש לי לולאות שרצות… העבודה שלי היא לכתוב לולאות). כמה ימים לאחר מכן, Addy Osmani מ-Google נתן לזרם הזה שם: Loop Engineering — מאדם שנותן פרומפטים לסוכנים, לאדם שמתכנן את המערכות שנותנות פרומפטים לסוכנים.

השיח הזה משרטט נרטיב מעבר יחיד. הנדסת פרומפטים (בחירת המילים) → הנדסת קונטקסט (בחירת המידע שמראים) → הנדסת harness (בניית סביבת הביצוע) → הנדסת לולאות (תכנון מחזור התצפית-פעולה-אימות-התאוששות עצמו). המנוף נע החוצה שכבה אחר שכבה: ממילים למידע, ממידע לסביבה, מסביבה למחזור.

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

ההמלצה של Loop Engineeringההבניה של תור ה-reins
החצינו מצב לדיסק או ללוח (המודל שוכח)ה-Log אינו עזר זיכרון אלא הקלט היחיד של התור — compose הוא פונקציה טהורה של ה-Log
הפרידו בין הבונה למאמת (סוכני משנה)המאמת אינו עוד LLM אלא שער דטרמיניסטי — אין בכלל API שמעניק PASS
הגדירו תנאי סיום ברי-בדיקההמונוטוניות של ה-ratchet מבטיחה התכנסות כאינווריאנט — מבנה, לא תנאי
הבחינו בין כשלים ברי-התאוששות לכשלים קטלנייםמובנה בחוקי record — FAIL צורך ניסיון; שגיאות יצירה שייכות ל-circuit breaker

לב ההבדל הוא המרחק בין המלצה למבנה. ספרות הנדסת הלולאות עצמה מודה בהיררכיה של האימות — LLM-as-judge, הפקדת פסק הדין בידי בינה מלאכותית, “can be gamed or can collude with the actor” (ניתן לרמותו, או שהוא עלול לקשור קשר עם המבצע), ולכן בכל מקום שבו אפשרית בדיקה דטרמיניסטית — שימו בדיקה דטרמיניסטית. אבל זה נשאר בגדר שיטת עבודה מומלצת — המלצה המופקדת בידי רצונו הטוב של המתכנן. אם סוכן-המשנה המאמת הוא בסופו של דבר גם הוא LLM, דלת הקנוניה נשארת פתוחה. reins סוגר את הדלת הזו בתכנון. רק השער שופט, וה-framework אינו חושף שום דרך לתת ל-LLM סמכות PASS.

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

למה דווקא היחידה הזו

הדקו את התור כך ותרוויחו שלושה דברים. השמות שחלפו על פנינו קודם מוצאים כאן את מקומם.

  • יכולת ביקורת — התשובה ל"במה ה-loop האוטומטי שונה מה-next הידני?" אינה מלאכת השוואה של שתי ערכות קוד אלא חוק יחיד בתוך מסמך. אפשר לאשר במו עיניכם שבדיוק נתיב אחד במסמך יכול לנעול PASS. זו הסיבה שהמקור הקנוני של התור הוא מסמך קריא, לא קוד.
  • עמידות להפעלה מחדש — כל קלט של תור נגזר מה-Log שעל הדיסק, ולכן גם אם התהליך מת, אותו Log משחזר את אותו תור.
  • חד-פעמיות של סוכנים — החליפו את הסוכנים (LLMים, דרייברים) — וההתקדמות עדיין מצטברת ולעולם אינה נסוגה. “Agents are disposable; progress is cumulative.”

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

התור נראה קטן. אבל בהיותו היחידה הקטנה ביותר שמפרידה ומסדרת בטור את היצירה (הסתברות), השיפוט (דטרמיניזם) והרישום (אי-הפיכות) בתוך מחזור יחיד, להבין את התור פירושו להבין את reins כולו.

מאמרים קשורים

לקריאה נוספת (חיצוני)

מקורות

יומן שינויים

  • 2026-07-07: מהדורה ראשונה