Agentyczne przepływy pracy, które się nie psują: wywoływanie narzędzi, działanie człowieka w pętli i połączenia między systemami

Automatyzacja procesów biznesowych i agent AI są sprzedawane jako to samo, ale tak nie jest. Automatyzacja to stały proces: krok drugi zawsze następuje po kroku pierwszym w ten sam sposób. Agent to pętla, w której model decyduje, który krok będzie następny, na podstawie tego, co właśnie zwróciło wywołanie narzędzia. Obydwa mają swoje miejsce — większość tego, czego tak naprawdę potrzebuje firma, to automatyzacja z jednym lub dwoma agentowymi punktami decyzyjnymi, a nie agent wykonujący każdą rozmowę.

Architektura leżąca u podstaw każdego z nich decyduje o tym, czy przetrwa on kontakt z rzeczywistymi danymi: w jaki sposób dostarczasz kontekst modelu, w jaki sposób otrzymujesz odpowiedź w kształcie, któremu Twój kod może zaufać, w jaki sposób model dociera do innych systemów i gdzie dana osoba wciąż musi się zgodzić. To właśnie hydraulika, a nie wybór modelu, jest tym, na czym poświęcam większość projektu.

1. Inżynieria kontekstu: podawanie modelowi odpowiedniego fragmentu, a nie wszystkiego

Inżynieria kontekstu to mało efektowna praca polegająca na decydowaniu, co model widzi podczas danego wywołania – jakie nagrania, jakie wcześniejsze zwroty, jakie instrukcje – i, co równie ważne, czego nie widzi. Wrzucanie za każdym razem całej historii klienta lub pełnego dokumentu do podpowiedzi nie jest dokładnością; to hałas odsuwa faktyczne pytanie od uwagi modela i cicho zawyża koszty każdej rozmowy.

Wzorzec, który się utrzymuje, jest bliższy problemowi wyszukiwania niż problemowi z pamięcią: pobierz dwa lub trzy rekordy istotne dla tego konkretnego kroku, podsumuj to, co wydarzyło się wcześniej, zamiast dosłownie odtwarzać to i pozwól agentowi poprosić o więcej tylko wtedy, gdy tego potrzebuje. Przepływ pracy, który niezawodnie wyciąga pięć właściwych linii z dziesięciu tysięcy, bije taki, który wpycha wszystkie dziesięć tysięcy i ma nadzieję.

2. Ustrukturyzowane wyjścia i wywoływanie narzędzi/funkcji to rzeczywisty interfejs

Model, który odpowiada w postaci dowolnego tekstu i jest analizowany za pomocą wyrażenia regularnego, to sytuacja, w której kompilacje te po cichu zawodzą w produkcji. Ustrukturyzowane dane wyjściowe — schemat JSON, na który model musi odpowiedzieć w środku, oraz wywołanie narzędzia/funkcji — model żądający określonej funkcji z wpisanymi argumentami zamiast opisywać akcję w prozie — pozwalają Twojemu kodowi ufać odpowiedzi na tyle, aby móc na niej działać bez konieczności ponownego czytania każdego wyniku przez człowieka.

Sprawdzam poprawność schematu na wyjściu z modelu i ponownie, zanim dotrze on do rzeczywistego systemu, ponieważ model może wygenerować poprawną składniowo liczbę JSON, która nadal jest błędna w przypadku danej reguły biznesowej – ilość ujemna, data z przeszłości, waluta, której konto nie obsługuje. Schemat wychwytuje błędy kształtu; druga, nudna warstwa walidacji wychwytuje te, które są prawidłowe JSON i nadal błędne.

3. Osadzania i baza danych wektorowych - tylko wtedy, gdy właściwym zadaniem jest wyszukiwanie

Osadzania i baza danych wektorów zyskują swoje miejsce, gdy zadanie jest rzeczywiście pobierane: znajdź trzy zgłoszenia pomocy technicznej najbliższe temu nowemu, znajdź klauzulę w umowie najbliższą temu pytaniu. Są niewłaściwym narzędziem w przypadku stałego, małego zestawu rekordów, na które odpowiada już normalne zapytanie do bazy danych — widziałem wektorową bazę danych powiązaną z przepływem pracy mającym jedenaście możliwych kategorii, w przypadku których tabela przeglądowa byłaby szybsza, tańsza i łatwiejsza do debugowania.

Jeśli jest to właściwe narzędzie, częścią, która faktycznie wymaga uwagi, nie jest model osadzania — chodzi o to, co jest dzielone na kawałki, w jaki sposób i jak świeży pozostaje indeks po zmianach dokumentu źródłowego. Przeszukiwanie wektorów nieaktualnych fragmentów daje pewną, błędną odpowiedź, a nic w wynikach agenta nie informuje, że tak się stało.

4. Orkiestracja typu „człowiek w pętli” i API: tam, gdzie faktycznie się psuje

Najczęstszą porażką, którą widzę, nie jest złe rozumowanie modelu – jest to połączenie dwóch systemów: wywołanie API, którego limit czasu upływa, a agent ponawia je dwukrotnie, wysyłając zduplikowane zamówienie; webhook uruchamiany przed zakończeniem zapisu w poprzednim kroku; wywołanie narzędzia, które zakończyło się sukcesem po stronie dostawcy, ale odpowiedź otrzymana przez agenta mówi, że nie powiodło się. Organizowanie połączeń w CRM, rozliczeniach i poczcie e-mailowej oznacza decydowanie, co się stanie w przypadku przekroczenia limitu czasu lub częściowej awarii, zanim stanie się to w środowisku produkcyjnym, a nie później.

Wszystko, co wysyła pieniądze, usuwa rekord lub wysyła e-maile do klienta, przed uruchomieniem przechodzi etap potwierdzenia przez człowieka — nie dlatego, że model jest ogólnie niegodny zaufania, ale dlatego, że koszt błędnej automatycznej akcji jest asymetryczny z kosztem jednego dodatkowego kliknięcia. Wolałbym, żeby ktoś zatwierdzał dwadzieścia poprawnych działań dziennie, niż żeby agent automatycznie wysyłał jedną błędną fakturę.

Wniosek: agent to łatwe 10%

Wybór modelu i napisanie pierwszego monitu to naprawdę łatwa część agentycznego przepływu pracy. Kontekst, który jest wprowadzany, schemat, który jest sprawdzany, wyszukiwanie wektorów, które działa tylko wtedy, gdy powinno, logika ponawiania prób w trzech interfejsach API i jeden krok, który człowiek nadal akceptuje – to pozostałe 90% i to decyduje, czy automatyzacja będzie nadal działać we wtorek za sześć miesięcy od teraz z danymi, których nikt nie testował. Napisz w formularzu, jaki proces chcesz zautomatyzować, a powiem Ci, które 10% to agent, a które 90% to część, która faktycznie wymaga zbudowania.