Коралниот протокол за градење на интернетот на агентите за соработка на ИИ економијата
Како што ерата на силоданите агенти за вештачка интелигенција исчезнува, се појавува нова парадигма, каде што интелигентните агенти не само што извршуваат, туку и соработуваат.Коралниот протоколе пионер на оваа визија со инфраструктура за децентрализирана агентна комуникација, оркестрација и доверба. Ние седнеме со Роман Георгио и Caelum Фордер, соосновачи наКоралниот протоколЗа да се нурне длабоко во архитектурата што го поттикнува Интернетот на агентите, и зошто утрешната економија на вештачката интелигенција ќе треба повеќе од само подобри модели, ќе биде потребна подобра соработка.
Ishan Pandey:Здраво Роман, Здраво Caelum, одлично е да ги имате и двајцата тука. Да почнеме со вашата позадина. И двајцата сте работеле на работ на AGI истражување и комерцијална инфраструктура за вештачка интелигенција. Што ве натера да го започнете Коралниот протокол и како вашите минати искуства ја обликуваа оваа визија?
Roman Georgio:Еј, благодарам што нè имаш, да, па се сретнавме на работа во CAMEL-AI - истражувачка лабораторија за вештачка интелигенција која ги открива законите за скалирање на агентите.
Caelum Forder:Всушност, почнавме да градиме Coral како средство за завршување на друг проект што сакавме да го направиме, тоа беше вид на автоматски репортер кој беше наменет да најде трендови или настани во трговските податоци и да ги поврзе со вести и она што луѓето велеа да креираат и споделуваат релевантни раскази.
Ishan Pandey:Терминот „Интернет на агенти“ станува сè повеќе привлечен, но во практична смисла, што значи и кои фундаментални проблеми Coral има за цел да ги реши во овој контекст?
Roman Georgio:Накратко, Cisco го дефинира како:„Систем каде што разни агенти за вештачка интелигенција – развиени од различни продавачи или организации – можат да комуницираат и да соработуваат беспрекорно.“ На прв поглед, ова може да звучи потполно, но ако навистина размислите за тоа, тоа е моќно: секој бизнис или програмер може да го примени своето знаење за да ги изгради најдобрите агенти за нивниот домен.
Во моментов има илјадници рамки за агенти, така што сите навистина кул агенти кои се градат не можат лесно да се користат повторно или да соработуваат едни со други. Coral има за цел да го отклучи овој блокер со градење на инфраструктурата за агентите да се приклучат на "Интернетот на агентите". Ние овозможуваме секој агент - без оглед на рамката - да соработува. Ние исто така обезбедуваме безбеден начин за креаторите на агенти и програмерите за обработка на плаќања, така што луѓето всушност се охрабруваат да ги одржуваат и подобруваат своите агенти.
Ishan Pandey:Графички структурираната координација и системот за меморија на Coral се издвојуваат како нови примитиви.Можете ли да објасните како овие технички избор на дизајн поддржуваат скалабилна, безбедна мулти-агентска соработка?
Caelum Forder:Најкорисен начин за размислување за агентите е во однос на одговорноста, а не според задачата или способноста - за што може да биде одговорен?
Агентите базирани на LLM се многу полесно преоптоварени со одговорност отколку луѓето во моментов (и се надеваме дека ова нема да се промени премногу брзо) Така што тогаш овој графички пристап изгледа очигледно, строго хиерархичен пристап ќе наметне преоптоварувачки одговорности на агентите поблиску до врвот, имајќи ги независно да работат во графиконот им овозможува на програмерите да ја управуваат одговорноста на агентите, да спречат преоптоварување и да го прошират системот без граници.
Ishan Pandey:Ајде да зборуваме за MCP, протоколот за контекст на моделот. Што го прави MCP критичен овозможувач на интероперабилност меѓу агентите?
Caelum Forder:Пред MCP, единствениот практичен начин за дефинирање на алатките беше преку сопствените SDK на провајдерот на моделот, како што се openai или python SDKs на Anthropic, или рамки изградени за да ги користат. Овие се технички со отворен код, но најчесто се развиени од самите провајдери на модели кои ги контролираат АПИ-то на задната страна со кои се поврзуваат. Како што станува достапна специфична функционалност како што е prompt caching, станува многу непрактично да не се користи еден од овие SDK при создавање на апликации LLM, па ако сакате вашата алатка да се користи широко, ќе треба да ја направите достапна одделно во форма на алатка со која секоја библиотека на вашите корисници работи, што би било како 25 посебни имплементации на
За среќа, MCP дојде и го направи многу попрактично да се изгради повторувачки софтвер и услуги за пресекот на апликацијата и LLM, дури и не треба да ги разгледате програмските јазици повеќе, бидејќи е io-ограничен.
Ishan Pandey:Многу проекти се фокусираат на интелигенцијата на агентот или перформансите на моделот. Вие се занимавате со компонирањето на агентот. Зошто ова е вистинската пречка за отклучување на колективната интелигенција на агентите?
Roman Georgio:Целта на тие фокуси е всушност за отклучување на способности, со способности отклучени од страна на перформансите на моделите поблиску до "растечки способности" отколку намерно градење способности. Овој претходно растечки пристап се покажа популарен и лесен, но идентификувавме дека недостатокот на фокус на цврсти предвидливи елементи кои можат да се поврзат е ограничување на скалата на составот што го прави Интернетот толку голем. Се чини дека постои барање за способност да се направи вид на мост помеѓу "растените" способности и "изградените". Композибилност е навистина од суштинско значење за градење работи, постојат овие својства кои повеќето повторно користени софтвер и услуги имаат заеднички кои се критично недостасуваат во услугите на АИ. И всу
Гледате најновиот пост на Anthropic за Claude 4 изнудувајќи го креаторот кога знае дека ќе биде затворен, и мора да размислите - растечките системи како ова ги прават навистина тешки за доверба, не можете да знаете како ќе се однесуваат во нови ситуации или со нови модели. Дури и пред да станат доволно моќни за да бидат егзистенцијална загриженост, од бизнис гледна точка, сакате ли да користите модели во производството на кои не можете да им верувате?
Ishan Pandey:Од гледна точка на дизајнот на системите, кои беа најтешките технички компромиси со кои сте се соочиле при изградбата на архитектурата на Coral за отворена координација и управување со меморијата?
Caelum Forder:Значи, изградивме еден вид автоматски репортер кој требаше да најде трендови или настани во трговските податоци и да ги поврзе со вести и она што луѓето велеа за да создадат и споделат релевантни раскази.
Работев на неколку апликации пред со слични потреби, па помисливме дека постои празнина таму за да го направиме ова нашата главна работа.Оригиналниот случај на употреба звучи релативно комплицирано, но споделува неверојатно среќно својство со некои други апликации како истражување и тестирање на софтвер OSS, каде што доверливоста на информациите е далеку помалку неопходна отколку со поголемиот дел од случаите на употреба каде што сакате агенција во софтверските услуги.
Проблемот со изолацијата на податоците на корисниците многу ни се закануваше додека работевме на комуникацијата. „Проблемот со изолацијата“ беше речиси криптид, како суштество во просторот за решенија. Сакав да се шегувам со Роман дека понекогаш ќе има повеќе забелешки од вообичаеното, или дека мора да биде гладно и дека не би сакал одредени опции додека работи на потенцијално поврзани карактеристики. Имав како 5 прилично длабоки решенија дизајнирани, секоја со значајни компромиси и свој сет на пречки.
Јас бев следење на неговата активност и можев да кажам тоа не би им се допадна. Мислам дека како програмери ние често ја пропуштаме можноста да преземе нематеријални патеки за развој, и на крајот мора да преземе подолги патеки, зацврстени на работи кои се лесни за објаснување. Овие патеки може да бидат многу подолги! Но помалку подложни на вина. Пример за материјален пат е правење на интерфејс во React да одговара на дизајни кои се предадени. имплементацијата и дизајнот практично формираат лента за напредок, и можете да се релаксирате. Помалку материјален пат за развој би можел да биде каде што ви се дава специфична потреба или намера, и може да одите да најдете решенија за ОСС со
Се разбира, постојат моменти кога материјалните патишта се многу подобри, како што е кога работата треба да биде предодредена, нејзината вредност лесно да се комуницира пред да се направи, или да се направи од страна на непознат и скалирање тим.
Но, заедничките стимули и динамиката на довербата навистина ги пристрастуваат луѓето кон опипливи патеки на развој, дури и кога тие се најлошите патеки, ова е проблемот. Најлошите бази на кодови на кои некогаш сте работеле веројатно се формирале во средини каде што имаше голема пристрасност подалеку од нематеријалната работа.
Ова е навистина проблематично, иако затоа што се отсекувате од ограничените преостанати врски до опипливоста со криење, и ве присилува да преземете подлабоки и поопасни патеки, кои би можеле да бидат уште подолги, само за да избегнете да бидете забележани и извлечени од темната шума во која сте инвестирале толку многу.
Вие не можете само да останете во шумата со криптиди, Не-драги не можат да ве нахранат или да ја платат вашата изнајма, сепак треба често да дојдете за воздух и да одржувате усогласеност и контакт со реалноста. Во секој случај, на крајот се чувствував подготвен, и бев во многу среќна позиција каде што можев да поминам многу време каде што целиот напредок што го направив беше нематеријален и не требаше да се кријам. Не можам доволно да нагласам колку ретки и среќни се овие услови.
Резултатот го нарекуваме „сесии“, иако тоа едвај беше самостојна функција колку што е насловот на ажурирањето. Тоа ја промени улогата на протоколот 20% од патот кон онаа на рамка или платформа. Coral with Sessions наметнува ограничувања за распоредување (да можете да покренете посебен процес на приватна мрежа со вашата апликација), тоа значи дека секоја имплементација на нашата спецификација бара компонента која е скапа да се имплементира и да се добие правилно, што значи дека суптилно наметнува прописи на апликациите кои ја користат.
Овие работи се многу непријатни за програмерите на протоколот во теорија. Во пракса, барањето за приватна мрежа е речиси универзално поддржано по трендот за микро-услуги. Да, тешко е да се изгради серверот за корали, но луѓето можат само да го користат референтниот оној што го направивме, бидејќи има граници на io и не треба да ги исполнува барањата за бинарни / врски кои обично би побарале флексибилност таму.
Со сесии, програмерите на агенти ги дефинираат своите агенти како kubernetes или docker compose ресурси, и тие се инстантирани на начин каде што би било невозможно случајно да се мешаат корисничките податоци, а над тоа, серверот на корали може опционално да распореди и да работи со агенти на платформи како Phala каде што се направени проверени тврдења за тоа што се одржува и каде што може да се испрати информации.
Се чувствува неинтуитивно од перспективата на дизајнот на решенијата, но тоа се вклопува толку добро од перспективата на некој кој сака да додаде агенција на нивните апликации. Исто така, го ограничува агентите кои се веќе во фиксна 1-процес имплементација, можеби од решение без код, но ми се чини неверојатно вреди.
Ishan Pandey:Coral воведува концепти како што се рекламирање на агенти, сферирана меморија и плаќања базирани на сесија.Можете ли да ни кажете како вистински случај на употреба во реалниот свет, на пример, во децентрализираната трговија или корпоративните операции, ќе функционира користејќи го протоколот на Coral?
Roman Georgio:Сигурно! Coral има за цел да биде најефикасен начин да додадете агенција на софтверот. Сите карактеристики, како што се реклами за агенти, опсежна меморија и плаќања базирани на сесија, се дизајнирани со таа цел на ум. На пример, програмерите за агенти заработуваат стимули кога се користат нивните агенти, а програмерите за апликации можат да се мешаат и да ги совпаѓаат агентите од растечката библиотека на Coral за да ги соберат напредните системи побрзо, без да се заклучуваат продавачите.
Тоа значи дека ако сте програмер кој гради децентрализиран, мулти-агентски трговски систем, едноставно ќе ги одберете агентите кои ги истражуваат трендовите, ги следат клучните лидери на мислењето (KOLs), го следат споделувањето на умот итн.
Ishan Pandey:Конечно, каков совет и двајцата имате за техничките основачи кои градат на пресекот на АИ и Веб3?
Caelum Forder & Roman Georgio:Јас би рекол за основачите на Web3: помалку маркетинг, повеќе развој. И за основачите на Web2: повеќе маркетинг, помалку развој. Но и двајцата треба да се фокусираат повеќе на клиентите; што, знам, звучи како малку клише. Ние сме доста рано на ова патување, па не можам да кажам многу за клиентите уште. но можам да зборувам за начинот на размислување што го имаме во споредба со другите основачи што ги гледам од овие простори. Ова само доаѓа од тоа да се биде во светот на АИ, гледам многу високо технички, брилијантни истражувачи или AI талент градење навистина кул работи, но не се стави многу размислување за тоа како да се маркетинг, или дури и кој да го маркетинг на.
Дури и кога тие се добри во маркетинг, тоа често не е одржливо; бидејќи тие ги трошат сите свои напори насочени кон луѓе кои навистина нема да го користат производот. имаме општо правило за ова внатрешно, ако тие се технички проект и не можете да го најдете нивниот GitHub во првите 5 секунди на нивната почетна страница, тие најверојатно се маркетинг проект. И двата типа на основачи честопати не успеваат од истата причина: никој не го користи нивниот производ. Нешто што имавме мислење секој чекор на патот е она што ова крајно искуство изгледа како за корисникот, сакаме да изградиме нешто што е навистина користено и корисно, како и кул.
Не заборавајте да се допаѓа и споделување на приказната!
