בניתי שרת MCP שהופך את Claude לשלט של הטלוויזיה בסלון: שרת מקומי אחד עם 14 כלים, שמדבר ישירות עם טלוויזיית LG webOS ברשת הביתית — הדלקה וכיבוי, ווליום, פתיחת אפליקציות, ערוצים, הקלדת טקסט, וגם צילום מסך כדי שהאייג׳נט יראה מה באמת מוצג על המסך. החלק המעניין הוא לא הקוד. אחרי שהחיבור עבד, מה שהיה חסר כדי שזה יהיה באמת שימושי לא היה הנדסה אלא לימוד.
זאת אופטימיזציית קצה לתהליך שלא גוזל יותר מחמש דקות ביום, ואני מודע לזה לגמרי. מצד שני, אין סרטון עתידני שלא מתחיל בזה שהגיבור אומר לבית החכם שלו ״תדליק חדשות״ וזה קורה. אז העתיד כאן, והוא רץ על websocket ברשת הביתית.
העיקרון: AIOS, ומי אחראי על מה
בואו נתחיל להתרגל לשם AIOS — AI Operating System. זה מה שאפליקציות הדסקטופ של Claude ושל GPT הן בפועל: סביבה עם הרשאות רחבות על המחשב שלכם, ובתוכה אייג׳נטים כלליים שיודעים לתכנן, להריץ ולתקן.
מכאן נגזרת חלוקת עבודה די ברורה, והיא הלב של כל פרויקט הטמעה שאני עושה:
- הטכנולוג מנגיש את המידע והכלים בקונקטור — MCP, plugin, extension, השם פחות חשוב — שהוא יציב ובטיחותי, ומתקין אותו.
- המשתמשים, גם הלא־טכניים, לומדים לכתוב לעצמם skills: דפי הוראות בשפה רגילה שמלמדים את האייג׳נט איך לבצע תהליך מסוים.
הטלוויזיה היא דוגמה קטנה ונקייה לשני השלבים האלה, כולל התפר ביניהם.
מה בניתי בפועל
טלוויזיות LG מדברות פרוטוקול בשם SSAP — בעצם JSON מעל websocket, על wss://<ip>:3001, עם תעודה self-signed. התחלתי מהעבודה הפתוחה שקיימת סביב webOS, אבל בסוף כתבתי client משלי מעל ws: הספרייה הנפוצה lgtv2 מיושנת, מבוססת callbacks, וגוררת חבילת websocket ישנה. מה כן לקחתי משם — את מניפסט ההרשאות שידוע שעובד לשלב ה-pairing.
התוצאה היא שלוש תלויות npm בסך הכול: ה-SDK של MCP, ws ו-zod.
כמה החלטות שנראות טכניות ובעצם הן החלטות מוצר:
- Pairing חד־פעמי. בקריאת השליטה הראשונה הטלוויזיה מציגה על המסך חלון אישור. מאשרים פעם אחת עם השלט הפיזי, הטלוויזיה מנפיקה client key שנשמר מקומית, וזהו. המפתח הזה עובד רק מתוך הרשת הביתית ורק מול הטלוויזיה הזאת — הוא לא מכיל שום פרטי חשבון.
get_statusלא נוגע בכלום. הוא מדווח מצב הדלקה, pairing, אפליקציה נוכחית וווליום, והוא עובד גם לפני ה-pairing — בלי להקפיץ את חלון האישור.- הדלקה דורשת Wake-on-LAN. טלוויזיה בסטנדבי סוגרת את כל פורטי ה-TCP, אז
power_onשולח magic packet ב-UDP ומחכה שהיא תעלה, בערך 15 שניות. - לחיצות כפתורים לא עוברות בסוקט הראשי. צריך לבקש מהטלוויזיה
getPointerInputSocket, לקבל כתובת wss חד־פעמית, ולכתוב אליה שורות בפורמט שלה. - הכתובת משתנה, וזה בסדר. אם ה-IP האחרון לא עונה, השרת מחפש את הטלוויזיה ב-mDNS ומעדכן את הקונפיג בשקט.
הכלי שהיה חסר: פידבק
הבעיה שגיליתי תוך כדי היא שהעולם הזה יודע לבצע פעולות אבל לא להראות מה מוצג על המסך. אפשר ללחוץ ימינה, אי אפשר לדעת מה קרה אחר כך. לאייג׳נט זה קטלני — הוא מנווט בעיוורון.
אז לקחתי מפרויקט פתוח אחר רעיון לכלי בודד — צילום מסך — ומימשתי אותו ב-MCP. בפועל זו קריאת executeOneShot שמחזירה JPEG בגודל 960×540, שהשרת מוריד מהטלוויזיה ומחזיר כבלוק תמונה. וידאו מוגן DRM יוצא שחור, אבל ה-UI והתפריטים נראים מצוין — כך שפריים שחור הוא בעצמו סימן שמשהו מתנגן.
זה השינוי הכי משמעותי בכל הפרויקט, והוא לא היה בתוכנית המקורית: ברגע שהאייג׳נט יכול להסתכל, הוא יכול לתקן את עצמו. זה נכון גם הרבה מעבר לטלוויזיה — כלי שרק מבצע פעולות ולא מחזיר מצב מכריח את המשתמש להיות העיניים של האייג׳נט, ושם בדיוק נשברת האוטומציה. כשאני בונה קונקטור לארגון, השאלה הראשונה היא לא ״אילו פעולות״, אלא ״מאיפה הוא ידע שהפעולה הצליחה״.
מה השרת בכוונה לא עושה
הרבה מהעבודה בקונקטור טוב היא דווקא בהגבלות:
press_buttonמוגבל ל-10 חזרות, עם 150 מילישניות בין לחיצה ללחיצה. אין לולאות ניווט אינסופיות.- אין retry storms: לכל היותר חיבור מחדש אחד לכל קריאה, ואף פעם לא ניסיון pairing חוזר בלולאה.
- ה-skill שנשלח יחד עם השרת מנחה את האייג׳נט להעדיף
launch_appעל פני ניווט בחצים. - נשארו בחוץ במכוון: ה-API הענני של LG, תמיכה בכמה טלוויזיות, HDMI-CEC, והזזת סמן עכבר.
הסוויטה רצה מול טלוויזיה מדומה שרצה בתוך הטסטים (ומול מיקרופון מדומה לכלי הקול), כך שאפשר להריץ אותה בלי חומרה בכלל.
עוד שתי החלטות קטנות שאני אוהב: הודעות השגיאה למשתמש כתובות בעברית, כי זה הבית שהשרת משרת. ואחרי שהבסיס עבד הוספתי גם זוג כלים למדידת עוצמת רעש בחדר דרך המיקרופון של המחשב (הם רצים דרך ffmpeg, ונתיב ההקלטה הוא macOS בלבד), עם כיול חד־פעמי מול אפליקציית מד־רעש בטלפון — כדי שאפשר יהיה לבקש ״תוריד ווליום עד שיהיה שקט״, והאייג׳נט יסגור את הלולאה בעצמו. עוד לא הרצתי את הכיול עצמו, אז בינתיים המספר הוא הערכה גסה ולא dB אמיתי.
השרת עצמו הוא stdio מקומי, ולכן אותו קוד בדיוק רץ אצלי ב-Claude Code וב-ChatGPT Work, שם הוא גם ארוז כ-plugin בשם ״שלט לטלוויזיה״. קונקטור אחד, כמה סביבות.
איפה ההדגמה נעצרה
עד כאן עשיתי את תפקידי כטכנולוג. האייג׳נט קיבל יכולות חדשות, ובאמצעותן הוא יכול לעשות ״הכל״ גם בטלוויזיה.
אבל בהדגמה שהקלטתי רואים שהתהליך לא הושלם. ה-MCP עובד, אבל הלייטנסי נורא, והאייג׳נט לא מצליח למצוא את הדרך למה שהוא מחפש בתוך אפליקציית yes+.
הפער הזה הוא כל הפואנטה. הוא לא נובע מבאג ולא מכלי חסר. הוא נובע מזה שאף אחד עדיין לא לימד אותו איך מנווטים בטלוויזיה, כמו שמלמדים משתמש אנושי חדש: מאיפה מתחילים, איפה החיפוש, מתי כדאי לצלם מסך ולבדוק לפני שממשיכים ללחוץ.
ה-skill הזה, אם וכשייכתב, לא ייראה כמו קוד. הוא ייראה כמו פסקה: ״כדי להגיע לתוכנית ב-yes+, תפתח את האפליקציה, תחכה שהיא תעלה, תצלם מסך ותוודא שאתה במסך הבית, ורק אז תתחיל לזוז.״ מי שכותב אותו הכי טוב הוא לא אני — אלא מי שמנווט שם כל ערב.
ההשלכה לעולם העסקי
ללמד את Claude לנווט בתוך yes+ זו כבר לא משימה טכנולוגית. זו יכולת שצריכה להיות לכל מי שעובד מול מחשב. זה מה שנקרא אימוץ AI.
למה כדאי ללמוד את זה? קודם כל כי זה כיף וקל. שנית, כי ברגע שהמחסום נשבר והעלות של לבנות skill מתקרבת לאפס, משתחררת היצירתיות של האנשים בארגון — ונבנים דברים באמת יעילים, מלמטה למעלה, על ידי מי שמכיר את התהליך.
התהליך שאני עושה עם ארגונים הוא שלושה שלבים: אתם רוכשים מנוי ל-Claude או ל-GPT; אני שובר כל מחסום אפשרי ומחבר לכם אותו להכל, בצורה בטיחותית ויציבה; ואני מלמד אתכם ואת העובדים איך להשתמש בדבר הזה.
שימו לב שהשלב השלישי הוא הארוך מבין השלושה, ושהוא לא נגמר. קונקטור מותקן פעם אחת; skills נכתבים כל שבוע, על ידי אנשים שונים, לתהליכים שאף אחד לא היה חושב עליהם מראש. זה בדיוק החלק שאי אפשר לעשות במקומכם.
מה לוקחים מזה
הצד ההנדסי של הטמעת AI קטן ממה שנדמה, ומסתיים מוקדם. שרת MCP לטלוויזיה זה ערב-שניים של עבודה; ללמד את הארגון לנווט בעזרתו זה מה שקובע אם משהו באמת ישתנה. אם אתם מודדים הטמעה במספר הקונקטורים שהותקנו, אתם מודדים את החלק הקל.
אם השלב השני הוא זה שמעניין אתכם, ככה נראה התהליך שאני עושה עם ארגונים.