תשתיות AI: בעולם של מלחמה על הקונטקטס, ה-CLI הוא (לפעמים) המלך

הפוסט הזה הוא חלק מהסדרה של איך הופכים פרויקט ל AI Ready ועל המשמעויות של לעבוד על פרויקט קוד בתקופה הנוכחית שבה משתמשים בעיקר בכלי בינה מלאכותית על מנת לכתוב את הקוד. הפוסט הקודם בסדרה דיבר על סקילים והוראות וההבדל בינהם. בפוסט הזה נדבר על משמעות הכלים שאנו נותנים לסקילים.

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

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

אני ממליץ לקרוא את הפוסט שלי (וגם לצפות בסרטון שם) על MCP והפרוטוקול שלו לפני קריאת הפוסט הזה.

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

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

1. איך אני יודע מה הטיקטים? נבדוק אם יש קובץ גיטהאב.
2. יש קובץ גיטהאב! או קיי, אז בוא ונבדוק אם יש לנו MCP נייטיב.
3. יש MCP נייטיב! מה הפעולות שאפשר לעשות?
4. הנה ה-list, אני אבצע בדיקה.
5. תוצאות הבדיקה של הטיקטים! הנה, נחליט על הראשון.
6. תחילת עבודה

אבל אם יש לכם הוראות אז האופרציה תהיה:

1. אני צריך טיקטים, אני יודע שזה פרויקט בגיטהאב, אני יודע שיש MCP, יש לי את רשימת הפעולות בזכרון.
2. שואל את ה-MCP עם הפעולה המתאימה.
3. תוצאות הבדיקה של הטיקטים! הנה, נחליט על הראשון.
4. תחילת עבודה.

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

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

MCP

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

איך מודדים את מה שיש מתחת למכסה המנוע (אפשר לדלג לתת הכותרת הבאה)

מה עשיתי כדי לבדוק את זה? בין אם מדובר בקורסור או בין אם מדובר בקלוד קוד, קשה להסתכל מתחת למכסה המנוע כי יש המון תנועה (המון) וגם יש המון כלים פנימיים ולא תמיד הכל שקוף. במיוחד ב-MCP שהם סטנדרטיים כמו זה של גיטהאב אז כדי להגביר את השקיפות השתמשתי בפרוקסי. במקום להורות לקורסור לעבוד ישירות עם GitHub MCP אני עובד עם MCP Proxy שמקושר ל-GitHub MCP.

איך עושים את זה? עם ספרית פייתון נחמדה בשם mcp-proxy ואז אני מפעיל את ה-MCP Server הרשמי של גיטהאב: @modelcontextprotocol/server-github עם ה-GITHUB_PERSONAL_ACCESS_TOKEN. בגדול? ככה:

GITHUB_PERSONAL_ACCESS_TOKEN="your_token_here" uvx mcp-proxy --sse-port 3000 npx -y @modelcontextprotocol/server-github

אין כאן יותר מדי משהו מסובך. בגדול יש לי localhost עם פורט 3000 שאם אני פונה אליו הוא הולך לגרסה הלוקלית של ה-MCP server של גיטהאב. הוא משתמש ב-GITHUB_PERSONAL_ACCESS_TOKEN. הפרוקסי פותח פורט ובעצם אני יכול להתחבר אליו. זה הכל.

ככה זה נראה כשאני מפעיל את זה בטרמינל של המק. שימו לב לפורט של הפרוקסי!

אם אני נכנס לתוך הדפדפן, אני במקרה הזה אוכל לראות את הפלט של ה-SSE!

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

http://proxyman.debug:64852/sse

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

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

{
  "mcpServers": {
    "github": {
      "url": "http://proxyman.debug:64852/sse"
    }
  }
}

אז מה רואים? את המידע שעובר ששייך ל MCP!

בזבוז הטוקנים של MCP

אז כשאנחנו בוחנים את התנועה, אנחנו רואים זרימה מטורפת של מידע שעובר ברשת ועובר למודל. במקרה הזה ליטרלי כל הפעולות של ה-MCP!

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

מה שמעניין הוא לבחון את ה-CLI הישן והטוב

פקודות CLI שונים הן מתועדות היטב. למשל GH CLI הוא כלי אולטרא פופולרי שמשתמשים בו כדי לנהל גיט. בעבר היינו משתמשים בו כדי לעבוד בנוחות מהטרמינל. אפילו כתבתי עליו פוסט כי הוא באמת היה מאד נוח. אנחנו יכולים להכניס את הפקודות של ה-CLI לסקילס כמובן.

אבל. למה…?

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

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

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

ויש כמובן עוד המון כלי CLI שאפשר להפעיל ומתועדים היטב. לא רק גיט. למשל JIRA CLI. או Confluence CLI.

סיכום – והאם MCP הוא חסר תוחלת ותועלת?

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

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

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

אם אתם רוצים עוד המחשה, אני ממליץ על ההרצאה הזו שלי על צלילה עמוקה ל JSON RPC ו-MCP