Często mówiliśmy o frameworkach agentowych. LangGraph, CrewAI, AutoGen, różne SDK, pętla, wywoływanie narzędzi, pamięć, planista, krytyk, przełożony. Wszystkie przydatne słowa, na litość boską. Ale im więcej patrzę na faktycznie używane agenty, tym bardziej wydaje mi się, że interesująca część przeniosła się poniżej poziomu frameworka.

Pytanie nie brzmi już tylko: jakiej biblioteki użyć, aby model krokowy zaczął myśleć?

Prawdziwe pytanie brzmi: gdzie będzie mieszkał ten agent, kiedy przestanie być demo?

Ponieważ poważny agent nie jest funkcją wywołującą model i zwracającą tekst. To mały system rozproszony. Musi czytać kontekst, używać narzędzi, wykonywać kod, dotykać plików, zapamiętywać decyzje, pytać o pozwolenie, kończyć się niepowodzeniem, uruchamiać się ponownie, zostawiać logi, nie spalać budżetu i nie zamieniać się w buldożer w repozytorium produkcyjnym.

Podstawą jest kierownica. Infrastruktura to droga, hamulce, garaż, ubezpieczenie i osoba, która wie, gdzie są klucze.

Ponieważ teraz dużo się o tym mówi

W latach 2023 i 2024 rozmowa skupiała się głównie na modelach. Które LLM? Ile kontekstu? Ile to kosztuje? Jak dobry jest w programowaniu?

W latach 2025 i 2026 rozmowa uległa zmianie. Modele są wystarczająco dobre, aby wykonać prawdziwą pracę, ale dlatego widoczne są nudne elementy: środowisko wykonawcze, bezpieczeństwo, łączniki, tożsamość, obserwowalność, wykonanie kodu, wdrożenie, wycofywanie zmian.

To naturalne przejście od magii do inżynierii.

Gdy agent potrzebuje tylko wygenerować odpowiedź, wystarczy czat. Kiedy musisz otworzyć żądanie ściągnięcia, wysłać zapytanie do bazy danych, wywołać CRM, rozpocząć zadanie, nawigować po witrynie, przeczytać Slack, skompilować kod i zaktualizować dokument, potrzebujesz wokół tego systemu operacyjnego.

Nie w sensie dosłownym. W sensie organizacyjnym.

Pierwszy element: środowisko wykonawcze, w którym agent może przetrwać

Agent często działa etapami. Przyjrzyj się stanowi, wybierz działanie, użyj narzędzia, obserwuj wynik, zaktualizuj plan, powtórz.

Jeśli ta pętla znajduje się w pojedynczym żądaniu HTTP, od razu pojawia się problem. Niektóre działania są powolne. Niektóre czekają na wkład człowieka. Niektóre kończą się niepowodzeniem i należy spróbować ponownie. Niektóre muszą przetrwać wdrożenie lub przekroczenie limitu czasu.

To tutaj wchodzą w grę trwałe przepływy pracy, kolejki, tła zadań i maszyny stanowe. Nie są olśniewający, ale stanowią różnicę między agentem, który na wersji demonstracyjnej wydaje się mądry, a agentem, którego możesz zostawić w pracy i iść na kawę.

Dla mnie środowisko wykonawcze agenta musi odpowiadać na bardzo konkretne pytania:

• gdzie zapisać stan pomiędzy jednym krokiem a drugim?
• co się stanie, jeśli proces umrze w połowie?
• czy mogę zrobić pauzę i poprosić o zgodę?
• czy mogę odtworzyć przebieg, aby zrozumieć, dlaczego dokonał takiego wyboru?
• czy mogę ograniczyć czas trwania, pamięć, narzędzia i koszt?

Vercel mocno naciska na ten front, oferując pakiety SDK AI, funkcje, przepływy pracy i narzędzia do tworzenia agentów w aplikacjach internetowych. Ale nie chodzi tylko o Vercel. Chodzi o to, że agent potrzebuje działającego domu, a nie pojedynczego punktu końcowego.

Drugi element: piaskownica, ponieważ agent musi mieć możliwość ubrudzenia się bez zniszczenia

Gdy tylko agent napisze kod lub wykona polecenia, potrzebna jest piaskownica.

Wydaje się, że to techniczne słowo, ale pomysł jest domowy: dajesz mu stół warsztatowy. Może otwierać pliki, instalować zależności, uruchamiać testy, przeprowadzać eksperymenty i generować dane wyjściowe. Jeśli się myli, powstrzymałeś szkody. Jeśli to zadziała, promuj wynik.

Agentyczna piaskownica powinna mieć pewne właściwości:

• izolowany system plików;
• Ograniczenia procesora, pamięci i czasu;
• sieć kontrolowana;
• sekrety montowane tylko w razie potrzeby;
• complete logs;
• możliwość eksportu artefaktów;
• w razie potrzeby czysty reset pomiędzy uruchomieniami.

Vercel Sandbox idzie dokładnie w tym kierunku: izolowane środowiska do uruchamiania kodu, instalowania zależności, pracy z plikami i tworzenia artefaktów bez uruchamiania wszystkiego w głównym środowisku wykonawczym aplikacji.

Ta sprawa jest ważniejsza, niż się wydaje. Wiele agentycznych prototypów przeskakuje bezpośrednio z modelu do rzeczywistego systemu. Model może wywołać narzędzie. Narzędzia mogą wiele. Wszystko wydaje się eleganckie, aż do pierwszego błędnego polecenia, pierwszej zależności zainstalowanej w złym miejscu, pierwszego tokena, który ląduje w logu.

Piaskownica to dorosły sposób powiedzenia: śmiało, ale tutaj.

Trzeci element: MCP i problem ze złączem

Model Context Protocol stał się jedną z najciekawszych części ekosystemu, ponieważ próbuje ujednolicić coś, co w innym przypadku szybko stałoby się niewykonalne: sposób, w jaki model odkrywa i wykorzystuje narzędzia zewnętrzne.

Bez standardu każda integracja jest małą wyspą. Złącze dla GitHuba zrobione w jeden sposób, jedno dla Slacka zrobione inaczej, jedno dla baz danych o różnej semantyce, jedno dla automatyzacji przeglądarki, które wygląda jak nic.

MCP proponuje wspólny język pomiędzy klientem a serwerem: narzędzia, zasoby, podpowiedzi, autoryzacje, transport, wykrywanie. Nie rozwiązuje w magiczny sposób zarządzania i bezpieczeństwa, ale daje gramatykę.

I gramatyka ma znaczenie. When an agent can connect to many tools, the question is not just "can he do it?". Problem w tym, „czy rozumie, co może zrobić, z jakimi ograniczeniami, w czyim imieniu i po jakim śladzie?”.

Dla mnie MCP nie jest szumem, ponieważ „wywołuje narzędzia”. Już to zrobiliśmy. To szum, ponieważ przesuwa środek ciężkości z pojedynczej integracji na operacyjny katalog narzędzi.

W dobrej architekturze agentowej MCP staje się rodzajem panelu krosowego:

• GitHub dla kodu i problemów;
• Slack dla kontekstu konwersacyjnego;
• Linear lub Jira do pracy planowej;
• baza danych tylko do odczytu do celów analitycznych;
• przeglądarka lub skrobak kontrolowany dla stron zewnętrznych;
• przechowywanie dokumentów;
• izolowane środowiska wykonawcze;
• systemy wewnętrzne narażone na ataki ze ścisłymi uprawnieniami.

Problem w tym, że wolny od zasad katalog narzędzi to po prostu bardziej elegancki sposób na wywołanie chaosu.

Czwarty element: tożsamość i uprawnienia

Jest to obszar, na który wiele demonstracji przymyka oko.

Agent działa w czyimś imieniu. Zatem musi być jasne, kto jest podmiotem działania.

Czy korzysta z uprawnień użytkownika? Z konta usługi? Z przestrzeni roboczej? Czy masz dostęp tymczasowy czy stały? Czy potrafisz przeczytać wszystko, czy tylko niektóre zasoby? Czy możesz pisać? Czy możesz anulować? Czy może pisać do prawdziwych ludzi?

Jeśli nie odpowiesz dobrze na te pytania, prędzej czy później zbudujesz asystenta z kluczami do domu i nie pamiętasz, kto mu je dał.

Praktyczna zasada, którą lubię, jest następująca: agent musi być w stanie zrobić mniej niż człowiek i nie więcej niż człowiek. A kiedy musi zrobić coś bardziej ryzykownego, musi się zatrzymać i zapytać.

Oznacza to OAuth, zakres tokena, zarządzanie sekretami, dziennik audytu, zasady dotyczące narzędzi, listę dozwolonych, etap zatwierdzania. Mało romantyczna sprawa. Niezbędne rzeczy.

Kawałek piąty: pamięć i kontekst, ale bez gromadzenia śmieci

Agenci potrzebują pamięci, ale pamięć staje się niebezpieczna, gdy staje się strychem.

Istnieją co najmniej trzy rodzaje pamięci:

• uruchom pamięć: co się stało w tym wykonaniu;
• pamięć projektowa: konwencje, decyzje, ograniczenia;
• pamięć osobista lub zespołowa: preferencje, ton, rytuały, procesy.

Umieszczenie wszystkiego w monicie jest skrótem. Działa dopóki nie przestaje działać. Należy dbać o użyteczną pamięć: indeksowaną, aktualizowaną, wygasłą, weryfikowaną, nadającą się do cytowania.

Agent, który źle pamięta, jest gorszy od agenta, który nie pamięta. Ponieważ mówi z przekonaniem.

Dlatego infrastruktura musi obejmować pobieranie, pliki instrukcji, bazę wiedzy, osadzanie w razie potrzeby, ale także czyszczenie. Potrzebujemy kultury pamięci: co wchodzi, kto to akceptuje, kiedy zanika, jak to naprawić.

Element szósty: obserwowalność, ocena i powtórka

Jeśli agent popełni błąd, dziennik „zwany modelem” nie wystarczy.

Chcesz zobaczyć trasę. Jaki kontekst otrzymał? Jakie narzędzia były dostępne? Które narzędzie wybrałeś? Z jakimi argumentami? Jaką otrzymałeś odpowiedź? Ile to kosztowało? Gdzie utknął? Czy człowiek coś zaakceptował? Czy błąd dotyczy modelu, narzędzia, podpowiedzi, danych lub uprawnień?

Tutaj agenci bardziej przypominają systemy rozproszone niż chatboty.

Potrzebujesz czytelnych śladów, a nie tylko dzienników tekstowych. Musisz umieć odtworzyć przebieg. Konieczne jest porównanie dwóch wersji tego samego agenta w przypadku znanych zadań. Musimy mierzyć regresje: nie tylko „odpowiada lepiej”, ale „zamyka właściwy bilet bez dotykania niechcianych plików”.

Ewaluacje agentyczne są trudniejsze niż ewaluacje tekstowe, ponieważ obejmują akcje. Nie wystarczy porównać oczekiwany ciąg. Należy wziąć pod uwagę sekwencje, skutki uboczne, jakość artefaktu, czas, koszt, liczbę interwencji człowieka.

Najśmieszniejsze jest to, że zawsze tam wracamy: inżynieria oprogramowania. Testy, środowiska, ślady, wycofywanie zmian. Tyle że teraz kod decyduje również, co robić dalej.

Element siódmy: interfejsy ludzkie

Agent nie musi tylko żyć na czacie.

Niektórzy agenci potrzebują zarządu. Inni stronę ze statusem i logiem. Others of an "approve" button. Więcej komentarzy wbudowanych. Jeszcze inne z CLI.

Interfejs użytkownika zmienia zachowanie. Jeśli jedynym sposobem kontrolowania agenta jest napisanie długiej wiadomości, użytkownik przekaże agentowi niejasne instrukcje. Jeśli jednak widzi plan, różnicę, źródła, ryzyko i dalsze działanie, może precyzyjnie interweniować.

Przyzwoita infrastruktura agentowa obejmuje powierzchnie kontrolne:

• aktualny stan;
• edytowalny plan;
• wytworzone artefakty;
• różnica;
• approval requests;
• chronologia;
• przycisk zatrzymania;
• przycisk ponownej próby;
• widoczne uprawnienia.

Wydaje się to banalne, ale tak nie jest. Różnica między „przerażającą sztuczną inteligencją” a „niezawodnym asystentem” często polega na tym, że ten drugi pokazuje, gdzie ma ręce.

Stos mentalny

Gdybym miał to dzisiaj narysować, minimalny stos agentów wyglądałby następująco:

1. Model: wnioskowanie, generowanie, wywoływanie narzędzi, w razie potrzeby multimodalny.
2. Orkiestracja: pętla, krok, planista, polityka, człowiek w pętli.
3. Trwały czas działania: przepływ pracy, kolejka, ponowna próba, pauza, wznawianie.
4. Sandbox: wykonanie kodu, izolowany system plików, ograniczenia, artefakty.
5. Warstwa narzędziowa: MCP, wewnętrzne API, przeglądarka, baza danych, repozytorium.
6. Identity layer: OAuth, scope, secret, audit, policy.
7. Memory layer: project context, retrieval, instructions, expiration.
8. Obserwowalność: metryki śledzenia, odtwarzania, ewaluacji, kosztów i jakości.
9. Powierzchnia produktu: rozmawiaj, kiedy potrzeba, pulpit nawigacyjny, kiedy potrzeba, przeglądaj, kiedy to ma znaczenie.

Struktura agentyczna obejmuje głównie punkty 2 i część punktu 1. Reszta to prawdziwa praca.

Co zrobiłbym w praktyce

Gdyby zespół powiedział mi „chcemy agentów na produkcji”, nie zaczynałbym od dziesięciu agentów.

Zacząłbym od małego, powtarzalnego i obserwowalnego przepływu pracy. Na przykład: otwieraj żądania PR dotyczące konserwacji, aktualizuj dokumentację z zamkniętych problemów, przygotuj cotygodniowy przegląd, segreguj zduplikowane błędy, generuj testy dla plików, których dotyczy problem.

Następnie ustaliłbym bardzo jasne granice:

• żadnego pisania bez gałęzi i piaskownicy;
• brak tajemnic w monicie;
• narzędzia na liście dozwolonych;
• ludzka akceptacja dla działań zewnętrznych;
• obowiązkowe rejestrowanie i śledzenie;
• budżet na uruchomienie;
• dane wyjściowe zawsze można sprawdzić.

Dopiero wtedy mógłbym się rozwinąć.

Agenci nie ponoszą porażek tylko dlatego, że modele się mylą. Zawodzą, ponieważ umieszczamy je w niejasnym środowisku, z mylącymi pozwoleniami i teatralnymi oczekiwaniami.

Moja lektura

Infrastruktura agentowa jest nudna w najlepszym tego słowa znaczeniu.

To nie jest ten moment, który powoduje, że klaskasz w demie. To ta część, która pozwala faktycznie skorzystać z wersji demonstracyjnej w poniedziałek rano, z prawdziwymi ludźmi, prawdziwymi danymi i prawdziwymi konsekwencjami.

O przyszłości agentów nie będzie decydować wyłącznie to, kto będzie miał najlepszy wzór do naśladowania. O tym zadecyduje ten, kto zbuduje najlepsze miejsce, w którym będzie mógł pracować: odizolowany, gdy będzie eksperymentował, połączony, gdy zajdzie taka potrzeba, zawsze możliwy do zaobserwowania, autoryzowany na podstawie kryteriów i wystarczająco pokorny, aby przestać, gdy nie wie.

W tym miejscu agenci przestają być zabawką i stają się infrastrukturą.

Źródła

• Vercel: Jak zbudować agentów AI za pomocą Vercel i pakietu AI SDK
• Dokumenty Vercel: Piaskownica
• Vercel Docs: Praca z piaskownicą – Dokumenty Vercel: MCP
• Protokół kontekstu modelu: Specyfikacja
• OpenAI: Nowe narzędzia dla agentów budowlanych
• Blog Cloudflare: Agenci w Cloudflare