לולאות סוכנים: איך נותנים ל-AI לבדוק ולשפר את העבודה של עצמו

מה זו לולאת סוכן, ולמה כולם מדברים עליה?

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

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

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

למה לולאה מקדמת את האיכות כבר מהניסיון הראשון?

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

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

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

איך נראית לולאת מחקר אמיתית מההתחלה ועד הסוף?

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

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

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

מה אפשר ללמוד משלוש לולאות קצרות?

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

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

איך כותבים יעד ותנאי עצירה שאפשר לבדוק?

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

/goal Build a landing page hero section for the product in ./brief.md.

Definition of done:
- Lighthouse accessibility score >= 95
- No layout shift on 375px and 1440px widths (check with screenshots)
- Headline fits in 2 lines on mobile

Loop: build -> open in browser -> screenshot both widths -> score -> fix.
Stop when all 3 checks pass, or after 6 passes. Log every pass to loop-log.md.

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

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

שמונה מרכיבים של לולאה שעובדת

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

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

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

מתי לולאה ארוכה באמת שווה את המחיר?

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

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

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

חמש תובנות על לולאות סוכנים

סיכום: איך מתחילים לעבוד עם לולאות?

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

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

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