Agenci i persony — AiHummer Dokumenty

Jeden agent to jednostka, którą AiHummer umieszcza na początku rozmowy. Każdy agent ma swoją osobowość, własny model, ustrukturyzowany prompt i zestaw umiejętności, a każda zmiana w nim jest wersjonowana. Agenci są zarządzani z poziomu interfejsu administracyjnego w sieci oraz poprzez API administracyjne pod /v1/admin/agents/*.

Ta strona obejmuje to, z czego składa się agent, jak zbudowany jest ustrukturyzowany prompt “G3” oraz jak agent może bezpiecznie edytować swój własny profil.

Rejestr agentów

Rejestr jest pełnym katalogiem CRUD agentów. Dla każdego agenta definiujesz tożsamość, personę, model, na którym działa, oraz umiejętności, które może wykorzystać. Ponieważ brama jest wielodostępna, agenci znajdują się wewnątrz przestrzeni roboczej i są izolowani jak dane każdego innego najemcy.

Persona — głos i zachowanie agenta, przeniesione do stajni, warstwa przyjazna pamięci podręcznej w systemowym poleceniu.
Model per-agenta — każdy agent może przypiąć swój własny model i dostawcę, więc a Tani agent i agent flagowy mogą współistnieć w tej samej przestrzeni roboczej.
Umiejętności — umiejętności przypisane do agenta i wspólne przekształcają blok „Umiejętności” w podpowiedź; opisują możliwości, a nie wagi.

[!NOTE] Model per-agenta jest niezależny od routingu. Routing na poziomie modelu (prosty / standardowy / złożony) wybiera klasę modelu dla tury, podczas gdy dla każdego agenta model jest domyślny dla agenta. Zobacz Trasowanie.

Wersje, cofanie i klonowanie

Każda znacząca zmiana agenta jest rejestrowana jako wersja. To sprawia, że konfiguracja agenta jest możliwa do audytu i odwracalna: możesz przejrzeć, co się zmieniło, cofnąć do wcześniejszej wersji, lub klon agent do użycia go jako punktu wyjścia dla nowego. Zasoby wersji i profilu znajdują się pod /v1/admin/agents/* (profil, sekcje, umiejętności, wersje).

[!TIP] Sklonuj działającego agenta przed dużą zmianą osobowości lub wskazówki. Jeśli nowy jeśli kierunek się nie sprawdzi, oryginał wciąż jest jeden rollback od nas.

Strukturalny prompt „G3”

Zamiast pojedynczego polecenia systemowego w formie wolnego tekstu, AiHummer używa ustrukturyzowany profil agenta (wewnętrznie „G3”). Tożsamość to rozkład na pola zamiast ukrywać w prozie, a reszta podpowiedzi jest zbudowana z nazwanych sekcje plus jeden wdrażanie blok. Orkiestrator renderuje je w warstwowy systemowy prompt, utrzymując stabilne części (tożsamość, persona, sekcje) w buforowanym prefiksie i dołączając zmienne dane na końcu.

Struktura sprawia, że profil jest łatwy do edytowania pole po polu, łatwy do porównania między wersjami i przewidywalny w renderowaniu — nie ma ukrytej zupy z podpowiedziami.

G3 profile
├── identity fields   (decomposed: name, role, ...)
├── sections          (named, ordered prompt blocks)
└── onboarding        (first-run guidance)

Samodzielna edycja za bramką zatwierdzającą

Agent może mieć pozwolenie na edytować swój własny profil korzystanie z narzędzi do samodzielnej edycji — na przykład w celu ulepszenia sekcji lub zaktualizowania jej wprowadzania. Jest to celowo chronione:

Samo-edytowanie przechodzi przez brama zatwierdzenia: proponowana zmiana jest rejestrowana i musi być zatwierdzony przez człowieka, zanim wejdzie w życie. Odrzucona zmiana nigdy nie zastosowany.
Zmiana jest zarejestrowana jako nowa wersja, więc samoedycja jest tak samo możliwa do audytu i odwracalny jak każda ręczna edycja.

[!WARNING] Samodzielna edycja jest potężna. Trzymaj ją za bramką zatwierdzeń, aby agent nie mógł cicho przepisuje swoją własną tożsamość. Przejrzyj proponowane samodzielne poprawki w ten sam sposób, jak ty przejrzyj każdą uprzywilejowaną zmianę.

Hasła do poczty trafiają do sejfu

Jeśli konfiguracja agenta zawiera dane uwierzytelniające do poczty (dla mail narzędzie), hasło jest zapisane w zaszyfrowany sejf na dane uwierzytelniające, nie są przechowywane w profilu ani wprowadzane do promptu. Sekrety nigdy nie trafiają do kontekstu modelu.

Polityka wykonania: kontekst, sesje i agenci potomni

Od wersji 1.3 agent ma politykę wykonania — pole runtime_policy w API administracyjnym (/v1/admin/agents przy tworzeniu i aktualizacji). To ściśle walidowany obiekt JSON z "version": 1: pusty {} przywraca ustawienia domyślne, pominięcie pola przy aktualizacji zachowuje poprzednią politykę, a nieznane pola i wartości poza dopuszczalnym zakresem są odrzucane. Polityka nie nadaje narzędzi i nie rozszerza uprawnień — ustala tylko budżety i terminy. Klon agenta i przekazanie mu tury ją dziedziczą.

context — budżet historii: max_tokens, reserve_tokens i history_share decydują, ile historii trafia do żądania; max_history_messages ogranicza okno wiadomości, bootstrap_max_chars — rozmiar bloku profilu. Gdy kontekst jest zadany jawnie, starsze wiadomości są kompaktowane do streszczenia partiami, zanim zostanie zbudowane bieżące żądanie.
- pruning — czyszczenie nieaktualnych wyników narzędzi: według wieku (ttl_seconds), z ochroną ostatnich odpowiedzi (keep_last_assistants), miękkie przycinanie (soft_trim_ratio, head_chars, tail_chars) i pełne zastąpienie tekstem placeholder powyżej hard_clear_ratio. Tekst użytkownika, obrazy i pełna historia w bazie pozostają nietknięte.
- memory_flush — przed kompaktowaniem agent bez narzędzi zapisuje krótką notatkę o celach, decyzjach i sprawach otwartych (soft_threshold_tokens); trzy ostatnie notatki tej samej rozmowy są domieszane do kontekstu jako niezweryfikowane odniesienie.
session — cykl życia rozmowy: idle_reset_minutes zaczyna nowy kontekst po przerwie (surowa historia jest zachowana), index_prune_after_days i index_max_entries usuwają stare rozmowy z listy domyślnej, nie kasując ich. scope = per-peer (jedna rozmowa na zweryfikowanego użytkownika we wszystkich kanałach) lub per-channel-peer (osobna rozmowa na kanał).
children — agenci potomni: max_depth (do 4), max_concurrent (do 8 na drzewo uruchomienia), max_per_parent (do 5), timeout_seconds (do 48 godzin, nigdy dłużej niż rodzic) i archive_after_minutes — kiedy zakończone uruchomienia znikają z listy domyślnej. Wartości nadpisują dla tego agenta globalne AIHUMMER_SUBAGENT_MAX_DEPTH i AIHUMMER_SUBAGENT_TIMEOUT_SEC.
max_iterations (1–256) — limit kroków pętli wywołań funkcji dla sprawdzonych scenariuszy z wieloma delegacjami.
app — tylko dla aplikacji AiHummer: reasoning_effort, service_tier i tryb krótkiej odpowiedzi direct_completion (auto lub always z max_tokens do 4096 i timeout_ms do 60 000).
interaction — jawne uprawnienia do pracy z sesjami: user_ids, session_agent_ids, spawn_agent_ids, widoczność session_visibility (self, agent lub granted), session_send, zakazy narzędzi dla wywołań potomnych (child_tool_deny, child_leaf_tool_deny) oraz elevated_telegram_user_ids — podzbiór user_ids, któremu wolno żądać jawnie podniesionego uruchomienia code_exec (zatwierdzenia nie są omijane). Nie ma symboli wieloznacznych ani uprawnień dla całego najemcy.

API administratora

Agenci i ich uporządkowane profile są zarządzani za pomocą API administratora, które jest zabezpieczone OIDC i audytowane:

Zasób	Cel
`/v1/admin/agents`	Wyświetl, utwórz, zaktualizuj, usuń agentów (CRUD)
`/v1/admin/agents/.../profile`	Strukturalny profil G3 (pola tożsamości)
`/v1/admin/agents/.../sections`	Nazwane sekcje promptu
`/v1/admin/agents/.../skills`	Umiejętności poszczególnych agentów
`/v1/admin/agents/.../versions`	Historia wersji, przywracanie i klonowanie

Dokąd dalej

Zrozum, jak agenci wykonują turę i generują pomocników w Orkiestracja i podagentów.
Zobacz, jak nadchodząca wiadomość dociera do konkretnego agenta w Trasowanie.
Daj swoim agentom pamięć długoterminową z Pamięć (Einstein).