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

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

השאלה האמיתית היא: איפה הסוכן הזה חי כשהוא מפסיק להיות הדגמה?

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

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

כי יש הרבה דיבורים על זה עכשיו

ב-2023 וב-2024 השיחה הייתה מאוד ממוקדת מודל. איזה LLM? כמה הקשר? כמה זה עולה? כמה הוא טוב בתכנות?

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

זה המעבר הטבעי מקסם להנדסה.

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

לא במובן המילולי. במובן ארגוני.

היצירה הראשונה: זמן ריצה שבו הסוכן יכול להחזיק מעמד

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

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

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

עבורי זמן הריצה הסוכן חייב לענות על שאלות מאוד קונקרטיות:

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

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

החלק השני: ארגז חול, כי הסוכן חייב להיות מסוגל להתלכלך מבלי להישבר

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

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

ארגז חול סוכן צריך להיות בעל כמה מאפיינים:

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

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

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

ארגז החול הוא הדרך הבוגרת לומר: קדימה, אבל כאן.

החלק השלישי: MCP ובעיית המחבר

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

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

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

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

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

בארכיטקטורה סוכן טובה, MCP הופך לסוג של פאנל תיקונים:

• GitHub עבור קוד ובעיות;
• רפיון עבור הקשר שיחה;
• ליניארי או Jira לעבודה מתוכננת;
• מסד נתונים לקריאה בלבד לניתוח;
• דפדפן או מגרד נשלט עבור אתרים חיצוניים;
• אחסון מסמכים;
• סביבות ביצוע מבודדות;
• מערכות פנימיות חשופות עם הרשאות קפדניות.

החלק המסובך הוא שקטלוג כלים נטול מדיניות הוא רק דרך אלגנטית יותר ליצור כאוס.

היצירה הרביעית: זהות והרשאות

זה האזור שבו הדגמות רבות מעלימים עין.

סוכן פועל בשמו של מישהו. אז חייב להיות ברור מי נושא הפעולה.

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

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

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

המשמעות היא OAuth, היקף אסימון, ניהול סודי, יומן ביקורת, מדיניות כלים, רשימת היתרים, שלב אישור. דברים לא רומנטיים במיוחד. דברים הכרחיים.

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

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

ישנם לפחות שלושה סוגי זיכרון:

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

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

סוכן שזוכר רע גרוע יותר מסוכן שלא זוכר. כי הוא מדבר בביטחון.

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

היצירה השישית: צפייה, eval ושידור חוזר

אם סוכן עושה טעות, יומן "נקרא למודל" אינו מספיק.

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

כאן הסוכנים דומים יותר למערכות מבוזרות מאשר לצ'אטבוטים.

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

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

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

היצירה השביעית: ממשקים אנושיים

הסוכן לא צריך לחיות רק בצ'אט.

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

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

תשתית סוכנים הגונה כוללת משטחי בקרה:

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

זה נראה טריוויאלי, אבל זה לא. ההבדל בין "AI מצמרר" ל"עוזר אמין" הוא לרוב רק שהאחרון מראה לך היכן יש לו ידיים.

המחסנית המנטאלית

אם הייתי מצייר את זה היום, ערימת הסוכן המינימלית תהיה כזו:

1. מודל: הגיון, דור, קריאת כלי, מולטימודאלי במידת הצורך.
2. תזמור: לולאה, שלב, מתכנן, מדיניות, אנושי-בלולאה.
3. זמן ריצה עמיד: זרימת עבודה, תור, ניסיון חוזר, השהה, המשך.
4. ארגז חול: ביצוע קוד, מערכת קבצים מבודדת, מגבלות, חפצים.
5. שכבת כלי: MCP, API פנימי, דפדפן, מסד נתונים, מאגר.
6. שכבת זהות: OAuth, scope, סוד, ביקורת, מדיניות.
7. שכבת זיכרון: הקשר פרויקט, שליפה, הוראות, תפוגה.
8. צפיות: מדדי מעקב, שידור חוזר, הערכה, עלות ואיכות.
9. משטח מוצר: צ'אט כשמספיק, לוח מחוונים כשצריך, סקירה כשזה חשוב.

המסגרת האגנית מכסה בעיקר את נקודות 2 וחלק מנקודה 1. השאר הוא העבודה האמיתית.

מה הייתי עושה בפועל

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

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

אז הייתי מציב גבולות מאוד ברורים:

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

רק אז ארחיב.

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

הקריאה שלי

תשתית סוכן משעממת בצורה הטובה ביותר.

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

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

שם סוכנים מפסיקים להיות צעצוע והופכים לתשתית.

מקורות

• Vercel: כיצד לבנות סוכני AI עם Vercel ו-AI SDK
• Vercel Docs: Sandbox
• Vercel Docs: Working with Sandbox
• Vercel Docs: MCP
• Protocol Context Model: Specification
• OpenAI: כלים חדשים לסוכני בנייה
• בלוג Cloudflare: סוכנים ב-Cloudflare