აგენტები და პირები — AiHummer დოკუმენტაცია

ერთი აგენტი ეს ერთეულია, რომელსაც AiHummer ათავსებს საუბრის წინ. ყოველ აგენტს აქვს პერსონა, საკუთარი მოდელი, სტრუქტურირებული მოთხოვნა და უნარების ნაკრები, და ყოველ ცვლილებას მასში ვერსიებად ინახავს. აგენტები მართავს ვებ-მოწესრიგების ინტერფეისით და ადმინისტრაციული API–ის მეშვეობით ფარგლებში /v1/admin/agents/*.

ამ გვერდზე განხილულია, რით შედგება აგენტი, როგორ შეიკრიბება სტრუქტურირებული მოთხოვნა „G3“ და როგორ შეუძლია აგენტს უსაფრთხოდ დახვეწოს თავისი საკუთარი პროფილი.

აგენტების რეესტრი

რეგისტრი არის აგენტების სრული კატალოგი CRUD შესაძლებლობით. თითოეული აგენტისთვის თქვენ განსაზღვრავთ პიროვნებას, პერსონას, მოდელს, რომელზეც იგი მუშაობს, და უნარები, რომელსაც იგი შეუძლია გამოიყენოს. რადგან პორტალი მრავალმომხმარებლიანი გახლავთ, აგენტები მდებარეობენ სამუშაო სივრცეში და აიზოლირებენ, როგორც ნებისმიერი სხვა ქირავნებლის მონაცემს.

პერსონა — აგენტის ხმა და ქცევა, გადაცემული სტაბილში, კეშ-სამედეგი სისტემური მოთხოვნის სერვისი.
აგენტის მოდელი — თითოეულ აგენტს შეუძლია საკუთარი მოდელისა და პროვაიდერის დამყარება, ასე რომ საფასო აგენტი და ფლაგმანური აგენტი შეუძლიათ ერთ სამუშაო სივრცეში თანაარსებობა.
მობალოვებები — თითოეული აგენტის უნარები და საერთო უნარები აღინიშნება ბლოკში „უნარები“ კინძვა; ისინი აღწერენ შესაძლებლობებს, არა წონებს.

[!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`	ვერსიების ისტორია, უკან დაბრუნება და კლონირება

სად შემდეგ?

გესმეთ, როგორ ასრულებენ აგენტები ნაბიჯს და ქმნიან დამხმარეებს ორკესტრაცია და სუბაგენტები.
ნახეთ, როგორ აღწევს შემომავალი შეტყობინება კონკრეტულ აგენტს რუტირება.
მოუცეთ თქვენს აგენტებს ხანგრძლივი მეხსიერება მეხსიერება (აინშტაინი).