Managed agents kontra lokalne harnessy agentowe: co warto zachować

Anthropic oraz OpenAI przekształcają infrastrukturę runtime’u dla agentów w powierzchnię produktową: hostowane sesje, sandboxy, śledzenie, pamięć, przekazania (handoffs), rubryki oraz strumienie zdarzeń znajdują się dziś bliżej dostawcy modelu niż prywatnego folderu ze skryptami zespołu.¹²

Jakie są kluczowe wnioski?

• Managed agents stają się warstwą runtime’u. Sesje, sandboxy, ślady (traces), zdarzenia oraz wykonywanie asynchroniczne coraz częściej należą do zarządzanej infrastruktury, o ile dostawca spełnia wymagania bezpieczeństwa zespołu.¹²
• Lokalne harnessy wciąż mają znaczenie. Warto zachować te elementy, które kodują smak, dowody, integralność publikowanych treści, granice prywatności, weryfikację źródeł oraz pamięć projektu.
• Jednostką migracji jest zadanie, nie polecenie. Polecenie z ukośnikiem, skill w Codex, przekazanie w SDK, serwer MCP lub zarządzany outcome mogą obsłużyć ten sam workflow, jeśli kryteria akceptacji zostaną zachowane.
• Nie należy publikować prywatnej maszynerii. Publiczne wpisy powinny wyjaśniać wzorzec i kryteria akceptacji, a nie prywatne prompty, dokładne ciała hooków, dane konta czy wewnętrzne reguły oceny.
• Promocja wymaga dowodu. Należy zacząć w trybie jawnym, uruchomić jedno realne zadanie, zarejestrować rezultat i awansować dopiero wtedy, gdy ścieżka widoczna dla użytkownika rzeczywiście się poprawi.

Platformy zarządzanych agentów powinny przejąć rutynową pracę runtime’ową: wykonywanie w sandboxie, sesje stanowe, strumienie zdarzeń, śledzenie, uruchamianie plików oraz asynchroniczne kończenie zadań. Lokalne harnessy nadal są ważne, lecz ich rola staje się węższa i ostrzejsza. Należy zachować elementy kodujące smak produktu, bramki dowodowe, integralność publikowanych treści, granice prywatności, weryfikację źródeł oraz pamięć operacyjną specyficzną dla projektu. Przenieść trzeba te części, które istnieją wyłącznie dlatego, że nikt wcześniej nie zapakował dla nas runtime’u.

Złą migracją jest skasowanie własnego harnessu lokalnego tylko dlatego, że dostawca dostarczył zarządzaną infrastrukturę. Drugą złą migracją jest zachowanie każdego lokalnego polecenia, hooka i promptu wyłącznie dlatego, że kiedyś rozwiązywały realny problem. Właściwa migracja stawia jedno pytanie wobec każdego komponentu: czy koduje on moje standardy, czy tylko obsługuje maszynę?

Szersze ujęcie architektoniczne znajduje się w przewodniku po architekturze agentów AI. Wzorzec migracji lokalnej, który stoi za tym tekstem, opisują: przewodnik migracji Claude Code → Codex, wzorce AGENTS.md oraz filozofia jakości Jiro.

Stronę narzędzi lokalnych w tym podziale opisuje wpis Claude Code jako infrastruktura, wyjaśniający, dlaczego prywatne warstwy runtime’u rosną, a Claude Code kontra Codex CLI 2026 porównuje powierzchnie aktywacji i bezpieczeństwa.

Co zmieniło się wraz z managed agents?

Claude Managed Agents daje deweloperom gotowy harness agentowy działający w zarządzanej infrastrukturze. Anthropic pozycjonuje go jako rozwiązanie dla zadań długotrwałych i pracy asynchronicznej, z podstawowymi pojęciami: agentów, środowisk, sesji oraz zdarzeń.¹ Te same dokumenty opisują zarządzane środowisko, w którym Claude może czytać pliki, uruchamiać polecenia, przeglądać sieć, wykonywać kod, korzystać z serwerów MCP oraz utrzymywać historię zdarzeń po stronie serwera.¹

Tekst inżynierski Anthropic wyraża myśl architektoniczną wyraźniej niż dokumentacja produktowa. Zespół Managed Agents rozdzielił dziennik sesji, harness oraz sandbox tak, by każda część mogła zawodzić lub zmieniać się niezależnie.³ To rozdzielenie ma znaczenie, ponieważ zamienia kruchą pętlę agentową w jednym kontenerze w system z odzyskiwalnym stanem sesji, wymiennymi środowiskami wykonawczymi oraz węższą granicą bezpieczeństwa wokół poświadczeń.³

OpenAI zmierza w tym samym kierunku poprzez Agents SDK. Jego aktualizacja z 15 kwietnia 2026 wprowadziła natywny dla modelu harness, natywne wykonywanie w sandboxie, abstrakcję manifestu dla obszarów roboczych oraz wsparcie dla typowych prymitywów: MCP, skille, AGENTS.md, wykonywanie poleceń powłoki i nakładanie patchy.² Dokumentacja SDK udostępnia również sesje dla pamięci wieloprzebiegowej, śledzenie generacji LLM, wywołań narzędzi, przekazań, guardrails i zdarzeń własnych, a także przekazania umożliwiające przenoszenie pracy między wyspecjalizowanymi agentami.⁴⁵⁶

Tyle nowości. Pytanie strategiczne brzmi inaczej: skoro platformy dostarczają runtime agentowy, czym powinien jeszcze zajmować się lokalny harness?

Na czym polega podział między runtime’em a osądem?

Większość lokalnych harnessów agentowych łączy dwie role, które niekoniecznie powinny mieszkać razem.

Pierwszą jest infrastruktura runtime’owa. Runtime uruchamia sesje, przyznaje narzędzia, przygotowuje obszar roboczy, wykonuje polecenia, przechowuje zdarzenia, obsługuje przerwania, wznawia pracę, strumieniuje status oraz rejestruje ślady. To zadanie zyskuje na standaryzacji. Zyskuje też na inżynierii bezpieczeństwa, której większość zespołów nie powinna budować od zera bez ważnego powodu.

Drugą rolą jest osąd. Osąd mówi, jak wygląda dobra praca, które publiczne twierdzenia wymagają źródeł pierwotnych, kiedy przewodnik jest zbyt nieaktualny, by go publikować, kiedy hook jest zbyt głośny, by go egzekwować, kiedy skanowanie źródeł powinno zostać prywatną notatką zamiast wpisem oraz kiedy agent powinien odmówić wykonania pracy technicznie poprawnej, lecz niegodnej. Ta rola pozostaje lokalna, bo pochodzi od produktu, zespołu i czytelnika.

Zarządzana infrastruktura potrafi prowadzić lepszą pętlę. Nie potrafi natomiast zdecydować, jaki ma być twój smak.

Co warto przenieść do managed agents?

Należy przenieść komponenty, które nie kodują standardów produktu.

Funkcja Outcomes od Anthropic pokazuje, dokąd zmierza ten trend. Deweloper definiuje rubrykę, zarządzany harness inicjuje osobnego ewaluatora, a agent iteruje wobec jego informacji zwrotnej.⁷ To nie usuwa lokalnych standardów. Daje im miejsce w runtime’ie.

Ten sam wzorzec dotyczy śledzenia w OpenAI. SDK domyślnie śledzi przebieg, spany agentów, generacje, wywołania funkcji-narzędzi, guardrails oraz przekazania, z opcjami wyłączania śledzenia i procesorami dla innych miejsc docelowych.⁵ Lokalny skrypt potrafi to przybliżyć. System produkcyjny powinien zwykle preferować standaryzowany ślad i wysyłać go tam, gdzie zespół już debuguje pracę.

Co warto zachować lokalnie?

Należy zachować komponenty definiujące standardy, czytelnika lub prywatny kontekst operacyjny.

Smak produktowy. Platforma potrafi wykonać zadanie; nie potrafi ocenić, czy wynik poprawia całość produktu. Należy zachować reguły smaku odrzucające rezultaty rozproszone, generyczne lub pozbawione godności.

Bramki dowodowe. Należy zachować reguły wymagające dowodów z bieżącej sesji, weryfikacji ścieżki użytkownika, nazwanych luk oraz analizy przyczyny źródłowej. Zarządzane ślady mówią, co się wydarzyło. To twój standard rozstrzyga, czy dowód wystarcza.

Integralność publikowanych treści. Należy zachować reguły cytowań, poziomy zaufania źródeł, kontrole granic prywatności, kontrole SEO/AIO oraz bramki publikacyjne blisko serwisu. Dostawca modelu nie powinien rozstrzygać, które prywatne szczegóły workflow są bezpieczne do publikacji.

Pamięć projektu. Należy zachować zwięzłą doktrynę projektu, decyzje stylistyczne, znane zagrożenia, granice wydań oraz dzienniki operacyjne tam, gdzie zespół może je przeglądać. Przenieść warto wyłącznie warstwę magazynowania, jeśli zarządzany magazyn sesji rzeczywiście poprawia trwałość.

Wywiad źródłowy. Należy zachować redakcyjną warstwę routingu. Skaner może znaleźć 14 dobrych pozycji i wciąż wygenerować zero wpisów, jeśli właściwym ruchem jest monitoring, utrzymanie przewodnika lub prywatna notatka.

Polityka promocji. Należy zachować reguły wprowadzania zmian etapami. Skill może startować wyłącznie w trybie jawnym, hook może działać w trybie cienia (shadow), a plugin może pozostać w fazie install-pilot do czasu, aż realna praca dowiedzie, że pomaga bardziej, niż rozprasza.

Ta lista jest właściwym harnessem. Pliki i polecenia są tylko jego implementacją.

Jakiego błędu migracyjnego powinny unikać zespoły?

Najłatwiejszym sposobem zepsucia tej migracji jest zachowanie kształtu zamiast zadania.

Polecenia z ukośnikiem Claude Code, skille Codex, narzędzia SDK, zarządzane outcomes oraz serwery MCP to nie wymienne formy składniowe tego samego. To różne powierzchnie aktywacji. Polecenie z ukośnikiem może stać się skillem. Skill może stać się rubryką zarządzanego outcome. Hook może stać się procesorem śladów. Lokalny skrypt może stać się zbędny, gdy platforma udostępni sesje lub webhooki.

Tekst Anthropic o agentach długotrwałych formułuje tę myśl od drugiej strony: sama kompresja kontekstu nie wystarczyła, by uzyskać jakość produkcyjną, więc skuteczny wzorzec dodał listy funkcji, artefakty postępu, czyste stany przekazania oraz testy end-to-end.⁸ To nie konwencje UI. To zobowiązania dowodowe.

Migracja nie powinna pytać: „gdzie umieścić /scan-intel?”. Powinna pytać: „jakie zadanie pełnił workflow wywiadu źródłowego?”.

W przypadku skanera źródeł zadaniem nie jest „uruchomić polecenie”. Zadaniem jest skanować skonfigurowane źródła, dowodzić ich osiągalności, oceniać kandydatów, odmawiać szerokich, niskiej jakości zapisów, zachowywać prywatnie wartościowe notatki oraz kierować publiczne okazje do recenzji redakcyjnej. Dokładna fraza aktywacyjna może się zmienić bez utraty workflow.

Ta sama reguła dotyczy doktryny jakości. Nie należy publikować prywatnego pakietu promptów. Doktrynę warto przekształcić w obserwowalne bramki ukończenia: dowody, weryfikację ścieżki użytkownika, przegląd granic prywatności oraz prawo do odmowy pracy osłabiającej produkt.

Jak zastosować to do skanera wywiadu źródłowego?

Skaner wywiadu źródłowego konkretyzuje ten podział.

Strona runtime’owa może się przenieść. Zarządzana platforma może uruchamiać zadanie cykliczne, przechowywać sesję, wykonywać narzędzia przeglądania lub pobierania feedów, emitować zdarzenia oraz utrzymywać ślady. Jeśli skanowanie przekroczy limit czasu, zarządzana sesja powinna wiedzieć, co się wykonało, które źródła zawiodły i gdzie kolejne uruchomienie powinno wznowić pracę.

Strona osądu powinna pozostać lokalna. Skaner nadal potrzebuje prywatnej mapy źródeł, progów punktacji, kontroli duplikatów, limitów ilości zapisów oraz redakcyjnej trasy. Skanowanie znajdujące 14 kandydatów nie powinno automatycznie publikować 14 notatek ani jednego artykułu. Właściwym działaniem może być prywatna notatka, zadanie utrzymania przewodnika, kolejka monitoringu lub odmowa napisania czegokolwiek publicznego.

To rozróżnienie zamienia hałaśliwą automatyzację w użyteczny workflow:

Ta sama logika dotyczy workflow programistycznych, utrzymania przewodników, tłumaczeń oraz publikowania. Mechanikę wykonania należy przenieść tam, gdzie platforma robi to lepiej. Standard rozstrzygający, czy wynik zasługuje na istnienie, należy zachować.

Jakiej listy kontrolnej powinny używać zespoły przed przeniesieniem harnessu?

Przed przeniesieniem dowolnego komponentu lokalnego harnessu na platformę zarządzanych agentów warto skorzystać z poniższej listy kontrolnej.

Ścieżka promocji powinna pozostać nudna:

1. Zinwentaryzuj komponent.
2. Nazwij zadanie, które wykonuje.
3. Sklasyfikuj go jako: runtime, osąd, pamięć, publikowanie, wywiad źródłowy lub bezpieczeństwo.
4. Przenieś najmniejszą użyteczną wersję.
5. Uruchom ją na jednym realnym zadaniu.
6. Zarejestruj, co się wydarzyło.
7. Awansuj, popraw lub usuń.

Cokolwiek bardziej rozbudowanego zwykle ukrywa niepewność.

Jak zespoły powinny dziś dzielić realny harness?

W przypadku poważnego setupu programistyczno-pisarskiego zastosowałbym następujący podział.

Warstwa dostawcy lub zarządzana:

• tworzenie sandboxa
• wykonywanie plików
• trwałe sesje
• strumienie zdarzeń
• webhooki
• ślady i spany
• odzyskiwanie pracy długotrwałej po awarii
• podstawowa delegacja wieloagentowa
• wykonywanie rubryk, gdy dostawca to wspiera

Warstwa lokalna lub projektowa:

• AGENTS.md lub równoważna polityka projektu
• standardy publicznego pisania
• reguły cytowań i poziomów zaufania źródeł
• doktryna jakości produktu
• prywatna pamięć operacyjna
• kontrole SEO/AIO specyficzne dla witryny
• routing wywiadu źródłowego
• końcowe bramki publikacyjne
• polityka granic wydań dla pluginów i pakietów współdzielonych

Linia podziału nie przebiega między „zarządzanym” a „self-hosted”. Przebiega między „rutynowym runtime’em” a „osądem produktowym”.

Gdzie managed agents wymagają nadal ostrożności?

Platformy zarządzanych agentów nie usuwają trudnych części. Przesuwają je.

Nadal potrzebny jest model bezpieczeństwa dla narzędzi, plików, dostępu sieciowego oraz poświadczeń. Architektura Anthropic wprost oddziela poświadczenia od sandboxa, w którym uruchamia się wygenerowany kod, co jest właściwym kierunkiem, ale zespoły wciąż muszą poprawnie skonfigurować zasoby, sejfy i granice dostępu.³

Nadal potrzebna jest obserwowalność. Ślad pokaże graf wywołań; nie powie, czy praca zasługiwała na wysyłkę. Ewaluator może ocenić rubrykę; nie wie, czy rubryka wyraża właściwy smak.

Nadal potrzebne są granice treści. Publiczny artykuł migracyjny może opisać wzorzec, lecz nie powinien zrzucać prywatnych promptów, dokładnych wnętrz hooków, prywatnych ścieżek plików, list źródeł, danych konta ani autorskich zasad oceny redakcyjnej.

Nadal potrzebne jest etapowanie. Anthropic zaznacza, że Managed Agents pozostaje w fazie beta, a wszystkie endpointy wymagają nagłówka beta managed-agents-2026-04-01, przy czym niektóre funkcje wymagają dostępu preview.¹ Beta-runtime może być użyteczny, nie stając się domyślną ścieżką dla każdego workflow.

Co zespoły powinny z tego wynieść?

Dla liderów inżynierii:

• Pracę runtime’ową przenosić ku zarządzanym sesjom, sandboxom, zdarzeniom i śladom, gdy platforma spełnia twoje wymagania bezpieczeństwa.
• Zachować lokalne standardy dla dowodów, jakości źródeł, smaku produktu oraz granic wydań.
• Zarządzane rubryki traktować jako sloty wykonawcze dla swoich standardów, nie jako ich zastępstwo.

Dla budujących agentów:

• Nie przenosić poleceń jeden do jednego. Przenosić zadania-do-wykonania.
• Zaczynać w trybie jawnym, awansować dopiero po tym, jak realne zadanie udowodni wartość.
• Preferować ślady, dzienniki sesji oraz publiczne artefakty zamiast archeologii prywatnych promptów.

Dla osób piszących publicznie:

• Prywatny proces zamieniać w publiczne kryteria akceptacji.
• Cytować oficjalną dokumentację produktową dla aktualnego zachowania.
• Odmawiać podsumowania, gdy lepszym artykułem jest sama rama decyzyjna.

Jakie jest krótkie podsumowanie?

Platformy zarządzanych agentów sprawiają, że lokalny harness staje się mniejszy, lecz nie nieistotny. Pracę runtime’ową należy przenosić do zarządzanych sesji, sandboxów, śladów, zdarzeń oraz orkiestracji, gdy platforma na to zaufanie zasługuje. Zachować trzeba lokalne standardy, które definiują jakość, dowody, prywatność, integralność publicznego pisania oraz to, jaka praca zasługuje na wysyłkę.

FAQ: Managed agents i lokalne harnessy

Czy managed agents zastępują lokalny harness agenta AI?

Nie. Zarządzane platformy zastępują większą część warstwy runtime’u: sesje, sandboxy, strumienie zdarzeń, śledzenie oraz wykonywanie narzędzi. Lokalne harnessy nadal mają znaczenie, gdy kodują standardy produktu, bramki dowodowe, reguły publicznego pisania, granice prywatności, wywiad źródłowy oraz pamięć specyficzną dla projektu.

Co powinno pozostać w AGENTS.md lub CLAUDE.md?

Tam powinny znaleźć się trwałe reguły projektu: co produkt ceni, jak weryfikuje się ukończenie, których prywatnych szczegółów nie wolno publikować, jak kontroluje się publiczne pisanie oraz które ścieżki widoczne dla użytkownika muszą działać, zanim zadanie zostanie uznane za wykonane. W stałych plikach instrukcji nie należy upychać przejściowych wyników narzędzi ani prywatnych ciał promptów.

Kiedy zespół powinien sięgać po platformę zarządzanych agentów?

Zarządzaną infrastrukturę warto wybrać, gdy praca wymaga długotrwałego wykonywania, bezpiecznych kontenerów, trwałych sesji, strumieni zdarzeń, asynchronicznego kończenia, śledzenia lub zarządzanej orkiestracji wieloagentowej, a kontrole bezpieczeństwa, kosztu i danych po stronie dostawcy pasują do przypadku użycia.¹²

Czego nie należy przenosić do publicznego pakietu z harnessem?

Nie należy publikować prywatnych promptów, dokładnych ciał hooków, wrażliwych ścieżek plików, identyfikatorów kont, obsługi tokenów, prywatnych list źródeł, autorskich zasad punktacji ani niczego, co pozwoliłoby obcej osobie odtworzyć wewnętrzny system operacyjny zespołu. Publikować należy wzorzec oraz kryteria akceptacji.

Bibliografia