- Jak agent AI uczy się na błędach zespołu? Audyt artefaktów i doskonalenie skilli - 27 października 2026
- Co zmienia się dla klienta, gdy partner wdrożeniowy pracuje z agentami AI? - 26 października 2026
- Jak wygląda wytwarzanie oprogramowania z agentami AI w praktyce? Proces eVolpe krok po kroku - 22 października 2026
Agent AI nie uczy się na błędach sam. Model językowy nie zmienia się między sesjami, więc lekcja przetrwa tylko wtedy, gdy ktoś ją zapisze. Uczy się zespół: regularnie audytuje artefakty pracy agenta (raporty, kod, zgłoszenia, poprawki), a wnioski zapisuje w skillach, czyli wersjonowanych instrukcjach, które agent czyta przy kolejnym zadaniu. W eVolpe instrukcja prowadzonego tak agenta przeszła pięć zmian wersji w pięć tygodni.
W skrócie: agent proponuje zmiany, człowiek o nich decyduje, a skill rośnie kolejnymi wersjami. Audyt artefaktów odpowiada na pytanie, które błędy się powtarzają i skąd się biorą. Każda zmiana skilla dostaje numer wersji i uzasadnienie, a jej skutek sprawdzamy w następnym przebiegu agenta.
Czy agent AI w ogóle uczy się na błędach?
Agent AI zbudowany na modelu językowym nie uczy się na błędach w taki sposób jak człowiek. Wagi modelu są zamrożone po treningu, a kontekst sesji znika po jej zamknięciu. Jeśli agent we wtorek źle sklasyfikował dane, w środę popełni ten sam błąd, chyba że ktoś zapisze poprawną regułę w miejscu, które agent czyta na starcie zadania. Zdanie „agent się nauczył” oznacza w praktyce, że zespół zmienił jego instrukcje.
Agent ma do dyspozycji trzy rodzaje pamięci. Kontekst sesji działa od razu, ale znika po zakończeniu rozmowy. Wagi modelu zmienia tylko dostawca albo zespół, który robi fine-tuning, co jest kosztowne i trudne do cofnięcia. Pamięć zewnętrzna to pliki instrukcji, skille i bazy wiedzy. Tylko pamięć zewnętrzna jest w pełni pod kontrolą zespołu. Przegląd badań Adaptation of Agentic AI (arXiv, 2025) opisuje pamięć i biblioteki skilli jako osobne od dotrenowania modelu mechanizmy adaptacji agentów.
Brak takiej pętli kosztuje tym więcej, im szerzej zespół korzysta z AI. Raport DORA 2025, oparty na ankiecie wśród blisko 5 tys. specjalistów IT, pokazuje, że 90% respondentów używa AI w pracy. Główny wniosek raportu brzmi: AI działa jak wzmacniacz, który powiększa zarówno mocne strony zespołów, jak i ich dysfunkcje (Google DORA, 2025). Zespół, który nie wyciąga wniosków z błędów agenta, dostaje te same błędy szybciej i w większej skali.
Czym jest skill agenta AI?
Skill agenta AI to folder z plikiem SKILL.md, który zawiera nazwę, opis i instrukcję wykonania określonego zadania, a opcjonalnie także skrypty, szablony i materiały referencyjne. Format Agent Skills opracował Anthropic, a 18 grudnia 2025 r. opublikował jego specyfikację jako otwarty standard (agentskills.io). Na starcie agent zna tylko nazwę i opis każdego skilla. Pełną instrukcję wczytuje dopiero wtedy, gdy zadanie pasuje do opisu.
Dla nauki na błędach najważniejsze jest to, że skill jest zwykłym plikiem tekstowym. Można go wersjonować w Git, porównywać zmiany między wersjami, przypisać mu właściciela i cofnąć nietrafioną poprawkę. Skill staje się w ten sposób pamięcią zespołu zapisaną w formie, którą agent potrafi przeczytać. Autor pracy Knowledge Activation (arXiv, 2026) twierdzi wprost, że wąskim gardłem w agentycznym wytwarzaniu oprogramowania jest architektura wiedzy, a nie możliwości modelu.
Skill nie jest jedynym miejscem, w którym można zapisać lekcję. Wybór miejsca zależy od tego, czy lekcja dotyczy jednej rozmowy, całego projektu, powtarzalnej procedury czy faktów.
| Gdzie zapisać lekcję | Kiedy agent ją widzi | Czy przetrwa sesję | Czy da się wersjonować | Do czego nadaje się najlepiej |
| Prompt w czacie | tylko w tej rozmowie | nie | nie | jednorazowe doprecyzowanie zadania |
| Plik projektu (np. CLAUDE.md, AGENTS.md) | przy każdej pracy w danym repozytorium | tak | tak | ogólne zasady i konwencje projektu |
| Skill (SKILL.md) | gdy zadanie pasuje do opisu skilla | tak | tak | powtarzalna procedura z regułami i wyjątkami |
| Baza wiedzy (RAG) | gdy wyszukiwanie zwróci właściwy fragment | tak | częściowo | fakty i dokumentacja, nie procedury |
Które artefakty warto audytować?
Artefakt to każdy trwały ślad pracy agenta lub zespołu, z którego da się odtworzyć, co zostało zrobione i dlaczego. Do audytu najlepiej nadają się artefakty, które pokazują różnicę między tym, co oddał agent, a tym, co ostatecznie zaakceptował człowiek. Ta różnica jest najczystszym sygnałem błędu, bo nie wymaga interpretacji: ktoś coś poprawił, więc coś było nie tak.
| Artefakt | Jaki błąd ujawnia | Co może trafić do skilla |
| Diff i merge request | co człowiek zmienił w wyniku agenta przed akceptacją | konwencja kodu, wzorzec architektoniczny |
| Komentarze z code review | uwagi, które recenzenci powtarzają | reguła typu „zawsze / nigdy” z przykładem |
| Reverty i hotfixy | zmiana, która przeszła review, ale zawiodła | krok weryfikacji przed oddaniem pracy |
| Zgłoszenia w systemie ticketowym | błędy, które zauważyli użytkownicy | przypadek brzegowy do obsłużenia |
| Raport lub log przebiegu agenta | miejsca, w których agent zgadywał albo obchodził ograniczenie | brakujące źródło danych, limit narzędzia |
| Errata | liczba lub fakt poprawiony po przekazaniu wyniku | reguła weryfikacji danych |
| Decyzje zespołu (planning, retro) | rozjazd między rekomendacją agenta a wyborem ludzi | nowe kryterium priorytetu |
Nie każdy błąd jest błędem agenta. Jeśli zespół kilka tygodni z rzędu wybiera inne zadania niż te, które agent stawia na szczycie listy, problem może leżeć w kryteriach rankingu zapisanych w skillu, a nie w ludziach ani w modelu. Dlatego audyt obejmuje także decyzje zespołu. Rozjazd między rekomendacją a wyborem to informacja do poprawienia instrukcji, a nie powód do oceniania kogokolwiek.
Jak przeprowadzić audyt artefaktów krok po kroku?
Audyt artefaktów to cykliczny przegląd śladów pracy agenta, zakończony listą konkretnych propozycji zmian w skillu. W naszych projektach sprawdza się siedem kroków:
- Ustal okno i zakres. Audyt obejmuje konkretny okres, na przykład tydzień, i jeden skill. Bez stałego okna dwa przeglądy są nieporównywalne.
- Zbierz artefakty, nie wrażenia. Diffy, komentarze z review, logi przebiegów, erraty. Opinia „agent czasem myli X” staje się danymi dopiero wtedy, gdy wskazuje konkretne przypadki.
- Sklasyfikuj każdy błąd. Brak wiedzy (agent nie znał reguły), błąd procesu (reguła była, ale kolejność kroków była zła), ograniczenie narzędzia (limit API, format odpowiedzi) albo problem danych (źródło niekompletne lub zmieniające się wstecz).
- Odróżnij przypadek od wzorca. Pojedynczy błąd zapisz w notatkach z audytu. Regułę w skillu pisz wtedy, gdy błąd wraca albo gdy jeden błąd ma wysoki koszt.
- Sformułuj zgłoszenie. Każde zgłoszenie ma trzy elementy: obserwację, dowód (odnośnik do artefaktu) i proponowaną zmianę w skillu. Agent może przygotować zgłoszenie sam, ale nie wprowadza zmiany.
- Podejmij decyzję. Właściciel skilla przyjmuje, odrzuca albo odkłada każde zgłoszenie. Decyzja ma datę i krótkie uzasadnienie.
- Wydaj nową wersję i sprawdź skutek. Zmiana dostaje numer wersji i wpis w changelogu. W następnym przebiegu sprawdź, czy błąd zniknął i czy poprawka nie wywołała nowego.
Kto powinien zmieniać skill: agent czy człowiek?
Skill powinien zmieniać człowiek, a agent powinien przygotowywać propozycje zmian. Agent dobrze widzi, gdzie instrukcja nie pasuje do rzeczywistości, bo trafia na ten rozjazd w trakcie pracy. Gorzej ocenia, czy poprawka nie zepsuje innego przypadku, czy reguła nie jest reakcją na jednorazowy incydent i czy zgadza się z polityką firmy. Podział ról „agent proponuje, człowiek decyduje” łączy obie te perspektywy.
Automatyczna edycja skilla przez agenta niesie trzy ryzyka. Pierwsze to dryf: drobne poprawki kumulują się, aż instrukcja przestaje opisywać proces, który zespół zaprojektował. Drugie to puchnięcie: reguły są dopisywane, ale nikt ich nie usuwa, więc skill zajmuje coraz więcej kontekstu i zaczyna sam sobie przeczyć. Trzecie to bezpieczeństwo: agent, który czyta dane z zewnątrz, może dostać spreparowaną treść i wpisać do skilla instrukcję, której nikt nie zatwierdził (prompt injection).
Istnieją podejścia, w których agent sam rozwija swoje skille. Przykładem jest framework EvoAgent (arXiv, 2026), łączący autonomiczne uczenie się skilli z delegowaniem zadań do wyspecjalizowanych subagentów. Takie rozwiązania mają sens w kontrolowanym środowisku z mocnymi testami. W systemach, które pracują na danych klientów, w CRM albo w procesach finansowych, zostajemy przy modelu, w którym agent proponuje, a człowiek zatwierdza.
Jak wygląda doskonalenie skilla w praktyce? Przykład z eVolpe
Od września 2026 r. agent AI w eVolpe co tydzień przygotowuje digest pomysłów na treści. Agent zbiera sygnały z systemu zgłoszeń, CRM i komunikatora firmowego, liczy agregaty i układa ranking tematów dla zespołu marketingu. Pracuje według jednej instrukcji przechowywanej w repozytorium GitLab, z numerem wersji i wskazanym właścicielem. Instrukcja zawiera zasadę: jeśli coś jest nieaktualne, agent to zgłasza, ale nie poprawia bez zgody właściciela.
Każdy przebieg agenta kończy się sekcją „Zgłoszenia do instrukcji”, w której agent opisuje rozjazdy między instrukcją a tym, co zastał w danych i narzędziach. W przebiegach od drugiego do szóstego agent przygotował kolejno 6, 7, 6, 6 i 5 zgłoszeń. O każdym decydował właściciel instrukcji. Między 1 września a 7 października 2026 r. instrukcja przeszła z wersji 1.0.0 do 1.4.0, a każda zmiana ma wpis w changelogu z datą i uzasadnieniem.
Ten przykład dotyczy agenta analitycznego, a nie agenta piszącego kod, ale mechanizm jest ten sam. Tabela pokazuje wybrane błędy i reguły, które po nich trafiły do instrukcji.
| Co poszło nie tak | Reguła, która trafiła do instrukcji |
| Liczb z pierwszego przebiegu nie dało się odtworzyć: agent klasyfikował projekty po nazwie produktu i łapał projekty spoza zakresu | jawna reguła klasyfikacji oraz obowiązek podawania wolumenów danych, żeby przebiegi były porównywalne |
| Agent wskazał jako źródło danych moduł, którego nie było w systemie | jako brakujące źródło można wskazać wyłącznie takie, którego istnienie sprawdzono w bieżącej sesji |
| Liczba z jednego tygodnia wyglądała na trend, a wynikała z jednego dużego zadania | liczba z jednego tygodnia nie trafia do tytułu bez doliczenia 3–4 tygodni wstecz |
| Wyszukiwanie po frazie pomijało warianty („za mali” i „zbyt mali”) | frazy rozszerzane o warianty, którymi faktycznie piszą handlowcy |
| Zespół dwa tygodnie z rzędu wybrał temat spoza rekomendacji agenta | zespół dostaje 3 tematy, w tym co najmniej jeden gotowy do napisania bez dodatkowych warunków |
| W jednym z raportów liczba 63% okazała się błędna (poprawnie: 56,6%) | błąd opisany erratą w pliku raportu; instrukcja zabrania poprawiania wyników po cichu |
Jedna z lekcji dotyczyła samego procesu zmian. Wersja 1.4.1, uzgodniona na spotkaniu, nie została zapisana w repozytorium. Kolejny przebieg agenta wykrył rozjazd między wersją w repozytorium a ustaleniami i opisał go w zgłoszeniach, zamiast samodzielnie wybrać jedną z wersji. Wniosek dla każdego zespołu: skill ma jedno źródło prawdy, a ustalenia z rozmów obowiązują agenta dopiero po zapisaniu ich w pliku.
Jakich błędów unikać przy doskonaleniu skilli?
Najczęstsze błędy przy doskonaleniu skilli wynikają z traktowania instrukcji jak notatnika, do którego tylko się dopisuje. Lista poniżej pochodzi z naszej pracy z instrukcjami agentów:
Jak sprawdzić, czy skill rzeczywiście się poprawia?
Najprostszy test to sprawdzenie, czy błąd, który był powodem zmiany, wraca w kolejnych przebiegach. Do tego dochodzą trzy wskaźniki, które da się liczyć bez specjalnych narzędzi: liczba zgłoszeń na przebieg, liczba errat (poprawek wyników już przekazanych ludziom) i liczba przypadków, w których człowiek musiał poprawić wynik agenta przed użyciem. W naszym przykładzie pięć przebiegów to za mało punktów, by mówić o trendzie.
Spadek liczby zgłoszeń nie zawsze oznacza poprawę. Może też znaczyć, że agent przestał zgłaszać rozjazdy albo że zmieniły się dane wejściowe. Zgłoszenia warto więc czytać jakościowo, a nie tylko je liczyć. Przy skillach używanych przez wiele osób przydaje się zestaw przypadków testowych: kilka zadań ze znanym poprawnym wynikiem, uruchamianych po każdej zmianie wersji. Każdy błąd, który doprowadził do zmiany skilla, jest dobrym kandydatem na nowy przypadek testowy.
Umów bezpłatną konsultację z ekspertem wdrożeniowym eVolpe
Wybierz dogodny dla siebie termin.
Najczęściej zadawane pytania
Nie. Model językowy nie zmienia się między sesjami. Agent „pamięta” błąd tylko wtedy, gdy błąd i poprawna reguła zostały zapisane w pamięci zewnętrznej, którą agent czyta: w skillu, pliku projektu albo bazie wiedzy.
Prompt działa tylko w jednej rozmowie. Skill to plik SKILL.md z nazwą, opisem i instrukcją, który agent wczytuje automatycznie, gdy zadanie pasuje do opisu. Skill przetrwa sesję, da się go wersjonować i przypisać mu właściciela.
Do reguł procesowych zwykle nie. Fine-tuning jest kosztowny, trudny do cofnięcia i nie pokazuje, która reguła wpłynęła na wynik. Skill zmienia się w kilka minut, a każdą zmianę widać w historii wersji.
W rytmie pracy agenta: przy agencie uruchamianym co tydzień po każdym przebiegu, przy agencie piszącym kod na retrospektywie sprintu. Regularność jest ważniejsza niż częstotliwość, bo tylko stałe okno pozwala porównać kolejne audyty.
Osoba odpowiedzialna za proces, który skill opisuje, a nie za narzędzie. Właściciel decyduje o zgłoszeniach, zatwierdza nowe wersje i odpowiada za to, żeby skill miał jedno źródło prawdy.
Technicznie tak, ale w systemach pracujących na danych firmowych rekomendujemy model, w którym agent przygotowuje zgłoszenia, a człowiek je zatwierdza. Automatyczne zmiany grożą dryfem instrukcji, ich puchnięciem i wstrzyknięciem niezatwierdzonych poleceń.
Nie. Format opracował Anthropic, ale od grudnia 2025 r. jest otwartym standardem, który obsługuje wiele narzędzi agentowych. Specyfikację i dokumentację publikuje agentskills.io.
Źródła
- Agent Skills — specyfikacja i dokumentacja otwartego standardu: https://agentskills.io/ (dostęp: 26.10.2026)
- The New Stack, „Agent Skills: Anthropic’s Next Bid to Define AI Standards”, 18.12.2025: https://thenewstack.io/agent-skills-anthropics-next-bid-to-define-ai-standards/
- Google DORA, „State of AI-assisted Software Development”, 2025: https://research.google/pubs/dora-2025-state-of-ai-assisted-software-development-report/
- Bakal G., „Knowledge Activation: AI Skills as the Institutional Knowledge Primitive for Agentic Software Development”, arXiv:2603.14805, 2026: https://arxiv.org/abs/2603.14805
- „Adaptation of Agentic AI: A Survey of Post-Training, Memory, and Skills”, arXiv:2512.16301, 2025: https://arxiv.org/abs/2512.16301
- „EvoAgent: An Evolvable Agent Framework with Skill Learning and Multi-Agent Delegation”, arXiv:2604.20133, 2026: https://arxiv.org/abs/2604.20133
- Jak agent AI uczy się na błędach zespołu? Audyt artefaktów i doskonalenie skilli - 27 października 2026
- Co zmienia się dla klienta, gdy partner wdrożeniowy pracuje z agentami AI? - 26 października 2026
- Jak wygląda wytwarzanie oprogramowania z agentami AI w praktyce? Proces eVolpe krok po kroku - 22 października 2026
