סוכן שמפרסם לכמה פלטפורמות עם Claude - למה חצי מהפוסטים נעלמים

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

הבעיה: תוצאות כלים שפוצלו בין הודעות

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

איך זה אמור לעבוד

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

למה חשוב להמשיך גם כשפלטפורמה אחת נכשלת

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

איפה זה עוד נשבר: פרסום כפול בטעות בגלל retry

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

מקרה קצה: פלטפורמה אחת דורשת אישור ידני

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

דוגמה מספרית: כמה זה עולה על פני 100 פרסומים בשבוע

סוכן שמפרסם ל-3 פלטפורמות במקביל, 100 פעמים בשבוע (300 קריאות כלי בסך הכל): התקורה הקבועה של tool use לכל בקשה - כ-354 טוקן אצל Sonnet 5 לפי Anthropic - מוסיפה כ-106,000 טוקן קלט נוספים בשבוע רק בגלל נוכחות הכלים בבקשה, עוד לפני תוכן הפוסט עצמו. זה מספר קטן יחסית (כמה סנטים בשבוע במחיר Sonnet 5), אבל שווה לזכור אותו כשמשווים סוכן עם 3 כלי פרסום נפרדים מול סוכן עם כלי אחד גנרי שמקבל פרמטר "פלטפורמת יעד" - האחרון חוסך את התקורה הזו פי 3.

איך יודעים שהתהליך עובד נכון

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

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

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