ai-agents-for-beginners

פריסת סוכנים בקנה מידה עם Microsoft Foundry

פריסת סוכנים בקנה מידה

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

השיעור הזה עוסק בהבדל בין “זה עובד על המחשב שלי” לבין “זה עובד, באמינות ובעלות סבירה, בייצור.” אנו סוגרים את הפער הזה באמצעות Microsoft Foundry ו-Microsoft Foundry Agent Service, ועושים זאת על ידי בניית סוכן תמיכה ללקוחות אמיתי שיש לו כלים, שליפה, זיכרון, הערכה ומעקב.

מבוא

שיעור זה יכלול:

מטרות הלמידה

בסיום שיעור זה, תדעו כיצד:

דרישות מוקדמות

שיעור זה מניח שסיימתם את השיעורים הקודמים ואתם בנוח עם:

תזדקקו גם ל:

מאב-טיפוס לייצור: מה באמת משתנה

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

דאגה אב-טיפוס ייצור
אירוח רץ במחברת שלך רץ כשירות אירוח, בגרסאות ומופץ
זהות הטוקן שלך של az login זהות מנוהלת עם RBAC ממוקד
מצב בזיכרון, נאבד באתחול מופרד (מחסן נושאים, שירות זיכרון)
כישלון אתה רואה את מעקב השגיאות ניסיונות חוזרים, גיבויים, מכתבים מתים, התראות
עלות “זה כמה סנטים” מעקב לפי בקשה, ניתוב, מטמון, תקציב
איכות אתה בודק בעין את הפלט מוערך אוטומטית לפני כל פרסום
אמינות אתה מאשר כל פעולה מדיניות + אדם בלולאה לפעולות בסיכון

זכרו את הטבלה הזו. כל קטע למטה מתאים לאחת מהשורות האלה.

דפוסי פריסת סוכנים

ישנם שלושה דפוסים שתשתמשו בהם, לעיתים בשילוב.

1. סוכנים מותאמים ללקוח

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

2. סוכנים מאוחסנים (Foundry Agent Service)

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

3. זרימות עבודה של סוכן

סוכנים וכלים רבים מורכבים לגרף עם זרימת בקרה מפורשת — שלבים רצופים, הסתעפויות, נקודות אישור אנושיות, ונקודות בדיקה עמידות שיכולות להפסיק ולהמשיך. זוהי יכולת זרימות עבודה במסגרת Microsoft Agent Framework המיושמת בקנה מידה של פריסה.

flowchart TB
    subgraph P1[Client-Hosted]
        A1[Your App Process] --> M1[Model Provider]
    end
    subgraph P2[Hosted Agent]
        A2[Thin Client] --> F2[Foundry Agent Service]
        F2 --> M2[Model + Tools + Thread Store]
    end
    subgraph P3[Agent Workflow]
        A3[Orchestrator] --> S1[Triage Agent]
        S1 --> S2[Resolver Agent]
        S2 --> H[Human Approval Node]
        H --> S3[Action Agent]
    end

מחזור חיי הסוכן ב-Microsoft Foundry

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

flowchart LR
    Create[Create / Author] --> Version[Version]
    Version --> Evaluate[Evaluate offline]
    Evaluate -->|passes gate| Deploy[Deploy hosted]
    Evaluate -->|fails gate| Create
    Deploy --> Observe[Observe online]
    Observe --> Improve[Collect failures]
    Improve --> Create
    Deploy --> Retire[Retire old version]

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

אסטרטגיות סקיילינג

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

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

ניתוב מודלים. לא כל בקשה זקוקה למודל היעיל (והיקר) ביותר שלכם. ניתבו בקשות פשוטות — סיווג כוונות, תשובות קצרות עובדתיות — למודל קטן ומהיר, ושמרו את המודל הגדול לניתוח אמיתי. Foundry’s Model Router יכול לעשות זאת עבורכם, או שתוכלו ליישם מסווג קל משקל בעצמכם. תבנו את הגרסה ה-DIY במעבדה.

מטמון תגובות. הרבה שאלות תמיכה הן חזרות קרובות (“איך אני מאפס את הסיסמה?”). מטמנו תשובות לשאלות נפוצות והגישו אותן בלי להשתמש במודל כלל. אפילו שיעור תאימות מטמון צנוע פוגע משמעותית בעלות ובזמן תגובה.

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

flowchart LR
    Q[User query] --> C{Cache hit?}
    C -->|yes| R[Return cached answer]
    C -->|no| Router{Complexity?}
    Router -->|simple| SLM[Small model]
    Router -->|complex| LLM[Large model]
    SLM --> Out[Response]
    LLM --> Out
    Out --> Store[Cache + trace]

תצפית בייצור

אי אפשר להפעיל מה שלא רואים. כפי שנלמד בשיעור 10, Microsoft Agent Framework משדר עקבות OpenTelemetry באופן טבעי — כל קריאה למודל, הפעלת כלי, ושלב תזמור הופכים לרווח. בייצור אתם מייצאים את הרווחים הללו ל-Microsoft Foundry (או לכל backend תואם OTel) כדי שתוכלו:

from agent_framework.observability import get_tracer

tracer = get_tracer()

with tracer.start_as_current_span("support_request") as span:
    span.set_attribute("customer.tier", "enterprise")
    span.set_attribute("routed.model", "gpt-5-nano")
    # agent execution is traced automatically inside this span

תכונות כמו customer.tier ו-routed.model הן מה שהופכות קיר עקבות לשאלות שניתן לענות עליהן (“האם לקוחות ארגוניים מנותבים למודל הקטן יותר לעיתים קרובות מדי?”).

אופטימיזציית עלויות

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

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

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

שיקולי פריסת ארגון

ממשל. סוכנים מאוחסנים יורשים את RBAC, בטיחות תוכן, ורישום ביקורת של Foundry. תן לכל סוכן זהות מנוהלת עם ההרשאה המינימלית הנדרשת — גישה רק לקריאה לבסיס הידע, גישה ממוקדת ל-API של טיקטים, ולא יותר.

אדם בלולאה. פעולות מסוימות חשובות מדי לאוטומציה מוחלטת — החזרת תשלום, מחיקת חשבון, העלאה לצוות משפטי. Microsoft Agent Framework תומך בכלים שדורשים אישור: הסוכן מציע את הפעולה, ההרצה נעצרת, אדם מאשר או דוחה, וזרימת העבודה ממשיכה. ראיתם את הפרימיטיב ב-שיעור 6; כאן אתם מפרסים אותו.

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

flowchart TB
    subgraph Dev[Development Architecture]
        D1[Notebook] --> D2[Agent Framework]
        D2 --> D3[Model Provider]
        D2 --> D4[Local tools]
    end
    subgraph Deploy[Deployment Architecture]
        E1[CI pipeline] --> E2[Evaluation gate]
        E2 -->|pass| E3[Foundry Agent Service]
        E3 --> E4[Versioned hosted agent]
    end
    subgraph Run[Runtime Architecture]
        F1[Client app] --> F2[Hosted agent]
        F2 --> F3[Model Router]
        F2 --> F4[Azure AI Search RAG]
        F2 --> F5[Memory service]
        F2 --> F6[MCP tools]
        F2 --> F7[OTel -> Foundry tracing]
        F2 --> F8[Human approval]
    end

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

מעבדה מעשית: סוכן תמיכה ללקוח מוכן לייצור

פתח את code_samples/16-python-agent-framework.ipynb ועבור עליו מקצה לקצה. תרכיב סוכן תמיכה ללקוח Contoso עם כל דאגה של ייצור מטובלת:

  1. קריאת כלים — בדוק סטטוס הזמנה ופתח כרטיסי תמיכה.
  2. RAG — ענה על שאלות מדיניות מבסיס ידע (Azure AI Search, עם גיבוי בזיכרון כדי שהמחברת תרוץ ללא משאב חיפוש).
  3. זיכרון — זוכר את הלקוח בין סבבי השיחה.
  4. ניתוב מודל — מסווג מורכבות מנתב כל בקשה למודל קטן או גדול.
  5. מטמון תגובות — שאלות חוזרות מוגשות מהמטמון.
  6. אישור אנושי — החזרים מעל סף נעצרים לחתימת אדם.
  7. צינור הערכה — סט מבחן לא מקוון קטן מדרג את הסוכן ומשמש כשער שחרור.
  8. תצפית — עקבות OpenTelemetry סביב כל בקשה.

סיור

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

async def handle_support_request(query: str, customer_id: str) -> str:
    # 1. Serve from cache when we can.
    cached = response_cache.get(normalize(query))
    if cached:
        return cached

    # 2. Route by complexity to control cost.
    model = "gpt-5-nano" if is_simple(query) else "gpt-5-mini"

    # 3. Run the agent inside a trace span for observability.
    with tracer.start_as_current_span("support_request") as span:
        span.set_attribute("routed.model", model)
        span.set_attribute("customer.id", customer_id)
        response = await support_agent.run(query, model=model)

    # 4. Cache and return.
    response_cache.set(normalize(query), response.text)
    return response.text

שער ההערכה שמגן על שחרור נראה כך:

async def evaluation_gate(agent, test_cases, threshold: float = 0.8) -> bool:
    passed = 0
    for case in test_cases:
        result = await agent.run(case["input"])
        if score_response(result.text, case["expected"]) >= 0.8:
            passed += 1
    pass_rate = passed / len(test_cases)
    print(f"Evaluation pass rate: {pass_rate:.0%} (gate: {threshold:.0%})")
    return pass_rate >= threshold  # only deploy if the gate passes

קרא כל שורה — המחברת משאירה את היסודות קטנים בכוונה כך ששום דבר לא מוסתר מאחורי קריאת מסגרת.

אימות סוכן מפורסם עם בדיקות עשן

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

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

מאגר זה כולל צינור בדיקות עשן מוכן לשימוש המבוסס על AI Smoke Test GitHub Action:

- name: Smoke-test hosted agent
  uses: JFolberth/ai-smoketest@v1
  with:
    project_endpoint: $
    agent_name: ContosoSupportAgent
    tests_file: tests/lesson-16-smoke-tests.json

הריצו אותו מהכרטיסייה Actions לאחר הסעת הסוכן שלכם, תוך אספקת נקודת הקצה של פרויקט Foundry ושם הסוכן. זהות מאוחדת זקוקה לתפקיד Azure AI User במסגרת פרויקט Foundry. חשבו על השכבות כעל פירמידה: בדיקות עשן (האם נגיש ותגובות?) מופעלות בכל הפעלה, הערכה לא מקוונת (האם טוב מספיק למשלוח?) מופעלת לפני קידום, והערכה מקוונת (איך זה מתפקד בשטח?) פועלת ברציפות.

בדיקת ידע

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

1. בערך כמה מהסוכן בפרודקשן הוא “המודל,” ומהו שאר החלק?

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

2. מתי תעדיפו סוכן Hosted Agent על פני סוכן מאוחסן בלקוח?

תשובה כאשר רוצים סביבת הרצה מנוהלת עם עמידות מובנית (תהליכים שממשיכים ויכולים להתחדש), יכולת תצפית, בטיחות תוכן ו-RBAC, ומוכנים לוותר על קצת שליטה ברמת הלולאה בתמורה לפחות שטח תפעולי. סוכן מאוחסן בלקוח מועדף כשצריך שליטה מלאה על הלולאה או כאשר משבצים את הסוכן במערכת backend קיימת.

3. מדוע סוכן מתרחב חייב להיות ללא מצב בזיכרון התהליך שלו?

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

4. איזו בעיה פותר ניתוב מודל, וכיצד זה קשור להערכה?

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

5. מהו “שער הערכה” והיכן הוא ממוקם במחזור החיים?

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

6. מדוע יש להתייחס לשרת MCP כגבול לא מהימן בפרודקשן?

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

7. איזו שינוי בודד בדרך כלל משפיע הכי הרבה על עלות סוכן בפרודקשן, ומדוע?

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

8. איזו תפקיד ממלאים מאפייני span כמו customer.tier ו-routed.model בתצפית?

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

משימה

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

ההגשה שלכם צריכה:

  1. להחליף את הכלים לכלים רלוונטיים לחיוב: get_subscription_status, get_invoice, ו-issue_credit (אשראי מעל 50$ דורש אישור אנושי).
  2. להוסיף שלושה מסמכי RAG המכסים את מדיניות ההחזרים של החברה, מחזור החיוב, ומדיניות הביטולים.
  3. להרחיב את מערך ההערכה לפחות לשמונה מקרים, כולל לפחות שני מקרים שצריכים להפעיל את דרך האישור האנושי, ולאשר שהשער ההערכה שלכם עובר או נכשל בהתאם.
  4. להוסיף דוח עלות אחד: לאחר הרצת עשר שאילתות מעורבות דרך הסוכן, להדפיס כמה נכנסו למודל הקטן, כמה למודל הגדול וכמה נשמרו במטמון.

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

סיכום

בשיעור זה העברתם סוכן מפרוטוטייפ לפרודקשן עם Microsoft Foundry:

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

משאבים נוספים

שיעור קודם

בניית סוכני שימוש מחשב (CUA)

שיעור הבא

יצירת סוכני AI מקומיים

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

This site is open source. Improve this page.