Czym jest inżynieria harnessu?

Inżynieria harnessu to praktyka zamieniania każdego powtarzającego się błędu agenta w stałą kontrolę: instrukcję, narzędzie, test albo regułę lintera, żeby go nie powtórzył. Mitchell Hashimoto nazwał ją na piśmie 5 lutego 2026, a sześć dni później wpis OpenAI umieścił ją w tytule. W odróżnieniu od vibe codingu dokłada kontrole, które działają, nawet gdy nikt nie czyta diffa.

Pochodzenie Najwcześniejsze użycie dokładnego wyrażenia, jakie znalazły badania, napisał Mitchell Hashimoto w „My AI Adoption Journey” (otwiera się w nowej karcie) 5 lutego 2026, a wpis OpenAI autorstwa Ryana Lopopolo (otwiera się w nowej karcie) umieścił „harness engineering” w tytule 11 lutego 2026, po czym termin się rozprzestrzenił.

Ostatnia aktualizacja: 2026-10-10; Autor: Michał Jaskólski; Opublikowano 2026-10-10
Po angielsku: Harness engineering
Najbliższy poziom drabiny: Poziom 5, darmowy przewodnik
Szukane też jako: harness engineering

Wypróbuj 7 dni za darmo Przeczytaj darmowy przewodnik

Potem $19.99 miesięcznie lub $99.99 rocznie. Subskrypcję anulujesz na stronie konta. Zwrot pierwszego zakupu: 30 dni.

Na tej stronie

Dlaczego to ważne Inżynieria harnessu a vibe coding Inżynieria promptów, kontekstu i harnessu Siedem warstw harnessu agenta kodującego Jak robi to każde narzędzie Pytania Źródła

Dlaczego to ważne.

Gdy agent popełnia ten sam błąd po raz drugi, odruchem jest kolejne zdanie w pliku reguł. Inżynieria harnessu pyta, która warstwa naprawdę go zatrzyma: zdanie to rada, którą model może zignorować, hook to kod uruchamiany przy każdym pasującym zdarzeniu, a sandbox to ściana. Nasza zasada brzmi: każdą kontrolę umieść w najbardziej deterministycznej warstwie, która potrafi ją wyrazić, a harness wersjonuj, recenzuj i oceniaj jak kod. Wpis Anthropic zauważa, że każdy element zawiera założenie o tym, czego model nie potrafi, a takie założenia starzeją się wraz z modelami.

Inżynieria harnessu a vibe coding

Oba podejścia zmniejszają ilość kodu czytanego przez człowieka; nasza analiza: vibe coding przestaje sprawdzać, a inżynieria harnessu przenosi sprawdzanie do kodu, który głośno zawodzi.

Inżynieria harnessu w zestawieniu z vibe codingiem: co nazywa, kto pisze kod, kto go sprawdza, co kończy pętlę, skąd pochodzi nazwa i gdzie zawodzi
Pytanie	Vibe coding	Inżynieria harnessu
Co nazywa	Sposób pracy: przyjmować wynik modelu bez czytania	Dyscyplinę: zaprojektować otoczenie agenta tak, żeby błąd nie mógł się powtórzyć
Kto pisze kod	Model	Agent; OpenAI opisuje jeden wewnętrzny produkt zbudowany z „0 lines of manually-written code” (dane dostawcy, jeden zespół)
Kto to sprawdza	Nikt nie czyta diffa; człowiek ocenia działanie na oko	Najpierw kontrole mechaniczne i agenci recenzujący; OpenAI: „Humans may review pull requests, but aren’t required to.”
Co kończy pętlę	Człowiek uznaje, że działa	Kontrole przechodzą; Hashimoto: daj agentowi „fast, high quality tools to automatically tell it when it is wrong”
Skąd nazwa	Andrej Karpathy, wpis na X, 2 lutego 2025	Mitchell Hashimoto, 5 lutego 2026, który zastrzega, że jej nie wymyślał; rozpowszechnił ją wpis OpenAI Ryana Lopopolo z 11 lutego 2026
Gdzie zawodzi	Wszędzie, gdzie kod utrzymują inni; Karpathy uznał je za dobre do „throwaway weekend projects” (weekendowych projektów na wyrzucenie)	Założenia harnessu starzeją się wraz z modelami (Anthropic), a Dex Horthy twierdzi, że samo w sobie to za mało

Esej Horthy’ego ma sekcję zatytułowaną „this has nothing to do with vibe coding” i mówi: „If you love vibe coding, please, go on vibing.” Dodaje, że reszta tekstu jest skierowana do „folks solving hard problems in complex codebases” (osób rozwiązujących trudne problemy w złożonych bazach kodu).

Źródło: Vibe coding a inżynieria agentowa, 2026-10-10.

Inżynieria promptów, kontekstu i harnessu

Lipcowa taksonomia Grigoreva z 2026 daje każdej warstwie własne pytanie (dodaje jeszcze inżynierię pętli i grafową, których tu nie pokazujemy), a źródła spierają się, czy harness zawiera inżynierię kontekstu, czy odwrotnie.

Pytanie, na które odpowiada każda z inżynierii promptów, kontekstu i harnessu, i kto tak twierdzi
Warstwa	Pytanie, na które odpowiada	Według
Inżynieria promptów	„what we say when we interact with the agent”	Alexey Grigorev, 22 lipca 2026
Inżynieria kontekstu	„what the agent knows before it starts”	Alexey Grigorev, 22 lipca 2026
Inżynieria harnessu	Co ogranicza i sprawdza agenta	Nasza analiza

Birgitta Böckeler (2 kwietnia 2026) umieszcza harness wewnątrz inżynierii kontekstu: „Engineering a user harness for a coding agent is a specific form of context engineering.” Artykuł „Agent harness” z Wikipedii, odczytany 10 października 2026, ujmuje to odwrotnie: harness „designs the whole operational environment and contains the other two as parts.” Żadne z zagnieżdżeń nie jest rozstrzygnięte i ta strona nie wybiera żadnego.

Źródło: Vibe coding a inżynieria agentowa, 2026-10-10.

Siedem warstw harnessu agenta kodującego

Nasz przewodnik po harnessie dzieli harness na siedem warstw, z których każda zapobiega jednej klasie błędów i wymusza to inaczej.

Siedem warstw harnessu, co każda zawiera i jak mocno wymusza
Warstwa	Co zawiera	Wymuszanie
1 · Kontekst	Instrukcje projektu (`CLAUDE.md`, `AGENTS.md`, Cursor Rules), pamięć	Rada: model może ją zignorować
2 · Narzędzia	Serwery MCP, CLI, subagenci	Zdolność: do czego agent ma dostęp
3 · Uprawnienia i sandbox	Tryby uprawnień, reguły allow/ask/deny, sandbox systemowy, ruch wychodzący	Twarde: odmawia klient albo system
4 · Hooki	Skrypty uruchamiane w zdarzeniach cyklu życia, np. przed wywołaniem narzędzia lub na zakończenie	Deterministyczne: kod uruchamia się za każdym razem
5 · Skille	Procedury ładowane na żądanie (`SKILL.md` i skrypty)	Rada, ładowana tylko wtedy, gdy jest potrzebna
6 · Pluginy	Instalowalne pakiety skilli, hooków, subagentów i serwerów MCP	Dystrybucja: jedno wersjonowane źródło
7 · Środowiska	Worktree, kontenery, środowiska chmurowe, dane testowe, bloki portów	Izolacja: osobny stan na każde uruchomienie

Baza kodu i wyrocznia, czyli testy i bramki decydujące o „gotowe”, stoją obok harnessu, a nie w nim. Setup Pack z tej witryny obejmuje stację Harness: pliki, które agent czyta, zanim cokolwiek napisze. Przewodnik po drabinie umieszcza harness wśród sześciu stacji Poziomu 5.

Źródło: Przewodnik po harnessie, 2026-10-02.

Jak robi to każde narzędzie.

Cursor, Claude Code i Codex nazywają to po swojemu. Każda notatka ma datę sprawdzenia.

Cursor

Warstwy pokrywają Rules, MCP, Subagents, Run modes, Hooks, Agent Skills, Plugins, Worktrees i Cloud Agents; ścieżki plików i nazwy ustawień pominięto do ponownej weryfikacji.

Przewodnik po harnessie, 2026-08-28

Claude Code

Warstwy znajdują się w CLAUDE.md, regułach permissions w .claude/settings.json, bloku hooks (33 zdarzenia w Claude Code 2.1.283), .claude/skills/, pluginach i --worktree; ustawienia zarządzane mają pierwszeństwo przed ustawieniami projektu.

Przewodnik po harnessie, 2026-10-02

Codex

Warstwy znajdują się w AGENTS.md, .codex/config.toml (wczytywanym tylko dla zaufanego repozytorium), profilach uprawnień (beta) i 12 zdarzeniach hooków, które wymagają utrwalonego zaufania (Codex CLI 0.157.1); /debug-config pokazuje, która warstwa ustawiła daną wartość.

Przewodnik po harnessie, 2026-10-02

Najczęstsze pytania.

Czym inżynieria harnessu różni się od vibe codingu?

Vibe coding przyjmuje wynik agenta bez czytania; inżynieria harnessu zamienia każdy powtarzający się błąd w test, regułę lintera, hook albo instrukcję. Nasza analiza: vibe coding przestaje sprawdzać, a inżynieria harnessu przenosi sprawdzanie do kodu. Esej Dexa Horthy’ego z 22 lipca 2026 dodaje: „If you love vibe coding, please, go on vibing.” Resztę kieruje do osób, które rozwiązują trudne problemy w złożonych bazach kodu.

Kto wymyślił inżynierię harnessu?

Nie ustalono autora nazwy. Wpis Mitchella Hashimoto z 5 lutego 2026 to najwcześniejsze użycie dokładnego wyrażenia, jakie znalazły badania, a on sam napisał: „I don’t need to invent any new terms here; if another one exists, I’ll jump on the bandwagon.” Wpis OpenAI Ryana Lopopolo z 11 lutego 2026 umieścił je w tytule; Birgitta Böckeler zauważyła, że „only mentions ‘harness’ once in the text”.

Czym inżynieria harnessu różni się od inżynierii kontekstu?

Inżynieria kontekstu decyduje, co agent widzi; inżynieria harnessu decyduje, co go sprawdza i ogranicza. Źródła spierają się o zagnieżdżenie. Birgitta Böckeler nazywa harness „a specific form of context engineering”, a artykuł „Agent harness” z Wikipedii umieszcza inżynierię kontekstu wewnątrz harnessu. Żadne zagnieżdżenie nie jest rozstrzygnięte, więc potraktuj je jako dwa pytania, które się pokrywają.

Czy inżynieria harnessu wystarczy?

Według Dexa Horthy’ego z HumanLayer nie: 22 lipca 2026 napisał, że „no amount of harness engineering or loopsmaxxing can solve what is fundamentally a model-training issue.” Anthropic dodaje, że każdy element harnessu „encodes an assumption about what the model can’t do on its own”, a takie założenia mogą się starzeć wraz z modelami.