Tool Use — כלים לסוכנים

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

לולאת הסוכן — תזכורת

סוכן פועל בלולאה: המודל מקבל מטרה + רשימת כלים, מחליט אילו להפעיל, הקוד מריץ אותם ומחזיר תוצאות, וחוזר חלילה עד שהמשימה הושלמה.

while not done:
    response = model.generate(messages, tools=TOOLS)
    if response.tool_calls:
        for call in response.tool_calls:
            result = run_tool(call.name, call.input)   # הקוד שלך מריץ
            messages.append(tool_result(call.id, result))
    else:
        done = True   # המודל סיים והחזיר תשובה סופית

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

עיצוב כלי טוב — 6 עקרונות

1. שם ותיאור ברורים. התיאור הוא ה"פרומפט" של הכלי. get_order_status עם תיאור "מחזיר סטטוס הזמנה לפי מספר הזמנה" עדיף פי כמה על lookup בלי הסבר. כתוב מתי להשתמש ומתי לא.
2. מעט פרמטרים, מוגדרים היטב. כל פרמטר עם תיאור, טיפוס ו-enum כשאפשר. פחות פרמטרים = פחות טעויות.
3. כלי אחד = משימה אחת. אל תבנה כלי-על שעושה עשרה דברים לפי דגל. פצל לכלים ממוקדים.
4. תוצאות תמציתיות. החזר רק את מה שהמודל צריך. אל תחזיר 5,000 שורות JSON — סנן/סכם (ראו Context Engineering).
5. הגבל את מספר הכלים. יותר מדי כלים מבלבלים. אם יש הרבה, קבץ לפי הקשר או השתמש בשליפה דינמית.
6. שמות עקביים. אותה קונבנציה לכל הכלים — קל למודל ללמוד את הדפוס.

טיפול בשגיאות — אל תיתן לכלי להפיל את הסוכן

כלי שנכשל צריך להחזיר הודעת שגיאה ברורה למודל, לא להתרסק. המודל יכול לקרוא את השגיאה ולנסות אחרת:

def run_tool(name, args):
    try:
        return TOOLS[name](**args)
    except Exception as e:
        # מחזירים את השגיאה למודל כתוצאה, לא זורקים
        return {"error": str(e), "hint": "בדוק את הפרמטרים ונסה שוב"}

• שגיאות ולידציה: אם פרמטר לא חוקי, אמור למודל בדיוק מה לא בסדר.
• הגבל ניסיונות. אם הסוכן נכשל באותו כלי 3 פעמים — עצור והסלם, אל תיכנס ללולאה אינסופית.
• Timeouts: כלי איטי (API חיצוני) צריך timeout כדי לא לתקוע את הסוכן.

Human-in-the-loop — לכלים מסוכנים

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

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

אורכסטרציה של כמה כלים

כשמשימה דורשת רצף כלים (חפש → סנן → פעל), המודל מנהל את הסדר. כדי שזה יעבוד:

• תיאורים שמרמזים על רצף ("השתמש ב-search_products לפני add_to_cart").
• החזר מזהים שהמודל יכול להעביר לכלי הבא (למשל order_id).
• Sub-agents למשימות מורכבות — סוכן-משנה עם קבוצת כלים משלו והקשר נקי.
• לחיבור כלים חיצוניים בצורה סטנדרטית — MCP.

אבטחה — כלים הם משטח תקיפה

כלי נותן למודל יכולת לפעול בעולם האמיתי — וזה מסוכן אם המודל "מושפע" מprompt injection:

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