Caveman הוא אחד הפרויקטים הצומחים ביותר בעולם כלי ה-AI כרגע: הוא נוצר באפריל 2026 וחצה 100,000 כוכבים בגיטהאב בפחות מחמישה חודשים. ההבטחה שלו מפתה — "למה להשתמש בהרבה טוקנים כשמעט טוקנים עושים את העבודה" — והמספרים אמיתיים: פרוקסי דחיסה שמקצץ כ-33% מטוקני הקלט, סקיל שמצמצם את פלט הסוכן בכ-65%, ומצב דפדפן שמכווץ שאילתות של עץ נגישות בשני סדרי גודל.
אנחנו מפעילים צי של כעשרים ליינים אוטונומיים של Claude Code — פייפליינים של בנייה, ליינים של code review, סריקות QA ורצי משימות מתוזמנים — שעובדים מסביב לשעון, רובם ללא השגחה. הוצאת הטוקנים על הצי הזה היא סעיף תקציבי אמיתי. אז כשכלי מבטיח לחתוך אותה ביותר מחצי, אנחנו בוחנים אותו ברצינות. בחנו — והחלטנו לא להטמיע. הפוסט הזה מסביר למה, כי הנימוקים חשובים יותר מהפסיקה — וכי רעיון אחד מתוך Caveman דווקא שרד את הבדיקה.
מה Caveman בעצם עושה
Caveman מגיע כשני מוצרים נפרדים תחת שם אחד, עם שני רישיונות שונים:
- הסקיל (רישיון MIT): הנחיות שהופכות את התשובות של הסוכן לתמציתיות. פחות נימוסים, ניסוח דחוס, "שפת אדם מערות". מכאן מגיע החיסכון המדובר של כ-65% בטוקני פלט.
- הפרוקסי (רישיון BSL-1.1): קובץ בינארי מקומי ב-Go שיושב בין סוכן הקוד שלכם לספק המודל. הוא מזהה סוגי תוכן — JSON, לוגים, diffs, תוצאות חיפוש, עצי נגישות של דפדפן — ודוחס אותם לפני שהם נכנסים לחלון ההקשר, עם שחזור מדויק בייט-בייט בדרך חזרה.
שניהם עובדים. המדדים אמינים, הפרויקט מתוחזק באופן פעיל, וההנדסה חכמה באמת. אף אחת מההסתייגויות שלנו אינה על איכות.
סיבה 1: פייפליינים שתלויים בטקסט מדויק נשברים תחת דחיסה
זה היה השיקול המכריע. צי סוכנים אוטונומי מוחזק על ידי טקסט מדויק: קובצי זיכרון עם כללים שחייבים להיות מצוטטים מילה במילה, תגובות בכרטיסי משימות שריצות עתידיות מחפשות בהן ביטויים ספציפיים, דוחות מובנים שסשנים אחרים מפענחים, ותחקירי תקלות שהניסוח המדויק שלהם מקודד את מה שהשתבש. בסשן אינטראקטיבי, אדם קורא סיכום תמציתי ומשלים את הפערים. בפייפליין ללא השגחה אין אדם — הסוכן הבא פועל על סמך בדיוק מה שהקודם כתב.
היסטוריית התקלות שלנו מלאה במקרים שבהם דוח לא מדויק במעט גרם לפעולה שגויה ימים אחר כך. שכבת סגנון שדוחסת באופן שיטתי את הטקסט של הסוכן היא מכונה לייצור התקלות האלה. החיסכון של 65% בטוקני פלט אמיתי; אמיתית גם העלות של פייפליין שמשתבש כי "נפרס ל-staging, ממתין ל-QA, לא לקדם לפרודקשן" נדחס ל"נפרס".
הלקח הכללי: אופטימיזציית טוקנים תלוית-עומס. פלט תמציתי הוא כמעט חינם בסשן עם אדם בלולאה — ומסוכן ממש במסירות בין סוכן לסוכן. כל צוות שמריץ סוכנים אוטונומיים צריך לסווג את הסשנים שלו על הציר הזה לפני התקנת כל כלי שמעצב פלט.
סיבה 2: הפרוקסי יושב על נתיב ההרשאות שלכם
הפרוקסי של Caveman עוטף את כל השיחה של הסוכן עם הספק, כולל סשנים מאומתי OAuth. המשמעות: כל בקשה — כולל סשנים שנוגעים בנתוני לקוחות, בהרשאות פנימיות ובתשתית פרודקשן — עוברת דרך קובץ בינארי של צד שלישי, שמותקן באמצעות סקריפט shell עם ווים לתוך הקונפיגורציה של הסוכן.
לסביבה חובבנית זה טרייד-אוף סביר. לסוכנות שמריצה עומסי לקוחות תחת מסגרת אבטחה קפדנית, זו חשיפת שרשרת-אספקה שאיננו יכולים להצדיק בשביל אופטימיזציית עלות — והתערבות בזרימה מאומתת של ספק נמצאת באזור אפור של תנאי שימוש שאין לנו שום עניין לשהות בו. ההסתייגות הזו קבועה: שום עדכון גרסה לא מתקן בעיית אמון ארכיטקטונית.
סיבה 3: פיצול הרישיונות משנה אם אתם מפיצים הלאה
הסקיל הוא MIT, אבל המנוע, הפרוקסי ושרת ה-MCP הם BSL-1.1 (עם המרה ל-Apache 2.0 בסביבות 2030). שימוש פנימי מותר; הפצה — לא. אנחנו מתחזקים מרקטפלייס ציבורי של פלאגינים, כך שכל מה שאנחנו מאמצים נוטה לזרום החוצה ככלי ארוז — והחצי השימושי של Caveman הוא בדיוק החצי שאסור לנו לשלוח.
סיבה 4: מצב "learn" קורא את ההיסטוריה שלכם
פקודת ה-learn של Caveman מנתחת את תמלולי הסוכן שלכם כדי לאתר בזבוזי טוקנים. פיצ'ר מצוין — ופסילה מיידית במכונות שבהן התמלולים מכילים מידע אישי של לקוחות וחומר קרוב להרשאות, לפחות עד שמישהו יבדוק בדיוק מה הוא קורא ולאן משהו נשלח. לא הגענו לשם, כי סיבות 1–3 כבר הכריעו את השאלה.
הרעיון האחד ששמרנו: דחיסת עצי ARIA ל-QA
עמוק ברשימת הפיצ'רים של Caveman מסתתר הרעיון הטוב ביותר שלו: דחיסת עצי נגישות של דפדפן לפני שהם נכנסים לחלון ההקשר, עם צמצום מוצהר של פי 129.8. מי שהריץ QA מבוסס אוטומציית דפדפן עם סוכן AI יודע למה המספר הזה סביר — צילומי ARIA של דפים אמיתיים הם עצומים, רפטטיביים לעומק, וברובם לא רלוונטיים לאף בדיקה בודדת.
אנחנו לא מתקינים את הבינארי של Caveman בשביל זה. אנחנו לוקחים את הטכניקה: שלב קדם-דחיסה ברתמת ה-Playwright QA שלנו, שמגזם ומאחד כפילויות בעץ הנגישות לפני שהסוכן רואה אותו. זה שינוי תחום וניתן לביקורת בקוד שבבעלותנו — כל התועלת, בלי שטח האמון.
איך אנחנו מחליטים (ואיך כדאי לכם)
רשימת הבדיקה שלנו לכל כלי שנכנס לצי אוטונומי, בסדר שהורג הכי מהר:
- האם הוא נוגע בנתיב ההרשאות? אם כן, הרף הופך ל"האם היינו כותבים את זה בעצמנו" — לא "האם הוא פופולרי".
- האם הוא משנה טקסט שמכונות אחרות פועלות לפיו? דחיסה, תמצות ועיצוב מחדש הם כולם מוטציות. פייפליינים ללא השגחה אלרגיים למוטציות.
- האם אפשר לאמץ את הרעיון בלי התלות? לעיתים קרובות התשובה כן, והרעיון הוא החלק בעל הערך.
- האם הרישיון מתיר את המקום שאליו הקוד באמת יגיע? בודקים לפני האינטגרציה, לא אחרי.
מאה אלף כוכבים לא עונים על אף אחת מהשאלות האלה. פופולריות היא עדות לכך שכלי פותר בעיה אמיתית — היא אינה עדות לכך שהוא פותר את הבעיה שלכם בבטחה.
אם הצוות שלכם בונה או מפעיל מערכות סוכני AI ומתמודד בדיוק עם הטרייד-אופים האלה — עלות, בטיחות ואוטונומיה — זו העבודה שאנחנו עושים כל יום ב-MSApps וב-OpsAgents. דברו איתנו.