Po przejęciu zadania przez Agenta pierwszą rzeczą, którą należy dokręcić, jest jednostka pracy.

Czytam ostatnio wiele dyskusji na temat Agenta i zawsze na koniec wracam do tego samego pytania: Komu oddać pracę, jak ją zapakować przed oddaniem i jak zostanie przyjęta po zwróceniu. Gdy ten problem pojawi się w projekcie, pierwszą rzeczą, która często wzrasta, nie jest koszt modelu, ale złożoność jednostki pracy. Jeśli zadanie zostanie zbyt duże, model będzie wyglądał „tak, jakby można go było wykonać”; prawdziwe problemy zwykle wiążą się z wycofywaniem, reprodukcją i akceptacją.

Jednostka pracy musi najpierw zostać zaakceptowana

W ciągu ostatnich kilku dni, po połączeniu fragmentarycznych notatek Martina Fowlera i kilku dyskusjach podczas Thinkworks Future of Software Development Retreat, najbardziej oczywistym odczuciem jest to, że rozmowa na spotkaniu była powierzchownie rozproszona, ale tak naprawdę kręciła się tylko wokół jednego – przekazania dużej części pracy Agentowi.

Wykończenie Kiefa Morrisa jest najprostsze. Podczas różnych sesji omawiano przegląd kodu, wypadki produkcyjne, podział pracy w zespole i routing modeli. Wydawało się, że mówią o różnych rzeczach, ale wniosek okazał się ten sam: ludzie dostosowywali rozmiar „pracy jednostkowej”. Im większa jednostka, tym łatwiej będzie ją przekazać; im większa jednostka, tym trudniej będzie ją zaakceptować po powrocie. Nie chodzi o to, że model nie może tego zrobić, ale o to, że kolejny link potwierdzający nie może wytrzymać jako pierwszy.

Dlatego też uprząż jest wciąż wspominana. Zarządzanie kontekstem, czujniki obliczeniowe, testowanie oparte na właściwościach, metody formalne – te rzeczy brzmią jak dodatkowe narzędzia, ale w rzeczywistości gromadzą jednostki pracy. Niektórzy ludzie kontrolują agents.md do mniej niż 200 linii, nie po to, aby dbać o schludność formy, ale po to, aby zmusić system do otrzymywania tylko tej części informacji, która jest naprawdę przydatna i naprawdę może zostać sprawdzona. Kontekst jest zbyt luźny, oczywiście Agent może działać; ale po uruchomieniu nikt nie wie, którą warstwę ograniczeń połknął.

Self-hosting zwiększa powierzchnię kontrolną

Dyskusje na temat modeli hostowanych samodzielnie również wskazują na to samo. Gdy tokeny staną się droższe, wymagania dotyczące zgodności staną się bardziej rygorystyczne, a dane nie mogą wyciekać, modele open source i modele lokalne w naturalny sposób staną się atrakcyjniejsze. Ale kiedy sam nosisz model, pojawiają się również problemy: procesor graficzny, pokój wnioskowania, routing, wycofywanie, dostrajanie i wybór modelu. Nie są to same możliwości modelu, ale od nich zależy, czy system będzie ostatecznie stabilny.

Takie koszty są często niedoszacowane. Wiele zespołów początkowo skupiało się na tym, „czy model jest silniejszy”, ale później odkryło, że tym, co naprawdę pochłania czas, jest stabilne przenoszenie jednostek pracy między wieloma modelami. Kiedy użyć dużego modelu, kiedy lekkiego modelu, a kiedy po prostu modelu lokalnego, nie zależy to od preferencji werbalnych, ale od warstwy powierzchni kontrolnej, którą można wykorzystać do odwrócenia uwagi i zatuszować. Bez tej warstwy rzeczy hosting na własny koszt przestanie „przejmować inicjatywę” do „samodzielnego przejmowania złożoności obsługi i konserwacji”.

Simon Willison wspomniał, że pozwala silniejszym modelom wybierać mniejsze modele do wykonania pracy. Pomysł ten jest również bardzo podobny do tego, co robi płaszczyzna sterowania. Sam model niekoniecznie zna granice kosztów zespołu, ale system je zna. Traktowanie modelu jako brokera i wykorzystywanie go do alokacji zadań jest bliższe rzeczywistej dostawie niż ślepe dążenie do jednego modelu obejmującego dostawę all-inclusive.

Akceptacji i celów nie można zlecać na zewnątrz

„Bring me a Rock” Sama Ruby’ego wyciągnęła na światło dzienne kolejną kwestię. Przekazanie pracy modelowi jest równoznaczne z dodaniem executora; odpowiedzialność nie znika. Menedżerowie mogą wykorzystać LLM do eksploracji i pozwolić mu najpierw wypluć kilka potencjalnych rozwiązań, ale ostateczne kryteria akceptacji i tak muszą wpaść w ludzkie ręce. Najbardziej kłopotliwe są ukryte cele. Uprawnienia, prywatność, destrukcyjne działania i wycieki kontekstu często nie są uwzględnione w oryginalnych wymaganiach.

Dlatego testy zgodności są często bardziej przydatne niż specyfikacje. Specyfikacje dobrze opisują „to, co jest wymagane”, a testy lepiej ujawniają „to, co nie może się zdarzyć”. Jest to szczególnie prawdziwe w systemach agentowych. Model może bardzo dobrze nadrobić jawne cele, ale ukryte granice należy zweryfikować poprzez twardszą weryfikację. Dopóki warunki akceptacji pozostają w niejasnych opisach, im więcej Agent zrobi, tym bardziej system będzie wyglądał, jakby stawiał na prawdopodobieństwo.

Dlatego przeglądanie kodu, obsługa incydentów i przydzielanie zadań, które kiedyś były zadaniami bardzo ludzkimi, teraz zaczynają przybierać inne formy. Menedżerowie korzystają z modelu bezpośrednio. Na pozór wydaje się, że poprawia to efektywność, ale na dole tak naprawdę zmieniają metodę zarządzania: z zarządzania metodami na zarządzanie celami. Jeśli cel jest jasno napisany, model będzie miał szansę zadziałać; jeśli cel jest niejasny, model tylko wzmocni niejednoznaczność dla innych.

Doświadczenie i umiejętności czytania wciąż się poprawiają

Wiedza interakcyjna i wiedza uzupełniająca, o których wspomniał Dan Davies, są również bardzo istotne dla tej zmiany. Model potrafi przeczytać wiele materiałów i dokonać rozsądnej oceny, ale aby system był stabilny, wciąż musi być ktoś, kto potrafi przeczytać specyfikacje, zobaczyć wyniki i wiedzieć, co jest nie tak. Kluczem nie jest to, że ludzie powinni konkurować z modelem, aby zobaczyć, kto jest mądrzejszy, ale to, aby ludzie nadal opowiadali się za stanowiskiem, które wyznacza granice.

Sprawa jest prostsza, jeśli chodzi o dostarczanie oprogramowania. Po przejęciu kontroli przez Agenta praca ludzka w mniejszym stopniu będzie polegać na ręcznym wykonywaniu zadań, a bardziej na segmentacji zadań, definiowaniu granic, projektowaniu akceptacji i obsłudze wyjątków. To, czy zadania można przekazać, jasno określa, czy warto zająć się późniejszym zarządzaniem kontekstem, wyznaczaniem tras modeli i orkiestracją narzędzi. Jeśli jednostka nie jest przejrzysta, niezależnie od tego, ile jest warstw, spowoduje to tylko cofnięcie problemu.

Po przeczytaniu tych fragmentów w ciągu ostatnich kilku dni nie pozostaje mi w głowie konkretna nazwa modelu ani nowy framework, ale prostsza ocena: pierwszą rzeczą, którą system Agent musi udoskonalić, nie są możliwości modelu, ale jednostka pracy. Jeśli jednostka jest mniejsza, akceptacja jest bardziej rygorystyczna, a uprawnienia bardziej rygorystyczne, system będzie miał możliwość utrzymania złożoności w kontrolowanym zakresie.