סוכנים הם רק קבצים: איך הסוכן החדש של Gemini מחליף קוד ב-markdown

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

אותו סוכן, שלוש בנייות, פחות קוד בכל פעם

ההרצאה נפתחה בהגדרה של סיימון וילסון לסוכן: מודל שפה שמריץ כלים בלולאה עד שהוא משיג מטרה. כדי להמחיש את הרעיון, הדובר בנה מחדש סוכן אחד ל-review של pull requests ב-GitHub, שלוש פעמים נפרדות, וכל גרסה מחקה יותר קוד מקודמתה. בגרסה השלישית כבר לא נותרה תיקיית קוד לסוכן בכלל - רק קובץ markdown עם הוראות וסקריפט bash קטן.

גרסה ראשונה: לולאת Python

הבנייה הראשונה היא הגישה הקלאסית מלפני בערך שנה וחצי. מחלקת Python מריצה את הלולאה, JSON schema מגדיר כל כלי, פונקציית Python מממשת אותו, והקוד בודק כל תשובה של המודל כדי להחליט אם זו קריאה לפונקציה או תשובת טקסט רגילה לפני שהוא מחליט מה לעשות הלאה. זה עובד, אבל הכל צריך להיות מוגדר ביד: הסכמות, הניתוב, הניסיונות החוזרים, ה-state.

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

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

גרסה שנייה: framework לסוכנים

הבנייה השנייה החליפה את ה-Python הגולמי ב-ADK של גוגל, framework לסוכנים שמנהל בעצמו את לולאת הכלים, ניתוב קריאות הפונקציות, ניסיונות חוזרים, וטיפול בשגיאות. הוא אפילו גוזר את ה-JSON schema של כל כלי ישירות מהחתימה של פונקציית Python במקום לדרוש לכתוב אותה בנפרד. קטגוריות שלמות של boilerplate פשוט נעלמו.

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

גרסה שלישית: סוכן מרוחק שמנהל לעצמו sandbox

בבנייה השלישית תיקיית המקור נעלמת לגמרי. במקומה: קובץ AGENTS.md עם הוראות, וסקריפט bash קטן שמתקין את ה-GitHub CLI אם הוא עדיין לא שם. בלי סכמות לכלים. בלי פונקציות Python לקריאת pull request. רק הערה שאומרת לסוכן שיש לו GitHub CLI, כלי bash, ומערכת קבצים, ושכדאי לו להשתמש בהם.

זה הסוכן Antigravity, סוכן מנוהל וכללי שזמין עכשיו דרך Gemini API, ורץ על אותו harness שמפעיל את הסביבה Antigravity IDE (סוכן ממוקד קידוד, לא אותו דבר בדיוק, רק בנוי על אותו בסיס). מה שהופך את הגרסה הזו לשונה הוא פרמטר "environment" חדש: במקום ארגז כלים קבוע, הסוכן מקבל sandbox מבודד של Linux, מתארח אצל גוגל, שבו הוא יכול להריץ פקודות bash, להתקין מה שהוא צריך, ולשמור קבצים. אפשר להצביע לסביבה הזו על מאגר GitHub, bucket ב-Cloud Storage, או קבצים inline כמקורות.

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

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

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

מה זה משנה לגבי הרחבת סוכן

להוסיף יכולת חדשה לשתי הגרסאות הראשונות פירושו לכתוב פונקציית Python, לבנות ביד סכמה בשבילה, ולחבר אותה לרשימת הכלים. להוסיף יכולת לגרסה השלישית זה בדרך כלל לכתוב קובץ markdown. רוצים שהסוכן יריץ סריקת אבטחה על pull request? תגידו לו באיזה כלי CLI להשתמש, או פשוט שימו את הכלי הזה בתוך ה-sandbox. בלי שינוי קוד, בלי redeploy, רק עוד קובץ שהסוכן יקרא.

כמה דוגמאות אמיתיות שעלו בהרצאה הופכות את הדפוס הזה לפחות תיאורטי. בכנס AI Engineer באירופה, Cursor תיארו איך החליפו בערך 12,000 שורות TypeScript שנכתבו ביד לתזמור של git worktrees בערך ב-200 שורות של קבצי הוראה לסוכן. Manus בנתה מחדש את ה-harness של הסוכן שלה חמש פעמים נפרדות במשך שישה חודשים בשנה שעברה. framework מוכר ל-open deep research עבר שלוש כתיבות מחדש של הארכיטקטורה בתוך שנה אחת. Windsurf קיצצה 80 אחוז מרשימת הכלים שלה וקיבלה פחות שלבים, תגובות מהירות יותר, ודיוק טוב יותר ממה שנשאר.

כלל האצבע שנשאר איתי מההרצאה: אם ה-harness שלכם ממשיך להיות מסובך יותר ככל שהמודל הבסיסי משתפר, זה סימן שאתם עושים over-engineering, לא סימן שהבעיה קשה.

סוכנים שכותבים לעצמם הערות

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

מה נשאר מזה

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