Loop Engineering: מה הדרך הנכונה לתת לסוכן AI לעבוד בלופים

רוב העבודה עם כלי AI עדיין נראית כמו פינג-פונג. אתם כותבים בקשה, המודל מחזיר תשובה, אתם בודקים, מתקנים, מבקשים שוב, ואז חוזרים על אותו מעגל עד שהתוצאה מספיק טובה. במשימה קצרה זה נוח. במשימה שחוזרת בכל יום, תלויה בבדיקות, או דורשת כמה ניסיונות עד שהיא עובדת באמת, זה כבר מתחיל להיות צוואר בקבוק. כאן נכנס המושג Loop Engineering, או תכנון לולאות עבודה. במדריך שפרסמה אנטרופיק (Anthropic), צוות קלוד קוד (Claude Code) מגדיר לולאה כסוכן שחוזר על מחזורי עבודה עד שמתקיים תנאי עצירה. כלומר, במקום לבקש ממנו בכל פעם “תמשיך”, “תקן”, “בדוק שוב”, אפשר להגדיר מראש מה היעד או המטרה, מה הוא צריך לבדוק בדרך ומתי עליו לעצור.

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

המחזור הבסיסי של סוכן AI | מקור: Anthropic

קודם כול, מהי לולאה

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

בשיחה רגילה אתם אלה שמנהלים את הלולאה. אתם קוראים את התוצאה ומחליטים אם להמשיך. בלולאה מתוכננת, אתם מגדירים מראש כלל ברור יותר. למשל, “אל תעצור עד שכל הבדיקות עוברות”, או “בדוק את בקשת הלקוח כל 30 דקות וטפל בהערות חדשות”.

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

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

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

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

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

דוגמה ל-Skill | מקור: Anthropic

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

מקור: Anthropic

לולאת מטרה: כשאפשר להגדיר מה נחשב “סיימנו”

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

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

לפי התיעוד של אנתרופיק, goal/ מפעיל מודל הערכה נפרד (בדרך כלל מודל מהיר כמו Haiku) שבודק אחרי כל תור אם התנאי שהגדרתם התקיים. אם לא, קלוד ממשיך לעבוד עד שהיעד מושג או עד שמגיעים למגבלת התורות שהוגדרה.

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

לולאת מטרה | מקור: Anthropic

הפרט החשוב כאן הוא שהבודק של goal/ לא מריץ בדיקות בעצמו מאחורי הקלעים. הוא בוחן את מה שקלוד הציג בשיחה. לכן תנאי טוב צריך להיות כזה שקלוד יכול להוכיח מתוך הפעולות שביצע. “שהקוד יעבוד” הוא תנאי חלש. “כל הבדיקות בתיקיית auth עוברות ופקודת lint מסתיימת בלי שגיאות” הוא תנאי טוב בהרבה.

הנה דוגמה מוצלחת:

מקור: Anthropic

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

לולאת זמן: כשהעבודה חוזרת מבחוץ

יש עבודות שלא מתחילות כי אתם כתבתם הודעה חדשה, אלא כי משהו השתנה מחוץ לשיחה. מישהו השאיר הערה על Pull Request, כלומר בקשה למיזוג קוד. מערכת בדיקות אוטומטית, שנקראת CI, נכשלה. התקבלו הודעות חדשות בערוץ Slack. במקרים כאלה אפשר להשתמש ב-loop/, שמריץ בקשה מחדש במרווחי זמן קבועים.

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

דוגמה לפקודה שבודקת PR, מטפלת בהערות סקירה ומתקנת CI שנכשל | מקור: Anthropic

ככה זה יכול להיראות:

מקור: Anthropic

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

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

כשמשימה צריכה להמשיך גם כשהמחשב סגור

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

רוטינות בסרגל הצד של קלוד קוד

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

דוגמה יכולה להיראות ככה:

מקור: Anthropic

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

איך להתחיל בלי להסתבך

הדרך הנכונה להתחיל היא לא לבנות אוטומציה מורכבת. תבחרו משימה אחת קטנה שחוזרת על עצמה ושיש לה דרך בדיקה ברורה.

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

שלב מתקדם: לולאה משולבת

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

ומה לגבי Auto Mode

Auto Mode הוא מצב שבו קלוד קוד יכול לבצע הרבה פעולות בלי לבקש אישור על כל פעולה בנפרד. באוגוסט 2026 אנטרופיק הודיעה שהוא הופך לברירת מחדל בסשנים חדשים בתוכניות Pro, Max ו-Team, אלא אם המשתמש או הארגון הגדירו אחרת. החברה גם מדגישה שהמצב נשען על מערכת סיווג שנועדה לחסום פעולות מסוכנות, הרסניות או כאלה שפועלות מחוץ לסביבה המותרת.

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

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

חלון מצבי הרשאות

מתי לא להשתמש בלולאות

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

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

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

המדריכים תמיד חינמיים, אבל אם בא לכם להתמקצע - יש גם קורס קלוד קוד (Claude code) וסביבת אנטרופיק

לפרטים נוספים לחצו כאן >>

לולאה זה החיים

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

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

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