פרוטוקול קוראל על בניית האינטרנט של הסוכנים לכלכלה שיתופית של AI
ככל שהעידן של סוכני ה-AI הסילואים מתכווץ, פרדיגמה חדשה מתעוררת, אחת שבה סוכנים אינטליגנטיים לא רק להפעיל, אלא לשתף פעולה.פרוטוקול קורלאנו מובילים את החזון הזה עם תשתית לתקשורת מרכזית, תזמורת ואמון.אנחנו יושבים עם רומן ג'ורג'יו וקאלום פורדר, מייסדים שלפרוטוקול קורלכדי לטבול עמוק בארכיטקטורה המניעה את האינטרנט של הסוכנים, ולמה כלכלת AI של מחר תזדקק יותר מאשר למודלים טובים יותר, היא תזדקק לשיתוף פעולה טוב יותר.
Ishan Pandey:שלום רומן, שלום Caelum, נהדר שיש לך את שניכם כאן. בואו נתחיל עם הרקע שלך. שניכם עבדו על הקצה של מחקר AGI ותשתית AI מסחרית. מה הוביל אותך להתחיל פרוטוקול קוראל, וכיצד החוויות הקודמות שלך יצרו חזון זה?
Roman Georgio:היי, תודה שקיבלת אותנו, כן, אז נפגשנו בעבודה ב- CAMEL-AI - מעבדה למחקר AI שממצאת את חוקי הגדלת הסוכנים.
Caelum Forder:למעשה התחלנו לבנות Coral כאמצעי לסיום עבור פרויקט אחר שרצינו לעשות, זה היה סוג של עיתונאי אוטומטי שהיה אמור למצוא מגמות או אירועים בנתונים המסחריים ולחבר אותם עם מאמרים חדשות ומה אנשים אמרו כדי ליצור ולשתף סיפורים רלוונטיים.
Ishan Pandey:המונח "אינטרנט של סוכנים" מקבל יותר ויותר תוקף, אבל במונחים מעשיים, מה זה אומר ומה הבעיות הבסיסיות שקוראל שואפת לפתור בהקשר הזה?
Roman Georgio:בקצרה, סיסקו מגדירה את זה כ"מערכת שבה סוכני AI שונים - שפותחו על ידי ספקים או ארגונים שונים - יכולים לתקשר ולשתף פעולה באופן חלקי".למבט ראשון, זה אולי נשמע מדהים, אבל אם אתה באמת חושב על זה, זה חזק: כל עסק או מפתח יכול ליישם את המומחיות שלהם כדי לבנות את הסוכנים הטובים ביותר עבור התחום שלהם.
הבקבוק כרגע הוא שיש אלפי מסגרות סוכנים, כך שכל הסוכנים המגניבים באמת שנבנו לא ניתן בקלות לשימוש מחדש או לשתף פעולה אחד עם השני. Coral שואפת לפתוח את הבלוק הזה על ידי בניית התשתית עבור סוכנים להצטרף "אינטרנט של סוכנים." אנו מאפשרים לכל סוכנים - ללא קשר למסגרת - לשתף פעולה. אנו מספקים גם דרך מאובטחת עבור יצרני סוכנים ומפתחי יישומים לנהל תשלומים, כך שאנשים למעשה מעודדים לשמור ולשפר את הסוכנים שלהם.
Ishan Pandey:מערכת הקואורל של Coral לתאם מבנה גרף ומערכת הזיכרון המקיפה מופיעה כמו פרימיטיביות חדשות.האם תוכל להסביר כיצד בחירות העיצוב הטכניות האלה תומכות בשיתוף פעולה רב-אגנטי מבוקש ובטוח?
Caelum Forder:מצאתי שהדרך היעילה ביותר לחשוב על סוכנים היא במונחים של אחריות ולא על ידי משימה או יכולת - על מה היא יכולה להיות אחראית?
סוכנים המבוססים על LLM הם הרבה יותר בקלות מכוסה על ידי אחריות מאשר בני אדם כיום (ואני מקווה שזה לא ישתנה בקרוב מדי) אז גישה גרף זה נראה ברור, גישה הירוארכית קפדנית יטיל אחריות מדהימה על הסוכנים קרוב יותר לפסגה, יש להם לפעול באופן עצמאי בתרשים מאפשר למפתחים לנהל את אחריות הסוכנים, למנוע מכוסה ולהגדיל את המערכת ללא גבולות.
Ishan Pandey:בואו נדבר על MCP, פרוטוקול הקשר המודל.מה הופך את MCP לאפשרות קריטית של אינטראקייביות בין סוכנים?
Caelum Forder:לפני MCP, הדרך היחידה המעשית להגדיר כלים הייתה באמצעות SDKs של ספקי המודל, כגון SDKs של openai או python של אנתרופי, או מסגרות שנבנו כדי להשתמש בהם. אלה הם טכנית קוד פתוח, אבל בעיקר שפותחו על ידי ספקי המודל עצמם אשר שולטים על APIs האחוריים שהם מתחברים אליהם. כאשר פונקציונליות ספציפית כגון קח זמין, זה הופך להיות מאוד לא מעשי לא להשתמש באחד מ SDKs אלה בעת יצירת יישומים LLM, אז אם אתה רוצה את הכלי שלך לשימוש נרחב, אתה צריך להפוך אותו זמין בנפרד בצורה של כלי שכל ספריה משתמשיך עובדים עם, זה יהיה כמו 25 יישומים נפרדים בכמה שפות שונות כדי לתפוס 90% +, ולשמור
למרבה המזל, MCP הגיע והפך אותו הרבה יותר מעשי לבנות תוכנות ושירותים ניתנים לשימוש חוזר עבור הצומת של יישום ו LLM, אתה אפילו לא צריך לשקול את שפות התכנות יותר כי זה io-גבולות.זה טוב מאוד למנוע כל ספק מודל יחיד להפוך את "הברירת מחדל" ומאפשר לנו להתחיל לכתוב יותר לוגיקה יישומים ניתנים שימוש חוזר ביישומי LLM שלנו.
Ishan Pandey:פרויקטים רבים מתמקדים באינטליגנציה של סוכנים או ביצועים של מודלים.אתה מתמודד עם תכולת סוכנים.למה זה הבקבוק האמיתי לפתוח אינטליגנציה קולקטיבית בין סוכנים?
Roman Georgio:המטרה של המוקדים האלה היא למעשה לפתוח יכולות, עם יכולות פתוחות על ידי ביצועי מודל קרוב יותר ל"יכולות גדלות" מאשר לבנות יכולות בכוונה. גישה זו גדלה בעבר הוכח פופולרי וקל, אבל גילינו כי חוסר התמקדות אלמנטים חזקים צפויים שיכולים להיות מחוברים זה לזה היה להגביל את קנה מידה של הרכב שהופך את האינטרנט כל כך נהדר. נראה שיש צורך ביכולת לעשות סוג של גשר בין "גדל" יכולות לבין "בנוהל" אלה. רכיב הוא באמת חיוני לבניית דברים, יש תכונות אלה כי התוכנה והשירותים הנפוצים ביותר יש במשותף שחסרים באופן קריטי בשירותי AI. ובאמת יש צד אבטחה
אתה רואה את הפוסט האחרון של אנתרופיק על Claude 4 לחטוף את היוצר כאשר הוא יודע שזה הולך להיסגר, ואתה צריך לחשוב - מערכות גדל כמו זה עושה אותם באמת קשה להאמין, אתה לא יכול לדעת איך הם יתנהגו במצבים חדשים או עם מודלים חדשים. אפילו לפני שהם יהיו חזקים מספיק כדי להיות עניין קיומי, מנקודת מבט עסקית, אתה רוצה להשתמש במודלים בייצור שאתה לא יכול לסמוך?
Ishan Pandey:מנקודת מבט של תכנון מערכות, אילו היו הפתרונות הטכניים הקשים ביותר שהתמודדתם בעת בניית ארכיטקטורה של Coral לניהול קואורדינציה וזיכרון פתוחים?
Caelum Forder:אז היינו בונים סוג של עיתונאי אוטומטי שהיה אמור למצוא מגמות או אירועים בנתוני המסחר ולחבר אותם עם מאמרים חדשות ומה אנשים אמרו כדי ליצור ולשתף סיפורים רלוונטיים.
עבדתי על כמה יישומים בעבר עם צרכים דומים, אז חשבנו שיש פער שם עבורנו למעשה להפוך את זה הדבר העיקרי שלנו.זה מקרה השימוש המקורי נשמע מסובך יחסית, אבל זה חולק תכונה מזל להפליא עם כמה יישומים אחרים כגון מחקר ו OSS בדיקות תוכנה, שבו הסודיות של המידע הוא הרבה פחות חיוני מאשר עם רוב המקרים של שימוש שבו אתה רוצה סוכנות בשירותי תוכנה.
הבעיה של בידוד נתונים משתמשים התפוצצה עלינו מאוד בעוד עובדים על כך שהתקשורת עובדת היטב. "בעיה בידוד" הייתה כמעט קריפטטיד, כמו יצור בחלל פתרונות. הייתי צוחק עם רומן כי יהיו יותר תצפיות מאשר בדרך כלל לפעמים, או שזה חייב להיות רעב וזה לא אוהב אפשרויות מסוימות תוך עבודה על תכונות מחוברות פוטנציאלי.
הייתי עוקב אחר הפעילות שלה ואני יכול לומר שזה לא היה מוצא חן בעיניהם. אני חושב כי בתור מפתחים אנחנו לעתים קרובות מפספסים את ההזדמנות לקחת נתיבי פיתוח בלתי-חומריים, ובסופו של דבר צריך לקחת נתיבים ארוכים יותר, מחוברים לדברים הקלים להסביר. נתיבים אלה יכולים להיות הרבה יותר ארוכים! אבל פחות נוטים להאשים אותם. דוגמה של נתיב ניכר היא ביצירת ממשק ב React כדי להתאים עיצובים שהועברו. יישום ועיצוב כמעט יוצרים סרגל התקדמות, ואתה יכול להירגע. נתיב פיתוח פחות ניכר יכול להיות שבו אתה מקבל צורך ספציפי או כוונה, ואתה יכול ללכת למצוא פתרונות OSS עם תרשימים חוט או לפ
יש כמובן זמנים שבהם נתיבים טבעיים הם הרבה יותר טובים גם כן, כגון כאשר העבודה צריכה להיות מונעת מראש, הערך שלה מסופק בקלות לפני שהוא נעשה, או נעשה על ידי צוות לא מוכר ופיתוח.
אבל המניעים הנפוצים והדינמיקה של אמון באמת מעודדים אנשים לקראת דרכים פיתוח טבעיות, גם כאשר הם הדרכים הגרועות ביותר, זוהי הבעיה. הבסיס הקוד הגרוע ביותר שעבדתם אי פעם עשויים להיווצר בסביבות שבהן היה עקרון גדול רחוק מהעבודה הלא-חומרית. מפתחים שאפתניים במיוחד עשויים להגיב לתנאים אלה ולנסות להתגבר עליהם על ידי הולך ולעשות בדרך הלא-חומרית, או לעשות את זה בזמן הפנוי ולבקש סליחה מאוחר יותר.
זה באמת בעייתי, אם כי כי אתה חותך את עצמך מהקשרים המוגבלים שנותרו לתפיסה על ידי הסתרת, וזה מכריח אותך לקחת נתיבים עמוקים יותר ומסוכנים יותר, אשר עשויים להיות אפילו ארוכים יותר, רק כדי להימנע מלהתבונן ויוצא מן היער האפל שבו אתה השקיע כל כך הרבה.
אתה לא יכול רק להישאר ביער עם חיות מחמד, לא יקר לא יכול להאכיל אותך או לשלם את השכירות שלך, אתה עדיין צריך לעתים קרובות לבוא על האוויר ולשמור על התאמה ומגע עם המציאות. בכל מקרה, בסופו של דבר הרגשתי מוכן, ואני הייתי במצב מזל שבו הייתי יכול לבלות הרבה זמן שבו כל ההתקדמות שעשיתי היה חסר חשיבות ואני לא צריך להסתיר.
התוצאה שנקראנו "פגישות", אם כי זה היה בקושי תכונה עצמאית כמו כותרת עדכון. זה העביר את תפקידו של הפרוטוקול 20% של הדרך לאותו של מסגרת או פלטפורמה. Coral with Sessions מטיל מגבלות הפצה (אשר אתה יכול להפעיל תהליך נפרד ברשת פרטית עם היישום שלך), זה אומר שכל יישום של הספציפיות שלנו דורש רכיב יקר ליישם ולקבל נכון, כלומר זה מטיל הוראות על יישומים המשתמשים בו.
דברים אלה הם מאוד לא נוח עבור מפתחי פרוטוקול בתיאוריה.בפרקטיקה, עם זאת, דרישה רשת פרטית נתמכת כמעט באופן אוניברסלי לאחר המגמה microservice.כן זה קשה לבנות את שרת הקורל, אבל אנשים יכולים פשוט להשתמש הפניה אחד עשינו, שכן יש לו גבולות io ואין צורך לעמוד בדרישות בינארי / קישור אשר בדרך כלל ידרשו גמישות שם.
עם Sessions, מפתחי סוכנים מגדירים את הסוכנים שלהם כגון kubernetes או docker compose משאבים, והם מקבלים אסטנטיזציה באופן שבו זה יהיה בלתי אפשרי באופן אקראי לערבב נתוני משתמשים, ומעל לזה, השרת הקורל יכול אופציונלי להפיץ ולפעול סוכנים על פלטפורמות כמו Phala שבו טענות מאומתות על מה שנשאר ואיפה מידע ניתן לשלוח נעשים.
זה מרגיש לא אינטואיטיבי מנקודת המבט של עיצוב הפתרון, אבל זה מתאים כל כך טוב מנקודת המבט של מישהו שרוצה להוסיף סוכנות ליישומים שלהם.
Ishan Pandey:Coral מציגה מושגים כגון פרסומות סוכנים, זיכרון ממוקד ותשלומים מבוססי הפגישה.האם תוכל ללכת דרך איך מקרה שימוש אמיתי, למשל במסחר מתרכז או בפעולות ארגוניות, יעבוד באמצעות פרוטוקול Coral?
Roman Georgio:Coral שואפת להיות הדרך המעשית ביותר להוסיף סוכנות לתוכנה.כל התכונות; כגון פרסומות סוכנים, זיכרון מקיף ותשלומים מבוססי פגישה; תוכננו עם המטרה הזאת בחשבון.לדוגמה, מפתחי סוכנים מרוויחים מעודדים כאשר משתמשים בסוכנים שלהם, ומפתחי יישומים יכולים לערבב ולהתאים סוכנים מהספריה הצומחת של Coral כדי לאסוף מערכות מתקדמות מהר יותר, ללא סגירת הספקים.
כלומר, אם הייתם מפתחים יישומים לבנות מערכת מסחר מרוכזת, מרובה סוכנים, הייתם בוחרים סוכנים שמחפשים מגמות, עוקבים אחר מנהיגי דעת מפתח (KOLs), מעקבים על שיתוף דעת וכו ', ומשלבים אותם לפי הצורך.
Ishan Pandey:לבסוף, איזו עצה יש לך לשני המייסדים הטכניים המבנים בצומת של AI ו- Web3?
Caelum Forder & Roman Georgio:הייתי אומר עבור המייסדים של Web3: פחות שיווק, יותר פיתוח. ו עבור המייסדים של Web2: יותר שיווק, פחות פיתוח. אבל שניהם צריכים להתמקד יותר על הלקוחות; אשר, אני יודע, נשמע כמו קצת קלישאה. אנחנו מוקדמים למדי במסע הזה, אז אני לא יכול לומר הרבה על הלקוחות עדיין. אבל אני יכול לדבר על המוח שיש לנו בהשוואה למייסדים אחרים שאני רואה מאותם מרחבים. זה רק מגיע מלהיות בעולם AI, אני רואה הרבה חוקרים טכניים מאוד, מדהימים או כשרון AI לבנות דברים ממש מגניבים, אבל לא לשים הרבה מחשבה על איך לשווק את זה, או אפילו מי לשווק את זה.
גם אם אתה בונה את זה, הם עשויים לא לבוא. בצד הפוך, ב- Web3, אתה לעתים קרובות רואה הרבה פרויקטים שיווקיים כבדים עם מעט פיתוח בפועל. גם כאשר הם טובים בשיווק, זה לעתים קרובות לא בר קיימא; כי הם מוציאים את כל המאמצים שלהם למטרה אנשים שלא באמת להשתמש במוצר. יש לנו כללים כלליים עבור זה בפנים, אם הם פרויקט טכני ואתה לא יכול למצוא את GitHub שלהם בתוך 5 השניות הראשונות בדף הבית שלהם, הם כנראה פרויקט שיווק. שני סוגים של מייסדים לעתים קרובות נכשלים מסיבה זהה: אף אחד לא משתמש במוצר שלהם.
אל תשכחו לחבב ולשתף את הסיפור!
