קרו איי-איי / CrewAI

מה זה קרו איי-איי ומה בדיוק צוות סוכנים?

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

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

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

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

הפיצ'רים המרכזיים של קרו

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

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

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

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

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

כמה זה עולה?

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

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

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

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

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

קרו מול הדרכים האחרות לבנות סוכנים

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

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

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

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

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

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

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

הפיצ'ר שעושה את ההבדל: זרימה עם תקרת תקציב

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

# זרימה בשליטת הקוד, עם תקרת תקציב וסוכנים בנקודות ההחלטה בלבד
import os
from crewai import Agent, Task, Crew, Process, LLM

# מודל שונה לכל תפקיד. סיווג וסיכום אינם צריכים את המודל החזק
FAST = LLM(model="claude-haiku-4-5", temperature=0.2)
STRONG = LLM(model="claude-opus-5", temperature=0.4)

MAX_USD_PER_RUN = 0.25

classifier = Agent(
    role="ממיין פניות",
    goal="לקבוע לאיזה מסלול שייכת הפנייה ולהחזיר תווית אחת בלבד",
    backstory="עובד ותיק בשירות לקוחות שראה אלפי פניות ויודע לזהות דפוס מיד",
    llm=FAST,
    max_iter=2,          # בלי תקרה סוכן יכול להסתובב בלולאה ולשרוף תקציב
    verbose=False,
)

analyst = Agent(
    role="מנתח תוכן",
    goal="לחלץ את העובדות הרלוונטיות ולנסח מסקנה מנומקת בעברית",
    backstory="אנליסט שמסכם חומר ארוך לפסקה שאפשר לפעול לפיה",
    llm=STRONG,
    max_iter=3,
    verbose=False,
)

def build_tasks(payload):
    triage = Task(
        description="מיין את הפנייה הבאה לאחת מהתוויות: מכירה, תמיכה, חשבונית, אחר.\n"
                    + payload["text"],
        expected_output="מילה אחת בלבד מתוך הרשימה",
        agent=classifier,
    )
    analyse = Task(
        description="נתח את הפנייה וכתוב סיכום של עד חמישה משפטים עם המלצה לפעולה",
        expected_output="פסקה בעברית, בלי כותרות ובלי רשימות",
        agent=analyst,
        context=[triage],
    )
    return [triage, analyse]

# הזרימה. הקוד מחליט מה קורה, ולא סוכן מנהל שמחלק עבודה לפי הבנתו
def run(payload):
    tasks = build_tasks(payload)
    crew = Crew(
        agents=[classifier, analyst],
        tasks=tasks,
        process=Process.sequential,
        memory=False,        # זיכרון משותף מנפח את ההקשר ואת העלות
    )
    result = crew.kickoff()
    usage = crew.usage_metrics
    spent = estimate_cost(usage)
    if spent > MAX_USD_PER_RUN:
        alert("run exceeded budget", spent=spent, payload_id=payload["id"])
    return {"label": str(tasks[0].output).strip(),
            "summary": str(result), "cost": round(spent, 4)}

def estimate_cost(usage, in_rate=0.000005, out_rate=0.000025):
    return usage.prompt_tokens * in_rate + usage.completion_tokens * out_rate

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

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

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

חסרונות שאתם צריכים לדעת

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

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

היתרונות שעושים את קרו שווה

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

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

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

מתי לבחור בקרו ומתי לוותר עליו?

שלוש שאלות מכריעות את הבחירה: מי כותב את הקוד, כמה הרצות ביום, וכמה ודאות התהליך דורש.

# עץ החלטה לבניית מערכת שמבצעת משימות מורכבות
שאלה 1: מי יתחזק את זה?
    מפתח בצוות           -->  ספריית קוד אפשרית
    איש אוטומציה         -->  מנוע חזותי
    אף אחד               -->  מוצר מוכן, בלי פיתוח

שאלה 2: כמה סוכנים באמת צריך?
    אחד עם כמה כלים      -->  לא צריך צוות, לכתוב ישירות
    שניים עם כלים שונים  -->  זרימה עם שני סוכנים
    ארבעה ומעלה          -->  לבדוק שוב, כמעט תמיד יותר מדי

שאלה 3: כמה זמן מותר להרצה?
    שניות, משתמש ממתין   -->  לא מתאים, קריאה ישירה למודל
    דקות, עבודת רקע      -->  מתאים
    שעות, עיבוד לילי     -->  מתאים מאוד

שאלה 4: כמה הרצות ביום?
    עד 10                -->  העלות זניחה, אפשר להתנסות
    10 עד 500            -->  לחשב עלות להרצה לפני שמרחיבים
    מעל 500              -->  זרימה קשיחה ומודל זול לכל תפקיד

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

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

השורה התחתונה: האם קרו שווה?

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

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

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

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