הנדסה עם סוכנים

SwarmForge: מה נחיל הסוכנים של אנקל בוב מבין נכון

SwarmForge מריץ כמה סוכני קוד מבוססי AI בחלונות tmux, כל אחד ב-worktree נפרד של git וכל אחד מחזיק תפקיד הנדסי אחד בלבד. הכלים משעממים במתכוון. המעניין הוא תרשים הארגון שמוצפן בהם.

לדבר עם צוות הנדסת ה-AI שלנו לשירותי פיתוח AI

מה SwarmForge באמת

SwarmForge היא מעטפת של שֶׁל ו-Babashka סביב שלושה מרכיבים שכבר יש לרוב הצוותים: חלונות tmux, worktrees של git וקבצי פרומפט. כל חלון מריץ סוכן אחד בתפקיד אחד מול worktree משלו תחת .worktrees/, כך ששני סוכנים לא נאבקים על אותה ספריית עבודה. ההתנהגות מגיעה מטקסט פשוט ב-swarmforge/roles/<role>.prompt, שמונח על constitution.prompt משותף והמאמרים שלו. הסוכנים לא מקלידים לטרמינל אחד של השני: הם מכניסים לתור העברות מאומתות דרך .swarmforge/handoffs/, והמטען הוא או קיצור קומיט של עשרה תווים או הערה של שמונים תווים לכל היותר. את המנוע בוחרים לכל תפקיד בנפרד, כך שסשן אחד יכול לערבב Claude, Codex, Copilot ו-Grok.

ענף main הוא תיעודי. הנחילים שרצים באמת נמצאים בענפים two-pack, four-pack ו-six-pack: מורידים את הענף בצורה שרוצים ומריצים ./swarm. הדרישות הן zsh, git, tmux, Babashka ו-CLI מוגדר של סוכן.

שלוש צורות נחיל

כל ענף הוא תשובה אחרת לשאלה כמה תהליך מגיע למשימה. הזרימה היא טבעת ולא תור: העבודה חוזרת סביב.

two-pack

coder → cleaner → coder

coder שעובד קודם-כל-בדיקה ו-cleaner שמסדר, עושה סקירת CRAP ו-DRY ותיקוני ארכיטקטורה. הלופ השימושי הקטן ביותר: לכתוב, ואז להעביר למי שלא מאוהב בקוד.

four-pack

specifier → coder → refactorer → architect → specifier

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

six-pack

specifier → coder → cleaner → architect → hardener → QA

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

סוכן אחד, דיסציפלינה אחת

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

specifier

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

coder

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

cleaner

סידור מקומי, כיסוי, סקירת CRAP ו-DRY. שמות וכפילויות מקבלים מעבר מוקדש במקום הערת סקירה שאף אחד לא מטפל בה.

architect

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

תפקיד ההקשחה

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

QA

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

איך התיאום עובד

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

הטופולוגיה היא קובץ הגדרות אחד

conf

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

# swarmforge/swarmforge.conf
# window <role> <agent> <worktree> [task|batch] [extra-cli-args...]
window coordinator codex master
window coder       codex coder
window architect   codex architect

העברות מאומתות, לא משוחחות

sh

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

# queue work for the next role: a commit, or a note of <= 80 chars
./swarm_handoff.sh coder 4f2a9c1b0d "boundary rule now specified"

# on the receiving side
./ready_for_next.sh      # accept the next item or batch
./done_with_current.sh   # close it out and free the window

התקן חי בעץ הפרומפטים

text

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

swarmforge/
  swarmforge.conf
  constitution.prompt
  constitution/articles/
    engineering.prompt
    handoffs.prompt
    workflow.prompt
    project.prompt
    local-engineering.prompt
    local-workflow.prompt
  roles/
    <role>.prompt

מה לקחת גם אם לא תריצו את זה

לתת לכל מעבר שם ותפקיד אחד

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

לבודד את סביבת העבודה, לא רק את הענף

  • - worktree נפרד לכל תפקיד מבטל את כל משפחת הכשלים שבה שני סוכנים עורכים את אותו קובץ במקביל
  • - בידוד הופך עבודה מקבילית לקריאה: לכל תפקיד יש עץ שאפשר לבדוק בנפרד
  • - אותו טריק עובד גם לאדם אחד שמריץ כמה סוכנים מקומית, בלי שום נחיל

העברות צרות ומאומתות

  • - הפניה לקומיט ועוד שורה קצרה דוחפות את הכוונה אל הקוד ואל הודעת הקומיט
  • - אימות בגבול ההעברה תופס בקשה שגויה לפני שהתפקיד הבא מבזבז עליה ריצה
  • - העברות צרות ניתנות לביקורת: אפשר לשחזר מי העביר מה ומתי

להחזיק את התקן במקום שבו העבודה קורית

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

איפה ההסתייגויות הכנות

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

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

שמונים תווים הם צינור צר

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

תפקידים הם פרומפטים, לא הבטחות

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

מישהו עוד חותם

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

זרימת העבודה היא התרומה

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

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

מאמרי הנדסה קשורים

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

חזרה לפיתוח AI
עיצוב בדיקות

בדיקות מוטציה הן שליליות. בדיקות TDD הן חיוביות.

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

מדדי איכות קוד

מדד CRAP: מורכבות וכיסוי במספר אחד

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

שאלות נפוצות

מה צריך כדי להריץ את SwarmForge?

zsh, git, tmux ו-Babashka, ובנוסף CLI מוגדר של סוכן כמו Claude, Codex, Copilot או Grok. אין שירות ענן ואין שכבת אורקסטרציה להקים: הנחיל הוא חלונות tmux שאפשר להסתכל בהם, עם worktree נפרד לכל תפקיד על הדיסק.

מאיזה ענף כדאי לצוות להתחיל?

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

האם נחיל סוכנים מייתר את ה-QA?

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

האם זו אורקסטרציה בשלה לפרודקשן?

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

© 2026 - Ryware.