מה זה Loop engineering? הגדרה ומשמעות

מה המשמעות של הנדסת לולאות (Loop engineering)

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

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

מדוע המונח הופיע בשנת 2026

השם מתקבע בשיח הציבורי ממש עכשיו. מאגר ה-GitHub המכונה cobusgreyling/loop-engineering חצה את רף 9,600 הכוכבים תוך חודשיים ממועד הופעתו הראשונה (נכון ליולי 2026), תחת הכותרת "הפסיקו לתת הנחיות (prompting). תכננו את הלולאה. קבלו ציון." הוא מרכז את השינוי לשישה אבני בניין: תזמון, worktrees, מיומנויות, תוספים ומחברים, סוכני-משנה, וזיכרון עמיד שנשמר מחוץ לשיחה.

הוא מצטט את בוריס צ'רני, המוביל את Claude Code ב-Anthropic:

אני כבר לא נותן הנחיות ל-Claude. יש לי לולאות שרצות ומנחות את Claude.

מאגר שני, AI-Builder-Club/skills, מתקרב ל-1,100 כוכבים (נכון ליולי 2026) ומגדיר את שני התפקידים באופן ישיר: "רתמת בסיס קוד" (codebase harness) שהופכת מאגר לבטוח עבור סוכן להרצת בדיקות ופריסות בתוכו, ו"מהנדס לולאות" (loop engineer) שבונה תהליכי עבודה המתעוררים בעקבות טריגר, מבצעים את העבודה, וכותבים את מה שלמדו לקובץ משותף כדי שהלולאה הבאה תוכל לקרוא אותו.

אף אחד מהמאגרים לא המציא את הפרקטיקה הזו. כל מי שהריץ build לילי, linter בתוך תהליך של continuous integration, או cron job שפותח כרטיס (ticket), כבר מכיר את המבנה. מה שחדש הוא שהעובד בתוך הלולאה הוא כעת לא-דטרמיניסטי, דבר שמשנה את מה שהמנגנון העוטף נדרש לבצע.

ארבעת החלקים של לולאה

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

• טריגר (Trigger). האירוע שמתחיל הרצה: טיימר, webhook, בקשת pull request חדשה, או התראה.
• גבולות (Boundary). הקבצים, פרטי הגישה (credentials) והרשת שהסוכן רשאי להגיע אליהם במהלך אותה הרצה.
• אימות (Verification). בדיקה עם קוד יציאה (exit code) הקובעת אם לשמור את פלט ההרצה או להשליך אותו.
• תקציב (Budget). מגבלת ה-token, הזמן והכסף שמסיימת הרצה, בין אם הצליחה ובין אם לא.

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

טריגר: מה מפעיל את הסוכן

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

כתבו את היחידה ב-/etc/systemd/system/agent-loop.service:

[Unit]
Description=Agent loop: triage open issues
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
User=agent
WorkingDirectory=/srv/agent/repo
ExecStart=/srv/agent/bin/loop.sh
TimeoutStartSec=1800

ואת הטיימר ב-/etc/systemd/system/agent-loop.timer:

[Unit]
Description=Run the triage loop every 30 minutes

[Timer]
OnBootSec=5min
OnUnitActiveSec=30min
Unit=agent-loop.service

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now agent-loop.timer
systemctl list-timers agent-loop.timer

הפקודה systemctl list-timers אמורה להציג עמודת NEXT עם זמן עתידי ועמודת LEFT המציגה את הזמן שנותר עד להפעלה. תוצאה ריקה משמעותה שהטיימר אינו פעיל, כיוון ש-enable ללא --now מתזמן אותו להפעלה הבאה רק לאחר אתחול המערכת. TimeoutStartSec=1800 חשוב יותר ממה שנראה: סוכן שנתקע בהמתנה לקלט יותיר את היחידה במצב פעיל לנצח, והטיימר לא יופעל שוב. קראו את הלוג של הרצה באמצעות journalctl -u agent-loop.service -n 50.

אם אתם מפעילים את הלולאה מתוך cron, הוסיפו מנגנון הגנה מפני חפיפה, כיוון ש-cron יפעיל בשמחה עותק נוסף:

*/30 * * * * /usr/bin/flock -n /tmp/agent-loop.lock /srv/agent/bin/loop.sh

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

גבולות: הענקת עותק נפרד לכל הרצה

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

cd /srv/agent/repo
git worktree add -b loop/triage-01 /srv/agent/work/triage-01 origin/main
git worktree list

git worktree list מדפיס שורה אחת לכל עץ עם הנתיב, ה-commit והענף שלו. בסיום ההרצה, git worktree remove /srv/agent/work/triage-01 מוחק את הספרייה, ו-git worktree prune מנקה רשומות שהספרייה שלהן נעלמה. לולאות מקביליות הופכות לבטוחות בנקודה זו, כיוון ששני סוכנים על שני ענפים בשתי ספריות שונות אינם יכולים לדרוס זה את זה.

הגבול נוגע גם להרשאות. לולאה שרצה ללא השגחה מחזיקה אסימונים (tokens) ארוכי טווח, וכל הרצה היא הזדמנות לדליפת אסימון לתוך לוג, commit או הקשר של מודל. הגבילו את האסימון למאגר הנתונים היחיד שהלולאה נוגעת בו, הרחיקו אותו מהסביבה שבה ה-shell של הסוכן פועל ככל הניתן, וקראו את כיצד לשמור סודות מחוץ לסוכני AI לפני שאתם מעניקים ללולאה גישת production. לקבלת חומת הגנה חזקה יותר, הריצו את הלולאה כולה על מכונה וירטואלית זמנית שניתן להשמיד לאחר כל הרצה. הכלי שבו אתם משתמשים קובע גם הוא חלק מהגבול עוד לפני כתיבת הקוד, לכן כדאי לקרוא את כיצד ה-sandbox המנוהל של Cowork בהשוואה ל-Claude Code על המכונה שלך לפני שתחליטו על רמת הבידוד שעליכם לבנות בעצמכם.

אימות: השער שהופך את הלולאה לבטוחה

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

#!/usr/bin/env bash
set -euo pipefail

repo=/srv/agent/repo
branch="loop/$(date -u +%Y%m%dT%H%M%SZ)"
tree="/srv/agent/work/$(basename "$branch")"

cd "$repo"
git fetch --quiet origin
git worktree add -b "$branch" "$tree" origin/main
cd "$tree"

# the agent's own command runs here, in non-interactive mode

if ! npm test; then
  echo "gate failed: discarding $branch" >&2
  cd "$repo"
  git worktree remove --force "$tree"
  exit 1
fi

git push origin "$branch"
cd "$repo"
git worktree remove "$tree"

set -euo pipefail מבצע עבודה ממשית בתוך הסקריפט הזה. ללא -e, כשל ב-git fetch יתעלם מהשגיאה וההרצה תימשך מול origin/main מיושן. ללא -u, שגיאת הקלדה בשם של משתנה תתרחב למחרוזת ריקה, ופעולת הניקוי תרוץ על הנתיב הלא נכון במקום להיכשל באופן ברור.

בלוק ה-if ! npm test הוא לב העניין. קוד היציאה של בדיקה שאתם כבר סומכים עליה, חבילת הבדיקות שלכם או בודק הטיפוסים, הוא שקובע אם ה-branch יידחף או יושמד. לולאה ללא שער מייצרת עבודה שאף אחד לא יספיק לעבור עליה, וזה גרוע יותר מחוסר עבודה. לולאה עם שער מייצרת branch שכבר עבר את אותו רף ש-branch של תורם אנושי נדרש לעבור. שער ירוק לא מעיד על היקף הקוד שהסוכן שינה כדי להגיע לתוצאה, לכן כדאי לשלב את הבדיקה עם הנחיה קבועה כמו הכלל שמחייב סוכן לבצע את השינוי הקטן ביותר שעובד, מה ששומר על ה-diff קטן מספיק כדי שהסקירה שלו תישאר זולה.

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

תקציב: מה עוצר הרצה

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

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

התבניות שמקודדות במאגרים המגמתיים

המאגר loop-engineering מפרט שבע תבניות עבודה בסביבת production, וכדאי להתייחס אליהן כתפריט ולא כמניפסט. מיון יומי (Daily triage). בייביסיטר ל-pull-request שעוקב אחר הערות סקירה ומשיב עליהן. מנקה אינטגרציה רציפה (continuous-integration sweeper) שמטפל ב-builds שנכשלו. מנקה תלויות. מנסח changelog. ניקוי לאחר merge. מיון תקלות (Issue triage).

מה שמשותף להן הוא משימה מוגדרת היטב עם שער ברור. ל-"Fix the failing build" יש תנאי הצלחה שהמכונה יכולה לקרוא. ל-"Improve the codebase" אין, ולכן הוא לעולם לא הופך ללולאה. הוא הופך לבלגן מתוזמן.

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

היכן לולאות נכשלות

הכשלים הם משעממים, והם חוזרים על עצמם בצוותים שונים.

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

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

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

אין צורך ב־framework. שרת Linux קטן שפועל תמיד, מאגר git שחבילת הבדיקות שלו נכשלת כאשר היא אמורה להיכשל, טיימר אחד של systemd וסקריפט shell המכיל if יוצרים לולאה שלמה. זהו המקום שבו רוב האנשים צריכים להתחיל, כיוון ששאלות התכנון מקבלות מענה תוך כדי הרצת המערכת ולא על ידי בחירת כלי מורכב. ברגע שלולאה אחת יציבה, הרצת לולאה שנייה היא בעיקר עניין של טיימר נוסף ו־worktree נוסף. עיינו ב-איך להריץ סוכן AI לכתיבת קוד על גבי VPS עבור הגדרת הבסיס, וב-אפשרויות נוכחיות לסוכני AI באירוח עצמי אם ברצונכם להריץ את הסוכן עצמו על חומרה שבשליטתכם.

FAQ

האם הנדסת לולאות (loop engineering) שונה מהנדסת פרומפטים (prompt engineering)?

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

האם אני זקוק ל-framework כדי לבנות לולאת סוכן (agent loop)?

לא. טיימר של systemd, עץ עבודה (git worktree) לכל ריצה, סקריפט shell שמסתיים בפקודת בדיקה, ומכסת הוצאות בחשבון ספק ה-API, מכסים כל חלק בהגדרה. Frameworks מוסיפים ממשקי תזמון, פורמטים של זיכרון משותף וניתוב מרובה-סוכנים, שהם שימושיים ברגע שמריצים כמה לולאות. הם אינם תנאי סף ללולאה הראשונה.

מהו codebase harness?

זהו אוסף הרכיבים המאפשרים לסוכן לעבוד במאגר (repository) ללא נוכחות אנושית: הגדרה בפקודה אחת, בדיקות שרצות ללא אינטראקציה ונכשלות בצורה ברורה, linter, ודרך לפרוס או להציג שינוי בתצוגה מקדימה. המונח מגיע מאותו גל של מאגרים משנת 2026 כמו הנדסת לולאות. המבחן המעשי פשוט: אם תורם אנושי חדש לא יכול לעבור מ-clone לבדיקות תקינות (green tests) בפקודה אחת, גם סוכן לא יוכל.

איך אוכל למנוע מלולאת סוכן לצבור חשבון גבוה?

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

אילו משימות כדאי להפוך ללולאה תחילה?

בחרו משימה עם תנאי הצלחה שניתן לקריאה על ידי מכונה ועם טווח השפעה (blast radius) קטן. תיקון build שנכשל, עדכון תלות ויצירה מחדש של changelog הם מועמדים מתאימים, כיוון שחבילת בדיקות או diff יכולים להוכיח את התוצאה. עבודה פתוחה כמו refactoring או עיצוב אינה מתאימה עדיין, כיוון שאין שום דבר שהשער יכול לבדוק, ולולאה ללא שער היא דרך יקרה לייצר חוב סקירה.