הגדרת פרוטוקול A2A: אינטגרציה של סוכני בינה מלאכותית ללא כאב

מדוע סוכנים לא מגיעים להסכמה: היכן נשבר Agent-to-Agent Protocol

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

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

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

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

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

Agent-to-Agent Protocol סוגר בדיוק את השכבה הזו: לכל סוכן יש תפקיד מוצהר וחוזה הודעה, המשימה מקבלת מזהה ומצב, והתשובה — אישור מסירה. נבחן ממה מורכבת אינטגרציה של סוכני AI שלא מתפוררת בצעד השלישי.

מה נותן אינטראקציה מנוהלת בין סוכנים במתאר העבודה

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

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

שיעור המשימות שמגיעות לסוף בלי התערבות ידנית עולה מ-~70% ל-95% — הודות לחזרות עם שמירת מצב ביניים ולבדיקות מפורשות של התוצאה בכל צעד.

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

מתאר כזה מתואר במפרט הפתוח Agent-to-Agent, שפיתוחו מנוהל על ידי Linux Foundation: הלקוח אינו נקשר לספק סוכנים אחד ומחליף מבצע בלי לבנות מחדש את האורקסטרציה כולה.

מצבי הפעולה של Agent-to-Agent Protocol והמגבלות שלהם

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

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

ארבעה מצבי העברה

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

שלבי היישום: מסקר סכמה ועד מסירה לתפעול

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

1. סקר סכמת הסוכנים. מפרקים את הסוכנים הקיימים, את תחומי האחריות שלהם ואת דרכי ההעברה הנוכחיות. בפלט — מפה: מי פונה למי, אילו נתונים מועברים והיכן כעת הולך לאיבוד ההקשר.
2. תכנון ההעברה. קובעים את מבני ההודעות, כללי הזיהוי של משימות וההתנהגות כשלשכן אין זמינות. את ההעברה בונים על Agent-to-Agent Protocol — תקן פתוח, ולכן לא יהיה צורך לשכתב את הסכמה בעת החלפת מודלים או ספקים.
3. הגדרת הניתוב וההרשאות. קובעים מי רשאי להאציל משימה למי, אילו קריאות אסורות ובאילו מגבלות הסוכן עוצר בעצמו, בלי לשאוב משאבים מהאחרים.
4. הרכבה במתאר בדיקות. מחברים את הסוכנים על עותק של נתונים אמיתיים ומריצים תרחישים שגרתיים ותרחישי חירום: ניתוקי קשר, כפילויות, מסירה חוזרת.
5. קבלת האינטגרציה תחת עומס. בודקים איך הסכמה מחזיקה בזרימת שיא ומה קורה כשצומת אחד כושל. הקריטריונים מדידים: שיעור ההעברות המוצלחות, זמן התגובה, שיעור המשימות שהגיעו לתוצאה.
6. מסירה לתפעול. מוסרים תקנונים, סכמות מסלולים, לוחות ניטור ונוהל טיפול באירועים. צוות הלקוח משנה מסלולים ומוסיף סוכנים בלעדינו.

ארטיפקטים של הפרויקט: מרשם סוכנים, סכמות ומדיניות גישה

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

אנחנו מוסרים לא «שירות עובד כמו שהוא», אלא תצורות, סכמות ותקנונים שלפיהם הצוות שלכם בעצמו משנה את הקשרים בין הסוכנים ואת זכויות הגישה — בלעדינו וללא בנייה מחדש של האינטגרציה לפי Agent-to-Agent Protocol. להלן רשימה של מה שנשאר פיזית אצל הלקוח.

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

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

מקרה בוחן: שרשרת של שבעה סוכנים — מדדים לפני ואחרי

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

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

מה שינינו

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

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

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

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

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

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

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

ספקות טכניים נפוצים לפני אינטגרציה של סוכנים

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

מה יקרה אם סוכן בשרשרת אינו זמין?

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

איך להבין באיזה צעד נשברה השרשרת?

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

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

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

נדון במשימה ונחזור עם הערכה ותוכנית עבודה

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

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

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

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