Model nie ma rąk. Nie wykonuje niczego, nie sięga nigdzie, nie zmienia stanu świata. Może wyłącznie zaproponowaćwywołanie — a między propozycją a skutkiem stoi kod, który napisałeś. To brzmi jak ograniczenie modelu. Jest twoją jedyną przewagą: skoro wszystko...
W pierwszym artykule padło zdanie, że agent nie kontynuuje pracy — zaczyna od zera z coraz dłuższą notatką. Notatką jest kontekst, a jego rosnąca długość to główny składnik rachunku. Pytanie, które z tego wynika, brzmi: co właściwie musi być w tej notatce, a co...
Wszystkie dotychczasowe przykłady zakładały, że narzędzie działa. W produkcji to założenie jest fałszywe częściej, niż się zakłada przy projektowaniu: API mają awarie, limity, przeciążenia i czasy oczekiwania. To, co pętla zrobi w takim momencie — i co powie o tym...
Dodanie narzędzia wygląda na czynność addytywną. Agent umie o jedną rzecz więcej, reszta zostaje jak była. Nie zostaje. Każde kolejne narzędzie pogarsza wybór wszystkich pozostałych i podnosi cenę każdego obrotu pętli — a oba efekty są niewidoczne, dopóki ktoś ich nie...
Kiedy agent wybiera niewłaściwe narzędzie, pierwszym odruchem jest poprawianie promptu systemowego. Drugim — zmiana modelu na mocniejszy. Zwykle problem leży gdzie indziej i naprawia się go bez dotykania jednego i drugiego. Model nie widzi kodu To warto powiedzieć...
Dwa poprzednie artykuły opisywały pętlę, która dostaje zadanie i ma je skończyć. Warunek zakończenia dotyczył całego agenta, budżet liczyliśmy na zadanie, a na wynik ktoś czekał. Istnieje druga kategoria, w której żadne z tych założeń nie obowiązuje. Dwa rytmy Agent...
