Harness, który mówi agentom kodującym, jak działa twój kod

• Instrukcje dla każdego repozytorium, na tyle zwięzłe, żeby agent się do nich stosował
• Polecenia, którymi agent może zbudować projekt i uruchomić jego testy w świeżo sklonowanym repozytorium
• Jasny zakres kontekstu i narzędzi: z jakich usług, plików i endpointów agent może korzystać
• Reguły określające, które polecenia powłoki, edycje plików i rodzaje dostępu do sieci są dozwolone, a które wymagają zatwierdzenia
• Testy, hooki i kroki review, które wyłapują problemy w pracy agenta, zanim ktokolwiek z twojego zespołu na nią spojrzy

Gdy nikt nie obserwuje agenta, w ryzach trzymają go jego ograniczenia. Każde uruchomienie dostaje uprawnienia dopasowane do zadania, własny izolowany workspace i dane dostępowe ważne tylko dla tego uruchomienia. Nic nie zostaje zmergowane, dopóki nie przejdzie review. Dokładna konfiguracja różni się w zależności od narzędzia i infrastruktury, dlatego ustalamy ją z twoim zespołem bezpieczeństwa.

Pliki harnessu są wersjonowane tak samo jak kod. Każdy plik ma osobę, która za niego odpowiada, i uzgodniony sposób wprowadzania zmian. Bez tego każdy inżynier dodaje własne ustawienia, a repozytoria coraz bardziej się od siebie różnią. Razem z tobą ustalamy, które elementy są wspólne dla wszystkich repozytoriów, a które zostają lokalne, oraz po czym poznasz, że zaczynają się rozjeżdżać.

Każda zmiana dotyczy jednego elementu harnessu, a mierzymy ją na zadaniach typowych dla twojej pracy. Gdy trzeba porównać dwie konfiguracje, korzystamy z ewaluacji na twoich własnych repozytoriach. Pliki konfiguracyjne i spisane runbooki trafiają do twoich inżynierów, żeby mogli dalej dostosowywać harness bez nas.

W repozytorium context engineering oznacza ustalenie, co agent dostaje na starcie, a po co jeszcze może sięgnąć w trakcie pracy. Obejmuje to polecenia do buildów i testów, pliki z instrukcjami, dokumenty, które może otwierać, oraz narzędzia, które wolno mu wywoływać. Więcej nie znaczy lepiej. Instrukcje ładowane przy każdym zapytaniu zabierają miejsce samemu zadaniu. Tę część utrzymujemy krótką. Cała reszta trafia do plików ładowanych dopiero wtedy, gdy zadanie ich wymaga, na przykład do Skills albo reguł przypisanych do ścieżki.

Zmiany kontekstu przechodzą ten sam proces co każda inna zmiana w harnessie. Każdą wprowadzamy osobno i sprawdzamy na stałym zestawie przykładowych zadań. Potem zapisujemy, czy liczba zaakceptowanych zmian i nakład pracy na review rosną, czy spadają.

Kilka opublikowanych workflowów zmienia sposób, w jaki agent przechodzi przez zadanie. Jednym z nich jest technika Ralph, którą Geoffrey Huntley opisał w lipcu 2025 roku. Agent w pętli dostaje wciąż ten sam prompt i każdą rundę zaczyna ze świeżym kontekstem. Między rundami postęp zapisywany jest w plikach, na przykład w planie i specyfikacjach. Dla Claude Code Anthropic udostępnia plugin ralph-wiggum. Utrzymuje on pętlę w obrębie jednej sesji i kończy ją po pojawieniu się frazy kończącej albo, jeśli go ustawisz, po osiągnięciu limitu iteracji. Huntley uważa, że technika sprawdza się w nowych projektach, i odradza jej stosowanie w istniejącej bazie kodu.

Superpowers od Jessego Vincenta i Prime Radiant zaczyna od burzy mózgów i spisanego planu. Potem subagenci wykonują pracę, zaczynając od testów, a review kodu jest stałą częścią procesu. Plugin compound engineering od Every przechodzi przez burzę mózgów, plan, pracę, upraszczanie i review. Na koniec zapisuje wnioski, żeby można było z nich skorzystać przy kolejnych zadaniach. pstack autorstwa Lauren Tan, plugin do Cursora, kieruje każde zadanie do pasującego playbooka i zleca review wyniku kilku modelom.

Te workflowy dają agentowi instrukcje. Żaden z nich niczego nie wymusza. Pętla, która działa godzinami, wymaga tych samych zabezpieczeń co każde uruchomienie, którego nie pilnuje człowiek. Oznacza to ograniczenie liczby iteracji i budżetu, izolację workspace'u, ochronę testów przed zmianami ze strony agenta i review przed każdym merge'em. Zanim zespół przyjmie dany workflow, testujemy go na twoim repozytorium i sprawdzamy pod kątem twoich mechanizmów kontroli. Uruchamiamy go też równolegle z twoją obecną konfiguracją na identycznych zadaniach.

Nasz przewodnik po pstack · Spec-driven development w praktyce · Jak porównujemy workflowy

W OpenCode dostawcę i endpoint modelu ustawia się w konfiguracji. Ustalamy to w pierwszej kolejności, razem z osobami, które odpowiadają u ciebie za dane i umowy. To ustawienie decyduje, dokąd trafiają twoje prompty i kontekst kodu, jakie warunki je obejmują i kto dostaje rachunek. Gdy ruch przechodzi przez gateway, atrybucję użycia i zasady masz w jednym miejscu. Gateway jest jednak kolejnym systemem z dostępem do tego ruchu. O tym, czy udostępnianie sesji jest włączone, również decydujemy wspólnie.

Poza formatem praca nad harnessem nie różni się od innych narzędzi: po prostu zapisujemy ją w konfiguracji OpenCode. Dokumentujemy drogę twoich danych od maszyn deweloperów przez ewentualny gateway aż do dostawcy. Dostajesz też runbook, który wyjaśnia, jak w przyszłości zmienić dostawcę lub model. Okresy przechowywania danych wynikają z twoich umów i z warunków, które dany dostawca aktualnie publikuje. Zapisujemy je dla każdego dostawcy, z którego korzystasz.

Z Kilo można korzystać w edytorze, w CLI i w chmurze. Najpierw sprawdzamy, jakich wariantów i wersji Kilo używają twoje zespoły i na których dostawców pozwala twoja organizacja. To połączenie testujemy na twoim kodzie, zanim inne zespoły zaczną z niego korzystać. Aplikacja desktopowa jest wersją beta, więc uwzględniamy ją tylko w zespołach, które już na niej polegają. Klient jest open source i działa lokalnie, ale to nie mówi nic o tym, które serwery otrzymują prompty i kontekst kodu. Decyduje o tym dostawca, którego skonfigurujesz, oraz każdy gateway, przez który przechodzi ruch, w tym gateway Kilo, jeśli z niego korzystasz.

Każdy własny agent, każda reguła repozytorium, każdy skill i każde polecenie znajduje się w kontroli wersji i ma właściciela. Obecne rozszerzenie jest zbudowane na CLI i czyta definicje własnych agentów z plików Markdown. Starsze instalacje wciąż czytają custom modes, czyli dawny format. Dla każdej zainstalowanej wersji sprawdzamy, który format czyta, a po migracji powtarzamy zadania akceptacyjne. Wszystkie te pliki mówią agentowi, co ma robić. To, co agent faktycznie może zrobić, wyznaczają jego uprawnienia i dostęp do MCP, które konfigurujemy osobno dla każdego agenta. To, jak bardzo możesz ograniczyć modele, zależy od twojego planu. Kontrola dla organizacji opisana w dokumentacji Kilo to blocklista w planie Enterprise. Każdy nowy dostawca i model pozostaje dostępny, dopóki ktoś go nie zablokuje. Dlatego zatwierdzony wybór potrzebuje osoby, która za niego odpowiada i sprawdza każdą nową pozycję. Ustalamy też, jaki mechanizm wymusza ten wybór w twoim planie.

• Test wariantów, wersji i dostawców twoich zespołów na twoim własnym kodzie
• Wspólne definicje agentów, polecenia, reguły i skille w kontroli wersji, każdy element z imiennie wskazanym właścicielem i zapisany w formacie, który rozumieją zainstalowane u ciebie wersje
• Serwery MCP i uprawnienia ograniczone do tego, czemu służy dany agent
• Modele i dostawcy oceniani według zaakceptowanych zmian, nakładu na review i ponownych prób oraz osoba odpowiedzialna za zatwierdzoną listę

Wdrożenie z wyborem dostawcy · Jak porównujemy workflowy · Ile kosztują workflowy wieloagentowe · Dokumentacja Kilo o dostosowywaniu agentów

Gdy agent działa w chmurze dostawcy, harness musi zostać skonfigurowany także w tym środowisku. Wszystko, dzięki czemu projekt działa na maszynie dewelopera, trzeba tam odtworzyć. Chodzi o instalację zależności, uruchomienie usług, załadowanie danych testowych i udostępnienie sekretów ograniczonych do zadania. Potem otwieramy nową sesję i sprawdzamy, czy projekt się buduje, a jego testy działają. Sprawdzamy też, czy dostęp agenta do gita, MCP i sieci odpowiada zadaniu. To, co da się tam wymusić, zależy od produktu i planu. Jak wybierać zadania, kto odpowiada za review i jak prowadzić pilotaż, opisujemy w części o Devinie na naszej stronie o wdrażaniu agentów kodujących.

Przekazywanie pracy Devinowi

• Odsetek pierwszych prób agenta, które przechodzą twoje kontrole
• Ile rund review potrzebują pull requesty agentów i ile poprawek
• Każda zmiana w harnessie zmierzona na niezmienionym zestawie zadań, zanim zostanie na stałe