Jeden prompt może wyglądać jak magia, ale za skutecznym działaniem agenta AI stoi znacznie więcej: kontekst, narzędzia, instrukcje oraz odpowiednio zaprojektowane środowisko pracy. W tym artykule pokazujemy, co naprawdę dzieje się „pod spodem” i jak te elementy wpływają na możliwości agentów AI.
To, co z naszej perspektywy wygląda jak jedno polecenie, w praktyce jest jedynie początkiem całej serii operacji – niezależnie od tego, którego narzędzia używamy do realizacji naszego „vibe’u”. Nasz prompt jest tylko punktem startowym dalszej pracy.
Czy korzystamy z Claude Code, czy z różnych modeli dostępnych w Opencode, możemy podejrzeć, jak naprawdę przebiega realizacja naszego żądania. Agent najpierw przetwarza prompt inicjalny, a następnie na jego podstawie przygotowuje kolejny krok. Ten krok staje się w praktyce następnym promptem, którego wynik prowadzi do kolejnego. W ten sposób agent iteracyjnie rozwiązuje zadanie.
Warto zauważyć, że wcześniejsze prompty nie znikają. Tworzą historię konwersacji i razem stanowią kontekst, o którym tak często mówi się w świecie LLM-ów. Przetwarzanie całego tego kontekstu – a dokładniej tokenów, na które zostaje rozbity – jest kosztowne. Dlatego narzędzia i organizacje pracujące nad agentami stale optymalizują jego wykorzystanie: stosują cache, unikają ponownego przetwarzania tych samych tokenów i starają się ograniczać zbędne operacje. Wielu ludzi bardzo ciężko pracuje nad tym, aby użytkownik miał wrażenie, że jego wkład ogranicza się do jednego promptu.
Kolejnym modnym, choć bardziej technicznym pojęciem, jest harness. To zestaw narzędzi, reguł, ograniczeń i możliwości, którymi „opakowany” jest używany przez nas model językowy. Claude Code to przykład takiego Agent Harness, podobnie jak Codex czy Opencode. Nawet omo.dev, będące rozszerzeniem do Opencode, jest w praktyce dodatkową warstwą rozbudowującą jego możliwości. Celem każdej takiej „uprzęży” jest poprowadzenie LLM-a we właściwym kierunku: udostępnienie narzędzi MCP, dostępu do systemu plików, innych programów na urządzeniu czy odpowiedniej reakcji w sytuacji wyczerpania kontekstu.
LLM jest mózgiem, ale sam w sobie nie ma rąk do wykonywania zadań. Widać to choćby podczas korzystania z Gemini w przeglądarce. Model chętnie podpowie, jakie komendy wykonać lub które przyciski kliknąć, ale nie zrobi tego za nas. Odpowiedni harness dostarcza właśnie te możliwości. Oczywiście to użytkownik decyduje, na ile chce je udostępnić agentowi. Praktycznie każde narzędzie agentowe do kodowania ma system uprawnień pozwalający określić, które operacje są dozwolone, które zabronione, a o które agent powinien zapytać.
Harness to także zestaw promptów. Kiedy i jak wykonywać operacje kompaktowania konwersacji, aby nie przekroczyć dostępnego kontekstu? Jak nazywać sesje z LLM-em? Jak model powinien się zachowywać i w jaki sposób prezentować odpowiedzi użytkownikowi? W przypadku Opencode możemy łatwo podejrzeć, jakimi zasadami kieruje się model „wpięty” w to rozwiązanie. Prompty są po prostu plikami tekstowymi dostępnymi w repozytorium kodu. Możemy z nich dowiedzieć się na przykład, że agent generujący tytuły konwersacji ma jasno określone zadanie: nie narzekać, tylko generować tytuły. W innym pliku znajdziemy instrukcję, że agent ma uważać się za najlepszego na świecie agenta kodującego. Trudno o lepszą reprezentację idei „jesteś zwycięzcą”.
Oczywiście Claude Code czy Codex chronią swoje wewnętrzne prompty i organizację pracy na tyle, na ile potrafią. Trzeba jednak uczciwie przyznać, że nie zawsze wychodzi im to idealnie. Możemy jednak przypuszczać, że ich wewnętrzne rozwiązania nie różnią się dramatycznie od tego, co oferuje Opencode. Ciekawym przypadkiem jest wspomniane wcześniej omo.dev. Twórcy chwalą się, że są najlepsi, a jako dowód podają fakt, że ich rozwiązanie miało odpowiadać za zablokowanie możliwości używania subskrypcji Claude w Opencode. Ich zdaniem model Anthropic działał lepiej przez ich wtyczkę niż w oryginalnym Claude Code. Oczywiście możliwość korzystania z modeli Anthropic nadal istnieje, ale już w modelu rozliczanym za wykorzystane tokeny.
Czy ten jeden plugin rzeczywiście był powodem tych ograniczeń, czy po prostu złożyło się na to więcej czynników – trudno powiedzieć. Tak czy inaczej pokazuje to, że sposób wyposażenia agenta ma znaczenie.
AI przyspiesza budowę aplikacji. Productive24AI zapewnia spójne środowisko do ich wdrażania.
A jak robimy to my? Chwalimy się przecież, że w Productive24AI można używać Claude Code, Codex, Opencode czy Antigravity. Skoro integrujemy gotowe rozwiązania, to gdzie jest nasza „uprząż”?
Productive24AI jest tutaj bardzo bliskie podejściu omo.dev. Tak jak jego twórcy obudowali Opencode własnymi narzędziami, tak my robimy to samo dla wszystkich dostępnych agentów. Całość składa się z wielu warstw, które razem sprawiają, że agent „wie, co robi”, pracując z Vibe Configuratorem w Productive24AI.
Agenta inicjujemy bezpośrednio w repozytorium użytkownika. Znajduje się dokładnie w miejscu, w którym ma pracować, i ma dostęp do zasobów potrzebnych do wykonania zadania. Pracę zaczyna od wczytania pliku z instrukcjami inicjalnymi, który wyjaśnia mu, gdzie się znajduje i jak działa konfiguracja Productive24AI. To skondensowana dawka wiedzy ładowana przy każdej rozmowie, dlatego musi zawierać wszystko, co istotne, ale jednocześnie nie może niepotrzebnie zapychać kontekstu i marnować tokenów.
Oprócz tej początkowej „bomby wiedzy” wyposażamy agenta w zestaw umiejętności (skills), które pomagają mu efektywnie wykonywać określone zadania. Projektowanie aplikacji, przygotowanie planu prac, edycja dokumentacji, obsługa uprawnień czy pomoc przy operacjach Git – to wszystko są umiejętności, które agent wykorzysta wtedy, gdy będą potrzebne. Użytkownik nie musi znać ich wszystkich; agent sam dobiera właściwe do sytuacji. Dodatkowo ma „pod ręką” pliki szczegółowo opisujące bardziej złożone elementy systemu. Nie są one ładowane zawsze, aby nie zajmować kontekstu, ale pozostają łatwo dostępne, gdy pojawi się taka potrzeba.
Narzędzia są najważniejszą częścią naszego zestawu. Elementy systemu Productive24AI często składają się z kilku lub kilkunastu plików różnych typów. Agent mógłby tworzyć je wszystkie ręcznie, ale byłoby to nieefektywne i kosztowne pod względem tokenów. Większość tych plików ma znaną strukturę, którą trzeba jedynie dostosować do konkretnego przypadku. Dlatego udostępniamy narzędzia do tworzenia i modyfikowania tych elementów. Niektóre operacje – na przykład zmiana jednego ustawienia w wielu miejscach – są znacznie bardziej efektywne przy użyciu narzędzi systemowych. Agent jest poinstruowany, jak w takich sytuacjach optymalizować wykorzystanie tokenów.
Mamy pliki opisujące działanie poszczególnych elementów systemu, ale nic nie jest tak dokładne jak pełna dokumentacja platformy. Dlatego udostępniamy również narzędzia pozwalające wyszukiwać konkretne informacje w dokumentacji. Jeśli coś nie jest jasne, wystarczy tool call, aby agent otrzymał sprawdzone informacje. Pracujemy w przeglądarce, a agent jest z nami w tym samym oknie. Kiedy coś zrobi, możemy poprosić go o pokazanie efektu. Gdy skończy pracę, może wysłać powiadomienie. To kolejna warstwa narzędzi, która sprawia, że współpraca jest po prostu wygodna.
GitOps, który wybraliśmy jako podstawę architektury P24, ma wiele zalet. Nie jest to filozofia wymagająca doktoratu, ale uczciwie trzeba przyznać, że nie jest też czymś, co przychodzi całkowicie samo. Jeśli użytkownik chce i nada agentowi odpowiednie uprawnienia, może on wykonać te operacje za niego. Wystarczy poprosić, aby zmiana trafiła na produkcję, a użytkownik zostanie poprowadzony przez proces wdrożenia i ewentualnego rozwiązywania konfliktów.
Łącznie oferujemy trzy zestawy narzędzi MCP. Są podzielone w taki sposób, aby optymalizować rozmiar kontekstu. Zapewniają pełen dostęp do możliwości platformy – od przewodnika po aktualnej stronie, przez Vibe Configurator, który przygotuje aplikację, po eksperta Git wdrażającego zmiany i kontrolera sprawdzającego zgodność aplikacji z wymaganiami.
Oczywiście Productive24AI to nie tylko platforma. Z perspektywy użytkownika to przede wszystkim aplikacja i konfiguracje, które się w niej znajdują. Dlatego razem z agentem korzystamy również z „Wiedzy o projekcie” – dokumentu, który można edytować samodzielnie lub z pomocą LLM-a. To właśnie tam utrzymujemy informacje, zasady i dobre praktyki dotyczące pracy z konfiguracją. Jeśli organizacja chce ustalić konkretny sposób pracy i oczekuje, że agent będzie tych zasad pilnował, jest to idealne miejsce na zapisanie takich ustaleń.
Zbudowaliśmy to rozwiązanie w taki sposób, ponieważ znamy zarówno Productive24AI, jak i agenty kodujące. Wiemy, jak się z nimi pracuje, i rozumiemy możliwości oraz ograniczenia platformy. Opisane wyżej funkcje nie wyczerpują oczywiście całego spektrum możliwości. Możemy tworzyć dokumentację dla poszczególnych modułów, wyszukiwać błędy, generować raporty zmian, przygotowywać specyfikacje rozwiązań i wykonywać wiele innych zadań. Celem tego tekstu nie było pokazanie wszystkiego, co można zrobić w Productive24AI. Chcieliśmy pokazać coś innego: że to nie są czary. To nie jest przypadek ani efekt „magicznego promptu”, po którym system sam z siebie zaczął działać.
To zaplanowana i przemyślana architektura – zestaw wiedzy, narzędzi, reguł i procesów, które razem sprawiają, że korzystanie z dowolnego agenta do pracy z Productive24AI jest tak łatwe, szybkie i przewidywalne, jak to tylko możliwe.
MVP w kilka dni!
Przetestuj możliwości Productive24AI w swoich procesach!
do naszego newslettera i bądź na bieżąco ze świeżymi artykułami ze świata produktywności.
Wypróbuj Productive24AI bez ryzyka
