AI Agents מול RPA: מתי סוכן חכם מחליף בוט כללים נוקשה

מאת צוות מדיה דיל · 04.08.2026 · Automation · 7 דק׳

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

עד לפני כמה שנים, "אוטומציה חכמה" הייתה בעיקרה RPA עם קצת machine learning מוזרק לתוכו - לרוב מודל סיווג לזיהוי מסמכים. היום, עם התבגרות ה-LLM Agents, יש אפשרות אמיתית לבנות סוכנים שלא רק מבצעים תסריט קבוע אלא מתכננים את הצעדים הבאים, קוראים כלים (tools) לפי הצורך, ומגיבים לאי-ודאות בזמן אמת. ההבדל בין RPA לבין AI Agent הוא לא רק ברמת התחכום - הוא שינוי פרדיגמה שלם באופן שבו בונים, בודקים, ומפקחים על אוטומציה.

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

RPA: ביצוע דטרמיניסטי של תסריט קבוע מראש

בוט RPA טיפוסי הוא state machine מוגדר מראש: צעד 1 קורה תמיד לפני צעד 2, עם ענפי if/else מוגדרים מראש לכל תרחיש ידוע. זה מבטיח דטרמיניזם מלא - אותו קלט תמיד יוצר את אותה תוצאה, בדיוק, בכל פעם. זו תכונה קריטית לתהליכים רגולטוריים שדורשים חזרתיות מוחלטת (למשל חישובי שכר או דיווחים פיננסיים), אבל היא גם המגבלה המרכזית: כל תרחיש שלא נחזה מראש ולא קיבל ענף if/else ייעודי, הבוט פשוט נכשל או מתנהג בצורה לא צפויה.

יתרון נוסף של הדטרמיניזם הוא היכולת לבצע formal verification - להוכיח מתמטית שהתהליך מתנהג נכון בכל תרחיש אפשרי, מה שקריטי בתעשיות עם רגולציה קפדנית כמו בנקאות מרכזית. אף מודל LLM כיום, מכל גודל שהוא, לא מציע רמת ודאות כזו - וזו הסיבה שבתהליכים עם השלכות רגולטוריות ישירות, כלל האצבע הוא לשמור את ליבת ההחלטה בקוד דטרמיניסטי ולתת ל-AI Agent תפקיד עזר בלבד (למשל ניסוח הסבר, לא קבלת ההחלטה עצמה).

AI Agents: תכנון דינמי מבוסס reasoning

AI Agent מבוסס LLM עובד אחרת לגמרי: הוא מקבל מטרה (goal) ולא תסריט, ניגש למאגר כלים זמינים (tools - יכולים להיות API calls, שאילתות database, או אפילו RPA actions), ומתכנן דינמית איזה כלים להפעיל ובאיזה סדר כדי להשיג את המטרה. ארכיטקטורת ה-ReAct (Reasoning + Acting) הפכה לסטנדרט דה-פקטו: הסוכן חושב (thought), פועל (action), צופה בתוצאה (observation), וחוזר על הלולאה עד שהמטרה מושגת.

// דוגמה פשטנית ללולאת ReAct של AI Agent
Thought: הלקוח ביקש להחזיר כסף על הזמנה. צריך לבדוק סטטוס הזמנה קודם.
Action: get_order_status(order_id="12345")
Observation: { status: "delivered", amount: 340, days_since: 12 }
Thought: מדיניות ההחזרים מאפשרת עד 14 יום. אפשר לאשר את ההחזר.
Action: process_refund(order_id="12345", amount=340)
Observation: { success: true, refund_id: "rf_9981" }
Thought: ההחזר בוצע בהצלחה. אפשר לעדכן את הלקוח.

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

ארכיטקטורת ה-tools עצמה ראויה להתעכבות. כל tool שנחשף לסוכן הוא בעצם פונקציה עם schema מוגדר (בדרך כלל JSON Schema) שמתאר את הפרמטרים הנדרשים ואת מטרת הפונקציה בשפה טבעית. איכות התיאור הזה משפיעה ישירות על יכולת המודל לבחור נכון מתי להשתמש בכלי - תיאור מעורפל מוביל לבחירות שגויות, גם אם הקוד מאחורי ה-tool תקין לחלוטין. בפרודקשן, כתיבת תיאורי tools מדויקים היא לרוב חלק גדול יותר מהעבודה מכפי שנראה בהתחלה.

המחיר של הגמישות: אי-דטרמיניזם וצורך בגבולות

הגמישות הזו מגיעה עם מחיר אמיתי: LLM Agents הם לא דטרמיניסטיים מטבעם. אותה קריאה יכולה, תיאורטית, להוביל להחלטות שונות מעט בין הרצות. זה בעייתי בתהליכים שדורשים ודאות מוחלטת. הפתרון בפרודקשן הוא לא לתת לסוכן חופש בלתי מוגבל, אלא לעטוף אותו בguardrails ברורים: אילו tools הוא בכלל יכול לקרוא (allowlist מוגדר, לא גישה חופשית לכל המערכת), אילו פעולות דורשות אישור אנושי (human-in-the-loop) לפני ביצוע בפועל - במיוחד פעולות בלתי הפיכות כמו החזר כספי או מחיקת רשומה - ולוגים מפורטים של כל צעד חשיבה והחלטה לצורך audit.

הפרקטיקה המומלצת שהתגבשה בשנתיים האחרונות היא מודל "circuit breaker" לסוכנים: הגבלת מספר צעדי ה-reasoning המקסימלי לפני עצירה כפויה (למניעת לולאות אינסופיות), timeout כולל לכל ריצה, ו-budget מקסימלי בטוקנים לכל session. בלי הגבלות כאלה, סוכן שנתקל בבעיה לא צפויה עלול "להסתובב" בין ניסיונות כושלים במשך זמן רב, צובר עלות ולעיתים אף מבצע פעולות לא רצויות בניסיון "לפתור" את הבעיה בכל מחיר.

מודל העלות: token-based מול license-based

ההבדל התפעולי הכי פחות מדובר אבל הכי משמעותי: RPA מתומחר לרוב לפי רישיון בוט (per-bot license) - עלות קבועה בלי קשר לכמות הרצות. AI Agent מתומחר לפי טוקנים - כל thought, כל tool call, כל תשובה של המודל צורכת טוקנים שעולים כסף. תהליך עם agent שמבצע 15 צעדי reasoning כדי להגיע להחלטה יכול לעלות משמעותית יותר מבוט RPA שמבצע את אותה פעולה ב-3 צעדים דטרמיניסטיים. לכן, agent לא תמיד "יותר טוב" כלכלית - צריך לחשב עלות-תועלת אמיתית, במיוחד עבור נפחים גבוהים.

יש גם טכניקה שמצמצמת עלות משמעותית: שימוש במודל קטן וזול לרוב המקרים הפשוטים, עם escalation למודל גדול ויקר יותר רק במקרים מורכבים או כשה-confidence של המודל הקטן נמוך. ארכיטקטורת "router" כזו, שמנתבת כל בקשה למודל המתאים ביותר לרמת המורכבות שלה, יכולה לצמצם עלות תפעולית ב-50-70% ביחס לשימוש גורף במודל היקר ביותר לכל בקשה, כמעט בלי לפגוע באיכות התוצאה הסופית.

מהירות פיתוח ותחזוקה

בוט RPA לתהליך פשוט וקבוע לרוב מהיר יותר לבנייה בפעם הראשונה - מקליטים את התהליך, מגדירים selectors, וזהו. AI Agent דורש עבודת prompt engineering, הגדרת tools מדויקת, ובדיקות מקיפות על מגוון תרחישי קצה כי ההתנהגות פחות צפויה מראש. אבל התחזוקה לאורך זמן הפוכה: RPA שובר בכל שינוי UI, בעוד Agent שמדבר עם APIs יציבים ומבוסס reasoning גמיש הרבה יותר עמיד לשינויים קטנים בתרחיש, כי הוא לא תלוי בתסריט מדויק אלא במטרה.

יש גם עניין של בדיקות (testing). בדיקת בוט RPA היא לרוב בינארית - עובד או לא עובד לתרחיש נתון. בדיקת AI Agent דורשת גישה סטטיסטית: evaluation set של עשרות עד מאות תרחישים מייצגים, מדידת שיעור הצלחה לאורך זמן, ומעקב אחרי regression כשמעדכנים prompt או מחליפים מודל. זו תרבות בדיקות שונה לגמרי מזו שרוב צוותי ה-QA מכירים מ-RPA, ודורשת השקעה בתשתית evaluation ייעודית כבר משלב מוקדם בפרויקט.

ניהול זיכרון והקשר לאורך אינטראקציה מתמשכת

הבדל נוסף שקל לפספס: בוט RPA "שוכח" הכל בין הרצה להרצה - כל execution הוא עולם סגור עם קלט ופלט מוגדרים, בלי מצב פנימי שנשמר. AI Agent, לעומת זאת, לרוב פועל בתוך שיחה או session מתמשך שבו הקשר קודם משפיע על החלטות עתידיות - וזה דורש ארכיטקטורת memory ייעודית. יש כמה רמות: short-term memory (היסטוריית ההודעות בתוך שיחה בודדת, שפשוט נכנסת בכל פעם מחדש לתוך context window), ו-long-term memory (מידע שצריך להישמר בין שיחות שונות, לרוב במסד וקטורי שנשלף לפי רלוונטיות לשיחה הנוכחית).

הניהול הזה מייצר בעיה הנדסית מעניינת: context window של מודל שפה מוגבל בגודלו, וככל ששיחה מתארכת, צריך להחליט מה לשמור מילה במילה, מה לסכם, ומה פשוט לזרוק. אסטרטגיית סיכום גרועה עלולה לאבד מידע קריטי שהוזכר מוקדם בשיחה, בעוד שמירת הכל ללא סינון מובילה לעלות טוקנים גבוהה ולירידה באיכות התשובות ככל שהקשר הרלוונטי "מוצף" בפרטים משניים. פתרונות בשלים משלבים חלון גולש (sliding window) של ההודעות האחרונות עם סיכום רץ (rolling summary) של כל מה שקדם לו, כדי לשמר את המהות בלי לחרוג ממגבלת ההקשר.

מתי RPA עדיין הבחירה הנכונה

לתהליכים חוזרים, פשוטים, וודאיים לחלוטין - הזנת נתונים בין שתי מערכות בפורמט קבוע, חישובים דטרמיניסטיים, דוחות תקופתיים במבנה קבוע - RPA (או אוטומציה מבוססת API פשוטה) עדיין עדיפה: זולה יותר, צפויה יותר, וקלה יותר ל-audit. שימוש ב-AI Agent לתהליך כזה הוא overengineering שמוסיף עלות ואי-ודאות ללא תועלת אמיתית.

מתי AI Agent הופך הכרחי

כשיש שונות אמיתית בקלט (טפסים חופשיים, שיחות לקוח, מסמכים לא סטרוקטורליים), כשצריך שיפוט הקשרי (context-dependent judgment) שקשה לקודד כללים עבורו, או כשמספר התרחישים האפשריים גדול מכדי לתחזק עץ if/else סביר - שם AI Agent מתחיל להצדיק את העלות והמורכבות הנוספת. דוגמה טובה: תמיכת לקוחות שצריכה לסווג ולטפל בפניות מגוונות שאי אפשר לצפות את כולן מראש.

נקודת מעבר טובה לזיהוי היא כשגודל עץ ה-if/else של פתרון RPA/כללים מתחיל לצמוח באופן בלתי נשלט - כשכל תיקון של edge case אחד יוצר שני edge cases חדשים, וצוות הפיתוח מבלה יותר זמן בתחזוקת הכללים מאשר בפיתוח פיצ'רים חדשים. זהו איתות ברור שהבעיה כנראה דורשת שיפוט הקשרי ולא עוד ענף תנאי.

טעויות נפוצות בפרודקשן

  • מתן גישה לא מוגבלת לסוכן לכל ה-tools והנתונים במקום allowlist ברור - סיכון אבטחה ותקציב כאחד.
  • אי-הוספת human-in-the-loop לפעולות בלתי הפיכות כמו החזרים כספיים או מחיקות.
  • שימוש ב-agent במקום כלל פשוט - overkill יקר ובלתי צפוי לבעיה שכלל if/else פותר מצוין.
  • אי-ניטור עלויות טוקנים - agent שנתקע בלולאת reasoning יכול לצרוך תקציב משמעותי בלי שאף אחד שם לב.
  • חוסר evaluation set קבוע - בלי מדדי בדיקה אוטומטיים, קשה לדעת אם שינוי ב-prompt שיפר או פגע בהתנהגות הסוכן.

סיכום: לא תחליף, אלא כלי נוסף בארגז

AI Agents לא מחליפים RPA - הם פותרים סוג בעיה אחר. ארגונים בוגרים מחזיקים את שניהם: RPA/אוטומציית API לתהליכים דטרמיניסטיים בהיקף גבוה, ו-AI Agents לתהליכים שדורשים שיפוט והתמודדות עם שונות. בהרבה מקרים הארכיטקטורה הטובה ביותר היא בכלל היברידית ברמת תהליך בודד: agent מקבל את המטרה הכללית ומתכנן את הצעדים, אבל כל צעד בפועל מבוצע דרך tool דטרמיניסטי ובדוק - כלומר ה-AI אחראי על ה"מה ומתי", והקוד הרגיל אחראי על ה"איך". זה משלב את הגמישות של הסוכן עם היציבות של ביצוע דטרמיניסטי, שומר על עלות מבוקרת כי רק שלב ה"מה ומתי" צורך טוקנים בעוד רוב הביצוע בפועל זול וצפוי, ומאפשר גם audit ברור: אפשר לראות בדיוק אילו tools הופעלו ומתי, גם אם ה-reasoning שהוביל לבחירה לא לגמרי דטרמיניסטי. במדיה דיל אנחנו בדרך כלל ממליצים להתחיל מהשאלה "האם התהליך באמת דורש שיפוט, או שהוא רק נראה מורכב כי אף אחד לא טרח למפות את כל התרחישים?" - התשובה חוסכת הרבה כסף ופיתוח מיותר.

תגיות: AI Agents · RPA · LLM agents · ReAct · human-in-the-loop · אוטומציה חכמה · process automation

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