Agent Factory¶

Cel¶

Agent Factory służy do projektowania, testowania, wersjonowania i certyfikowania wyspecjalizowanych agentów. Agent nie jest osobnym modelem ani kontem o nieograniczonych prawach. Jest manifestem roli: określa cel, dozwolony kontekst, strategie, narzędzia, limity, sposób eskalacji i kryteria jakości.

Factory ma zamieniać prośbę „potrzebujemy agenta do X” na sprawdzalny pakiet. Może automatycznie wygenerować kandydacki manifest, przykładowe workflow i testy, ale nie może aktywować wyniku. Agent nie może być jednocześnie autorem, jedynym recenzentem i podmiotem nadającym sobie capability.

Karta modułu¶

Pole	Kontrakt
Odpowiedzialności	specyfikacja roli, manifest, dataset/testy, shadow, ocena, review, wersjonowanie, rollback.
Wejścia	problem domenowy, proces referencyjny, polityki, dozwolone tools, kryteria jakości, przykłady i kontrprzykłady.
Wyjścia	`AgentManifest` candidate, evaluation report, risk report, test artifacts, activation proposal.
Zależności	Agent Registry, Model/Tool Registry, Sandbox, Workflow Engine, Artifact Store, Audit.
Uprawnienia	create candidate i run tests; brak `activate_agent`, capability assignment i production send/publish.
Autonomia	iteracja kandydata w limicie prób i budżetu; zatrzymanie przy wzroście zakresu.
Walidacja	schema, deterministyczne gates, benchmark zadaniowy, adversarial tests, shadow, human review.
Awaria	odrzucenie wersji, zachowanie dowodów, przywrócenie poprzedniego aktywnego wpisu bez mutacji historii.

Manifest agenta¶

Manifest obejmuje:

agent_id, semver i opis odpowiedzialności;
właściciela biznesowego oraz technicznego;
typy akceptowanych intencji i projekty, w których może działać;
dozwolone źródła kontekstu i maksymalną klasyfikację danych;
wymagane profile modeli oraz fallback;
allowlistę tools z dokładnymi wersjami lub kompatybilnym zakresem;
capabilities wymagane od principal, ale bez możliwości samoprzypisania;
politykę planowania, retry, kosztu, czasu i zasobów;
kryteria ukończenia i walidatory;
przypadki wymagające approvala albo przekazania człowiekowi;
zestaw testowy, znane ograniczenia, status lifecycle i podpis pakietu.

Instrukcje językowe są tylko jednym z pól. Nie mogą osłabić polityki systemowej ani rozszerzyć tool allowlist. Zmiana instrukcji, narzędzia, modelu minimalnego lub walidatora tworzy nową wersję.

Proces tworzenia¶

flowchart LR
    N["Potrzeba"] --> S["Specyfikacja roli"]
    S --> M["Manifest candidate"]
    M --> T["Testy kontraktowe"]
    T --> E["Ewaluacja jakości"]
    E --> A["Adversarial / safety"]
    A --> H["Shadow mode"]
    H --> R["Review"]
    R -->|odrzuć| M
    R -->|zaakceptuj| P["Osobny approval aktywacji"]
    P --> G["Gradual rollout"]

1. Specyfikacja roli¶

Właściciel definiuje rzeczywisty rezultat, nie antropomorficzny zawód. Zamiast „agent księgowy” powstają role typu: ekstrakcja faktury, kontrola pól, dopasowanie do zamówienia, przygotowanie candidate dekretacji i raport wyjątków. Operacje o skutku księgowym są osobnymi adapterami i politykami.

2. Dataset i kryteria¶

Zestaw testowy zawiera typowe zadania, trudne przypadki, brakujące dane, konflikty, treści z prompt injection, błędne dokumenty, próby rozszerzenia zakresu i scenariusze odmowy. Kryteria dzielą się na twarde (schema, brak wycieku, poprawna suma) oraz jakościowe (użyteczność, styl, kompletność).

3. Budowa kandydata¶

Factory może wygenerować manifest, prompty, przykłady i workflow. Każdy element jest artefaktem candidate z lineage. Liczba automatycznych iteracji i koszt są ograniczone. Factory nie „uczy się na produkcji” przez cichą zmianę manifestu.

4. Test i shadow¶

Testy uruchamiają tylko dozwolone adaptery na danych syntetycznych lub zanonimizowanych. Shadow otrzymuje kopię rzeczywistych intencji, ale jego propozycje nie prowadzą do skutków. Porównuje się jakość, latency, koszt, liczbę eskalacji i naruszenia. Dane shadow podlegają tej samej retencji.

5. Review i aktywacja¶

Recenzent widzi manifest diff, testy, niepowodzenia, model/resource profile i pełen zakres capabilities. Aktywacja jest osobnym efektem activate_agent, niedostępnym agentom i Factory. Rollout może objąć najpierw jedną rolę, projekt lub 5% zadań, z automatycznym zatrzymaniem po naruszeniu twardej bramki.

Poziomy autonomii agenta¶

Agent może mieć poziom inny niż cały system. Agent research może działać automatycznie na publicznym webie, ale jego publikacja pozostaje manualna. Agent magazynowy może automatycznie oznaczać prawdopodobne odchylenia, ale korekta stanu wymaga pracownika. Agent coding może tworzyć i testować candidate, lecz promocja na main wymaga niezależnego approvala.

Przykładowe polecenia¶

„Zaprojektuj agenta do kontroli kompletności ofert i przygotuj 50 testów, ale go nie aktywuj.”
„Porównaj wersję 1.3 i 1.4 agenta planującego grafik na danych historycznych.”
„Uruchom przez tydzień wersję 2.0 w shadow tylko dla oddziału północnego.”
„Zawieś routing do agenta, jeżeli twardy błąd przekroczy 0,5%, i powiadom właściciela.”

Walidacja i miary¶

Factory mierzy task success, false positive/negative, kompletność, zgodność z narzędziami, liczbę niepotrzebnych approvali, koszt, latency, stabilność structured output i zachowanie przy braku danych. Wysoki wynik średni nie kompensuje krytycznego wycieku albo nieuprawnionej akcji. Wyniki są przypisane do wersji manifestu, modelu, tool registry i datasetu.

Ryzyka i scenariusz awaryjny¶

Ryzyka to overfitting do testów, niepełny dataset, ukryta zależność od jednego modelu, tool sprawl i wzrost uprawnień pod pozorem jakości. Ograniczenia: niezależny test set, przegląd zakresu, benchmark na kilku modelach, minimalna allowlista i diff capabilities jako osobna część review.

Po incydencie wersja agenta może zostać natychmiast zawieszona przez politykę bezpieczeństwa. Aktywne jobs są zatrzymywane albo kończone według ryzyka; grants powiązane z wersją są revoked. Poprzednia wersja wraca do routingu tylko jeśli nadal jest aktywna i kompatybilna. Factory przygotowuje poprawkę, ale reaktywacja ponownie wymaga review.