יחידה 9 / 11

סוכני AI ושימוש בכלים

רווחים:

  • הגדרת סוכן כ'מודל + כלים + לולאה' והחלטה מתי יש צורך בכך
  • כתיבת הגדרת הכלי עם שם, תיאור ו-input_schema
  • ניטור הזרימה והטיפול בשגיאות של לולאת tool_use ו-tool_result

עד עכשיו, המודל תמיד עשה עבודה אחת: קבלת קלט טקסט, הפקת תגובות טקסט. אבל עבודה אמיתית דורשת לרוב יותר מטקסט; ביצוע חישוב, שאילתה למסד נתונים, קריאה ל-API, גילוי שער חליפין עדכני. הדוגמנית לא יכולה לעשות את הדברים האלה בעצמה - אבל היא יכולה להחליט מתי הם צריכים להיעשות ולבקש ממישהו לעשות אותם. זה מה שהשימוש בכלים נותן למודל, וזה הבסיס של סוכני AI. ביחידה זו נלמד מהו סוכן, כיצד מוגדר הכלי וכיצד פועלת לולאת tool_use.

מה זה סוכן? דגם + כלים + לולאה

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

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

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

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

הגדרת כלי: שם, תיאור, input_schema

כדי להכניס כלי למודל, אתה נותן שלושה דברים:

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

# הגדרת רכב (קונספטואלית — JSON schema){ "name": "get_order_status", "description": "מאחזר את סטטוס המשלוח הנוכחי של הזמנה. התקשר כאשר המשתמש שואל היכן מספר הזמנה או מתי היא תגיע.", "input_schema": { "type": "object", "properties": { "order_scription": ",Order_no": string", למשל SP-1024"} }, "נדרש": ["הזמנה_לא"] }}

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

אזור

מה זה עושה?

דוגמה טובה

דוגמה רעה

שם

מזהה רכב

order_status_getir

להביא

תיאור

מה זה עושה + מתי להתקשר

"מחזיר את מצב המטען; התקשר כשהמשתמש שואל היכן ההזמנה"

"שואב נתונים"

input_schema

סוג פרמטר ודרישה

{order_no: מחרוזת, מוערת}

ללא דיאגרמה / ללא תיאור

tool_use → tool_result לולאה

המחזור עובד כך, צעד אחר צעד:

  1. אתה שולח את שאלת המשתמש + תיאורי הכלים לדגם.
  2. המודל מגיב ישירות או יוצר בלוק tool_use: "קורא order_durumu_getir עם order_no=SP-1024."
  3. היישום שלך למעשה מריץ את הכלי (שאילתות במסד הנתונים).
  4. אתה שולח את התוצאה בחזרה למודל בתור tool_result.
  5. עם תוצאה זו, המודל מייצר את התשובה הסופית או קורא לכלי אחר. המחזור נמשך עד שהדגם אומר "סיימתי".

# לולאת סוכן (קונספטואלית) הודעות = [user_question]while True: response = model.uret(messages, tools=tool_definitions) if response.tur == "tool_use": result = harness.run(response.tool_name, response.entries) # APPLICATION מפעיל הודעות כלי +_= [תגובה תוצאה, תוצאה סופית: הפסקה תגובה; לולאה מסתיימת

ערכות SDK מודרניות מציעות רצי כלים שמריצים את הלולאה הזו עבורך; אתה פשוט כותב את פונקציות הכלי. אבל זה בדיוק מה שקורה מאחורי הקלעים.

ניהול שגיאות

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

תיאור רכב חלש/חזק

חלש (שם עצם בלתי מוגדר, ללא "מתי"):

שם: "נתונים", תיאור: "מביא נתונים"# המודל לא יודע מתי ואיך להתקשר; או שהוא לא מתקשר בכלל או מתקשר בצורה לא נכונה.

חזק (שם נטו + כאשר + תיאור פרמטר):

name: "musteri_bakiyesi_getir"description: "מחזיר את יתרת החשבון השוטף של לקוח. התקשר כאשר המשתמש מבקש חיוב, זיכוי או יתרה. לא מבצע תשלום."input_schema: {custeri_id: string ("מזהה לקוח")}# המודל מתקשר בזמן הנכון, עם הפרמטרים הנכונים, בידיעה המגבלה שלו.

שלושה מיני מארזים

מקרה 1 - סוכן מיותר. צוות אחד בנה את העסק של "סיכום טקסט" עם סוכן מרובה כלים; כל סיכום לוקח 4 שיחות דגם ו-9 שניות. העבודה הייתה למעשה עבודה של שיחה אחת. כשהסרנו את הסוכן וצמצמנו אותו לשיחה אחת, הזמן ירד ל-1.5 שניות והעלות ירדה לרבעון. לקח: השתמש בסוכן כשממש יש צורך.

מקרה 2 - הסבר חלש, שיחה שגויה. בסוכן תמיכה, כלי לא ברור שנקרא אחזור נקרא באקראי על ידי המודל הן בשאלת האיזון והן בשאלת המשלוח. כאשר הרכבים חולקו ל-balance_getir ו-cargo_durumu_getir ונוספו הסברים "התקשר כאשר", בחירת רכב שגויה ירדה מ-18 ל-1 מתוך 50 דוגמאות.

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

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

  • הפיכת הכל לסוכן: בעוד שיחה אחת מספיקה, הסוכן מוסיף עלות ועיכוב.
  • תיאור רכב מעורפל: הדגם לא יודע מתי להתקשר; בוחר לא נכון.
  • לחשוב שהדגם מפעיל את הרכב: הרתמה מפעילה את הרכב; הדוגמנית רק רוצה.
  • בליעת השגיאה: על הדוגמנית לדעת מה השתבש; תן את השגיאה בתור open tool_result.
  • יותר מדי רכבים דומים: הדגם מתבלבל; שמור על ערכת הכלים ממוקדת ומינימלית.
שימו לב: זה שהדגם אומר "קרא לזה רכב" לא אומר שצריך לעשות מעשה. בכלים הרסניים (מחיקה, צ'ק-אאוט, דוא"ל) האפליקציה שלך לא אמורה לבצע את השיחה באופן עיוור - זה הליבה של נושא האבטחה ביחידה הבאה.

לסיכום

  • סוכן = מודל (החלטה) + כלים (פונקציות) + לולאה (כלי קריאה, קבל תוצאה, החליט שוב).
  • שיחת דפוס יחיד אינה סוכן; הסוכן הוא תהליך שלב אחר שלב.
  • הדגם אינו מריץ את הרכב; היישום שלך פועל (רתום) ומחזיר את התוצאה בתור tool_result.
  • הכלי מזוהה לפי שם, תיאור (במיוחד "התקשר כאשר") ו-input_schema.
  • הלולאה ממשיכה כאשר tool_use → רתמה פועלת → tool_result → המודל ממשיך עד שהמודל אומר "בוצע"; שגיאות מדווחות במפורש למודל.

משימת יישום

עיצוב 3 כלים מהעסק שלך שניתן לתת לסוכן. (1) כתוב שם, תיאור עם "התקשר כאשר", ו-input_schema עבור כל אחד מהם; תנו לפחות אחד להיות כלי קריאה לא הרסני ואחד לחישוב. (2) בחר שאלת משתמש מציאותית וכתוב ידנית שלב אחר שלב (בלולאה) לאיזה מהכלים הללו המודל יקרא עם אילו כניסות ומה הוא יעשה לאחר הגעת tool_result. (3) הגדר תרחיש שבו אחד הכלים נכשל והראה כיצד הודעת השגיאה תחזור למודל.

רשימת בדיקה

  • [ ] אני יכול להגדיר את הסוכן כ"מודל + כלים + לולאה" ולהחליט מתי הוא נחוץ.
  • [ ] אני יודע שהרתמה מפעילה את הרכב, הדוגמנית רק רוצה את זה.
  • אני יכול לכתוב תיאור רכב מוצק עם שם [ ], תיאור ("התקשר כאשר") ו-input_schema.
  • אני יכול לעקוב אחר מחזור [ ] tool_use → tool_result שלב אחר שלב.
  • [ ] אני מדווח על שגיאות בכלי למודל בתור open tool_result.