Dlaczego większość konfiguracji agentów AI działa dużo wolniej, niż mogłaby

Przepaść między umiarkowaną a znaczącą wartością z narzędzi AI wynika z architektury oplatającej model. Steve Yegge zauważył na początku 2026 roku, że deweloperzy korzystający z agentów AI do kodowania raportują wyraźny wzrost produktywności przy odpowiednich zadaniach; podawane liczby różnią się znacznie w zależności od metodologii i rodzaju zadania. Te same modele. Ta sama bazowa inteligencja. Zmienną jest struktura.

W ciągu jednego tygodnia w kwietniu 2026 roku pięciu niezależnych twórców opublikowało frameworki dotyczące architektury agentów AI. Garry Tan (Y Combinator), Andrej Karpathy, Viv Trivedy, Daniel Miessler oraz repozytorium społecznościowe, które osiągnęło 19 700 gwiazdek GitHub, zbiegły się na tej samej podstawowej tezie: umieszczać inteligencję w przenośnych plikach markdown, utrzymywać infrastrukturę orkiestracji jak najcieńszą i pozwalać modelowi na samodzielne wnioskowanie. Ten artykuł omawia punkty zgodności, obszary rozbieżności i wnioski dla wszystkich budujących z AI.

Kluczowe wnioski

• Inteligencja należy do plików skill w markdownie, nie do kodu frameworka. Skill są przenośne, podlegają wersjonowaniu i automatycznie się poprawiają, gdy poprawia się model.
• Harness powinien robić cztery rzeczy i nic więcej. Uruchamiać model w pętli, czytać i pisać pliki, zarządzać kontekstem, egzekwować bezpieczeństwo. Każda dodana funkcja ponad to pochłania kontekst i spowalnia wnioskowanie.
• Pięciu twórców niezależnie opublikowało tę samą tezę w ciągu trzech dni (od 12 do 15 kwietnia 2026). Garry Tan, Andrej Karpathy, Viv Trivedy, Daniel Miessler oraz repozytorium społecznościowe z 19 700 gwiazdkami. Konwergencja z wielu niezależnych źródeł to jeden z sygnałów, że wzorzec architektoniczny jest solidny.
• LangChain się nie zgadza i ma benchmarki na potwierdzenie. Harrison Chase argumentuje, że harness JEST produktem. Odpowiedź może zależeć od tego, czy buduje się narzędzia konsumenckie, czy pipeliny korporacyjne.
• Instrukcje przepisowe wygasają. Kontekst nie. Każdy przepis krok po kroku napisany dla AI traci aktualność wraz z kolejnym wydaniem modelu. Kontekst dotyczący tego, kim jest użytkownik i czego chce, kumuluje się.

Architektura jest zwarta

Publiczne dyskusje o produkcyjnych środowiskach uruchomieniowych agentów coraz częściej skupiają się na zwartej architekturze: pętla modelu, narzędzia, zarządzanie kontekstem i mechanizmy bezpieczeństwa. Garry Tan opisał ten wzorzec jako czynnik produktywności, który nauczał w Y Combinator od miesięcy: przepaść w produktywności wynika z tego, co otacza model.

Tan zredukował tę architekturę do trzech warstw:

Zasada jest kierunkowa. Inteligencja wędruje w górę do skill. Wykonanie schodzi w dół do deterministycznych narzędzi. Harness pozostaje cienki. 90% wartości leży w warstwie skill. Harness to dyrygent, który czyta pliki, nie ich właściciel.

Własne doświadczenie Tana ilustruje ten punkt. Jego prywatny CLAUDE.md zaczął od 20 000 linii. Każda osobliwość, każda konwencja, każda lekcja, z jaką kiedykolwiek się zetknął. Efekt: uwaga Claude Code degradowała się. Model dosłownie powiedział mu, żeby go skrócił. Rozwiązaniem okazały się ok. 200 linii wskaźników do dokumentów ładowanych na żądanie. Pełne 20 000 linii wiedzy nadal istnieje, ładuje się tylko wtedy, gdy jest potrzebne, zamiast zaśmiecać okno kontekstu przy każdym zapytaniu.

Jeśli budujecie narzędzia lub przepływy pracy oparte na AI dla swojej firmy, właściwa architektura od samego początku decyduje o tym, czy powstanie imponujące demo, czy system, który realnie działa.

Pięć definicji odróżniających wysokowydajne projekty AI

Architektura opiera się na pięciu koncepcjach. Pominięcie którejkolwiek z nich powoduje, że system działa poniżej możliwości.

1. Pliki skill

Skill to wielokrotnego użytku dokument w markdownie, który uczy model procesu dla danej kategorii zadań. Użytkownik dostarcza zadanie, skill dostarcza procedurę. Działa jak wywołanie metody: ta sama procedura, inne argumenty, radykalnie różne wyniki.

Przykład Tana: skill o nazwie /investigate ma siedem kroków (określ zakres zbioru danych, zbuduj oś czasu, sporządź protokół każdego dokumentu, syntetyzuj, argumentuj obie strony, cytuj źródła). Skierowany na naukowca zajmującego się bezpieczeństwem i 2,1 miliona e-maili z postępowania dochodzeniowego daje analityka badań medycznych. Skierowany na spółkę-słup i dokumenty FEC daje śledczego finansowego. Te same siedem kroków. Wywołanie dostarcza kontekstu świata.

2. Resolvery

Resolver to tabela routingu dla kontekstu. Gdy pojawia się typ zadania X, najpierw załaduj dokument Y. Bez resolvera deweloper zmienia prompt i wdraża go. Z resolverem model najpierw czyta dokumentację zestawu ewaluacyjnego, uruchamia benchmarki i cofa zmiany, jeśli dokładność spadnie o więcej niż 2%. Deweloper nie wiedział, że zestaw ewaluacyjny istnieje. Resolver załadował właściwy kontekst we właściwym momencie.

3. Latentne a deterministyczne

Każdy krok w systemie jest jednym lub drugim. Mylenie ich to najczęstszy błąd w projektowaniu agentów. LLM może rozmieścić 8 osób przy stole kolacyjnym, uwzględniając osobowości. Poproszony o rozmieszczenie 800 osób wygeneruje plan siedzący, który wygląda sensownie, ale jest zupełnie błędny. To problem deterministyczny wtłoczony na siłę w przestrzeń latentną. Najlepsze systemy są bezwzględne w utrzymaniu tej granicy.

4. Diaryzacja

Model czyta wszystko na dany temat i tworzy ustrukturyzowany profil. Żadne zapytanie SQL tego nie wyprodukuje. Żaden pipeline RAG tego nie wyprodukuje. Model musi czytać, utrzymywać sprzeczności w pamięci, zauważać co i kiedy się zmieniło, a następnie syntetyzować ustrukturyzowaną wiedzę.

Zespół Tana zbudował system dla YC Startup School zarządzający 6 000 profili założycieli w ten sposób. Wyniki diaryzacji wychwytują rzeczy, których żadne wyszukiwanie słów kluczowych nie znajdzie: założycielka, która mówi "Datadog dla agentów AI", ale której commity na GitHub w 80% dotyczą kodu rozliczeniowego. Buduje narzędzie FinOps ukryte pod szyldem obserwowalności. Ta rozbieżność między "mówi" a "faktycznie buduje" wymaga jednoczesnego przeczytania historii commitów, wniosku i transkryptu rozmowy z doradcą. Żadne wyszukiwanie przez podobieństwo embeddingów tego nie znajdzie.

5. Trwałe ulepszenia

Instrukcja Tana dla jego AI: "Jeśli prosisz mnie o zrobienie czegoś, co będzie musiało się powtórzyć, skodyfikuj to w pliku skill. Jeśli ma działać automatycznie, ustaw to jako cron. Jeśli musisz mnie o coś prosić dwa razy, zawiodłeś." Każdy napisany skill to trwałe ulepszenie. Nigdy nie degraduje się. Gdy pojawi się kolejny model, każdy skill natychmiast staje się lepszy. System się kumuluje.

Pięć frameworków opublikowanych w ciągu jednego tygodnia mówi to samo

Konwergencja jest najsilniejszym sygnałem. Te pięć niezależnych prac powstało między 12 a 15 kwietnia 2026 roku. Żaden z tych twórców nie współpracował ze sobą. Doszli do tej samej architektury z różnych punktów wyjścia.

Tan doszedł tu po opublikowaniu dużej ilości kodu produkcyjnego w ciągu dwóch miesięcy, gdzie liczba linii jest miernikiem przepustowości, a ta przepustowość jest niezwykła z gstack (ponad 23 000 gwiazdek GitHub w pierwszym tygodniu; liczba gwiazdek mierzy widoczność, a nie przydatność produkcyjną). Karpathy doszedł tu po debugowaniu trzech trwałych trybów awarii asystentów AI do kodowania. Trivedy doszedł tu po iterowaniu nad projektem harnessu przez ponad 30 wersji. Miessler doszedł tu, stosując gorzką lekcję Richarda Suttona do narzędzi AI.

Konwergencja z wielu niezależnych źródeł to jeden z sygnałów, że wzorzec architektoniczny jest solidny.

LangChain się nie zgadza i ma benchmarki na potwierdzenie

Harrison Chase (CEO LangChain) opublikował Deep Agents w tym samym tygodniu i argumentował odwrotnie: harness JEST produktem. Wbudowane planowanie zadań, uruchamianie subagentów, middleware, hooki, pełna infrastruktura orkiestracji. Jego dowód: zmiana wyłącznie harnessu przeniosła DeepAgent LangChain z miejsca poza top 30 do top 5 na TerminalBench 2.0.

LangChain przetwarza miliony wywołań agentów dziennie, więc ten argument zasługuje na uwagę. Benchmarki są publiczne. Rzeczywisty podział poglądów: stanowisko Tana głosi, że każdy fragment logiki w harnessie ogranicza wnioskowanie, które mógłby wykonać model. Im lepszy model, tym cieńszy powinien być harness. Stanowisko Chase'a jest takie, że inżynieria harnessu rozszerza możliwości modelu, a nie je zastępuje.

Oba stanowiska mogą być słuszne w różnych kontekstach. Agenty konsumenckie i osobiste, gdzie liczy się przenośność i długowieczność, preferują cienki harness. Pipeliny korporacyjne, gdzie liczy się niezawodność i audytowalność, mogą uzasadniać gruby harness. Żadna ze stron nie kwestionuje, że skill powinny być grube. Użyteczne pytanie dla danego projektu dotyczy tego, po której stronie tej granicy leży konkretny przypadek użycia.

Większość firm budujących funkcje AI po raz pierwszy powinna zaczynać od cienkiego harnessu i dodawać infrastrukturę tylko wtedy, gdy napotyka konkretne problemy z niezawodnością. Nie wiadomo, po której stronie leży dany projekt? Zapraszamy do rozmowy z webvise o tym, która architektura pasuje.

Instrukcje wygasną. Kontekst nie.

Daniel Miessler opublikował najostrzejszą diagnozę tygodnia. Nazywa ją audytem inżynierii przez pryzmat gorzkiej lekcji, nawiązując do obserwacji Richarda Suttona z 2019 roku, że ogólne podejścia skalujące się wraz z obliczeniami konsekwentnie pokonują podejścia zakodowane ręcznie w perspektywie długoterminowej.

W zastosowaniu do narzędzi AI: zła inżynieria harnessu to instrukcje przepisowe. "Najpierw skopiuj ten plik, potem załaduj to, potem zrób tamto, potem to." Mikromanagement wykonania AI krok po kroku. To podejście degraduje się wraz z coraz inteligentniejszymi modelami. Nadmiernie sztywne kroki uniemożliwiają modelowi stosowanie własnego wnioskowania.

Dobra inżynieria harnessu jest kontekstualna. Informacje o tym, czym się zajmuje twórca, nad czym pracuje, co chce osiągnąć i jak wygląda dobry oraz zły wynik. Tożsamość, gust, standardy, cele. Model sam dochodzi do tego, jak to zrobić.

Diagnostyka Miessler jest prosta. Jeśli konfiguracja wygląda jak przepis (krok 1, krok 2, krok 3), to jest zła inżynieria harnessu. Jeśli wygląda jak dokument briefingowy (oto kto to jest, oto co jest ważne, oto dostępne narzędzia), to jest dobra inżynieria harnessu. Kontekst dotyczący tożsamości nigdy nie wygasa. Instrukcje przepisowe stają się przestarzałe wraz z każdym ulepszeniem modelu.

Architektura nie jest skomplikowana. Grube skill, cienki harness, bezwzględne oddzielenie pracy latentnej od deterministycznej. Trudna jest dyscyplina: kodowanie osądu w wielokrotnego użytku skill zamiast wykonywania jednorazowej pracy, utrzymywanie harnessu w cienkości, gdy kusi dodawanie funkcji, i zaufanie modelowi, że sam znajdzie "jak", gdy dostarczy się mu właściwe "co" i "dlaczego".

webvise buduje systemy oparte na AI zgodnie z tymi zasadami architektonicznymi. Niezależnie od tego, czy potrzebny jest przepływ pracy agentów, zautomatyzowany pipeline, czy integracja AI klasy produkcyjnej, architektura ma większe znaczenie niż model.