losowa tyrada na temat tego, gdzie jesteśmy z agentami AI:

niektórzy nie nazywają ich agentami, ale "agentami roboczymi" z deterministycznymi przepływami są wszędzie i działają. każdy może zbudować proste agenty robocze, nawet zaczynając od narzędzi bez kodu, takich jak Zapier i n8n. złożone agenty robocze wymagają znacznie więcej przemyślenia, aby zbudować je niezawodnie i efektywnie. złożony przepływ dla powszechnego i cennego przypadku użycia, z odpowiednimi integracjami wbudowanymi, może funkcjonować jako samodzielny biznes, a także jako świetna strategia wprowadzenia na rynek, aby później rozszerzyć się na inne przepływy lub bardziej autonomiczną pracę.

coraz więcej dynamicznych/autonomicznych agentów zaczyna działać i jest pomocnych w badaniach (szczególnie jeśli są oparte na sieci) oraz w kodowaniu. mniej niezawodne, gdy zaczynasz dodawać więcej źródeł danych (np. API). agenci tylko do odczytu wydają się bezpieczni i łatwi do przetestowania, ale pozwolenie autonomicznym agentom na podejmowanie działań (zapisywanie) jest przerażające. (losowy pomysł na ten temat: byłoby fajnie, gdyby narzędzia takie jak CRM pozwalały na „forkowanie” lustra dewelopera i przeprowadzanie eksperymentów automatyzacyjnych, które można cofnąć lub ponownie połączyć.)

dynamiczne agenty działają dobrze, gdy mogą (1) stworzyć i śledzić dobry plan oraz (2) poprawnie wykonywać zadania, jednocześnie (3) znajdując odpowiedni kontekst do wprowadzenia na każdym etapie (zarówno w planowaniu, jak i w każdym zadaniu). w końcu muszą (4) reflektować w trakcie (z lub bez ludzkiego wkładu), aby mogły odpowiednio dostosować plan, a także poprawić sposób, w jaki wykonują nieudane lub słabo działające zadania.

planowanie zadań: zdolności rozumowania LLM działają dobrze w przypadku prostych list zadań, które nie wymagają prywatnego kontekstu (jak głębokie badania, tylko seria wyszukiwań w sieci podczas podsumowywania). jeśli chcesz zbadać wiele podmiotów, głębokie badania nie działają tak dobrze, ponieważ zarządzanie listą zadań jest stosunkowo podstawowe. narzędzia AI oparte na arkuszach kalkulacyjnych działają lepiej w przypadku badania wielu podmiotów, ponieważ efektywnie przenosisz zarządzanie zadaniami do arkusza kalkulacyjnego, ponieważ przekazywanie długich list zadań między podpowiedziami tutaj nie działa. zarządzanie zadaniami w agentach kodujących działa w przypadku prostych problemów, prostego kodu lub gdy zaczynasz od zera. gdy przechodzisz do bardziej złożonych, istniejących projektów, są one mniej niezawodne - a deweloperzy zwiększają niezawodność, dokumentując, jak działa ich kod i jak jest zorganizowany (pliki .md), co pozwala agentowi tworzyć lepiej poinformowane listy zadań. złożony kod wymaga więcej dokumentów i ostatecznie dynamicznego wyciągania tylko istotnego kontekstu z tych dokumentów. wiele osób/biznesów ma silne, niedokumentowane opinie na temat poprawnej kolejności/podejścia/narzędzi do realizacji projektu, a potrzebujemy więcej podejść do dokumentowania tego z wyprzedzeniem i na bieżąco. innym powodem, dla którego agenci kodujący i badania w sieci działają dobrze, jest to, że wszyscy używają tego samego zestawu narzędzi, więc nie ma potrzeby „uczenia się”, jak używać tych narzędzi (więcej na ten temat w następnej części).

wykonywanie zadań: zadania to zazwyczaj wywołania API (wymagające autoryzacji i zrozumienia, jak korzystać z API oraz struktury danych - która może być unikalna, jak w CRM lub bazie danych z niestandardowymi tabelami/kolumnami), rozumowanie LLM (np. podsumowanie), kombinacja, a nawet agenci roboczy*. agent badawczy to tak naprawdę wyszukiwanie w sieci i podsumowywanie w pętli. agenci kodowania to CRUD w twojej bazie kodu, a może wyszukiwanie w sieci w celu nauki API. autoryzacja i podstawowy dostęp do API wydają się rozwiązane (MCPs pasują tutaj), ale chciałbym zobaczyć więcej kontekstu specyficznego dla narzędzi (zapytaj użytkownika, ale także analizuj przy początkowym połączeniu, zagłębiaj się w istniejące dane, aby zrozumieć, jak narzędzie jest używane, jak dane są strukturalizowane, w jakich scenariuszach/projektach używamy narzędzia). błędy/refleksja/feedback muszą przekształcić się w zorganizowane nauki, które będą wprowadzane jako kontekst, gdy to istotne. te same narzędzia mogą być używane do różnych celów i w różnych sposób między organizacjami i musimy jakoś to uchwycić/dokumentować, aby dobrze wykonywać zadania.

kontekst: wyobraź sobie, że jesteś nowym pracownikiem w firmie. uczysz się wiele podczas onboardingu (im lepszy onboarding, tym bardziej efektywny jesteś od samego początku), a potem jest nauka w pracy, która dzieli się na naukę z doświadczenia organizacji ("tak robimy rzeczy") i naukę z własnego doświadczenia - to pierwsze jest bardziej dominujące w dużych organizacjach. zarządzanie kontekstem jest podobne. są różne warstwy kontekstu, takie jak meta (użytkownik/firma), specyficzne dla projektu/działu, specyficzne dla zadania, specyficzne dla narzędzia itd. przeszliśmy od prostych podpowiedzi systemowych do hybrydowych strategii RAG (wektor, słowo kluczowe, graf), ale poza posiadaniem danych/kontekstu, potrzebujemy wskazówek, kiedy i jak odzyskać kontekst, co widzimy w wczesnych wersjach dzisiaj - ale jest wiele miejsca na poprawę. to nie jest tylko problem techniczny, ale także kwestia biznesowa - ponieważ zasadniczo musisz stworzyć dokument onboardingowy, który obejmuje każdy scenariusz, którego się spodziewasz. w miarę jak projekty stają się coraz bardziej skomplikowane, wymaga to więcej przemyślenia, aby poprawnie przyciąć kontekst, aby tylko istotne informacje były zawarte w podpowiedzi, minimalizując jednocześnie nieistotny kontekst.

refleksja: mamy narzędzia do monitorowania agentów, które pokrywają koszty LLM/api, obserwacja, ale przypisanie sukcesu/niepowodzenia jest wyzwaniem - jednym z obszarów, w którym agenci kodujący mają przewagę nad innymi, jest deterministyczny sposób zauważania błędów (poprzez testowanie kodu). W przypadku wielu innych zadań agentowych wciąż ustalamy właściwy sposób zbierania ludzkich informacji, aby poprawić przyszłe wyniki. O ile mi wiadomo, refleksja dzisiaj jest w trybie człowiek-w-pętli, gdzie informacje zwrotne są w dużej mierze przekazywane ludzkim programistom w celu poprawy agenta, ale kluczowym momentem będzie, gdy ustalimy, jak przekształcić refleksję w samodoskonalenie - gdzie agent czerpie wnioski z błędów w generowaniu listy zadań i wykonywaniu zadań, aby następnym razem poradzić sobie lepiej. W zasadzie refleksja musi przekształcić się w dobrze zorganizowany kontekst, który można wykorzystać w podpowiedziach tylko wtedy, gdy jest to istotne. To ewoluuje w kierunku dostrajania elementów agenta, a następnie agentowych środowisk RL - wciąż wydaje się, że jesteśmy na wczesnym etapie.

*wcześniej wspomniałem o przekazywaniu zadań agentom roboczym, co zaczyna mieć sens, gdy twój agent zyskuje na tym, że nie ma agentów roboczych jako narzędzi (w porównaniu do ustalania znanej listy zadań za każdym razem) lub gdy twój system jest wystarczająco skomplikowany, że wyspecjalizowani agenci z wyspecjalizowanym kontekstem i narzędziami działają lepiej. lub jeśli korzystasz z agentów stworzonych przez innych ludzi (jednym z wzorców, które zacząłem tutaj dostrzegać, są punkty końcowe API języka naturalnego dla łatwiejszej współpracy agentów).

gdybyśmy mieli dzisiejszą jakość modelu z nieskończonym oknem treści (bez degradacji jakości), nieskończoną moc obliczeniową, nieskończoną pamięć, dostęp przez przeglądarkę i metodę płatności, pojedyncza pętla LLM prawdopodobnie wystarczyłaby, aby wiele osiągnąć punkt bezsensownego punktu powyżej (nic nie jest nieskończone) polega na tym, że orkiestracja agentów w dużej mierze polega na zarządzaniu ograniczeniami poprzez projektowanie sposobów odciążania pracy z LLM za pomocą struktury i kodu.

agenci w produkcji występują w różnych formach: jako narzędzia wewnętrzne, jako samodzielny produkt łączący różne narzędzia oraz wbudowane jako funkcja w narzędzie podstawowe. Mogą być ogólne lub specjalistyczne. czat, głos i agenci w tle wydają się być najczęściej spotykanym interfejsem UI do uruchamiania przepływów agentowych.

Czego jeszcze mi brakuje?