LLMs לא חודרים לקוד שלך – הם מגישים לך בקשה, ואתה מריץ את הפונקציה. העובדה הפשוטה הזו הופכת את המיתוס ש"המודל קורא באופן קסם לשגרת ה-Python שלי" ומאלצת מפתחים לחשוב מחדש על ניפוי שגיאות (debugging) ואבטחה.
לולאת הניתוב (dispatch loop), שלב אחר שלב
כאשר מודל שפה (LLM) זקוק לכלי, הוא פועל לפי רצף דטרמיניסטי:
- תכנון (Planning) – המודל מחליט שנדרשת פעולה (למשל, "החזרת תשלום").
- יצירת בקשה (Generating a request) – הוא מוציא טקסט מובנה — בדרך כלל JSON — המציין את שם הכלי ומספק ארגומנטים.
- ניתוח (Parsing) – האפליקציה שלך או תשתית (framework) תומכת קוראת את הטקסט הזה.
- התאמה (Matching) – התשתית מחפשת את השם ברישום (registry) של הפונקציות האמיתיות שחשפת.
- אימות (Validating) – היא בודקת שהארגומנטים תואמים לסכימה (schema) של הפונקציה ושהקורא מורשה.
- ביצוע (Executing) – הפונקציה שנמצאה מתבצעת בסביבה שלך ומבצעת את העבודה.
- החזרה (Returning) – התוצאה נארזת ונשלחת חזרה למודל לצורך המשך חשיבה.
חשבו על ה-LLM כמתכנן, על ה-framework כמנתב (dispatcher), ועל הפונקציה כעובד שמזיז בפועל נתונים או כסף.
למה מיתוס ה"קסם" נמשך
רוב המפתחים רואים שורה בודדת של פלט מהמודל שנראית כמו קריאה לפונקציה, ומניחים שהמודל ביצע את הפעולה בעצמו. המונח "tool calling" בתיעוד של הספקים נשמע כאילו המודל מפעיל קוד באופן ישיר.
במציאות, המודל רק מייצר טקסט שמתאר קריאה. התהליך שלכם עושה את העבודה הקשה — חיפוש, בדיקת טיפוסים, אכיפת הרשאות וטיפול בשגיאות.
תשתיות (Frameworks) שמסתירות את ה"צנרת"
ספריות כמו PydanticAI ו-LangChain מבצעות הפשטה (abstraction) של הלולאה כדי שתוכלו להתמקד בלוגיקה העסקית. הן מבצעות באופן אוטומטי:
- אימות ארגומנטים מול סכימה (למשל, Pydantic model).
- אכיפת הרשאות, כדי להבטיח שהמשתמש מורשה להפעיל את הכלי.
- ניסיון חוזר (Retry) במקרה של כישלון, על ידי חזרה למודל כאשר כלי מחזיר שגיאה.
- הגנה מפני לולאות אינסופיות, על ידי הגבלת מספר קריאות הכלי הרצופות.
- שמירה על מצב השיחה (conversation state), על ידי שילוב תוצאות הכלי בתוך הדיאלוג.
גם עם העוזרים הללו, הדפוס נשאר זהה: המודל לעולם אינו מריץ קוד.
תמיכה מובנית (Native) ב-tool-calling מהספקים
חלק מהספקים מספקים ממשק "native" ל-tool-calling שמתקנן הגדרות כלים ופורמטים של בקשות. זה מקל על האינטגרציה אך לא מסיר את שלב הניתוב (dispatch). אתם עדיין כותבים (או מייבאים) את הקוד שמריץ בפועל את הפעולה המבוקשת.
ניפוי שגיאות (Debugging) הופך לקל יותר כשמשנים את שם הבעיה
במקום להאשים "סוכן מבולבל" (confused agent), אמרו שהבעיה היא ש"תגובת המודל לא הכילה קריאות לכלי". ההבחנה הזו חשובה:
- אין קריאה לכלי (No tool call) – המודל ענה ישירות או נכשל ביצירת בקשה בפורמט תקין.
- בקשה לא תקינה (Malformed request) – ה-JSON שגוי מבחינה תחבירית או שחסרים בו שדות חובה, ולכן המנתב (dispatcher) דוחה אותו.
- כישלון אימות (Validation failure) – הארגומנטים אינם תואמים לסכימה, מה שגורם לשגיאה לפני הביצוע.
סיווג הכשלים מאפשר לכם לתעד (log) כל שלב בלולאה ולאתר בדיוק היכן הדברים יצאו מהמסלול.
טיפים מעשיים לתשתית (pipeline) אמינה
- התייחסו לפלט המודל כקלט לא מהימן. העבירו כל בקשה דרך אימות דטרמיניסטי לפני הפעלת קוד בעל השפעות לוואי (side-effecting code).
- תעדו (Log) את הבקשה הגולמית ואת התוצאה של כל שלב אימות. זה יוצר עקבות שניתן לשחזר כאשר משהו משתבש.
- הגדירו מגבלות מפורשות על קריאות כלי רצופות; לולאה שאינה נשלטת עלולה לרוקן משאבים או להגיע למגבלות קצב (rate limits).
- עטפו כל פונקציה בבלוק try/except שמחזיר אובייקט שגיאה מובנה שהמודל יכול להבין, מה שיכול להוביל לניסיון חוזר או לנסיגה מבוקרת (graceful fallback).
- פרידו בין בדיקות הרשאה לבין הלוגיקה העסקית. ודאו את זכויות הקורא לפני שהפונקציה רצה, במיוחד עבור פעולות בעלות הרשאה גבוהה כמו "מחיקת משתמש".
- השתמשו בהגדרות מונעות-סכימה (למשל, Pydantic models) כדי שהתשתית תוכל לייצר אוטומטית את סכימת ה-JSON שהמודל חייב לעקוב אחריה.
מה כדאי לעקוב אחריו בהמשך
ככל שהספקים ישפרו את ממשקי ה-API ה-native ל-tool-calling, צפו לחוזים (contracts) הדוקים יותר סביב פורמטים של בקשות וקודי שגיאה עשירים יותר. שינויים אלו יהפכו את האימות לקל יותר ויאפשרו למפתחים לבנות מגנוני אבטחה מחמירים יותר. עקבו אחר עדכוני ספריות — רבות מהן מוסיפות תמיכה מובנית בתכונות החדשות ביותר של הספקים.
שורה תחתונה
ה-LLM הוא מחולל טקסט מתוחכם, לא executor. הקוד שלך נותר הסמכות היחידה שמבצעת פעולות, וה-dispatcher שבנית (או ייבאת) הוא ה-gatekeeper שמאמת, מאשר ומריץ את הפעולות הללו. הגדרה מחדש של ה-workflow מבטלת את מיתוס ה"קסם", מחדדת את ה-debugging ואוכפת את משמעת האבטחה שכל מערכת production זקוקה לה.