Panel dyskusyjny podkreślił ciche niepowodzenia, inżynierię harnessów i zarządzanie agentami
19 października 2026 · Czas czytania: 3 min
Dostępne również w Türkçe, Deutsch, Português (Brasil), Nederlands, Svenska
Podczas ostatniego webinaru InfoQ o tytule "AI w produkcji: co się psuje, co działa i kto to zatwierdza" panel seniorów inżynieryjnych analizował praktyczne problemy wdrażania systemów agentowych. Moderatorem była Hien Luu, a panelistami byli Zichuan Xiong i Prem Chandrasekaran z ThoughtWorks, specjalistka prywatności Katharine Jarmul oraz praktyk AI w finansach Lan Chu.
Luu wstępnie wskazała trzy główne czynniki: modele AI nie działają tak jak tradycyjne oprogramowanie, bo generują przekonujące nieścisłości zamiast awarii; asystenci kodujący tworzą kod produkcyjny szybciej niż ludzie mogą go przeglądać; oraz poufne dane mogą wyciekać przez prompty, okna kontekstowe i pobrane dokumenty.
Xiong zwrócił uwagę na powszechny problem "drift semantyczny" w pipeline'ach LLM. Opisał, jak agenty tłumaczące tekst na SQL często spłaszczają koncepcje specyficzne dla domen, np. traktując "członka" identycznie w sprzedaży i obsłudze klienta, co prowadzi do ukrytych błędów w analizie biznesowej, które omykają standardowe monitorowanie.
Chu opowiedziała o krytycznym niepowodzeniu spowodowanym "driftem embedding" w systemach zgodności finansowej. Po wdrożeniu agenta blokującego niezalecane porady inwestycyjne oparte na progach podobieństwa wektorowego, niezgłoszone aktualizacje modelu zmieniły rozkład odległości wektorowych. Skutkiem tego były gwałtowne fale fałszywych pozytywów i fałszywych negatywów w ruchu na żywo, podczas gdy wszystkie kontrole infrastruktury pokazywały zielone światło.
Chandrasekaran podkreślił, że pipeline'y RAG mogą nieświadomie pobierać poufne dokumenty, a modele wrodzenie zapamiętują dane treningowe i mogą deanonimizować informacje lub ujawniać klucze API. Odwołał się także do podatności GitSpawn, pokazując, jak złośliwe konfiguracje repozytoriów mogą wykonywać nieautoryzowany kod podczas rutynowych poleceń.
W miarę jak asystenci kodujący generują coraz większą część kodu produkcyjnego, tradycyjne procesy przeglądu ręcznego stają się nieudźwignione. Chandrasekaran, lider usług technicznych i biznesowych w ThoughtWorks, podkreślił, że przegląd linii kodu nie jest w stanie nadążyć za szybkością wyjść agentów. Dlatego zespoły muszą automatyzować kontrolę stylu i składni w pipeline'ach CI/CD, pozostawiając ludzkie nadzorowanie dla wysokiego poziomu architektury, intencji biznesowej i wymagań niefunkcjonalnych.
Xiong dodał, że zespoły powinny przesuwać ocenę intencji w lewo, czyli sprawdzać ją na poziomie harnessa przed wygenerowaniem pull requestu. Chandrasekaran również podkreślił powrót testowania mutacyjnego jako kluczowej praktyki. Introdukując świadome mutacje kodu, można sprawdzić, czy automatyczne testy naprawdę oceniają logikę, czy jedynie spełniają powierzchowne kryteria pokrycia.
Chu podkreśliła, że oceny agentów powinny być postrzegane jako trwałe, żywe elementy infrastruktury, a nie jednorazowe listy kontrolne przed premierą. Efektywna ocena wymaga ciągłego śledzenia online na poziomie spanów, filtrowania logów i wykorzystywania modeli do klasyfikacji wzorców niepowodzeń, co pozwala zespołom wprowadzać przypadki brzegowe z produkcji z powrotem do zestawów benchmarków offline.
Jarmul ostrzegła przed poleganiem wyłącznie na inżynierii promptów jako środku ochrony. Zaleciła systematyczne red teaming, ciągłe modelowanie zagrożeń, definiowanie ściśle określonych zakresów funkcjonalnych dla autonomicznych agentów oraz skalowanie obserwacji, aby radzić sobie z rosnącą liczbą zdarzeń. Chandrasekaran zasugerował, że każdy agent AI powinien być traktowany jak nowy pracownik inżynieryjny, z odrębną tożsamością nieczłowieczą, kontrolą dostępu podzieloną na operacje tylko do odczytu i odwracalne zapisy, wersjonowanie zależności MCP oraz izolowaniem kluczy API w sandboxach.
W końcu, choć zespoły bezpieczeństwa, inżynierii i prywatności muszą potwierdzić, że zastosowane zabezpieczenia są wystarczające, ostateczna decyzja o wdrożeniu pozostaje decyzją strategiczną biznesu.