Azure AI Foundry Threads

כשפורסים בינה מלאכותית ב-Azure AI Foundry, לא מפעילים רק מודל שעונה על שאלות. מציבים אותו בסביבת הרצה מנוהלת, שבה כל פעולה, הודעה, קריאה לכלי ושלב ביצוע מתועדים ואפשר לעקוב אחריהם. השרשורים (Threads), ההרצות (Runs) ושלבי ההרצה (Run Steps) יוצרים יחד עקבות שמאפשרים לבקר את פעולת הסוכן ולהתאים אותו לדרישות של ארגון.

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

סוכן AI ב-Azure AI Foundry: מודל, הוראות וכלים

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

המודל – המוח

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

ההוראות – פקודות המשימה

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

הכלים – הציוד

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

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

אתם גם לא כבולים למודל אחד. אפשר להחליף מודלים בקטלוג של Foundry: GPT 4 לאסטרטגיה מורכבת, מודל רזה יותר למשימות קלות, או מודלים כמו Mistral ו-DeepSeek. כך הסוכן יודע להסתגל למשימה, ואתם בוחרים את המודל שמתאים לה.

מה קורה כשהשכבות חסרות: סיכונים וחסמי אימוץ

בלי המבנה הזה הבעיות מופיעות מהר, ובארגון הן לא עניין זניח.

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

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

שרשורים (Threads): יומן המשימה של הסוכן

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

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

הודעות: יותר מטקסט

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

למי זה עוזר

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

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

הרצות ושלבי הרצה: מהיומן לביצוע ולמעקב

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

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

הרצה אינה קופסה שחורה

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

שלבי הרצה: רישום מהלכים

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

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

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

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

כלים ואינטגרציה ארגונית: MCP, Logic Apps ואבטחה

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

1. כלים מובנים

הכלים המובנים כוללים את מפרש הקוד, חיפוש Bing, מחברי SharePoint ו-Microsoft Fabric, ו-Azure AI Search. בעזרתם הסוכן מנתח נתונים, שולף קבצים, מחפש בתוכן ארגוני ומפיק תרשימים ודוחות בלי התאמות אישיות.

2. כלים מותאמים אישית

אפשר לרשום כלים באמצעות מפרטי Open API או פרוטוקול MCP (Model Context Protocol). MCP מתואר כמו USB-C של כלי בינה מלאכותית. במקום לכתוב ידנית מעטפות בכל פעם שמחברים סוכן לשירות MCP מרוחק, המערכת מטפלת אוטומטית בגילוי כלים, בניהול גרסאות ובהפעלה. זה מקל על האינטגרציה, במיוחד כשבסביבה יש עשרות מערכות לחבר.

3. כלים הניתנים לצפייה

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

דוגמה מעשית

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

חיבור למערכות הארגון ואבטחה

כלים יכולים להתחבר ל-Logic Apps, וכך הסוכן ניגש ליותר מ-1,400 מחברים קיימים של SaaS ומערכות מקומיות. במקום לקודד מחדש אינטגרציות לפלטפורמות CRM, ERP או ITSM, מגדירים אותן מול מחברים שהעסק כבר מריץ, בלי גשרי API שבירים.

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

טיפים מעשיים להתחלה

• הגדירו לכל סוכן שלושה מרכיבים במפורש: מודל, הוראות וכלים.
• כתבו הוראות כספר חוקים: משימה ברורה, מקור נתונים ופורמט דיווח.
• התאימו את המודל למשימה: מודל חזק לאסטרטגיה מורכבת, מודל רזה למשימות קלות.
• הסתמכו על שרשורים כמסלול ביקורת, ולא על צילומי מסך או זיכרון.
• בדקו את סטטוס ההרצה, ובמקרה של תקלה עברו על שלבי ההרצה בציר הזמן.
• חברו מערכות חיצוניות דרך MCP, מפרטי Open API או מחברי Logic Apps, וודאו שההרשאות נשארות בתוקף.
• התחילו בפרויקט בדיקה: צרו סוכן בסיסי, הריצו שרשור ובדקו את שלבי ההרצה ב-SDK או בפורטל, כדי לוודא שהיומנים תואמים למה שציפיתם.

סיכום

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