בפוסט אורח שפורסם בבלוג של n8n ונכתב על ידי סונדאר ראגהוואן (Sundar Raghavan), מוביל Agentic AI Foundations ב-AWS, הוצגה דרך לבניית צוותי סוכני בינה מלאכותית (Multi-Agent Teams) מבוססי n8n ו-Amazon Bedrock AgentCore. המערכת מאפשרת לסוכנים שונים לחלוק זיכרון משותף פר לקוח, כך שסוכן אחד מסוגל להמשיך שיחה על בסיס הנתונים שנאספו על ידי סוכן אחר באותו תהליך עבודה, מבלי להקים מסד נתונים וקטורי ומבלי לפרוס תשתית נפרדת לכל סוכן.
האתגר בשיחות תמיכה מרובות סוכנים
בתרחיש תמיכה המתואר בפוסט, סוכן מיון (Triage Agent) מנתב פנייה של לקוח למומחה מתאים (למשל מומחה אינטגרציות). בתרחיש כזה, המומחה השני אינו מחזיק בהקשר של ההודעה הראשונה שהלקוח שלח ארבעים שניות קודם לכן.
כדי להתמודד עם בעיה זו קיימות שתי גישות מוכרות: העברת כל תמליל השיחה לכל סוכן – פתרון שמוגבל על ידי חלון ההקשר (Context Window) של המודל – או שמירת היסטוריית השיחה במסד נתונים וקטורי, דבר שדורש ניהול תשתית מסד נתונים וצינור עיבוד של הטמעות (Embeddings). הפתרון המוצג בפוסט מציע חלופה שלישית המבוססת על יכולות הזיכרון המנוהל של Amazon Bedrock AgentCore harness, שהפך לזמין באופן כללי (GA).
כיצד פועל הזיכרון המשותף ב-AgentCore harness
Amazon Bedrock AgentCore הוא פלטפורמה לבנייה, חיבור ואופטימיזציה של סוכנים בכל מסגרת (Framework) או מודל. הרכיב AgentCore harness מספק מעטפת מנוהלת סביב מודל השפה: המשתמש מגדיר את הסוכן בתצורה (כולל המודל, הכלים, המיומנויות וההוראות), וה-harness מנהל את לולאת ההפעלה (Agent Loop).
המערך נשען על שני מאפיינים מרכזיים:
- זיכרון מנוהל (Managed Memory) לפי מזהה ישות ומפגש: הזיכרון מוגדר לפי Actor ID ו-Session ID. כאשר מגדירים Actor ID המייצג את הלקוח ולא סוכן בודד, כל הסוכנים יכולים לקרוא מאותו מאגר זיכרון ולכתוב אליו. זיכרון זה ממשיך להתקיים גם מעבר להרצה בודדת של תהליך העבודה ב-n8n.
- הענקת כלים לפי קריאה (Per-Invocation): הכלים, המיומנויות, המודל וההוראות מועברים עם כל קריאה ולא נקבעים באופן קבוע על גבי סוכן פרוס. כתוצאה מכך, משאב harness יחיד משרת ארבעה תפקידי מומחים שונים במקום פריסה של ארבעה משאבים נפרדים.
מבנה תהליך העבודה ב-n8n
תהליך העבודה המוצג מורכב מעשרה צמתים (Nodes) ב-n8n:
- קבלת הודעה: הצומת When Chat Message Received מקבל את פניית הלקוח.
- הגדרת הקשר: הצומת Set Customer Context ממיר את מפגש הצ'אט למזהה לקוח, ומשדר אותו כ-Actor ID ו-Session ID לכל הסוכנים.
- מיון וניתוב: הצומת Triage Agent קורא את הפנייה, מחזיר סיווג בפורמט JSON, הצומת Read Triage Decision מפענח אותו, והצומת Route To Specialist מנתב את השאלה לאחד משלושה מומחים:
- מומחה ניתוח (Analysis Specialist) המחזיק בכלי AgentCore Code Interpreter לצורך חישובים מתמטיים בסביבת Sandbox.
- מומחה ארכיטקטורה (Architecture Specialist) המחזיק בקטלוג המיומנויות של AWS לקבלת הנחיות תכנון.
- מומחה מחקר (Research Specialist) המשתמש בכלים מובנים (Shell ו-file_operations) הקיימים בכל מפגש של ה-harness.
- החזרת תשובה: הצומת Format Reply מעבד את התשובה והצומת Post Answer To Slack מפרסם אותה בערוץ Slack כשהיא מתויגת בשם המומחה שיצר אותה.
חלוקת האחריות בין המערכות ברורה: n8n מנהל את הטריגר, החלטות הניתוב והתשובה; AgentCore מנהל את לולאת הסוכן ואת הזיכרון שנשמר מעבר להרצת תהליך יחיד, ומריץ כל מפגש בתוך microVM מסוג Firecracker ללא שיתוף מצב (State) או מערכת קבצים. התעבורה מ-n8n ל-AWS היא יוצאת בלבד (Outbound), וחתומה באמצעות מנגנון SigV4.
דרישות מוקדמות והגדרת זהויות IAM
לפני הרצת התבנית, יש להכין את הרכיבים הבאים:
- מופע n8n (בגרסת שירות עצמי או n8n Cloud).
- צומת הקהילה המאומת
@aws/n8n-nodes-agentcoreמותקן ב-n8n (הצומת ברישיון קוד פתוח MIT, כאשר AgentCore harness עצמו מופעל באמצעות Strands Agents מבית AWS). - חשבון AWS עם גישה ל-AgentCore harness באזור (Region) נתמך.
- מודל בסיס מופעל ב-Amazon Bedrock (למשל מודל Claude), כאשר הגישה למודלים מוגדרת לפי דרישה (Opt-in) פר חשבון ואזור.
- שני מזהי AWS IAM נפרדים: זהות הקורא (Caller) שמפתחות הגישה שלה מוזנים בהרשאות של n8n, ותפקיד הביצוע (Execution Role) שבו הסוכן רץ בפועל ב-AWS וזקוק להרשאות למודל, ל-Code Interpreter, לקטלוג המיומנויות ולזיכרון.
- אישורי גישה ל-Slack לשליחת התשובה (אופציונלי).
מבחינת עלויות, אין חיוב נפרד עבור ה-harness עצמו. התשלום מתבצע על פי השימוש ביכולות AgentCore שמופעלות, והזיכרון המנוהל כרוך בתעריפי AgentCore Memory הרגילים עבור אירועים לטווח קצר, רשומות לטווח ארוך ובקשות שליפה.
הדגמת תרחיש: תלונת חיוב והנחיות ארכיטקטורה
במהלך הבדיקה שתוארה בפוסט:
- חישוב נתונים: הלקוח שאל לגבי חריגה ממגבלת 50,000 קריאות API ביום וסיפק חמישה מספרים מיומני השימוש שלו. סוכן המיון סיווג את הפנייה כניתוח והעביר אותה למומחה הניתוח. המומחה הריץ קוד Python באמצעות AgentCore Code Interpreter בסביבת Sandbox, חישב ממוצע של 50,520 (חריגה של 520 קריאות או 1%), והחזיר תשובה המבוססת על הרצת הקוד.
- שאלת המשך ללא חזרה על נתונים: הלקוח שאל כיצד לתכנן מחדש את המערכת כדי למנוע חריגות, מבלי לציין שוב את המספרים. סוכן המיון ניתב את השאלה למומחה הארכיטקטורה, אשר השתמש בקטלוג המיומנויות של AWS. מומחה זה קרא את נתוני השימוש ישירות מהזיכרון המשותף של הלקוח תחת אותו Actor ID, מבלי שהלקוח נדרש לספקם שוב ומבלי שהמומחים תוכנתו להכיר זה את זה ישירות.
- שאלת מידע כללי: שאלה על שעת איפוס המגבלות נותבה למומחה המחקר, שפעל באמצעות הכלים המובנים בכל מפגש.
אפשרויות הרחבה וניקוי משאבים
משתמשים יכולים להרחיב את התבנית באמצעות:
- הפעלה באמצעות Slack Trigger או Webhook עבור סביבות ייצור.
- שילוב סוכנים קיימים שנוצרו דרך ה-CLI, הקונסולה, CloudFormation או Terraform על ידי הזנת ה-ARN שלהם בצומת.
- הוספת מומחים נוספים עם שרתי Model Context Protocol (MCP) מרוחקים, AgentCore Gateway לגישה מבוקרת לממשקי ה-API שלכם (your own APIs), או AgentCore Browser.
בסיום הבדיקה, כיוון שה-harness מקצה מאגר זיכרון מנוהל בחשבון AWS, מומלץ למחוק את משאב ה-harness שנוצר (למשל support_team) דרך ממשק ה-CLI של AWS באמצעות הפקודה aws bedrock-agentcore-control delete-harness כדי למנוע עלויות מתמשכות.