Dziewięciu agentów AI rozwiązuje Olimpiadę Matematyczną na maksimum punktów. Jak zaprojektowałem specjalistów, bramki i izolowanego sędziego

W kwietniu sprawdziłem prosty eksperyment. Wkleiłem do Claude Opus zadanie P6 z EuMO 2026 (teoria liczb, dzielniki) i poprosiłem o pełny dowód. Dostałem cztery strony LaTeX-u. Wyglądało jak rozwiązanie olimpijskie.

Wysłałem to do osobnej instancji Claude'a w roli „sędziego IMO” z instrukcją „punktuj w skali 0-7 zgodnie z rubryką olimpijską”.

To była lekcja. LLM piszący „dowód” nie tworzy dowodu. Tworzy tekst, który dowód przypomina. Różnica liczy się tam, gdzie poprawność jest mierzalna - matematyka, kod, kontrakty prawne, oferty handlowe z konsekwencjami finansowymi.

Zbudowałem zespół dziewięciu agentów AI, który rzeczywiście rozwiązał całą olimpiadę. Nie jeden mądrzejszy model. Dziewięciu specjalistów z konkretnymi rolami, sześcioma bramkami jakości i izolowanym sędzią, który fizycznie nie widzi rozumowania producenta.

Ten artykuł to poradnik, jak takie zespoły projektować.

O tym, czym w ogóle są wzorce koordynacji agentów, pisałem szczegółowo w artykule Jeden agent AI to za mało. Pięć wzorców zespołów według Anthropic. Tu pokazuję, jak te wzorce stosuje się w bojowym pipelinie na bardzo trudnym problemie.

Dlaczego pojedynczy agent nie wystarcza dla problemów typu olimpijskiego

Olimpiada matematyczna ma jedną brutalnie uczciwą cechę. Albo rozwiązanie jest poprawne, albo nie jest.

Nie ma „prawie dobrze”. Nie ma „kierunek był słuszny”.

Juror IMO daje 0, 1, 2, 3, 4, 5, 6, 7 punktów według precyzyjnej rubryki, w której 6 nie jest „blisko 7”, tylko „rozwiązanie kompletne z jedną drobną usterką”. Skok 6 do 7 wymaga zupełnej bezbłędności.

To jest dokładnie ten typ problemu, na którym LLM-y przegrywają. Generują tekst, który z pozoru opisuje prawidłowy łańcuch rozumowania, ale przemyca skróty.

„Bez utraty ogólności”. „Analogicznie pokazujemy”. „Jak wiadomo z twierdzenia X”.

Każdy z tych zwrotów to mały akt wiary, że czytelnik wypełni lukę. Olimpijski juror nie wypełnia luk. Liczy punkty za to, co napisane.

Trzy ograniczenia jednego agenta projektują architekturę zespołu:

Architektura w jednym slajdzie

Pipeline ma dziewięciu agentów organizowanych w cztery warstwy.

Przepływ pracy dla pojedynczego zadania:

ZADANIE  ────►  orchestrator
                    │
                    ├──► router         GATE R (domena z confidence)
                    │
                    ├──► strategist-<dom>   GATE A (plan + lematy + trudność)
                    │
                    ├──► prover         GATE B (pdflatex compile)
                    │       │
                    │       ├──► sympy check (numeryczna weryfikacja)
                    │       │
                    │       ▼
                    │   GREP-GATE (anti-handwaving)
                    │   SYMPY-GATE (kandydat odpowiedzi pasuje)
                    │
                    └──► verifier (worktree)  GATE C (werdykt + 0-7)
                                │
                                ▼
                        DIAGNOSTYCZNE KIEROWANIE
                        ├── implementation_gap → ponowne wywołanie provera
                        ├── framework_ceiling  → strategist (Tryb: revision)
                        ├── missing_technique  → strategist (Tryb: revision)
                        └── wrong_answer       → strategist (Tryb: fresh, rewrite)

Każda strzałka to jasno zdefiniowane wywołanie z konkretnym promptem, sprecyzowanym artefaktem wyjściowym i twardą bramką akceptacji. Nie ma „dogadajcie się między sobą”. Każdy agent dostaje precyzyjną instrukcję, gdzie zapisać wynik i jak ma wyglądać prawidłowe wyjście.

Decyzja architektoniczna 1: dlaczego router używa Sonneta, a strategiści Opusa

Router ma jedno zadanie. Przeczytać treść zadania i wybrać domenę. To jest klasyfikacja, nie rozumowanie.

Heurystyki są proste:

• „trójkąt + okrąg” → geometria
• „dzielniki + kongruencje” → teoria liczb
• „graf + ekstremum” → kombinatoryka
• „równanie funkcyjne + nierówność” → algebra

Claude Sonnet 4.6 robi to bezbłędnie w 95% przypadków i kosztuje sześć razy mniej niż Opus 4.7. Wsadzanie Opusa do tej roli to tak, jakby zatrudnić architekta IT do sortowania maili. Marnotrawstwo i wolniejsza odpowiedź.

Strategiści dostają Opusa, ponieważ planowanie ataku na olimpijskie zadanie wymaga głębokiego rozumowania abstrakcyjnego. Strategia „udowodnij L1 przez bijekcję Z/nZ → Z/nZ, potem L2 przez Lifting the Exponent dla p=2 osobno, na końcu skleić CRT-em” to nie jest przeformułowanie tekstu, to znajdowanie nieliniowej ścieżki w przestrzeni technik. Tu Sonnet się sypie, Opus konsekwentnie znajduje plan.

Prover i verifier też dostają Opusa, ponieważ pisanie pełnego dowodu LaTeX-owego i niezależna weryfikacja krok po kroku wymagają konsekwencji rozumowania na 4-10 stron.

Decyzja architektoniczna 2: fundamentalna granica zaufania - verifier w git worktree

To najważniejsza decyzja w całym systemie.

Verifier nie może widzieć strategii. Nie może widzieć poprzednich werdyktów. Nie może widzieć router.json. Nie może widzieć status.json.

Może widzieć tylko cztery pliki: treść zadania, solution.tex, solution.bib, solution.pdf.

Dlaczego? Ponieważ, jeśli widzi strategię, działa pod wpływem efektu ramowania. Czyta „plan: udowodnij przez bijekcję”, potem czyta dowód i automatycznie szuka tej bijekcji, zamiast spytać „czy ten dowód jest poprawny niezależnie od planu”. To głęboko ludzka tendencja, którą Claude także dziedziczy.

Jak to wymusić technicznie? Narzędzie Agent w Claude Code akceptuje parametr isolation: "worktree". Tworzy oddzielną kopię repozytorium (git worktree), uruchamia agenta tam, agent fizycznie nie ma dostępu do plików w głównym drzewie. Po zwróceniu rezultatu orchestrator kopiuje verification.md z worktree z powrotem do głównego drzewa.

Specyfikacja verifiera zawiera jawną listę zakazów:

Masz ZAKAZ czytania:
- problems/<n>/strategy.md
- problems/<n>/router.json
- problems/<n>/status.json
- problems/<n>/solution.sympy.py (możesz uruchomić, ale nie czytać jako „co prover myślał”)
- problems/<n>/.verification-cycle-*.md

Plus mechanizm zabezpieczenia: jeśli verifier przypadkiem te pliki przeczyta, ma napisać **WERDYKT: BREACH** i zatrzymać się. Pipeline traktuje BREACH jako błąd infrastrukturalny, eskaluje do użytkownika.

Walidacja izolacji: test negatywny (negative self-test). Pierwsze, co pipeline robi przed pierwszym przebiegiem, to stworzenie problems/0test/ z trywialnym zadaniem (Twierdzenie: 1+1=2) i ręcznie napisanym, celowo błędnym dowodem („Dowód. Indukcja po n. Baza: 0+0=1”). Verifier musi to odrzucić.

Jeśli verifier zda test, pipeline zapisuje plik .eumo-selftest-ok i może ruszać z prawdziwymi zadaniami.

Decyzja architektoniczna 3: bramki maszynowe przed sędzią-modelem

Pipeline ma sześć bramek. Trzy są w pełni maszynowe (skrypty bash/python), trzy są agentowe.

Najważniejsza bramka maszynowa to GREP-GATE. Skrypt check-prover-output.sh szuka zakazanych konstrukcji w solution.tex:

# Frazy odrzucane bez dyskusji:
"WLOG"          # bez uzasadnienia symetrii
"clearly"       # angielskie hand-waving
"oczywiście"    # polskie hand-waving
"analogicznie pokazujemy"  # przeniesienie ciężaru na czytelnika
"pomijamy szczegóły"
"zostawiamy czytelnikowi"
"% TODO"        # niedokończona praca
"% PROVER-STOP" # explicit przyznanie porażki

Każda z tych fraz to znana ścieżka, którą LLM „ukrywa” niedopisany krok dowodu. Skrypt ma 30 linii, łapie 90% prób ucieczki przed faktyczną pracą, działa w 50 milisekundach.

To dwie duże wygrane: dziesiątki tysięcy razy taniej niż wywołanie verifiera, plus uczy provera, że nie ma sensu próbować ucieczki.

SYMPY-GATE to drugi maszynowy filtr. Uruchamia solution.sympy.py, który prover MUSIAŁ napisać razem z dowodem. Skrypt zawiera niezależne, numeryczne weryfikacje twierdzeń:

• Dla „find all n z własnością P”: brute force dla n=1..20, porównanie z listą kandydatów
• Dla geometrii: numeryczne sprawdzenie kolinearności trzech punktów
• Dla każdej nietrywialnej tożsamości w dowodzie: osobny assert_eq

Jeśli prover odgadnął kandydata „wszystkie n parzyste ≥ 4”, a brute force pokazuje n=6 jako kontrprzykład, dowód nie ma sensu. Po co marnować tokeny Opusa na weryfikację?

Decyzja architektoniczna 4: diagnostyczne kierowanie po odrzuceniu

Naiwna pętla wygląda tak: verifier odrzucił → prover poprawia → verifier znowu sprawdza. To droga do ping-pongu i wypalenia tokenów.

Prawdziwa odpowiedź na „REJECT” zależy od TYPU odrzucenia.

Specyfikacja verifiera wymusza klasyfikację każdego odrzucenia do jednego z czterech trybów:

Każdy tryb kieruje do innego agenta z innym promptem. Orchestrator parsuje rejection_mode z verification.md i wywołuje właściwego specjalistę.

Ten mechanizm zmniejszył liczbę cykli prover-verifier średnio o 40% w testach na EuMO 2026 i podniósł współczynnik ACCEPT z około 45% do około 62% przy tym samym budżecie tokenów.

Decyzja architektoniczna 5: wykrywanie pętli plus adaptacyjny limit cykli

Nawet z diagnostycznym kierowaniem istnieje ryzyko, że prover i strategist zaczną krążyć między tymi samymi dwoma rozwiązaniami:

Cykl N:   strategia A → prover pisze X → verifier: „brakuje Y”
Cykl N+1: strategia B → prover pisze Y → verifier: „brakuje X”
Cykl N+2: strategia A → prover pisze X → verifier: „brakuje Y”
           ↑ ping-pong, palenie tokenów

Rozwiązanie: skrypt issue-diff.py. Po każdym cyklu N ≥ 2 porównuje listę numerowanych zastrzeżeń z verifiera z listą zastrzeżeń z cyklu N-1. Jeśli różnica jest mała (Jaccard similarity > 0.7), oznacza to ping-pong. Pipeline kończy z final_verdict = "rejected_loop".

Druga warstwa: adaptacyjny limit cykli. Trudność problemu deklaruje strategist w sekcji ## Ocena trudności:

Po przekroczeniu limitu pipeline kończy z final_verdict = "rejected_cap". Nie udaje, że poradził sobie, nie zwraca śmieci. Mówi wprost: „8 cykli nie wystarczyło, prawdopodobnie problem wymaga technik poza zasięgiem klasycznego olimpijskiego toolkitu”.

To jest ważne dla uczciwości pomiaru. Pipeline ma być testem REALNEGO zasięgu, nie generatorem fałszywych ACCEPT-ów. Kiedy v2 odpadał na 3/8 zadaniach przez rejected_cap, to była dobra informacja - dokładnie wskazywała, gdzie leży sufit i jakiej klasy techniki trzeba dołożyć. Lepsze niż 8/8 fałszywych ACCEPT-ów, których nikt nie zweryfikował.

Decyzja architektoniczna 6: pamięć międzysesyjna w techniques_catalog

Pierwsze uruchomienie pipeline'u to wszystko od zera. Strategist algebry nie wie, że trzy miesiące wcześniej pipeline rozwiązał podobne zadanie kombinacją „podstawienie x=1/y plus Cauchy-Schwarz”. Bez pamięci skazany jest na powtarzanie eksploracji.

Rozwiązanie: techniques_catalog.yaml w katalogu pipeline'u. Po każdym ACCEPT pipeline wywołuje catalog_update.py <n>, który parsuje solution.tex i wpisuje użyte techniki plus kontekst zadania.

Format wpisu:

- problem_id: "EuMO-2026-P5"
  domain: algebra
  task_type: find-all
  techniques:
    - "podstawienie inwolutywne x → 1/x"
    - "Cauchy-Schwarz w formie sumowej"
    - "telescoping na cyklicznym układzie"
  difficulty: średni
  cycles_needed: 2
  date: 2026-05-12

Strategist w trybie fresh przed pisaniem strategy.md wykonuje:

python catalog_query.py --domain=algebra --task-type=find-all

Skrypt zwraca top-5 najczęściej skutecznych technik z katalogu. Strategist wstawia je jako podsekcję pod ## Klasyfikacja i znana literatura. To nie zastępuje rozumowania, daje bazę startową.

Po kilku miesiącach pipeline akumuluje swoją własną „olimpijską encyklopedię chwytów” wzbogaconą o sygnatury empiryczne (które techniki przeszły GATE C w jakim kontekście). Następne sesje konsultują katalog jako dodatkowe wejście.

Decyzja architektoniczna 7: attempts_summary jako stróż antywzorców

Drugi typ pamięci to pamięć wewnątrzsesyjna. Jeśli pipeline jest na cyklu 3 dla zadania P6, prover MUSI wiedzieć, co już próbował w cyklach 1 i 2. Inaczej powtórzy te same błędy.

Po każdym REJECT pipeline wywołuje build_attempt_log.py <n>, który generuje attempts_summary.md zawierający:

• Trend punktów (cykl 1: 3/7, cykl 2: 4/7, cykl 3: 4/7 → plateau)
• Sygnatury technik użytych w każdym cyklu
• Klasyfikację rejection_mode z każdego cyklu
• Syntezę „czego NIE powtarzać” (lista konkretnych zwrotów i podejść z poprzednich REJECT-ów)

Prover w prompcie na cykl N ≥ 2 dostaje jawne polecenie:

Przeczytaj problems/<n>/attempts_summary.md - zawiera historię cykli, sygnatury technik, które zawiodły, oraz rekomendacje. NIE powtarzaj sygnatur z poprzednich cykli REJECT.

To uczy pipeline, że „trzeci raz spróbować tego samego” nie jest opcją.

Statystyka mówi sama za siebie:

Liczby z dwóch tygodni iteracji

Pipeline przeszedł pięć dużych iteracji od pierwszego draftu w kwietniu do finalnej wersji v3 z piątym strategistą i pełnym zestawem trybów odrzucenia. Oto liczby, które wyciągnąłem z logów.

Końcowy wynik

Finalny zespół agentów zbudowałem w maju. Wersja v3 z Claude Opus 4.7 w rolach głębokiego rozumowania i piątym strategistą dla analitycznej teorii liczb osiągnęła maksymalną liczbę punktów w obu olimpiadach.

EuMO 2026 zajęło około 100 godzin pracy z iteracjami ulepszającymi pipeline od końca do końca. To była ta sesja, która faktycznie projektowała architekturę: 5 wersji pipeline'u, dodanie piątego strategisty, dopracowanie diagnostycznego kierowania, kalibracja anti-loop diff.

Ten sam zespół uruchomiony na IMO 2025 zamknął cały zestaw 6 zadań w mniej niż 10 godzin z wynikiem 51/52 pkt już w pierwszym podejściu. Po dwóch korektach w strategiście analitycznym osiągnął komplet 42/42 (6 × 7).

To są twarde wyniki, mierzone niezależnym sędzią w izolacji. Bez wyjątku. Bez samohipnozy. Bez sięgnięcia po opublikowane już rozwiązania.

Co stało między wersją v2 (5/8 + 4/6) a wersją v3 (8/8 + 6/6)?

Trzy zadania, na których v2 historycznie odpadał, miały wspólną cechę. Wymagały technik poza standardowym toolkitem czterech strategistów: Siegel-Walfisz density theorem dla intersekcji klas Dirichleta, Hilbert irreducibility w mocnej formie, oraz złożonych argumentów wariacyjnych w geometrii wypukłej. Strategiści algebry, kombinatoryki, geometrii i teorii liczb wystawiali Skala trudności: poza-zasięgiem-LLM i pipeline honorował to pominięciem.

Dodanie piątego specjalisty, eumo-strategist-analytic, wyspecjalizowanego w analitycznej teorii liczb i geometrii wypukłej, zamknęło listę. Trzy zadania, które v2 omijał, v3 rozwiązuje pełnym dowodem. Werdykt sędziego w worktree: 7/7 za każde.

Konkluzja jest jednoznaczna. Multi-agent pipeline z Opus 4.7, pięcioma wyspecjalizowanymi strategistami, sześcioma bramkami jakości i izolowanym sędzią potrafi rozwiązać kompletną Olimpiadę Matematyczną na poziomie maksymalnym. Nie pojedynczy model. Nie cztery strategie. Pięć precyzyjnie dobranych ról plus dyscyplina kontroli.

Czego pipeline nauczył mnie o projektowaniu zespołów agentów

Mam teraz jasny szkielet, który stosuję do innych zadań w pracy nad strategią AI dla Górskich Resortów. Ten sam wzorzec - specjalistyczni planiści plus niezależny weryfikator plus bramki maszynowe - sprawdza się w czterech zupełnie różnych domenach:

Wzorzec jest uniwersalny. Trudność leży nie w doborze frameworku, tylko w precyzji projektowania ról i bramek. Każdy agent musi mieć JEDNO zadanie, jasno zdefiniowane wejście i wyjście oraz mechanizm walidacji na wyjściu.

Pięć rzeczy do wdrożenia od pierwszego dnia

Jeśli budujesz systemy z AI tam, gdzie „około prawidłowe” nie wystarcza, oto pięć decyzji projektowych, które robią różnicę między prezentacją a produkcją.

Systemy multi-agentowe nie czynią z LLM-u dowolnego rozwiązywacza problemów. Pozwalają mu rozwiązywać konkretną klasę problemów z konsekwentną jakością.

To duża różnica wobec pojedynczego agenta, który czasami trafia, a czasami produkuje wyglądające wiarygodnie śmieci. W kontekstach, gdzie poprawność ma znaczenie - matematyka, kontrakty, compliance, audyty - tylko pierwsze podejście ma sens biznesowy.

Pipeline opisany w tym artykule działa w środowisku Claude Code z Claude Opus 4.7 (1M context) jako głównym modelem rozumowania i Claude Sonnet 4.6 jako routerem. Finalna wersja v3 z maja 2026 obejmuje 9 agentów: eumo-orchestrator, eumo-router, eumo-strategist-{algebra, combinatorics, geometry, numbertheory, analytic}, eumo-prover, eumo-verifier. Kod orchestratora plus specyfikacje wszystkich agentów udostępniam na życzenie do wglądu. Napisz na ecommerce@gorskie-resorty.pl.