Agenter og personaer — AiHummer Dokumenter

En agent er enheten AiHummer setter foran en samtale. Hver agent har en persona, sin egen modell, et strukturert prompt og et sett med ferdigheter, og hver endring til den er versjonert. Agenter administreres fra nettadministrasjonsgrensesnittet og gjennom administrasjons-API-et under /v1/admin/agents/*.

Denne siden dekker hva en agent består av, hvordan den strukturerte “G3”-prompten settes sammen, og hvordan en agent trygt kan redigere sin egen profil.

Agentregisteret

Registeret er en full CRUD-katalog over agenter. For hver agent definerer du en identitet, en persona, modellen den kjører på og ferdighetene den kan bruke. Fordi gatewayen er flermodus, lever agenter inne i et arbeidsområde og er isolert som alle andre leietakere.

Persona — stemmen og oppførselen til agenten, gjengitt inn i en stall, cache-vennlig lag av systemprompten.
Per-agent-modell — hver agent kan feste sin egen modell og leverandør, så en En billig agent og en flaggskipagent kan sameksistere i samme arbeidsområde.
Ferdigheter — per-agent og delte ferdigheter gjør en “Ferdigheter”-blokk om til prompt; de beskriver kapasiteter, ikke vekter.

[!NOTE] En per-agent modell er uavhengig av ruting. Modell-nivå ruting (enkel / standard / kompleks) velger en modellklasse for en tur, mens per-agent modellen er agentens egen standard. Se Rutinger.

Versjoner, tilbakestilling og kloning

Hver meningsfulle endring av en agent blir fanget opp som en versjon. Dette gjør agentkonfigurasjon reviderbar og reversibel: du kan gjennomgå hva som har endret seg, rulle tilbake til en tidligere versjon, eller klone en agent for å bruke den som utgangspunkt for en ny. Versjons- og profileressurser ligger under /v1/admin/agents/* (profil, seksjoner, ferdigheter, versjoner).

[!TIP] Klon en fungerende agent før en stor persona- eller prompt-omskriving. Hvis den nye retningen ikke fungerer, er originalen fortsatt bare ett tilbakeslag unna.

Den strukturerte “G3”-prompten

I stedet for et enkelt systemprompt med fritekst, bruker AiHummer en strukturert agentprofil (internt “G3”). Identiteten er oppsplittet i felt snarere enn begravd i prosa, og resten av prompten er bygget fra navngitte seksjoner pluss en opplæring blokk. Orkestratoren gjengir disse inn i det lagdelte systempromptet, og holder de stabile delene (identitet, persona, seksjoner) i en bufret prefiks og legger til flyktige data til slutt.

Strukturen gjør det enkelt å redigere en profil felt for felt, enkelt å sammenligne versjoner, og forutsigbar å gjengi — det finnes ingen skjult prompt-rot.

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

Selvredigering bak en godkjenningsport

En agent kan få lov til å redigere sin egen profil bruk av verktøy for selvredigering — for eksempel for å forbedre en seksjon eller oppdatere dens onboarding. Dette er bevisst beskyttet:

Selvredigeringer går gjennom godkjenningsport: en foreslått endring blir registrert og må godkjennes av et menneske før den trer i kraft. En avvist endring blir aldri påført.
Endringen blir registrert som en ny versjon, så en selvredigering er like reviderbar og reversibel som enhver manuell redigering.

[!WARNING] Selvredigering er kraftfullt. Hold det bak godkjenningsporten slik at en agent ikke kan stille omskrive sin egen identitet. Gjennomgå foreslåtte selvediter på samme måte som du gjennomgå enhver privilegert endring.

E-postpassord går til hvelvet

Hvis en agents konfigurasjon inkluderer e-postpåloggingsinformasjon (for mail verktøy), passordet skrives til kryptert legitimasjonsarkiv, ikke lagret i profilen eller gjengitt i prompten. Hemmeligheter kommer aldri inn i modellens kontekst.

Kjøretidspolicy: kontekst, økter og underagenter

Fra versjon 1.3 har en agent en kjøretidspolicy — feltet runtime_policy i admin-API-et (/v1/admin/agents ved opprettelse og oppdatering). Det er et strengt validert JSON-objekt med "version": 1: et tomt {} gjenoppretter standardverdiene, utelatelse av feltet ved oppdatering beholder den tidligere policyen, og ukjente felt eller verdier utenfor grensene avvises. Policyen tildeler ingen verktøy og utvider ingen rettigheter — den setter bare budsjetter og frister. Kloning av en agent og overlevering av en tur til den arver den.

context — historikkbudsjettet: max_tokens, reserve_tokens og history_share avgjør hvor mye historikk som inngår i en forespørsel; max_history_messages begrenser meldingsvinduet, bootstrap_max_chars profilblokkens størrelse. Med en eksplisitt kontekst komprimeres eldre meldinger til et sammendrag i porsjoner før den gjeldende forespørselen bygges.
- pruning — opprydding av utdaterte verktøyresultater: etter alder (ttl_seconds), med vern av de siste svarene (keep_last_assistants), myk beskjæring (soft_trim_ratio, head_chars, tail_chars) og full erstatning med placeholder-teksten over hard_clear_ratio. Brukertekst, bilder og hele historikken i databasen berøres ikke.
- memory_flush — før komprimeringen skriver en agent uten verktøy et kort notat om mål, beslutninger og åpne punkter (soft_threshold_tokens); de tre siste notatene fra samme dialog blandes inn i konteksten som ukontrollert referanse.
session — dialogens livssyklus: idle_reset_minutes starter en ny kontekst etter en pause (råhistorikken bevares), index_prune_after_days og index_max_entries fjerner gamle dialoger fra standardlisten uten å slette dem. scope = per-peer (én dialog per verifisert bruker på tvers av kanaler) eller per-channel-peer (en egen dialog per kanal).
children — underagenter: max_depth (opptil 4), max_concurrent (opptil 8 per kjøretre), max_per_parent (opptil 5), timeout_seconds (opptil 48 timer, aldri lenger enn forelderen) og archive_after_minutes — når fullførte kjøringer forlater standardlisten. Verdiene overstyrer de globale AIHUMMER_SUBAGENT_MAX_DEPTH og AIHUMMER_SUBAGENT_TIMEOUT_SEC for denne agenten.
max_iterations (1–256) — trinngrensen for funksjonskallsløyfen for gjennomgåtte scenarioer med mange delegeringer.
app — bare for AiHummer-appen: reasoning_effort, service_tier og kortsvarmodusen direct_completion (auto eller always med max_tokens opptil 4096 og timeout_ms opptil 60 000).
interaction — uttrykkelige økttillatelser: user_ids, session_agent_ids, spawn_agent_ids, synligheten session_visibility (self, agent eller granted), session_send, verktøyforbud for underkall (child_tool_deny, child_leaf_tool_deny) og elevated_telegram_user_ids — en delmengde av user_ids som kan be om uttrykkelig forhøyet code_exec-kjøring (godkjenninger omgås ikke). Det finnes verken jokertegn eller tillatelser for hele leietakeren.

Admin-API

Agenter og deres strukturerte profiler administreres under admin-API-et, som er OIDC-beskyttet og revidert:

Ressurs	Formål
`/v1/admin/agents`	Liste, opprett, oppdater, slett agenter (CRUD)
`/v1/admin/agents/.../profile`	Den strukturerte G3-profilen (identitetsfelt)
`/v1/admin/agents/.../sections`	Navngitte promptseksjoner
`/v1/admin/agents/.../skills`	Ferdigheter per agent
`/v1/admin/agents/.../versions`	Versjonshistorikk, tilbakeføring og kloning

Hvor til neste

Forstå hvordan agenter kjører en runde og spawner hjelpere i Orkestrering og underagenter.
Se hvordan en innkommende melding når en spesifikk agent i Rutinger.
Gi agentene dine langtidshukommelse med Minne (Einstein).