מהי הנדסת לולאות? הגדרה פשוטה לסוכני AI

מהי הנדסת לולאות

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

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

מדוע המונח הופיע ב-2026

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

במאגר מצוטט Boris Cherny, המוביל את Claude Code ב-Anthropic:

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

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

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

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

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

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

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

Trigger: מה מעיר את הסוכן

טיימר הוא הטריגר הפשוט ביותר. בשרת 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 מסתיים מיד עם status 1 כאשר הנעילה מוחזקת. כך ההפעלה השנייה נעלמת בשקט במקום להתחרות בהפעלה הראשונה. אותה הגדרה של שירות וטיימר של systemd חלה על כל משימה ממושכת בשרת, בין שהיא סוכן ובין שלא.

גבול: תנו לכל הרצה עותק משלה

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

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 מנקה רשומות שהספרייה שלהן נעלמה. בשלב זה לולאות מקביליות בטוחות, משום ששני סוכנים בשני ענפים ובשתי ספריות אינם יכולים לדרוס זה את זה.

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

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

זהו החלק שמבדיל בין לולאה לבין משימת 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 הוא עיקר הרעיון. קוד היציאה של בדיקה שכבר נותנים בה אמון, כגון חבילת הבדיקות או בודק הטיפוסים, קובע אם הענף יידחף או יימחק. לולאה ללא שער מייצרת עבודה שלאיש אין זמן לבדוק, וזה גרוע יותר מלא לייצר עבודה. לולאה עם שער מייצרת ענף שכבר עומד באותו רף שענף של תורם אנושי חייב לעמוד בו.

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

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

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

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

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

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

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

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

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

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

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

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

התחלה ללא המינוח

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

FAQ

האם הנדסת לולאה שונה מהנדסת הנחיות?

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

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

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

מהו רתמת קוד?

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

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

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

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

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