איך ה-computer use של Astra באמת עובד?

לחץ להאזנה

הפוסט הזה תורגם מ-X. המקור והקרדיט ליוצר: How does Astra’s computer use actually work? מאת Kyle Jeong (@kylejeong).

איך ה-computer use של Astra באמת עובד?

כותרת: How does Astra’s computer use actually work?

בשבוע שעבר OpenAI השיקו את GPT‑6 Astra, המודל הכי חכם שלהם עד היום. למרות שהוא מוחץ בנצ׳מרקים של agentic coding ושל alignment, הם בחרו להדגיש יכולת אחת ספציפית: computer use.

ציוץ מוטמע של ההשקה

סרטון ההשקה של המודל הוא המשך של "Put That There", קליפ מ־1979 עם Chris Schmandt ו־Eric Hulteen מ־Architecture Machine Group של MIT (שבהמשך הפך ל־MIT Media Lab). בו הם מנחים מחשב — ניחשתם נכון — לשים "את זה שם" וממקמים צורות על מסך המקרן. נכון לכתיבת השורות האלה, לפוסט יש 131 מיליון צפיות (מה?!).

הרעיון שמחשבים יוכלו להשתמש בעצמם קיים כבר המון זמן. אבל איך Astra כל כך טובה בזה?

בפוסט הזה אני רוצה ללמד אתכם בדיוק איך Astra מצליחה להשתמש במחשב שלכם כל כך ביעילות. קוראים לי Kyle ואני עובד ב־Browserbase, שם אנחנו עובדים על פריסת computer use לפרודקשן כבר שלוש השנים האחרונות.


מה זה בעצם computer use? אני מגדיר את זה כיכולת של AI לשלוט באופן אוטונומי במערכת מבוססת מחשב.

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

היסטוריה קצרה של computer use

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

באוקטובר ’24, Anthropic השיקו computer use עם Claude 3.5 Sonnet. הגישה שלהם הייתה vision-only computer use, כלומר המודל למד איך לתקשר עם מסך המחשב שלכם דרך צילומי מסך. הוא עבר post-training על פיקסלים, והחזיר פיקסל + פעולות בפורמט JSON כזה:

"action": {
    "type": "click",
    "x": 156,
    "y": 50
}

שמתורגמים לאינטראקציות בדפדפן/מחשב באמצעות דרייברים כמו Stagehand או Playwright.

אחרי 3.5 Sonnet, מעבדות אחרות התחילו לשחרר מודלים דומים של computer use שמבוססים על vision ואימנו אותם לזהות פיקסלים על המסך. OpenAI השיקו את Operator ואת computer-use-preview, ו־Google Deepmind הוסיפו computer use ל־Gemini 2.5 Pro (שעזרנו להם לעשות עליו eval).

אבל המודלים האלה לא מושלמים. כי הם עברו post-training על פיקסלים, המעבדות חייבות לבחור viewport ספציפי (למשל 1288 x 711) ולהישאר איתו לאורך כל האימון. כשמשתמשים במודלים האלה בגודל חלון אחר, הם מתפרקים לגמרי — מתחילים לפספס כפתורים והופכים לחסרי תועלת.

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

היו המון ניסויים גם בגישות text-only וגם בסוכני hybrid של DOM + vision. ניסוי מגניב של computer use הוא FDM-1 של Standard Intelligence, שמקודד וידאו (במקום צילומי מסך סטטיים) ל־computer-use.

מה שונה ב־Astra?

כדי להבין למה Astra שונה, נחזור אחורה למשפחת המודלים 5.6 ונדבר על ה־harness של Codex/ChatGPT. Computer use הוא גם בעיית harness (הנדסה) וגם בעיית מודל (מחקר) — המודל מחליט מה לעשות, וה־harness מבצע. כדי לבנות computer use מצוין, צריך לפתור את שניהם.

Computer-use היה "מגניב" כבר די הרבה זמן, אבל עדיין לא הוכיח את עצמו כמוכן לפרודקשן (בעיקר בגלל חוסר האמינות שדיברנו עליו קודם). כש־OpenAI השיקו computer-use באפליקציית Codex, הרבה מפתחים התחילו להשתמש בזה יומיומית ועכשיו מבינים כמה זה יכול להיות חזק.

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

במקום להיות איטי ולא מדויק, computer use ב־Codex באמת מרגיש טוב. הוא הרבה יותר מהיר מ־Atlas (הדפדפן של OpenAI עם CUA מובנה), ויכול לעשות הרבה יותר בזכות כתיבה + הרצה של קוד (לייצר גרפים, לקרוא לכלים אחרים וכו').

Astra לוקחת את היכולות של 5.6 והופכת אותן למהירות וזולות יותר (לפחות על max thinking).

השוואת ביצועים של Astra

כדי להבין את ה־איך, צריך להבין את המבנה של מחשב. היום, רוב המחשבים מציעים GUI (ממשק משתמש גרפי) שאתם ואני יכולים לראות. אנחנו מסתכלים על הפיקסלים במסך ומחליטים על מה ללחוץ (דומה למודלים הישנים). אבל מה אם אתם בכלל עיוורים?

לאנשים עם לקויות ראייה או שמיעה, כל אתר ב־Chrome ורוב המחשבים מציעים איזושהי גרסה של "Accessibility Mode", שממפה הכול על המסך ל־Accessibility Tree (או a11y tree). זה מכריח אפליקציות לחשוף מידע סמנטי על אלמנטי UI, והופך אותם לניתנים לאינטראקציה.

ככה נראה a11y tree בדפדפן:

דוגמה ל-a11y tree בדפדפן

זה הרבה יותר קל למודלים לקרוא, כי זה מסיר את כל הקוד שמגדיר את השכבה הוויזואלית (במקרה של עמוד ווב, זה בעיקר ה־CSS ושמות המחלקות).

ה־a11y tree משתמש בפחות טוקנים מצילום מסך, ובמקביל מספק את אותו קונטקסט של המסך (אם לא טוב יותר). Astra מנצלת את העץ הזה ומשתמשת בו כדי לשלוח פעולות מחשב (לחיצה, הקלדה, לחיצה על מקש). ממש כל אתר ב־Chrome מקבל a11y tree שנוצר אוטומטית, מה שאומר שהם כולם תואמים ל־Astra מהקופסה. (על a11y tree)

הארכיטקטורה

למעשה זה די פשוט.

תרשים ארכיטקטורת computer use של Astra

כשמתחיל סשן של computer use, Codex מפעיל Node REPL למצב הסשן, עם bindings לשימוש בדפדפן או במחשב native. הסוכן בוחר באילו bindings להשתמש לפי המשימה.

גם באפליקציה native וגם בדפדפן, הסוכן צופה בעמוד באמצעות טקסט, צילום מסך, או שניהם — כדי לקבל ייצוג הכי מדויק של המצב. אחר כך הוא בוחר איזו פעולה לבצע באמצעות קוד. כן, computer use עכשיו הוא פשוט code mode. גם בתיעוד ה־API של OpenAI ממליצים על code exec לכל computer use.

זרימת תצפית ופעולה

פלט לדוגמה נראה ככה:

{
  "type": "function_call",
  "name": "exec_js",
  "call_id": "call_123",
  "arguments": "{\"code\":\"await page.getByRole('searchbox').fill('browser automation'); ...\"}"
}

השירות המקומי (בשם CodexComputerUseIPC-5) מבצע את הפעולה. ה־execution wrapper ממיר את בחירת האלמנט ל־ID native של האלמנט (או לקואורדינטות אם המודל בוחר בכך), ואז משתמש ב־pipe transport native עם הודעות JSON-RPC ו־request IDs כדי לפתור ולהשלים את זה.

בפועל, OpenAI ממליצים על Playwright ו־PyAutoGUI כפריימוורקים לשליטה בדפדפן ובמחשב בהתאמה.

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

ואז הלולאה ממשיכה עד שהמשימה שלכם הושלמה. כי computer use הוא stateful מטבעו, ה־Node REPL חייב לשמור את כל הסשן.

בטבלה למעלה, Astra היא המודל היחיד שדורש auto-review. אבל זה לא מה שאתם חושבים. Astra משתמשת ב־Guardian Policy, שבודק פעולות מחשב מוצעות לבטיחות לפני שמרשים להן להתבצע.

Guardian משתמש ב־GPT 5.6 Luna כמסווג ברקע שמעריך את ה־workflow הנוכחי ואת הסיכונים הפוטנציאליים הקרובים, ואז מחזיר high או low. סיווג high מפעיל בדיקה חוסמת על פעולות עתידיות. אחר כך הפעולה עוברת דרך blocking reviewer, שמעריך במלואו את הפעולה המוצעת.

{
  "risk_level": "high",
  "user_authorization": "low",
  "outcome": "deny",
  "rationale": "..."
}

המדיניות מקבלת קונטקסט על הפעולה המוצעת והארגומנטים, ראיות מהשיחה (כולל הרשאת משתמש), סביבת האב וקונטקסט הרשאות, ראיות REPL זמינות ותמונות, ואת בקשת האישור והסיבה שלה. (מקור) טכנית זה לא מובטח שהוא רואה את כל ה־a11y tree, וזה גם לא תמיד נחוץ לסיווג תקין.

אם האצלתם משימות ל־Codex, כנראה נתקלתם בחסימות Guardian הנפוצות האלה:

  • Permission grants: הרשאה ספציפית להרשאה ולנמען
  • Sign-in and consequential account actions: האם המשתמש אישר אותן במפורש
  • Sensitive data submission: הרשאה גם לנתונים וגם ליעד
  • Consequential clicks: מצב הממשק בפועל וההשפעות; קלטים/הגדרות שגויים בטפסים; האם הם תואמים להוראות המשתמש
  • Restriction bypass: האם המסלול החלופי אושר
  • Destructive actions: אובדן מצב משמעותי או נזק בלתי הפיך
  • Out-of-scope private-data access: האם הגישה שייכת למשימה המורשית

בבנצ׳מרקים של alignment, Astra מקבלת ציון משמעותית יותר טוב מהקודמת שלה.

בנצ'מרקים של alignment

אני מהירות

אוקיי, אז אם היא עושה בדיוק אותו דבר כמו GPT 5.6 אבל דורשת עוד בדיקה, איך היא מהירה יותר?

תשובה קצרה: היא חכמה יותר, אז היא לוקחת פחות תורות.

השוואת מהירות ותורות

Astra עברה post-training על 100k GB300s, אז זה לקח המון compute. אבל המודל הרבה יותר חכם ועבר המון RL בסביבות computer use. חכם יותר ← פחות תורות למשימה ← משימה מהירה יותר. במקרה הזה, מהירויות inference הן לא משהו שתראו מיד משפיע על יכולות computer use; בכל דבר מעל 300+ TPS, תיתקעו בצוואר הבקבוק של מהירות ביצוע הפעולה.

היו גם כמה אופטימיזציות harness, כמו websocket prewarming, connection reuse, ו־incremented requests עם previous_response_id, אבל אף אחת מהן לא קשורה למהירות הפעולה עצמה — רק לזמן עליית הכלים.

מצבי כשל נוכחיים

זה באמת טוב, אבל זה לא מושלם. Astra עלולה להיכשל בתצפיות ולקבל מצב a11y חלקי, או צילום מסך בלי מספיק פירוט, או תצוגה ישנה. המצב גם יכול להיסחף בין תצפית לפעולה. בחלק מהאפליקציות ה־a11y tree יכול להשתנות לעיתים קרובות, וזה שובר את הפעולות.

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

החזית של computer use

Computer use רק מתחיל להיות טוב. צפינו בו עובר מכשלונות מתמידים במשימות טריוויאליות, להגיע ליהלומים ב־Minecraft מהר יותר מילד בן 10. אנשים סוף־סוף מבינים כמה הם יכולים להעמיס על AI.

ברגע שהמודלים עברו מ־vision + צילומי מסך לשימוש ב־a11y tree, הם השתפרו משמעותית. יותר compute אומר מודלים טובים יותר ומחירים נמוכים יותר, וככל שנמשיך לדחוף את גבולות ה־post‑training, המודלים ימשיכו להשתפר במשימות ספציפיות לתחום שהמעבדות בוחרות לאמן עליהן.

Astra משלבת מהירות ודיוק עם guardrails חזקים כדי לוודא שהסוכן שלכם לא נחטף. כל איטרציה חדשה של מודלי computer use מקרבת אותנו ל־computer use מוכן לפרודקשן.

העתיד של תוכנה הוא AI שעושה עבודה בשבילכם, כדי שתוכלו להתמקד בבעיות שצריכות מוח אנושי. אם אתם רוצים לפרוס computer use לפרודקשן — אשמח לדבר!

← Kyle


אם התוכן הזה היה מועיל או מבדר בשבילכם, אעריך מאוד follow ו־share. ה־DMs שלי תמיד פתוחים לשאלות או פידבק.

מקורות:

קוד המקור של אפליקציית ChatGPT


Comments

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *