מדוע להריץ סוכני קידוד בתוך מכונה וירטואלית זמנית

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

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

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

הגדירו את רדיוס הפיצוץ לפני שאתם מתווכחים עליו

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

היא כוללת את ~/.ssh/id_ed25519, שלרוב אינו מוצפן כי נמאס לכם להקליד את סיסמת הגישה. היא כוללת את ~/.aws/credentials ואת ~/.config/gh/hosts.yml, שהם קובצי טקסט פשוט מעצם תכנונם. היא כוללת כל מאגר (repository) אחיות תחת ~/code, כולל אלו שמכילים מחרוזות התחברות לסביבת ייצור בתוך קובץ env מקומי. היא כוללת את היסטוריית ה־shell שלכם, ששומרת אסימונים (tokens) שהדבקתם פעם אחת. היא כוללת גם את הרשת שבה המחשב הנייד שלכם נמצא, שלרוב היא רשת ביתית או משרדית עם שירותים לא מאומתים.

שום דבר מזה לא דורש סוכן זדוני. הוא דורש פקודה אחת שגויה שבוצעה בביטחון. rm -rf עם משתנה לא מוגדר שמתרחב ל-/, git clean -xfd בספרייה הלא נכונה, docker system prune -af --volumes שלוקח איתו את מסד הנתונים המקומי שלכם, או chmod -R 777 מועיל על ספריית הבית. סוכנים מאומנים על אותו אינטרנט שלימד את הפקודות האלו לכל השאר.

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

חישוב העלויות הוא משעמם, וזו בדיוק הנקודה

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

בצעו את החישוב עם המספרים שלכם. קחו את התעריף השעתי שלכם, הכפילו במספר השעות שיידרשו להתקנה מחדש של מערכת הפעלה, שחזור ספריית בית, החלפת SSH key, החלפת personal access token, ושכפול מחדש של עשרים מאגרים (repositories). השוו זאת לעלות של 12 חודשים עבור השרת הקטן ביותר שהספק שלכם מוכר. נקודת האיזון נמצאת מתחת לאירוע אחד בכל כמה שנים, והאירוע לא חייב להיות קטסטרופלי כדי להצדיק את ההוצאה. אובדן של אחר צהריים אחד בגלל סביבה מקומית פגומה כבר מכסה את עלות השנה כולה.

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

הנוף הטכנולוגי נכון ליולי 2026

קיימות שלוש תשובות כנות לשאלה "היכן על הסוכן (agent) לרוץ", והן מאזנות בין שני גורמים: עוצמת הגבול (boundary) ומידת המאמץ הנדרש להגדרה.

מכונה וירטואלית מקומית (Micro VM). כלים בקטגוריה זו מפעילים מכונה וירטואלית אמיתית על החומרה שלך, מעגנים (mount) את המאגר (repository) לתוכה, ומעניקים לסוכן הרשאות root בתוכה. clawk הוא הדוגמה העדכנית, והטיעון שלו הוא בדיוק התזה של פוסט זה: תנו לסוכני תכנות מכונת Linux חד-פעמית, לא את המחשב האישי שלכם. נכון ליולי 2026, הוא מיועד ל-macOS 14 ומעלה על גבי Apple silicon, עם תמיכה ניסיונית ב-Linux דרך Firecracker, והוא מותקן באמצעות brew install clawkwork/tap/clawk. מריצים clawk בתוך מאגר כדי להפעיל את ה-sandbox ולחבר סוכן, clawk down כדי לעצור אותו, ו-clawk destroy כדי להסיר אותו. הגבול הוא hypervisor, שהוא חזק. המגבלה היא שה-VM חיה על המכונה שאתם נושאים עמכם, לכן היא מתחרה על הזיכרון שלכם ונעצרת כשסוגרים את המכסה.

מכולה (Container). Docker היא התשובה שרוב האנשים כבר התקינו, והיא שימושית מאוד.

docker run --rm -it -v "$PWD:/work" -w /work --network none ubuntu:24.04 bash

--rm משליך את המכולה עם היציאה, ו---network none לא מעניק לה גישה לרשת כלל; זו ברירת מחדל טובה עבור הרצת build או בדיקה. חשוב להבין מה זה לא עושה: מכולה חולקת את ה-kernel של המארח, לכן באג ב-kernel הוא דרך החוצה, והגבול נעלם ברגע שמוסיפים --privileged או מעגנים את /var/run/docker.sock כדי שהסוכן יוכל "להשתמש ב-Docker". עיגון ה-socket של Docker לתוך מכולה שקול למתן הרשאות root על המארח לאותה מכולה.

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

תבנית ה-VPS: הקצאת משתמש ייעודי לסוכן

התחילו משרת מוקשח. המדריך עשר הדקות הראשונות ב-VPS חדש מכסה את החלקים שאינם ספציפיים לסוכן: עדכונים, התחברות ללא משתמש root, שימוש במפתחות SSH בלבד, ו-firewall.

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

sudo adduser --disabled-password --gecos "" agent
sudo install -d -m 700 -o agent -g agent /home/agent/work
sudo -u agent -H bash -lc 'id; ls -la ~'

--disabled-password משמעו שאין סיסמה שניתן לנחש, ואתם מגיעים לחשבון באמצעות sudo -u agent או מפתח SSH. שימו לב ש-agent אינו נמצא במכוון בקבוצת sudo. לסוכן עם sudo יש הרשאות root, ומשתמש root יכול לקרוא את הקבצים של כל משתמש אחר; לכן, ההפרדה שיצרתם כרגע היא קוסמטית בלבד. אם הסוכן באמת זקוק ליכולת להתקין חבילות, זהו טיעון לשרת ייעודי בבעלותו, ולא למתן הרשאות sudo בשרת משותף. הכללים הכלליים מפורטים ב-עקרון הסמכות המינימלית למשתמשי Linux ב-VPS.

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

sudo -u agent cat /home/you/.ssh/id_ed25519

אתם אמורים לראות cat: /home/you/.ssh/id_ed25519: Permission denied. אם אתם רואים תוכן של מפתח, תיקיית הבית שלכם מוגדרת במצב 755 והבידוד אינו אמיתי עדיין. תקנו זאת באמצעות sudo chmod 700 /home/you.

שמירה על פרטי הזדהות מחוץ לשרת

התועלת במכונה זמנית מתבטלת אם מעתיקים אליה את פרטי הגישה (secrets) של סביבת הייצור. הכלל פשוט: אל תאחסנו על המכונה שום פרט הזדהות שלא הייתם רוצים להחליף (rotate) עוד היום.

עבור git, השתמשו ב־SSH agent forwarding במקום להעתיק מפתח. המפתח הפרטי נשאר על המחשב האישי שלכם, ורק בקשות חתימה עוברות דרך החיבור.

ssh -A agent@203.0.113.10
ssh -T git@github.com

הפקודה השנייה צריכה להחזיר Hi yourname! You've successfully authenticated, but GitHub does not provide shell access.. זה מוכיח ש־git push יעבוד ללא קובץ מפתח על השרת. הריצו ls -la ~/.ssh על המכונה לאחר מכן וודאו שאין בה מפתח פרטי.

ל־agent forwarding יש סייג אחד משמעותי, ויש להציג אותו בבירור: כל עוד אתם מחוברים, לכל מי שיש לו הרשאות root על השרת יש אפשרות להשתמש ב־socket המועבר כדי להזדהות בשמכם. בשרת שבו אתם המשתמשים היחידים, זהו סיכון מקובל. בשרת משותף זה אינו המצב, ושימוש ב־deploy key המוגבל למאגר (repository) אחד הוא פתרון עדיף. האפשרויות מפורטות ב־יסודות ניהול מפתחות SSH.

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

הגבלת הגישה של הסוכן לרשת

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

sudo iptables -A OUTPUT -m owner --uid-owner agent -o lo -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -p udp --dport 53 -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -p tcp --dport 443 -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -j REJECT

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

sudo -u agent curl -sS -m 5 http://example.com

פעולה זו אמורה להיכשל עם curl: (7) Failed to connect to example.com port 80: Connection refused, מכיוון שחוק ה-reject משיב מיד במקום לתת לחיבור להמתין. בקשת HTTPS לאותו מארח עדיין אמורה להצליח.

שתי מגבלות כנות. ראשית, חוקים אלו יאבדו באתחול הבא אלא אם תשמרו אותם באמצעות sudo apt install -y iptables-persistent ולאחר מכן sudo netfilter-persistent save. שנית, סינון זה מתבצע ברמת הפורטים והכתובות, לא ברמת השמות. חוק המתיר פורט 443 מתיר גישה לכל מארח HTTPS באינטרנט, מה שמספיק כדי להגיע ל-API של המודל, אך גם מספיק כדי להגיע ל-pastebin. רשימת היתרים (allow-list) מבוססת דומיינים מחייבת שהתעבורה תעבור דרך proxy שקורא את שם המארח המבוקש, מה שמהווה מורכבות גדולה יותר ממה שרוב המפתחים העובדים לבדם מעוניינים בו. הצהירו רק על מה שיש לכם: בקרת תעבורה יוצאת ברמת הפורט, על מכונה שאתם מוכנים לאבד.

איפוס למצב נקי בין משימות

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

הגרסה הזולה היא ביצוע checkout חדש לכל משימה.

sudo -u agent -H bash -lc 'rm -rf ~/work/repo && git clone git@github.com:you/repo.git ~/work/repo'

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

שמרו כל דבר שחשוב לכם מחוץ למכונה החד-פעמית; המשמעות היא בעיקר דחיפת ענפים (branches) במקום צבירתם באופן מקומי. אם המכונה בכל זאת מכילה משהו שתתגעגעו אליו, גבו אותו כראוי באמצעות גיבויי restic ב-VPS. מכונה שניתן להשמיד מועילה רק אם השמדתה היא אירוע חסר משמעות.

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

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

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

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

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

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

FAQ

האם מכולה (container) מספקת בידוד מספיק עבור סוכן קידוד?

עבור רוב המשימות, כן, בתנאי שמתקיימים שני תנאים. אסור למכולה לרוץ עם --privileged, ואסור שיהיה לה /var/run/docker.sock מותקן (mounted) בתוכה, כיוון ששני אלו מעניקים לתהליך נתיב להרשאות root על המארח. מכולה חולקת את ה-kernel של המארח, ולכן גבול הבידוד שלה חלש יותר מזה של מכונה וירטואלית. אם הסוכן מריץ קוד לא מהימן שנמשך מהאינטרנט, העדיפו מכונה וירטואלית (VM) ייעודית או שרת נפרד.

האם הסוכן זקוק ל-sudo על השרת?

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

איך מאפשרים לסוכן לבצע push ל-git מבלי לשמור את מפתח ה-SSH שלי על השרת?

בצעו Forwarding ל-SSH agent שלכם באמצעות ssh -A בעת ההתחברות. בקשות החתימה עוברות דרך החיבור בעוד המפתח הפרטי נשאר על המחשב הנייד שלכם, כך ש-ssh -T git@github.com מבצע אימות ו-git push עובד ללא צורך במפתח פרטי על השרת. הסתייגות: משתמש root על אותו שרת יכול להשתמש ב-socket שעבר Forwarding כל עוד אתם מחוברים, לכן השתמשו ב-deploy key מוגבל למאגר (repository-scoped) בכל מכונה שאתם חולקים עם אנשים אחרים.

איזה גודל VPS נדרש עבור סוכן?

עבודת סוכן מורכבת בעיקר מעריכת קבצים, הרצת build והרצת בדיקות, לכן התאימו את גודל המכונה לצרכי ה-build ולא למודל. מודל מאוחסן רץ על החומרה של הספק, מה שמוסיף תעבורת רשת אך כמעט ללא עומס מקומי. התחילו עם 2 GB RAM לעבודות סקריפטים ועברו ל-8 GB אם המאגר בונה מכולות או מבצע הידור (compile) של משהו משמעותי.

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

בנו מחדש כאשר המצב (state) מפסיק להיות מובן, ולכל הפחות בכל פעם שקיים חשש שפרט אימות (credential) על המכונה נחשף. ביצוע checkout נקי בין משימות מטפל בשינויים מצטברים (drift) יומיומיים, וצילום מצב (snapshot) שנלקח לפני הרצת הסוכן הראשונה יספק לכם תמונת מערכת נקייה לחזרה. אם בנייה מחדש מרגישה יקרה, זה סימן שמשהו חשוב מדי חי על מכונה שהגדרתם כחד-פעמית.