En agent är enheten som AiHummer sätter framför en konversation. Varje agent har en persona, sin egen modell, en strukturerad prompt och en uppsättning färdigheter, och varje ändring av den versionshanteras. Agenter hanteras från webbadministrationsgränssnittet och genom administrations-API:et under /v1/admin/agents/*.
Denna sida behandlar vad en agent består av, hur den strukturerade “G3”-prompten sätts ihop, och hur en agent säkert kan redigera sin egen profil.
Agentregistret
Registret är en fullständig CRUD-katalog över agenter. För varje agent definierar du en identitet, en persona, modellen den körs på och de färdigheter den kan använda. Eftersom gatewayen är multitenant, lever agenterna inom ett arbetsområde och är isolerade som vilken annan tenant-data som helst.
Persona — agentens röst och beteende, återgivna i en stall,
cache-vänligt lager av systemprompten.
Per-agentmodell — varje agent kan spika sin egen modell och leverantör, så en
En billig agent och en flaggskeppsagent kan samexistera i samma arbetsyta.
Färdigheter — per-agent och delade färdigheter renderar en “Färdigheter”-block till
prompt; de beskriver kapaciteter, inte vikter.
[!NOTE]
En per-agent modell är oberoende av routing. Modell-nivå routing (enkel /
standard / komplex) väljer en modellklass för en tur, medan per-agent
modellen är agentens egen standard. Se
Routing.
Versioner, återställning och kloning
Varje meningsfull förändring av en agent fångas som en version. Detta gör agentkonfigurationen granskbar och omvändbar: du kan se vad som har ändrats, återställa till en tidigare version, eller klon en agent att använda det som utgångspunkt för en ny. Versions- och profileresurser finns under /v1/admin/agents/* (profil, sektioner, färdigheter, versioner).
[!TIP]
Klon en fungerande agent innan en stor personlighets- eller promptomskrivning. Om den nya
om riktningen inte fungerar, är originalet fortfarande ett återställningssteg bort.
Den strukturerade “G3”-uppmaningen
Istället för en enda fritextsystemuppmaning använder AiHummer en strukturerad agentprofil (internt “G3”). Identiteten är uppdelad i fält snarare än begravd i prosa, och resten av uppmaningen är byggd från namngivna avsnitt plus en introduktion block. Orkestratorn renderar dessa i det lagerlade systempromptet, och behåller de stabila delarna (identitet, persona, sektioner) i ett cachbart prefix och lägger till flyktig data sist.
Strukturen gör att en profil är lätt att redigera fält för fält, lätt att jämföra mellan versioner och förutsägbar att återge — det finns ingen dold prompt-soppa.
En agent kan tillåtas att redigera sin egen profil använda självredigeringsverktyg — till exempel för att förbättra en sektion eller uppdatera dess introduktion. Detta är medvetet skyddat:
Självredigeringar går igenom godkännandekontroll: en föreslagen ändring registreras och
måste godkännas av en människa innan det träder i kraft. En avvisad ändring är aldrig
tillämpad.
Förändringen registreras som en ny version, så en självredigering är lika granskbar
och omvändbar som vilken manuell redigering som helst.
[!WARNING]
Självredigering är kraftfullt. Håll det bakom godkännandegrinden så att en agent inte kan
tyst omskriver sin egen identitet. Granska föreslagna självediteringar på samma sätt som du
granska alla privilegierade ändringar.
E-postlösenord går till valvet
Om en agents konfiguration inkluderar e-postuppgifter (för mail verktyg), lösenordet skrivs till krypterad behörighetsvalv, inte lagrat i profilen eller renderat i prompten. Hemligheter kommer aldrig in i modellens kontext.
Körningspolicy: kontext, sessioner och underagenter
Från version 1.3 har en agent en körningspolicy — fältet runtime_policy i
admin-API:et (/v1/admin/agents vid skapande och uppdatering). Det är ett
strikt validerat JSON-objekt med "version": 1: ett tomt {} återställer
standardvärdena, att utelämna fältet vid uppdatering behåller den tidigare
policyn, och okända fält eller värden utanför gränserna avvisas. Policyn
tilldelar inga verktyg och utvidgar inga rättigheter — den sätter bara budgetar
och tidsgränser. Kloning av en agent och överlämning av en tur till den ärver
den.
context — historikbudgeten: max_tokens, reserve_tokens och
history_share avgör hur mycket historik som ingår i en förfrågan;
max_history_messages begränsar meddelandefönstret, bootstrap_max_chars
profilblockets storlek. Med en explicit kontext komprimeras äldre meddelanden
till en sammanfattning i omgångar innan den aktuella förfrågan byggs.
pruning — rensning av föråldrade verktygsresultat: efter ålder
(ttl_seconds), med skydd av de senaste svaren (keep_last_assistants),
mjuk beskärning (soft_trim_ratio, head_chars, tail_chars) och full
ersättning med placeholder-texten över hard_clear_ratio. Användartext,
bilder och hela historiken i databasen berörs inte.
memory_flush — före komprimeringen skriver en agent utan verktyg en
kort anteckning om mål, beslut och öppna punkter (soft_threshold_tokens);
de tre senaste anteckningarna från samma dialog blandas in i kontexten som
ogranskad referens.
session — dialogens livscykel: idle_reset_minutes startar en ny
kontext efter en paus (råhistoriken bevaras), index_prune_after_days och
index_max_entries tar bort gamla dialoger från standardlistan utan att
radera dem. scope = per-peer (en dialog per verifierad användare över
alla kanaler) eller per-channel-peer (en separat dialog per kanal).
children — underagenter: max_depth (upp till 4), max_concurrent
(upp till 8 per körningsträd), max_per_parent (upp till 5),
timeout_seconds (upp till 48 timmar, aldrig längre än föräldern) och
archive_after_minutes — när avslutade körningar lämnar standardlistan.
Värdena åsidosätter de globala AIHUMMER_SUBAGENT_MAX_DEPTH och
AIHUMMER_SUBAGENT_TIMEOUT_SEC för denna agent.
max_iterations (1–256) — steggränsen för funktionsanropsloopen för
granskade scenarier med många delegeringar.
app — endast för AiHummer-appen: reasoning_effort, service_tier
och kortsvarsläget direct_completion (auto eller always med
max_tokens upp till 4096 och timeout_ms upp till 60 000).
interaction — uttryckliga sessionsbehörigheter: user_ids,
session_agent_ids, spawn_agent_ids, synligheten session_visibility
(self, agent eller granted), session_send, verktygsförbud för
underanrop (child_tool_deny, child_leaf_tool_deny) och
elevated_telegram_user_ids — en delmängd av user_ids som får begära
uttryckligen upphöjd code_exec-körning (godkännanden kringgås inte). Det
finns varken jokertecken eller behörigheter för hela hyresgästen.
Admin-API
Agenter och deras strukturerade profiler hanteras under admin-API:t, som är OIDC-skyddat och granskats:
En **agent** är enheten som AiHummer sätter framför en konversation. Varje agent har en persona, sin egen modell, en strukturerad prompt och en uppsättning färdigheter, och varje ändring av den versionshanteras. Agenter hanteras från webbadministrationsgränssnittet och genom administrations-API:et under `/v1/admin/agents/*`.
Denna sida behandlar vad en agent består av, hur den strukturerade "G3"-prompten sätts ihop, och hur en agent säkert kan redigera sin egen profil.
## Agentregistret
Registret är en fullständig CRUD-katalog över agenter. För varje agent definierar du en identitet, en persona, modellen den körs på och de färdigheter den kan använda. Eftersom gatewayen är multitenant, lever agenterna inom ett arbetsområde och är isolerade som vilken annan tenant-data som helst.
- **Persona** — agentens röst och beteende, återgivna i en stall,
cache-vänligt lager av systemprompten.
- **Per-agentmodell** — varje agent kan spika sin egen modell och leverantör, så en
En billig agent och en flaggskeppsagent kan samexistera i samma arbetsyta.
- **Färdigheter** — per-agent och delade färdigheter renderar en "Färdigheter"-block till
prompt; de beskriver kapaciteter, inte vikter.
> [!NOTE]
> En per-agent modell är oberoende av routing. Modell-nivå routing (enkel /
> standard / komplex) väljer en modellklass för en tur, medan per-agent
> modellen är agentens egen standard. Se
> [Routing](/sv/v1.0/concepts/routing).
## Versioner, återställning och kloning
Varje meningsfull förändring av en agent fångas som en **version**. Detta gör agentkonfigurationen granskbar och omvändbar: du kan se vad som har ändrats, **återställa** till en tidigare version, eller **klon** en agent att använda det som utgångspunkt för en ny. Versions- och profileresurser finns under `/v1/admin/agents/*` (profil, sektioner, färdigheter, versioner).
> [!TIP]
> Klon en fungerande agent innan en stor personlighets- eller promptomskrivning. Om den nya
> om riktningen inte fungerar, är originalet fortfarande ett återställningssteg bort.
## Den strukturerade "G3"-uppmaningen
Istället för en enda fritextsystemuppmaning använder AiHummer en **strukturerad agentprofil** (internt "G3"). Identiteten är **uppdelad i fält** snarare än begravd i prosa, och resten av uppmaningen är byggd från namngivna **avsnitt** plus en **introduktion** block. Orkestratorn renderar dessa i det lagerlade systempromptet, och behåller de stabila delarna (identitet, persona, sektioner) i ett cachbart prefix och lägger till flyktig data sist.
Strukturen gör att en profil är lätt att redigera fält för fält, lätt att jämföra mellan versioner och förutsägbar att återge — det finns ingen dold prompt-soppa.
```text
G3 profile
├── identity fields (decomposed: name, role, ...)
├── sections (named, ordered prompt blocks)
└── onboarding (first-run guidance)
```
## Självredigering bakom en godkännandespärr
En agent kan tillåtas att **redigera sin egen profil** använda självredigeringsverktyg — till exempel för att förbättra en sektion eller uppdatera dess introduktion. Detta är medvetet skyddat:
- Självredigeringar går igenom **godkännandekontroll**: en föreslagen ändring registreras och
måste godkännas av en människa innan det träder i kraft. En avvisad ändring är aldrig
tillämpad.
- Förändringen registreras som en ny **version**, så en självredigering är lika granskbar
och omvändbar som vilken manuell redigering som helst.
> [!WARNING]
> Självredigering är kraftfullt. Håll det bakom godkännandegrinden så att en agent inte kan
> tyst omskriver sin egen identitet. Granska föreslagna självediteringar på samma sätt som du
> granska alla privilegierade ändringar.
### E-postlösenord går till valvet
Om en agents konfiguration inkluderar e-postuppgifter (för `mail` verktyg), lösenordet skrivs till **krypterad behörighetsvalv**, inte lagrat i profilen eller renderat i prompten. Hemligheter kommer aldrig in i modellens kontext.
## Körningspolicy: kontext, sessioner och underagenter
Från version 1.3 har en agent en **körningspolicy** — fältet `runtime_policy` i
admin-API:et (`/v1/admin/agents` vid skapande och uppdatering). Det är ett
strikt validerat JSON-objekt med `"version": 1`: ett tomt `{}` återställer
standardvärdena, att utelämna fältet vid uppdatering behåller den tidigare
policyn, och okända fält eller värden utanför gränserna avvisas. Policyn
tilldelar inga verktyg och utvidgar inga rättigheter — den sätter bara budgetar
och tidsgränser. Kloning av en agent och överlämning av en tur till den ärver
den.
- **`context`** — historikbudgeten: `max_tokens`, `reserve_tokens` och
`history_share` avgör hur mycket historik som ingår i en förfrågan;
`max_history_messages` begränsar meddelandefönstret, `bootstrap_max_chars`
profilblockets storlek. Med en explicit kontext komprimeras äldre meddelanden
till en sammanfattning i omgångar innan den aktuella förfrågan byggs.
- **`pruning`** — rensning av föråldrade verktygsresultat: efter ålder
(`ttl_seconds`), med skydd av de senaste svaren (`keep_last_assistants`),
mjuk beskärning (`soft_trim_ratio`, `head_chars`, `tail_chars`) och full
ersättning med `placeholder`-texten över `hard_clear_ratio`. Användartext,
bilder och hela historiken i databasen berörs inte.
- **`memory_flush`** — före komprimeringen skriver en agent utan verktyg en
kort anteckning om mål, beslut och öppna punkter (`soft_threshold_tokens`);
de tre senaste anteckningarna från samma dialog blandas in i kontexten som
ogranskad referens.
- **`session`** — dialogens livscykel: `idle_reset_minutes` startar en ny
kontext efter en paus (råhistoriken bevaras), `index_prune_after_days` och
`index_max_entries` tar bort gamla dialoger från standardlistan utan att
radera dem. `scope` = `per-peer` (en dialog per verifierad användare över
alla kanaler) eller `per-channel-peer` (en separat dialog per kanal).
- **`children`** — underagenter: `max_depth` (upp till 4), `max_concurrent`
(upp till 8 per körningsträd), `max_per_parent` (upp till 5),
`timeout_seconds` (upp till 48 timmar, aldrig längre än föräldern) och
`archive_after_minutes` — när avslutade körningar lämnar standardlistan.
Värdena åsidosätter de globala `AIHUMMER_SUBAGENT_MAX_DEPTH` och
`AIHUMMER_SUBAGENT_TIMEOUT_SEC` för denna agent.
- **`max_iterations`** (1–256) — steggränsen för funktionsanropsloopen för
granskade scenarier med många delegeringar.
- **`app`** — endast för AiHummer-appen: `reasoning_effort`, `service_tier`
och kortsvarsläget `direct_completion` (`auto` eller `always` med
`max_tokens` upp till 4096 och `timeout_ms` upp till 60 000).
- **`interaction`** — uttryckliga sessionsbehörigheter: `user_ids`,
`session_agent_ids`, `spawn_agent_ids`, synligheten `session_visibility`
(`self`, `agent` eller `granted`), `session_send`, verktygsförbud för
underanrop (`child_tool_deny`, `child_leaf_tool_deny`) och
`elevated_telegram_user_ids` — en delmängd av `user_ids` som får begära
uttryckligen upphöjd `code_exec`-körning (godkännanden kringgås inte). Det
finns varken jokertecken eller behörigheter för hela hyresgästen.
## Admin-API
Agenter och deras strukturerade profiler hanteras under admin-API:t, som är OIDC-skyddat och granskats:
| Resurs | Syfte |
|---|---|
| `/v1/admin/agents` | Lista, skapa, uppdatera, ta bort agenter (CRUD) |
| `/v1/admin/agents/.../profile` | Den strukturerade G3-profilen (identitetsfält) |
| `/v1/admin/agents/.../sections` | Namngivna uppmaningsavsnitt |
| `/v1/admin/agents/.../skills` | Färdigheter per agent |
| `/v1/admin/agents/.../versions` | Versionshistorik, återställning och kloning |
## Vart härnäst
- Förstå hur agenter kör en tur och skapar hjälpare i
[Orkestrering och underagenter](/sv/v1.0/concepts/orchestration-subagents).
- Se hur ett inkommande meddelande når en specifik agent i
[Routing](/sv/v1.0/concepts/routing).
- Ge dina agenter långtidsminne med
[Minne (Einstein)](/sv/v1.0/concepts/memory-einstein).
