Agenci są zawsze pracownikami pierwszego dnia. Nadszedł czas, abyśmy projektowali z myślą o tym.

Do 2027 roku, 74% firm ma korzystać z agentów w pewnym zakresie, według niedawnego badania Deloitte. Od lat projektowaliśmy i budowaliśmy oprogramowanie, aby usprawnić ludzkie doświadczenia w nawigacji po naszych aplikacjach, stronach internetowych, systemach operacyjnych i dokumentach. Teraz użytkownik wcale nie jest człowiekiem. Ma to szersze konsekwencje niż tylko przejście od pulpitów nawigacyjnych i kontrolowanych przepływów pracy, które projektujemy dla ludzkich zadań. Znajdujemy się w momencie, w którym musimy projektować środowiska operacyjne agentów, jednocześnie również projektując ludzkie przepływy pracy, aby skutecznie prowadzić doświadczenie agenta w tych środowiskach.  

Wciąż jesteśmy na wczesnym etapie poznawania tego, czego agenci naprawdę potrzebują od nas, aby być powtarzalnie i niezawodnie skuteczni. Instynkt skłania nas do traktowania integracji agenta wyłącznie jako problemu podpowiadania lub interfejsu użytkownika. Projektowanie środowiska wykonawczego o dobrej kontroli jest dla nas nowym terenem kulturowym. Jednak podstawowe zasady dobrego projektowania i dobrego zarządzania nie uległy zmianie: jesteśmy winni agentom jasny kontekst, jednoznaczną dyrektywę i wyraźny zamiar.

Kontekst: Dlaczego kodowanie było pierwsze

Kontekst jest prawdopodobnie najważniejszym wkładem, jeśli chcemy, aby agenci powtarzalnie dostarczali wyniki na zamierzonym poziomie. Rozwój oprogramowania ma go zapisane więcej niż prawie jakakolwiek inna dziedzina: repozytoria, schematy API, relacje między systemami, przeglądy kodu i dyskusje społecznościowe. Dlatego sensowne jest, że laboratoria AI zaczęły od kodowania. To jedna z niewielu dziedzin, w których spora część kontekstu jest już zapisana.

Jednak, jak każdy nowy pracownik w zespole programistycznym powie, nawet przy całej tej ilości danych, agenci wciąż będą brakować pamięci instytucjonalnej zawartej w niewypowiedzianych regułach, których nikt nie udokumentował. Ta luka jest powszechna: 43% programistów obawia się, że narzędzia AI nie mają wystarczającego kontekstu dotyczącego ich konkretnego projektu lub bazy kodu. Wiedza ukryta obejmuje wszystko, od codziennych konwencji, takich jak preferowane biblioteki do określonych zadań, po krytyczne „duchy” operacyjne: nocna poprawka, która pozostaje na zawsze, lub pozornie pustą kolumnę w bazie danych, która potajemnie podtrzymuje niestandardowy raport przychodów. Ten kontekst istnieje w głowie starszego inżyniera, w niedawnym wątku Slack, lub wcale nie istnieje. Rzadko znajduje się w samej bazie kodu.  

Jeśli to prawda w oprogramowaniu, jednej z najlepiej udokumentowanych dziedzin, łatwo zrozumieć, dlaczego agenci mają trudności z efektywnym działaniem od pierwszego dnia w wielu innych branżach. W opiece zdrowotnej i prawie duża część wiedzy instytucjonalnej kształtującej codzienną pracę jest uczona i internalizowana. Żyje w doświadczeniach ludzi, a nie w formalnej dokumentacji. Agent prawny może nie znać preferowanej struktury, tonu czy argumentacji konkretnego partnera w briefie, podczas gdy agent medyczny może nie rozumieć lokalnych przepływów pracy i praktyk eskalacji, które zajęta klinika stosuje, aby wspierać triage prowadzone przez klinicystów. Sama dokumentacja nie może zamknąć tej luki, ponieważ wyzwanie nie polega jedynie na dostępie do informacji; chodzi o przekazanie kontekstu. Aby dać agentom to, czego potrzebują, aby odnieść sukces, musimy wprowadzić ich tak, jak wprowadzilibyśmy nowego pracownika.

Kierunek: Dlaczego osmoza nie działa

Wprowadzenie nowego członka zespołu wymaga więcej niż udostępnienie odpowiednich materiałów i dostępu. Kiedy zależy nam na sukcesie osób wokół nas, zapewniamy solidne wytyczne, co zrobić z nowymi materiałami i dostępem: oczekiwania, jasność co staramy się osiągnąć oraz informacje zwrotne w trakcie. Tę samą mentalność przenoszę na projektowanie dla agentów. Daję jasne, konkretne wytyczne (odnoszące się do bieżącego zadania). Dotyczy to każdego współpracownika, niezależnie od stażu. Jednak w scenariuszu nowego pracownika wytyczne muszą iść dalej, ponieważ nie posiada on jeszcze żadnego kontekstu instytucjonalnego.

Wyobraź sobie agenta jako nowego pracownika, który nigdy nie przestaje być nowy. Jest chętny i zdolny (szczerze mówiąc, ma nieograniczoną energię), ale nie potrafi przyswajać i zachowywać tak wielu niewypowiedzianych reguł, jak człowiek z czasem. Ludzie uczą się przez osmozę i doświadczenie, podczas gdy agenci uczą się z architektury, która jest wyraźnie wbudowana w ich środowisko pracy.

W przypadku nowego pracownika możesz zamykać tę lukę z czasem poprzez pytania, informacje zwrotne i nowe spostrzeżenia, które zdobywa o procesach i preferencjach organizacji w trakcie. Dosłowne rozmowy przy ekspresie do kawy lub wspólne lunche. Z agentem musisz zbudować zamykanie tej luki w samym projekcie. To może obejmować: 

• Dostarczanie agentowi strukturalnego okna kontekstu, które oddziela trwałe zasady, fakty specyficzne dla zadania i istotną historię, zamiast wrzucać mu stos dokumentów.
• Zdefiniowanie z góry jego uprawnień i granic decyzyjnych: co może robić samodzielnie, co wymaga zatwierdzenia i czego nigdy nie powinien mieć dostępu.
• Wbudowanie kilku konkretnych przykładów wysokiej jakości wyników bezpośrednio w doświadczeniu, aby agent miał jasny model, jak praca powinna być wykonana.
• Udostępnianie wcześniejszych ślepych zaułków, w które natrafiłeś.

Projektowanie dobrze zarządzanego środowiska agenta nie polega na ułatwianiu pracy modelowi. Chodzi o ochronę ludzkiego zespołu inżynierskiego przed niewidzialnym długiem technicznym. Jednak nawet dobrze ukierunkowany agent może perfekcyjnie wykonać instrukcje i nadal nie trafić w sedno. Kierunek mówi mu, co zrobić, ale nie określa, jak wygląda „dobro”. To właśnie w tej luce pojawia się zamiar.

Intencja: Dlaczego agenci dryfują w środek

Ważne jest, aby pamiętać, że agenci są maszynami dopasowującymi wzorce, szkolonymi na ogromnych ilościach wiedzy i naturalnie skłonnymi do dostarczania statystycznej średniej. Bez jasnego, wyraźnego zamiaru, średni wynik jest dokładnie tym, co agent zwróci. Poproś agenta o „dodanie punktu końcowego uwierzytelniania użytkownika”, a wygeneruje on textbookową trasę Express z podstawowym haszowaniem haseł. Działa, ale całkowicie ignoruje własny serwis uwierzytelniania zespołu, pomija wymaganą telemetrię i psuje ustandaryzowane formatowanie błędów. To akceptowalna funkcja na papierze, ale w zależności od kontekstu jest w praktyce błędem architektonicznym. Łatwość, z jaką wprowadzane są takie „błędy”, nie może być przeceniona.

Aby temu zapobiec, kierunek musi być połączony z aktywną weryfikacją intencji i rejestrowaniem. Barierki nie powinny jedynie sprawdzać, czy kod się kompiluje, choć to ważne. Barierki muszą wyraźnie wymuszać subiektywne standardy, reguły wyjątkowych przypadków i kontekst domenowy, które podnoszą ogólny wynik do poziomu gotowego do produkcji. Rejestrowanie ma znaczenie jako wskaźnik statusu systemu dla nas, ludzi. Ta możliwość śledzenia jest kluczowa dla zaufania. 

W interakcjach międzyludzkich istnieje dużo miejsca na niepewność. Ktoś może podzielić się z tobą pierwszą wersją, a razem możecie omówić, co jest mocne, a co wymaga poprawy. Działa to, ponieważ nie oczekujemy, że nasi współpracownicy będą autonomicznymi maszynami. Aby naprawdę uchwycić moc i obietnicę współpracowników-agenta (którzy muszą działać bardziej autonomicznie…), możemy zaprojektować wiele z tych kontrolnych wytycznych. Wymiana zdań wciąż musi mieć miejsce, ale nie może opierać się wyłącznie na ręcznym wysiłku. Poprzez wstępne określenie jasnych kryteriów akceptacji i reguł weryfikacji, umożliwiasz agentowi prowadzenie własnych wewnętrznych pętli sprzężenia zwrotnego. Projektowanie w celu zapobiegania błędom to kolejna solidna zasada UX, którą możemy zastosować w tym nowym świecie: dając agentom możliwość oznaczania niskiego poziomu pewności przed podjęciem działania, zamiast cichego domyślania się najlepszego rozwiązania.

Gdzie metafora się rozpada

Ramowanie jako nowy pracownik działa, dopóki nie przestaje. W przypadku ludzkiego zatrudnienia doświadczenie prowadzi do kompetencji, które prowadzą do osądu. Obserwowanie, jak nowy pracownik internalizuje „dlaczego” stojące za kontekstem i kierunkiem, buduje zaufanie z czasem i ogólnie jest kumulatywne. Agent nie ma gdzie gromadzić i przechowywać tego doświadczenia.

Pierwszy tydzień i setny tydzień nowego pracownika wyglądają inaczej. Pierwsze zadanie agenta i tysiące z kolei wyglądają identycznie, chyba że zaprojektujesz i zbudujesz coś, co je odróżni. To nasze nowe wyzwanie projektowe.

Odpowiedzialność agenta zależy od projektu

Jeśli odpowiedzialność nie może mieszkać w agencie, musi znajdować się w otaczającej go strukturze. To sprowadza się do tych samych trzech pytań, które zadałbym przed przekazaniem pracy nowemu pracownikowi: Jakim kontekstem dysponuje? Jakie wytyczne mu przekazałem? Jaki jest mój rzeczywisty zamiar?

Następnym razem, gdy przekażesz zadanie agentowi, nie sprawdzaj tylko wyniku. Najpierw sprawdź własne dane wejściowe. Czy podałeś mu kontekst, którego nowy pracownik potrzebowałby w pierwszym dniu? Czy twoje wytyczne były wystarczająco konkretne, aby przetrwać dosłowne zrozumienie? Czy twój zamiar był na tyle jasny, że „średnia odpowiedź” nie była najlepszym, co mógł zrobić?

Mając w ręku te jasne wytyczne (w bajtach?), dzieje się coś interesującego: agent nie potrzebuje długiego okresu, aby stać się godnym zaufania. Kontekst, kierunek i weryfikacja, które wbudujesz od początku, określają, jak działa przy każdym zadaniu. Nowy pracownik zdobywa twoje zaufanie z czasem; agent musi je zdobywać przy każdym zadaniu poprzez system, który zaprojektowałeś. Odpowiedzialność nie jest czymś, w co agent się rozwija, jest wbudowana od samego początku. Pytanie nie brzmi, kiedy twój agent będzie gotowy na większą odpowiedzialność. Brzmi, czy zaprojektowałeś go tak, aby zdobywał tę odpowiedzialność przy każdym pojedynczym zadaniu.