Rok 2025 może być rokiem agentów AI, jeśli przetrwają piekło przedsiębiorstw

Przez dziesięciolecia firmy starały się automatyzować zadania back-office, wprowadzanie danych, procesy rozliczeniowe i inne powtarzalne przepływy pracy. Jednak nawet w miarę rozwoju oprogramowania prawdziwa automatyzacja typu end-to-end pozostaje nieuchwytna dla większości przedsiębiorstw. Teraz, wraz z szybkim wzrostem modeli języka dużego (LLM) i pojawieniem się „agentów AI” zdolnych do rozumowania i działania autonomicznego, rośnie przekonanie, że 2025 r. może być rokiem, w którym w końcu zobaczymy znaczący krok naprzód w automatyzacji przedsiębiorstw.

Sam Altman publicznie oświadczył , że „w 2025 r. możemy zobaczyć pierwszych agentów AI dołączających do siły roboczej i istotnie zmieniających wyniki firm”, podczas gdy Marc Benioff przestawia Salesforce w kierunku „AgentForce” w oczekiwaniu na przyszłość, w której wiele procesów organizacyjnych jest delegowanych wyspecjalizowanym agentom. Te prognozy rodzą centralne pytanie: czy agenci AI pokonają skomplikowane przeszkody rzeczywistych systemów przedsiębiorstw? W tym artykule przyjrzymy się wyjątkowym trudnościom automatyzacji przedsiębiorstw i przyjrzymy się niektórym z dzisiejszych obiecujących (ale wciąż dojrzewających) rozwiązań. Podzielimy się również praktycznymi testami pozornie prostego przepływu pracy w Salesforce (SFDC) — tworzenia zamówienia resellera dla nowego konta — który ujawnia złożoność kryjącą się za kulisami.

Dlaczego automatyzacja przedsiębiorstw jest tak trudna?

Na papierze automatyzacja zadań przedsiębiorstwa brzmi prosto: uruchom skrypt, aby się zalogować, wypełnić formularze i kliknąć „prześlij”. W praktyce złożoność jest oszałamiająca. Przedsiębiorstwa polegają na niezliczonej liczbie systemów rekordów, takich jak Salesforce, SAP, Oracle i wielu rodzimych rozwiązaniach. Każdy system ma własną sieć uprawnień, przepływy uwierzytelniania i niestandardową logikę biznesową. Co więcej, te systemy są często mocno dostosowane. Często można zobaczyć wyspecjalizowane interfejsy użytkownika, dodatkowe pola danych i niestandardowe przepływy pracy, które różnią się w zależności od firmy.

Według wspólnego badania przeprowadzonego przez MuleSoft i Deloitte, duże przedsiębiorstwa mogą używać średnio 976 różnych systemów do obsługi codziennych operacji ( źródło ). Ta fragmentacja oznacza, że narzędzie automatyzacji musi komunikować się z wieloma systemami, z których każdy ma swoje własne niuanse; niektóre z solidnymi interfejsami API, inne bez żadnych. Często najprostsze zadania obejmują łączenie danych w starych, starszych aplikacjach i nowych usługach w chmurze. Nawet standardowe platformy, takie jak Salesforce, mogą stać się labiryntowe, gdy wdrożone zostaną niestandardowe przepływy pracy i integracje z rozwiązaniami innych firm.

Na tym tle agenci zasilani przez LLM obiecują bardziej elastyczne podejście: potrafią analizować dane, wnioskować o kolejnych krokach, a nawet poruszać się po skomplikowanych interfejsach graficznych — przynajmniej w teorii. Ale jak zobaczysz w poniższym przykładzie, rzeczywistość sprawienia, aby agent AI wykonał nawet podstawowy przepływ pracy Salesforce bez pomocy człowieka, jest bardziej skomplikowana, niż wielu zdaje sobie sprawę.

Przykład praktyczny: Tworzenie niestandardowego zamówienia resellera w Salesforce

Zadanie

Wyobraź sobie, że jesteś sprzedawcą w firmie produkującej rowery, która używa Salesforce. Właśnie sprzedałeś 1 duży rower Dynamo X1 za 5000 USD nowemu sprzedawcy o nazwie „Northern Trail Cycling”. Twoim zadaniem jest:

1 - Uwierzytelnij się w Salesforce (przy użyciu podanych danych uwierzytelniających).

2 - Utwórz nowe konto dla sprzedawcy.

3 - Utwórz zamówienie u dystrybutora i dodaj pozycję zamówienia (rower).

4 - Prześlij zamówienie do działu produkcji w celu zatwierdzenia.

Aby realizacja zakończyła się sukcesem, spodziewamy się, że końcowy rezultat będzie wyglądał następująco:

Wydaje się to wystarczająco proste, ale diabeł tkwi w szczegółach. Instancja Salesforce firmy jest dostosowana: używa niestandardowego obiektu i przepływu „zamówienia odsprzedawcy”, specjalnej funkcji „przeciągnij i upuść” do dodawania produktów oraz ukrytego kroku „prześlij do produkcji” bez wyraźnego oznaczenia. Przetestowałem ten scenariusz, używając kilku nowych podejść automatyzacji opartych na sztucznej inteligencji, aby sprawdzić, jak się sprawdzają.

Claude Komputer Użytkowanie

Co to jest?

Claude Computer Use to nowa funkcja firmy Anthropic, wprowadzona w Claude 3.5 Sonnet v2 . Posuwa ona standardowy paradygmat wywoływania funkcji LLM o krok dalej, dając Claude całe skonteneryzowane środowisko pulpitu do „widzenia” i „kontrolowania”. Może ona przechwytywać zrzuty ekranu, interpretować je za pomocą rozumowania wizualnego/przestrzennego i wykonywać czynności na poziomie systemu operacyjnego, takie jak kliknięcia myszą, przewijanie i naciśnięcia klawiszy.

Z perspektywy użytkownika, dajesz Claude'owi zadanie wysokiego poziomu („Zaloguj się do Salesforce i utwórz to zamówienie resellera”), a Claude próbuje zrobić dokładnie to. Pętla przechodzi przez sekwencję:

1. Przechwytywanie zrzutu ekranu i jego interpretacja.
2. Wykonywanie akcji interfejsu użytkownika (kliknięcia myszą, naciśnięcia klawiszy, polecenia powłoki Bash).
3. Powtarzanie, aż do ukończenia zadania (lub do rezygnacji).

Poddanie testowi

Zacznijmy od najprostszego podejścia polegającego na uruchomieniu implementacji referencyjnej Anthropic bez żadnych zmian w wierszu poleceń systemu . Oto początek interakcji pokazujący początkowy wiersz poleceń, proponowany plan Claude'a i pulpit, z którym rozpoczyna interakcję.

Obserwacja kontenerowego pulpitu Claude'a początkowo robiła wrażenie. Otworzył przeglądarkę, odwiedził adres URL Salesforce, zalogował się przy użyciu podanych danych uwierzytelniających i przeszedł do „Kont”. Bezbłędnie utworzył nowe konto dla Bike Production Company , wprowadzając właściwe dane w formularzu, a następnie próbował utworzyć nowe zamówienie odsprzedawcy. Wszystko szło gładko, dopóki nie napotkał niestandardowego interfejsu „przeciągnij i upuść” do dodania roweru. System utknął, próbując wykonać przeciąganie i upuszczanie oparte na pikselach.

Po kilku niepowodzeniach, próbował znaleźć alternatywną metodę (jak ukryty przycisk „Dodaj element”). Pierwsza próba z przyciskiem „edytuj” nie powiodła się.

„Zauważyłem, że w oknie dialogowym edycji nie ma jasnego sposobu dodawania produktów. Pozwól mi spróbować innego podejścia, klikając na rozwijane menu Reseller Orders, aby sprawdzić, czy są inne opcje”.

Ostatecznie udało się znaleźć sposób na dodawanie nowych pozycji za pomocą zakładki „powiązane” — tylko po to, by zawieść, gdy dynamiczne wyzwalacze aplikacji nie aktualizowały automatycznie łącznej kwoty zamówienia. Twórcy aplikacji SFDC nie ukończyli opracowywania tej ścieżki kodu, oczekując, że użytkownik po prostu wykona metodę przeciągania i upuszczania. Krótko mówiąc, przepływ został zaprojektowany dla ludzi, a nie dla agenta AI.

Następnie Claude próbował zlokalizować przycisk „prześlij do produkcji”, który był ukryty pod niestandardową zakładką. Ponieważ nie miał wcześniejszej wiedzy na temat tego kroku, błądził przez kilka kolejnych minut. Ostatecznie musiałem interweniować, ręcznie dodać rower do zamówienia i wskazać Claude'owi odpowiedni przycisk. Po około 10 minutach i około 0,80 USD kosztów użytkowania proces nadal nie był w pełni zautomatyzowany. Łatwo było zrozumieć, dlaczego Anthropic nazywa tę funkcję eksperymentalną: wiele rzeczywistych zabezpieczeń i ulepszeń jest potrzebnych, zanim Computer Use będzie mógł być naprawdę gotowy do produkcji.

Czy może być lepiej?

Pomimo niedociągnięć, koncepcja jest ekscytująca. Oparta na wizji sztuczna inteligencja do interakcji GUI szybko się poprawia, a krzywa kosztów wnioskowania szybko spada. Ostatnie badanie a16z sugeruje, że przy tej samej wydajności koszty LLM spadają mniej więcej 10 razy rocznie. Zasadniczo przyszłe wersje Claude mogą stać się szybsze, tańsze i dokładniejsze w zadaniach wizualnych/przestrzennych, takich jak przeciąganie i upuszczanie.

Jednak podstawowym problemem pozostaje to, że interfejsy użytkownika przedsiębiorstw, zwłaszcza starsze lub mocno dostosowane, rzadko są tworzone z myślą o automatyzacji. Interakcje na poziomie pikseli są kruche. Niewielkie zmiany w układzie lub dynamiczne wyskakujące okienka mogą zakłócić cały przepływ. Coraz więcej badań dotyczy również wizualnie ugruntowanych ram GUI, ale uczynienie ich produkcyjnymi dla setek różnych przepływów pracy jest poważnym przedsięwzięciem.

Przeglądarki bez interfejsu graficznego: całkowite pominięcie interfejsu graficznego

Alternatywnym podejściem jest całkowite zignorowanie „wizualnych ramek ograniczających”. Jeśli Twoja aplikacja docelowa działa w przeglądarce internetowej, możesz zautomatyzować ją na poziomie DOM, pomijając zrzuty ekranu i interakcje oparte na pikselach. Podczas gdy tradycyjne przeglądarki bezgłowe, takie jak Playwright i Selenium, są często kojarzone z frameworkami testowymi, pojawia się nowa generacja przeglądarek bezgłowych zorientowanych na przypadki użycia AI. Te nowsze platformy opierają się na Playwright i Selenium, aby umożliwić bardziej dynamiczne interakcje oparte na LLM.

PrzeglądarkaBase

BrowserBase jest jednym z takich przykładów. Działa jako platforma infrastruktury, która hostuje i skaluje sesje przeglądarki bez konieczności zarządzania kontenerami przez programistów. Wzorzec interakcji opiera się na parsowaniu zawartości HTML strony na komponenty (np. formularze, przyciski) mapowane na ich ścieżki xPath i przekazywaniu tej struktury do wybranego przez Ciebie LLM. Następnie LLM generuje następny zestaw kodu Playwright do wykonania, umożliwiając interakcję z DOM za pośrednictwem kodu, a nie tradycyjnych kliknięć GUI. Ponieważ jest całkowicie bezgłowy, używa mniej lub wcale zrzutów ekranu, utrzymując długość kontekstu krótką i opóźnienie niższe niż pełne podejście „środowiska pulpitu”.

Niedawno BrowserBase udostępnił swoją bibliotekę open-source StageHand , aby ułatwić pracę deweloperom. W oryginalnym modelu interakcje były nadal bardzo ręczne, wymagając od deweloperów pracy z niskim poziomem szczegółów przeglądarki bezgłowej, w tym bezpośredniego pisania kodu Playwright i ręcznego analizowania HTML. Dzięki StageHand BrowserBase zapewnia wyższy poziom abstrakcji, umożliwiając deweloperom korzystanie z poleceń języka naturalnego opartych na intencjach, takich jak „navigate” lub „extract”. To podejście obejmuje również pewne przetwarzanie w celu konwersji surowego HTML na komponenty, ułatwiając LLM obsługę zadań. Jednak użytkownicy nadal muszą tworzyć własne warstwy orkiestracji, aby łączyć i zarządzać przepływami pracy, ponieważ sam StageHand nie oferuje wbudowanej orkiestracji.

Aby przetestować BrowserBase, użyłem ich developer playground, który udostępnia konsolę do pisania kodu Playwright i program do pisania poleceń LLM, aby automatycznie tworzyć te skrypty. Pomysł polega na nawigacji wieloetapowej — logowanie, tworzenie konta, tworzenie zamówienia resellera. Jednak platforma oczekuje, że sam zorganizujesz te kroki. Zaczynając od tego samego polecenia podanego Claude'owi, BrowserBase się potknął, ponieważ nie mógł rozumować w sposób wieloetapowy. Więc przystąpiłem do dostarczania poleceń w języku naturalnym dla każdego kroku i obserwowania, czy wygenerowany kod Playwright robi to, co było zamierzone. Na poniższym zrzucie ekranu możesz zobaczyć serię poleceń i wygenerowany przez nie kod Playwright.

W praktyce natrafiałem na sporadyczne rozbieżności między środowiskiem przeglądarki Playground a formularzami HTML, które należało wypełnić. Przyciski renderowały się dziwnie, czasy oczekiwania się wydłużały, a pola formularza nie ładowały się dokładnie tak, jak oczekiwano. Pomimo tych usterek kod Playwright wygenerowany przez LLM zdołał się zalogować, utworzyć konto i częściowo wypełnić formularz zamówienia odsprzedawcy. Jednak przeciąganie i upuszczanie, aby dodać element, znów stanowiło przeszkodę. Spędziłem około siedmiu minut na majstrowaniu przy tym, zanim się poddałem. Było jasne, że platforma nie nadaje się jeszcze do tego typu automatyzacji. Prawdopodobnie najlepiej sprawdza się w przypadkach użycia web scrapingu.

Niebo

Skyvern to bardziej kompleksowe podejście bezgłowe, które domyślnie dodaje orkiestrację. W przeciwieństwie do BrowserBase, które wymaga od użytkowników ręcznego definiowania i zarządzania krokami, Skyvern próbuje obsługiwać orkiestrację od razu. Pod maską działa podobnie do BrowserBase — jak widać w ich kodzie open source — ale dodaje również agenta internetowego, który może orkiestrować i rozumować o krokach. Obejmuje to opcjonalny tryb wizji, który wysyła zrzuty ekranu do LLM wraz z wyodrębnionymi komponentami i ich ścieżkami xPath, aby pomóc w podejmowaniu decyzji.

Aby rozwiązać ograniczenia ręcznego tworzenia kroków w BrowserBase, postanowiłem przetestować Skyvern przy użyciu jego usługi zarządzanej, skupiając się szczególnie na trybie Workflow. Ten tryb jest przeznaczony do procesów wieloetapowych i chciałem ocenić, jak dobrze działa z naszym przepływem pracy Salesforce. Niestety, przebieg spędził ponad 15 kroków rozumowania i 1 USD kredytów utkniętych w procesie uwierzytelniania dwuskładnikowego (2FA). Hostowany adres IP Skyvern został oznaczony, co uruchomiło 2FA, a nie było możliwości ręcznego podania kodu lub udostępnienia pliku cookie w celu obejścia tej sytuacji. Podkreśla to trwające wyzwanie uwierzytelniania w środowiskach korporacyjnych i podkreśla, dlaczego startupy takie jak Anon pojawiają się, aby skupić się wyłącznie na rozwiązaniach uwierzytelniania dla agentów AI.

Zespół Skyvern pozycjonuje platformę jako odpowiednią do prostszych, mniejszych zadań, przy czym automatyzacja formularzy kontaktowych jest głównym obsługiwanym przypadkiem użycia. Inne potencjalne przypadki użycia (np. Jobs, Invoices) są nadal wymienione jako „w trakcie szkolenia”, co wskazuje, że platforma zaczyna od prostej automatyzacji skupionej na przypadkach użycia, a nie bardziej złożonych potrzebach przepływów pracy w przedsiębiorstwie. Choć obiecujące, jest jasne, że Skyvern lepiej nadaje się do mniej skomplikowanych scenariuszy na tym etapie rozwoju.

Kompromisy

Przeglądarki bezgłowe pomijają zgadywanie na poziomie pikseli, co często prowadzi do mniejszej liczby błędów i szybszego wykonywania. Ale gdy tylko trafisz na zaawansowane funkcje, takie jak przeciąganie i upuszczanie lub złożone aplikacje jednostronicowe, może być konieczne powrót do częściowej analizy zrzutów ekranu lub specjalistycznego kodu. Przeglądarki mogą również napotkać 2FA i czarną listę IP. W przypadku aplikacji korporacyjnych z wieloma dzierżawcami samo uwierzytelnianie może być trudne i nadal możesz potrzebować niestandardowych warstw orkiestracji.

Innym ograniczeniem jest to, że platformy te polegają na dynamicznym generowaniu kodu za pośrednictwem LLM za każdym razem, gdy wykonywany jest przepływ pracy. Ponieważ LLM są z natury niedeterministyczne, wygenerowany kod może się różnić w różnych przebiegach, co utrudnia audyt lub weryfikację spójności. Ta nieprzewidywalność może prowadzić do problemów, szczególnie w przypadku wrażliwych przepływów pracy. Podczas gdy buforowanie wygenerowanego kodu wydaje się być na mapie drogowej niektórych platform, stanowi ono poważne wyzwanie dla LLM. Nawet niewielkie zmiany w monicie lub przetwarzaniu wsadowym podczas wnioskowania mogą dawać zupełnie inne wyniki, co komplikuje proces buforowania.

Ogólnie rzecz biorąc, przeglądanie bezgłowe może być tańsze i bardziej stabilne niż pełna manipulacja GUI, ale jest dalekie od magicznego rozwiązania. Wiele rozwiązań, takich jak BrowserBase i Skyvern, koncentruje się na węższych przypadkach użycia (np. formularze, ekstrakcja danych), zamiast być „jedną platformą do automatyzacji wszystkiego”.

Inżynieria wsteczna wewnętrznych interfejsów API

Trzecie podejście polega na całkowitym ominięciu strony internetowej poprzez przechwycenie wywołań sieciowych, które występują, gdy klikasz. Jeśli możesz przechwycić żądania wysyłane przez przeglądarkę, możesz odtworzyć te wywołania w kodzie. Zasadniczo pozwala to uniknąć bałaganu opartego na interfejsie użytkownika i zapewnia, że korzystasz z tej samej logiki zaplecza, której używa Twoja aplikacja. Ten trend nie jest zupełnie nowy, ponieważ interfejsy API do inżynierii wstecznej istnieją od dawna. Jednak nowatorskim dodatkiem jest włączenie agenta AI do rozumowania żądań sieciowych, dzięki czemu proces staje się bardziej inteligentny i elastyczny.

Kilka miesięcy temu na Hackernews pojawił się produkt o nazwie Integuru, który przyciągnął uwagę swoim podejściem open-source i nowatorską metodologią. Zaintrygowany jego potencjałem, postanowiłem go przetestować, przyciągnięty jego interesującym podejściem opartym na grafach i integracją agentów AI w celu rozumowania żądań sieciowych. Obietnica drastycznego skrócenia czasu i kosztów automatyzacji sprawiła, że stała się atrakcyjną opcją do zbadania.

Repozytorium Integuru jest stosunkowo nowe, ale obiecujące. W swojej istocie rejestruje cały ruch sieciowy i pliki cookie w Chromium podczas zadania. Następnie tworzy reprezentację grafową żądań, mapując, które strony wywołują które punkty końcowe. Używając tego grafu, wykonuje przejście, przekazując go do LLM w celu wygenerowania kodu dla każdego węzła, który odtwarza te same żądania, wstrzykując Twoje parametry dynamiczne (takie jak „Bike Production Company”) w razie potrzeby i składając je razem na podstawie zależności. Takie podejście mogłoby teoretycznie znacznie usprawnić proces automatyzacji.

W praktyce jednak nie sprawdziło się to w naszym przypadku użycia, głównie z powodu ograniczeń okna kontekstowego. Przepływ mógł być zbyt długi, aby LLM mógł sobie z nim skutecznie poradzić. Nawet próby obejścia procesu poprzez osadzanie plików cookie logowania bezpośrednio i rozpoczynanie od strony głównej nie powiodły się. Chociaż podejrzewam, że mój klucz API OpenAI niskiego poziomu przyczynił się do tych problemów, jasne jest, że Integuru jest wciąż w powijakach. Potencjał istnieje, ale produkt wymaga dalszego udoskonalenia. Jego dema (takie jak pobieranie dokumentów podatkowych z Robinhood) działały najlepiej w nowoczesnych frameworkach internetowych z prostszymi przepływami. Salesforce, ze swoim skomplikowanym front-endem i labiryntowymi obiektami niestandardowymi, wprowadzał błędy.

Mimo to ta metoda nie jest jeszcze uniwersalnym rozwiązaniem. Konieczność rejestrowania wszystkich kroków ogranicza jej elastyczność i skłania się ku bardziej statycznemu podejściu generowania kodu dla określonych przepływów z wyprzedzeniem, przypominając popularne dekadę temu narzędzia RPA oparte na regułach. Podkreśla to podstawowe ograniczenie: podczas gdy dodanie rozumowania AI do żądań sieciowych jest ekscytujące i może otworzyć drzwi do integracji z systemami, które nie mają interfejsów API, nadal lepiej nadaje się do bardziej kontrolowanych lub powtarzalnych zadań niż do dynamicznych, zróżnicowanych przepływów pracy w środowiskach korporacyjnych.

AgentForce: natywne rozwiązanie Salesforce

Żadna rozmowa o automatyzacji opartej na sztucznej inteligencji w Salesforce nie byłaby kompletna bez wzmianki o AgentForce , wielkim zakładzie Marca Benioffa na tworzenie „agentów” w ekosystemie Salesforce. W przeciwieństwie do innych rozwiązań, które testowaliśmy powyżej, które są skoncentrowane na deweloperach i mają na celu automatyzację przepływów pracy w różnych systemach, AgentForce jest pozycjonowany jako rozwiązanie low-code, osadzone specjalnie dla Salesforce. Łączy wiele komponentów i koncentruje się na całym przepływie w ramach platformy Salesforce.

Pomysł polega na tworzeniu agentów, którzy w pełni rezydują w Salesforce i opierają się na Twoich dostosowaniach. Użytkownicy definiują ogólny opis agenta, przypisują tematy i łączą powiązane akcje, które są wstępnie zbudowanymi przepływami zdefiniowanymi w kodzie lub za pośrednictwem interfejsu użytkownika Salesforce. Następnie konfiguruje się uprawnienia, role użytkowników i instrukcje, aby umożliwić działanie agenta. Ta koncepcja teoretycznie pozwala firmom wykorzystać istniejące dane i przepływy pracy Salesforce do napędzania automatyzacji bez rozległego kodowania.

Chciałem przetestować AgentForce bezpośrednio na naszym przykładzie zamówienia odsprzedawcy eBikes. Niestety, wymagany jest dostęp do Einstein (funkcje AI), który nie jest dostępny na bezpłatnym koncie programisty. Zamiast tego eksplorowałem ich 30-minutowy plac zabaw z fikcyjną aplikacją „Coral Beach Resort”. Zadaniem testowym było skonfigurowanie agenta w celu zautomatyzowania tworzenia rezerwacji, procesu w pewnym sensie analogicznego do zamówienia odsprzedawcy w naszym scenariuszu eBikes.

Konfiguracja była dość skomplikowana, wymagała wielu kroków: definiowania uprawnień, włączania tematów, łączenia się z wstępnie zbudowanymi działaniami, mapowania pól danych i wyjaśniania instrukcji. Podczas gdy reklamowano to jako rozwiązanie low-code, stało się jasne, że konieczna jest znaczna wiedza na temat zawiłości Salesforce. Jeśli instancja Salesforce firmy nie ma dobrze udokumentowanych pól niestandardowych i wstępnie skonfigurowanych przepływów działań, początkowy wzrost może być znaczny. Realistycznie rzecz biorąc, większość firm prawdopodobnie musiałaby zatrudnić integratorów systemów lub konsultantów, aby w pełni wdrożyć i zoptymalizować tych agentów.

Oparta na regułach natura AgentForce również się wyróżniała. Użytkownicy muszą dokładnie mapować, które pola są wypełniane lub przekazywane, aby automatyzacja działała dokładnie, co czyni ją bardziej praktyczną niż niektóre platformy oparte na sztucznej inteligencji. Podczas gdy takie podejście zapewnia precyzję, wzmacnia zależność od silnej wiedzy Salesforce i istniejącej infrastruktury.

Chociaż AgentForce ogranicza się do ekosystemu Salesforce, ma to zarówno zalety, jak i wady. Z jednej strony jest to rozwiązanie pakietowe, które ujednolica uwierzytelnianie, uprawnienia użytkowników, definicje narzędzi i logikę orkiestracji w ramach jednej platformy. Z drugiej strony wiele przepływów pracy w przedsiębiorstwach obejmuje wiele systemów, a wyizolowana natura AgentForce ogranicza jego przydatność do szerszych potrzeb automatyzacji. Marc Benioff stwierdził, że setki klientów podpisało już umowy na korzystanie z AgentForce, więc warto będzie monitorować jego ewolucję.

No więc… Czy już jesteśmy na miejscu?

Z tych eksperymentów jasno wynika, że obecne rozwiązania agentów AI potrafią dobrze rozumować zadania wieloetapowe i tworzyć plany. Prawdziwym wyzwaniem jest wykonanie w chaotycznym, rzeczywistym środowisku z wiedzą plemienną na temat tego, jak te systemy naprawdę się zachowują. Graficzne interfejsy użytkownika zostały stworzone do interakcji z ludźmi, a niestandardowa logika każdego przedsiębiorstwa jest jak miniaturowa czarna dziura złożoności. Nawet jeśli pominiesz GUI na rzecz podejścia bezgłowego lub wykonasz inżynierię wsteczną interfejsów API zaplecza, nadal będziesz napotykać przypadki skrajne, przeszkody uwierzytelniania, ograniczenia szybkości lub dynamiczne przepływy pracy, które zakłócają najlepsze z LLM.

Pozostałe wyzwania to głównie problemy inżynieryjne: budowanie solidnych narzędzi, głęboka integracja z systemami przedsiębiorstwa, ustanawianie zabezpieczeń i tworzenie niezawodnych ram monitorowania i orkiestracji. Można je rozwiązać dzięki zaangażowaniu i specjalizacji. Dzisiejsze LLM-y już wykazują zdolności rozumowania znacznie wykraczające poza to, co było dostępne nawet rok temu, a ich koszt gwałtownie spada. Teraz należy skupić się na konstruowaniu infrastruktury i procesów potrzebnych do skutecznego wdrażania tych zdolności.

Jednak te trudności nie powinny przyćmiewać stałego postępu. Widzimy już wyspecjalizowane, pionowo ukierunkowane automatyzacje AI (np. SDR lub agenci obsługi klienta), które mogą zapewnić wysoką dokładność w kontrolowanej domenie. W miarę dojrzewania każdej z tych automatyzacji jednorazowego użytku możemy zobaczyć, jak są one łączone w szersze przepływy pracy. To może być sposób, w jaki ostatecznie rozbijemy automatyzację end-to-end w dużych przedsiębiorstwach: łącząc wielu wyspecjalizowanych agentów, zamiast oczekiwać, że jeden agent ogólnego przeznaczenia zrobi wszystko. Na razie zwrot z inwestycji w zbudowanie agenta od podstaw może nie pokrywać się ze wszystkimi zadaniami poza tymi o największej objętości.

Specjalizacja i droga naprzód

Jedną z lekcji z tych testów jest znaczenie specjalizacji. Osiągnięcie niemal doskonałej niezawodności w jednej domenie (na przykład tworzenie faktur w NetSuite) wymaga znacznego dostrojenia. Startupy lub wewnętrzne zespoły, które koncentrują się na jednym wyspecjalizowanym przepływie pracy, mogą zapewnić lepsze doświadczenie niż szerokie, ogólne rozwiązanie. Już teraz widzimy falę „agentów pionowych”, którzy zajmują się ukierunkowanymi zadaniami w finansach, logistyce, HR lub łańcuchu dostaw. Każdy agent byłby głęboko zintegrowany, być może łącząc automatyzację interfejsu użytkownika w razie potrzeby z bezpośrednimi wywołaniami API, gdy jest to możliwe, a także domenową logikę zapasową i zabezpieczenia.

Pozostaje wielkie pytanie: czy 2025 r. będzie rokiem, w którym agenci ci naprawdę staną się mainstreamowi, czy też czeka nas dłuższy okres? Technologia rozwija się szybko, a optymizm jest powszechny. Ale tak jak inżynierowie oprogramowania nie zniknęli, gdy generowanie kodu stało się lepsze, prawdopodobnie nie zobaczymy „bezobsługowej” automatyzacji przedsiębiorstw dla wszystkich procesów. Zamiast tego zobaczymy iteracyjne ulepszenia w wyspecjalizowanych kieszeniach, ostatecznie łącząc je w mozaikę częściowych automatyzacji.

Wniosek

Koncepcja autonomicznych agentów AI jest niewątpliwie przekonująca, zwłaszcza w środowiskach korporacyjnych, w których powtarzalne zadania są powszechne. Potencjalne korzyści — oszczędność czasu, redukcja błędów i umożliwienie pracownikom skupienia się na bardziej kreatywnej i strategicznej pracy — są ogromne. Jednak podczas gdy podstawowe możliwości agentów AI są silne, droga do powszechnej adopcji zależy od pokonania wyzwań inżynieryjnych oprócz rozwijania podstawowych badań.

Kluczowe jest zbudowanie odpowiedniej infrastruktury: solidne narzędzia, niezawodne integracje i rozwiązania specyficzne dla domeny z dobrze zdefiniowanymi zabezpieczeniami i warstwami orkiestracji. Złożoność rzeczywistych systemów korporacyjnych wymaga specjalistycznych rozwiązań, a to właśnie w tym zakresie agenci pionowi mogą się wykazać. Skupienie się na wąskich, dobrze zdefiniowanych przepływach pracy pozwala zespołom udoskonalać swoje rozwiązania do wysokiego stopnia dokładności i niezawodności, rozwiązując unikalne wyzwania każdej domeny. Z czasem ci wyspecjalizowani agenci mogliby się ze sobą łączyć, tworząc szerszą sieć automatyzacji.

Rok 2025 może przynieść imponujące postępy i rosnącą liczbę programów pilotażowych. Zamiast świata działającego na autopilocie, bardziej prawdopodobne jest, że zobaczymy ukierunkowane, wysoce skuteczne automatyzacje rozwiązujące konkretne problemy. Podróż w kierunku pełnej automatyzacji przedsiębiorstwa będzie iteracyjna, napędzana specjalizacją i współpracą. Pęd nabiera tempa, a rozwiązanie tych wyzwań inżynieryjnych utoruje drogę dla kolejnej fali innowacji przedsiębiorstw.

(Źródło grafiki: DALL-E)