ניסוי AI

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

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

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

נמאס לי לעבור בין הצ'אט לעורך, ועלה לי רעיון: מה אם אוכל להימנע מזה לחלוטין?

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

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

לאחר החיבור, המשתמש יכול לכתוב לסוכן ישירות מ-Builder:

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

זה התחיל כניסוי

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

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

ניתן לצייר את הדיאגרמה הקצרה ביותר כך:

Personal AI agent  <->  MCP  <->  Romergo Builder

אבל השלט לשני הכיוונים חשוב.

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

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

זה יוצר לולאה סגורה:

1. User -> Builder panel: "Replace the music in this chapter"
2. Builder -> authenticated channel: command + current page + selection
3. Personal agent -> MCP: wait for the next Builder command
4. Agent -> Romergo MCP tools: inspect and edit the project
5. Agent -> MCP channel: status, question, result, or error
6. Builder panel -> User: live response from the personal agent

רומרגו אינו מפעיל את הדגם באף אחד מהשלבים הללו.

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

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

איך סוכן נכנס לפגישה

Builder יוצר קוד ערוץ זמני. המשתמש מעתיק הודעת התחלה קצרה לצ'אט ה-AI שלו עם משהו כזה:

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

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

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

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

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

בזמן שהוא עובד, הסוכן יכול להתקשר לromergo_report_builder_event ולשלוח את הפאנל:

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

הזכויות שייכות לחדר, לא להנחיה

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

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

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

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

מה יש ברומרגו, ומה נשאר אצל המשתמש

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

רומרגו מספק:

סוכן המשתמש מביא:

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

למה לא לעשות טייס משנה מובנה רגיל

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

אבל אז רומרגו יצטרך להפוך גם למפעיל של תשתית AI:

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

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

החלק המוזר ביותר: הסוכן נמצא גם בחוץ וגם בפנים

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

אבל מנקודת מבטו של המשתמש, הסוכן נמצא בתוך העורך:

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

אני לא הראשון שהתקדם בכיוון הזה

לאחר שהניסוי עבד, התחלתי לחפש גישות דומות.

פרוטוקול לקוח סוכן מאפשר לעורכים כמו Zed ו-JetBrains לחבר סוכני קידוד חיצוניים. Tidewave מציב את קלוד קוד, קודקס וסוכני ACP אחרים ליד יישום האינטרנט הפועל ומעביר להם את ההקשר של הדפדפן וזמן הריצה. לקוח סוכן אובסידיאן מציג את קלוד קוד, קודקס וג'מיני ממש ליד הערות ומצרף אוטומטית את המסמך והבחירה הפעילים. marimo נותן לסוכן החיצוני מחברת חיה כמרחב עבודה משותף.

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

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

ניסוי רומרגו מעניין אותי בגלל שאלה קצת אחרת: מה יקרה אם סוכן משתמש אישי יוכל להיכנס לאפליקציה יצירתית רגילה?

לא דגם חדש. לא מפתח API לדגם. לא יישום פיילוט מובנה. סוכן שאדם כבר משתמש בו כל יום.

נוחות היא רק חצי מהבעיה

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

עולות שאלות שלא ניתן לענות עליהן במסך OAuth אחד:

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

איך לקרוא לזה

עדיין אין לי כותרת סופית.

Bring Your Own AI פירושו בדרך כלל מפתח API משלך או בחירת דגם. Bring Your Own Agent קרוב יותר מכיוון שהמשתמש מביא לא רק את המודל, אלא גם זיכרון, כלים ולופ סוכן. עם זאת, BYOA אינו מתאר חלק חשוב מהניסוי: האפליקציה יכולה גם ליצור קשר עם הסוכן ולקיים איתו סשן חי.

אולי זה:

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

ייתכן שיישומים לא צריכים AI מקורי

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

יש עוד דגם אפשרי.

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

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

אבל אני כן יודע שלהתנסות זה כיף גדול.

חזרה לבלוג הפיתוח