איך לבנות כלים יעילים לסוכני AI – בעזרת סוכני AI

פרוטוקול ה-Model Context Protocol (MCP) מאפשר לסוכני LLM להשתמש במאות כלים לפתרון משימות מורכבות בעולם האמיתי. אבל איך נוודא שכלים אלה יהיו אפקטיביים ככל האפשר?

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

נתחיל בכך שנסקור כיצד ניתן:

• לבנות ולבדוק אבות טיפוס של הכלים שלכם
• ליצור ולהריץ הערכות מקיפות של הכלים שלכם עם סוכנים
• לשתף פעולה עם סוכנים כמו Claude Code כדי להגביר אוטומטית את ביצועי הכלים שלכם

נסיים עם עקרונות מפתח לכתיבת כלים איכותיים שזיהינו לאורך הדרך:

• בחירת הכלים הנכונים ליישום (ואילו לא ליישם)
• Namespacing לכלים כדי להגדיר גבולות ברורים בפונקציונליות
• החזרת מידע בעל משמעות מהכלים בחזרה לסוכנים
• אופטימיזציה של תגובות כלים ליעילות טוקנים
• Prompt Engineering לתיאורי ומפרטי כלים

מהו כלי?

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

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

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

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

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

איך לכתוב כלים

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

בניית אב טיפוס

קשה לצפות אילו כלים סוכנים ימצאו ארגונומיים ואילו לא, מבלי להתנסות בעצמכם. התחילו בהקמת אב טיפוס מהיר של הכלים שלכם. אם אתם משתמשים ב-Claude Code כדי לכתוב את הכלים שלכם (אולי ב-one-shot), כדאי לספק ל-Claude תיעוד עבור כל ספריות התוכנה, API או SDK (כולל אולי ה-MCP SDK) שהכלים שלכם יסתמכו עליהם. תיעוד ידידותי ל-LLM ניתן למצוא בדרך כלל בקבצי llms.txt פשוטים באתרי תיעוד רשמיים (הנה ה-API שלנו: Anthropic API).

עטיפת הכלים שלכם בשרת MCP מקומי או בDesktop extension (DXT) תאפשר לכם לחבר ולבדוק את הכלים שלכם ב-Claude Code או באפליקציית Claude Desktop.

כדי לחבר את שרת ה-MCP המקומי שלכם ל-Claude Code, הריצו claude mcp add <name> <command> [args...].

כדי לחבר את שרת ה-MCP המקומי או DXT שלכם לאפליקציית Claude Desktop, נווטו אל Settings > Developer או Settings > Extensions, בהתאמה.

ניתן גם להעביר כלים ישירות לקריאות Anthropic API לבדיקות תוכנתיות.

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

הפעלת הערכה

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

יצירת משימות הערכה

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

הנה כמה דוגמאות למשימות חזקות:

• תזמן פגישה עם ג'יין בשבוע הבא כדי לדון בפרויקט Acme Corp האחרון שלנו. צרף את ההערות מפגישת תכנון הפרויקט האחרונה שלנו ושמור חדר ישיבות.
• לקוח מספר זיהוי 9182 דיווח שחויב שלוש פעמים עבור ניסיון רכישה אחד. מצא את כל רשומות הלוג הרלוונטיות וקבע אם לקוחות אחרים הושפעו מאותה בעיה.
• לקוחה שרה חן הגישה זה עתה בקשת ביטול. הכן הצעת שימור. קבע: (1) מדוע הם עוזבים, (2) איזו הצעת שימור תהיה המשכנעת ביותר, ו-(3) אילו גורמי סיכון עלינו להיות מודעים אליהם לפני מתן הצעה.

והנה כמה משימות חלשות יותר:

• תזמן פגישה עם jane@acme.corp בשבוע הבא.
• חפש ביומני התשלומים עבור purchase_complete ו-customer_id=9182.
• מצא את בקשת הביטול על ידי Customer ID 45892.

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

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

הפעלת ההערכה

אנו ממליצים להריץ את ההערכה שלכם באופן תוכנתי באמצעות קריאות ישירות ל-LLM API. השתמשו בלולאות סוכני פשוטות (while-loops העוטפות קריאות ל-LLM API וקריאות כלים לסירוגין): לולאה אחת לכל משימת הערכה. כל סוכן הערכה צריך לקבל פרומפט משימה יחיד ואת הכלים שלכם.

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

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

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

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

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

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

שיתוף פעולה עם סוכנים

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

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

הסתמכנו על מערכי בדיקה נפרדים כדי לוודא שלא "נתאמנו יתר על המידה" (overfit) על הערכות ה"אימון" שלנו. מערכי בדיקה אלה גילו שאנו יכולים לחלץ שיפורי ביצועים נוספים, אף מעבר למה שהשגנו עם יישומי כלים "מומחים" – בין אם הכלים הללו נכתבו ידנית על ידי החוקרים שלנו ובין אם נוצרו על ידי קלוד עצמו.

בחלק הבא, נשתף כמה ממה שלמדנו מתהליך זה.

עקרונות לכתיבת כלים אפקטיביים

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

בחירת הכלים הנכונים לסוכנים

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

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

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

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

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

הנה כמה דוגמאות:

• במקום ליישם כלים כמו list_users, list_events ו-create_event, שקלו ליישם כלי schedule_event שמוצא זמינות ומתזמן אירוע.
• במקום ליישם כלי read_logs, שקלו ליישם כלי search_logs שמחזיר רק שורות לוג רלוונטיות וקצת חלון הקשר מסביב.
• במקום ליישם כלים כמו get_customer_by_id, list_transactions ו-list_notes, יישמו כלי get_customer_context שאוסף את כל המידע העדכני והרלוונטי של לקוח בבת אחת.

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

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

Namespacing לכלים שלכם

סוכני ה-AI שלכם יקבלו גישה פוטנציאלית לעשרות שרתי MCP ומאות כלים שונים – כולל אלה של מפתחים אחרים. כאשר כלים חופפים בפונקציה או שיש להם מטרה מעורפלת, סוכנים עלולים להתבלבל לגבי אילו מהם להשתמש.

Namespacing (קיבוץ כלים קשורים תחת קידומות משותפות) יכול לעזור בתיחום גבולות בין כלים רבים; לקוחות MCP עושים זאת לעיתים קרובות כברירת מחדל. לדוגמה, Namespacing של כלים לפי שירות (לדוגמה, asana_search, jira_search) ולפי משאב (לדוגמה, asana_projects_search, asana_users_search), יכול לסייע לסוכנים לבחור את הכלים הנכונים בזמן הנכון.

מצאנו כי בחירה בין Namespacing מבוסס קידומת (prefix) ל-Namespacing מבוסס סיומת (suffix) משפיעה באופן לא מבוטל על הערכות שימוש הכלים שלנו. ההשפעות משתנות לפי LLM ואנו ממליצים לכם לבחור סכימת שמות בהתאם להערכות שלכם.

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

החזרת מידע בעל משמעות מהכלים שלכם

באותו אופן, יישומי כלים צריכים לדאוג להחזיר רק מידע בעל "אות גבוה" (high signal) בחזרה לסוכנים. הם צריכים לתעדף רלוונטיות הקשרית על פני גמישות, ולהימנע מזהים טכניים ברמה נמוכה (לדוגמה: uuid, 256px_image_url, mime_type). שדות כמו name, image_url ו-file_type נוטים יותר להשפיע ישירות על פעולות ותגובות עתידיות של סוכנים.

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

במקרים מסוימים, סוכנים עשויים לדרוש את הגמישות לקיים אינטראקציה עם פלטים של שפה טבעית ומזהים טכניים כאחד, ולו רק כדי להפעיל קריאות כלים עוקבות (לדוגמה, search_user(name=’jane’) → send_message(id=12345)). אתם יכולים לאפשר את שניהם על ידי חשיפת פרמטר enum פשוט response_format בכלי שלכם, מה שמאפשר לסוכן שלכם לשלוט אם הכלים מחזירים תגובות “concise” או “detailed” (תמונות למטה).

ניתן להוסיף פורמטים נוספים לגמישות רבה עוד יותר, בדומה ל-GraphQL שבו ניתן לבחור בדיוק אילו פיסות מידע ברצונכם לקבל. הנה דוגמה ל-ResponseFormat enum לשליטה ברמת הפירוט של תגובת הכלי:

enum ResponseFormat {
   DETAILED = "detailed",
   CONCISE = "concise"
}

הנה דוגמה לתגובת כלי מפורטת (206 טוקנים):

הנה דוגמה לתגובת כלי תמציתית (72 טוקנים):

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

אופטימיזציה של תגובות כלים ליעילות טוקנים

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

אנו מציעים ליישם שילוב כלשהו של חלוקה לעמודים (pagination), בחירת טווח (range selection), סינון ו/או קיטוע (truncation) עם ערכי פרמטרים ברירת מחדל הגיוניים עבור כל תגובות כלים שעלולות לצרוך הרבה חלון הקשר. עבור Claude Code, אנו מגבילים את תגובות הכלים ל-25,000 טוקנים כברירת מחדל. אנו מצפים שאורך חלון ההקשר האפקטיבי של סוכנים יגדל עם הזמן, אך הצורך בכלים יעילים בחלון הקשר יישאר.

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

הנה דוגמה לתגובת כלי מקוטעת:

הנה דוגמה לתגובת שגיאה לא מועילה:

הנה דוגמה לתגובת שגיאה מועילה:

Prompt Engineering לתיאורי הכלים שלכם

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

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

בעזרת ההערכה שלכם תוכלו למדוד את ההשפעה של Prompt Engineering שלכם בביטחון רב יותר. אפילו ליטושים קטנים בתיאורי הכלים יכולים להניב שיפורים דרמטיים. Claude Sonnet 3.5 השיג ביצועים שיא במדד הביצועים SWE-bench Verified לאחר שביצענו ליטושים מדויקים לתיאורי הכלים, והפחתנו באופן דרמטי את שיעורי השגיאות ושיפרנו את השלמת המשימות.

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

מבט לעתיד

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

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

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

תודות

נכתב על ידי קן אייזאווה (Ken Aizawa) עם תרומות חשובות מעמיתים ממחלקות שונות: Research (בארי ז'אנג (Barry Zhang), זכארי ויטן (Zachary Witten), דניאל ג'יאנג (Daniel Jiang), סמי אל-שייח' (Sami Al-Sheikh), מאט בל (Matt Bell), מגי וו (Maggie Vo)), MCP (תיאודורה צ'ו (Theodora Chu), ג'ון וולש (John Welsh), דוד סוריה פארה (David Soria Parra), אדם ג'ונס (Adam Jones)), Product Engineering (סנטיאגו סיירה (Santiago Seira)), Marketing (מולי וורוורק (Molly Vorwerck)), Design (דרו רופר (Drew Roper)), ו-Applied AI (כריסטיאן ריאן (Christian Ryan), אלכסנדר בריקן (Alexander Bricken)).

1מעבר לאימון ה-LLM הבסיסיים עצמם.

רוצים ללמוד עוד?