Agentic Design Patterns
10 דפוסי עיצוב לסוכני AI

Workflow מול Agent — הכלל הראשון

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

דפוסים 1–6 הם ברובם workflows. דפוס 7 הוא הסוכן האוטונומי האמיתי. דפוסים 8–10 חוצי-רוחב — נלווים לכל השאר. מקורות מוסמכים לרוב הדפוסים: המאמר "Building Effective Agents" של Anthropic, מאמר ReAct (Yao et al.) ומאמר Reflexion (Shinn et al.).

1 · Prompt Chaining — שרשור פרומפטים

linkWORKFLOW · רצף קבוע

פירוק משימה לרצף קבוע של קריאות LLM, כשכל שלב מעבד את הפלט של הקודם. אפשר לשים "שער" (gate) בין שלבים שבודק שהפלט תקין לפני שממשיכים.

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

2 · Routing — ניתוב לפי סוג

call_splitWORKFLOW · סיווג ואז שליחה

מסווגים את הבקשה, ואז שולחים אותה למומחה המתאים — פרומפט ייעודי, מודל אחר, או כלי אחר. זה הדפוס מהסרטון הוויראלי (04/05).

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

3 · Tool Use / ReAct — הלולאה הבסיסית

buildAGENTIC · חשוב ← פעל ← צפה

הלב של כל סוכן: המודל חושב מה לעשות, מפעיל כלי (חיפוש, DB, קוד, API), רואה את התוצאה, וחוזר — עד לתשובה. זה הדפוס מהסרטון (01/05), ומבוסס על מאמר ReAct.

מתי להשתמש: כשהמשימה דורשת מידע חי או פעולה בעולם — חיפוש, קריאת מסד נתונים, הרצת קוד. הרחבנו על מימוש מלא במדריך AI Agents ובMCP (הדרך הסטנדרטית לחבר כלים לסוכן).

4 · Planning — תכנון ואז ביצוע

checklistWORKFLOW · Plan-and-Execute

מודל אחד מפרק יעד רחב לשלבים מסודרים; לאחר מכן כל שלב מבוצע (לעיתים על ידי תת-סוכנים). מפריד בין "מה לעשות" ל"עשייה". זה הדפוס מהסרטון (02/05).

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

5 · Reflection / Critic — ייצר, הערך, שפר

rate_reviewWORKFLOW · Evaluator-Optimizer

מחולל מייצר פלט; מבקר מעריך אותו מול קריטריונים; חוזרים על "שפר" עד שהפלט עובר את הסף. זה הדפוס מהסרטון (03/05), ומבוסס על Reflexion.

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

6 · Parallelization — מקבול

splitscreenWORKFLOW · במקביל

מריצים כמה קריאות LLM בו-זמנית. שני טעמים: Sectioning — פיצול לתת-משימות בלתי-תלויות; Voting — הרצת אותה משימה כמה פעמים וצבירת הצבעה/קונצנזוס.

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

7 · Orchestrator-Workers — סוכן שמנהל סוכנים

hubAGENTIC · Multi-Agent

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

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

8 · Memory — זיכרון

databaseנלווה · הקשר לאורך זמן

זיכרון קצר-טווח = היסטוריית השיחה בחלון ההקשר. זיכרון ארוך-טווח = מידע שנשמר מחוץ להקשר (בדרך כלל ב-Vector Store) ומאוחזר לפי רלוונטיות.

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

9 · Human-in-the-Loop — אדם בלולאה

how_to_regנלווה · אישור לפני פעולה

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

מתי להשתמש: לכל פעולה עם השלכה אמיתית בעולם. אמון עיוור בסוכן לפעולות בלתי-הפיכות הוא מתכון לאסון — עדיף checkpoint אחד מאשר לתקן נזק. מימוש נוח מאוד ב-LangGraph (Conditional Edges + נקודת עצירה).

10 · Guardrails — מעקות בטיחות

shieldנלווה · שכבת הגנה

לא זרימה אלא שכבת בטיחות שעוטפת את כל שאר הדפוסים: אימות קלט ופלט, allowlists, בדיקת סכימה (schema), מודרציה, ומגבלות קשיחות (max_iterations, timeout, תקרת עלות).

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

גיליון עזר — איזה דפוס לאיזו בעיה