סוכני AI חייבים חוזה תפעולי לפני ממשק גנרטיבי
הכותרת המפתה סביב AG-UI היא שסוכן AI יכול לצייר גרף במקום לכתוב תשובה. החידוש החשוב יותר הוא חוזה התפעול שנוצר בין הסוכן, הממשק והאדם המאשר. בלי חוזה כזה, כל סוכן מוצלח נשאר הדגמה שקשה לנטר ולשדרג. עם חוזה כזה, ממשק הסוכן נעשה יחידת בקרה, ולכן Amazon Bedrock AgentCore מעניין יותר כתשתית ניהול מאשר כמנוע תצוגה.
פרוטוקול AG-UI יוצר חוזה אירועים במקום תלות בקוד הממשק
פרוטוקול AG-UI מייצר זרם אירועים טיפוסי בין הסוכן ללקוח. בחיבור המבוסס בדרך כלל על Server-Sent Events, השרת משאיר ערוץ HTTP פתוח ודוחף דרכו אירועים לפי סדר התרחשותם. כל אירוע נושא סוג, מזהה ריצה ומטען נתונים, למשל התחלת ריצה, מקטע טקסט, קריאת כלי, תוצאת כלי, עדכון מצב או בקשה לקלט אנושי. הקלט מהמשתמש חוזר בבקשה נפרדת ומאפשר לסוכן להמשיך מאותה נקודה. כך הממשק אינו צריך להבין את הלוגיקה הפנימית של Strands או LangGraph, אלא רק לפרש חוזה יציב.
תבנית FAST מחברת שבעה רכיבים מרכזיים: סביבת הריצה AgentCore Runtime, שער, זהות, זיכרון, מפרש קוד, React ו-Cognito. מספר הרכיבים חושף מדוע פיתוח סוכן ארגוני אינו משימת ממשק. המודל הוא רכיב אחד בתוך מערכת שצריכה לשמר זהות ומצב, לבודד סשנים ולתעד פעולות. אותו Parser בצד הלקוח יכול לקרוא אירועים משני מנועי סוכנים, ולכן החלפת מנוע אינה מחייבת בנייה מחדש של חוויית המשתמש.
סוכני AI נכשלים ברגע שבו מצב עסקי ומצב חזותי נפרדים
נניח שמנהל מכירות מבקש מהסוכן לאתר חידושים בסיכון, לחשב הנחה ולהכין הצעות ללקוחות. הסוכן קורא נתוני CRM וחיוב, מציג תרשים סיכון ומבקש אישור לפני שליחת הצעה מעל רף ההנחה. במימוש מותאם אישית, רענון דפדפן עלול למחוק את מצב האישור בזמן שהכלי כבר השלים את החישוב. לחיצה חוזרת עלולה ליצור הצעה כפולה. בזרם אירועים מסודר, הממשק משחזר את מצב הריצה לפי מזהה, מציג את תוצאת הכלי שכבר התקבלה ומחדש את ההמתנה לאישור. כשהמנהל מאשר, נשלח אירוע המשך ולא ריצה חדשה.
בקרת אדם בלולאה צריכה להופיע בנקודות שבהן הפעולה בלתי הפיכה או חורגת ממדיניות. אישור על כל שאילתת CRM רק מחליף עבודה ידנית במסך המתנה. מנהל אחד צריך לפקח על מאות ריצות באמצעות תורים, חריגות וספי הרשאה. ממשק גנרטיבי מועיל כשהוא מרכז את ההחלטות החריגות ומאפשר לשאר התהליך להתקדם עצמאית.
ניהול סוכנים מתחיל בסכמות והרשאות לפני CopilotKit
אפשר לטעון ש-CopilotKit ו-AG-UI מוסיפים שכבת מורכבות במקום לפשט את הפיתוח, במיוחד כשיישום פנימי כולל רק תהליך אחד. הטיעון נכון עבור אב טיפוס קצר. ממשק מותאם עשוי להיות מהיר יותר בשבוע הראשון. אולם העלות מופיעה כשמתווספים סוכן שני, הרשאות שונות או מנוע חלופי. הפרוטוקול גם אינו פותר אבטחת מידע לבדו. רכיב שהסוכן מבקש להציג עדיין דורש אימות סכמה, הגבלת פעולות ותיעוד מלא לפי זהות המשתמש.
כדאי להתחיל את ההטמעה בהגדרת קטלוג אירועים ארגוני עבור AG-UI, לפני בניית התרשים הראשון. כל אירוע עסקי צריך לכלול זהות משתמש, הרשאה, מזהה ריצה וחותמת זמן. יש להגדיר אילו אירועים רק מעדכנים תצוגה, אילו מפעילים כלי ואילו עוצרים לאישור. לאחר מכן צריך לבדוק שלושה כשלים מכוונים: רענון דפדפן באמצע ריצה, תוצאת כלי כפולה ואישור שמגיע ממשתמש חסר הרשאה. העבודה דורשת הבנה טכנולוגית יחד עם ניתוח התהליך העסקי. ארגון שמדלג על החוזה הזה יקבל ממשק מרשים שמסתיר תהליך בלתי נשלט.
