איך בונים Copilot Agent: הפלואו הנכון, שלב אחר שלב
בניית Copilot Agent טובה היא תהליך בן שבעה שלבים, לא כפתור אחד: להתחיל מ-use case אחד וברור, להשקיע בהוראות, להוסיף דוגמאות, לעגן תשובות במקורות, לבחור Knowledge מדויק, להיעזר ב-Copilot עצמו לכתיבת ההוראות, ולבנות לולאת בדיקה קבועה. הסדר הזה מבוסס על הרצאות וסדנאות שאני מעביר (שמתפתחות כל הזמן כמובן, כמו הקופיילוט), לא על תיעוד גנרי של מיקרוסופט.
המדריך מיועד ל…כולם וכולן בתכלס. כל מי שרוצה לעשות קפיצת מדרגה בשימוש בקופיילוט הארגוני. אם עוד לא ברור לכם בכלל מה ההבדל בין פרומפט רגיל לסוכן, או אילו סוגי סוכנים יש, כדאי להתחיל מאיך לבנות סוכן Copilot לארגון, בלי קוד ואז לחזור לכאן לפלואו המעשי. ואם אתם מחפשים תמונה רחבה עוד יותר של איך סוכני AI עובדים בכלל (לא רק ב-Copilot), יש לי עמוד נפרד גם על זה. הפלואו הזה הוא לא רק תוכן למדריך. כל ארגון שאימץ Copilot כדאי שיעביר אותו הלאה, גם לצוותים שבונים וגם להנהלה שמחליטה, בסדנה מעשית וגם בהרצאה להנהלה. זה בדיוק מה שאני עושה בשטח.
מה זה בכלל Declarative Agent?
Declarative Agent הוא עוזר AI מותאם שבונים בתוך Microsoft 365 Copilot באמצעות הוראות, דוגמאות וקבצי ידע, בלי לכתוב שורת קוד. הוא מתנהג כמו עובד חדש עם תפקיד מוגדר, גבולות ברורים ומקורות מידע ספציפיים, בזמן שה-Copilot הכללי עונה מכל מה שהוא יודע. (נכון לספטמבר 2026: מיקרוסופט משנה שמות וכלים בתדירות גבוהה, אז לפני שאתם בונים כדאי לוודא שהמסך שמולכם עדיין נראה בדיוק ככה).
שני דברים שהשתנו ב-Builder תוך כדי כתיבת המדריך הזה
אי אפשר לדלג על זה: יש עכשיו Skills (עדיין ב-Preview) ב-Agent Builder, יכולת לארוז הוראות שלמות כמודול אחד שאפשר לצרף לכל Agent, במקום להעתיק ולהדביק את אותה הוראה מחדש בעשרה Agents שונים. זה ה"וואו" האמיתי של החודש הזה. הדבר השני קטן יותר אבל שימושי בטירוף: יש עכשיו לשונית Monitor ממש למעלה בבילדר, עם נתוני שימוש אמיתיים (Sessions, Avg. DAU, Avg. user messages, גרף Engagement, ואפילו Knowledge analytics), בלי לצאת לשום Studio או Admin Center. זה בדיוק מה שהופך את שלב 7 למטה (בדיקה ואופטימיזציה) מ"מנחשים" ל"רואים נתונים אמיתיים". (נכון לספטמבר 2026, לפני שמישהו שם ישנה את זה שוב.)
שלב 1: להתחיל מ-use case אחד וברור, לפני שפותחים את Microsoft Copilot Agent Builder
לפני שנוגעים בבילדר (Microsoft Copilot Agent Builder, נכון לספטמבר 2026) בכלל: תגדירו למי הבוט הזה מיועד, מה הוא כן עושה, ומה הוא בשום אופן לא עושה. הגבולות והסיכונים באים לפני היכולות, לא אחריהן.
מהניסיון שלי, כמעט כל Agent שנתקע באמצע הבנייה נתקע כי מישהו ניסה לפתור יותר מדי בעיות בבת אחת. עדיף עוזר צר מאוד, כמו "contract summarizer" שמסכם חוזים ותו לא, ולהתרחב רק אחרי שההתנהגות שלו יציבה.
דוגמה קונקרטית שעובדת: Agent שעונה אך ורק על שאלות עובדים לגבי ימי חופשה ותקנון נוכחות, ולא נוגע בשכר, בתלונות או בגיוס. דוגמה שכמעט תמיד נכשלת: Agent בשם "שירות עובדים" שאמור לענות על הכל. את הראשון אפשר לבדוק תוך יום עבודה אחד. את השני אף אחד לא יודע איך לבדוק, כי אף אחד לא באמת יודע מה הוא אמור לדעת.
וזו הסיבה שלמה use case רחב מדי הורס לא רק את השלב הזה, אלא את כל התהליך: כשאין גבול ברור, גם ההוראות בשלב הבא יוצאות כלליות מדי, וגם הדוגמאות בשלב 3 מתחילות לסתור אחת את השנייה. כל מי ששואל איך בונים Copilot Agent טוב צריך להתחיל בדיוק כאן, ולא בבילדר עצמו.
טעות שכיחה נוספת: לבחור use case לפי מה שהכי "מרשים" להראות להנהלה, ולא לפי מה שהכי קל לבדוק. שני הדברים לא תמיד חופפים, וכשצריך לבחור, תמיד עדיף לבדוק.
(אגב, ה-use case הראשון ל-Copilot Agent שלכם לא צריך להיות מרשים. הוא צריך לעבוד).
שלב 2: תשקיעו בהוראות (Instructions)
כותבים הוראות ל-Agent בדיוק כמו שכותבים לעובד חדש ביום הראשון: מה התפקיד, למי הוא פונה, באיזה סגנון עונה, מה מבנה התשובה, ומה אסור לו לעשות. הניסוח עובד הכי טוב כשהוא ישיר ("You are…", "Always…", "Never…"), לא כללי מעורפל.
זה השלב שהכי הרבה אנשים מדלגים עליו, ובטעות. הוראות רזות מייצרות Agent שמתחיל טוב ומתפרק אחרי חמש שאלות. תכתבו גם מה לעשות וגם מה לא לעשות, במפורש.
(דוגמה קטנה: לא מספיק לכתוב "תענה בקצרה". תכתבו "תענה בשלוש עד חמש שורות, בלי הקדמות, ותסמן כשאתה לא בטוח").
מהניסיון שלי, ארגונים כמעט תמיד כותבים הוראות שמתארות מה ה-Agent אמור להיות ("עוזר ידידותי ומקצועי"), במקום מה הוא אמור לעשות בפועל. זה נשמע דומה, אבל זו הוראה שאי אפשר לבדוק: Agent "ידידותי" יכול להתנהג בעשרות דרכים שונות ועדיין לעמוד בהגדרה הזאת. Agent שעונה "בשלוש עד חמש שורות, בלי הקדמות, ומסמן כשהוא לא בטוח" אי אפשר לפרש בשתי דרכים.
ובלי הוראות ברורות כאלה, ה-Agent שלכם ינחש איך להתנהג בכל שיחה מחדש. לפעמים הוא ינחש נכון, לפעמים לא. זו בדיוק הסיבה שהוא נראה "הזוי" בפגישת ההדגמה הראשונה, גם כשהוא בנוי בסך הכל נכון.
וכשההוראות מפורטות מדי בכיוון הלא נכון, כלומר מנסות לכסות כל מקרה קצה אפשרי, קורה משהו הפוך: ה-Agent נהיה מהוסס, ועונה בזהירות-יתר גם בשאלות פשוטות. גם כאן הפתרון זהה: קונקרטי וממוקד, לא מקיף.
רוצים תבנית מוכנה להדבקה בלי כל ההסברים? כבר יש לנו אחת כזאת, גם בעברית וגם באנגלית: רוצים תבנית מוכנה להדבקה?
שלב 3: תשתמשו בדוגמאות (few-shot)
שלוש עד חמש דוגמאות אידיאליות של שאלה-תשובה משפרות משמעותית את התנהגות ה-Agent, יותר מכל תיאור מילולי של הסגנון הרצוי. במקום לכתוב "תענה כמו מומחה", מדביקים זוג שאלה-תשובה אמיתי ומראים לו איך זה נראה.
(אני רואה את זה שוב ושוב בעבודה עם ארגונים: החלק שהכי מדלגים עליו הוא בדיוק החלק שהכי משפר תוצאות).
דוגמה לזוג שאלה-תשובה שעובד טוב: השאלה "מה מדיניות ההחזרים שלנו ללקוח פרטי?", והתשובה בדיוק בפורמט, בטון ובאורך שאתם רוצים שה-Agent יחזור עליו בכל פעם. Agent שרואה דוגמה אחת כזו לומד ממנה יותר מאשר מפסקה שלמה שמסבירה "תענה בטון מקצועי וממוקד". שלוש עד חמש דוגמאות כאלה, במגוון סוגי שאלות, כבר מספיקות כדי שה-Agent יתחיל להתייצב על סגנון עקבי.
וזה גם המקום שבו רוב הצוותים מגלים שההוראות שכתבו בשלב 2 לא ברורות כמו שחשבו: ברגע שמנסים לכתוב דוגמת תשובה אמיתית לפי ההוראות, מתגלים כל הפינות שההוראה המילולית לא כיסתה.
שלב 4: תעגנו תשובות (grounding)
עיגון (grounding) אומר לחייב את ה-Agent לענות רק מתוך חומר המקור שהועלה אליו, ולציין את שם הקובץ או הסעיף בכל תשובה עובדתית. זה מוריד הזיות ומאפשר לבדוק כל תשובה מול מסמך ספציפי, במקום לסמוך על "ידע כללי" של המודל.
תוסיפו הוראה מפורשת למקרה שאין מספיק מידע: "If unsure or missing info, say you don't have enough information and ask for clarification or upload." בלי המשפט הזה, ה-Agent פשוט יממציא תשובה בטוחה שנשמעת נכון.
מהניסיון שלי, זה השלב שהכי הרבה ארגונים גדולים מדלגים עליו, כי הוא נשמע "מובן מאליו", ואז מתפלאים כשה-Agent עונה תשובות בטוחות ולא נכונות. עיגון הוא לא תוספת נחמדה. הוא ההבדל בין Agent שאפשר לתת לעובדים לסמוך עליו לבין Agent שצריך לבדוק אחריו כל תשובה.
בלי עיגון, ה-Agent לא באמת "לא יודע" שום דבר. הוא תמיד ידע לענות משהו, כי ככה מודלי שפה עובדים: הם משלימים טקסט סביר, גם כשאין להם את המידע. עם הוראת עיגון מפורשת, "אני לא יודע" הופך לתשובה לגיטימית ותקינה, לא לכישלון של ה-Agent.
בהרצאה שנתתי ב-EY שאלתי את הקהל מי היה סומך על תשובה של Agent בלי לבדוק אותה במקור. כמעט אף אחד לא הרים יד, וזו בדיוק הנקודה: עיגון הוא מה שהופך "כמעט אף אחד" ל"רוב האנשים".
(עיגון הוא לא רק עניין טכני. זה מה שהופך Agent מ"עוד צ'אטבוט חמוד" לכלי שאפשר לבדוק ולסמוך עליו).
שלב 5: Knowledge מדויק
לא מעלים "כל מה שיש", אלא בוחרים מסמכים מדויקים כמו playbooks, שאלות נפוצות ומצגות, עם שמות קבצים ברורים וגרסאות מסודרות. Knowledge base מצומצם ומתוחזק מביא ביצועים טובים יותר מ-Knowledge base עמוס, וגם קל יותר לתחזק: מחליפים קובץ אחד במקום לבנות Agent מחדש.
הפיתוי הטבעי הוא להעלות תיקייה שלמה "למקרה שיצטרך". אל תעשו את זה. מקורות הידע (Knowledge) שמזינים את ה-Agent שלכם צריכים להיות ממוקדים, לא מקיפים.
מהניסיון שלי בעבודה עם ארגונים, ה-Knowledge base שמתחיל מסודר נשאר לרוב מסודר, וזה שמתחיל "נעלה הכל ונסנן אחר כך" כמעט אף פעם לא מגיע לשלב הסינון. הבעיה לא רק בביצועים. Knowledge base עמוס גורם ל-Agent למצוא סתירות בין מסמכים ישנים לחדשים, ולענות לפי המסמך הלא נכון, בלי שום דרך לדעת שזה קרה.
דוגמה מהחיים: קובץ FAQ שהוחלף שלוש פעמים בשנה האחרונה, אבל שתי הגרסאות הישנות עדיין יושבות איפשהו בתיקייה המשותפת. אם כולן מועלות ל-Agent, הוא עלול לצטט בביטחון מלא את המדיניות שהייתה נכונה לפני שנה.
כלל אצבע שאני נותן בהדרכות: אם אתם לא בטוחים אם מסמך שייך ל-Knowledge, הוא כנראה לא שייך. תעלו אותו רק אחרי שהוא עבר עדכון אחרון ואושר.
(שם קובץ ברור וגרסה מסודרת נשמעים כמו פרט טכני משעמם, עד שאתם מנסים לתחזק Agent אחרי חצי שנה בלי זה).
שלב 6: תכתבו את ההוראות עם Copilot עצמו, בתוך Microsoft Copilot Agent Builder
כן, ואני ממליץ על זה: משתמשים ב-Copilot עצמו (בממשק Work או Web) כדי לנסח את מסמך ההוראות, במקום לכתוב prompt engineering ידני מאפס. בהרצאה שנתתי ב-EY הדגמתי את זה עם פרומפט כמו:
"תכתוב לי הוראות בבקשה, ל-Copilot agent, שיעסיק את הילדים שלי אחרי הצהריים במקומי. האייג'נט צריך ל…"
(שימו לב: זו לא דוגמה מוקפדת שנוצרה בשביל עמוד אינטרנט. זה בדיוק מה שנאמר על הבמה, ואני משאיר את זה ככה כי זה מדגים בדיוק את הנקודה: אפשר לבקש מ-Copilot משהו יומיומי לגמרי, והוא יודע לתרגם את זה למסמך הוראות מסודר).
הרעיון: Copilot כבר יודע איך הוראות טובות נראות. במקום להתחיל ממסך ריק, תבקשו ממנו טיוטה ראשונה, ואז תעדכנו אותה לפי מה שבאמת קרה בבדיקות (שלב 7 למטה).
הסיבה שזה עובד טוב היא שמסמך הוראות טוב הוא בעצם מסמך שמתאר תהליך אנושי מוכר: תפקיד, קהל, טון, מבנה תשובה וגבולות. Copilot כבר "ראה" אלפי מסמכי הוראות כאלה, ולכן הטיוטה הראשונה שהוא מייצר כמעט תמיד קרובה למה שבאמת צריך, גם אם היא לא מושלמת.
בפועל, ככה זה נראה: מבקשים טיוטה, בודקים אותה מול שלוש-ארבע שאלות אמיתיות, ומבקשים מ-Copilot לתקן פסקה ספציפית לפי מה שראיתם. זה מחזור של דקות, לא של ישיבות.
טעות נפוצה: לבקש מ-Copilot לכתוב הוראות בלי לתת לו שום הקשר על הארגון או על השימוש בפועל. הטיוטה שתקבלו תהיה כללית מדי. תנו לו הקשר אמיתי (למי זה מיועד, אילו שאלות הוא יקבל, מה אסור לו לענות), ואז הטיוטה כבר קרובה בהרבה למוצר הסופי.
שלב 7: בדיקה ואופטימיזציה
בונים סט קבוע של 5-10 שאלות בדיקה ומריצים אותו מחדש בכל פעם שמשנים הגדרות או Knowledge. לולאת בדיקה קבועה היא ההבדל בין Agent שנבנה פעם אחת ונשכח לבין Agent שמשתפר עם הזמן.
תשמרו סט קבוע: 5-10 פרומפטים אמיתיים שמייצגים את מה שהמשתמשים שלכם באמת ישאלו. בדיקת Copilot Agent לא צריכה להיות מסובכת, רק עקבית: בכל פעם שמשנים הוראות, מוסיפים דוגמה, או מחליפים קובץ Knowledge, מריצים את כל הסט מחדש ובודקים מה השתנה.
מהניסיון שלי, ה-Agent הכי גרוע שראיתי לא היה כזה שנבנה רע. הוא היה כזה שנבנה טוב, ואז אף אחד לא חזר אליו במשך חצי שנה, בזמן שהמדיניות שהוא מצטט כבר התיישנה. לולאת בדיקה לא בודקת רק אם ה-Agent "עובד". היא בודקת אם הוא עדיין נכון.
סט בדיקה טוב כולל גם שאלות "רגילות" (מה מדיניות X) וגם שאלות "גבוליות": שאלה שה-Agent בכלל לא אמור לענות עליה, כדי לוודא שהוא יודע לסרב בנימוס במקום לנחש.
אם אין לכם עדיין סט קבוע, תתחילו היום עם חמש שאלות בלבד. אפשר להרחיב בהמשך. הכי חשוב שהסט הזה באמת ירוץ כל פעם, לא שיהיה מושלם מההתחלה.
(בלי לולאת בדיקה, בונים Agent פעם אחת ומקווים לטוב. עם לולאת בדיקה, בונים Agent שמשתפר כל שבוע. וזה בעצם ההבדל בין מי שיודע איך בונים Copilot Agent טוב לבין מי שרק יודע איך להשיק אחד).
שאלות נפוצות על בניית Copilot Agent
כמה מילים לפני שקופצים לשאלות: בעברית קוראים לזה גם "קופיילוט אייג'נט" וגם "סוכן Copilot", זה אותו דבר.
איך בונים Copilot Agent, שלב אחר שלב?
בניית Copilot Agent טובה היא תהליך בן שבעה שלבים, לא כפתור אחד: להתחיל מ-use case אחד וברור, להשקיע בהוראות, להוסיף דוגמאות, לעגן תשובות במקורות, לבחור Knowledge מדויק, להיעזר ב-Copilot עצמו לכתיבת ההוראות, ולבנות לולאת בדיקה קבועה. הסדר הזה מבוסס על הרצאה מעשית שנתתי בספטמבר 2026, לא על תיעוד גנרי של מיקרוסופט.
איך כותבים הוראות (Instructions) טובות ל-Copilot Agent?
כותבים הוראות ל-Agent בדיוק כמו שכותבים לעובד חדש ביום הראשון: מה התפקיד, למי הוא פונה, באיזה סגנון עונה, מה מבנה התשובה, ומה אסור לו לעשות. הניסוח עובד הכי טוב כשהוא ישיר (You are, Always, Never), לא כללי מעורפל.
כמה דוגמאות (few-shot) כדאי להוסיף כדי שה-Agent יתנהג טוב?
שלוש עד חמש דוגמאות אידיאליות של שאלה-תשובה משפרות משמעותית את התנהגות ה-Agent, יותר מכל תיאור מילולי של הסגנון הרצוי. במקום לכתוב "תענה כמו מומחה", מדביקים זוג שאלה-תשובה אמיתי ומראים לו איך זה נראה.
למה חשוב לעגן (grounding) את תשובות ה-Agent במקורות, ואיך עושים את זה בפועל?
עיגון (grounding) אומר לחייב את ה-Agent לענות רק מתוך חומר המקור שהועלה אליו, ולציין את שם הקובץ או הסעיף בכל תשובה עובדתית. זה מוריד הזיות ומאפשר לבדוק כל תשובה מול מסמך ספציפי, במקום לסמוך על "ידע כללי" של המודל.
אילו מסמכים כדאי להעלות כ-Knowledge ל-Copilot Agent, וכמה?
לא מעלים "כל מה שיש", אלא בוחרים מסמכים מדויקים כמו playbooks, שאלות נפוצות ומצגות, עם שמות קבצים ברורים וגרסאות מסודרות. Knowledge base מצומצם ומתוחזק מביא ביצועים טובים יותר מ-Knowledge base עמוס, וגם קל יותר לתחזק: מחליפים קובץ אחד במקום לבנות Agent מחדש.
אפשר לבקש מ-Copilot עצמו לכתוב את ההוראות ל-Agent שבונים?
כן, ואני ממליץ על זה: משתמשים ב-Copilot עצמו (בממשק Work או Web) כדי לנסח את מסמך ההוראות, במקום לכתוב prompt engineering ידני מאפס. בהרצאה ב-EY הדגמתי את זה עם פרומפט כמו "תכתוב לי הוראות בבקשה, ל-Copilot agent, שיעסיק את הילדים שלי אחרי הצהריים במקומי".
איך בודקים ומשפרים Copilot Agent אחרי שבנו אותו?
בונים סט קבוע של 5-10 שאלות בדיקה ומריצים אותו מחדש בכל פעם שמשנים הגדרות או Knowledge. לולאת בדיקה קבועה היא ההבדל בין Agent שנבנה פעם אחת ונשכח לבין Agent שמשתפר עם הזמן.
בואו נבנה Agent אמיתי, לא רק נדבר עליו
המדריך הזה נותן לכם את הפלואו המלא, אבל תרגול בזמן אמת על use case אמיתי שלכם זה עולם אחר. אני מעביר סדנת Copilot Agents בארגון שבה בונים Agent אמיתי מהשלב הראשון ועד לולאת הבדיקה, על הדוגמאות והמסמכים שלכם (בעיני המשוחדות, זו הדרך היחידה שבאמת נשארת אחרי הסדנה).