Microsoft השיקה את Foundry Toolbox ואת תכונת הלוויה שלה, Tool Search, שירות בעל נקודת קצה אחת (single-endpoint) המאפשר למפתחים לחבר סוכני AI למאות כלים מבלי לחבר כל סוכן באופן פרטני. Tool Search הפחית את טוקני הקלט בשיעור של עד 94% כאשר הקטלוג הכיל יותר מ-600 כלים.

למה ארגז כלים מרכזי הוא חשוב

סוכני AI זקוקים ליכולות חיצוניות — מסדי נתונים, מערכות CRM, פלטפורמות אנליטיקה — כדי למלא בקשות משתמשים. עד כה, ארגונים רבים חיברו כל סוכן ישירות ל-APIs הנדרשים. מהנדסים חזרו על הגדרות אישורים (credentials), אכיפת מדיניות וקוד לטיפול בשגיאות עבור כל סוכן חדש. התוצאה הייתה רשת מסובכת של הגדרות כפולות שהיה קשה לבקר וחשופה לפרצות אבטחה.

Foundry Toolbox מחליף את הטלאי הזה בשכבת שירות מאוחדת. במקום תריסר סוכנים שכל אחד מהם מפנה ל-12 נקודות קצה נפרדות, כל הסוכנים מדברים עם נקודת קצה אחת של "toolbox". ה-toolbox מנהל את ניהול הגרסאות (versioning), מחרוזות החיבור (connection strings) ומדיניות האבטחה, מה שמאפשר לצוותים לנהל את כל המערכת האקולוגית של הכלים ממקום אחד. ארגונים המריצים עשרות סוכנים ביחידות עסקיות מרובות רואים ירידה מיידית בעומס התפעולי.

קטלוגי כלים גדולים יוצרים עלות נסתרת: שימוש בטוקנים. כאשר מודל שפה מקבל הנחיה (prompt) המפרטת כל כלי זמין, חלון ההקשר (context window) מתנפח וצורך טוקנים שניתן היה להשתמש בהם לצורך הסקה (reasoning) או בטקסט המופנה למשתמש. Tool Search תוקף את הבעיה מהשורש.

כאשר סוכן מפעיל את Tool Search, המודל קורא תחילה לכלי-על (meta-tool) בשם tool_search, ומתאר באנגלית פשוטה מה הוא צריך (למשל, "find the latest sales forecast for region X"). השירות מחזיר רשימה קצרה ומדורגת של כלי מועמדים התואמים לכוונה. לאחר מכן, המודל מפעיל את call_tool, ובוחר את הרשומה המתאימה ביותר מתוך הרשימה הזו. על ידי חשיפת תת-קבוצה רלוונטית בלבד, ה-prompt נשאר קטן מאוד, מה שחוסך עד 94% מטוקני הקלט במבחן ביצועים של 600 כלים.

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

איך להפיק את המרב מארגז הכלים

  • כתבו מטא-דאטה מצוין – Tool Search מסתמך על השם והתיאור של כל כלי. תוויות מעורפלות כמו "Get data" משאירות למודל מעט מאוד חומר לעבוד איתו. כותרות מפורטות כמו "Retrieve customer renewal risks and contacts" מכוונות את מנוע החיפוש להתאמה הנכונה.
  • נעצו כלים בשימוש תדיר – אם סוכן זקוק תמיד לכלי מסוים בכל תור, נעצו את הכלי הזה בהגדרות הסוכן. נעיצה (pinning) מדלגת על שלב החיפוש, מה שמפחית שיהוי (latency) וצריכת טוקנים.
  • ארגנו לפי יכולת – במקום ארגז כלים מונוליטי המכסה את כל הארגון, חלקו את הכלים לקבוצות לוגיות (למשל, sales-tools, CRM-tools). קבוצות קטנות יותר מגבילות את רדיוס הפגיעה (blast radius) של הגדרות שגויות ושומרות על תוצאות חיפוש ממוקדות.
  • בחנו לפני פריסה – גרסאות ה-toolbox הן בלתי ניתנות לשינוי (immutable); ברגע שגרסה מוגדרת כברירת מחדל, כל הסוכנים מתחילים להשתמש בה. השתמשו בנקודת הקצה למפתחים כדי לאמת גרסה חדשה בבידוד לפני הפריסה לכלל החברה.

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

בשורה התחתונה: Foundry Toolbox ו-Tool Search מעניקים לפריסות AI גדולות דרך לאלף את התפשטות הכלים, לצמצם בזבוז טוקנים בשיעור של עד 94% ולאכוף מדיניות אבטחה עקבית — וכל זאת על ידי הוספת שכבת שירות אחת ומנוהלת היטב. צוותים שיכולים להרשות לעצמם את ההגדרה הראשונית ואת המשמעת של ניהול המטא-דאטה צפויים ליהנות ממערכת אקולוגית של סוכנים רזה וידידותית יותר לשליטה.