Agentic Architecture — ארכיטקטורה לבניית AI Agents בפרודקשן

מאת צוות מדיה דיל · 09.08.2026 · AI · 7 דק׳

מה מבדיל Agent שרץ יציב בפרודקשן מדמו שקורס בבדיקה השלישית: לולאת ה-Agent, ניהול מצב, טיפול בכשלים, וגבולות אוטונומיה — ומתי בכלל כדאי להשתמש בארכיטקטורה אגנטית.

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

מה מגדיר מערכת כ"אגנטית"

לא כל שימוש במודל שפה הוא Agent. מערכת נחשבת אגנטית כשמתקיימים שלושה תנאים: אוטונומיה בקבלת החלטות — המודל בוחר אילו פעולות לבצע ובאיזה סדר, ולא רק ממלא תבנית קבועה; שימוש בכלים — המודל יכול לפעול על העולם (לקרוא נתונים, לכתוב, להריץ קוד) ולא רק לייצר טקסט; ולולאה איטרטיבית — המודל רואה את תוצאות הפעולות שלו ומתאים את התוכנית בהתאם. מערכת שרק "שולפת מידע ומחזירה תשובה בקריאה אחת" היא RAG פשוט, לא Agent. ברגע שיש שרשרת החלטות עם משוב, נכנסים לתחום האגנטי.

לולאת ה-Agent: Reason, Act, Observe

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

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

while step_count < MAX_STEPS:
    plan = model.reason(state, history)
    if plan.is_final_answer:
        return plan.answer
    result = execute_tool(plan.tool_call)   # עם timeout ו-retry
    if is_repeating_pattern(history, plan):
        escalate_to_human("Agent stuck in loop")
        break
    history.append((plan, result))
    step_count += 1

ניהול מצב: Stateless מול Stateful

החלטה ארכיטקטונית מרכזית היא איך שומרים את מצב ההתקדמות של ה-Agent. בגישה stateless, כל קריאה כוללת את כל ההיסטוריה מחדש — פשוט למימוש, אבל לא מתאים למשימות ארוכות שחוצות תהליכים (processes) או ימים. בגישה stateful, מצב ה-Agent נשמר באחסון חיצוני (מסד נתונים, Redis) ומאפשר להשהות ולחדש ריצה, לשרוד קריסות, ולתמוך במשימות ארוכות טווח — נושא שמפורט במדריך Stateless מול Stateful ובAgents עמידים (Durable). ברוב מערכות הפרודקשן הרציניות, ניהול מצב חיצוני עם checkpoints הוא לא "nice to have" אלא דרישה בסיסית — ראו Agent Checkpoints.

ניהול הכלים הזמינים ל-Agent

כלים (tools) הם הממשק שדרכו ה-Agent פועל על העולם, ואיכות ההגדרה שלהם משפיעה ישירות על איכות ההחלטות. כל כלי צריך שם ברור, תיאור מדויק של מתי להשתמש בו (ולא רק מה הוא עושה), וסכימת קלט/פלט מוגדרת. כשיש הרבה כלים דומים באותה קריאה — למשל שלושה כלים שונים לחיפוש מידע ממקורות שונים — המודל עלול לבחור בטעות בכלי הלא נכון, גם אם התיאורים טכנית מדויקים. פתרון נפוץ הוא לקבץ כלים לפי הקשר המשימה ולחשוף לכל Agent רק את הכלים הרלוונטיים לתפקידו, נושא שמתקשר ישירות לארכיטקטורת MCP כשהכלים מגיעים משרתים חיצוניים.

גבולות אוטונומיה: כמה חופש לתת ל-Agent

אחת ההחלטות החשובות ביותר בתכנון Agent היא כמה אוטונומיה לאפשר. הספקטרום נע בין שלושה מודלים: Fully autonomous — ה-Agent מבצע פעולות ללא אישור (מתאים לפעולות הפיכות, סיכון נמוך); Human-in-the-loop — פעולות קריטיות (מחיקה, תשלום, שליחת מייל ללקוח) עוברות דרך שער אישור; וHuman-on-the-loop — ה-Agent פועל אוטונומית אבל אדם מנטר ויכול לעצור בזמן אמת. הכלל המעשי: ככל שהפעולה בלתי הפיכה יותר או משפיעה על גורם חיצוני (לקוח, כסף, נתונים קריטיים), כך נדרש יותר פיקוח. הרחבה בנושא במדריך Human-in-the-Loop ובשערי אישור (Approval Gates).

טיפול בכשלים: מה קורה כשכלי נכשל

ב-Agent אמיתי, כלים נכשלים כל הזמן — timeout ברשת, API שמחזיר שגיאה, נתונים לא צפויים. ארכיטקטורה טובה מבחינה בין שלושה סוגי כשל: כשל זמני (רשת, rate limit) שדורש retry עם backoff; כשל קבוע (הרשאה חסרה, כלי לא קיים) שדורש דיווח ברור למודל כדי שיתאים תוכנית; וכשל שקט — הכלי "מצליח" אבל מחזיר תוצאה שגויה, שהוא הכי מסוכן כי הוא לא מזוהה מיד. הגנה מרכזית כאן היא verifier — שלב נוסף שבודק את התוצאה לפני שממשיכים, ראו מודלי Verifier וארכיטקטורת Retry לסוכנים.

ניטור ומדידה של Agent בפרודקשן

Agent שרץ בפרודקשן בלי ניטור הוא קופסה שחורה — אי אפשר לדעת אם הוא בכלל עובד טוב, ולא רק "לא קורס". מדדים חיוניים כוללים: שיעור השלמת משימות בהצלחה, מספר צעדים ממוצע למשימה (עלייה פתאומית מעידה על בעיה), שיעור אסקלציה לאדם, ועלות ממוצעת לריצה. בנוסף, מומלץ לתעד trace מלא של כל ריצה — כל צעד נימוק, כל קריאת כלי, כל תוצאה — כדי לאפשר ניתוח בדיעבד כשמשהו משתבש. בלי טרייס כזה, כל דיווח על "ה-Agent התנהג מוזר" הופך לחקירה בלתי אפשרית. הרחבה בנושא במדריך LLM Observability.

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

Trade-offs: פשטות מול יכולת

• Single-agent מול Multi-agent — Agent יחיד עם הרבה כלים פשוט יותר לנפות שגיאות, אבל מגיע למגבלת יכולת כשהמשימה מורכבת מדי; פיצול לכמה Agents מתמחים מוסיף עלות תיאום. ראו Multi-Agent Systems.
• תכנון מראש מול תכנון מתקדם — Agent שמתכנן את כל השלבים מראש (plan-then-execute) צפוי יותר אך פחות גמיש מ-Agent שמתכנן צעד-צעד תוך כדי תנועה. ראו תכנון סוכנים (Agent Planning).
• עלות מול אמינות — הוספת שלבי אימות, retry ו-verifier מייקרת כל ריצה אך מקטינה משמעותית את שיעור הכשלים הבלתי מזוהים.

דוגמה מהשטח

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

טעויות נפוצות בבניית Agents

• בניית Agent כשמספיק pipeline קבוע — לא כל משימה זקוקה לאוטונומיה; אם השלבים ידועים וקבועים מראש, קוד דטרמיניסטי זול ואמין יותר מלולאת Agent.
• העדר מגבלת תקציב — Agent בלי הגבלה על מספר צעדים או עלות מקסימלית לריצה יכול "לברוח" בעלות בזמן שהוא מנסה לפתור בעיה בלתי פתירה.
• הענקת יותר מדי הרשאות "ליתר ביטחון" — Agent עם הרשאת כתיבה מלאה כשהוא זקוק רק לקריאה הוא סיכון אבטחה מיותר, במיוחד כשמעורב קלט חיצוני שעלול לכלול הזרקת הוראות. ראו Least Privilege לסוכנים.
• אי-הבחנה בין כשל זמני לכשל קבוע — retry עיוור על שגיאת הרשאה (שלא תיפתר בניסיון נוסף) מבזבז זמן ותקציב ללא תועלת.
• העדר לוג מפורט של שרשרת ההחלטות — בלי תיעוד של כל צעד וכל נימוק, אי אפשר להבין בדיעבד למה Agent קיבל החלטה מסוימת, מה שהופך דיבוג לניחוש.

שאלות נפוצות

מתי כדאי להשתמש בארכיטקטורה אגנטית ומתי עדיף pipeline רגיל?

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

איך מונעים מ-Agent "לברוח" ולבצע פעולות לא רצויות?

שילוב של גבולות הרשאה מחמירים (least privilege), שערי אישור לפעולות בלתי הפיכות, ומגבלת תקציב פעולות לכל ריצה. ראו מדריך AI Guardrails.

כמה כלים כדאי לתת ל-Agent אחד?

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

האם Agent צריך לדעת מתי הוא "לא בטוח"?

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

איך בודקים איכות של Agent לפני שמעלים לפרודקשן?

באמצעות סט תרחישי בדיקה (evals) שכוללים גם מקרי קצה וכשלים מכוונים, לא רק תרחישים "שמחים". ראו מדריך LLM Evals.

מה ההבדל בין Agent לבין אוטומציה רגילה (Workflow Engine)?

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

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

תגיות: Agentic Architecture · AI Agents · Agent Loop · Autonomy · Tool Use · LLM Orchestration

← חזרה לבלוג · צור קשר