Copilot Studio או Teams Toolkit: באיזה כלי לבחור לסוכני Copilot?

פריסת Microsoft 365 Copilot מרגישה לפעמים כמו קבלת פריט אגדי שמגיע רק עם ערכת התחלה. ישר מהקופסה Copilot נשען על ידע בסיסי של המודל ועל התוכן שבתוך הדייר שלכם. זה שימושי, אבל הוא לא מכיר את ספר ההדרכה של משאבי אנוש, את מערכת ה-ERP הישנה שבפינה או את מסמכי המדיניות הנעולים בתיקייה. בלי מחברים, ביסוס (grounding) וסוכנים מותאמים אישית, Copilot לא יכול להשתמש בהם.

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

למה בניית הסוכן הראשון היא רק ההתחלה

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

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

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

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

ארכיטקטורה של Copilot: ארבע שכבות, ערימה אחת

המוח של Copilot אינו בלוק בודד. הוא מורכב מארבע שכבות:

1. מודל הבסיס: מנוע השפה הגולמי.
2. תזמור: השכבה שקובעת אילו פונקציות נקראות ומתי. Microsoft 365 Copilot מספק אותה כברירת מחדל.
3. ביסוס: החיבור לתוכן הארגוני, שמונע תשובות מפוברקות.
4. מיומנויות, תוספים ומחברים מותאמים: השכבה שמבצעת משימות בפועל.

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

Copilot Studio או Teams Toolkit: איך בוחרים

שני הכלים טוענים שהם מרחיבים את Copilot, אבל הם משרתים בוני תוכנה וצרכים שונים. Teams Toolkit נקרא גם Microsoft 365 Agents Toolkit. בחירה שגויה עולה בזמן ובתקציב, ולפעמים גם באמינות כשההדגמה המבריקה מתקלקלת בייצור.

Copilot Studio: זירת היוצרים

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

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

Teams Toolkit: מגרש המשחקים של מפתחי Full Stack

הערכה מתחברת ל-VS Code ולא לקנבס של גרירה ושחרור. אפשר לבנות בה סוכנים הצהרתיים עם כללים מובנים, או ללכת רחוק יותר וליצור סוכני מנוע מותאמים, שבהם אתם מגדירים בעצמכם קריאות למודל, תזמור וטיפול ב-API. מקבלים תבניות פיגומים, ניפוי שגיאות, תצורה ופרסום, לא רק ל-Copilot אלא גם ל-Teams, לאפליקציות Microsoft 365, לאינטרנט ולערוצים חיצוניים. החופש רחב, אבל האחריות על כל פרט בידיכם.

מה באמת שונה ביניהם

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

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

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

רשימת בדיקה קצרה

• צריכים סוכנים מהירים, ניתנים לביקורת ומנוהלים, שמשתמשים מתקדמים יכולים לבנות? בחרו ב-Copilot Studio.
• צריכים תזמור מותאם, מודלי AI חיצוניים או אינטגרציה עמוקה לליבת הארגון? בחרו ב-Agents Toolkit.
• אל תסתמכו על התוויות. התבססו על הצרכים בפועל של הצוות.

בדיקה אחת שכדאי לעשות מראש היא הרישוי. חלק מיכולות הביסוס, כמו תוכן SharePoint, צ'אטים ופגישות ב-Teams, נתוני Dataverse או מחברים לדואר ולחיפוש אנשים, נדלקות רק אם בדייר יש רישוי Microsoft 365 Copilot או מדידה של Copilot Studio. בלי הזכאות הזו, גם בחירה ב-Studio לא תפתח אותן.

ביסוס: איך הסוכן מפסיק לנחש

ביסוס הוא המקום שבו הסוכן מפסיק לזייף חוכמה ומתחיל לעבוד עם ידע אמיתי. Microsoft 365 Copilot כבר רואה קבצים, צ'אטים, פגישות ואירועי לוח שנה דרך Microsoft Graph. אבל התוכן היקר ביותר נמצא מעבר לליבה הזו: מלאי ב-ERP, מחזורי חיי לקוח ב-CRM, ספרי הדרכה של משאבי אנוש עמוק ב-SharePoint ומסמכי מדיניות בתיקיות נעולות.

Copilot Studio ומחברי Microsoft Graph מאפשרים להגיע ל-SharePoint למסמכים, ל-Dataverse לטבלאות מובנות, ל-Exchange לדואר ול-Teams לצ'אטים. מעבר לכך, מחברים רבים דרך Power Platform פותחים דלת למערכות חיצוניות כמו כספים, משאבי אנוש וכרטיסי תמיכה, וממשקי API מותאמים משלבים אפליקציות עסקיות שאין להן מחבר מובנה.

הדוגמה של משאבי אנוש

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

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

כל חיבור הוא גם נקודת סיכון

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

ממשל: איך מונעים התפשטות סוכנים

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

• מערכת הבקרה של Copilot במרכז הניהול של Microsoft 365.
• ניהול מחזור חיים במרכז הניהול של Power Platform.
• Microsoft Purview לתיוג רגישות ול-DLP.
• יומני אבחון של Copilot לצורכי ביקורת.

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

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

1. להגדיר מי רשאי ליצור סוכנים, ולקשור זאת לסביבות במרכז הניהול של Power Platform.
2. להגדיר מי רשאי לפרסם סוכנים, דרך הגדרות Copilot במרכז הניהול של 365, כדי לאשר או לחסום מהדורות.
3. להגדיר היכן סוכנים פועלים, על ידי שיוך לסביבות מבודדות כך שהייצור אינו זירה פתוחה.
4. להגדיר כיצד מוקצים קרדיטים, בעזרת מד הצריכה של סוכני Copilot.

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

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

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

רישוי ועלויות: המלכודת שלא רואים

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

מאגר משותף לכל הדייר

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

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

והצד של Toolkit

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

שלוש בקרות מעשיות

1. לאפשר ניטור צריכה ברמת הדייר, דרך מד הצריכה של סוכני Copilot או דוחות תשלום לפי שימוש.
2. להגדיר ספי התראה, כדי שמנהלי הכספים ומנהלי ה-IT יקבלו הודעה לפני שהמאגר מתרוקן.
3. להקצות תקציבים לכל יחידה עסקית, באמצעות חבילות קרדיטים נפרדות או מדיניות פנימית ברורה.

טעויות נפוצות ואבני נגף

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

טיפים מעשיים לסיכום

• בחרו את מסלול הבנייה לפי הצורך: Copilot Studio למהירות בקוד נמוך, ו-Teams Toolkit (Microsoft 365 Agents Toolkit) לתזמור מותאם ולבקרה עמוקה יותר.
• בדקו את מפת הרישוי לפני שאתם מתחייבים לכלי.
• חברו את הסוכן למקורות הארגוניים הנכונים, והשתמשו בציטוטים כדי שכל תשובה תהיה ניתנת להגנה.
• שלבו Purview, תוויות רגישות ו-DLP מהיום הראשון.
• הגבילו את ניהול התרחישים לתפקידים המתאימים.
• הגדירו מי יוצר, מי מפרסם והיכן הסוכנים פועלים, והפעילו יומני אבחון לפני הפרסום.
• הגדירו ניטור צריכה, ספי התראה ותקציבים לכל יחידה עסקית.
• קטלגו רישיונות ומחברים בשלב התכנון, ואשרו מי משלם על כל אחד.

סיכום

סוכן Copilot מוצלח נמדד בעמידה בתנאים אמיתיים לאורך זמן, לא בהדגמה מרשימה. הבחירה בין Copilot Studio ל-Teams Toolkit חשובה, אבל היא רק ההתחלה. מה שמחזיק את הסוכן בחיים הוא ביסוס נכון, ממשל מההשקה ותכנון של הרישוי והעלויות.