Agent Loops ב-Claude Code: מדריך עבודה

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

מה זה Agent Loop בפועל

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

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

מקור רשמי: איך Claude Code עובד

למה הלולאה הפכה לצוואר הבקבוק, ולא הפרומפט

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

הכשלים מתנהגים לפי תבנית קבועה. סוכן בלי verifier בדרך כלל לא מתפוצץ, הוא נסחף. הוא מתקן את הבדיקה על ידי מחיקת ה-assertion. הוא מסמן משימה כהושלמה כי הפקודה האחרונה החזירה אפס, והפקודה האחרונה הייתה echo. הוא עושה refactor למודול תקין כי החליט שזה היה מרומז. אף אחד מהדברים האלה לא נראה כמו טעות באמצע ההרצה. הם נראים כמו התקדמות, וזה מה שהופך אותם ליקרים. אתה מגלה אותם אחר כך, ב-diff שלא קראת מספיק לעומק, או בפרודקשן.

בעיית המנהל: למה לפקח על סוכן קשה יותר מלכתוב קוד

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

הפתרון הוא לא יותר משמעת בקריאת diffים. הוא להעביר את הבדיקה ממך ללולאה. כל בדיקה שאתה יכול לנסח כפקודה שמחזירה קוד יציאה שונה מאפס היא בדיקה שלא תצטרך לעשות שוב בעיניים. בדיקות, type check, lint, build, הרצת יבש של migration, diff של סכימה. זו העבודה האמיתית עכשיו: להמיר את שיקול הדעת שלך ל-gates שהלולאה יכולה להריץ בלעדיך. מה שנשאר, הדברים שבאמת דורשים בן אדם, זו רשימה הרבה יותר קצרה ממה שהיא מרגישה בהתחלה.

איך מאמתים קוד בתוך agent loop

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

1. 01פקודה עם קוד יציאה אמיתי. סוויטת הבדיקות, tsc, ה-build, בדיקת migration. אי אפשר לשכנע אותה לעבור, וזו הקטגוריה היחידה שאני נותן לרוץ בלי השגחה.
2. 02gate מצומצם ל-diff. lint או בדיקות מוגבלות למה שבאמת השתנה, כדי שלולאה ארוכה תישאר מהירה מספיק שהסוכן ימשיך להריץ אותה במקום לדלג עליה.
3. 03סוכן שני שסוקר את הפלט של הראשון מול קריטריונים כתובים. שימושי לדברים ששום פקודה לא תופסת, כמו האם השינוי באמת עונה על ה-issue. חלש יותר מקוד יציאה, כי זה מודל שבודק מודל.
4. 04ההצהרה של הסוכן עצמו שהוא סיים. זה לא אימות. תתייחס לזה כבקשה לביקורת, אף פעם לא כראיה.

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

Claude Code /loop: מה הוא עושה ומה הוא לא

/loop של Claude Code מריץ פרומפט או slash command במרווח חוזר. /loop 5m /tests יריץ את הבדיקות כל חמש דקות. תשמיט את המרווח ו-Claude יבחר את הקצב בעצמו אחרי כל סיבוב, וזה מה שאתה רוצה כשההמתנה תלויה בעבודה ולא בשעון.

המגבלות חשובות יותר מהתחביר. משימות חוזרות פגות שבעה ימים אחרי היצירה. הן מופעלות רק כל עוד Claude Code רץ ופנוי, כך שלפטופ סגור זו לולאה עצורה. חזרה לאותה שיחה עם --resume או --continue משחזרת משימה שעדיין בתוקף. הצורה הזו הופכת את /loop למתאים למעקב שתלוי בסשן: לראות deploy מסתיים, לשמור על PR פתוח, להריץ שוב בדיקות בזמן שאתה עובד על משהו אחר באותו חלון. זה הכלי הלא נכון לכל דבר שצריך לשרוד את סגירת הטרמינל. בשביל זה יש Routines, Desktop scheduled tasks או GitHub Actions, שרצים בין אם אתה שם ובין אם לא.

מקור רשמי: הפעלת משימות חוזרות ב-Claude Code

Loop Engineering: ארבעה דברים שאני בודק לפני שמתחילים

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

• מה תנאי העצירה, מנוסח כמשהו שמכונה יכולה להעריך. לא "עד שזה יעבוד", אלא "עד ש-npm test מחזיר אפס" או "עד שה-check על ה-PR ירוק". היעדר תנאי עצירה הוא הסיבה הנפוצה ביותר לסוכן שיוצא משליטה.
• מה ה-verifier, והאם אפשר לרמות אותו. אם ההוכחה היחידה היא הסיכום של הסוכן עצמו, אין verifier והלולאה פתוחה בין אם אני מודה בזה ובין אם לא.
• פתוחה או סגורה. לולאה סגורה רצה עד הסוף לבד וצריכה verifier חזק. לולאה פתוחה שמה בן אדם בהחלטות שאי אפשר להחזיר אחורה. כל דבר שנוגע בנתוני פרודקשן, בכסף או במשטח ציבורי הוא פתוח, לתמיד.
• כמה צר ההיקף. לולאה שמכוונת למודול אחד מתכנסת. לולאה שמכוונת ל"תשפר את הקוד" משוטטת, כי כל סיבוב משנה את מה שהסיבוב הבא רואה.

לולאה שאני באמת מריץ

פייפליין הבלוג שלי רץ לפי לוח זמנים: הוא מייצר טיוטה בעברית, בונה את האתר, פותח PR ושולח לי הודעה. כל חלק בו נבחר מול הרשימה למעלה. תנאי העצירה הוא המיזוג שלי. ה-verifier הוא ה-build, כך שטיוטה ששוברת את האתר לא מגיעה ל-PR בכלל ואני אפילו לא רואה אותה. ההיקף הוא פוסט אחד, לא הבלוג. זו לולאה פתוחה בכוונה, כי לפרסם בשם שלי זה לא הפיך באותו אופן ששינוי קוד הפיך.

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