Metapoznawcza sztuczna inteligencja: jak nauczyć agenta samooceny

Poleciłem mojemu agentowi naprawić nieudany test. Agent odczytał błąd, zidentyfikował niezgodność asercji, zmienił oczekiwaną wartość na zgodną z faktycznym wynikiem i zgłosił: „Test naprawiony. Wszystkie testy przechodzą.” Miał rację. Test przechodził. Naprawa była też całkowicie błędna.

Test nie przechodził, ponieważ funkcja zwracała nieprawidłowe dane. Agent „naprawił” test, sprawiając, że oczekiwał złej odpowiedzi. Wykonał moją instrukcję perfekcyjnie: napraw nieudany test. Chodziło mi o: napraw kod, który test testuje. Agent nie miał mechanizmu pozwalającego rozróżnić te dwie interpretacje, ponieważ nic w jego zestawie instrukcji nie wymagało oceny dlaczego test nie przechodzi, zanim zdecyduje jak go naprawić.

Ta luka ma swoją nazwę. To luka między instrukcjami na poziomie działań a instrukcjami metapoznawczymi. Większość ludzi pisze wyłącznie te pierwsze.

TL;DR

Istnieją dwa poziomy instrukcji dla agentów AI. Instrukcje na poziomie działań mówią agentowi, co ma robić: „waliduj dane wejściowe”, „pisz testy”, „stosuj konwencje REST”. Instrukcje metapoznawcze mówią agentowi, jak oceniać, czy robi to dobrze: „jeśli zauważysz, że mówisz powinno zamiast zrobiłem, nie zweryfikowałeś”, „jeśli trzy poprawki zawiodą, zatrzymaj się i zakwestionuj architekturę”, „pewność siebie to nie dowód”. Większość konfiguracji agentów zawiera wyłącznie instrukcje na poziomie działań. Warstwa metapoznawcza oddziela agenta produkującego wiarygodnie wyglądające wyniki od agenta produkującego poprawne wyniki. Prowadzę produkcyjny system metapoznawczy od dziewięciu miesięcy z siedmioma nazwanymi trybami awarii, sześciokryterialną bramką dowodową i detekcją języka zastępczego egzekwowaną przez 95 hooków.

Dwa poziomy instrukcji dla agenta

Każda instrukcja dla agenta działa na jednym z dwóch poziomów.

Instrukcje na poziomie działań definiują zachowanie:

# Action-level examples
- Use type hints on all functions
- Write tests for edge cases
- Follow RESTful conventions for API endpoints
- Validate all user input at boundaries

Instrukcje na poziomie działań są konieczne. Mówią agentowi, jak wygląda poprawne zachowanie. Dzielą jednak wspólne ograniczenie strukturalne: zakładają, że agent będzie je wiernie wykonywał. Nie uwzględniają tego, jak agent ocenia własną zgodność z nimi.

Instrukcje metapoznawcze definiują samomonitorowanie:

# Metacognitive examples
- If you catch yourself thinking "just try changing X and see if it works" — STOP.
  That's a signal to investigate, not guess.
- If you've searched the same files three times — you're stuck.
  Step back and question your assumptions.
- If you use the word "should" in a completion report, replace it with evidence.
  Run the command. Paste the output.
- After three failed fixes, stop fixing. The problem is architectural.

Rozróżnienie ma znaczenie, ponieważ instrukcje na poziomie działań mówią agentowi, jak wygląda cel. Instrukcje metapoznawcze mówią agentowi, jak wykryć, że zmierza w złym kierunku. Jedne zapobiegają błędnym działaniom. Drugie zapobiegają błędnemu rozumowaniu: wzorcom myślenia, które w pierwszej kolejności prowadzą do błędnych działań.

Projekt obra/superpowers na GitHub jako pierwszy sformułował to rozróżnienie, nazywając je „uczeniem AI obserwowania własnego wewnętrznego rozumowania pod kątem sygnałów awarii”.¹ Kluczowe spostrzeżenie: większość umiejętności działa na poziomie działań (rób X, nie rób Y). Poziom metapoznawczy działa inaczej (zauważ, kiedy zamierzasz zrobić Y).

Tabela fałszywych dowodów

Najskuteczniejszym narzędziem metapoznawczym, jakie zbudowałem, jest tabela definiująca, co NIE stanowi dowodu.²

Gdy mówię agentowi „zweryfikuj swoją pracę”, agent produkuje weryfikację. Jednak weryfikacja ta jest często przeformułowaniem intencji, a nie demonstracją wyniku. „Testy powinny przechodzić.” „Implementacja stosuje dobre praktyki.” „Jestem pewien, że to jest poprawne.” Każde z tych stwierdzeń brzmi jak dowód. Żadne z nich nie jest dowodem.

Tabela fałszywych dowodów z wyprzedzeniem blokuje konkretne skróty, nazywając je:

Trzecia kolumna jest źródłem wartości. Bez niej agent wypełnia drugą kolumnę wiarygodnie brzmiącymi przeformułowaniami własnej pewności. Z nią tabela nazywa i blokuje każdy konkretny skrót zanim agent go zastosuje.³

Tabela to nie prompt engineering. To architektura poznawcza. Tabela nie mówi agentowi, co ma robić inaczej. Mówi mu, czego szukać we własnym wyjściu. Agent monitoruje własne odpowiedzi względem kolumny NIEWYSTARCZAJĄCE i gdy wykryje dopasowanie, wie, że musi zastąpić skrót faktycznym dowodem.

Wzorzec się skaluje. Można dodać dowolne twierdzenie specyficzne dla domeny. Dla przeglądów bezpieczeństwa: „Brak podatności” wymaga „konkretnych klas podatności sprawdzonych i wyników”, a nie „Przejrzałem kod.” Dla dostępności: „Zgodność z WCAG” wymaga „wyników audytu axe lub Lighthouse”, a nie „Sprawdziłem kontrast.”

Nazwane tryby awarii jako bariery metapoznawcze

Ludzie mają nazwane zniekształcenia poznawcze: efekt potwierdzenia, zakotwiczenie, efekt Dunninga-Krugera. Nazwy mają znaczenie. Gdy potrafisz nazwać zniekształcenie, możesz go wypatrywać. Agenci AI potrzebują tego samego słownictwa dla swoich wzorców awarii.

Udokumentowałem siedem trybów awarii, które mój agent wykazywał wielokrotnie, nadałem każdemu nazwę i dodałem sygnały wykrywania:⁴

Nazwy czynią awarie wykrywalnymi. Bez nich agent produkuje Miraż pewności, a ani agent, ani użytkownik nie rozpoznaje tego jako wzorca. Z nimi instrukcja brzmi: „Jeśli zauważysz, że wykazujesz jakikolwiek nazwany tryb awarii, ZATRZYMAJ SIĘ i zacznij ponownie od kroku Ocena.”

Monitorowanie jest metapoznawcze w ścisłym znaczeniu: agent obserwuje własny proces poznawczy (czy pomijam weryfikację? czy używam pewności jako substytutu dowodów?) zamiast swoich wyników (czy ten kod jest poprawny?). Monitorowanie odbywa się zanim agent wyprodukuje wynik, dlatego wyłapuje błędy, które przegląd na poziomie wyników pomija.

Własne referencyjne implementacje umiejętności Anthropic potwierdzają to podejście. Analiza ich 16 oficjalnych umiejętności Claude Code ujawniła wzorce strukturalne w skutecznym projektowaniu instrukcji dla agentów. Zakazy („NIGDY nie rób X”) okazały się znacznie skuteczniejsze niż sugestie („rozważ Y”), ponieważ nazywają konkretne ominięcie, a nie ogólne działanie.⁵ Nazwane tryby awarii to konkretne zakazy: „NIGDY nie wykazuj Fantomowej weryfikacji” przewyższa „zawsze uruchamiaj testy”, ponieważ blokuje ominięcie, a nie powtarza działanie.

Detekcja języka zastępczego

Najprostszy monitor metapoznawczy, jaki wdrożyłem, wykrywa konkretne słowa w wynikach agenta:

Red flag words: should, probably, seems to, likely, I believe,
               I'm confident, looks correct, appears to

Za każdym razem, gdy agent użyje jednego z tych słów w raporcie ukończenia, samo słowo jest dowodem niewystarczającej weryfikacji.⁶ „Testy powinny przechodzić” oznacza, że agent ich nie uruchomił. „Wydaje się działać” oznacza, że agent tylko zerknął. „Jestem pewien” oznacza, że agent zastępuje stan wewnętrzny dowodem zewnętrznym.

Implementacja jest mechaniczna. System hooków przechwytuje wynik agenta i flaguje język zastępczy. Agent następnie zastępuje słowo zastępcze weryfikacją, którą powinien był wykonać:

• „Testy powinny przechodzić” staje się: uruchamia testy, wkleja wynik pokazujący 0 błędów
• „Wygląda poprawnie” staje się: cytuje konkretną asercję lub sprawdzenie potwierdzające poprawność
• „Jestem pewien” staje się: wymienia dowody tworzące tę pewność

Wzorzec pochodzi z prac obra nad weryfikacją przed ukończeniem: „Własne wybory słów AI sygnalizują niewystarczające dowody.”¹ Analogia z naukami kognitywnymi jest realna. W ludzkiej metapoznawczości trafność samooceny („Rozumiem to”) słabo koreluje z faktycznym zrozumieniem. Ludzie, którzy mówią „Rozumiem”, często nie rozumieją. Ludzie, którzy potrafią wyjaśnić, zwykle rozumieją. To samo dotyczy agentów AI: agent, który potrafi wskazać konkretne dowody, rozumie problem. Agent, który mówi „Jestem pewien”, może nie rozumieć.

Trójstopniowy wyłącznik awaryjny

Metapoznanie to nie tylko wykrywanie błędnego rozumowania. To także wykrywanie, kiedy należy się zatrzymać.

Zasada trójstopniowej eskalacji: jeśli trzy próby naprawy tego samego problemu zawiodły, agent musi się zatrzymać i fundamentalnie zakwestionować architekturę.⁷ Nie próbować czwartej poprawki. Nie szukać innego kąta w ramach tego samego podejścia. Zatrzymać się. Cofnąć. Zapytać, czy problem tkwi w rozwiązaniu, czy w definicji problemu.

Zasada działa jak wyłącznik awaryjny dla pętli debugowania. Bez niej agenci wchodzą w coś, co nazywam Spiralą napraw: każda nieudana próba rodzi nową teorię, która rodzi nową poprawkę, która zawodzi, co rodzi kolejną teorię. Agent może przejść przez dziesiątki poprawek, nigdy nie kwestionując, czy pracuje nad właściwym problemem. Incydent niekontrolowanych 23 agentów był wersją szerokościową tego zjawiska: agenci osiągnęli konsensus w sprawie złego pytania, ponieważ żaden mechanizm metapoznawczy nie zapytał „czy to pytanie jest poprawnie zdefiniowane?”

Zasada trzech poprawek działa, ponieważ wymusza przejście fazowe w rozumowaniu agenta. Poprawki 1-3 działają w ramach aktualnego modelu mentalnego. Poprawka 4 (która w rzeczywistości jest „przestań naprawiać”) zmusza agenta do skonstruowania nowego modelu mentalnego. W praktyce oznacza to zazwyczaj ponowne przeczytanie błędu od początku, ponowne zbadanie założeń lub poproszenie użytkownika o wyjaśnienie — a wszystkie te działania są produktywniejsze niż czwarte zgadywanie.

Przed i po: co się zmienia

Oto konkretny przykład. Poprosiłem agenta o dodanie walidacji danych wejściowych do endpointu API.

Bez instrukcji metapoznawczych:

Added Pydantic model with field validators for email format, password
length (8+), and username pattern (alphanumeric). Tests should pass.
The implementation follows FastAPI best practices.

Wynik zawiera trzy sygnały zastępcze: „should pass” (nie uruchomił testów), „follows best practices” (nie nazwał których praktyk) i brak dowodów rozważenia przypadków brzegowych. Miraż pewności opakowany w Pusty raport.

Z instrukcjami metapoznawczymi (to samo zadanie, ten sam agent):

Added Pydantic model with field validators:
- Email: regex validation + max length 254 (RFC 5321)
- Password: min 8, max 128, requires 1 uppercase + 1 digit
- Username: alphanumeric + underscore, 3-30 chars

Test output (just ran):
  tests/test_auth.py::test_valid_registration PASSED
  tests/test_auth.py::test_invalid_email_rejected PASSED
  tests/test_auth.py::test_short_password_rejected PASSED
  tests/test_auth.py::test_empty_username_rejected PASSED
  tests/test_auth.py::test_unicode_username_rejected PASSED
  5 passed in 0.34s

Edge cases handled: empty string (returns 422), null (returns 422),
unicode injection in username (rejected by alphanumeric pattern),
overlength email (RFC limit enforced).

Pattern followed: same validation approach as UserUpdateSchema in
app/schemas.py line 45.

Różnica nie polega na tym, że drugi agent napisał lepszy kod. Obaj agenci mogli napisać identyczny kod. Różnica polega na tym, że drugi agent zweryfikował swoją pracę względem konkretnych kryteriów dowodowych i zaraportował dowody zamiast swojej pewności.

Budowanie własnej warstwy metapoznawczej

Framework jest przenośny. Nie potrzeba mojego konkretnego systemu. Potrzebne są trzy komponenty:

1. Tabela fałszywych dowodów. Zdefiniuj, co NIE stanowi dowodu dla twierdzeń, które agent najczęściej formułuje. Zacznij od sześciu kryteriów powyżej i dodaj wiersze specyficzne dla domeny. Trzecia kolumna (NIEWYSTARCZAJĄCE) jest źródłem wartości.

2. Nazwane tryby awarii. Udokumentuj od trzech do pięciu sposobów, w jakie agent najczęściej zawodzi. Nadaj każdemu nazwę. Dodaj sygnały wykrywania. Dołącz instrukcję: „Jeśli zauważysz, że wykazujesz jakikolwiek nazwany tryb awarii, zatrzymaj się i dokonaj ponownej oceny.”

3. Detekcja języka zastępczego. Wymień konkretne słowa sygnalizujące niewystarczającą weryfikację w danej domenie. Dodaj instrukcję: „Zastąp każde słowo zastępcze dowodem, który wyeliminowałby niepewność.”

Te trzy komponenty składają się w warstwę metapoznawczą, która nadbudowuje się nad dowolnymi instrukcjami na poziomie działań. Instrukcje na poziomie działań definiują, jak wygląda poprawne zachowanie. Warstwa metapoznawcza definiuje, jak agent wykrywa własne odchylenie od poprawnego zachowania.

Implementacja może być tak prosta, jak dodanie sekcji do pliku CLAUDE.md lub AGENTS.md:

## Self-Monitoring

### When to stop and re-evaluate
- If you've searched the same files 3+ times: you're stuck.
- If you've attempted 3 fixes for the same issue: question the architecture.
- If you use "should" or "probably" in your response: replace with evidence.

### What doesn't count as evidence
[your false evidence table here]

### Named failure modes to watch for
[your failure modes here]

To, czy egzekwowanie odbywa się przez hooki (deterministyczne, nie można ich pominąć), pliki reguł (ładowane do kontekstu), czy instrukcje inline (polegające na zgodności modelu), determinuje niezawodność warstwy metapoznawczej. Hooki są najsilniejsze, ponieważ przechwytują na poziomie użycia narzędzi, a nie na poziomie promptu. Jednak nawet instrukcje metapoznawcze na poziomie promptu mierzalnie poprawiają jakość wyników agenta, ponieważ zmieniają kryteria oceny agenta, a nie tylko jego działania.

Czego metapoznanie nie potrafi

Programowanie metapoznawcze czyni agentów AI bardziej niezawodnymi. Nie czyni ich mądrymi.

Tabela fałszywych dowodów wyłapuje konkretne skróty. Nie wyłapuje nowych skrótów, których tabela nie wymienia. Nazwane tryby awarii wykrywają znane wzorce. Nie wykrywają wzorców, które jeszcze nie zostały nazwane. Detekcja języka zastępczego wyłapuje powierzchowne zastępowanie pewności za dowody. Nie wyłapuje agenta, który szczerze przekonał siebie (w jakimkolwiek sensie „przekonał” ma zastosowanie), że błędny wynik jest poprawny.

Bardziej fundamentalnie, instrukcje metapoznawcze przybliżają gust, ale go nie wytwarzają. System Jiro może zapobiec except: pass i wymusić dowody z testów. Nie potrafi jednak określić, czy architektura jest właściwa, czy nazewnictwo oddaje intencję, czy rozwiązanie adresuje faktyczny problem w odróżnieniu od deklarowanego. Te oceny wymagają rodzaju rozumowania kontekstowego, które obecne modele przybliżają, ale nie wykonują niezawodnie.

Ktoś odpowiedział na jednego z moich tweetów o systemie Jiro: „W zasadzie próbujesz nauczyć pętlę powściągliwości, gustu i czegoś zbliżonego do moralnej pauzy — rzeczy, przeciw którym bazowy wzorzec Ralph jawnie optymalizuje w imię przepustowości.”⁸

Mieli rację. Programowanie metapoznawcze to rusztowanie strukturalne dla jakości, których maszyna nie posiada. Rusztowanie jest nośne. Bez niego maszyna produkuje Miraże pewności na skalę. Z nim maszyna produkuje zweryfikowane wyniki na skalę. Przepaść między tymi dwoma rezultatami to różnica między agentem, któremu można zaufać, że będzie pracował przez noc, a agentem, którego trzeba niańczyć.

Ale rusztowanie to nie budynek. Budynek (gust, osąd, zdolność rozpoznania, kiedy właściwą odpowiedzią na pytanie jest inne pytanie) pozostaje ludzki. Na razie.

Kluczowe wnioski

Dla inżynierów budujących systemy agentowe:

• Pisz instrukcje metapoznawcze, nie tylko instrukcje na poziomie działań. Instrukcje na poziomie działań definiują poprawne zachowanie. Instrukcje metapoznawcze definiują, jak agent wykrywa własne odchylenie od poprawnego zachowania. Ten drugi rodzaj oddziela wiarygodnie wyglądające wyniki od zweryfikowanych wyników.

• Nazwij tryby awarii swojego agenta. Gdy wzorzec awarii ma nazwę (Miraż pewności, Fantomowa weryfikacja, Spirala skrótów), agent może go wypatrywać. Nienazwane awarie powtarzają się w nieskończoność.

Dla zespołów skalujących przepływy pracy wspomagane AI:

• Zbuduj tabelę fałszywych dowodów przed skalowaniem. Zdefiniuj, co NIE stanowi dowodu dla każdego twierdzenia, które formułuje agent. Trzecia kolumna (NIEWYSTARCZAJĄCE) z wyprzedzeniem blokuje konkretne skróty, które agenci stosują, gdy zostaną poproszeni o „weryfikację.”

• Język zastępczy to wiarygodny sygnał. Za każdym razem, gdy agent mówi „powinno”, „prawdopodobnie” lub „jestem pewien” w raporcie ukończenia, agent nie wykonał weryfikacji, którą deklaruje. Wykrywaj i zastępuj mechanicznie.

Audyt metapoznawczy

Chcesz ocenić własne instrukcje dla agenta? Interaktywne narzędzie poniżej analizuje dowolny plik CLAUDE.md, AGENTS.md lub prompt systemowy i ocenia go w wymiarach metapoznawczych opisanych w tym poście.

Wklej instrukcje dla agenta, a audyt zidentyfikuje: jaki procent instrukcji jest na poziomie działań, a jaki metapoznawczy, które nazwane tryby awarii są pokryte, czy istnieje detekcja języka zastępczego i gdzie są luki.

Część serii Claude Code Mastery, dokumentującej infrastrukturę autonomicznego rozwoju AI: od hooków wymuszających deterministyczną kontrolę przez zarządzanie kontekstem jako dyscyplinę architektoniczną po wieloagentową deliberację wyłapującą martwe punkty pojedynczego agenta. Filozofia inżynierii kumulatywnej leżąca u podstaw systemu wyjaśnia, dlaczego każdy komponent przyspiesza wszystko, co zbudowano po nim.