בקצרה
OpenHands מפריד בין ממשק העבודה, שירותי הביצוע והמודל. אירוח עצמי של רכיב אחד אינו מבטיח עיבוד מקומי או בידוד של כל המערכת. החלטה מקצועית צריכה להתבסס על גבולות גישה, תוצרים ניתנים לבדיקה ועלות כוללת לכל משימה שהתקבלה.
יש הבדל גדול בין מודל שמציע תיקון לקוד לבין מערכת שמקבלת משימת פיתוח, פותחת קבצים, מפעילה כלים ומחזירה שינוי למאגר. במקרה הראשון, האדם מחבר בין התשובה לבין העבודה. במקרה השני, הסוכן נכנס אל סביבת העבודה עצמה.
זה המקום שבו OpenHands נעשה מעניין. הפרויקט אינו רק חלון שיחה נוסף למתכנתים. במבנה הנוכחי שלו, Agent Canvas הוא מרכז שליטה לסוכני פיתוח ולתהליכים אוטומטיים, שיכול להתחבר לסביבות הרצה שונות ולהפעיל גם סוכנים תואמים שאינם הסוכן המובנה של OpenHands.
אבל כאן מתחילה גם אי־ההבנה: העובדה שהממשק מותקן על שרת שלכם אינה אומרת שכל המידע נשאר אצלכם, שכל הרצה מבודדת, או שכל משימה עולה אפס. כדי להבין מה באמת מקבלים, צריך לפרק את המערכת לשכבות ולבדוק מי אחראי לכל אחת מהן.
OpenHands כבר אינו רק סוכן שמקבל תיקייה
לפי התיעוד העדכני של הפרויקט, Agent Canvas מתחבר ל־Agent Server שמנהל שיחות, כלים וסביבות עבודה. כשמפעילים אוטומציות, מצטרף גם Automation Server, שאחראי על תזמונים, אירועים ומחזור החיים של הריצות.
ההפרדה הזאת חשובה. הממשק מציג את העבודה; שרת הסוכן מבצע אותה; שירות האוטומציה מחליט מתי להפעיל אותה. אף אחד משלושת התפקידים האלה אינו המודל עצמו. המודל יכול להגיע מספק חיצוני, דרך שירות ניתוב או משרת הסקה מקומי, בהתאם לסוכן ולתצורה שנבחרו.
המאגר הרשמי מתאר תמיכה ב־OpenHands ובסוכנים דוגמת Claude Code, Codex ו־Gemini באמצעות Agent Client Protocol. אין בכך הבטחה שכל יכולת, מדיניות הרשאות או דרך חיוב זהות בין הסוכנים. ההבדלים האלה הם חלק מהתכנון, לא פרט שאפשר לדחות לאחר ההתקנה.
מי שמנסה להבין את החיבורים בין המערכות צריך להפריד בין MCP, ACP ותקשורת בין סוכנים. ממשק שמאפשר לבחור סוכן אינו בהכרח הממשק שמעניק לו גישה למסד הנתונים.
שרת פרטי אינו הגדרה של פרטיות
במערכת סוכנים יש לפחות ארבע שאלות שונות של מיקום: היכן נמצא הממשק, היכן מתבצעות הפעולות, היכן רץ המודל והיכן נשמרים התוצרים והיומנים. אפשר לארח את הראשונה בישראל, את השנייה בשרת אירופי ואת השלישית אצל ספק אמריקאי. זאת עדיין התקנה עצמאית של הממשק, אבל לא מערכת שכל עיבודה מקומי.
אם הסוכן שולח למודל חיצוני קטעי קוד, תוצאות של בדיקות או תוכן של קובץ, המידע הזה יוצא מסביבת העבודה כדי לקבל תשובה. בחירת שרת פרטי אינה משנה את העובדה הזאת. מה שקובע הוא מסלול המידע בפועל, יחד עם תנאי הספק, הגדרות השמירה, החוזים וההרשאות.
גם שימוש במודל מקומי אינו סוף הבדיקה. כלי חיפוש, שירות ניטור, שרת MCP, הורדת תלויות או מערכת מעקב אחר שגיאות יכולים ליצור מסלולי יציאה נוספים. לכן השאלה הנכונה אינה “האם זה self-hosted?”, אלא “איזה מידע עובר בין אילו רכיבים, ולאיזו מטרה?”.
| שכבה | מה אפשר להחזיק בתשתית שלכם | מה עדיין דורש בדיקה |
|---|---|---|
| ממשק העבודה | Agent Canvas והגדרות החיבור | מי יכול להיכנס, ואילו סביבות נגישות ממנו |
| סביבת הביצוע | קובצי הפרויקט, הכלים ותהליכי הבנייה | בידוד, הרשאות קבצים וגישה לרשת |
| המודל | שרת הסקה מקומי, אם נבחר כזה | איכות, זיכרון, תפוקה ותנאי הרישיון |
| מודל חיצוני | בדרך כלל רק הגדרות החיבור נמצאות אצלכם | אילו קלטים נשלחים ומה מדיניות הספק |
| תוצרים ותיעוד | שינויים בקוד, תוצאות בדיקה ויומני עבודה | סודות ביומנים, הרשאות קריאה ומשך שמירה |
“Remote” אינו אומר “מבודד”
בתיעוד Agent Canvas, המונח backend מתייחס לשירותים שאליהם הממשק מתחבר. “Remote” מתאר את אופן החיבור, ולא בהכרח את מקום האירוח. הוא יכול להיות תהליך אחר על אותו מחשב, מכונה בענן או שירות מנוהל.
גם שמות סביבת ההרצה עלולים ליצור תחושת ביטחון מופרזת. תיעוד Process Sandbox אומר במפורש שמצב זה מפעיל את שרת הסוכן כתהליך רגיל, ללא בידוד של ארגז חול. הסוכן יכול לקרוא ולכתוב קבצים ולהפעיל פקודות בהתאם להרשאות החשבון שמריץ אותו.
זו אינה סיבה לפסול את המערכת. זו סיבה להפסיק להתייחס לכל “sandbox” כאל אותה הגנה. תהליך רגיל, מכולה ומכונה וירטואלית הם גבולות שונים. גם בתוך מכולה, מה שקובע הוא מה הועבר אליה: תיקיות, הרשאות, משאבים וחיבורים.
אני מתייחס לשרת פיתוח סוכני כאל מחשב עבודה שמישהו קיבל בו יכולת פעולה רציפה. אם אותו מחשב מחזיק גם מידע של לקוחות, הרשאות ניהול או גישה למערכות הייצור, השפעתה של טעות מתרחבת בהתאם. הדיון המלא נמצא במאמר על אבטחת סוכנים והרשאה לפעול.
מאגר קוד הוא גם מידע שהסוכן צריך לפרש
סוכן פיתוח אינו קורא רק קוד. הוא קורא תיעוד, תיאורי משימות, תגובות, קובצי תצורה ופלטים של כלים. חלק מהמידע עשוי להיות אמין, חלק שגוי וחלק הגיע מגורם שאינו רשאי להחליט מה הסוכן יבצע.
לכן חשוב להפריד בין הוראות העבודה שאושרו לבין תוכן שהסוכן נתקל בו בדרך. קובץ שמציע לשנות הרשאות או לעקוף בדיקה אינו מקבל סמכות רק מפני שהוא נמצא במאגר. אותו עיקרון חל על הצעה שמגיעה מתיאור משימה או מאתר חיצוני.
הבקרה החשובה אינה רק יכולתו של המודל לזהות ניסוח חשוד. היא קיומה של שכבה שמגדירה מראש אילו פעולות וכלים זמינים לו. המודל יכול להציע פעולה; המערכת קובעת אם יש לו סמכות לבצע אותה.
מה כדאי למסור לסוכן פיתוח ראשון?
המשימה הראשונה אינה צריכה להיות “בנה מחדש את המוצר”. היא צריכה לאפשר לבדוק את כל שרשרת העבודה בלי לערבב יותר מדי אי־ודאות.
דוגמה מתאימה היא שינוי בפונקציה קיימת שיש לה חוזה ברור ובדיקות רלוונטיות. הסוכן מקבל את מטרת השינוי, את המגבלות ואת התנאים שבהם התוצאה תתקבל. הוא עובד בעותק נפרד, מציג את השינויים ומצרף תוצאות של בדיקות. ההעברה לענף הראשי נשארת החלטה נפרדת.
לעומת זאת, שינוי רחב במודל הרשאות, העברת נתונים בין מערכות או החלפת תשתית תשלומים מערבים סיכונים ותלויות שקשה לגלות באמצעות בדיקה מקומית אחת. אפשר להיעזר בסוכן גם שם, אך תחילה במשימות מוגבלות: מיפוי, תיעוד, השוואת חלופות או הכנת שינוי לבדיקה.
ההבחנה אינה בין “משימות קלות” ל“משימות קשות”. היא בין תוצאה שאפשר להכריע אם היא נכונה לבין תוצאה שהארגון עדיין לא הגדיר כיצד לבדוק.
שינוי שנבנה בהצלחה אינו שינוי שהתקבל
מערכת יכולה להחזיר הודעה ירוקה גם כשהתוצר אינו מוכן. ייתכן שהקוד מתקמפל אבל משנה התנהגות שלא הייתה אמורה להשתנות. ייתכן שהבדיקות עברו מפני שהבדיקה הבעייתית הוסרה. וייתכן שסביבת ההרצה חסרה רכיב שקיים בייצור.
חבילת מסירה טובה כוללת את ההבדל בקוד, תיאור תמציתי של השינוי, הבדיקות שבוצעו, תוצאותיהן ומה שלא נבדק. חשוב גם לדעת על איזו גרסה נעשתה העבודה ואילו קבצים נמצאים מחוץ לתחום המשימה.
הראיה להשלמת עבודה אינה הצהרת הסוכן, אלא תוצר שאפשר לבדוק. מעבר לכך, האחריות על הקבלה חייבת להיות ברורה. אם כל סוכן מאשר לעצמו את השינוי, נוספה אוטומציה אבל לא נוספה ביקורת עצמאית.
זהו גם ההבדל בין ממשק שיחה נוח לבין ניהול מסודר של עבודת סוכנים: מערכת עבודה צריכה להחזיק מצב, בעלות ותנאי סיום, ולא רק היסטוריה של הודעות.
העלות אינה אפס, גם כשהתוכנה זמינה להתקנה עצמאית
התיעוד של OpenHands מזהיר שהמערכת עשויה לבצע פניות רבות למודל ושהמודלים המחוברים אליה עשויים להיות כרוכים בתשלום. במודל מקומי, החשבונית עוברת לחומרה, לחשמל, לזיכרון ולתחזוקה. היא אינה נעלמת.
מעבר לכך, יש זמן בנייה ובדיקה, אחסון, ניטור וזמן אנושי לבדיקת השינוי. אם משימה חוזרת שלוש פעמים לפני שמתקבל תוצר תקין, מחיר הפנייה הראשונה אינו מדד שימושי.
אפשר לחשב עלות למשימת פיתוח שהתקבלה: סך עלויות המודל, ההרצה והבדיקה האנושית, חלקי מספר המשימות שעמדו בתנאי הקבלה. אין צורך להעמיד פנים שכל רכיב מדויק עד האגורה; גם אומדן עקבי עדיף על ספירת טוקנים בלבד.
דוגמה חשבונית, לא תוצאה ממערכת מסוימת: אם עשר משימות עלו יחד 100 שקלים בשירותי מודל והרצה, אך רק חמש התקבלו, רכיב זה לבדו עולה 20 שקלים למשימה שהתקבלה. אם הבדיקה האנושית עלתה עוד 200 שקלים, העלות הכוללת היא 60 שקלים למשימה שהתקבלה. ההבדל משנה את ההשוואה לתהליך הידני.
לכן בחירת מודל זול יותר יכולה לשפר את הכלכלה, אבל יכולה גם להחמיר אותה אם היא מגדילה תיקונים ובדיקות. כלכלת סוכני AI מתחילה באיכות התוצר ובמספר הניסיונות, לא רק במחירון.
האם חייבים GPU?
לא בהכרח. כאשר משתמשים במודל חיצוני, שרת OpenHands נדרש להפעיל את סביבת העבודה, הכלים והשירותים הרלוונטיים. הוא אינו חייב לבצע בעצמו את חישוב המודל.
GPU נעשה חלק מהדיון כאשר מפעילים הסקה מקומית או כשעומס הפיתוח עצמו דורש אותו. גם אז אי אפשר לבחור חומרה רק לפי מספר הפרמטרים בשם המודל. צריך להבין את הזיכרון הנדרש, אורך ההקשר, מספר השיחות המקבילות וקצב התשובה הרצוי.
יש גם הבדל בין מודל שעולה לזיכרון לבין מודל שמסיים את העבודה באיכות ובזמן המתאימים. התיעוד הרשמי עצמו מציין שונות באמינות השימוש בכלים אצל מודלים מקומיים ופתוחי־משקולות. לכן מבחן של שיחה אחת אינו בסיס לרכישת תשתית לצוות שלם.
איך בודקים כדאיות בלי לבנות הדגמה שנועדה להצליח?
כדאי להתחיל מאוסף משימות שמייצג את העבודה האמיתית: לא רק תיקוני ניסוח, אלא גם שינוי עם תלות בין קבצים, בדיקה שנכשלת, משימה עמומה ומשימה שאמורה להיעצר מחוסר מידע.
לכל משימה מגדירים מראש את אותה גרסת קוד התחלתית ואת תנאי הקבלה. לאחר מכן משווים זמן עד לתוצר שהתקבל, כמות תיקונים, עלות, היקף התערבות והשפעות שלא התבקשו. אם משנים מודל או הוראות תוך כדי, מתעדים זאת כדי שלא להשוות שתי תצורות שונות כאילו היו ניסוי אחד.
המדגם אינו צריך להוכיח שהמערכת טובה בכל שפת תכנות. הוא צריך לענות על שאלה צרה ושימושית: באילו סוגי משימות אצלנו היא משפרת את העבודה, ובאילו היא מגדילה את נטל הבדיקה?
כדאי לכלול גם מסלול לאי־הצלחה: מה קורה כשהמודל אינו זמין, כשהבדיקות אינן מסתיימות או כשמתגלה צורך בהרשאה שלא ניתנה. מערכת שמסיימת יפה משימה פשוטה אבל מאבדת את המצב שלה בכשל הראשון עדיין אינה מערכת עבודה יציבה.
מתי התקנה עצמאית מוצדקת, ומתי לא?
התקנה עצמאית נעשית מעניינת כאשר יש צורך אמיתי לשלוט בסביבת העבודה, לשלב כלים פנימיים, להגדיר גבולות גישה או לשמור תוצרים ויומנים בתשתית מסוימת. היא מתאימה יותר לארגון שיודע מי מתחזק את המערכת ומי מטפל בתקלה.
היא פחות משכנעת כאשר הסיבה היחידה היא “כך לא נשלם על AI”. גם שירות מנוהל וגם התקנה עצמאית דורשים בחינה של עלות, פרטיות ואחריות, אבל הם מחלקים את עבודת התפעול אחרת.
יש גם חלופות עם מרכז כובד שונה. למשל, OpenClaw על שרת פרטי עוסק בסביבת סוכנים וחיבורים רחבה יותר, בעוד OpenHands ממוקד בעולם הפיתוח והעבודה סביבו. הבחירה צריכה להתחיל מהמשימות, לא מהעדפה לממשק מסוים.
השורה התחתונה
OpenHands מאפשר להעביר חלק גדול יותר מעבודת הפיתוח אל מערכת סוכנים שמפעילים בתשתית שנבחרה. זהו שינוי משמעותי, משום שהוא מחבר בין מודל לבין קבצים, כלים, תהליכים ותוצרים.
אבל היתרון אינו “מפתח פרטי בחינם”. היתרון הוא יכולת לתכנן את סביבת העבודה ואת גבולותיה. כדי להפיק ממנו ערך צריך להפריד בין הממשק, המודל וההרצה; למדוד תוצרים שהתקבלו; ולשמור על החלטה ברורה לגבי מה הסוכן רשאי לעשות ומה מחייב בדיקה נוספת.
שרת פרטי נותן יותר שליטה. מערכת טובה מתחילה כשמחליטים מה לעשות עם השליטה הזאת.
שאלות נפוצות
האם התקנת OpenHands בשרת שלי מבטיחה שהקוד לא יוצא ממנו?
לא. אם המודל או כלי עזר פועלים אצל ספק חיצוני, מידע עשוי להישלח אליהם במסגרת העבודה. צריך לבדוק את מסלול המידע, את התצורה ואת תנאי השירות של כל רכיב.
האם סביבת Process Sandbox מבודדת את הסוכן?
לא. התיעוד הרשמי מבהיר שזהו תהליך מקומי ללא בידוד של ארגז חול. הרשאותיו נגזרות מהחשבון ומהסביבה שבהם הוא רץ.
האם אפשר להשתמש בסוכנים אחרים דרך Agent Canvas?
לפי המאגר והתיעוד הרשמיים, כן, לרבות סוכנים תואמי Agent Client Protocol. התאימות לממשק אינה מבטיחה שמדיניות הרשאות, עלויות ותכונות זהות בין הסוכנים.
מהו המדד החשוב ביותר בפיילוט?
משימות שעמדו בתנאי קבלה שנקבעו מראש, יחד עם העלות הכוללת והזמן האנושי שנדרשו להגיע אליהן. מספר ההודעות או שורות הקוד לבדו אינו מוכיח שיפור.