Internet uznał, że to rok agenta. LangGraph, CrewAI i AutoGen to nazwy pojawiające się w każdym planie rozwoju inżynieryjnego. Zespoły testują pod obciążeniem warstwy orkiestracji, debatują nad maszynami stanów kontra odgrywaniem ról i zastanawiają się, która biblioteka w końcu uczyni duże modele językowe autonomicznymi.

Oto niewygodna prawda: większość tych porównań jest przedwczesna. Frameworki nie są najtrudniejszą częścią. Najtrudniejsze jest to, że przestaliśmy definiować nasze pojęcia. Teraz wszystko nazywa się agentem. Wywołanie narzędzia (tool call) to nie agent. Chatbot to nie agent. Tak niechlujna definicja prowadzi bezpośrednio do złego inżynieringu, przeintelektualizowanych systemów i awarii produkcyjnych, których można było uniknąć za pomocą prostego skryptu.

Zanim wybierzesz framework, zdefiniuj to, co tak naprawdę budujesz.

Czym tak naprawdę jest agent

Agent nie jest definiowany przez model, na którym pracuje, ani przez liczbę wywołań API, których dokonuje. Agent jest definiowany przez swoje zachowanie. Musi mieć jasny cel. Musi decydować, jaki krok nastąpi po kolei, bez wcześniejszego mapowania ścieżki przez człowieka. Musi radzić sobie z błędami, gdy dany krok zawiedzie. I musi wiedzieć, kiedy przestać.

Wyobraź sobie system wsparcia, który czyta przychodzący e-mail, klasyfikuje go jako prośbę o zwrot, wyodrębnia numer zamówienia, odpytuje bazę danych wysyłek, sprawdza okno polityki zwrotów, przygotowuje szkic odpowiedzi i oznacza zgłoszenie jako rozwiązane. Jeśli baza danych przekroczy limit czasu, system czeka i ponawia próbę. Jeśli okno polityki jest niejednoznaczne, zgłasza sprawę człowiekowi. Gdy odpowiedź zostanie wysłana, system przestaje działać. To jest agent. Wrapper wokół pojedynczego wywołania LLM, który zwraca JSON, nim jest, bez względu na to, ile naklejek „agent” naklei dział marketingu.

To rozróżnienie jest istotne, ponieważ złożoność ma swoją cenę. System, który nie wymaga autonomii, nie powinien za nią płacić.

Prawdziwy kształt AI na produkcji

Większość systemów AI działających obecnie na produkcji jest wąska. Robią jedną rzecz dobrze. Sortują zgłoszenia wsparcia do kolejek. Wyodrębniają daty ważności ze skanowanych dokumentów. Dopasowują zapytania klientów do istniejących artykułów w bazie wiedzy. Nie są to ogólne silniki rozumowania, a udawanie, że nimi są, prowadzi do najgorszego rodzaju overengineeringu.

Prowadzi to również do destrukcyjnej obsesji na punkcie premier nowych modeli. Zespoły gonią za najnowszym modelem fundamentowym, jakby miał on zrekompensować niechlujną architekturę. Tak się nie stanie. Bardziej zdolny model działający wewnątrz kruchej pętli bez obsługi błędów po prostu zawiedzie z większą pewnością siebie i bardziej kreatywnymi halucynacjami. Przestań gonić za benchmarkami. Zacznij gonić za strukturą.

Framework to nie produkt

LangGraph oferuje jawne maszyny stanów i cykle. CrewAI stawia na orkiestrację opartą na rolach, gdzie agenci przyjmują persony. AutoGen koncentruje się na agentach konwersacyjnych, którzy rozmawiają ze sobą, aby rozwiązywać problemy. Wszystkie one są zdolnymi narzędziami. Są one również fundamentalnie różnymi podejściami do przepływu sterowania.

Jednak framework, który wybierzesz, ma mniejsze znaczenie niż wzorce, które w nim wymusisz. Widziałem zespoły wdrażające niezawelną automatyzację używając jedynie Pythona i Redis, ponieważ szanowały granice. Widziałem inne zespoły upadające pod ciężarem wymyślnej orkiestracji, ponieważ traktowały framework jako substytut projektowania.

Jeśli Twoje przekazywanie zadań jest niejasne, narzędzia kruche, a logika ponawiania prób nie istnieje, logo w Twoim pliku requirements.txt Cię nie uratuje.

Trzy rzeczy, które naprawdę zasługują na Twój czas

Jeśli budujesz systemy agentowe, skieruj swój wysiłek na te trzy obszary.

Projektowanie narzędzi. Każda funkcja, którą może wywołać Twój agent, jest ryzykiem ubranym w interfejs. Projektuj je ściśle. Agresywnie waliduj dane wejściowe. Zwracaj błędy, które są faktycznie czytelne, a nie zrzuty typu 500. Dobre narzędzie to takie, o którym agent może logicznie wnioskować, gdy coś pójdzie nie tak.

Obsługa błędów. Załóż, że każdy LLM