Andrew Qu, chief of software w Vercel, przez rok przepisywał wewnętrznego agenta do analizy danych. Zaczął od jednego wielkiego promptu, przeszedł przez łańcuch wyspecjalizowanych agentów, potem do jednego agenta zarządzającego własnym stanem. Dopiero czwarta wersja zadziałała, i to nie dzięki sprytnym narzędziom, tylko dzięki zwykłemu systemowi plików z poleceniami listuj, czytaj i bash. Wynik w ewaluacjach się podwoił. Z tych wniosków powstało Eve, framework wydany dwa tygodnie przed tym wystąpieniem. Poniżej cała droga, razem z momentem, w którym pierwsi użytkownicy powiedzieli, że agent jest fatalny.
Agent na każdym biurku
W tysiąc dziewięćset osiemdziesiątym Bill Gates mówił, że wyobraża sobie komputer na każdym biurku i w każdym domu. Wtedy brzmiało to przekornie, dziś to norma. Qu i dyrektor techniczny Vercela zadali sobie analogiczne pytanie: czy da się mieć agenta na każdym biurku?
Dzisiaj agentów używa się głównie do kodowania i zadań technicznych, ale widać już wejście w projektowanie, zarządzanie produktem i inne branże. Qu zaczął eksperyment mniej więcej rok temu, czyli w czasach modelu Sonnet cztery, gdy narzędzia były sporo mniej dojrzałe niż obecnie. Obszedł różne działy w firmie: marketing, sprzedaż, finanse, prawny. Każdemu zadał jedno pytanie: co najbardziej nienawidzicie w swojej pracy?
Wąskie gardło w zespole danych
Najciekawsza odpowiedź przyszła z zespołu danych. Był bardzo mały, a Vercel rósł szybciej niż on. Danych przybywało: od klientów, z analityki, z metryk, ze sprzedaży. Zespół musiał to wszystko bez końca agregować i udostępniać.
Schemat pracy wyglądał tak: ktoś z marketingu albo sprzedaży miał pytanie o klienta lub produkt, więc analityk rzucał wszystko, pisał zapytanie, przetwarzał wynik, robił analizę i wracał z rekomendacją. Zabójcze dla produktywności. Nikt w zespole danych nie chciał odkładać swojej pracy, żeby całymi dniami pisać zapytania. Qu zabrał się z wiceprezesem do spraw danych za zbudowanie czegoś lepszego.
Wersja pierwsza, jeden wielki prompt
Pierwsza próba była najprostsza z możliwych. Pytanie wchodzi do modelu, model odpowiada, koniec.
Qu poprosił zespół o zrzut schematu ze Snowflake, wkleił go do promptu systemowego razem z pytaniem, a wygenerowane zapytanie S Q L kopiował i uruchamiał ręcznie. Chciał sprawdzić jedną rzecz: czy dzisiejsze modele potrafią napisać poprawne S Q L, jeśli dostaną przyzwoitą strukturę.
Wniosek był umiarkowany. Modele nie są aż tak dobre, ale da się poprawić kontekst wokół nich i dołożyć barierki, żeby działały sensowniej.
Wersja druga, łańcuch wyspecjalizowanych agentów
Kolejny krok wyszedł z obserwacji, co analityk faktycznie robi z pytaniem. Musi je przetworzyć. Musi przejrzeć warstwę semantyczną i ustalić wzorce złączeń. Musi wykonać zapytanie. Jeśli zapytanie nie przeszło albo było zbyt kosztowne, wraca i robi to jeszcze raz. Na końcu raportuje: wizualizuje dane, pisze kilka akapitów, czasem robi retrospektywę.
Te fazy zostały odwzorowane jeden do jednego na osobnych agentów. Tak powstała druga wersja agenta danych, nazwana D zero. Pytanie trafia do agenta zapytań, ten przekazuje je do agenta planowania, dalej idzie agent wykonawczy, na końcu raportowanie. Każdy ma własny, wąski prompt systemowy i narzędzia dobrane dokładnie do swojej funkcji. Agent planowania dostaje na przykład tylko narzędzie do czytania plików Y A M L z encjami i narzędzie do przeszukiwania schematów. Używa wyłącznie ich, aż ma odpowiedź do przekazania dalej.
To był postęp. Znikło ręczne kopiowanie zapytań, system domykał pętlę od pytania do odpowiedzi.
Wersja trzecia, jeden agent ze swoim stanem
Architektura łańcucha szybko zaczęła uderzać w ściany. Największy problem: kolejny agent w łańcuchu dostawał tylko streszczenie i krótki wycinek tego, co zrobił poprzedni.
Wniosek był taki, że potrzebny jest jeden agent z całym kontekstem w środku, zarządzający własną pamięcią. Agent musi móc spojrzeć wstecz na to, co zrobił, zastanowić się nad tym i odtworzyć kroki, które doprowadziły go w to miejsce.
Trzecia wersja to więc jedno duże wywołanie modelu, limit rzędu stu kroków i wewnętrzne przełączanie stanu. Raz planuje, raz buduje, raz wykonuje, raz raportuje. Narzędzia podobne, kształt podobny, ale gdy coś wysypało się przy wykonaniu albo złączeniu, agent mógł wrócić, doczytać i sam znaleźć swój błąd.
Rollout, który poszedł źle
Zespół był już pewny systemu, więc dał go wąskiej grupie zaufanych osób. Narzędzie było mocne i nikt nie chciał, żeby trafiło od razu do krytycznych zastosowań.
Odpowiedź przyszła natychmiast: jest fatalny.
Myśleliśmy, że nam idzie. Myśleliśmy, że zaliczamy trzydzieści procent naszych ewaluacji, ale nie byliśmy w stanie przewidzieć części pytań, które ludzie zadawali.
Ręczne mapowanie kolejnych scenariuszy nie wyglądało na coś, co się skaluje.
Odkrycie, czyli system plików
W tym samym czasie pojawił się Opus cztery pięć i w parze z nim Claude Code. Zespół Qu porównał to ze swoim agentem i wniosek był bolesny: w zestawieniu z tym, co mieli wcześniej, to było praktycznie A G I. Claude Code odpowiadał na większość ich pytań bez zająknięcia.
Gdy cofnęli się o krok i spytali, co robią źle, odpowiedź okazała się banalna. To był po prostu system plików. Minimalny zestaw narzędzi: wypisz pliki, przeczytaj plik, uruchom bash.
Kluczowe było to, że agent dostał narzędzia, na których modele są dobrze wytrenowane, i mógł swobodnie eksplorować oraz zapisywać tam, gdzie potrzebuje. Claude Code nie narzucał mu ścisłego zestawu narzędzi. Puszczał go wolno i pozwalał na zachowania wyłaniające się same z siebie.
Przebudowa poszła w tę stronę. Agent działa teraz w piaskownicy. Do piaskownicy zrzucana jest cała warstwa semantyczna. Agent chwyta za bash, czyta pliki, pisze pliki, sam szuka tego, czego potrzebuje. Na wierzch dołożono tylko kilka narzędzi specyficznych dla Vercela.
Implementacja jest prosta: dajesz agentowi narzędzie bash, podpinasz je do piaskownicy i dokładasz pliki do czytania, pisania i wykonywania. Vercel wypuścił do tego pomocniczą paczkę bash tool na n p m.
Efekt: wynik w ewaluacjach się podwoił. Qu napisał o tym wpis na blogu, który w tygodniu publikacji odpowiadał za siedemdziesiąt procent ruchu na stronie Vercela.
Powtarzalne zapytania zamieniane w umiejętności
Po tym agent trafił do całej firmy. Zaczęło wpadać kilka tysięcy zapytań dziennie: metryki klientów, metryki sprzedaży, liczby pobrań z n p m.
Okazało się, że te zapytania mają w większości ten sam kształt. Jest tylko tyle sposobów na zrobienie agregacji, tyle sposobów na wyszukanie produktu, tyle sposobów na sprawdzenie informacji rozliczeniowych.
Powstało więc cykliczne zadanie, które bierze najnowsze zapytania i destyluje je w umiejętności. Dziś jest ich mniej więcej sto, od agregacji po wyszukiwanie konkretnych danych o konkretnych osobach.
Powód, dla którego to działa, jest prosty. Każde nowe uruchomienie agenta startuje od zera. Nie ma żadnego wcześniejszego kontekstu poza warstwą semantyczną i promptem systemowym. Z umiejętnością agent rusza już z porcją wiedzy kontekstowej, która została wypracowana wcześniej. W praktyce wystarczyło dołożyć folder ze skillami. Vercel zbudował też przy okazji narzędzie Skillsh, najpopularniejszy sposób na znajdowanie i uruchamianie umiejętności dla agentów.
Next JS dla agentów
Ta droga, od czegoś prostego przez stopniowe dokładanie złożoności do systemu gotowego na produkcję, jest typowa. Problem w tym, że na każdym jej etapie ktoś w Vercelu odgałęział się od agenta D zero i budował własnego. A za każdym razem istniał już lepszy sposób, o którym ta osoba nie wiedziała.
Stąd pytanie: co, gdyby ludzie mogli startować od ostatniego wniosku, zamiast zaczynać od prostego promptu i wyprowadzać dobre praktyki od zera?
Odpowiedzią było zbudowanie Next JS dla agentów. Next JS to framework webowy Vercela, który wprowadził infrastrukturę definiowaną przez system plików. Nie zastanawiasz się, gdzie co trafia. Piszesz pliki zgodnie z konwencją, a framework sam deklaruje miejsce: strony do C D N, funkcje bezserwerowe tam, gdzie trzeba, cache po środku.
Budowanie agentów miało być równie proste. Tworzysz folder z umiejętnościami, folder z narzędziami, folder z kanałami, a framework wie, jak złożyć z tego agenta.
Tak powstało Eve, wydane dwa tygodnie temu. Zaczynasz od szablonu i dochodzisz do gotowego agenta, do którego dokładasz własną wiedzę, własne narzędzia i integracje z kanałami, których używasz.
Model agenta w Eve wygląda tak: agent ma środowisko uruchomieniowe i kanały. W środowisku masz trwałość, izolowane wykonanie, wywołania różnych modeli i połączenia. Całość powstała z myślą o otwartym kodzie, więc można podpiąć własne adaptery, na przykład do Postgresa, do API odpowiedzi OpenAI, do Dockera. Wdrożenie na Vercelu korzysta z ich własnych klocków: workflows do trwałości, sandbox do bezpiecznego wykonania i Vercel Connect, świeżo wydany sposób na generowanie krótkotrwałych tokenów O D C do połączeń. W zestawie jest obserwowalność: wszystkie uruchomienia agenta, wywołania narzędzi, poszczególne kroki, szacowane koszty i propozycje optymalizacji.
Agent D zero został w trakcie prac nad Eve przepisany w całości na ten framework. Struktura plików jest prosta: instrukcje systemowe, kilka umiejętności, kilka narzędzi.
Efekty i rada na start
Przed pełnym wydaniem Eve trafiło do kilku klientów w wersji beta. Firma Aura przebudowała na nim swojego agenta, coś w rodzaju mini Claude Code, który wchodzi na strony, instaluje usługi i próbuje ich używać, żeby je przetestować. W porównaniu z gotowym Claude Code agent zbudowany od zera w Eve dał mniej kroków, więcej sukcesów i lepsze wnioski.
Główna teza Qu dotyczy jednak czegoś innego: warto budować wąskich agentów pod konkretny biznes. Przed budową D zero zespół przetestował sporo dobrze finansowanych startupów robiących agentów wertykalnych, podpinanych do instancji Snowflake, żeby odpytywały ją za ciebie.
Odkryliśmy, że tym, co naprawdę robi z tego dobrego agenta, jest bardzo konkretna wiedza firmowa.
Vercel jest firmą webową. Ma klientów ze stronami i serwisami. To wchodzi znacznie głębiej w to, kiedy o co pytać i co się z czym łączy. Gotowe rozwiązania są w porządku i warto je wypróbować, ale najwięcej wyciśniesz z własnego agenta nasyconego wiedzą o twojej firmie.
Dziś w Vercelu działa około dwudziestu agentów z sensownym dopasowaniem do potrzeb. Robią retrospektywy marketingowe, ustalają, do kogo się odezwać, nanoszą pierwszą wersję poprawek na kontrakt, gdy dział prawny dostaje nowe negocjacje, no i odpowiadają na pytania o dane.
Zespół danych nigdy nie był bardziej produktywny. Ma czas na poprawianie wydajności Snowflake, dokładanie brakujących źródeł danych i zapełnianie luk, na które wcześniej nie starczało czasu, bo wszystko szło na pisanie zapytań. Sporą część pracy w dziale kadr, finansach i sprzedaży da się dziś w podobny sposób odjąć ludziom z biurka.
Koniec artykułu.