TOOLNEW

סוכן שמנהל אימיילים עם Claude - למה שולח ומנסח הם שני כלים

איך לבנות סוכן AI שמטפל בתיבת דואר נכנס בלי לתת לו שליחת מיילים אוטומטית - הפרדת כלים, strict tool use ואישור ידני לפני שליחה.

מערכת בינה AI טופסוכני AI ואוטומציה3 בספטמבר 20263 min1 sources
מעטפות נייר ישנות מונחות בערימה מסודרת על שולחן עץ, אחת מהן פתוחה עם מכתב מוצץ החוצה, תאורה חמה
מעטפות נייר ישנות מונחות בערימה מסודרת על שולחן עץ, אחת מהן פתוחה עם מכתב מוצץ החוצה, תאורה חמה

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

שני כלים, לא אחד

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

const draftTool: Anthropic.Tool = {
  name: "draft_email",
  description: "יוצר טיוטת מייל לבדיקה - לא שולח",
  strict: true,
  input_schema: {
    type: "object",
    properties: {
      to: { type: "string" },
      subject: { type: "string" },
      body: { type: "string" },
    },
    required: ["to", "subject", "body"],
    additionalProperties: false,
  },
};

const sendTool: Anthropic.Tool = {
  name: "send_email",
  description: "שולח טיוטה קיימת שכבר אושרה - דורש draft_id",
  strict: true,
  input_schema: {
    type: "object",
    properties: { draft_id: { type: "string" } },
    required: ["draft_id"],
    additionalProperties: false,
  },
};

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

מה קורה בקוד שלכם בין שני הכלים

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

מה זה עלות בפועל, לא רק סיכון

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

איפה זה נשבר: משתמש שמאשר בלי לקרוא

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

מקרה קצה: תשובה לשרשור עם כמה נמענים

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

מיון תיבת הדואר הנכנס - הצד הבטוח יותר

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

דוגמה: איך זה נראה בפרקטיקה על יום עבודה טיפוסי

תיבה עם 40 מיילים חדשים בבוקר: הסוכן מסווג את כולם תוך שניות ומתייג 30 כ"לארכיון או אין צורך בתגובה", 7 כ"לטיפול השבוע", ו-3 כ"דחוף - דורש תגובה היום". על ה-3 הדחופים, הוא מכין טיוטת תשובה לכל אחד ומציג אותן יחד למשתמש בתחילת היום - לא שולח כלום לבד. המשתמש קורא, עורך במידת הצורך, ולוחץ אישור על כל טיוטה בנפרד. כל שאר ה-37 המיילים כבר מסודרים ומתויגים, בלי שהמשתמש נגע בהם - זה בדיוק החלוקה הנכונה בין מה שבטוח לאוטומציה מלאה לבין מה שדורש עין אנושית לפני יציאה.

מה לנסות עכשיו

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

שאלות נפוצות

בטוח לתת לסוכן AI לשלוח מיילים באופן אוטומטי לגמרי?

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

מה זה strict tool use ולמה זה חשוב לסוכן אימייל?

זו הגדרה (strict: true) שמבטיחה שהקלט שהמודל שולח לכלי תואם בדיוק לסכימה שהגדרתם - חשוב במיוחד לכלי כמו 'שלח מייל' שבו שדה כתובת חסר או שגוי הוא טעות יקרה.

SOURCES

  1. Anthropic - Tool use with Claude (platform.claude.com) · נבדק 3 בספטמבר 2026

קשור לזה