O czym jest ten film
- Vercel wydał nowy open-source’owy framework do budowy agentów AI o nazwie Eve.
- Kluczowa idea: agent to po prostu folder — zbiór plików Markdown i TypeScript, gdzie każdy prymityw (skille, narzędzia, kanały, sub-agenci, harmonogramy) ma swój podfolder.
- Najważniejszym elementem jest krok kompilacji: Eve sam przechodzi przez folder i łączy wszystko w jeden manifest — nie trzeba niczego ręcznie importować.
- W przeciwieństwie do dotychczasowych agentów plikowych (osobiste „drugie mózgi”), Eve nadaje się do wdrożeń produkcyjnych obsługujących tysiące czy miliony użytkowników.
- Produkcyjna niezawodność opiera się na infrastrukturze Vercela: trwałe sesje z checkpointami, izolowany sandbox do wykonywania kodu, człowiek w pętli (human-in-the-loop) oraz evale jako bramka wdrożeniowa.
- Vercel dostarcza plugin do agentów kodujących (Claude Code, Cursor), który zawiera skille i serwer MCP — jedna komenda instaluje cały zestaw.
- Dzięki pluginowi agent kodujący zna strukturę Eve i potrafi zbudować oraz wdrożyć pełnego agenta bez znajomości frameworka na wylot.
- Autor pokazuje demo „Eve analyst agent” — agenta analitycznego rozmawiającego z bazą danych, z skillem od pytań o przychody i sub-agentem-śledczym.
- Wdrożenie sprowadza się do polecenia „Deploy this Eve agent”; integracja ze Slackiem daje pamięć krótkoterminową w wątku, równoległe rozmowy i przyciski zatwierdzania ryzykownych akcji.
- Autor pozycjonuje Eve jako standard struktury agenta, komplementarny do OKF jako standardu baz wiedzy — i zaznacza, że współpracował przy filmie z Vercelem.
Redakcyjne tłumaczenie
Nowy framework: agent jako system plików
Vercel właśnie wydał nowy, open-source’owy framework do budowy agentów AI o nazwie Eve — i naprawdę warto mu się przyjrzeć. Twórcy nazywają go frameworkiem „file system first”, czyli takim, w którym punktem wyjścia jest system plików. To dla mnie fascynujące, bo czegoś takiego wcześniej nie widziałem.
Tradycyjnie, kiedy budujesz agenta AI mocniej opartego na systemie plików, robisz to raczej z myślą o agencie osobistym albo o „drugim mózgu”. To nie jest zwykle taki agent, którego wdrażasz na produkcję, żeby korzystały z niego tysiące czy miliony użytkowników — twoi klienci. Ale Eve to umożliwia. Dostajesz łatwość i elastyczność agentów opartych na plikach, a jednocześnie masz solidny fundament niezawodności klasy produkcyjnej, gdy przychodzi czas na wdrożenie. A tego zwykle nie masz, kiedy twój agent wygląda mniej więcej tak, jak to, co za chwilę pokażę.
Jeśli budowałeś już wcześniej agentów osobistych, znasz tę strukturę: cały twój agent AI to tak naprawdę zbiór plików w jednym folderze. I to jest właśnie idea Eve — twój agent AI to po prostu folder. To sprawia, że budowanie go jest tak proste, a wszystko staje się kompozycyjne.
Prymitywy agenta jako podfoldery
Wewnątrz folderu masz swoje instrukcje — czyli system prompt i globalne reguły. Masz definicję agenta, w której określasz model, którego chcesz użyć. Masz skille — wszystkie zdolności, które chcesz dać agentowi. Masz narzędzia (tools). Masz sandbox do niezawodnego wykonywania kodu. Masz kanały (channels), dzięki którym podłączysz agenta do czegoś takiego jak Slack czy Discord. Masz połączenia (connections), które obejmują twoje serwery MCP. Masz sub-agentów. I masz też harmonogramy (schedules), dzięki którym możesz uruchamiać agenta cyklicznie, żeby robił coś autonomicznie.
Praktycznie wszystkie podstawowe prymitywy, które dziś widzimy w agentach, definiujesz każdy w osobnym folderze, a potem masz główny folder nadrzędny, który spina wszystko razem. To właśnie czyni całość tak kompozycyjną i łatwą do zbudowania.
Dlaczego to zwróciło moją uwagę
Największym powodem, dla którego to mnie w ogóle zainteresowało, jest to, że widzę mnóstwo organizacji budujących coś takiego dla siebie, wewnętrznie. Mają własną strukturę: agenta na najwyższym poziomie, a potem swój sposób definiowania modelu, pakowania skilli i wciągania system promptu. Eve daje nam tutaj standard — sposób zdefiniowania tego w możliwie najprostszej formie.
Do tego Eve bierze na siebie sporo „hydrauliki” pod maską. Rzeczy, o których nawet byś nie pomyślał, że musisz się nimi zająć, ale przy budowaniu tego rodzaju agenta w architekturze folderowej dużo musi się wydarzyć, żeby agent był faktycznie podpięty pod skille, hooki i wszystko inne, co zdefiniowałeś.
Krok kompilacji — najbardziej imponująca część
I to właśnie ten krok kompilacji jest najbardziej imponujący w Eve. Kiedy tworzysz swoje skille, sub-agentów i całą resztę w folderach, nie musisz niczego samodzielnie importować ani łączyć. Patrząc na główny plik TypeScript agenta — pokażę przykład za chwilę — nie ma tam nic, co musiałoby importować albo jawnie wskazywać konkretne rzeczy z pozostałych folderów. Tym właśnie jest krok kompilacji.
Kiedy uruchamiasz agenta i kiedy go wdrażasz, Eve zajmuje się przejściem przez twój jeden folder, znajduje wszystkie skille, serwery MCP i podobne rzeczy, a następnie tworzy jeden manifest, w którym wszystko jest ze sobą połączone. Na wyjściu masz więc skompilowanego agenta, który obsługuje wszystkie połączenia, tak żeby budowanie było dla ciebie maksymalnie proste.
To bardzo podobne do tego, jak działają prymitywy w rodzaju skilli w agentach kodujących, np. w Claude Code. W Claude Code wystarczy, że wrzucisz plik skill.md do folderu w skillach, a Claude Code „magicznie” go rozumie i możesz go wywołać komendą slash. Tutaj działa to tak samo — ale Eve idzie znacznie dalej niż agenci kodujący, jeśli chodzi o wdrożenia produkcyjne i niezawodność.
Niezawodność klasy produkcyjnej dzięki infrastrukturze Vercela
To właśnie sprawia, że agenci Eve mogą skalować się aż do produkcji i być wystarczająco niezawodni — bo opieramy się na sporej części infrastruktury, którą daje Vercel. Vercel zawsze był jedną z moich ulubionych platform do wdrażania rzeczy. I ma sens, że promują tutaj Vercela — sami stworzyli ten open-source’owy framework, więc uczciwie: chcą, żebyś wdrażał również na Vercelu.
Po pierwsze, mamy trwałe sesje (durable sessions). Każda sesja to workflow z checkpointami, który przetrwa awarie i ponowne wdrożenia. Pod maską każda tura i każde wywołanie narzędzia są zapisywane, więc kiedy dojdzie do jakiegokolwiek załamania, możesz naturalnie wznowić pracę od tego punktu.
Oferują też izolowany sandbox do wykonywania kodu. Twój agent może pisać i wykonywać kod, ale robi to w bezpieczny sposób.
Mamy też człowieka w pętli (human-in-the-loop) — zatrzymanie na ryzykownych krokach w celu uzyskania zatwierdzenia. Dzięki temu agent może robić realne rzeczy, ale bez ryzyka, że wymknie się spod kontroli.
Mają też evale jako bramkę wdrożeniową. Evale to kolejna rzecz, dla której możesz mieć po prostu osobny folder w agencie. Możesz testować określone zachowania agenta i upewnić się, że dostajesz zielone „ptaszki” na całej linii, zanim wdrożysz aktualizację agenta na produkcję.
No i oczywiście Vercel może obsłużyć całą infrastrukturę hostingu twojego agenta, skalując go do tysięcy czy milionów użytkowników. Nie musisz więc martwić się podpinaniem pod jakąś inną infrastrukturę ani hostowaniem na własnej maszynie.
Wreszcie mamy bardzo łatwe połączenia z innymi platformami — z własnym UI przez API czy z czymś takim jak Slack.
Dlaczego kibicuję standardom
Zanim przejdę do agenta, którego chcę zademonstrować, chcę powiedzieć jedną rzecz. Absolutnie uwielbiam standard, który Eve nam tu daje dla agentów opartych na systemie plików — strukturę agenta i sposób jego kompilacji.
Jeśli śledziłeś moje treści, wiesz, że jestem wielkim fanem standardów, takich jak MCP, A2A czy OKF — wszystkich tych trzyliterowych akronimów.
(Informacja dodatkowa: MCP — Model Context Protocol, standard łączenia modeli z zewnętrznymi narzędziami i danymi. A2A — Agent-to-Agent, standard komunikacji między agentami. OKF — standard struktury baz wiedzy podłączanych do agentów.)
To standardy popychają branżę do przodu. Bo kiedy wszyscy mają to samo podejście, możemy uczyć się od siebie nawzajem i budować na sobie nawzajem. To właśnie napędza rozwój, zwłaszcza w open-source’owym AI. A to, że Eve jest open-source, sprawia, że wpisuje się dokładnie w moje przekonania.
To, co zawsze mówię przy tych standardach: nie wiem, czy Eve stanie się w przyszłości standardem dla agentów opartych na systemie plików, ale tworzy tu precedens. I jakkolwiek ten standard ostatecznie będzie wyglądał, będzie to coś w tym rodzaju. Można wręcz myśleć o tym tak, że Eve to standard tego, jak strukturyzujemy agenta, a OKF to standard tego, jak strukturyzujemy bazy wiedzy, które do tych agentów podpinamy. Widzę tu więc naprawdę fajne połączenie: Eve plus OKF.
Jedną rzecz chcę postawić jasno: kiedy mówię, że Eve potrafi skalować agentów opartych na plikach do produkcji, nie mówię o skalowaniu baz wiedzy w Markdownie — takich „wiki dla LLM-ów”. Mówiłem już wcześniej, że one niekoniecznie się skalują, zwłaszcza gdy dojdziesz do dziesiątek tysięcy dokumentów. Baza wiedzy to osobna sprawa. Tu chodzi wyłącznie o skalowanie podstawowych prymitywów agenta — agenta połączonego z rzeczami takimi jak skille i serwery MCP.
Jak się buduje agentów Eve
Pytanie, które w tym momencie możesz mieć, brzmi: jak właściwie budować agentów Eve? Na szczęście jest to tak proste, jak tylko się da, bo Vercel dostarcza plugin, który wnosisz do swoich agentów kodujących — takich jak Claude Code — żeby zarówno budowanie, jak i wdrażanie tych agentów było niesamowicie łatwe.
Mamy więc plugin Vercela. Użyłem go do zbudowania całego agenta, którego za chwilę pokażę. Widać, że mamy tu podpięty Vercel MCP do wdrażania, więc łatwo wprowadzić agenta na produkcję. A kiedy wpiszę /skills, widać, że w ramach pluginu mamy też wszystkie te skille Vercela, w tym Vercel Eve. Dzięki temu skillowi agent kodujący, taki jak Claude Code, dokładnie zna strukturę naszego agenta: jak budujemy kanały, jak włączamy skille, jak tworzymy harmonogramy i środowisko sandbox. Nie musisz więc być mistrzem Eve i całej tej struktury, żeby budować w pełni gotowe na produkcję agenty.
Podlinkuję w opisie artykuł z instrukcją instalacji pluginu — dokładną komendą do skopiowania i wklejenia. To pojedyncze polecenie, które uruchamiasz w agencie kodującym w rodzaju Claude Code czy Cursor, żeby wciągnąć cały zestaw skilli i serwer MCP dostarczany z pluginem.
Demo: Eve analyst agent
Drugą rzeczą, którą podlinkuję w opisie, jest agent Eve analyst. To demo, które chcę teraz pokazać, żeby wszystko było konkretne. Zbudowałem pełnego agenta wykorzystującego wszystkie różne możliwości Eve i chcę cię przez niego przeprowadzić na wysokim poziomie, a nawet pokazać, jak wygląda wdrożenie i rozmowa z agentem w Slacku.
Oto mój sklonowany egzemplarz agenta Eve analyst. Wszystko tutaj zbudowałem Claude Code’em z pluginem. Twój agent zaczyna się od prostego pliku agent.ts. Wewnątrz folderu agenta to jest wszystko, co mam — sam zbiór Markdowna i TypeScriptu. I bez obaw: cały TypeScript jest naprawdę prosty. Definiując agenta, musimy w zasadzie tylko podać model, a w zmiennych środowiskowych ustawilibyśmy klucz API Anthropic — z czym również przeprowadzi cię twój agent kodujący.
Kiedy masz już agent.ts, cała reszta jest opcjonalna. Oczywiście, żeby zrobić naprawdę użytecznego agenta, musimy dodać inne rzeczy — skille, narzędzia — ale już teraz moglibyśmy uruchomić tego agenta od ręki. Żeby go uruchomić, wystarczy komenda eve. Możesz też kazać agentowi kodującemu uruchomić to i przetestować samego agenta, sprawdzając własną pracę. I proszę — agent działa lokalnie. Mogę powiedzieć „cześć”; podpiąłem to pod Claude Sonnet 5 przez API Anthropic, i odpowiedzi są nam streamowane na bieżąco.
Dodawanie zdolności: skille, kanały, sub-agenci, narzędzia
Dodawanie kolejnych zdolności nie jest dużo trudniejsze. Spójrzmy na skille. Mamy skill dotyczący reguł przychodowych (revenue rule). Ma on opis — tak jak opis, który dajesz agentowi kodującemu na początku rozmowy — mówiący, czym jest ta zdolność: „załaduj to przed odpowiedzią na jakiekolwiek pytania o przychody, sprzedaż lub wzrost”. Na potrzeby demo wszystko, co zbudowałem, jest proste: mamy kilka reguł, które poprawiają wynik i sprawiają, że odpowiedzi agenta na takie pytania są powtarzalne.
Mamy kanały — to jest Eve, więc możemy rozmawiać z nim lokalnie, jak przed chwilą. Mamy kanał Slacka, i znów: agent kodujący pomoże ci skonfigurować dane uwierzytelniające. Mamy sub-agenta — śledczego (investigator). Kiedy pojawia się pytanie w stylu „dlaczego ta metryka się zmieniła”, które pochłonie więcej tokenów, chcemy przekazać je do workera — i mamy do tego sub-agenta. Mamy też nasz główny system prompt („jesteś Eve analyst, uważnym analitykiem danych” itd.) w pliku instructions.md.
Nie muszę przechodzić przez wszystko — sandboxing, evale — ale sedno jest takie, że to po prostu zbiór Markdowna i TypeScriptu, więc jest niesamowicie prosto.
Żeby przetestować to lokalnie, wracamy do terminala, uruchamiamy komendę eve i mogę zadawać pytania korzystające z wbudowanych zdolności. I podkreślam: te zdolności po prostu wrzucam — skill do folderu skilli, sub-agenta do folderu sub-agentów. Nie muszę robić żadnego połączenia z agent.ts. Przez cały czas dodawania tych zdolności do tego głównego pliku — swego rodzaju punktu wejścia do agenta — nie muszę dobudowywać nic więcej. To zupełnie inaczej niż w innych frameworkach agentowych.
Zobaczmy to w akcji. Wklejam pytanie: „Jakie tabele są w hurtowni danych i ile wierszy ma każda z nich?”. To nie wymaga sub-agenta ani skilla, ale skorzysta z narzędzi, które daliśmy agentowi do interakcji z bazą danych. To proste pytanie, więc jedno wywołanie narzędzia — wypisało tabele, szybko, dokładnie ta informacja, której potrzebowaliśmy.
Każde z tych narzędzi to po prostu prosty plik TypeScript. To narzędzie, które właśnie uruchomiliśmy do wypisania zawartości tabeli, to zaledwie jedna operacja na bazie danych. Używamy tu Zoda do typowania, żeby dane, które agent podaje funkcji, były niezawodne pod kątem tego, czego naprawdę potrzebuje. Uwielbiam, jak to jest proste. I znów — żadnego podpinania do agenta. Definiujemy narzędzie jako funkcję w folderze narzędzi i ładuje się ono automatycznie przy kompilacji agenta komendą eve albo komendą wdrożenia.
Zadam kolejne pytanie — to skorzysta z naszego skilla, bo pytamy o przychody. I rzeczywiście: ładuje skill, instrukcje, jak chcemy otrzymać odpowiedź, po czym wykonuje wywołania narzędzi, żeby zdobyć dane, uruchamia trochę SQL-a i za chwilę dostajemy odpowiedź. Zajmuje to chwilę, bo trzeba przetworzyć sporo informacji, ale mamy końcową liczbę, podaną dokładnie w formacie, który określiliśmy w skillu.
Wdrożenie i praca w Slacku
Zbudowałem dość prostego agenta na potrzeby demo, ale załóżmy, że jesteśmy zadowoleni ze zdolności, które podpięliśmy, i chcemy go wdrożyć. Dzięki pluginowi Vercela wystarczy powiedzieć agentowi: „Wdróż tego agenta Eve”. I tyle. Reszta dzieje się przy użyciu serwera MCP.
A skoro to się wykonuje — otworzę nową instancję Claude Code, bo chcę pokazać, jak łatwo zbudować agenta od zera. Dokładnie to zrobiłem, żeby zbudować to demo. Spójrz na ten prompt: powiedziałem po prostu „Scaffolduj nowego agenta Eve o nazwie hello agent”. Dajesz mu nazwę, mówisz, żeby użył Eve — więc wie, że ma sięgnąć po skill — i to wszystko. Możesz też opisać sub-agentów czy skille, które chcesz, żeby zbudował; agent w pełni to rozumie i wszystko utworzy. Nie przesadzam, mówiąc, że prościej się nie da.
Wracając do agenta kodującego: wdrożenie jest gotowe, a agent nawet uruchomił test dymny (smoke test), żeby upewnić się, że wszystko gra. Na tym etapie mógłbyś też uruchomić evale, po prostu każąc agentowi odpalić zestaw evali — to kolejna rzecz w skillu, którą potrafi wykorzystać. I jeśli masz skonfigurowane dane uwierzytelniające dla platformy w rodzaju Slacka, możesz od razu zacząć rozmawiać z agentem. A jeśli została jeszcze jakaś konfiguracja do dokończenia, po prostu poproś agenta, żeby cię przez nią przeprowadził.
Pokażę, jak wygląda rozmowa z agentem w Slacku. Powiem uczciwie: żeby utworzyć aplikację Slacka i wszystko podpiąć, jest sporo kroków. Mój Claude Code przeprowadził mnie przez to, ale trochę rzeczy trzeba zrobić ręcznie. Kiedy już masz to skonfigurowane, robisz @eveanalyst i mówisz na przykład „cześć”. Od razu widzisz, że agent Eve „myśli”, a po chwili pojawia się odpowiedź w wątku.
Możemy też kontynuować rozmowę — mogę zapytać: „Eve analyst, co przed chwilą powiedziałem?”, żeby udowodnić, że mamy pamięć krótkoterminową w obrębie wątku. I możemy prowadzić wiele rozmów równolegle, bo mamy wszystko wyskalowane na Vercelu — tysiące osób może wchodzić w interakcję z tym agentem jednocześnie.
Człowiek w pętli w praktyce
Pokażę jeszcze jedną rzecz — człowieka w pętli. To trochę sztuczny prompt, bo jawnie każę agentowi wykonać zapytanie SQL — nigdy naprawdę nie rozmawia się z agentem w ten sposób. Chcę jednak wywołać zatwierdzanie przez człowieka: proszę o operację uznawaną za ryzykowną, bo robimy coś, co mogłoby być ogromnym SELECT-em. Wchodzę w to i muszę zatwierdzić albo odrzucić. Mamy więc integrację bezpośrednio w Slacku — z przyciskami. Klikam „zezwól”, agent wykonuje zapytanie i podaje ostateczną odpowiedź. Gotowe, w kilka sekund.
To jedna z najważniejszych rzeczy dla niezawodności przy wprowadzaniu agenta na produkcję — zwłaszcza jeśli korzysta z niego wewnętrzny zespół na platformie takiej jak Slack. Musisz mieć te zatwierdzenia przez człowieka dla tego rodzaju akcji. Oczywiście moglibyśmy po prostu sprawić, żeby agent w ogóle nie mógł robić takich rzeczy, ale wtedy byłby po prostu mniej użyteczny. Dobra równowaga to dać mu więcej mocy, ale sprawić, że pewne rzeczy musisz zatwierdzić. I Eve czyni konfigurację tego bardzo łatwą.
Podsumowanie
To wszystko, co miałem do powiedzenia o Eve — nowym frameworku i standardzie dla agentów opartych na systemie plików. Mam nadzieję, że uznasz to za interesujące, choćby po to, żeby pomyśleć, jak przesuwamy standard budowania agentów AI. Dochodzimy do momentu, w którym mamy pojedynczy folder będący po prostu zbiorem uporządkowanego Markdowna i TypeScriptu. Uwielbiam to. Gdybyś powiedział mi jeszcze pół roku temu, że agenci do tego zmierzają, uznałbym cię za szaleńca. A jednak jesteśmy tu, i to mnie cieszy, bo nie tracimy żadnej mocy agentów klasy produkcyjnej, a dużo prościej jest teraz to osiągnąć.
Chcę też powiedzieć, że współpracowałem przy tym filmie z Vercelem, żeby upewnić się, że wszystko przedstawiam dobrze. Dziękuję im za tę współpracę. Sam się do nich zgłosiłem, bo naprawdę uważam ten framework za znakomity.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Agent jako folder — jeden standard zamiast wewnętrznych wynalazków
Na czym polega: Eve traktuje agenta jako pojedynczy folder z podfolderami na każdy prymityw (instrukcje, definicja agenta, skille, narzędzia, sandbox, kanały, połączenia MCP, sub-agenci, harmonogramy, evale). Wszystko to Markdown i TypeScript.
Jak stosować: Jeśli twoja organizacja dorobiła się własnej, autorskiej struktury agentów, rozważ Eve jako gotowy standard — oszczędzasz utrzymywanie własnej „hydrauliki” i ułatwiasz onboarding nowych osób.
Na co uważać: To nadal świeży framework Vercela, nie ustalony standard branżowy. Autor sam zaznacza, że nie wie, czy Eve „wygra” — zakładaj możliwość migracji i nie buduj wokół niego niczego, czego nie dałoby się przenieść.
2.Krok kompilacji zastępuje ręczne łączenie komponentów
Na czym polega: Nie importujesz ani nie rejestrujesz skilli, narzędzi czy sub-agentów w pliku agenta. Przy uruchomieniu (eve) lub wdrożeniu Eve przechodzi przez folder i buduje jeden manifest łączący wszystko.
Jak stosować: Nowe zdolności dodajesz przez samo wrzucenie pliku do właściwego folderu — trzymaj się konwencji nazewnictwa i struktury, którą framework rozpoznaje (analogicznie do skill.md w Claude Code).
Na co uważać: „Magiczne” ładowanie oznacza mniej jawnych zależności — łatwiej o niezamierzone załadowanie skilla albo konflikt. Warto testować, co faktycznie znalazło się w skompilowanym manifeście, zamiast zakładać.
3.Produkcyjna niezawodność wynika z infrastruktury Vercela, nie z samych plików
Na czym polega: Trwałe sesje z checkpointami (przetrwają awarie i redeploy), izolowany sandbox kodu, człowiek w pętli i evale jako bramka wdrożeniowa to elementy dające skalę do tysięcy/milionów użytkowników.
Jak stosować: Traktuj Eve jako drogę do produkcyjnego agenta, nie tylko do osobistego „drugiego mózgu” — zaplanuj wdrożenie na Vercelu, żeby korzystać z tych mechanizmów.
Na co uważać: Te gwarancje są mocno związane z platformą Vercela. Poza jego infrastrukturą (self-hosting, inna chmura) możesz nie dostać trwałych sesji ani skalowania „za darmo” — to realny vendor lock-in.
4.Człowiek w pętli to klucz do bezpiecznego, a jednocześnie użytecznego agenta
Na czym polega: Agent zatrzymuje się na ryzykownych krokach (np. potencjalnie ogromny SELECT) i czeka na zatwierdzenie — w Slacku pojawiają się przyciski „zezwól/odrzuć”.
Jak stosować: Zamiast całkowicie odbierać agentowi ryzykowne akcje (co czyni go mniej użytecznym), daj mu więcej mocy, ale wymuś zatwierdzenie wybranych operacji — szczególnie dla agentów wewnętrznych w Slacku.
Na co uważać: Musisz świadomie zdefiniować, co jest „ryzykowne”. Zła klasyfikacja = albo zalew próśb o zgodę (zmęczenie zatwierdzaniem), albo przepuszczenie groźnej operacji bez kontroli.
5.Plugin Vercela sprawia, że agent kodujący buduje agentów Eve za ciebie
Na czym polega: Jedna komenda instaluje w Claude Code czy Cursorze zestaw skilli (w tym Vercel Eve) oraz serwer MCP do wdrażania. Agent kodujący zna wtedy strukturę Eve i potrafi scaffoldować, testować i wdrażać.
Jak stosować: Zacznij od zainstalowania pluginu i buduj przez polecenia w stylu „Scaffolduj nowego agenta Eve o nazwie X, użyj Eve, dodaj sub-agenta Y i skill Z”. Wdrażaj przez „Deploy this Eve agent”.
Na co uważać: Delegowanie budowy i wdrożenia agentowi kodującemu to wygoda kosztem kontroli — przeglądaj wygenerowany kod i konfigurację, zwłaszcza uprawnienia, dane uwierzytelniające i to, co trafia na produkcję.
6.Narzędzia to zwykłe funkcje TypeScript z typowaniem przez Zod
Na czym polega: Każde narzędzie to prosty plik TS z jedną operacją (np. zapytanie do bazy), a Zod wymusza niezawodne typy wejścia, które agent przekazuje funkcji.
Jak stosować: Definiuj narzędzia wąsko i jednozadaniowo, opisuj wejścia schematem Zod — to redukuje błędne wywołania i zwiększa przewidywalność. Nie musisz nic podpinać ręcznie; ładują się przy kompilacji.
Na co uważać: Prostota kusi do dawania agentowi surowego dostępu do bazy. Waliduj i ograniczaj zakres operacji (i łącz z zatwierdzaniem przez człowieka), żeby narzędzie nie stało się furtką do niebezpiecznych zapytań.
7.Sub-agenci do zadań token-ochłonnych
Na czym polega: Cięższe, otwarte pytania („dlaczego ta metryka się zmieniła”) są delegowane do wyspecjalizowanego sub-agenta (workera), np. „investigatora”, zamiast obciążać głównego agenta.
Jak stosować: Wydzielaj kosztowne, eksploracyjne zadania do sub-agentów — to porządkuje przepływ i pozwala kontrolować zużycie tokenów. Sub-agenta dodajesz przez wrzucenie do folderu sub-agentów.
Na co uważać: Każdy sub-agent to dodatkowe wywołania i koszt. Deleguj świadomie — bezmyślne mnożenie sub-agentów podnosi rachunek i opóźnienia bez realnej korzyści.
8.Skille narzucają powtarzalny format odpowiedzi
Na czym polega: Skill (np. „revenue rule”) ma opis mówiący, kiedy go załadować, i reguły kształtujące wynik — dzięki temu odpowiedzi na dany typ pytań są spójne i powtarzalne.
Jak stosować: Koduj w skillach reguły biznesowe i wymagany format wyjścia (np. jak prezentować dane o przychodach), zamiast liczyć na to, że model za każdym razem „zgadnie” tak samo. Pisz precyzyjne opisy wyzwalające załadowanie.
Na co uważać: Skill ładuje się na podstawie opisu — zbyt ogólny opis powoduje ładowanie nie tam, gdzie trzeba (albo brak załadowania). Testuj trafność wyzwalania na realnych pytaniach.
9.Evale jako bramka przed wdrożeniem
Na czym polega: Evale to osobny folder w agencie; testują wybrane zachowania i muszą przejść („zielone ptaszki”), zanim aktualizacja trafi na produkcję. Można je uruchomić poleceniem do agenta kodującego.
Jak stosować: Zdefiniuj eval-e dla krytycznych zachowań agenta i traktuj je jak bramkę CI — nie wdrażaj zmiany bez ich przejścia. Uruchamiaj też smoke testy po wdrożeniu.
Na co uważać: Evale są tak dobre, jak przypadki, które w nich ujmiesz. Zielone ptaszki na wąskim zestawie dają fałszywe poczucie bezpieczeństwa — rozbudowuj pokrycie o realne, trudne scenariusze.
10.Eve to standard agenta, nie baz wiedzy — nie myl skali
Na czym polega: Autor jasno oddziela skalowanie prymitywów agenta (skille, MCP) od skalowania baz wiedzy w Markdownie. Te drugie („wiki dla LLM-ów”) nie skalują się dobrze przy dziesiątkach tysięcy dokumentów — do tego służy osobny standard, OKF.
Jak stosować: Używaj Eve do struktury i wdrożenia agenta, a dużą bazę wiedzy trzymaj i skaluj osobno (np. wg OKF), podpinając ją do agenta — a nie wrzucając tysiące plików Markdown do folderu agenta.
Na co uważać: Nie traktuj „file system first” jako zaproszenia do trzymania całej wiedzy w plikach agenta. Przy dużej skali dokumentów to droga do problemów z wydajnością i jakością odpowiedzi.