ה-agent הראשון, צעד אחר צעד
נבנה agent קונקרטי: research agent שמקבל שאלה, מחפש באינטרנט, מסכם, ומחזיר תשובה עם מקורות. דוגמה קלאסית. שווה לבנות אותה לפני כל use case יותר מורכב, כי כל הבעיות מופיעות כאן בקטן.
- בחרו מודל. Claude Sonnet 4.5 או GPT-4.5. גם וגם תומכים ב-tool calling יציב ובעברית סבירה. ההפרש בעלות בפרוטוטיפ זניח.
- הגדירו tool אחד בלבד.
web_search(query: str) -> List[Result]. השתמשו ב-Tavily API או ב-Brave Search. אל תתחילו עם חמישה tools, גם אם נראה שצריך. - כתבו system prompt קצר. שלושה משפטים מקסימום. מה המטרה, מתי לעצור, מה לעשות כשאין מידע. system prompt ארוך זה דגל אדום שהשלב הקודם (use case) לא הוגדר טוב.
- הוסיפו מגבלת iterations. ה-agent לא ירוץ יותר מ-10 lap. אצלי זה הציל את החשבון פעמיים. ב-LangGraph זה
recursion_limit. ב-Agents SDK יש max_turns. - הריצו על 5 שאלות אמיתיות. כתבו ידנית מה התשובה הנכונה לכל אחת, שמרו את ה-eval. הוא הכלי החשוב ביותר שלכם בחודש הראשון, יותר מהקוד עצמו.
- תעדו את העלות. כמה טוקנים יצאו, כמה קריאות tool, איפה היה wait time. בלי זה אתם עיוורים כשמשהו ידפק.
שש שלבים. אם זה לוקח לכם יותר מיום עבודה, משהו לא בסדר ב-scope, חזרו לסעיף ה-prerequisites.
חמישה דברים שנשברו אצלי ב-production
ה-prototype תמיד עובד. production זה סיפור אחר. הנה מה ששרף לי שעות וכסף, ומה שלמדתי.
- לולאות אינסופיות. ה-agent קורא ל-tool, ה-tool מחזיר טעות, ה-agent מנסה שוב, אותה טעות, וחוזר חלילה. אצלי זה היה 200 lap בתוך חצי שעה, שעלו 47$ לפני שתפסתי. הפתרון:
max_turns נוקשה, plus log של ניסיון לקרוא ל-tool עם אותם פרמטרים, plus break מיידי. - JSON שבור ב-tool call. ב-3% מהקריאות המודל מחזיר JSON עם פסיק נוסף או escape שגוי. ב-Sonnet 4.5 זה השתפר משמעותית, אבל לא נעלם. תוסיפו fallback parser, או השתמשו ב-structured outputs של OpenAI שמכריחים schema.
- הקשר מתפוצץ. אחרי 15 lap ה-context בלולאה גדל ל-50K טוקנים, ועלות גדלה לינארית. הפתרון: סיכום (summarization) של ה-state כל 5 lap. Anthropic כתבה על זה במדריך ה-tool use שלהם, שווה לקרוא לפני שמתחילים.
- עברית ב-tool input. אם ה-tool שלכם מצפה לטקסט עברי וה-agent מייצר "אנתרופיק" במקום "Anthropic", search לא יחזיר תוצאות רלוונטיות. תכריחו את המודל ב-system prompt להשתמש בשמות חברות באנגלית.
- עלות לא צפויה. agent אחד אצל לקוח שלי בחיפה הגיע ל-1,200$ בחודש (כ-4,500 ש"ח) בלי שהבחנו, כי משתמש אחד הריץ אותו בלולאה 8,000 פעם ביום. הפתרון: alerts ב-OpenAI ו-Anthropic dashboard על תקרת יומית, plus rate limit לכל user_id.
מה זה אומר לשלושה סוגי קהל
הכלים זהים לכולם, אבל הדרך הנכונה תלויה במי אתם. שלושה פרופילים שאני פוגש שבוע אחר שבוע בישראל:
- פרילנסר או יועץ אוטומציה (1-2 אנשים): תתחילו ב-n8n או Make. הלקוח רוצה לראות תוצאה בשבועיים, לא ארכיטקטורה. אצל לקוח של סוכנות שיווק בתל אביב, agent ב-n8n שמסכם שיחות מכירה מתוך Zoom ומזין ל-HubSpot CRM יצא לפעולה תוך 12 שעות עבודה, ועלה 30 ש"ח לחודש להרצה על 200 שיחות. אילו הייתם פותחים LangGraph, הייתם עוד בכתיבת ה-state schema.
- צוות הנדסה בסטארטאפ early-stage (3-10 מהנדסים): OpenAI Agents SDK או tool use של Claude ישירות. מהר מספיק לאיטרציה שבועית, מובנה מספיק כדי לא להישבר ב-rev 5. סטארטאפ ישראלי שאני מלווה בתחום ה-fintech בנה את ה-MVP של agent תמיכה ב-9 ימי עבודה, החליף ל-LangGraph רק אחרי 4 חודשים, כשהמוצר הפך לרב-מודלי וה-state נהיה מסובך.
- צוות פלטפורמה בארגון גדול (10+ מהנדסים): LangGraph או framework פנימי דק מעליו. אתם צריכים observability רציני, version pinning, ויכולת להחליף מודל ספק תוך שבוע. בנק ישראלי שאני מכיר בנה wrapper פנימי מעל LangGraph כי דרישות הרגולציה והשמירה על נתונים הגבילו את ה-cloud providers שלהם לרשימה קצרה, וצריך היה לוודא שאף payload לא יוצא ל-US East.
לבנות agent בעצמכם מול שירות מנוהל
שאלה לגיטימית שעלתה לי בשבועיים האחרונים מצוותים שונים: למה לא פשוט להשתמש ב-OpenAI Assistants API או ב-Claude Agent מובנה במקום לבנות את הלולאה לבד? בדקתי את שניהם בעבודה אמיתית בשנה האחרונה, וההבדל מתמקד בשלושה אזורים שאסור להתעלם מהם.
שליטה ו-debugging: assistant מנוהל מסתיר מכם את ה-loop. נוח לפרוטוטיפ של יומיים, רע ל-debug ביום שלישי. כשה-agent עושה משהו מוזר ב-production, אין לכם access נקי ל-intermediate steps. ב-LangGraph או בקוד שכתבתם בעצמכם אתם רואים כל node שעבר, וכל החלטה של המודל מתועדת.
עלות: שירות מנוהל גובה לרוב premium של 20-40% מעל ה-API הגולמי, כי הם מנהלים threads, file storage ו-state. עבור 10K הרצות בחודש זה אומר 200-400$ נוספים (כ-750-1,500 ש"ח). לסטארטאפ ישראלי בתחילת דרכו זה כמעט חודש משכורת ל-junior, בלי שום ערך נוסף ללקוח הסופי.
Vendor lock: אם בניתם על OpenAI Assistants ורציתם לעבור ל-Claude כי המחיר ירד או האיכות עלתה, אתם כותבים את הלוגיקה מחדש. אם בניתם ב-LangGraph או ב-SDK פתוח, אתם מחליפים שורה אחת בקובץ config. אצל לקוח שלי בהרצליה, שינוי המודל מ-GPT-4 ל-Claude Sonnet 4.5 חסך 35% מהעלות החודשית בלי לגעת ב-logic של ה-agent. זמן ה-migration: שעה.
המסקנה הפרגמטית שלי: שירות מנוהל מצוין לפרוטוטיפ של יומיים שצריך להראות ל-PM. אם המוצר ייצא ל-production וישרת לקוחות משלמים, תכתבו את ה-loop בעצמכם. הזמן שתחסכו בהתחלה תשלמו בכפול ב-migration, ב-debugging, וב-vendor negotiation שנה מהיום.
מתי לעבור מ-no-code ל-code
שאלה שאני נשאל הרבה. ה-tradeoff פשוט אם רואים אותו נכון.
n8n מנצח כשיש לכם פחות מ-3 tools, logic לינארי, ואין צורך ב-evals מסודרים. כל הצוותי שיווק בישראל שאני מכיר מתחילים שם, וזה הגיוני. אבל ברגע שאתם צריכים branching, memory מורכב, או custom tool שמחבר לבסיס נתונים פנימי, ה-code מנצח.
סימן מוחשי: אם אתם כותבים פונקציה ב-n8n שבעצם מתחילה להיות JavaScript ארוך של 50 שורות, זה הזמן לעבור. OpenAI Agents SDK הוא ה-onramp הקל ביותר ממקום של no-code, ו-LangGraph הוא היעד כשמגיעים לרצינות.
BestAI Take
הטעות הכי נפוצה שאני רואה אצל מי שמתחיל לבנות agent היא להתחיל מהכלי במקום מה-use case. אנשים פותחים n8n בלי לדעת מה הם רוצים שה-agent יעשה ספציפית. התוצאה: שבועיים של חיפושים, ולא agent.
אם אני מתחיל היום מאפס, אני בונה את ה-agent הראשון ב-Python עם OpenAI Agents SDK או עם tool use של Claude ישירות. ארבע שעות מ-0 ל-agent שעובד על 5 שאלות בדיקה. בלי framework, בלי vendor lock. ברגע שזה עובד, אפשר לדבר על LangGraph. לפני זה אתם מתעסקים בארכיטקטורה במקום במוצר. ב-BestAI אנחנו פוגשים הרבה צוותים שעוצרים בשלב ה-prototype בגלל זה, אז תזכרו: scope צר, eval קטן, ולולאה עם תקרה.
