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

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

תן לסוכן קידוד מכונה וירטואלית (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 "$BUILD_DIR"/* עם BUILD_DIR לא מוגדר, שמתרחב ל-/* וחומק מהסירוב המובנה של GNU rm למחוק את / עצמו, 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 מקומית. כלים בקטגוריה זו מריצים מכונה וירטואלית מלאה על החומרה שלך, ממפים לתוכה את ה-repository, ומעניקים ל-agent הרשאות root בתוכה. clawk הוא הדוגמה העדכנית, והטיעון שלו הוא בדיוק התזה של פוסט זה: ספקו ל-coding agents מכונת Linux חד-פעמית, לא את המחשב הנייד שלכם. נכון לאוקטובר 2026, הוא מיועד ל-macOS 14 ומעלה על גבי Apple silicon, עם תמיכה ניסיונית ב-Linux דרך Firecracker, וההתקנה מתבצעת באמצעות brew install clawkwork/tap/clawk. מריצים clawk בתוך ה-repository כדי להעלות את ה-sandbox ולחבר את ה-agent, את clawk down כדי לעצור אותו, ואת clawk destroy כדי להסיר אותו. המחיצה היא hypervisor, והיא חזקה. המגבלה היא שה-VM חיה על המכונה שאתם נושאים עמכם, לכן היא צורכת את הזיכרון שלכם ונעצרת כשסוגרים את המכסה.

Container. ‏Docker הוא הפתרון שרוב האנשים כבר התקינו, והוא שימושי מאוד.

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

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

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

תבנית ה-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 ls /home/you

אתם אמורים לראות ls: cannot open directory '/home/you': Permission denied. אם אתם רואים רשימת קבצים, סימן שתיקיית הבית שלכם ניתנת לקריאה על ידי משתמשים אחרים, והסוכן יוכל לקרוא כל דבר בתוכה שאינו נעול בנפרד, כמו קובץ .env שפתוח לקריאה לכל. תקנו זאת באמצעות sudo chmod 700 /home/you. בדיקה זו אינה מגנה על מפתח ה-SSH הפרטי שלכם: ssh מתעלם מקובץ מפתח פרטי שמשתמשים אחרים יכולים לגשת אליו, כך שכל מפתח שבאמת עובד עבורכם כבר אינו קריא ל-agent, ללא קשר להרשאות של תיקיית הבית שלכם.

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

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

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

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

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

FAQ

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

עבור רוב המשימות, כן, בתנאי שמתקיימים שני תנאים. אסור להריץ את המכולה עם --privileged, ואסור לבצע mount ל-/var/run/docker.sock בתוכה, כיוון ששניהם מעניקים לתהליך נתיב להשגת הרשאות root על המארח (host). מכולה משתפת את ה-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 בכל מכונה שאתם חולקים עם אנשים אחרים.

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

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

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

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