Մեկ գործակալ այս այն միավորն է, որը AiHummer-ը տեղադրում է զրույցից առաջ։ Յուրաքանչյուր գործակալ ունի կերպար, սեփական մոդել, կառուցվածքային հարցում և հմտությունների հավաքածու, և նրա մեջ կատարվող յուրաքանչյուր փոփոխություն վերսիավորվում է։ Գործակալները կառավարվում են վեբ ադմինիստրատորական ինտերֆեյսի միջոցով և միջոցով վարչական API-ի շրջանակներում /v1/admin/agents/*.
Այս էջում քննարկվում է, թե ինչից է բաղկացած գործակալը, ինչպես են հավաքվում կառուցվածքային «G3» հարցումները և ինչպես կարող է գործակալը անվտանգորեն խմբագրել իր սեփական պրոֆիլը։
Գործակալների ռեեստր
Ռեեստրը ֆոլիս կատալոգ է գործակալների՝ CRUD հնարավորությամբ: Յուրաքանչյուր գործակալի համար դուք որոշում եք անձը, կերպարը, մոդելը, որի վրա նա աշխատում է, և հմտությունները, որոնցից նա կարող է օգտվել: Հաշվի առնելով, որ դարպասը բազմաբնակիչ է, գործակալները գտնվում են աշխատանքային տարածքի ներսում և ամրացված են, ինչպես ցանկացած այլ վարձատուի տվյալներ։
Անձ — ձայնն ու գործակալության վարքը, փոխանցված աստվարջիք
Cache-ընկալող շերտ համակարգային հարցման համար:
Մոդել ըստ գործակալի — յուրաքանչյուր գործակալ կարող է հաստատել իր սեփական մոդելը և պրովայդերին, այնպես որ
ժամանակակից գործակալը և դրոշակակիր գործակալը կարող են գոյակցել մեկ աշխատանքային տարածքում։
Հմտություններ — Յուրաքանչյուր գործակալի հմտություններն ու ընդհանուր հմտությունները ցուցադրվում են «Հմտություններ» բլոկում
հուշում; դրանք նկարագրում են հնարավորությունները, ոչ թե քաշերը։
[!NOTE]
Մոդելը գործակալի վրա անկախ է երթուղեգրմանից։ Երթուղեգրումն ըստ մոդելի մակարդակի (հեշտ /
համաչափ / բարդ) ընտրում է մի մոդելի դասակարգում նշված շրջանի համար, մինչդեռ յուրաքանչյուր գործակցի դեպքում
մոդելը գործը կատարող գործակալին պատկանող նախնական կարգավորումն է։ Տե՛ս
Ուղղորդում.
Տարբերակներ, հետընթաց և քլոնավորում
Անհրաժեշտ յուրաքանչյուր փոփոխություն գործակալում գրանցվում է որպես տարբերակ. Դա գրում է գործակալության կազմաձևը ստուգելի և հակադարձելի. դուք կարող եք դիտարկել, թե ինչ է փոխվել, հետ հետ հրել ավելի վաղ թողարկված տարբերակին, կամ կլոն գործակալ օգտագործման նրա որպես նորի ելակետ։ Վարկածի և պրոֆիլի ռեսուրսները գտնվում են /v1/admin/agents/* (պրոֆիլ, բաժիններ, հմտություններ, տարբերակներ).
[!TIP]
Ստեղծեք գործող գործակալի պատճեն մեծ կերպարի կամ հրահանգի վերաշարադրմամբ առաջի։ Եթե նոր
եթե ուղղությունը արդարացվի, բնօրինակն դեռ մեկ հետքայլով է ուշանում։
Կառուցված հարցում «G3»
Մի պատահական տեքստով մեկ հուշիչ համակարգի փոխարեն, AiHummer-ը օգտագործում է ագենտի կառուցվածքային պրոֆիլ (ներքին «G3»). Անձնությունը հանդիսանում է բաժանված դաշտերի փոխարենը, որ թաքնված լինի արձակ նամակում, իսկ հրահանգի մնացած մասը կառուցված է անվանվածներից բաժիններ գումարած մեկ պաշտոնում ներմուծում բլոկ։ Օրկեստրատորը նրանց վերածում է բազմաշերտ համակարգային հարցման, պահպանելով կայուն մասերը (համաձայնություն, կերպար, բաժիններ) պահվող պրեֆիքսում և ավելացնում վերջին փոփոխվող տվյալները։
Այս կառուցվածքը թույլ է տալիս հեշտությամբ խմբագրել պրոֆիլը դաշտերով, պարզապես համեմատել տարբերակները և կանխատեսված կերպով ցուցադրել — չկա թաքնված «աղիացված» հուշումների զանգված։
Ազատ է գրվում գործակալին խմբագրել ձեր սեփական պրոֆիլը ինքնաստեղծման գործիքների օգտագործումը՝ օրինակ, բաժինը ճշգրտելու կամ դրա ինդուկցիոն գործընթացը թարմացնելու համար։ Սա դիտամտորեն պաշտպանված է՝
Ինքնուրույն զեկուցումները անցնում են միջոցով հաստատման փրկակետ: առաջարկվող փոփոխությունը գրանցվել է և
պետք է հաստատվի մարդու կողմից, նախքան այն ուժի մեջ մտնելը։ Մերժված փոփոխությունը երբեք չի
կիրառվել է։
Այլացումը արձանագրվում է որպես նոր տարբերակ, այդ պատճառով ինքնուրույն խմբագրումը նույնպես ենթարկվում է ստուգմանը
և վերադարձնելի, ինչպես ցանկացած ձեռքի խմբագրում։
[!WARNING]
Ինքնակառավարումը — դա հզոր գործիք է։ Պահեք այն եկամուտների դարպասներից դուրս, որպեսզի գործակալը չկարողանա
լուռ կերպով վերակազմակերպում է իր սեփական ինքնությունը: Տեսեք առաջարկվող ինքնախմբագրումները այնպես, ինչպես դուք
դիտել ցանկացած բարվոք փոփոխություն։
Էլ.հաղորդագրությունների գաղտնաբառերը ուղարկվում են պահոց
Եթե գործակալի կազմը ներառում է փոստային հաշվի տվյալներ (որպես mail գործիք), գաղտնաբառը գրանցվում է ակնային ծածկագրված տվյալների պահոց, չեն պահպանվում պրոֆիլում և չեն երևում նամականուշում։ Գաղտնիքները երբեք չեն մտնում մոդելի կոնտեքստում։
Կատարման քաղաքականություն. համատեքստ, նիստեր և դուստր գործակալներ
1.3 տարբերակից գործակալն ունի կատարման քաղաքականություն — runtime_policy
դաշտը ադմին API-ում (/v1/admin/agents ստեղծելիս և թարմացնելիս)։ Սա խիստ
վավերացվող JSON օբյեկտ է "version": 1-ով. դատարկ {}-ը վերադարձնում է
լռելյայն արժեքները, թարմացնելիս դաշտի բացթողումը պահպանում է նախորդ
քաղաքականությունը, իսկ անհայտ դաշտերն ու թույլատրելի սահմաններից դուրս
արժեքները մերժվում են։ Քաղաքականությունը գործիքներ չի տալիս և իրավունքներ չի
ընդլայնում — այն սահմանում է միայն բյուջեներ և ժամկետներ։ Գործակալի կլոնը և
նրան հերթի փոխանցումը ժառանգում են այն։
context — պատմության բյուջե. max_tokens, reserve_tokens և
history_share որոշում են, թե որքան պատմություն է մտնում հարցման մեջ.
max_history_messages-ը սահմանափակում է հաղորդագրությունների պատուհանը,
bootstrap_max_chars-ը՝ պրոֆիլի բլոկի չափը։ Երբ համատեքստը հստակ նշված է,
հին հաղորդագրությունները մասերով սեղմվում են ամփոփման մեջ՝ նախքան ընթացիկ
հարցման կազմումը։
pruning — հնացած գործիքային արդյունքների մաքրում. ըստ ժամկետի
(ttl_seconds), վերջին պատասխանների պաշտպանությամբ
(keep_last_assistants), մեղմ կրճատում (soft_trim_ratio, head_chars,
tail_chars) և ամբողջական փոխարինում placeholder տեքստով
hard_clear_ratio-ն գերազանցելիս։ Օգտատիրոջ տեքստը, պատկերները և բազայի
ամբողջական պատմությունը չեն շոշափվում։
memory_flush — սեղմումից առաջ գործիքներ չունեցող գործակալը գրում է
կարճ նշում նպատակների, որոշումների և անավարտ գործերի մասին
(soft_threshold_tokens). նույն երկխոսության վերջին երեք նշումները
խառնվում են համատեքստի մեջ որպես չստուգված տեղեկանք։
session — երկխոսության կյանքի ցիկլ. idle_reset_minutes-ը դադարից
հետո սկսում է նոր համատեքստ (հում պատմությունը պահպանվում է),
index_prune_after_days-ը և index_max_entries-ը հին երկխոսությունները
հանում են լռելյայն ցանկից՝ առանց ջնջելու։ scope = per-peer (մեկ
երկխոսություն հաստատված օգտատիրոջ համար բոլոր ալիքներում) կամ
per-channel-peer (առանձին երկխոսություն յուրաքանչյուր ալիքի համար)։
children — դուստր գործակալներ. max_depth (մինչև 4), max_concurrent
(մինչև 8 մեկ գործարկման ծառի համար), max_per_parent (մինչև 5),
timeout_seconds (մինչև 48 ժամ, բայց ոչ ավելի, քան ծնողը) և
archive_after_minutes — երբ ավարտված գործարկումները դուրս են գալիս
լռելյայն ցանկից։ Արժեքներն այս գործակալի համար վերասահմանում են գլոբալ
AIHUMMER_SUBAGENT_MAX_DEPTH և AIHUMMER_SUBAGENT_TIMEOUT_SEC-ը։
max_iterations (1–256) — ֆունկցիաների կանչի ցիկլի քայլերի սահման
բազմաթիվ պատվիրակումներով ստուգված սցենարների համար։
app — միայն AiHummer հավելվածի համար. reasoning_effort,
service_tier և կարճ պատասխանի ռեժիմ direct_completion (auto կամ
alwaysmax_tokens-ով մինչև 4096 և timeout_ms-ով մինչև 60 000)։
interaction — նիստերի հետ աշխատելու հստակ թույլտվություններ.
user_ids, session_agent_ids, spawn_agent_ids, տեսանելիություն
session_visibility (self, agent կամ granted), session_send, դուստր
կանչերի գործիքային արգելքներ (child_tool_deny, child_leaf_tool_deny) և
elevated_telegram_user_ids — user_ids-ի ենթաբազմություն, որին թույլատրված
է հստակ բարձրացված code_exec գործարկում պահանջել (հաստատումները չեն
շրջանցվում)։ Փոխանորդ նշաններ և ամբողջ վարձակալի համար թույլտվություններ
չկան։
Ադմինիստրատիվ API
Անվանիքներ և նրանց կառուցվածքային պրոֆիլները կառավարվում են վարչական API-ով, որը պաշտպանված է OIDC-ով և անցնում է աուդիտ:
Մեկ **գործակալ** այս այն միավորն է, որը AiHummer-ը տեղադրում է զրույցից առաջ։ Յուրաքանչյուր գործակալ ունի կերպար, սեփական մոդել, կառուցվածքային հարցում և հմտությունների հավաքածու, և նրա մեջ կատարվող յուրաքանչյուր փոփոխություն վերսիավորվում է։ Գործակալները կառավարվում են վեբ ադմինիստրատորական ինտերֆեյսի միջոցով և միջոցով վարչական API-ի շրջանակներում `/v1/admin/agents/*`.
Այս էջում քննարկվում է, թե ինչից է բաղկացած գործակալը, ինչպես են հավաքվում կառուցվածքային «G3» հարցումները և ինչպես կարող է գործակալը անվտանգորեն խմբագրել իր սեփական պրոֆիլը։
## Գործակալների ռեեստր
Ռեեստրը ֆոլիս կատալոգ է գործակալների՝ CRUD հնարավորությամբ: Յուրաքանչյուր գործակալի համար դուք որոշում եք անձը, կերպարը, մոդելը, որի վրա նա աշխատում է, և հմտությունները, որոնցից նա կարող է օգտվել: Հաշվի առնելով, որ դարպասը բազմաբնակիչ է, գործակալները գտնվում են աշխատանքային տարածքի ներսում և ամրացված են, ինչպես ցանկացած այլ վարձատուի տվյալներ։
- **Անձ** — ձայնն ու գործակալության վարքը, փոխանցված աստվարջիք
Cache-ընկալող շերտ համակարգային հարցման համար:
- **Մոդել ըստ գործակալի** — յուրաքանչյուր գործակալ կարող է հաստատել իր սեփական մոդելը և պրովայդերին, այնպես որ
ժամանակակից գործակալը և դրոշակակիր գործակալը կարող են գոյակցել մեկ աշխատանքային տարածքում։
- **Հմտություններ** — Յուրաքանչյուր գործակալի հմտություններն ու ընդհանուր հմտությունները ցուցադրվում են «Հմտություններ» բլոկում
հուշում; դրանք նկարագրում են հնարավորությունները, ոչ թե քաշերը։
> [!NOTE]
> Մոդելը գործակալի վրա անկախ է երթուղեգրմանից։ Երթուղեգրումն ըստ մոդելի մակարդակի (հեշտ /
> համաչափ / բարդ) ընտրում է մի մոդելի դասակարգում նշված շրջանի համար, մինչդեռ յուրաքանչյուր գործակցի դեպքում
> մոդելը գործը կատարող գործակալին պատկանող նախնական կարգավորումն է։ Տե՛ս
> [Ուղղորդում](/hy/v1.0/concepts/routing).
## Տարբերակներ, հետընթաց և քլոնավորում
Անհրաժեշտ յուրաքանչյուր փոփոխություն գործակալում գրանցվում է որպես **տարբերակ**. Դա գրում է գործակալության կազմաձևը ստուգելի և հակադարձելի. դուք կարող եք դիտարկել, թե ինչ է փոխվել, **հետ հետ հրել** ավելի վաղ թողարկված տարբերակին, կամ **կլոն** գործակալ օգտագործման նրա որպես նորի ելակետ։ Վարկածի և պրոֆիլի ռեսուրսները գտնվում են `/v1/admin/agents/*` (պրոֆիլ, բաժիններ, հմտություններ, տարբերակներ).
> [!TIP]
> Ստեղծեք գործող գործակալի պատճեն մեծ կերպարի կամ հրահանգի վերաշարադրմամբ առաջի։ Եթե նոր
> եթե ուղղությունը արդարացվի, բնօրինակն դեռ մեկ հետքայլով է ուշանում։
## Կառուցված հարցում «G3»
Մի պատահական տեքստով մեկ հուշիչ համակարգի փոխարեն, AiHummer-ը օգտագործում է **ագենտի կառուցվածքային պրոֆիլ** (ներքին «G3»). Անձնությունը հանդիսանում է **բաժանված դաշտերի** փոխարենը, որ թաքնված լինի արձակ նամակում, իսկ հրահանգի մնացած մասը կառուցված է անվանվածներից **բաժիններ** գումարած մեկ **պաշտոնում ներմուծում** բլոկ։ Օրկեստրատորը նրանց վերածում է բազմաշերտ համակարգային հարցման, պահպանելով կայուն մասերը (համաձայնություն, կերպար, բաժիններ) պահվող պրեֆիքսում և ավելացնում վերջին փոփոխվող տվյալները։
Այս կառուցվածքը թույլ է տալիս հեշտությամբ խմբագրել պրոֆիլը դաշտերով, պարզապես համեմատել տարբերակները և կանխատեսված կերպով ցուցադրել — չկա թաքնված «աղիացված» հուշումների զանգված։
```text
G3 profile
├── identity fields (decomposed: name, role, ...)
├── sections (named, ordered prompt blocks)
└── onboarding (first-run guidance)
```
## Ինքնամասային խմբագրումը անցման շեղակի հետ
Ազատ է գրվում գործակալին **խմբագրել ձեր սեփական պրոֆիլը** ինքնաստեղծման գործիքների օգտագործումը՝ օրինակ, բաժինը ճշգրտելու կամ դրա ինդուկցիոն գործընթացը թարմացնելու համար։ Սա դիտամտորեն պաշտպանված է՝
- Ինքնուրույն զեկուցումները անցնում են միջոցով **հաստատման փրկակետ**: առաջարկվող փոփոխությունը գրանցվել է և
պետք է հաստատվի մարդու կողմից, նախքան այն ուժի մեջ մտնելը։ Մերժված փոփոխությունը երբեք չի
կիրառվել է։
- Այլացումը արձանագրվում է որպես նոր **տարբերակ**, այդ պատճառով ինքնուրույն խմբագրումը նույնպես ենթարկվում է ստուգմանը
և վերադարձնելի, ինչպես ցանկացած ձեռքի խմբագրում։
> [!WARNING]
> Ինքնակառավարումը — դա հզոր գործիք է։ Պահեք այն եկամուտների դարպասներից դուրս, որպեսզի գործակալը չկարողանա
> լուռ կերպով վերակազմակերպում է իր սեփական ինքնությունը: Տեսեք առաջարկվող ինքնախմբագրումները այնպես, ինչպես դուք
> դիտել ցանկացած բարվոք փոփոխություն։
### Էլ.հաղորդագրությունների գաղտնաբառերը ուղարկվում են պահոց
Եթե գործակալի կազմը ներառում է փոստային հաշվի տվյալներ (որպես `mail` գործիք), գաղտնաբառը գրանցվում է **ակնային ծածկագրված տվյալների պահոց**, չեն պահպանվում պրոֆիլում և չեն երևում նամականուշում։ Գաղտնիքները երբեք չեն մտնում մոդելի կոնտեքստում։
## Կատարման քաղաքականություն. համատեքստ, նիստեր և դուստր գործակալներ
1.3 տարբերակից գործակալն ունի **կատարման քաղաքականություն** — `runtime_policy`
դաշտը ադմին API-ում (`/v1/admin/agents` ստեղծելիս և թարմացնելիս)։ Սա խիստ
վավերացվող JSON օբյեկտ է `"version": 1`-ով. դատարկ `{}`-ը վերադարձնում է
լռելյայն արժեքները, թարմացնելիս դաշտի բացթողումը պահպանում է նախորդ
քաղաքականությունը, իսկ անհայտ դաշտերն ու թույլատրելի սահմաններից դուրս
արժեքները մերժվում են։ Քաղաքականությունը գործիքներ չի տալիս և իրավունքներ չի
ընդլայնում — այն սահմանում է միայն բյուջեներ և ժամկետներ։ Գործակալի կլոնը և
նրան հերթի փոխանցումը ժառանգում են այն։
- **`context`** — պատմության բյուջե. `max_tokens`, `reserve_tokens` և
`history_share` որոշում են, թե որքան պատմություն է մտնում հարցման մեջ.
`max_history_messages`-ը սահմանափակում է հաղորդագրությունների պատուհանը,
`bootstrap_max_chars`-ը՝ պրոֆիլի բլոկի չափը։ Երբ համատեքստը հստակ նշված է,
հին հաղորդագրությունները մասերով սեղմվում են ամփոփման մեջ՝ նախքան ընթացիկ
հարցման կազմումը։
- **`pruning`** — հնացած գործիքային արդյունքների մաքրում. ըստ ժամկետի
(`ttl_seconds`), վերջին պատասխանների պաշտպանությամբ
(`keep_last_assistants`), մեղմ կրճատում (`soft_trim_ratio`, `head_chars`,
`tail_chars`) և ամբողջական փոխարինում `placeholder` տեքստով
`hard_clear_ratio`-ն գերազանցելիս։ Օգտատիրոջ տեքստը, պատկերները և բազայի
ամբողջական պատմությունը չեն շոշափվում։
- **`memory_flush`** — սեղմումից առաջ գործիքներ չունեցող գործակալը գրում է
կարճ նշում նպատակների, որոշումների և անավարտ գործերի մասին
(`soft_threshold_tokens`). նույն երկխոսության վերջին երեք նշումները
խառնվում են համատեքստի մեջ որպես չստուգված տեղեկանք։
- **`session`** — երկխոսության կյանքի ցիկլ. `idle_reset_minutes`-ը դադարից
հետո սկսում է նոր համատեքստ (հում պատմությունը պահպանվում է),
`index_prune_after_days`-ը և `index_max_entries`-ը հին երկխոսությունները
հանում են լռելյայն ցանկից՝ առանց ջնջելու։ `scope` = `per-peer` (մեկ
երկխոսություն հաստատված օգտատիրոջ համար բոլոր ալիքներում) կամ
`per-channel-peer` (առանձին երկխոսություն յուրաքանչյուր ալիքի համար)։
- **`children`** — դուստր գործակալներ. `max_depth` (մինչև 4), `max_concurrent`
(մինչև 8 մեկ գործարկման ծառի համար), `max_per_parent` (մինչև 5),
`timeout_seconds` (մինչև 48 ժամ, բայց ոչ ավելի, քան ծնողը) և
`archive_after_minutes` — երբ ավարտված գործարկումները դուրս են գալիս
լռելյայն ցանկից։ Արժեքներն այս գործակալի համար վերասահմանում են գլոբալ
`AIHUMMER_SUBAGENT_MAX_DEPTH` և `AIHUMMER_SUBAGENT_TIMEOUT_SEC`-ը։
- **`max_iterations`** (1–256) — ֆունկցիաների կանչի ցիկլի քայլերի սահման
բազմաթիվ պատվիրակումներով ստուգված սցենարների համար։
- **`app`** — միայն AiHummer հավելվածի համար. `reasoning_effort`,
`service_tier` և կարճ պատասխանի ռեժիմ `direct_completion` (`auto` կամ
`always` `max_tokens`-ով մինչև 4096 և `timeout_ms`-ով մինչև 60 000)։
- **`interaction`** — նիստերի հետ աշխատելու հստակ թույլտվություններ.
`user_ids`, `session_agent_ids`, `spawn_agent_ids`, տեսանելիություն
`session_visibility` (`self`, `agent` կամ `granted`), `session_send`, դուստր
կանչերի գործիքային արգելքներ (`child_tool_deny`, `child_leaf_tool_deny`) և
`elevated_telegram_user_ids` — `user_ids`-ի ենթաբազմություն, որին թույլատրված
է հստակ բարձրացված `code_exec` գործարկում պահանջել (հաստատումները չեն
շրջանցվում)։ Փոխանորդ նշաններ և ամբողջ վարձակալի համար թույլտվություններ
չկան։
## Ադմինիստրատիվ API
Անվանիքներ և նրանց կառուցվածքային պրոֆիլները կառավարվում են վարչական API-ով, որը պաշտպանված է OIDC-ով և անցնում է աուդիտ:
| Ռեսուրս | Նպատակ |
|---|---|
| `/v1/admin/agents` | Տեղեկացույց, ստեղծում, թարմացում, գործակալի հեռացում (CRUD) |
| `/v1/admin/agents/.../profile` | G3 կառուցվածքային պրոֆիլ (հայտնության դաշտեր) |
| `/v1/admin/agents/.../sections` | Անվանված բաժինները հուշմանը |
| `/v1/admin/agents/.../skills` | Յուրաքանչյուր գործակալի հմտությունները |
| `/v1/admin/agents/.../versions` | Մակագրությունների պատմություն, հետպատահար և կլոնավորում |
## Որտեղից հետո
- Բացատրեք, թե ինչպես գործակալները կատարում են քայլը և ստեղծում օգնականներ
[Օրխեստրային կազմավորում և ենթագնացներ](/hy/v1.0/concepts/orchestration-subagents).
- Տեսեք, ինչպես զանգվածային հաղորդագրությունը հասնում է կոնկրետ գործակալի
[Ուղղորդում](/hy/v1.0/concepts/routing).
- Տվեք ձեր գործակալներին երկարաժամկետ հիշողություն
[Հիշողություն (Աայնշտեյն)](/hy/v1.0/concepts/memory-einstein).