Агенты і персоны — AiHummer Дакументацыя

Адзін агент гэта адзінка, якую AiHummer ставіць перад размовай. Кожны агент мае сваю асобу, уласную мадэль, структураваны падказак і набор навыкаў, а кожная змена ў яе версіруецца. Агентамі кіруюць з вэб-інтэрфейсу адміністратара і праз адміністрацыйны API па /v1/admin/agents/*.

Гэтая старонка апісвае, з чаго складаецца агент, як збіраецца структураваны запыт “G3” і як агент можа бяспечна рэдагаваць свой уласны профіль.

Рэгістр агентаў

Рэгістр з’яўляецца поўным CRUD-каталогам агентаў. Для кожнага агента вызначаецца яго ідэнтычнасць, персона, мадэль, на якой ён працуе, і навыкі, якія можа выкарыстоўваць. Паколькі шлюз падтрымлівае колькасць карыстальнікаў, агенты знаходзяцца ў рабочай прасторы і ізаляваныя, як і любыя іншыя дадзеныя арандатара.

Асоба — голас і паводзіны агента, перанесеныя на стабільную, кэш-аптымізаваны пласт сістэмнага падказкі
Мадэль на агента — кожны агент можа замацаваць у сябе ўласную мадэль і пастаўшчыка, так што a Дэшывы агент і галоўны агент могуць суіснаваць у адным працоўным асяроддзі.
Навыкі — навыкі, якія характэрныя для канкрэтнага агента або агульныя, ператвараюць блок «Навыкі» ў падказка; яны апісваюць магчымасці, а не вагу.

[!NOTE] Мадэль на агента незалежная ад маршрутызацыі. Маршрутызацыя ўзроўню мадэлі (простая / стандартны / складанны) выбірае клас мадэлі для ходу, у той час як кожны агент мадэль з’яўляецца стандартнай па змаўчанні для агента. Глядзі Маршрутызацыя.

Версіі, адкат і клон

Кожная значная змена агента зафіксавана як версіяГэта робіць канфігурацыю агента правяраемай і адкатвальнай: вы можаце праглядзець, што змянілася, адкат да ранейшай версіі, або клон агент выкарыстоўвае яго як адпраўную кропку для новага. Рэсурсы версій і профіляў знаходзяцца пад /v1/admin/agents/* (профіль, раздзелы, навыкі, версіі)

[!TIP] Кланіруйце працоўнага агента перад вялікай асобай або перапісваннем падказкі. Калі новы калі кірунак не спраўдзіцца, арыгінал усё яшчэ ў адным адкатным кроку.

Структураваны запыт “G3”

Замест аднаго сістэмнага запыту ў выглядзе свабоднага тэксту, AiHummer выкарыстоўвае структураваны профіль агента (унутрана “G3”). Ідэнтычнасць разлажаны на палі але не пахавана ў прозе, а астатняя частка падказкі пабудавана на імёнах сакцыі плюс адзін ўвядзенне ў пасаду блок. Аркестратар пераўтварае іх у шматслаёвую сістэмную падказку, захоўваючы стабільныя часткі (ідэнтычнасць, персону, раздзелы) у кэшуючымя прэфіксе і дадаючы нестабільныя даныя ў канцы.

Структура робіць прафіль лёгка рэдагуемым па палях, лёгка параўноўваць версіі і прадказальна адлюстроўвацца — няма схаванага набору падказак.

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`	Гісторыя версій, адкат і кланаванне

Куды далей

Зразумейце, як агенты праводзяць ход і выклікаюць памагатых Аркестрацыя і суб-агенты.
Паглядзіце, як уваходнае паведамленне даходзіць да канкрэтнага агента ў Маршрутызацыя.
Дайце сваім агентам доўгатэрміновую памяць з Памяць (Эйнштэйн).