Neviens aģents ir vienība, ko AiHummer liek sarunas priekšā. Katram aģentam ir personība, savs modelis, strukturēts uzvedne un prasmju kopums, un katras izmaiņas tiek versijuotas. Aģenti tiek pārvaldīti no tīmekļa administrēšanas lietotāja interfeisa un caur administrēšanas API zem /v1/admin/agents/*.
Šī lapa apraksta, no kā sastāv aģents, kā tiek izveidota strukturētā ‘G3’ uzvedne un kā aģents var droši rediģēt savu profilu.
Aģentu reģistrs
Reģistrs ir pilns CRUD aģentu katalogs. Katram aģentam jūs definējat identitāti, personību, modeli, uz kura tas darbojas, un prasmes, ko tas var izmantot. Tā kā vārteja ir daudznomnieku, aģenti dzīvo darbvietā un ir izolēti tāpat kā jebkuri citi nomnieka dati.
Persona — aģenta balss un uzvedība, pārtulkota stabilā,
sistēmas uzvednes kešatmiņai draudzīgā slānis.
Katram aģentam modelis — katrs aģents var piespraust savu modeli un nodrošinātāju, tāpēc a
Lēts aģents un galvenais aģents var līdzpastāvēt tajā pašā darba vidē.
Prasmes — katra aģenta un kopīgās prasmes pārvērš “Prasmju” bloku par
uzvedne; tās apraksta spējas, nevis svarus.
[!NOTE]
Aģenta modeļa līmenis ir neatkarīgs no maršrutēšanas. Modeļa slāņa maršrutēšana (vienkārša /
standarta / sarežģīts) izvēlas modeļa klasi vienam gājienam, kamēr katrs aģents
modelis ir paša aģenta noklusējums. Skatīt
Maršrutēšana.
Versijas, atcelšana un klons
Katras nozīmīgas izmaiņas aģentā tiek fiksētas kā versija. Tas padara aģenta konfigurāciju pārskatāmu un atgriezenisku: jūs varat pārskatīt, kas ir mainījies, atcelt izmaiņas uz iepriekšēju versiju, vai klons aģents to izmantot to kā sākumpunktu jaunam. Versijas un profila resursi dzīvo zem /v1/admin/agents/* (profils, sadaļas, prasmes, versijas).
[!TIP]
Klonējiet darba aģentu pirms lielas personas vai uzaicinājuma pārrakstīšanas. Ja jaunais
ja virziens neizdodas, oriģināls joprojām ir tikai vienas atsaukšanas attālumā.
Strukturētais “G3” uzvednes teksts
Vietā viena brīvteksta sistēmas uzvednes, AiHummer izmanto strukturēts aģenta profils (iekšēji “G3”). Identitāte ir sadalīts laukos nevis aprakti prozā, un pārējā uzvedne ir veidota no nosauktajiem sadaļas plus un ievadapmācība bloks. Orķestrators pārvērš tos slāņotajā sistēmas uzvednē, saglabājot stabilās daļas (identitāte, personība, sadaļas) kešojamā prefiksā un beigās pievienojot mainīgos datus.
Struktūra padara profilu viegli rediģējamu laukā pa laukam, viegli salīdzināmu starp versijām un paredzamu renderēšanai — nav nekādas slēptās uzvednes zupas.
Aģentam var būt atļauts rediģēt savu profilu izmantojot pašrediģēšanas rīkus — piemēram, lai uzlabotu sadaļu vai atjauninātu tās ievadapmācību. Tas ir apzināti aizsargāts:
Pašrediģējumi tiek izieti cauri apstiprināšanas vārti: ierosinātā izmaiņa tiek ierakstīta un
jābūt apstiprinātam cilvēka, pirms tas stājas spēkā. Noraidīta izmaiņa nekad
piemērots.
Izmaiņas tiek fiksētas kā jaunas versija, tāpēc pašrediģēšana ir tikpat pārbaudāma
un atgriezenisks kā jebkura manuāla rediģēšana.
[!WARNING]
Pašrediģēšana ir spēcīga. Glabājiet to aiz apstiprināšanas barjeras, lai aģents nevarētu
klusībā pārraksta savu identitāti. Pārskati ieteiktās pašrediģēšanas tāpat kā tu
pārskatīt jebkādas privilēģētās izmaiņas.
Pasta paroles tiek glabātas seifā
Ja aģenta konfigurācijā ir iekļauti pasta akreditācijas dati (lai mail rīks), parole tiek ierakstīta uz šifrēta akreditācijas glabātuve, netiek glabāti profilā vai attēloti uzvednē. Noslēpumi nekad neiet modela kontekstā.
Izpildes politika: konteksts, sesijas un bērnaģenti
Kopš versijas 1.3 aģentam ir izpildes politika — lauks runtime_policy
administrēšanas API (/v1/admin/agents izveidojot un atjauninot). Tas ir
stingri validēts JSON objekts ar "version": 1: tukšs {} atjauno
noklusējumus, lauka izlaišana atjauninot saglabā iepriekšējo politiku, bet
nezināmi lauki un vērtības ārpus pieļaujamām robežām tiek noraidītas. Politika
nepiešķir rīkus un nepaplašina tiesības — tā nosaka tikai budžetus un
termiņus. Aģenta klons un gājiena nodošana tam to manto.
context — vēstures budžets: max_tokens, reserve_tokens un
history_share nosaka, cik daudz vēstures nonāk pieprasījumā;
max_history_messages ierobežo ziņu logu, bootstrap_max_chars — profila
bloka lielumu. Kad konteksts ir norādīts skaidri, vecās ziņas pa daļām tiek
saspiestas kopsavilkumā, pirms tiek veidots pašreizējais pieprasījums.
pruning — novecojušu rīku rezultātu tīrīšana: pēc termiņa
(ttl_seconds), aizsargājot pēdējās atbildes (keep_last_assistants),
maiga apgriešana (soft_trim_ratio, head_chars, tail_chars) un pilnīga
aizstāšana ar placeholder tekstu, pārsniedzot hard_clear_ratio.
Lietotāja teksts, attēli un pilnā vēsture datubāzē netiek skarti.
memory_flush — pirms saspiešanas aģents bez rīkiem pieraksta īsu
piezīmi par mērķiem, lēmumiem un nepabeigtiem darbiem
(soft_threshold_tokens); pēdējās trīs tā paša dialoga piezīmes tiek
piejauktas kontekstam kā nepārbaudīta uzziņa.
session — dialoga dzīves cikls: idle_reset_minutes pēc pauzes sāk
jaunu kontekstu (neapstrādātā vēsture saglabājas), index_prune_after_days
un index_max_entries izņem vecos dialogus no noklusējuma saraksta, tos
nedzēšot. scope = per-peer (viens dialogs apstiprinātam lietotājam
visos kanālos) vai per-channel-peer (atsevišķs dialogs katram kanālam).
children — bērnaģenti: max_depth (līdz 4), max_concurrent (līdz 8
vienam palaišanas kokam), max_per_parent (līdz 5), timeout_seconds (līdz
48 stundām, bet ne ilgāk par vecāku) un archive_after_minutes — kad
pabeigtās palaišanas pazūd no noklusējuma saraksta. Vērtības šim aģentam
pārraksta globālos AIHUMMER_SUBAGENT_MAX_DEPTH un
AIHUMMER_SUBAGENT_TIMEOUT_SEC.
max_iterations (1–256) — funkciju izsaukumu cikla soļu limits
pārbaudītiem scenārijiem ar daudzām deleģēšanām.
app — tikai AiHummer lietotnei: reasoning_effort, service_tier un
īsās atbildes režīms direct_completion (auto vai always ar
max_tokens līdz 4096 un timeout_ms līdz 60 000).
interaction — skaidras atļaujas darbam ar sesijām: user_ids,
session_agent_ids, spawn_agent_ids, redzamība session_visibility
(self, agent vai granted), session_send, rīku aizliegumi
bērnizsaukumiem (child_tool_deny, child_leaf_tool_deny) un
elevated_telegram_user_ids — user_ids apakškopa, kurai atļauts pieprasīt
skaidri paaugstinātu code_exec izpildi (apstiprinājumi netiek apieti).
Aizstājējzīmju un atļauju visam nomniekam nav.
Administratora API
Aģenti un viņu strukturētie profili tiek pārvaldīti caur admin API, kas ir OIDC aizsargāts un uzraudzīts:
Neviens **aģents** ir vienība, ko AiHummer liek sarunas priekšā. Katram aģentam ir personība, savs modelis, strukturēts uzvedne un prasmju kopums, un katras izmaiņas tiek versijuotas. Aģenti tiek pārvaldīti no tīmekļa administrēšanas lietotāja interfeisa un caur administrēšanas API zem `/v1/admin/agents/*`.
Šī lapa apraksta, no kā sastāv aģents, kā tiek izveidota strukturētā 'G3' uzvedne un kā aģents var droši rediģēt savu profilu.
## Aģentu reģistrs
Reģistrs ir pilns CRUD aģentu katalogs. Katram aģentam jūs definējat identitāti, personību, modeli, uz kura tas darbojas, un prasmes, ko tas var izmantot. Tā kā vārteja ir daudznomnieku, aģenti dzīvo darbvietā un ir izolēti tāpat kā jebkuri citi nomnieka dati.
- **Persona** — aģenta balss un uzvedība, pārtulkota stabilā,
sistēmas uzvednes kešatmiņai draudzīgā slānis.
- **Katram aģentam modelis** — katrs aģents var piespraust savu modeli un nodrošinātāju, tāpēc a
Lēts aģents un galvenais aģents var līdzpastāvēt tajā pašā darba vidē.
- **Prasmes** — katra aģenta un kopīgās prasmes pārvērš “Prasmju” bloku par
uzvedne; tās apraksta spējas, nevis svarus.
> [!NOTE]
> Aģenta modeļa līmenis ir neatkarīgs no maršrutēšanas. Modeļa slāņa maršrutēšana (vienkārša /
> standarta / sarežģīts) izvēlas modeļa klasi vienam gājienam, kamēr katrs aģents
> modelis ir paša aģenta noklusējums. Skatīt
> [Maršrutēšana](/lv/v1.0/concepts/routing).
## Versijas, atcelšana un klons
Katras nozīmīgas izmaiņas aģentā tiek fiksētas kā **versija**. Tas padara aģenta konfigurāciju pārskatāmu un atgriezenisku: jūs varat pārskatīt, kas ir mainījies, **atcelt izmaiņas** uz iepriekšēju versiju, vai **klons** aģents to izmantot to kā sākumpunktu jaunam. Versijas un profila resursi dzīvo zem `/v1/admin/agents/*` (profils, sadaļas, prasmes, versijas).
> [!TIP]
> Klonējiet darba aģentu pirms lielas personas vai uzaicinājuma pārrakstīšanas. Ja jaunais
> ja virziens neizdodas, oriģināls joprojām ir tikai vienas atsaukšanas attālumā.
## Strukturētais "G3" uzvednes teksts
Vietā viena brīvteksta sistēmas uzvednes, AiHummer izmanto **strukturēts aģenta profils** (iekšēji "G3"). Identitāte ir **sadalīts laukos** nevis aprakti prozā, un pārējā uzvedne ir veidota no nosauktajiem **sadaļas** plus un **ievadapmācība** bloks. Orķestrators pārvērš tos slāņotajā sistēmas uzvednē, saglabājot stabilās daļas (identitāte, personība, sadaļas) kešojamā prefiksā un beigās pievienojot mainīgos datus.
Struktūra padara profilu viegli rediģējamu laukā pa laukam, viegli salīdzināmu starp versijām un paredzamu renderēšanai — nav nekādas slēptās uzvednes zupas.
```text
G3 profile
├── identity fields (decomposed: name, role, ...)
├── sections (named, ordered prompt blocks)
└── onboarding (first-run guidance)
```
## Pašrediģēšana aiz apstiprināšanas barjeras
Aģentam var būt atļauts **rediģēt savu profilu** izmantojot pašrediģēšanas rīkus — piemēram, lai uzlabotu sadaļu vai atjauninātu tās ievadapmācību. Tas ir apzināti aizsargāts:
- Pašrediģējumi tiek izieti cauri **apstiprināšanas vārti**: ierosinātā izmaiņa tiek ierakstīta un
jābūt apstiprinātam cilvēka, pirms tas stājas spēkā. Noraidīta izmaiņa nekad
piemērots.
- Izmaiņas tiek fiksētas kā jaunas **versija**, tāpēc pašrediģēšana ir tikpat pārbaudāma
un atgriezenisks kā jebkura manuāla rediģēšana.
> [!WARNING]
> Pašrediģēšana ir spēcīga. Glabājiet to aiz apstiprināšanas barjeras, lai aģents nevarētu
> klusībā pārraksta savu identitāti. Pārskati ieteiktās pašrediģēšanas tāpat kā tu
> pārskatīt jebkādas privilēģētās izmaiņas.
### Pasta paroles tiek glabātas seifā
Ja aģenta konfigurācijā ir iekļauti pasta akreditācijas dati (lai `mail` rīks), parole tiek ierakstīta uz **šifrēta akreditācijas glabātuve**, netiek glabāti profilā vai attēloti uzvednē. Noslēpumi nekad neiet modela kontekstā.
## Izpildes politika: konteksts, sesijas un bērnaģenti
Kopš versijas 1.3 aģentam ir **izpildes politika** — lauks `runtime_policy`
administrēšanas API (`/v1/admin/agents` izveidojot un atjauninot). Tas ir
stingri validēts JSON objekts ar `"version": 1`: tukšs `{}` atjauno
noklusējumus, lauka izlaišana atjauninot saglabā iepriekšējo politiku, bet
nezināmi lauki un vērtības ārpus pieļaujamām robežām tiek noraidītas. Politika
nepiešķir rīkus un nepaplašina tiesības — tā nosaka tikai budžetus un
termiņus. Aģenta klons un gājiena nodošana tam to manto.
- **`context`** — vēstures budžets: `max_tokens`, `reserve_tokens` un
`history_share` nosaka, cik daudz vēstures nonāk pieprasījumā;
`max_history_messages` ierobežo ziņu logu, `bootstrap_max_chars` — profila
bloka lielumu. Kad konteksts ir norādīts skaidri, vecās ziņas pa daļām tiek
saspiestas kopsavilkumā, pirms tiek veidots pašreizējais pieprasījums.
- **`pruning`** — novecojušu rīku rezultātu tīrīšana: pēc termiņa
(`ttl_seconds`), aizsargājot pēdējās atbildes (`keep_last_assistants`),
maiga apgriešana (`soft_trim_ratio`, `head_chars`, `tail_chars`) un pilnīga
aizstāšana ar `placeholder` tekstu, pārsniedzot `hard_clear_ratio`.
Lietotāja teksts, attēli un pilnā vēsture datubāzē netiek skarti.
- **`memory_flush`** — pirms saspiešanas aģents bez rīkiem pieraksta īsu
piezīmi par mērķiem, lēmumiem un nepabeigtiem darbiem
(`soft_threshold_tokens`); pēdējās trīs tā paša dialoga piezīmes tiek
piejauktas kontekstam kā nepārbaudīta uzziņa.
- **`session`** — dialoga dzīves cikls: `idle_reset_minutes` pēc pauzes sāk
jaunu kontekstu (neapstrādātā vēsture saglabājas), `index_prune_after_days`
un `index_max_entries` izņem vecos dialogus no noklusējuma saraksta, tos
nedzēšot. `scope` = `per-peer` (viens dialogs apstiprinātam lietotājam
visos kanālos) vai `per-channel-peer` (atsevišķs dialogs katram kanālam).
- **`children`** — bērnaģenti: `max_depth` (līdz 4), `max_concurrent` (līdz 8
vienam palaišanas kokam), `max_per_parent` (līdz 5), `timeout_seconds` (līdz
48 stundām, bet ne ilgāk par vecāku) un `archive_after_minutes` — kad
pabeigtās palaišanas pazūd no noklusējuma saraksta. Vērtības šim aģentam
pārraksta globālos `AIHUMMER_SUBAGENT_MAX_DEPTH` un
`AIHUMMER_SUBAGENT_TIMEOUT_SEC`.
- **`max_iterations`** (1–256) — funkciju izsaukumu cikla soļu limits
pārbaudītiem scenārijiem ar daudzām deleģēšanām.
- **`app`** — tikai AiHummer lietotnei: `reasoning_effort`, `service_tier` un
īsās atbildes režīms `direct_completion` (`auto` vai `always` ar
`max_tokens` līdz 4096 un `timeout_ms` līdz 60 000).
- **`interaction`** — skaidras atļaujas darbam ar sesijām: `user_ids`,
`session_agent_ids`, `spawn_agent_ids`, redzamība `session_visibility`
(`self`, `agent` vai `granted`), `session_send`, rīku aizliegumi
bērnizsaukumiem (`child_tool_deny`, `child_leaf_tool_deny`) un
`elevated_telegram_user_ids` — `user_ids` apakškopa, kurai atļauts pieprasīt
skaidri paaugstinātu `code_exec` izpildi (apstiprinājumi netiek apieti).
Aizstājējzīmju un atļauju visam nomniekam nav.
## Administratora API
Aģenti un viņu strukturētie profili tiek pārvaldīti caur admin API, kas ir OIDC aizsargāts un uzraudzīts:
| Resursi | Mērķis |
|---|---|
| `/v1/admin/agents` | Sarakstīt, izveidot, atjaunināt, dzēst aģentus (CRUD) |
| `/v1/admin/agents/.../profile` | Strukturētais G3 profils (identitātes lauki) |
| `/v1/admin/agents/.../sections` | Nosauktās uzvednes sadaļas |
| `/v1/admin/agents/.../skills` | Katram aģentam prasmes |
| `/v1/admin/agents/.../versions` | Versijas vēsture, atcelšana un klonēšana |
## Kur uz nākamo
- Izprotiet, kā aģenti veic kārtu un rada palīgus
[Orķestrācija un apakšaģenti](/lv/v1.0/concepts/orchestration-subagents).
- Skatiet, kā ienākošais ziņojums sasniedz konkrētu aģentu
[Maršrutēšana](/lv/v1.0/concepts/routing).
- Dodiet saviem aģentiem ilgtermiņa atmiņu ar
[Atmiņa (Einšteins)](/lv/v1.0/concepts/memory-einstein).
