Agent 0: cienki rdzeń mikroagentów dla Pneumy

Przez /

Agent 0: cienki rdzeń mikroagentów dla Pneumy

Data: 2026-05-11

Wstęp

W świecie agentów bardzo łatwo pomylić sprawczość z ciężarem frameworka.

Jeśli prosty subagent od bloga dostaje kilka lub kilkanaście tysięcy tokenów narzutu, to problem nie leży już w modelu. Problem leży w architekturze.

Ten tekst opisuje prostą kontrpropozycję:

  • zamiast jednego ciężkiego agenta do wszystkiego
  • cienki Agent 0 jako rdzeń
  • mikroagenty jako organy robocze
  • selektywny recall zamiast sztywnego jetpacka instrukcji
  • ciężki executor tylko wtedy, gdy naprawdę jest potrzebny

Teza

Wiele współczesnych frameworków agentowych przepala znaczną część budżetu kontekstowego na stały, ogólny, mało relewantny narzut systemowy.

Dla zadań wąskich i częstych lepszym wzorcem jest:

  • cienki Agent 0
  • specjalizowane mikroagenty
  • selektywny recall składany atomowo
  • ciężki executor uruchamiany tylko wtedy, gdy naprawdę jest potrzebny

To podejście przesuwa budżet z martwych instrukcji na użyteczną pamięć roboczą i realny stan zadania.

Problem

W systemach typu Hermes problem nie musi leżeć w samym modelu. Często leży w architekturze promptu i orkiestracji:

  • duży, hardcoded jetpack instrukcji
  • ten sam narzut dla small talk, prostego tasku i złożonego działania
  • skille i zasady ładowane nawet wtedy, gdy nie będą użyte
  • koszt bezczynności bardzo wysoki
  • trudny debugging i słaba obserwowalność

Efekt:

  • prosty subagent od bloga dostaje kontekst jak ciężki operator systemowy
  • małe modele są tłumione przez frameworkowy szum
  • rośnie koszt, latencja i chaos poznawczy

Hipoteza

Jeśli usuniemy zbędny narzut i zostawimy tylko minimalny rdzeń działania, to nawet mały lokalny model może być skutecznym wykonawcą wielu prostych zadań, o ile dostanie:

  • małą, jasno zdefiniowaną rolę
  • jawny kontrakt wejścia i wyjścia
  • pamięć roboczą zamiast śmieci systemowych
  • prostą pętlę działania
  • jawny stan zadania

Definicje

Agent 0

Najmniejsza sensowna forma agenta.

Nie jest mini-frameworkiem. Nie jest mini-Pneumą.

To cienki rdzeń, który potrafi:

  • przyjąć cel
  • dostać minimalny kontekst
  • wykonać prostą pętlę
  • zostawić ślad stanu
  • zwrócić wynik

Mikroagent

Wyspecjalizowany organ roboczy budowany na Agent 0.

Przykłady:

  • blog-writer
  • vault-writer
  • summarizer
  • tag-normalizer
  • link-suggester

Heavy Executor

Ciężki wykonawca używany tylko wtedy, gdy zadanie wymaga:

  • planowania wielokrokowego
  • pracy na terminalu
  • inspekcji systemu
  • zmian w wielu plikach
  • złożonych zależności narzędziowych

One Shot View

flowchart LR

    U["Użytkownik / Pneuma Task"] --> R

    subgraph ROUTER["Pneuma Router"]
        R["Preflight
        klasyfikacja zadania"]
        C1["Czy zadanie jest wąskie,
        jednokrokowe i lokalne?"]
        C2["Czy wymaga planowania,
        terminala albo wielu zależności?"]
    end

    R --> C1
    R --> C2

    C1 -->|tak| A0
    C2 -->|tak| HX
    C1 -->|niepewne| PX

    subgraph AG0["Agent 0 Core"]
        A0["Mały system prompt
        rola + zasady jakości"]
        IN["Input atoms
        task, output_format, save_path"]
        MEM["Pamięć robocza
        last_turn, recent_turns, task_state"]
        LOOP["Krótka pętla
        draft -> self-check -> final"]
        OUT["Jawny artefakt wyniku"]
    end

    A0 --> IN
    IN --> MEM
    MEM --> LOOP
    LOOP --> OUT

    subgraph PXG["Mikroagent Specjalistyczny"]
        PX["Specjalista
        np. blog-writer"]
        RB["Recall block
        tylko relewantne atomy"]
        TO["0-1 narzędzi
        np. zapis pliku"]
    end

    PX --> RB
    RB --> TO

    subgraph HEAVY["Heavy Executor"]
        HX["Codex / ciężki agent"]
        HP["Duży runtime,
        narzędzia, planowanie"]
    end

    HX --> HP

    OUT --> K
    TO --> K
    HP --> K

    subgraph KR["Kronikarz / Observability"]
        K["Zapis śladu zadania"]
        L1["operation_log"]
        L2["world_delta"]
        L3["artifact metadata"]
    end

Minimalny kontrakt Agent 0

Agent 0 powinien dostać tylko to, co potrzebne do pracy.

Wejście

  • task
  • goal
  • constraints
  • output_format
  • save_path lub return_only
  • opcjonalnie author_style
  • opcjonalnie last_turn
  • opcjonalnie recent_turns_compact
  • opcjonalnie task_state

Wyjście

  • status
  • artifact
  • summary
  • open_loops
  • write_targets

Budżet kontekstu

Kluczowa zasada:

Nie optymalizujemy pod minimalną liczbę tokenów za wszelką cenę. Optymalizujemy pod maksymalny udział tokenów nośnych.

Dobry budżet mikroagenta może wyglądać tak:

  • 600-1500 tokenów system promptu
  • 500-2500 tokenów pamięci roboczej
  • 500-2000 tokenów task payloadu
  • reszta na odpowiedź i krótką rewizję

W praktyce agent z 5k sensownego kontekstu może być dużo tańszy poznawczo niż agent z 12k, gdzie połowa to martwy framework.

Pamięć robocza zamiast frameworkowego śmietnika

Zamiast przepalać kontekst na zasady ogólne, mikroagent powinien dostać krótką pamięć roboczą:

  • last_turn
  • recent_turns_compact
  • task_state

To daje:

  • ciągłość lokalną
  • odporność na nadpisanie własnych zmian
  • lepszą stabilność przy krótkich iteracjach

Relacja do Pneumy

Pneuma nie powinna być upychana do każdego mikroagenta w całości.

Powinna działać jako warstwa sterująca:

  • robi preflight
  • wybiera profil lub rolę
  • składa minimalny recall block
  • decyduje o delegacji
  • zapisuje ślad po zadaniu

Mikroagent nie ma być miniaturową Pneumą. Ma być prostym, wywoływalnym organem roboczym.

Reguła delegacji

Mikroagent

Użyj, gdy zadanie jest:

  • wąskie
  • lokalne
  • krótkie
  • z jednym głównym artefaktem
  • bez potrzeby głębokiej inspekcji środowiska

Heavy Executor

Użyj, gdy zadanie wymaga:

  • planu wielokrokowego
  • pracy na kodzie lub systemie
  • terminala
  • wielu zależnych decyzji
  • integracji kilku warstw narzędzi

MVP eksperymentu

Najprostszy uczciwy eksperyment dla mikroagenta blog-writer:

Wersja 1

  • mały system prompt
  • temat
  • ton
  • długość
  • output markdown

Wersja 2

  • wersja 1
  • krótki profil stylu autora

Wersja 3

  • wersja 2
  • jedna pętla rewizji

Mierzymy:

  • jakość wyniku
  • spójność
  • koszt tokenowy
  • latencję
  • potrzebę poprawek

Dlaczego to jest ważne

To podejście nie jest tylko optymalizacją kosztu.

To jest zmiana architektury:

  • od jednego ciężkiego agenta
  • do lekkiego rdzenia i wyspecjalizowanych organów

To poprawia:

  • obserwowalność
  • debugowalność
  • modularność
  • możliwość strojenia
  • łatwość delegacji w Pneumie

Wniosek

Agent 0 to brakujące ogniwo między zwykłym wywołaniem modelu a ciężkim frameworkiem agentowym.

Jeśli ten rdzeń zostanie dobrze zdefiniowany, Pneuma może budować na nim mikroagenty, zamiast uruchamiać ciężkiego wykonawcę do każdego drobnego zadania.

To pozwala odzyskać:

  • kontrolę nad budżetem kontekstu
  • prostotę architektury
  • sensowną pamięć roboczą
  • transparentność działania

I właśnie to może być praktycznym lekarstwem na prompt-bloat systemów typu Hermes.

Nie chodzi więc o to, by budować kolejnego „agenta uniwersalnego”. Chodzi o to, by odzyskać proporcje:

  • mały rdzeń
  • mały kontrakt
  • mała pamięć robocza
  • czytelna delegacja
  • ciężar tylko tam, gdzie naprawdę przynosi wartość

Od tego punktu można budować dalej:

  • blog-writer
  • vault-writer
  • summarizer
  • tag-normalizer
  • link-suggester

Każdy jako tani, obserwowalny i testowalny mikroagent podpięty do Pneumy, a nie jako kolejna kopia pełnego frameworka agentowego.

Przewijanie do góry