Agent = Model + Harness: dlaczego production-ready harness to prawdziwa różnica
Gdy agent AI zawodzi w rzeczywistym środowisku, pierwsza reakcja niemal zawsze brzmi: „potrzebujemy lepszego modelu". To błędna diagnoza. W zdecydowanej większości przypadków problem nie tkwi w modelu — on rozumuje znakomicie. Problem tkwi w harness: infrastrukturze programowej wokół modelu, która zamienia go z czegoś, co odpowiada, w coś, co działa niezawodnie.
To także formuła, na której się opieramy:
Agent = Model + Harness
Ten sam model, ale lepszy harness — lepsze rezultaty. To właśnie obszar, w którym OpenKBS jest silny: budujemy production-ready, scalable, secure harness. Ten artykuł wyjaśnia, co to oznacza, dlaczego ma znaczenie dla biznesu i jak obie warstwy — model i harness — łączą się na platformie.
Czym właściwie jest harness
Jeśli model jest mózgiem, harness jest ciałem. Mózg potrafi myśleć, ale bez ciała nie chwyci niczego, nie otworzy drzwi ani nie sprawdzi rezultatu swojego działania. Harness to wszystko, co stoi między „model zdecydował, co zrobić" a „działanie wykonało się bezpiecznie, w sposób śledzalny i powtarzalny":
- narzędzia (tools), które model może wywołać;
- izolowane środowisko (sandbox), w którym wykonuje się kod;
- pamięć i magazyn danych, które przetrwają między sesjami;
- pętle sprzężenia zwrotnego (feedback loops), które pozwalają agentowi zobaczyć rezultat i go skorygować;
- guardrails — granice, które nie pozwalają agentowi wyrządzić szkody;
- obserwowalność (observability), która daje ślad audytowy dla każdego działania.
Model sam w sobie jest stateless — przyjmuje tekst i zwraca tekst. Wszystko pozostałe, co czyni agenta użytecznym w production, to harness.
Dlaczego większość awarii wynika z harness, a nie z modelu
To kluczowe spostrzeżenie: większość operacyjnych awarii agentów AI wynika z harness, a nie z samego modelu. Typowe objawy nie mają nic wspólnego z inteligencją modelu:
- Context rot — kontekst przepełnia się lub zanieczyszcza i model traci wątek;
- Tool overload — zbyt wiele, źle opisanych narzędzi, między którymi model się gubi;
- Kruche okablowanie — ręcznie sklejone integracje, które pękają przy pierwszej zmianie;
- Latencja — każdy krok przechodzi przez zbędne przeskoki sieciowe;
- Nietrafne wyszukiwanie — pamięć zwraca niewłaściwy kontekst;
- Słaba weryfikacja — agent nie sprawdza rezultatu swojego działania;
- Brakujące guardrails — nic nie zatrzymuje agenta, gdy popełni błąd.
Żadnego z tych problemów nie rozwiąże zmiana modelu. Wszystkie rozwiązuje lepszy harness. Dlatego silny harness czyni przeciętne modele użytecznymi, a słaby harness marnuje nawet te najlepsze.
Warstwa 1 — Model: zaufanie dzięki zero data retention
Nie tworzymy modeli. I jest to świadomy wybór: najlepsze modele zmieniają się co kilka miesięcy, a uzależnienie od jednego dostawcy to ryzyko strategiczne. Zamiast tego dajemy dostęp do wszystkich dużych dostawców — OpenAI, Anthropic, Google — przez jednolite AI proxy, rozmieszczone w naszej infrastrukturze w UE.
Różnica tkwi w warunkach, na jakich to się dzieje:
- Zero data retention. Zapytania przechodzą przez dostawców na podstawie umów o zerowym przechowywaniu danych — nic nie jest logowane, nic nie jest zachowywane i nic nie jest wykorzystywane do trenowania modeli. Dane klienta nie pozostają u dostawcy.
- Bez zarządzania kluczami API. Klient nie żongluje kluczami OpenAI, Anthropic i Google — dostęp odbywa się przez jeden identyfikator i jedno rozliczenie w kredytach.
- Konsolidacja łańcucha dostaw. Zamiast osobnej umowy, osobnej oceny ryzyka i osobnego audytu dla każdego dostawcy AI, klient współpracuje z jednym dostawcą. Dla sektorów regulowanych to bezpośrednia przewaga w kontekście NIS2 i AI Act — drastycznie mniej dostawców do oceny.
Innymi słowy: modele daje każdy. My rozwiązujemy część, która naprawdę waży w środowisku enterprise — zaufanie.
Warstwa 2 — Harness: tu jest nasza siła
Production harness składa się z rozpoznawalnych bloków konstrukcyjnych. Siłą OpenKBS jest to, że każdy z nich jest zrealizowany na zarządzanej, izolowanej i certyfikowanej infrastrukturze — nie jako ręcznie sklejony prototyp, lecz jako platforma.
| Blok konstrukcyjny harness | Realizacja w OpenKBS |
|---|---|
| System prompts / kontekst | Funkcje Lambda — kontekst i logika to kod, wersjonowany przy każdym wdrożeniu |
| Tools (narzędzia) | Project API: workers, S3, e-mail, MQTT, baza danych — gotowe narzędzia, które agent wywołuje |
| Sandboxes (izolacja) | Izolacja Lambda microVM + wydzielone konto AWS na klienta + on-demand workery EC2 do ciężkich zadań |
| Filesystem | Magazyn obiektowy S3 z presigned URLs — ograniczone w czasie i zakresie |
| Memory (pamięć) | Zarządzany PostgreSQL (Aurora/Neon), point-in-time restore do 35 dni, 6 kopii w 3 strefach |
| Feedback loops | Agent loop w Lambda: tool_use → wykonanie → obserwacja → powtórzenie i korekta |
| Guardrails | Izolacja multi-tenant, wstrzykiwane secrets, limity kredytowe, OWASP security audit, AES-256 / TLS 1.2+ |
| Observability | Logi CloudWatch, logi workerów, usage collector, administracyjny dziennik audytowy |
| Dostęp do modeli | AI proxy — wszyscy dostawcy, zero retention, jednolite rozliczenie, bez zarządzania kluczami |
To nie jest lista ambicji — to infrastruktura, która już stoi pod każdym projektem na platformie. Deweloper startuje z gotowego harness, zamiast składać go od zera dla każdego agenta.
Scalable domyślnie
Funkcje Lambda skalują się automatycznie od zera do tysięcy równoległych wykonań. Ciężkie zadania (przetwarzanie wideo, ML, batch) trafiają na on-demand workery z rozliczeniem za sekundę. Baza danych dobiera właściwy silnik w zależności od obciążenia. Brak planowania pojemności i brak serwerów do utrzymania.
Secure z założenia
Każdy klient jest fizycznie izolowany na poziomie konta AWS — twarda granica narzucana przez AWS IAM, a nie logiczne rozdzielenie. Secrets są wstrzykiwane przy wdrożeniu, nigdy do kodu. Dostęp odbywa się przez JWT i klucze per-project z automatyczną rotacją. Każda nowa wersja przechodzi przez ustrukturyzowany audyt bezpieczeństwa.
Production-ready znaczy compliant
W regulowanym europejskim środowisku „production-ready harness" ma jeszcze jedno znaczenie: compliant harness. Tutaj siła harness i zgodność regulacyjna zlewają się w jedno.
- EU data residency — wszystkie zasoby domyślnie znajdują się w regionie AWS eu-central-1 (Frankfurt). Dane nie opuszczają UE.
- Odziedziczone certyfikacje — infrastruktura opiera się na AWS z ponad 150 niezależnie audytowanymi certyfikacjami (ISO/IEC 27001, SOC 2 Type II, C5 niemieckiego BSI), w tym członkostwem w niemieckiej infrastrukturze krytycznej (KRITIS).
- Security audit przy każdej wersji — analiza statyczna pod kątem OWASP Top 10, weryfikacja pod kątem SQL injection, XSS, CSRF, SSRF, command injection i podatności CVE przed produkcją; raporty są dostępne dla regulatora.
- Wydzielone i przekazywalne konto — przy rozwiązaniu umowy całe konto AWS przekazywane jest klientowi. Nic się nie migruje, brak zastrzeżonych formatów, brak vendor lock-in.
Ten sam harness, który czyni agentów niezawodnymi, czyni ich również audytowalnymi. Szczegóły dotyczące NIS2 i AI Act opisaliśmy w osobnych artykułach — NIS2 i transformacja AI sektora produkcyjnego oraz AI Act i zgodność dla przedsiębiorstw.
Co to oznacza dla biznesu
Większość firm dziś nie buduje jednego agenta AI. Buduje dziesiątki. I bez wspólnej infrastruktury szybko zamienia się to w agent sprawl — rozproszonych, niepowiązanych agentów, których żaden zespół nie jest w stanie niezawodnie zarządzać, audytować ani utrzymywać.
Współdzielony, production-ready harness rozwiązuje dokładnie to:
- Od demo do production. Prototyp, który działa na laptopie, i system, który wytrzymuje rzeczywisty ruch w regulowanym środowisku, to dwie różne rzeczy. Różnicą jest harness.
- Governance. Jedno miejsce na obserwowalność, secrets, limity i audyt — zamiast by każdy agent na nowo wynajdował koło.
- Szybkość bez podejmowania ryzyka. Zespoły skupiają się na logice agenta, a nie na izolacji, skalowaniu i zgodności — te przychodzą gotowe.
Wniosek jest prosty: sukces w production wymaga, by inżynieria harness była traktowana jako odrębna dyscyplina, równa wagą wyborowi modelu. To dyscyplina, w której OpenKBS jest silny.
Następny krok
Jeśli Twoja organizacja przechodzi od prototypów AI do rzeczywistych, production agentów — zwłaszcza w sektorze regulowanym — skontaktuj się z nami. Przeanalizujemy Twój konkretny przypadek i pokażemy, jak wygląda production-ready harness dla Twojego biznesu: izolowany, skalowalny, bezpieczny i zgodny domyślnie.
Opisane usługi enterprise — wydzielone konto AWS, audyt bezpieczeństwa i przegląd kodu generowanego przez AI — są częścią planu Enterprise OpenKBS.
Niniejszy artykuł ma charakter informacyjny i nie stanowi porady prawnej.