העתיד של סוכני AI טמון ביכולת של מודלים לעבוד בצורה חלקה עם מאות או אלפי כלים. דמיינו עוזר IDE שיודע לשלב פעולות Git, מניפולציה של קבצים, מנהלי חבילות, פריימוורקים לבדיקות וצינורות פריסה (deployment pipelines). או רכז תפעול שמחבר בין Slack, GitHub, Google Drive, Jira, מסדי נתונים ארגוניים ועשרות שרתי MCP בו-זמנית.

כדי לבנות סוכנים יעילים, עליהם להיות מסוגלים לעבוד עם ספריות כלים בלתי מוגבלות, מבלי לדחוף כל הגדרה לחלון ההקשר (context window) מראש. כתבת הבלוג שלנו על ביצוע קידוד עם MCP דנה כיצד תוצאות והגדרות של כלים יכולות לעיתים לצרוך למעלה מ-50,000 טוקנים עוד לפני שהסוכן קורא בקשה. סוכנים צריכים לגלות ולטעון כלים לפי דרישה, ולשמור בחלון ההקשר רק את מה שרלוונטי למשימה הנוכחית.

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

כמו כן, סוכנים צריכים ללמוד שימוש נכון בכלים מתוך דוגמאות, ולא רק מהגדרות סכמה. סכמות JSON מגדירות מה תקף מבנית, אך אינן יכולות לבטא דפוסי שימוש: מתי לכלול פרמטרים אופציונליים, אילו שילובים הגיוניים, או אילו מוסכמות ה-API שלכם מצפה להן.

היום, אנו משחררים שלוש תכונות המאפשרות זאת:

  • Tool Search Tool, המאפשר לקלוד להשתמש בכלי חיפוש כדי לגשת לאלפי כלים מבלי לצרוך את חלון ההקשר שלו
  • Programmatic Tool Calling, המאפשר לקלוד לקרוא לכלים בסביבת ביצוע קידוד, ובכך להפחית את ההשפעה על חלון ההקשר של המודל
  • Tool Use Examples, המספק סטנדרט אוניברסלי להדגמת אופן השימוש היעיל בכלי נתון

בבדיקות פנימיות, מצאנו שתכונות אלו עזרו לנו לבנות דברים שלא היו אפשריים עם דפוסי שימוש בכלים קונבנציונליים. לדוגמה, Claude for Excel משתמש ב-Programmatic Tool Calling כדי לקרוא ולשנות גיליונות אלקטרוניים עם אלפי שורות, מבלי להעמיס יתר על המידה על חלון ההקשר של המודל.

מניסיוננו, אנו מאמינים שתכונות אלו פותחות אפשרויות חדשות עבור מה שתוכלו לבנות עם קלוד.

Tool Search Tool

האתגר

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

  • GitHub: 35 כלים (~26 אלף טוקנים)
  • Slack: 11 כלים (~21 אלף טוקנים)
  • Sentry: 5 כלים (~3 אלף טוקנים)
  • Grafana: 5 כלים (~3 אלף טוקנים)
  • Splunk: 2 כלים (~2 אלף טוקנים)

מדובר ב-58 כלים הצורכים כ-55 אלף טוקנים עוד לפני שהשיחה מתחילה. הוסיפו שרתים נוספים כמו Jira (שבדומה לו לבדו צורך כ-17 אלף טוקנים) ואתם מתקרבים במהרה לעלות תקורה של למעלה מ-100 אלף טוקנים. באנתרופיק, ראינו הגדרות כלים שצרכו 134 אלף טוקנים לפני אופטימיזציה.

אך עלות הטוקנים אינה הבעיה היחידה. הכשלים הנפוצים ביותר הם בחירת כלי שגויה ופרמטרים לא נכונים, במיוחד כאשר לכלים יש שמות דומים כמו notification-send-user מול notification-send-channel.

הפתרון שלנו

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

גישה מסורתית:

  • כל הגדרות הכלים נטענות מראש (~72 אלף טוקנים עבור למעלה מ-50 כלי MCP)
  • היסטוריית השיחה וה-System Prompt מתחרים על המקום הנותר
  • צריכת חלון הקשר כוללת: כ-77 אלף טוקנים לפני תחילת כל עבודה

עם ה-Tool Search Tool:

  • רק ה-Tool Search Tool נטען מראש (~500 טוקנים)
  • כלים מתגלים לפי דרישה בעת הצורך (3-5 כלים רלוונטיים, ~3 אלף טוקנים)
  • צריכת חלון הקשר כוללת: כ-8.7 אלף טוקנים, מה ששומר על 95% מחלון ההקשר

זה מייצג הפחתה של 85% בשימוש בטוקנים תוך שמירה על גישה לספריית הכלים המלאה שלכם. בדיקות פנימיות הראו שיפורי דיוק משמעותיים בהערכות MCP בעבודה עם ספריות כלים גדולות. Opus 4 השתפר מ-49% ל-74%, ו-Opus 4.5 השתפר מ-79.5% ל-88.1% עם ה-Tool Search Tool מופעל.

כיצד ה-Tool Search Tool פועל

ה-Tool Search Tool מאפשר לקלוד לגלות כלים באופן דינמי במקום לטעון את כל ההגדרות מראש. אתם מספקים את כל הגדרות הכלים שלכם ל-API, אך מסמנים כלים עם defer_loading: true כדי להפוך אותם לניתנים לגילוי לפי דרישה. כלים נדחים אינם נטענים לחלון ההקשר של קלוד בתחילה. קלוד רואה רק את ה-Tool Search Tool עצמו בתוספת כלים עם defer_loading: false (הכלים הקריטיים והנפוצים ביותר שלכם).

כאשר קלוד זקוק ליכולות ספציפיות, הוא מחפש כלים רלוונטיים. ה-Tool Search Tool מחזיר הפניות לכלים תואמים, אשר מתרחבים להגדרות מלאות בחלון ההקשר של קלוד.

לדוגמה, אם קלוד צריך לתקשר עם GitHub, הוא מחפש "github", ורק github.createPullRequest ו-github.listIssues נטענים – ולא 50+ הכלים האחרים שלכם מ-Slack, Jira ו-Google Drive.

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

הערה על שמירת פרומפטים במטמון (Prompt caching): ה-Tool Search Tool אינו שובר את שמירת הפרומפטים במטמון (prompt caching) מכיוון שכלים נדחים אינם נכללים בפרומפט הראשוני כלל. הם מתווספים לחלון ההקשר רק לאחר שקלוד מחפש אותם, כך שה-System Prompt והגדרות הכלים המרכזיות שלכם נשארים ניתנים לשמירה במטמון.

Implementation:

{
  "tools": [
    // Include a tool search tool (regex, BM25, or custom)
    {"type": "tool_search_tool_regex_20251119", "name": "tool_search_tool_regex"},

    // Mark tools for on-demand discovery
    {
      "name": "github.createPullRequest",
      "description": "Create a pull request",
      "input_schema": {...},
      "defer_loading": true
    }
    // ... hundreds more deferred tools with defer_loading: true
  ]
}

עבור שרתי MCP, ניתן לדחות טעינה של שרתים שלמים תוך שמירה על טעינת כלים ספציפיים בעלי שימוש גבוה:

{
  "type": "mcp_toolset",
  "mcp_server_name": "google-drive",
  "default_config": {"defer_loading": true}, # defer loading the entire server
  "configs": {
    "search_files": {
"defer_loading": false
    }  // Keep most used tool loaded
  }
}

פלטפורמת המפתחים של קלוד מספקת כלי חיפוש מבוססי Regex ו-BM25 מחוץ לקופסה, אך ניתן גם ליישם כלי חיפוש מותאמים אישית באמצעות embeddings או אסטרטגיות אחרות.

מתי להשתמש ב-Tool Search Tool

כמו כל החלטה ארכיטקטונית, הפעלת ה-Tool Search Tool כרוכה בפשרות. התכונה מוסיפה שלב חיפוש לפני קריאת הכלי, ולכן היא מספקת את החזר ה-ROI הטוב ביותר כאשר החיסכון בחלון ההקשר ושיפורי הדיוק עולים על העיכוב הנוסף.

השתמשו בו כאשר:

  • הגדרות כלים צורכות מעל 10 אלף טוקנים
  • חווים בעיות דיוק בבחירת כלים
  • בונים מערכות מבוססות MCP עם מספר שרתים
  • ישנם 10+ כלים זמינים

פחות יעיל כאשר:

  • ספריית כלים קטנה (פחות מ-10 כלים)
  • כל הכלים נמצאים בשימוש תכוף בכל סשן
  • הגדרות הכלים קומפקטיות

Programmatic Tool Calling

האתגר

קריאת כלים מסורתית יוצרת שתי בעיות מהותיות ככל שתהליכי העבודה הופכים מורכבים יותר:

  • זיהום חלון ההקשר מתוצאות ביניים: כאשר קלוד מנתח קובץ לוג בנפח 10MB לדפוסי שגיאות, הקובץ כולו נכנס לחלון ההקשר שלו, למרות שקלוד זקוק רק לסיכום של תדירות השגיאות. בעת שליפת נתוני לקוחות מטבלאות מרובות, כל רשומה מצטברת בחלון ההקשר ללא קשר לרלוונטיות. תוצאות ביניים אלו צורכות תקציבי טוקנים עצומים ויכולות לדחוק מידע חשוב לחלוטין מחוץ לחלון ההקשר.
  • תקורה של הסקה וסינתזה ידנית: כל קריאת כלי דורשת מעבר הסקה מלא של המודל. לאחר קבלת התוצאות, קלוד נדרש "לבחון" את הנתונים כדי לחלץ מידע רלוונטי, להסיק כיצד פיסות המידע משתלבות יחד ולהחליט מה לעשות הלאה – והכול באמצעות עיבוד שפה טבעית. תהליך עבודה הכולל חמישה כלים משמעו חמישה מעברי הסקה בתוספת ניתוח של קלוד לכל תוצאה, השוואת ערכים וסינתזת מסקנות. תהליך זה איטי ומועד לשגיאות כאחד.

הפתרון שלנו

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

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

דוגמה: בדיקת עמידה בתקציב

שקלו משימה עסקית נפוצה: "אילו חברי צוות חרגו מתקציב הנסיעות שלהם ברבעון השלישי (Q3)?"

יש לכם שלושה כלים זמינים:

  • get_team_members(department) - מחזיר רשימת חברי צוות עם מזהים (IDs) ורמות
  • get_expenses(user_id, quarter) - מחזיר פריטי הוצאות עבור משתמש
  • get_budget_by_level(level) - מחזיר מגבלות תקציב עבור רמת עובד

גישה מסורתית:

  • שליפת חברי צוות ← 20 איש
  • עבור כל אדם, שליפת הוצאותיו ברבעון השלישי ← 20 קריאות כלי, כל אחת מחזירה 50-100 פריטי הוצאה (טיסות, מלונות, ארוחות, קבלות)
  • שליפת מגבלות תקציב לפי רמת עובד
  • כל אלה נכנסים לחלון ההקשר של קלוד: למעלה מ-2,000 פריטי הוצאה (50KB+)
  • קלוד מסכם ידנית את הוצאות כל אדם, מחפש את תקציבו, ומשווה הוצאות מול מגבלות תקציב
  • יותר נסיעות הלוך ושוב למודל, צריכת חלון הקשר משמעותית

עם Programmatic Tool Calling:

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

הנה כיצד קידוד התזמור של קלוד נראה עבור משימת בדיקת עמידה בתקציב:

team = await get_team_members("engineering")

# Fetch budgets for each unique level
levels = list(set(m["level"] for m in team))
budget_results = await asyncio.gather(*[
    get_budget_by_level(level) for level in levels
])

# Create a lookup dictionary: {"junior": budget1, "senior": budget2, ...}
budgets = {level: budget for level, budget in zip(levels, budget_results)}

# Fetch all expenses in parallel
expenses = await asyncio.gather(*[
    get_expenses(m["id"], "Q3") for m in team
])

# Find employees who exceeded their travel budget
exceeded = []
for member, exp in zip(team, expenses):
    budget = budgets[member["level"]]
    total = sum(e["amount"] for e in exp)
    if total > budget["travel_limit"]:
        exceeded.append({
            "name": member["name"],
            "spent": total,
            "limit": budget["travel_limit"]
        })

print(json.dumps(exceeded))

חלון ההקשר של קלוד מקבל רק את התוצאה הסופית: שניים עד שלושה אנשים שחרגו מתקציבם. למעלה מ-2,000 פריטי ההוצאה, הסכומים הזמניים ובדיקות התקציב אינם משפיעים על חלון ההקשר של קלוד, ומפחיתים את הצריכה מ-200KB של נתוני הוצאות גולמיים לקילו-בייט בודד של תוצאות.

הישגי היעילות משמעותיים:

  • חיסכון בטוקנים: על ידי שמירה על תוצאות ביניים מחוץ לחלון ההקשר של קלוד, Programmatic Tool Calling מפחית דרמטית את צריכת הטוקנים. שימוש ממוצע ירד מ-43,588 ל-27,297 טוקנים, הפחתה של 37% במשימות מחקר מורכבות.
  • עיכוב מופחת: כל נסיעה הלוך ושוב ל-API דורשת הסקה של המודל (מאות מילישניות עד שניות). כאשר קלוד מתזמר למעלה מ-20 קריאות כלים בבלוק קידוד בודד, אתם מבטלים למעלה מ-19 מעברי הסקה. ה-API מטפל בביצוע הכלים מבלי לחזור למודל בכל פעם.
  • דיוק משופר: על ידי כתיבת לוגיקת תזמור מפורשת, קלוד מבצע פחות שגיאות מאשר בעת התמודדות עם ריבוי תוצאות כלים בשפה טבעית. שליפת ידע פנימית השתפרה מ-25.6% ל-28.5%; מדדי ביצועים של GIA מ-46.5% ל-51.2%.

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

כיצד Programmatic Tool Calling פועל

1. סמנו כלים כניתנים לקריאה מקידוד

הוסיפו code_execution לכלים, וקבעו את allowed_callers כדי להצטרף לכלים לביצוע פרוגרמטי:

{
  "tools": [
    {
      "type": "code_execution_20250825",
      "name": "code_execution"
    },
    {
      "name": "get_team_members",
      "description": "Get all members of a department...",
      "input_schema": {...},
      "allowed_callers": ["code_execution_20250825"] # opt-in to programmatic tool calling
    },
    {
      "name": "get_expenses",
 	...
    },
    {
      "name": "get_budget_by_level",
	...
    }
  ]
}

ה-API ממיר הגדרות כלים אלו לפונקציות Python שקלוד יכול לקרוא להן.

2. קלוד כותב קידוד תזמור

במקום לבקש כלים אחד בכל פעם, קלוד מייצר קידוד Python:

{
  "type": "server_tool_use",
  "id": "srvtoolu_abc",
  "name": "code_execution",
  "input": {
    "code": "team = get_team_members('engineering')\n..." # the code example above
  }
}

3. כלים מבוצעים מבלי להשפיע על חלון ההקשר של קלוד

כאשר הקידוד קורא ל-get_expenses(), אתם מקבלים בקשת כלי עם שדה caller:

{
  "type": "tool_use",
  "id": "toolu_xyz",
  "name": "get_expenses",
  "input": {"user_id": "emp_123", "quarter": "Q3"},
  "caller": {
    "type": "code_execution_20250825",
    "tool_id": "srvtoolu_abc"
  }
}

אתם מספקים את התוצאה, המעובדת בסביבת Code Execution במקום בחלון ההקשר של קלוד. מחזור בקשה-תגובה זה חוזר על עצמו עבור כל קריאת כלי בקידוד.

4. רק הפלט הסופי נכנס לחלון ההקשר

כאשר הקידוד מסיים לרוץ, רק תוצאות הקידוד מוחזרות לקלוד:

{
  "type": "code_execution_tool_result",
  "tool_use_id": "srvtoolu_abc",
  "content": {
    "stdout": "[{\"name\": \"Alice\", \"spent\": 12500, \"limit\": 10000}...]"
  }
}

זה כל מה שקלוד רואה, לא למעלה מ-2,000 פריטי הוצאה שעובדו לאורך הדרך.

מתי להשתמש ב-Programmatic Tool Calling

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

מועיל ביותר כאשר:

  • מעבדים מערכי נתונים גדולים שבהם אתם זקוקים רק לסיכומים או צבירים
  • מריצים תהליכי עבודה מרובי שלבים עם שלוש קריאות כלים תלויות או יותר
  • מסננים, ממיינים או מבצעים טרנספורמציה לתוצאות כלים לפני שקלוד רואה אותן
  • מטפלים במשימות שבהן נתוני ביניים לא אמורים להשפיע על ההסקה של קלוד
  • מבצעים פעולות מקבילות על פני פריטים רבים (בדיקת 50 נקודות קצה (endpoints), לדוגמה)

פחות יעיל כאשר:

  • מבצעים קריאות כלים יחידות ופשוטות
  • עובדים על משימות שבהן קלוד צריך לראות ולהסיק לגבי כל תוצאות הביניים
  • מבצעים בדיקות מהירות עם תגובות קטנות

Tool Use Examples

האתגר

סכמת JSON מצטיינת בהגדרת מבנה – סוגים, שדות נדרשים, קבועי מונים (enums) מותרים – אך היא אינה יכולה לבטא דפוסי שימוש: מתי לכלול פרמטרים אופציונליים, אילו שילובים הגיוניים, או אילו מוסכמות ה-API שלכם מצפה להן.

שקלו API לטיפול בפניות תמיכה:

{
  "name": "create_ticket",
  "input_schema": {
    "properties": {
      "title": {"type": "string"},
      "priority": {"enum": ["low", "medium", "high", "critical"]},
      "labels": {"type": "array", "items": {"type": "string"}},
      "reporter": {
        "type": "object",
        "properties": {
          "id": {"type": "string"},
          "name": {"type": "string"},
          "contact": {
            "type": "object",
            "properties": {
              "email": {"type": "string"},
              "phone": {"type": "string"}
            }
          }
        }
      },
      "due_date": {"type": "string"},
      "escalation": {
        "type": "object",
        "properties": {
          "level": {"type": "integer"},
          "notify_manager": {"type": "boolean"},
          "sla_hours": {"type": "integer"}
        }
      }
    },
    "required": ["title"]
  }
}

הסכמה מגדירה מה תקף, אך משאירה שאלות קריטיות ללא מענה:

  • עמימות פורמטים: האם due_date צריך להשתמש ב-"2024-11-06", "Nov 6, 2024" או "2024-11-06T00:00:00Z"?
  • מוסכמות מזהים (ID): האם reporter.id הוא UUID, "USR-12345", או רק "12345"?
  • שימוש במבנה מקונן: מתי קלוד צריך לאכלס את reporter.contact?
  • קורלציות פרמטרים: כיצד escalation.level ו-escalation.sla_hours קשורים לעדיפות?

עמימויות אלו עלולות להוביל לקריאות כלים שגויות ולשימוש לא עקבי בפרמטרים.

הפתרון שלנו

Tool Use Examples מאפשר לכם לספק דוגמאות לקריאות כלים ישירות בהגדרות הכלים שלכם. במקום להסתמך על הסכמה בלבד, אתם מציגים לקלוד דפוסי שימוש קונקרטיים:

{
    "name": "create_ticket",
    "input_schema": { /* same schema as above */ },
    "input_examples": [
      {
        "title": "Login page returns 500 error",
        "priority": "critical",
        "labels": ["bug", "authentication", "production"],
        "reporter": {
          "id": "USR-12345",
          "name": "Jane Smith",
          "contact": {
            "email": "jane@acme.com",
            "phone": "+1-555-0123"
          }
        },
        "due_date": "2024-11-06",
        "escalation": {
          "level": 2,
          "notify_manager": true,
          "sla_hours": 4
        }
      },
      {
        "title": "Add dark mode support",
        "labels": ["feature-request", "ui"],
        "reporter": {
          "id": "USR-67890",
          "name": "Alex Chen"
        }
      },
      {
        "title": "Update API documentation"
      }
    ]
  }

משלוש דוגמאות אלו, קלוד לומד:

  • מוסכמות פורמט: תאריכים משתמשים ב-YYYY-MM-DD, מזהי משתמשים עוקבים אחר USR-XXXXX, תוויות משתמשות ב-kebab-case
  • דפוסי מבנה מקוננים: כיצד לבנות את אובייקט ה-reporter עם אובייקט ה-contact המקונן שלו
  • קורלציות פרמטרים אופציונליים: לבאגים קריטיים יש פרטי קשר מלאים + הסלמה עם SLAs הדוקים; לבקשות פיצ'רים יש reporter אך ללא contact/escalation; למשימות פנימיות יש כותרת בלבד

בבדיקות הפנימיות שלנו, דוגמאות לשימוש בכלים שיפרו את הדיוק מ-72% ל-90% בטיפול בפרמטרים מורכבים.

מתי להשתמש ב-Tool Use Examples

Tool Use Examples מוסיפים טוקנים להגדרות הכלים שלכם, ולכן הם בעלי הערך הרב ביותר כאשר שיפורי הדיוק עולים על העלות הנוספת.

מועיל ביותר כאשר:

  • מבנים מקוננים מורכבים שבהם JSON תקף אינו מרמז על שימוש נכון
  • כלים עם פרמטרים אופציונליים רבים ודפוסי הכללה חשובים
  • ממשקי API עם מוסכמות ספציפיות לתחום שאינן נלכדות בסכמות
  • כלים דומים שבהם דוגמאות מבהירות באיזה מהם להשתמש (לדוגמה, create_ticket מול create_incident)

פחות יעיל כאשר:

  • כלי פרמטר יחיד פשוטים עם שימוש ברור
  • פורמטים סטנדרטיים כמו כתובות URL או מיילים שקלוד כבר מבין
  • חששות אימות שמטופלים טוב יותר על ידי אילוצי סכמת JSON

שיטות עבודה מומלצות

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

שילוב אסטרטגי של תכונות

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

  • נפיחות חלון הקשר מהגדרות כלים ← Tool Search Tool
  • תוצאות ביניים גדולות שמזהמות את חלון ההקשר ← Programmatic Tool Calling
  • שגיאות פרמטרים וקריאות כלים שגויות ← Tool Use Examples

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

לאחר מכן, שלבו תכונות נוספות לפי הצורך. הן משלימות זו את זו: ה-Tool Search Tool מבטיח מציאת הכלים הנכונים, ה-Programmatic Tool Calling מבטיח ביצוע יעיל, ו-Tool Use Examples מבטיח קריאה נכונה.

הגדרת Tool Search Tool לגילוי משופר

חיפוש כלים מתבצע לפי שמות ותיאורים, כך שהגדרות ברורות ותיאוריות משפרות את דיוק הגילוי.

// Good
{
    "name": "search_customer_orders",
    "description": "Search for customer orders by date range, status, or total amount. Returns order details including items, shipping, and payment info."
}

// Bad
{
    "name": "query_db_orders",
    "description": "Execute order query"
}

הוסיפו הנחיות ל-System Prompt כך שקלוד יידע מה זמין:

You have access to tools for Slack messaging, Google Drive file management, 
Jira ticket tracking, and GitHub repository operations. Use the tool search 
to find specific capabilities.

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

הגדרת Programmatic Tool Calling לביצוע נכון

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

{
    "name": "get_orders",
    "description": "Retrieve orders for a customer.\nReturns:\n    List of order objects, each containing:\n    - id (str): Order identifier\n    - total (float): Order total in USD\n    - status (str): One of 'pending', 'shipped', 'delivered'\n    - items (list): Array of {sku, quantity, price}\n    - created_at (str): ISO 8601 timestamp"
}

ראו מטה כלים שהצטרפו ונהנים מתזמור פרוגרמטי:

  • כלים שיכולים לרוץ במקביל (פעולות בלתי תלויות)
  • פעולות שבטוחות לניסיון חוזר (אידמפוטנטיות)

הגדרת Tool Use Examples לדיוק פרמטרים

צרו דוגמאות לבהירות התנהגותית:

  • השתמשו בנתונים מציאותיים (שמות ערים אמיתיים, מחירים סבירים, לא "string" או "value")
  • הציגו מגוון עם דפוסי מפרט מינימליים, חלקיים ומלאים
  • שמרו על תמציתיות: 1-5 דוגמאות לכלי
  • התמקדו בעמימות (הוסיפו דוגמאות רק כאשר השימוש הנכון אינו ברור מהסכמה)

תחילת עבודה

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

client.beta.messages.create(
    betas=["advanced-tool-use-2025-11-20"],
    model="claude-sonnet-4-5-20250929",
    max_tokens=4096,
    tools=[
        {"type": "tool_search_tool_regex_20251119", "name": "tool_search_tool_regex"},
        {"type": "code_execution_20250825", "name": "code_execution"},
        # Your tools with defer_loading, allowed_callers, and input_examples
    ]
)

לתיעוד API מפורט ודוגמאות SDK, עיינו ב:

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

אנו נרגשים לראות מה תבנו.

תודות

נכתב על ידי בין וו (Bin Wu), עם תרומות מאדם ג'ונס (Adam Jones), ארתור רנו (Artur Renault), הנרי טיי (Henry Tay), ג'ייק נובל (Jake Noble), נואה פיקארד (Noah Picard), סם ג'יאנג (Sam Jiang) וצוות פלטפורמת המפתחים של קלוד. עבודה זו נבנית על מחקר יסודי של כריס גורגולבסקי (Chris Gorgolewski), דניאל ג'יאנג (Daniel Jiang), ג'רמי פוקס (Jeremy Fox) ומייק למברט (Mike Lambert). שאבנו השראה גם מכלל מערכת ה-AI האקולוגית, כולל LLMVM של ג'ואל פובר (Joel Pobar), Code Mode של Cloudflare ו-Code Execution כ-MCP. תודה מיוחדת לאנדי שומיסטר (Andy Schumeister), המיש קר (Hamish Kerr), קייר בראדוול (Keir Bradwell), מאט בלייפר (Matt Bleifer) ומולי וורוורק (Molly Vorwerck) על תמיכתם.