Agent Planning — כיצד AI מפרק מטרה לתוכנית עבודה

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

בין 'עשה X' לבין ביצוע בפועל יש שלב שרוב הצוותים מזלזלים בו — תכנון. מדריך טכני על Task Decomposition, ReAct, Plan-and-Execute ותכנון דינמי בסוכני AI מורכבים.

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

מה זה Planning בסוכן AI ולמה זה לא טריוויאלי

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

Task Decomposition — איך שוברים מטרה למשימות

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

{
  "goal": "עדכן לקוחות לא-מחודשים ותעד ב-CRM",
  "plan": [
    { "step": 1, "action": "query_crm", "desc": "שלוף לקוחות עם renewal_date < 30 ימים אחורה" },
    { "step": 2, "action": "generate_message", "desc": "בנה מייל מותאם לכל לקוח", "per_item": true },
    { "step": 3, "action": "send_email", "desc": "שלח, עם retry ו-idempotency key" },
    { "step": 4, "action": "update_crm_status", "desc": "עדכן סטטוס 'נשלחה תזכורת'" }
  ]
}

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

ReAct, Plan-and-Execute ודפוסים נוספים

יש כמה דפוסים מבוססים לשילוב תכנון עם ביצוע:

• ReAct (Reasoning + Acting) — הסוכן "חושב בקול" צעד אחד קדימה, מבצע אותו, קורא את התוצאה, וחושב שוב מה הצעד הבא. אין תוכנית מלאה מראש — התכנון והביצוע שזורים. יתרון: מסתגל מיד לתוצאות בפועל. חיסרון: לא רואה את "התמונה הגדולה" מראש, ועלול להיתקע בלולאות מקומיות או לפעול בסדר לא-אופטימלי.
• Plan-and-Execute — הסוכן בונה תוכנית מלאה מראש (כמו בדוגמה למעלה), ואז מבצע אותה שלב-שלב, לעיתים עם "מתכנן" (planner) נפרד מ"מבצע" (executor). יתרון: ניתן לבדוק ולאשר את התוכנית לפני ביצוע (חשוב ל-Human-in-the-Loop), וקל יותר לעקוב אחרי התקדמות. חיסרון: תוכנית שנבנתה מראש עלולה להתברר כלא-רלוונטית ברגע שהמציאות בשטח שונה ממה שהונח.
• Hierarchical Planning — תכנון ברמות: תוכנית-על ברמה גבוהה (milestones), שכל milestone מפורק לתת-תוכנית מפורטת רק כשמגיעים אליו. משלב את היתרונות של שתי הגישות — רואים כיוון כללי מראש, אבל לא מתכננים לעומק צעדים שעדיין לא רלוונטיים.

Dynamic Replanning כשהמציאות משתנה

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

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

Trade-offs — עומק תכנון מול Latency ועלות

תכנון מוסיף שלב שלם לפני (או במקביל ל-) ביצוע — קריאת מודל נוספת, זמן המתנה נוסף, ולעיתים כמה איטרציות תכנון-ביקורת-תיקון לפני שהתוכנית "מספיק טובה". למשימות פשוטות וקצרות, תכנון מפורש הוא overhead מיותר — ReAct מינימלי (או אפילו קריאת כלי בודדת) מספיק. ככל שהמשימה מורכבת יותר, כוללת יותר צעדים תלויים, ויותר סיכון לטעות יקרה — ההשקעה בשלב תכנון מפורש, כולל אולי אישור אנושי לתוכנית לפני ביצוע, משתלמת יותר.

דוגמה מהשטח

סוכן שמבצע migration בין שתי גרסאות schema במערכת פנימית. במקום לגשת ישר לביצוע, הוא בונה תחילה תוכנית: זיהוי טבלאות מושפעות, סדר עדכון שמכבד foreign keys, אסטרטגיית rollback לכל שלב. התוכנית מוצגת למהנדס לאישור (approval gate) לפני שמתחיל ביצוע כלשהו. כשמתגלה באמצע הביצוע שטבלה מסוימת מכילה נתונים שלא צפויים, הסוכן לא ממשיך "לפי הספר" — הוא עוצר, מפעיל replanning עם המידע החדש, ומציג תוכנית מעודכנת.

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

• לדלג על תכנון מפורש במשימות מורכבות ולסמוך על ReAct בלבד — עובד לפעמים, אבל נוטה ללולאות ותפוקה לא-אופטימלית במשימות ארוכות.
• תכנון-יתר במשימות פשוטות — מוסיף latency ועלות בלי תועלת אמיתית.
• תוכנית קשיחה בלי מנגנון replanning — כשהמציאות סוטה מההנחות, הסוכן ממשיך "עיוור" ומייצר תוצאות שגויות.
• אין נראות (visibility) לתוכנית עצמה — אם התוכנית לא נחשפת ללוגים או לממשק אנושי, קשה מאוד לדבג למה הסוכן "החליט" לפעול כפי שפעל.

תכנון עם אילוצים (Constraints) מפורשים

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

תכנון ותלות בין צעדים (Dependency Graph)

לא כל תוכנית היא רשימה ליניארית פשוטה. במשימות מורכבות, חלק מהצעדים תלויים זה בזה (צעד ב' צריך את התוצאה של צעד א'), וחלקם עצמאיים לגמרי וניתנים לביצוע במקביל. תוכנית שמיוצגת כרשימה שטוחה "מפספסת" את המידע הזה ומאלצת ביצוע טורי גם כשמקביליות הייתה חוסכת זמן משמעותי. ייצוג התוכנית כ-גרף תלויות (DAG) במקום רשימה מאפשר לזהות אילו צעדים אפשר להריץ בו-זמנית — למשל, שליפת נתונים מכמה מקורות שונים לא תלויים זה בזה יכולה לרוץ במקביל, בעוד עיבוד סופי שתלוי בכל התוצאות ממתין לסיום כולן (דפוס fan-out/fan-in). זה משפר משמעותית latency במשימות עם הרבה צעדים עצמאיים, ומחייב שהמתכנן עצמו "יחשוב" במונחי תלויות, לא רק ברצף.

תכנון תחת אי-ודאות במידע

הרבה תוכניות נבנות בהתבסס על מידע חלקי — הסוכן לא תמיד יודע מראש מה בדיוק יימצא כשיפעיל כלי מסוים. תכנון טוב מתייחס לכך במפורש, על ידי הכללת ענפים מותנים (conditional branches) בתוכנית עצמה — "אם נמצא X, המשך לצעד א'; אם נמצא Y, המשך לצעד ב'" — במקום להניח תוצאה אחת ולתקן רק כשהיא מתבררת כשגויה. זה מצמצם את הצורך ב-replanning מלא בהמשך, כי חלק מהחלופות כבר "מובנות" בתוכנית מראש. במשימות עם רמת אי-ודאות גבוהה במיוחד, לפעמים משתלם יותר לתכנן רק את הצעד הקרוב הבא בפירוט מלא, ולהשאיר את השאר ברמת מיתאר גס בלבד עד שמידע נוסף מתקבל — גישה היברידית בין Plan-and-Execute לבין ReAct.

Few-Shot Planning — שימוש בדוגמאות תוכניות קודמות

כשסוג המשימה חוזר על עצמו בתדירות גבוהה (למשל, כל בקשות ה-onboarding נראות מבנית דומות), שווה לבנות ספריית דוגמאות תוכניות מוצלחות שכבר בוצעו בפועל, ולהזין אותן כדוגמאות (few-shot examples) לשלב התכנון עבור משימות חדשות דומות. זה לא רק משפר את איכות התכנון (המודל "רואה" איך תוכנית טובה נראית עבור התחום הספציפי, לא רק מנחש מהבנה כללית) אלא גם מייצב את הפלט — פחות שונות בין תוכניות שנוצרות למשימות דומות, מה שמקל על ניפוי שגיאות ועל בניית לוגיקת ביצוע (executor) שמצפה למבנה תוכנית עקבי יחסית. שווה לתחזק את ספריית הדוגמאות באופן פעיל — להוסיף אליה תוכניות שהוכחו כמוצלחות במיוחד, ולהוציא ממנה תוכניות שהתבררו כבעייתיות בדיעבד.

הבדל בין תכנון מרכזי לתכנון מבוזר

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

מדידת איכות תוכנית לפני ביצוע

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

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

שאלות נפוצות

מתי כדאי שהתוכנית תעבור אישור אנושי לפני ביצוע?

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

מה ההבדל בין Planning ל-Orchestration?

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

האם צריך מודל נפרד לתכנון ומודל נפרד לביצוע?

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

איך מודדים שהתכנון טוב?

מספר הפעמים שנדרש replanning, שיעור השלמת משימות ללא התערבות אנושית, ומספר הצעדים המיותרים (redundant steps) בתוכנית בפועל מול המינימום ההכרחי.

תגיות: Agent Planning · Task Decomposition · ReAct · Plan and Execute · AI Agents · Replanning

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