← Powrót do Insights

Wielu zespołom technologicznym w przedsiębiorstwach proponuje się dziś rozwiązania agentowe — autonomiczne, niezmordowane, o krok od przekształcenia wszystkiego. Propozycje łączy jedna właściwość: opisują, czym agenci mogliby się stać, a nie to, co sprawia, że działają. Tymczasem praktyczne pytanie pozostaje bez odpowiedzi: czy dla tego procesu, w tej organizacji, agent jest właściwym narzędziem?

Is the task bounded?noDeterministic workflowyesTools & permissions definable?noHuman processyesFailures recoverable & observable?noAutomate + human approvalyesAgentic workflow

Czym agent naprawdę jest

Budując i operując procesami agentowymi w naszej własnej, codziennej pracy, nasze stanowisko jest konkretne: agenci zasługują na swoje miejsce przy zadaniach ograniczonych, ze zdefiniowanymi narzędziami, uprawnieniami, obserwowalnością i punktami zatwierdzania — a deterministyczny skrypt jest lepszą odpowiedzią częściej, niż rynek przyznaje.

Pod warstwą oferty handlowej agent to pętla: model, który czyta kontekst, wybiera spośród narzędzi, które mu dano, działa, obserwuje wynik i kontynuuje aż do warunku zatrzymania. Ta definicja zawiera wszystko, co istotne. Agent jest dokładnie tak zdolny jak jego narzędzia, tak bezpieczny jak jego uprawnienia, tak godny zaufania jak jego warunki zatrzymania i tak debugowalny jak jego ślady.

Nie jest cyfrowym pracownikiem. Pracownika można zapytać, co się stało; agenta bez śladów wykonania — nie. Pracownik uczy się granic organizacji; agent ma dokładnie te granice, które ktoś skonfigurował, i żadnych innych. Nazywanie go pracownikiem zachęca organizację do pominięcia inżynierii, która czyni go bezpiecznym.

Test dopasowania

Cztery pytania przewidują, czy proces nadaje się do wykonania agentowego:

  • Czy zadanie jest ograniczone? Zdefiniowana praca z rozpoznawalnym stanem końcowym — posegreguj ten ticket, przygotuj ten szkic, uzgodnij te rekordy. Mandaty otwarte („popraw naszą dokumentację") produkują zachowania otwarte.
  • Czy powierzchnia narzędzi jest jawna? Potrzebne działania powinny dać się wyliczyć: czytaj te systemy, pisz do tego, wywołuj te API. Jeśli uczciwa lista narzędzi brzmi „co się okaże potrzebne", proces nie jest zrozumiany na tyle, by go automatyzować — jakąkolwiek metodą.
  • Czy działania są odwracalne — albo bramkowane? Szkice, sugestie i zmiany w stagingu są tanie do cofnięcia. Płatności, usunięcia, wysyłki do klientów — nie; potrzebują punktu zatwierdzenia przez człowieka zaprojektowanego w workflow, nie doklejonego po fakcie.
  • Czy weryfikacja jest tańsza niż wykonanie? Agenci mają wartość, gdy sprawdzenie wyniku zajmuje minuty, a wyprodukowanie go zajmowało godziny. Gdy weryfikacja kosztuje tyle co praca — niuansowe osądy, poprawność wysokiej stawki — agent nie oszczędza nic i dodaje tryb awarii.

Proces, który przechodzi wszystkie cztery, jest kandydatem. Jeśli kilka kryteriów zawodzi, deterministyczny workflow lub proces ręczny jest zwykle bezpieczniejszym punktem wyjścia.

Gdzie pomagają

Schematy przechodzące test w praktyce są spójne: segregacja i kierowanie — czytanie przychodzących ticketów, klasyfikacja, wzbogacanie kontekstem z systemów wewnętrznych, kierowanie z rekomendacją; szkice do przeglądu — dokumenty, odpowiedzi, analizy przygotowane dla człowieka, który zatwierdza; wyszukiwania wielosystemowe — odpowiadanie na pytania, których dowody żyją w repozytoriach, wiki i trackerach; oraz workflow inżynieryjne — wsparcie review, scaffolding testów, utrzymanie dokumentacji, gdzie wynik i tak weryfikują CI i reviewerzy.

Wspólny kształt: agent wykonuje pracę przemierzania i składania, która pochłania ludzkie godziny, a człowiek — lub automatyczna kontrola — jest właścicielem decyzji niosącej skutki.

Gdzie nie

Ten sam test wyklucza przypadki pokazowe: działania nieodwracalne bez bramek — wszystko, co dotyka pieniędzy, danych produkcyjnych lub klientów, gdzie punkt zatwierdzania „spowalnia demo"; cienka weryfikacja — wyniki, których nikt nie umie sprawdzić wydajnie, zamieniające automatyzację w odroczone ryzyko; ścieżki krytyczne dla compliance — gdzie „model dziś wybrał inaczej" to uwaga z audytu, determinizm jest wymogiem, nie ograniczeniem; oraz procesy, których nikt nie umie wyspecyfikować — agent nie zastępuje zrozumienia workflow. Automatyzacja procesu, którego nie umieją Państwo opisać, produkuje zautomatyzowane zachowanie, którego nie umieją Państwo przewidzieć.

Alternatywa deterministyczna

Dla zaskakującej części proponowanych zastosowań uczciwy przegląd architektury kończy się zdaniem: to jest silnik workflow i dwie integracje. Jeśli kroki są znane, rozgałęzienia wyliczalne, a wejścia ustrukturyzowane, deterministyczny pipeline jest tańszy w budowie, z reguły bardziej przewidywalny w działaniu i zachowuje się za każdym razem tak samo — co audytorzy, operatorzy i systemy niżej w łańcuchu zgodnie wolą.

Praktyczny wzorzec jest hybrydowy: deterministyczny pipeline dla znanej ścieżki, agent dla kroku, który naprawdę wymaga czytania i osądu — klasyfikacji nieuporządkowanego wejścia, składania kontekstu z nieustrukturyzowanych źródeł — i bramki zatwierdzania tam, gdzie się spotykają. Modelu używa się tam, gdzie wejście jest nieuporządkowane; pipeline'u tam, gdzie proces jest znany.

Nadzór jest architekturą

W użyciu enterprise kwestie nadzoru nie są narzutem compliance doklejonym do agenta — one są architekturą agenta: własna tożsamość z dostępem według najmniejszych uprawnień, nigdy pożyczona prywatna credential; jawny, odwoływalny kontrakt narzędzi; ślady każdego kroku — co przeczytano, co wywołano, co wróciło; punkty zatwierdzania tam, gdzie działania nabierają skutków; i właściciel, który przegląda, co agent naprawdę robi, i za to odpowiada.

Agent o tych właściwościach to infrastruktura. Bez nich to nieaudytowany proces z dostępem do produkcji — co nie jest nową kategorią ryzyka, tylko starą pod nową nazwą.

Awarie i odzyskiwanie

Wieloetapowe workflow zawodzą w locie: narzędzie przekracza limit czasu na kroku siódmym z dwunastu, model zwraca coś bezużytecznego, system zewnętrzny zmienia kształt. Produkcyjne systemy agentowe traktują to jako normalną operacyjność — checkpointy stanu, by workflow wznawiały się zamiast startować od zera; kroki idempotentne, by retry był bezpieczny; zdefiniowana eskalacja, by zablokowany workflow trafił do człowieka; i obserwacja wzorców awarii, bo rosnący współczynnik retry to wczesny sygnał, że coś powyżej się zmieniło.

Demo nigdy nie pokazuje awarii na kroku siódmym. Produkcja składa się właśnie z nich.

Test dopasowania agenta

  • Czy zadanie jest ograniczone, z rozpoznawalnym stanem końcowym?
  • Czy powierzchnia narzędzi jest jawna i możliwa do wyliczenia?
  • Czy działania są odwracalne — albo bramkowane punktem zatwierdzenia przez człowieka?
  • Czy weryfikacja wyniku jest tańsza niż jego wykonanie?

Powiązane kompetencje