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

התשובה הקצרה: סוכני מסחר אפקטיביים אינם אוסף בוטים שמדברים זה עם זה. הארכיטקטורה החזקה ש־Anthropic מתארת היא מודל אחד בתוך Agent Loop, שמקבל הקשר, מפעיל כלים מול מערכות העסק, טוען Skills לפי צורך, מציג ממשק מובנה ועוצר לפני פעולה כספית או בלתי הפיכה. סביב הלולאה נמצאים זיכרון, caching, שכבת אכיפה ו־Evals — ושם למעשה נקבעת איכות המוצר.

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

מהו סוכן מסחר — ומה הוא אמור להשלים

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

הליבה: מודל אחד בתוך Agent Loop

בליבה נמצא מודל שמבצע שוב ושוב רצף פשוט: מבין את היעד, בוחן הקשר, מפעיל כלי, מתבונן בתוצאה, שואל שאלה כשחסר מידע וממשיך עד שהמשימה הושלמה. לפי Anthropic, אין צורך ב־intent router שמנסה לסווג כל משפט מראש או בצבא של סוכני־משנה לפי מחלקה. שיחת מסחר אחת נוטה לעבור בין חיפוש, העדפות, מדיניות, מלאי ועגלה — ולכן שמירת ההקשר בתוך לולאה אחת היא יתרון.

Skills במקום Subagents — ברוב זרימות המסחר

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

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

מתי כן להשתמש בסוכן־משנה

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

מה נכנס ל־System Prompt ומה הופך ל־Skill

כלל האצבע של Anthropic הוא תדירות: מידע שהסוכן צריך ברוב התורים נשאר ב־System Prompt; נהלים שנדרשים רק לחלק מהתנועה עוברים ל־Skills. נקודת פתיחה מעשית היא שסעיף הרלוונטי לשליש או יותר מהבקשות ייכנס לפרומפט. אם אפשר לזהות את ה־Skill מתוך העמוד שממנו הגיע המשתמש, אפשר לטעון אותו מראש ולחסוך תור.

הכלים צריכים לקרוא למערכות העסק — לא להחליף אותן

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

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

ממשק משתמש הוא Tool, לא טקסט שהמודל מאלתר

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

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

מהירות ועלות: מודדים זמן עד השלמת משימה

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

1. 1טענו מראש את הקשר העמוד או הקמפיין שממנו המשתמש הגיע.
2. 2אפשרו קריאות מקבילות לכלים שאינם תלויים זה בזה.
3. 3הפעילו כלי מיד כשארגומנטיו הושלמו בזרם, במקום לחכות לסוף כל תשובת המודל.
4. 4הציגו רכיבים בהדרגה והראו בשפה פשוטה מה הסוכן בודק כעת.
5. 5בחרו מודל ורמת effort באמצעות sweep על חבילת ה־Evals האמיתית.

Prompt Caching הוא מנוע החיסכון הגדול

תנועת מסחר חוזרת שוב ושוב על אותו פרומפט, אותן הגדרות כלים ואותם כללי מותג. Anthropic מציינת שקריאת טוקנים מהמטמון עולה עשירית מקריאה טרייה, ושבפריסות מסחר חזקות אפשר לכוון ל־90%–99% cache hit. אבל המטמון הוא prefix-based: הבדל מוקדם אחד שובר את כל מה שאחריו.

לפרטים טכניים עדכניים על breakpoints, TTL ומדידת cache קראו את תיעוד Prompt Caching הרשמי.

זיכרון שסורד בין שיחות — בלי להפוך לסיכון פרטיות

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

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

בטיחות נאכפת ב־Harness, לא רק בפרומפט

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

Evals: כך משחררים מערכת לא־דטרמיניסטית

שינוי בפרומפט, Tool או Skill יכול לשבור התנהגות רחוקה. Anthropic ממליצה לבנות eval כ־snapshot של מצב: System Prompt, כלים, messages, מצב סל והודעת בדיקה. מריצים משם ומדרגים את המצב הסופי והרכיב שהוצג — לא את המסלול המדויק, שעלול להשתנות גם כשהתוצאה נכונה.

• לכל מקרה חיובי כתבו מקבילה שלילית: מתי לבצע ומתי לסרב, מתי לשאול ומתי להמשיך.
• בדקו מחירים, מלאי ותכונות מול הנתונים שהכלים החזירו.
• התחילו חלק מהמקרים מהיסטוריה ארוכה, סותרת ומלוכלכת — לא רק ממצב נקי.
• בדקו user-authored injection בנפרד מ־data-plane injection שמגיע מתוך listing או ביקורת.
• בדקו UI: סוג הרכיב, סדר הפריטים, caps, empty state, timeout והיעדר IDs פנימיים.
• כתבו תרחישים שחוצים שני תחומים, למשל הנחה יחד עם תחזית מלאי.

מפת יישום מעשית ל־90 יום

השורה התחתונה

הארכיטקטורה המתקדמת ביותר אינה בהכרח המסובכת ביותר. לסוכן מסחר טוב יש לולאה אחת שמחזיקה הקשר, Skills מודולריים, כלים שמפעילים אמת עסקית, UI טיפוסי, cache מתוכנן, זיכרון נשלט ו־Harness שלא מאפשר למודל לעקוף את העסק. כשה־Evals מודדים השלמת משימה ואמון — אפשר לשפר מודל בלי לבנות את המוצר מחדש.

להעמקה בבניית סוכנים קראו את המדריך המלא לסוכני AI, את מדריך Claude Skills, Connectors ו־MCP ואת מדריך Claude Code. אפשר להמשיך גם אל הסדנאות המוקלטות ואל קורס Claude Code המקיף.