Inżynieria uprzęży: środowisko zapewniające niezawodność agentów AI

Jeśli powierzyć wybitnemu inżynierowi zadanie bez narzędzi, dokumentacji, kontroli bezpieczeństwa oraz możliwości weryfikacji wyniku, rezultat będzie nieprzewidywalny. Model językowy o dużej mocy, używany jako agent, znajduje się w takiej sytuacji. Inżynieria wykorzystania to dziedzina, która to rozwiązuje: projektuje całe środowisko, w którym działa agent, włączając narzędzia, pamięć, zasady bezpieczeństwa, pętle zwrotne oraz sandboxy do wykonywania zadań.

Formuła robocza brzmi: Agent = Model + Harness. Model odpowiada za rozumowanie i podejmowanie decyzji. Wszystko inne stanowi element harness: sposób połączenia narzędzi, pamięć, środowiska testowe, zasady bezpieczeństwa, selekcja kontekstu, struktury planowania oraz pętle zwrotne, które zapewniają niezawodność i bezpieczeństwo agenta produkcyjnego. Databricks wyraża to w ten sposób: bez harness model może odpowiadać na pytania, ale nie może w sposób niezawodny uruchamiać kodu, wywoływać API, uzyskiwać dostęp do plików, pamiętać wcześniejsze działania ani samodzielnie kończyć wieloetapowych procesów.

To podejście stanowi trzeci krok w rozwoju. Inżynieria promptów pytała, co powiedzieć. Inżynieria kontekstu pytała, jakie informacje dostarczyć. Inżynieria harness pyta, jaki system zbudować.

Sześć komponentów harness

Prace z branży wskazują na mniej więcej następujące elementy:

1. Integracja narzędzi, która łączy model z zewnętrznymi API, bazami danych, narzędziami do wykonywania kodu oraz specjalistycznymi narzędziami poprzez określone protokoły.
2. Pamięć i stan, podzielone na kontekst roboczy, stan sesji oraz pamięć długoterminową, które przetrwają poza oknem kontekstowym.
3. Zarządzanie kontekstem i promptem, które dynamicznie dobiera to, co ma się pojawić przy każdym wywołaniu modelu.
4. Planowanie i dekompozycja, polegające na prowadzeniu modelu przez ustrukturyzowane sekwencje zamiast żądania wszystkiego za jednym razem.
5. Weryfikacja i zasady bezpieczeństwa, obejmujące sprawdzanie poprawności, weryfikację formatu, filtry bezpieczeństwa oraz pętle samokorygujące.
6. Modularność, oznaczająca, że komponenty mogą być włączane, wyłączane lub zastępowane niezależnie.

Dlaczego to ma znaczenie

Agenci pojawiają się wszędzie – od botów wsparcia, przez asystentów do analizy finansowej, aż po autonomiczne narzędzia do programowania. Większość z tych rozwiązań zawodzi w praktyce z powodu kruchej, niesecurej lub nieprzewidywalnej architektury, a nie dlatego, że leżący u jej podstaw model językowy jest słaby. Cztery powody wyjaśniają ten fakt:

• Przenosi on pracę z fazy nadziei na fazę inżynierii. Zamiast przypadkowego programowania i liczenia na szczęście, strukturalne ograniczenia oraz deterministyczna informacja zwrotna sprawiają, że wyniki są przewidywalne i powtarzalne.
• Łagodzi obciążenie związane z przeglądaniem. Dobra architektura zwiększa szanse na poprawny pierwszy próbny wynik, a także umożliwia naprawę jak największej liczby problemów przed tym, jak człowiek je zauważy.
• Umożliwia prawdziwą autonomię. Bez niej agent to jedynie udoskonalony chatbot. Z nią może on uruchamiać kod, korzystać z API, czytać pliki, pamiętać wcześniejsze działania i kończyć wieloetapowe procesy.
• Przekształca to agenty w rozwiązania gotowe do użycia w produkcji. Birgitta Böckeler, pisząc na stronie Martina Fowlera, opisuje dwa rodzaje kontroli: przewodniki, które są kontrolami typu feedforward kierującymi agentem przed podjęciem działania, oraz czujniki, które są kontrolami typu feedback pomagającymi mu korygować błędy po podjęciu działania. To połączenie odróżnia agenty demonstracyjne od tych używanych w produkcji.

Pętla w centrum

Większość agentów działa w ramach cyklu: rozumowanie, działanie, obserwacja:

1. Rozumowanie: model analizuje wszystko w kontekście (zadanie, pamięć, poprzednie wyniki) i wybiera następne działanie.
2. Działanie: narzędzie realizuje to działanie, na przykład wywołując narzędzie, uruchamiając kod w izolowanej środowisku, korzystając z API lub zapisując coś w pamięci.
3. Obserwacja: narzędzie przechwytuje wynik i zwraca go modelowi jako nowy kontekst.
4. Cykl się powtarza, a model wykorzystuje ten wynik do ponownego wyboru działania.

Główną zasadą projektowania jest klarowne rozdzielenie obowiązków. Model proponuje rozwiązania, natomiast narzędzie je wdraża, sprawdzając schematy, uprawnienia, budżety oraz zasady bezpieczeństwa. Model nigdy nie wywołuje narzędzi bezpośrednio – zwraca zapytanie w uporządkowanej formie, a narzędzie je waliduje, autoryzuje, uruchamia i wprowadza uzyskany wynik. Dzięki temu rozdzieleniu agenci pozostają bezpieczni i poddawalni audytowi: wszystkie działania są rejestrowane, awarie nadal dają uporządkowany wynik, a poziom ryzyka decyduje o ścieżce wykonywania zadań.

Pochodzenie terminu

Historia tego terminu jest krótka.

• Od 2022 do 2024 roku panowała era promptów. Programiści spędzali niezliczone godziny na formułowaniu zapytań, ich strukturze oraz przykładach, aby uzyskać lepsze wyniki.
• W połowie 2025 roku uwaga przeniosła się na kontekst. To, co widzi model, ma takie samo znaczenie jak sposób zadawania pytań, dlatego na pierwszy plan wysunęło się pobieranie informacji, ich kompresja oraz zarządzanie oknem kontekstowym.
• 5 lutego 2026 roku Mitchell Hashimoto, współzałożyciel HashiCorp i twórca Terraform, opublikował post opisujący pewne nawyki: za każdym razem, gdy agent popełniał błąd, wprowadzał trwałe rozwiązanie do jego środowiska, dzięki czemu ten konkretny błąd stawał się strukturalnie niemożliwy do wystąpienia. Nazwał to „inżynierią uprzęży”, mówiąc mniej więcej tak: za każdym razem, gdy agent popełnia błąd, poświęć czas na opracowanie rozwiązania, aby już nigdy w ten sposób nie pomylił się.
• 11 lutego OpenAI opublikowało obszerne opracowanie inżynieryjne na temat tworzenia i wdrażania produktu bez kodu napisanego ręcznie, co potwierdziło słuszność tego podejścia.
• W marcu Anthropic opublikowało dalsze opracowanie opisujące kompletną architekturę uprzęży składającej się z trzech agentów, a Thoughtworks, Databricks, Red Hat, LangChain oraz inne firmy wydały szczegółowe przewodniki. Termin ten już się ustalił.

Zasady, które pozostają aktualne

1. Model proponuje, a silnik wykonuje. Nigdy nie pozwól, by LLM bezpośrednio wywoływał narzędzia. To rozdzielenie stanowi podstawę bezpiecznego projektowania agentów.
2. Każde wezwanie narzędzia przynosi wynik, nawet w przypadku niepowodzenia. Sukces, odmowa dostępu oraz przekroczenie czasu oczekiwania powinny trafić do agenta jako ustrukturyzowane obserwacje. Ciche niepowodzenia są wrogiem autonomii.
3. Ryzyko zmienia proces. Użyj co najmniej trzech poziomów: operacji tylko do odczytu, które działają samodzielnie, projektów symulujących pracę bez zewnętrznych efektów ubocznych oraz zapisów zewnętrznych wymagających zatwierdzenia.
4. Zbieraj kontekst, ale nie wylewaj go wszystkiego naraz. Zamiast wkładać całą rozmowę do każdego kroku, układaj go warstwowo: polityki na poziomie systemu, instrukcje dostosowane do konkretnego zadania oraz wskazówki pobierane w odpowiednim momencie. Oznacz dane niewiarygodne jako takie.
5. Przydziel budżety długim zadaniom. Każdy cykl wymaga ograniczeń dotyczących liczby kroków, czasu trwania, tokenów (na ruch i łącznie) oraz kosztu w dolarach.
6. Przekształć powtarzające się błędy w funkcje narzędzia. Jeśli narzędzie ciągle zwraca niepoprawne odpowiedzi, drobna modyfikacja instrukcji nie jest właściwym rozwiązaniem. Napisz walidator w narzędziu, gdzie powinny znajdować się trwałe naprawy.
7. Łącz czujniki obliczeniowe z czujnikami inferencyjnymi. Lintery, sprawdzacze typów i narzędzia do testowania dostarczają szybkich i niezawodnych informacji zwrotnych. Przegląd kodu przez AI oraz użycie LLM jako sędziego zajmują się kwestiami semantycznymi, których nie potrafią rozwiązać narzędzia deterministyczne. Najskuteczniejsze zespoły przykładają wagę do ograniczeń deterministycznych, które zapewniają gwarancje.
8. Zarządzaj entropią. Kod generowany przez AI z czasem gromadzi nieuporządkowanie, dlatego uruchamiaj okresowo agenty czyszczące w celu zapewnienia spójności dokumentacji, skanowania naruszeń ograniczeń, egzekwowania wzorców oraz przeprowadzania audytów zależności.
9. Zacznij od prostoty. Rada Philippa Schmida brzmi: unikaj skomplikowanych struktur sterowania, zamiast tego dostarcz solidne, samodzielne narzędzia, pozwól modelowi tworzyć plan i dodaj mechanizmy kontroli, próby ponowne oraz weryfikację. Ciężka lekcja polega na tym, że procesy wymagające rozbudowanego ręcznego programowania w 2024 roku są często obsługiwane za pomocą jednego promptu już w 2026 roku, dlatego narzędzia powinny być projektowane tak, by wczorajsza sprytna logika mogła zostać usunięta, gdy tylko model nadrobi zaległości.

Trzy filary

Część praktyków organizuje pracę wokół trzech filarów zamiast sześciu komponentów:

• Inżynieria kontekstu: dostarczanie agentowi odpowiednich informacji we właściwym momencie, łączenie statycznych dokumentów z aktualnymi danymi z obserwacji.
• Ograniczenia architektoniczne: zapewnienie wysokiej jakości kodu za pomocą maszyn, poprzez warstwowe zależności, narzędzia do sprawdzania kodu, testy strukturalne oraz hooki typu pre-commit.
• Zarządzanie entropią: planowane czyszczenie, aby bazy kodu napisane przez AI nie ulegały degradacji.

Tani trik o dużym efekcie

LangChain doniosło, że sama zmiana na poziomie narzędziowego zestawu sprawiła, iż ich wynik w Terminal Bench 2.0 wzrósł z 52,8% do 66,5%, co oznaczało przejście z poza czołowej 30 na pozycje w pierwszej 5. Zmiana ta polegała na zastosowaniu strategii „kanapki rozumowania”: dużego wysiłku intelektualnego przy planowaniu i weryfikacji oraz umiarkowanego wysiłku przy implementacji. Model pozostał nietknięty, co pokazuje, jak daleko mogą zajść zmiany dotyczące wyłącznie narzędzi. Stopień zaawansowania tych narzędzi znacznie się różni wśród obecnych czołowych agentów programistycznych.

Wniosek końcowy

Pytanie przesunęło się od tego, jak lepiej formułować polecenia, na to, jaki system należy stworzyć. Modelem nie jest już produkt, lecz narzędzie do jego obsługi. To właśnie to narzędzie odróżnia imponującą, kontrolowaną demonstrację od systemu produkcyjnego, który funkcjonuje w rzeczywistym świecie, dlatego każdy, kto w 2026 roku buduje agenty, potrzebuje go. Praktycznym pierwszym krokiem jest przeanalizowanie obecnej konfiguracji pod kątem sześciu komponentów i dziewięciu zasad opisanych powyżej, zidentyfikowanie brakujących elementów i włączenie ich do tego narzędzia.