(z perspektywy doświadczenia dewelopera i kompatybilności, długoterminowa wartość $VANRY )

VANRY
VANRY
--
--

Jeśli pytasz mnie: na czym opiera się wygrana infrastruktury AI-first? Nie będę najpierw rozmawiać o TPS, ani o narracjach. Zadałbym najpierw bardziej 'inżynieryjne' pytanie: czy deweloperzy mogą włączyć zdolności inteligentnego agenta jak klocki, i stabilnie działać przez rok?

AI wprowadza Web3 w nowy etap: na łańcuchu nie ma tylko aktywów i kontraktów, ale pojawi się wiele 'inteligentnych modułów'. Są one podobne do bibliotek i usług w inżynierii oprogramowania: niektórzy specjalizują się w pamięci semantycznej, inni w wnioskowaniu i wyjaśnieniach, inni w automatyzacji wykonania, a jeszcze inni w rozliczeniach i zgodności. Problem polega na tym, że — jeśli te zdolności brakuje jednolitego sposobu dostępu i brakuje możliwości ponownego użycia podstawowej abstrakcji, deweloperzy utkną w nieskończonym 'piekle integracyjnym':

Każdy inteligentny komponent musi być dostosowywany do struktury danych.

Za każdym razem, gdy zmienia się ekosystem, trzeba napisać nową warstwę integracyjną.

Po prawdziwym uruchomieniu, trudno zlokalizować problemy: czy pamięć została utracona? Czy wnioskowanie jest błędne? Czy warunki wykonania nie zadziałały? A może kanał rozliczeniowy jest zablokowany?

Na końcu inteligentny agent staje się zbiorem rozproszonych demo, niemożliwych do skalowania.

To jest to, co rozumiem jako wejście do Vanar: to nie jest robienie 'mądrzejszego AI', ani 'szybszego łańcucha'. To bardziej jak robienie czegoś długoterminowego, ale kluczowego: przekształcenie podstawowych zdolności potrzebnych przez inteligentne agenty w standardowe komponenty na poziomie infrastruktury, aby deweloperzy mogli budować inteligentne aplikacje z mniejszym oporem.

Innymi słowy: konkurencja w erze AI często polega na tym, 'kto jest łatwiejszy w użyciu'. Kto potrafi obniżyć 'koszt dostępu', 'koszt ponownego wykorzystania' i 'koszt międzyekosystemowy', ten ma większe szanse stać się domyślnym wyborem.

1) AI-first vs AI-added: różnica nie leży w komunikatach marketingowych, ale w tym, czy 'interfejs był projektowany od samego początku dla inteligentnych modułów'

Wiele łańcuchów mówi 'my też wspieramy AI'. Ale gdy spojrzysz na prawdziwy przepływ pracy deweloperów, dostrzegasz różnicę:

'AI-added' zazwyczaj traktuje AI jako funkcję na poziomie aplikacji, robi kilka SDK, kilka demonstracji, a następnie ma nadzieję, że ekosystem sam się rozwinie. Jednak aby moduły inteligentne mogły się rozwijać, najgorsze, co może się zdarzyć, to brak odpowiednich interfejsów i abstrakcji na poziomie podstawowym.

Znaczenie AI-first jest bardziej konkretne w inżynierii:

Od pierwszego dnia zakładamy, że na łańcuchu będzie wiele inteligentnych agentów współpracujących z inteligentnymi modułami, więc potrzebujemy bardziej naturalnego wsparcia: długoterminowej dostępności stanu, możliwości śledzenia procesu wnioskowania, kontrolowanej automatyzacji działań oraz zamkniętej pętli rozliczeniowej. To nie są rzeczy, które można naprawić 'dodając przycisk funkcji'; bardziej przypomina to decyzję o tym, jak zaprojektować jądro systemu operacyjnego od samego początku.

@Vanarchain Talking Points podkreśla 'dostosowanie do rzeczywistego użycia, a nie narracji'; wolałbym przetłumaczyć to na język inżynieryjny:

Nie pytaj, czy możesz zrobić demonstrację, najpierw zapytaj, czy możesz dać deweloperowi podstawową warstwę inteligentnego agenta, którą można ponownie wykorzystać i konserwować.

2) Czym właściwie jest 'gotowość AI'? Z perspektywy dewelopera to cztery podstawowe zdolności, które 'muszą istnieć i współdziałać'.

Wielu ludzi myli gotowość AI z 'szybkością'. Ale gdy naprawdę tworzysz aplikacje inteligentnych agentów, odkrywasz, że prędkość to tylko powierzchnia. Głębiej chodzi o cztery zdolności, które muszą ze sobą współpracować; w przeciwnym razie cały system będzie miał trudności z wyjściem z POC:

Pamięć: to nie jest 'co było omawiane', lecz kontekst i stan semantyczny potrzebny do długoterminowych zadań inteligentnego agenta.

Wnioskowanie: to nie jest 'dawanie odpowiedzi', lecz zdolność do zrozumienia, przeglądania i ufania łańcuchowi decyzji.

Automatyzacja: to nie jest 'zdolność do wykonania', lecz zdolność do przekształcenia wykonania w stabilne komponenty procesowe.

Rozliczenie: to nie jest 'możliwość przelewu', lecz możliwość przekształcenia działań inteligentnego agenta w zamkniętą pętlę rzeczywistej działalności gospodarczej.

Wykonanie tych czterech rzeczy nie jest trudne, trudne jest, aby stały się one kompatybilne: czy deweloperzy mogą połączyć je jak standardową bibliotekę, z mniejszymi potknięciami, mniej przepisami i mniejszymi kosztami integracji.

@Vanarchain przykłady produktów (myNeutron / Kayon / Flows) nie traktuję jako 'trzech funkcji', lecz jako trzy podstawowe komponenty:

Ktoś jest odpowiedzialny za przekształcenie 'stanu semantycznego' w zdolności podstawowej warstwy (odpowiednik myNeutron).

Ktoś jest odpowiedzialny za przekształcenie 'wnioskowania i wyjaśniania' w zdolność do ponownego wykorzystania (odpowiednik Kayon)

Ktoś jest odpowiedzialny za przekształcenie 'inteligencji → akcji' w proces (odpowiednik Flows)

Dodanie 'toru rozliczeniowego/płatności', aby aplikacje były w zamkniętej pętli, to pełne wyjaśnienie 'gotowości AI' w inżynierii.

3) Dlaczego 'nowe wydanie L1' w erze AI jest trudniejsze? Ponieważ deweloperzy nie brakuje łańcuchów, brakuje im 'dojrzałego pośrednika dla inteligentnych agentów'.

W przeszłości nowy łańcuch mógł przyciągnąć deweloperów dzięki 'szybkości i niskim kosztom'. W erze AI ta logika staje się coraz słabsza:

Deweloperzy już mają wystarczająco dużo łańcuchów do wyboru, naprawdę brakuje pośredników i standardowych komponentów, które przyspieszają dostarczanie inteligentnych aplikacji, zapewniają stabilność działania i ułatwiają konserwację.

Jeśli jesteś zespołem gotowym do tworzenia aplikacji związanych z agentami AI, najbardziej obawiasz się nie tego, że 'na łańcuchu nie ma miejsca na wdrożenie', lecz tego, że:

Musisz stworzyć własny system pamięci, samodzielnie opracować wnioskowanie, napisać zabezpieczenia wykonania, samodzielnie podłączyć kanał rozliczeniowy.

Gdy działalność zacznie działać, koszty utrzymania rosną w sposób wykładniczy.

Im bardziej odniesiesz sukces, tym łatwiej system załamie się z powodu niedojrzałości jakiegoś modułu.

Dlatego 'nowe L1 jest trudne', nie oznacza to, że rynek nie potrzebuje nowego łańcucha, lecz że sama nowa infrastruktura łańcucha nie jest już rzadkością; rzadkością są kombinacje inteligentnych komponentów, które można bezpośrednio wykorzystać do produkcji. To również to, co oznacza 'brakujący produkt, który potwierdza gotowość AI' w Talking Points Vanar — przetłumaczyłem to na: brak rzeczy, które pozwalają deweloperom zaoszczędzić sześć miesięcy czasu integracji.

4) Rozpoczęcie z Base w cross-chain: to nie 'dodanie nowego wdrożenia', lecz 'sprawienie, by komponenty mogły być dystrybuowane', umieszczając kompatybilność w większej gęstości deweloperów do weryfikacji.

Jeśli naprawdę robisz 'standardowe komponenty', naturalnie będziesz się interesować dystrybucją: komponenty mogą być używane masowo, aby szybciej się rozwijać i stać się bardziej stabilne, a ostatecznie stać się domyślnym wyborem.

Infrastruktura AI-first, jeśli działa tylko w jednej sieci, ma ograniczone możliwości użycia komponentów, ograniczone opinie deweloperów, a ekosystem może łatwo stać się zamkniętym ogrodem. Vanar zaczyna być dostępny w różnych łańcuchach z poziomu Base, z tego punktu widzenia bardziej przypomina to realny wybór:

Umieść komponenty w miejscach, gdzie deweloperzy są bardziej gęsto skupieni i gdzie aplikacji jest więcej, zwiększając częstotliwość kontaktu i użycia, aby 'kompatybilność' naprawdę osiągnęła skalę.

To wpłynie bezpośrednio na ścieżkę wartości $VANRY : gdy więcej ekosystemów może korzystać z tego samego zestawu inteligentnych komponentów i zdolności rozliczeniowych, obszar użycia się rozszerza, a potencjalne ścieżki gromadzenia wartości stają się jaśniejsze.

5) Dlaczego płatności/rozliczenia są obowiązkowym przedmiotem dla AI-first? Ponieważ bez zamkniętej pętli deweloperzy zawsze pozostaną na poziomie 'przydatne, ale nie generujące wartości'.

Zauważysz, że wiele aplikacji AI 'wydaje się bardzo użytecznych', ale w dłuższej perspektywie nie rozwija się: ponieważ zatrzymują się na poziomie sugestii, poziomie narzędzi, brakuje im zamkniętej pętli, która mogłaby wywołać prawdziwe działania gospodarcze. Dotyczy to szczególnie Web3 - inteligentny agent podejmuje decyzje, ale jeśli nie może płynnie przejść do toru rozliczeniowego, może jedynie działać jako 'wskazówka', trudno mu przekształcić to w 'działanie'.

Vanar Talking Points podkreśla 'inteligentni agenci nie używają UX portfela', to zdanie jest naprawdę kluczowe:

Inteligentny agent potrzebuje zorganizowanego kanału rozliczeniowego, a nie działania jak człowiek, który klika przyciski. Tylko gdy tor rozliczeniowy jest stabilny, deweloperzy będą skłonni przekształcić zastosowania inteligentnych agentów w formy skierowane na przedsiębiorstwa lub rzeczywiste biznesy.

Połącz ten punkt z perspektywą 'kompatybilności': zdolność do rozliczeń nie jest dodatkowym modułem, lecz ostatnią częścią układanki, która musi istnieć w standardowej bibliotece. W przeciwnym razie system, który zbudujesz, zawsze będzie brakował 'wyjścia do realizacji zadania'.

6) $VANRY: bardziej przypomina 'gromadzenie wartości przez deweloperów i wywołania komponentów', a nie krótkoterminowe bilety napędzane emocjami.

Jeśli zgadzasz się z kierunkiem 'standardowe komponenty + dystrybucja', wtedy $VANRY łatwiej zrozumieć w kontekście logiki infrastruktury:

Nie chodzi o obstawianie jakiejś krótkoterminowej mody, lecz o obstawianie na długoterminowe potrzeby użytkowania wynikające z przyjęcia tej warstwy podstawowej inteligentnego agenta przez więcej aplikacji i wywołań z większej liczby ekosystemów.

To również ostatni punkt Talking Points: 'gotowość, nie narracje'. Mówiąc wprost:

Gdy produkt jest faktycznie używany, wartość gromadzi się w bardzo prosty sposób; gdy wartość zależy od narracji, wzrost często jest bardziej kruchy.

W erze AI, ta różnica będzie bardziej wyraźna. Ponieważ przedsiębiorstwa, instytucje oraz zespoły poważnie zajmujące się aplikacjami będą coraz bardziej wrażliwe na 'możliwość dostarczenia'. Kto potrafi obniżyć koszty dostarczenia aplikacji inteligentnego agenta, ten ma większe szanse stać się wyborem infrastruktury w następnej fali.

Podsumowując: zwycięzcami w erze AI są często ci, którzy potrafią 'uprościć złożone zdolności'.

Patrząc na @Vanarchain kluczowe informacje, zauważysz, że nie spieszy się, aby zapakować się jako 'najlepsza opowiadaczka historii w łańcuchu AI'. To bardziej przypomina robienie czegoś, co jest 'wygodne dla deweloperów': przekształcenie pamięci, wnioskowania, automatyzacji i rozliczeń w komponenty, które można łączyć, a następnie rozszerzanie obszaru użycia przez dystrybucję między łańcuchami.

Ta droga nie musi być najgłośniejsza, ale jeśli agenci AI naprawdę staną się ważną formą użytkowników Web3, wartość infrastruktury będzie pochodzić bardziej z 'ciągłej adopcji'. A w dłuższej perspektywie, uproszczenie złożonych zdolności często ma większą wartość niż 'rozszerzanie koncepcji'.

#vanar $VANRY