Kluczowe zasady projektowania:
- Specjalizacja Agenta: Zamiast tworzyć agentów o nieograniczonych możliwościach, lepiej jest wyspecjalizować ich w konkretnym obszarze. Upraszcza to dobór narzędzi i zmniejsza ryzyko błędów.
- Rozdzielenie Planowania od Wykonywania: Proces działania agenta powinien być podzielony na dwa etapy, które działają w pętli:
- Planowanie: Model analizuje cel i tworzy lub aktualizuje plan działania.
- Wykonywanie: Model skupia się na pojedynczym kroku z planu, wybiera odpowiednie narzędzie i generuje dla niego argumenty. Takie rozbicie logiki na mniejsze kroki zwiększa precyzję działania.
- Zarządzanie Kontekstem i Pamięcią: Istotne jest, jak długo przechowywane są informacje. Niektóre dane (np. cel konwersacji) muszą być dostępne przez cały czas, a inne (np. wynik ostatniej akcji) tylko na potrzeby bieżącego zadania.
- Prawidłowa Kolejność Informacji: Aby uniknąć pętli i nieporozumień, informacje o wykonanych akcjach powinny być dodawane do historii konwersacji po zapytaniu użytkownika, a nie w prompcie systemowym. Dzięki temu model wie, że zadanie zostało już zrealizowane.
- Spójny Format Danych: Należy dążyć do ujednolicenia formatu danych, z którymi pracuje agent. sugeruje sie stosowanie struktury “dokumentu” (obiekt z treścią i metadanymi) zarówno dla wyników narzędzi, obsługi błędów, jak i pracy z plikami. Zapewnia to ogromną elastyczność i ułatwia łączenie różnych modułów.
Interakcja z Użytkownikiem
Sposób interakcji agenta z użytkownikiem musi być świadomie zaprojektowany i może przybierać różne formy:
- Działanie w tle: Agent wykonuje zadania autonomicznie, bez bezpośredniego kontaktu.
- Kontakt asynchroniczny: Komunikacja odbywa się np. poprzez e-mail.
- Kontakt bezpośredni: Interakcja na czacie, często wymagająca potwierdzenia od użytkownika przed wykonaniem nieodwracalnych akcji (np. wysłanie maila). Można w tym celu wykorzystać dynamiczne komponenty interfejsu (Generative UI).
Główna Mechanika Agenta
Logika agenta została podzielona na kilka kluczowych, cyklicznie wykonywanych etapów, co zapewnia większą elastyczność i skuteczność w porównaniu do prostszych modeli.
- Etap Wstępnej Refleksji (“Myślenie”):
- Zanim agent przystąpi do działania, przeprowadza “wewnętrzny dialog”, który nie jest widoczny dla użytkownika.
- Na tym etapie agent orientuje się w sytuacji: analizuje zapytanie użytkownika, kompresuje informacje z ogólnego kontekstu (swojej “persony”, wiedzy o użytkowniku i otoczeniu), aby wybrać tylko te dane, które są w danym momencie istotne.
- Zadaje sobie pytania pomocnicze, aby określić, które obszary pamięci przeszukać i jakie narzędzia mogą być przydatne. Daje to modelowi “czas na myślenie” i pozwala na lepsze przygotowanie się do zadania.
- Etap Planowania (Zadania i Akcje):
- Na podstawie wstępnej refleksji agent tworzy plan działania w postaci listy zadań (tasks).
- Każde zadanie jest dalej dzielone na konkretne akcje (actions). Taka hierarchiczna struktura (zadanie > akcja) jest kluczowa dla odporności na błędy. Jeśli jedna akcja się nie powiedzie, można ją ponowić bez konieczności powtarzania całego zadania od początku.
- Etap Wykonania:
- Agent skupia się na wykonaniu pojedynczej akcji z planu.
- W oddzielnym kroku generuje obiekt żądania potrzebny do wywołania konkretnego narzędzia, co pozwala modelowi skoncentrować się wyłącznie na tym zadaniu i zwiększa precyzję.
- Następnie następuje faktyczne uruchomienie narzędzia, a jego rezultat jest dodawany do bieżącego stanu agenta.
Zarządzanie Stanem i Pamięcią
- Stan Agenta: Jest to centralne miejsce przechowujące wszystkie informacje związane z bieżącą konwersacją, w tym: ustawienia, kontekst, dostępne narzędzia, “przemyślenia” z etapu refleksji, wczytane dokumenty i wspomnienia oraz historię wiadomości. Stan jest dynamicznie aktualizowany i stanowi źródło informacji dla kolejnych kroków w pętli agenta.
- Pamięć Długo- i Krótkoterminowa: Agent dysponuje pamięcią długoterminową (np. bazą “wspomnień”) oraz krótkoterminową (bieżący stan). Kluczowym wyzwaniem jest, aby nie przeładować kontekstu modelu. Dlatego na etapie refleksji agent decyduje, które wspomnienia przywołać, a duże dokumenty mogą być kompresowane do streszczeń przed użyciem.
Każdy agent opiera się na trzech filarach:
- Planowanie: Zdolność do rozumienia sytuacji i podejmowania decyzji o następnym kroku.
- Narzędzia: Dostęp do zewnętrznych funkcji (np. wyszukiwarka internetowa), które rozszerzają jego możliwości.
- Pamięć: Dostęp do informacji z bieżącej interakcji oraz wiedzy długoterminowej.
Struktura Danych i Architektura Oparta na Zdarzeniach
Podstawą systemu jest architektura oparta na zdarzeniach (event-driven design) oraz dobrze zdefiniowana struktura bazy danych, która pozwala na śledzenie całego procesu. Kluczowe elementy schematu to:
- Konwersacje: Powiązane z użytkownikiem, stanowią wątek główny interakcji.
- Wiadomości: Elementy konwersacji, które mogą być powiązane z dokumentami.
- Zadania (Tasks): Główne cele do zrealizowania, przypisane do konwersacji. Posiadają statusy (np. w toku, zakończone, nieudane), co pozwala na ich monitorowanie.
- Akcje (Actions): Pojedyncze kroki składające się na zadanie. Każda akcja jest powiązana z konkretnym narzędziem i może operować na dokumentach.
Struktura (Zadanie > Akcja > Narzędzie) zapewnia elastyczność, umożliwia wznawianie procesu od miejsca, w którym wystąpił błąd, i daje wgląd w postęp prac.
Podział Odpowiedzialności: Model vs. Kod
Kluczową zasadą jest minimalizowanie roli modelu językowego. LLM powinien być angażowany tylko do zadań, których nie da się wykonać w sposób deterministyczny za pomocą kodu. Logika programistyczna powinna wspierać model poprzez:
- Ustawianie domyślnych wartości i weryfikację danych.
- Zapobieganie zapętleniom.
- Zarządzanie kontekstem przekazywanym do promptu.
- Obsługę logiki biznesowej, pozostawiając modelowi jedynie zadania kreatywne lub decyzyjne.
Zasady Efektywnego Użycia Narzędzi
Aby agent AI skutecznie posługiwał się narzędziami, należy wdrożyć następujące praktyki:
- Podział na małe kroki: Rozbijanie złożonych operacji na serię prostych, jednoznacznych akcji zmniejsza ryzyko błędu i “rozproszenia uwagi” modelu.
- Kontrola instrukcji: Zamiast polegać na nieprecyzyjnych poleceniach użytkownika, system powinien generować ustrukturyzowane zapytania do modelu na podstawie konkretnych działań (np. wgranie pliku uruchamia zdefiniowany proces).
- Zarządzanie kontekstem: Ilość informacji w prompcie powinna być ograniczona do niezbędnego minimum, aby unikać “szumu”.
- Wznawianie po błędach: Dzięki statusom zadań i akcji, system może automatycznie ponowić próbę wykonania kroku, który się nie powiódł.
- Weryfikacja: Odpowiedzi modelu powinny być weryfikowane, np. przez dodatkowy, prostszy prompt, ponieważ weryfikacja jest łatwiejsza niż generowanie.
Specjalizacja i Zaangażowanie Użytkownika
Obecna generacja modeli nie jest jeszcze gotowa do w pełni autonomicznego wykonywania bardzo złożonych, ogólnych zadań. Dlatego skuteczne aplikacje generatywne charakteryzują się:
- Wąską specjalizacją: Systemy są dostosowane do konkretnych potrzeb i procesów użytkownika, zespołu lub firmy, gdzie kontekst jest dobrze zdefiniowany.
- Inteligentną interakcją z użytkownikiem:
- Asynchroniczność: Długie zadania są wykonywane w tle, a użytkownik jest informowany o postępach.
- Personalizacja: System uczy się na podstawie interakcji, aby lepiej dopasować się do użytkownika.
- Bezpieczeństwo: Nieodwracalne akcje (np. publikowanie w mediach społecznościowych) wymagają ręcznego potwierdzenia przez użytkownika za pomocą wygenerowanego linku.
- Prośba o pomoc: Agent powinien mieć możliwość wstrzymania zadania i poproszenia o pomoc człowieka, gdy napotka problem, którego nie potrafi rozwiązać.
Bezpieczeństwo i Spójny Interfejs
- Ograniczone Uprawnienia: Ze względu na niedeterministyczną naturę LLM, kluczowe jest minimalizowanie ryzyka. Model powinien mieć dostęp tylko do absolutnie niezbędnych funkcji. Wszelkie akcje, których nie da się cofnąć (np. wysłanie e-maila), muszą być ograniczone programistycznie lub wymagać weryfikacji przez człowieka.
- Wspólny Interfejs Danych: Aby zapewnić elastyczność i możliwość łączenia ze sobą różnych narzędzi, wszystkie powinny operować na spójnym formacie danych. zaleca się stosowanie struktury “dokumentu” (treść + metadane) zarówno dla danych wejściowych, wyjściowych, jak i dla komunikatów o błędach. Dzięki temu agent może płynnie przekazywać wyniki działania jednego narzędzia do drugiego.
Kod vs. Narzędzia No-Code
- Narzędzia No-Code (np. Make.com): Są użyteczne do szybkiego prototypowania, prostych integracji lub gdy w proces zaangażowane są osoby nietechniczne. Pozwalają na łatwe łączenie wielu usług.
- Własny Kod: Wraz z rosnącymi zdolnościami LLM do generowania kodu (w tym obsługi skomplikowanych procesów autoryzacji jak OAuth 2.0), korzyści z no-code maleją. Własna implementacja daje większą kontrolę, elastyczność i stabilność, co jest preferowane w bardziej zaawansowanych zastosowaniach.
Koncepcja Zestawu Narzędzi (DocumentService)
Zamiast tworzyć skomplikowaną, monolityczną logikę, podejście opiera się na budowie zestawu prostych, wyspecjalizowanych funkcji. Agent AI nie musi rozumieć całego procesu przetwarzania, a jedynie wiedzieć, które narzędzie wywołać i z jakimi parametrami. Główne “umiejętności” wchodzące w skład tego zestawu to:
- Wczytywanie i Przetwarzanie (process): Funkcja ta przyjmuje źródło danych (link do strony, plik PDF/DOCX), wczytuje jego treść, a następnie dzieli ją na mniejsze, zarządzalne fragmenty (“dokumenty”) o określonej liczbie tokenów.
- Wydobywanie Informacji (extract): Na podstawie dostarczonej treści i opisu tego, czego należy szukać (np. “wypisz wszystkie wspomniane narzędzia”), model precyzyjnie wyciąga pożądane informacje.
- Odpowiadanie na Pytania (answer): Implementuje zaawansowany potok RAG (Retrieval-Augmented Generation). Dokument jest najpierw indeksowany w silnikach wyszukiwania (Algolia i Qdrant), a pytanie użytkownika jest przekształcane w serię zoptymalizowanych zapytań. Następnie system przeprowadza wyszukiwanie hybrydowe, aby znaleźć najbardziej relewantne fragmenty, i na ich podstawie generuje odpowiedź.
- Tłumaczenie (translate): Aby poradzić sobie z limitem tokenów wyjściowych modeli, długie dokumenty są tłumaczone fragment po fragmencie. Kluczowe jest tu zastosowanie promptu, który gwarantuje, że model zwróci wyłącznie przetłumaczony tekst, bez żadnych dodatkowych komentarzy.
Architektura Narzędzia na Przykładzie todo
Jako praktyczny przykład zaimplementowano narzędzie do zarządzania listą zadań w aplikacji Todoist. Jego architektura ilustruje kluczowe koncepcje:
- Wieloetapowa Logika Oparta na Promptach: Zamiast jednego, skomplikowanego promptu, narzędzie wykorzystuje serię mniejszych, wyspecjalizowanych promptów:
- “Mózg” Narzędzia (Understand Query): Pierwszy prompt analizuje zapytanie użytkownika w języku naturalnym i tworzy plan działania, np. decyduje, że należy dodać dwa zadania i zaktualizować jedno.
- Prompty Wykonawcze (add_tasks, update_tasks): Na podstawie planu, kolejne prompty generują precyzyjne obiekty JSON potrzebne do wywołania odpowiednich funkcji API (np. z treścią i terminem zadań).
- Równoległe Przetwarzanie: System jest w stanie przetwarzać wiele akcji jednocześnie (np. dodawanie kilku zadań naraz), co czyni go znacznie bardziej efektywnym niż ręczne wprowadzanie danych.
- Dynamiczny Kontekst: Prompty są dynamicznie zasilane niezbędnym kontekstem, takim jak aktualna lista projektów czy zadań, co pozwala modelowi podejmować trafniejsze decyzje.
dlawiki2m20 pt4x4 box 220×120
1 x 400×400 GRP junction box c/w 10 2.5mm terminals and 10 x 10mm terminals 2 x 20mm entries top 1 x 25mm entry top 1 x 32mm entry top – (then same entries in the bottom also)