En agent er enheden, som AiHummer sætter foran en samtale. Hver agent har en persona, sin egen model, en struktureret prompt og et sæt færdigheder, og hver ændring til den versionsstyres. Agenter administreres fra web-admin-UI’et og gennem admin-API’en under /v1/admin/agents/*.
Denne side dækker, hvad en agent består af, hvordan den strukturerede “G3”-prompt sammensættes, og hvordan en agent sikkert kan redigere sin egen profil.
Agentregistret
Registeret er et fuldt CRUD-katalog over agenter. For hver agent definerer du en identitet, en persona, den model, den kører på, og de færdigheder, den kan bruge. Fordi gatewayen er multitenant, lever agenter inden for et arbejdsområde og er isoleret som enhver anden lejerdata.
Persona — agentens stemme og adfærd, gengivet i en stald,
cache-venligt lag af systemprompten.
Per-agent model — hver agent kan fastgøre sin egen model og udbyder, så en
En billig agent og en flagskibsagent kan sameksistere i det samme arbejdsområde.
Færdigheder — per-agent og delte færdigheder gengiver en “Færdigheder”-blok i
prompt; de beskriver kapaciteter, ikke vægte.
[!NOTE]
En per-agent model er uafhængig af routing. Model-lag routing (simpel /
standard / kompleks) vælger en modelklasse for en tur, mens den pr. agent
modellen er agentens egen standard. Se
Routing.
Versioner, tilbageførsel og klon
Hver meningsfuld ændring af en agent registreres som en version. Dette gør agentkonfigurationen reviderbar og omvendelig: du kan gennemse, hvad der blev ændret, rulle tilbage til en tidligere version, eller klon en agent til at bruge det som udgangspunkt for en ny. Version- og profileressourcer findes under /v1/admin/agents/* (profil, sektioner, færdigheder, versioner).
[!TIP]
Klon en fungerende agent før en stor persona- eller prompt-omskrivning. Hvis den nye
hvis retningen ikke lykkes, er originalen stadig en tilbageførsel væk.
Den strukturerede “G3” prompt
I stedet for et enkelt frit tekstsystemprompt bruger AiHummer en struktureret agentprofil (internt “G3”). Identiteten er opdelt i felter snarere end begravet i prosa, og resten af prompten er bygget op af navngivne sektioner plus en introduktion blok. Orkestratoren gengiver disse i den lagdelte systemprompt, idet de stabile dele (identitet, persona, sektioner) holdes i et cachebart præfiks og de flygtige data tilføjes til sidst.
Strukturen gør det nemt at redigere en profil felt for felt, nemt at sammenligne mellem versioner og forudsigelig at gengive — der er ingen skjult prompt-suppe.
En agent kan få lov til at redigere sin egen profil at bruge selvredigeringsværktøjer — for eksempel til at forfine en sektion eller opdatere dens onboarding. Dette er bevidst beskyttet:
Selvredigeringer går gennem godkendelsesport: en foreslået ændring registreres og
skal godkendes af et menneske, før det træder i kraft. En afvist ændring er aldrig
anvendt.
Ændringen registreres som en ny version, så en selvredigering er lige så reviderbar
og lige så reversibel som enhver manuel redigering.
[!WARNING]
Selvredigering er kraftfuld. Hold det bag godkendelsesporten, så en agent ikke kan
stille omskrive sin egen identitet. Gennemgå foreslåede selvediteringer på samme måde, som du
gennemgå enhver privilegeret ændring.
Mailadgangskoder går til hvelvet
Hvis en agents konfiguration inkluderer maillegitimationsoplysninger (for mail værktøj), adgangskoden bliver skrevet til krypteret legitimationsopbevaring, ikke gemt i profilen eller indsat i prompten. Hemmeligheder kommer aldrig ind i modelkonteksten.
Kørselspolitik: kontekst, sessioner og underagenter
Fra version 1.3 har en agent en kørselspolitik — feltet runtime_policy i
admin-API’et (/v1/admin/agents ved oprettelse og opdatering). Det er et
strengt valideret JSON-objekt med "version": 1: et tomt {} genopretter
standardværdierne, udeladelse af feltet ved opdatering beholder den tidligere
politik, og ukendte felter eller værdier uden for grænserne afvises. Politikken
tildeler ingen værktøjer og udvider ingen rettigheder — den sætter kun budgetter
og frister. Kloning af en agent og overdragelse af en tur til den arver den.
context — historikbudgettet: max_tokens, reserve_tokens og
history_share afgør, hvor meget historik der indgår i en forespørgsel;
max_history_messages begrænser beskedvinduet, bootstrap_max_chars
profilblokkens størrelse. Med en eksplicit kontekst komprimeres ældre
beskeder til et resumé i portioner, før den aktuelle forespørgsel bygges.
pruning — oprydning af forældede værktøjsresultater: efter alder
(ttl_seconds), med beskyttelse af de seneste svar
(keep_last_assistants), blød beskæring (soft_trim_ratio, head_chars,
tail_chars) og fuld erstatning med placeholder-teksten over
hard_clear_ratio. Brugertekst, billeder og den fulde historik i databasen
berøres ikke.
memory_flush — før komprimeringen skriver en agent uden værktøjer et
kort notat om mål, beslutninger og åbne punkter (soft_threshold_tokens);
de tre seneste notater fra samme dialog blandes ind i konteksten som
ukontrolleret reference.
session — dialogens livscyklus: idle_reset_minutes starter en ny
kontekst efter en pause (den rå historik bevares), index_prune_after_days
og index_max_entries fjerner gamle dialoger fra standardlisten uden at
slette dem. scope = per-peer (én dialog pr. verificeret bruger på tværs
af kanaler) eller per-channel-peer (en separat dialog pr. kanal).
children — underagenter: max_depth (op til 4), max_concurrent (op
til 8 pr. kørselstræ), max_per_parent (op til 5), timeout_seconds (op til
48 timer, aldrig længere end forælderen) og archive_after_minutes — hvornår
afsluttede kørsler forlader standardlisten. Værdierne tilsidesætter de
globale AIHUMMER_SUBAGENT_MAX_DEPTH og AIHUMMER_SUBAGENT_TIMEOUT_SEC for
denne agent.
max_iterations (1–256) — trin-grænsen for funktionskaldsløkken til
gennemgåede scenarier med mange delegeringer.
app — kun for AiHummer-appen: reasoning_effort, service_tier og
kortsvarstilstanden direct_completion (auto eller always med
max_tokens op til 4096 og timeout_ms op til 60 000).
interaction — udtrykkelige sessionstilladelser: user_ids,
session_agent_ids, spawn_agent_ids, synligheden session_visibility
(self, agent eller granted), session_send, værktøjsforbud for
underkald (child_tool_deny, child_leaf_tool_deny) og
elevated_telegram_user_ids — en delmængde af user_ids, der må anmode om
udtrykkeligt forhøjet code_exec-kørsel (godkendelser omgås ikke). Der
findes hverken jokertegn eller tilladelser for hele lejeren.
Admin-API
Agenter og deres strukturerede profiler administreres under admin-API’en, som er OIDC-beskyttet og revideret:
En **agent** er enheden, som AiHummer sætter foran en samtale. Hver agent har en persona, sin egen model, en struktureret prompt og et sæt færdigheder, og hver ændring til den versionsstyres. Agenter administreres fra web-admin-UI'et og gennem admin-API'en under `/v1/admin/agents/*`.
Denne side dækker, hvad en agent består af, hvordan den strukturerede "G3"-prompt sammensættes, og hvordan en agent sikkert kan redigere sin egen profil.
## Agentregistret
Registeret er et fuldt CRUD-katalog over agenter. For hver agent definerer du en identitet, en persona, den model, den kører på, og de færdigheder, den kan bruge. Fordi gatewayen er multitenant, lever agenter inden for et arbejdsområde og er isoleret som enhver anden lejerdata.
- **Persona** — agentens stemme og adfærd, gengivet i en stald,
cache-venligt lag af systemprompten.
- **Per-agent model** — hver agent kan fastgøre sin egen model og udbyder, så en
En billig agent og en flagskibsagent kan sameksistere i det samme arbejdsområde.
- **Færdigheder** — per-agent og delte færdigheder gengiver en “Færdigheder”-blok i
prompt; de beskriver kapaciteter, ikke vægte.
> [!NOTE]
> En per-agent model er uafhængig af routing. Model-lag routing (simpel /
> standard / kompleks) vælger en modelklasse for en tur, mens den pr. agent
> modellen er agentens egen standard. Se
> [Routing](/da/v1.0/concepts/routing).
## Versioner, tilbageførsel og klon
Hver meningsfuld ændring af en agent registreres som en **version**. Dette gør agentkonfigurationen reviderbar og omvendelig: du kan gennemse, hvad der blev ændret, **rulle tilbage** til en tidligere version, eller **klon** en agent til at bruge det som udgangspunkt for en ny. Version- og profileressourcer findes under `/v1/admin/agents/*` (profil, sektioner, færdigheder, versioner).
> [!TIP]
> Klon en fungerende agent før en stor persona- eller prompt-omskrivning. Hvis den nye
> hvis retningen ikke lykkes, er originalen stadig en tilbageførsel væk.
## Den strukturerede "G3" prompt
I stedet for et enkelt frit tekstsystemprompt bruger AiHummer en **struktureret agentprofil** (internt "G3"). Identiteten er **opdelt i felter** snarere end begravet i prosa, og resten af prompten er bygget op af navngivne **sektioner** plus en **introduktion** blok. Orkestratoren gengiver disse i den lagdelte systemprompt, idet de stabile dele (identitet, persona, sektioner) holdes i et cachebart præfiks og de flygtige data tilføjes til sidst.
Strukturen gør det nemt at redigere en profil felt for felt, nemt at sammenligne mellem versioner og forudsigelig at gengive — der er ingen skjult prompt-suppe.
```text
G3 profile
├── identity fields (decomposed: name, role, ...)
├── sections (named, ordered prompt blocks)
└── onboarding (first-run guidance)
```
## Selvredigering bag en godkendelsesport
En agent kan få lov til at **redigere sin egen profil** at bruge selvredigeringsværktøjer — for eksempel til at forfine en sektion eller opdatere dens onboarding. Dette er bevidst beskyttet:
- Selvredigeringer går gennem **godkendelsesport**: en foreslået ændring registreres og
skal godkendes af et menneske, før det træder i kraft. En afvist ændring er aldrig
anvendt.
- Ændringen registreres som en ny **version**, så en selvredigering er lige så reviderbar
og lige så reversibel som enhver manuel redigering.
> [!WARNING]
> Selvredigering er kraftfuld. Hold det bag godkendelsesporten, så en agent ikke kan
> stille omskrive sin egen identitet. Gennemgå foreslåede selvediteringer på samme måde, som du
> gennemgå enhver privilegeret ændring.
### Mailadgangskoder går til hvelvet
Hvis en agents konfiguration inkluderer maillegitimationsoplysninger (for `mail` værktøj), adgangskoden bliver skrevet til **krypteret legitimationsopbevaring**, ikke gemt i profilen eller indsat i prompten. Hemmeligheder kommer aldrig ind i modelkonteksten.
## Kørselspolitik: kontekst, sessioner og underagenter
Fra version 1.3 har en agent en **kørselspolitik** — feltet `runtime_policy` i
admin-API’et (`/v1/admin/agents` ved oprettelse og opdatering). Det er et
strengt valideret JSON-objekt med `"version": 1`: et tomt `{}` genopretter
standardværdierne, udeladelse af feltet ved opdatering beholder den tidligere
politik, og ukendte felter eller værdier uden for grænserne afvises. Politikken
tildeler ingen værktøjer og udvider ingen rettigheder — den sætter kun budgetter
og frister. Kloning af en agent og overdragelse af en tur til den arver den.
- **`context`** — historikbudgettet: `max_tokens`, `reserve_tokens` og
`history_share` afgør, hvor meget historik der indgår i en forespørgsel;
`max_history_messages` begrænser beskedvinduet, `bootstrap_max_chars`
profilblokkens størrelse. Med en eksplicit kontekst komprimeres ældre
beskeder til et resumé i portioner, før den aktuelle forespørgsel bygges.
- **`pruning`** — oprydning af forældede værktøjsresultater: efter alder
(`ttl_seconds`), med beskyttelse af de seneste svar
(`keep_last_assistants`), blød beskæring (`soft_trim_ratio`, `head_chars`,
`tail_chars`) og fuld erstatning med `placeholder`-teksten over
`hard_clear_ratio`. Brugertekst, billeder og den fulde historik i databasen
berøres ikke.
- **`memory_flush`** — før komprimeringen skriver en agent uden værktøjer et
kort notat om mål, beslutninger og åbne punkter (`soft_threshold_tokens`);
de tre seneste notater fra samme dialog blandes ind i konteksten som
ukontrolleret reference.
- **`session`** — dialogens livscyklus: `idle_reset_minutes` starter en ny
kontekst efter en pause (den rå historik bevares), `index_prune_after_days`
og `index_max_entries` fjerner gamle dialoger fra standardlisten uden at
slette dem. `scope` = `per-peer` (én dialog pr. verificeret bruger på tværs
af kanaler) eller `per-channel-peer` (en separat dialog pr. kanal).
- **`children`** — underagenter: `max_depth` (op til 4), `max_concurrent` (op
til 8 pr. kørselstræ), `max_per_parent` (op til 5), `timeout_seconds` (op til
48 timer, aldrig længere end forælderen) og `archive_after_minutes` — hvornår
afsluttede kørsler forlader standardlisten. Værdierne tilsidesætter de
globale `AIHUMMER_SUBAGENT_MAX_DEPTH` og `AIHUMMER_SUBAGENT_TIMEOUT_SEC` for
denne agent.
- **`max_iterations`** (1–256) — trin-grænsen for funktionskaldsløkken til
gennemgåede scenarier med mange delegeringer.
- **`app`** — kun for AiHummer-appen: `reasoning_effort`, `service_tier` og
kortsvarstilstanden `direct_completion` (`auto` eller `always` med
`max_tokens` op til 4096 og `timeout_ms` op til 60 000).
- **`interaction`** — udtrykkelige sessionstilladelser: `user_ids`,
`session_agent_ids`, `spawn_agent_ids`, synligheden `session_visibility`
(`self`, `agent` eller `granted`), `session_send`, værktøjsforbud for
underkald (`child_tool_deny`, `child_leaf_tool_deny`) og
`elevated_telegram_user_ids` — en delmængde af `user_ids`, der må anmode om
udtrykkeligt forhøjet `code_exec`-kørsel (godkendelser omgås ikke). Der
findes hverken jokertegn eller tilladelser for hele lejeren.
## Admin-API
Agenter og deres strukturerede profiler administreres under admin-API'en, som er OIDC-beskyttet og revideret:
| Ressource | Formål |
|---|---|
| `/v1/admin/agents` | Liste, opret, opdater, slet agenter (CRUD) |
| `/v1/admin/agents/.../profile` | Den strukturerede G3-profil (identitetsfelter) |
| `/v1/admin/agents/.../sections` | Navngivne promptsektioner |
| `/v1/admin/agents/.../skills` | Færdigheder pr. agent |
| `/v1/admin/agents/.../versions` | Versionshistorik, tilbagetrækning og klon |
## Hvor til næste
- Forstå, hvordan agenter udfører en tur og fremkalder hjælpere i
[Orkestrering og underagenter](/da/v1.0/concepts/orchestration-subagents).
- Se, hvordan en indkommende besked når en specifik agent i
[Routing](/da/v1.0/concepts/routing).
- Giv dine agenter langsigtet hukommelse med
[Hukommelse (Einstein)](/da/v1.0/concepts/memory-einstein).
