Agentlərlə tanışlıq: rollar, run‑dövrü, determinlik, idempotentlik

1. Agent nədir və niyə sizə lazımdır

Agentlər ChatGPT App-in məcburi hissəsi deyil: LLM-agentlərdən istifadə etmədən istədiyiniz qədər əla tətbiqlər yarada bilərsiniz. Bununla belə, bu barədə sizə danışmaq üçün üç ciddi səbəbim var.

Agentlər — tətbiqinizin backendinə intellekt əlavə etməyin əla yoludur. Hədiyyələrin ağıllı seçimi, istifadəçinin mətn istəklərinin analizi. Axtarış, analiz, emal və yekunlaşdırmanın mürəkkəb ssenariləri — bunların hamısını LLM-agentlərin köməyi ilə çox asan etmək olur.

ChatGPT öz AgentsSDK-sını TS və Python üçün buraxıb. Çox uğurludur. Agentlərin orkestrasiyası qutudan hazır gəlir. Bir mürəkkəb vəzifə üzərində təkcə bir agent yox, bütöv bir komanda işləyə bilər. Bu, çox perspektivli istiqamətdir.

Və bir də tədris məqsədi var. ChatGPT mcp-tools-u elə çağırır ki, LLM-agentlər də öz tools-larını həmin qaydada çağırırlar. LLM-agentlərin necə işlədiyini anlayan kimi, məsələn, tətbiqdə model tərəfdə vəziyyət maşını hazırlamağın yolunu da başa düşəcəksiniz. Habelə, AgentsSDK-ni öyrənmək gələcəkdə ChatGPT SDK-nın necə işləyəcəyi barədə təsəvvür verir.

O halda başlayaq.

LLM-agent nədir

Əgər ChatGPT App — ChatGPT daxilində servisinizin gözəl və rahat “front”udur, MCP‑server isə alətlər və biznes-məntiq ilə “motor”dursa, agent — oxuyan, anlayan və bacaran ağıllı dispetçer kimidir:

• məqsədi oxumaq;
• hansı alətləri hansı ardıcıllıqla çağıracağını özü müəyyənləşdirmək;
• zərurət olduqda əlavə məlumat soruşmaq;
• xəta olduqda addımları təkrarlamaq;
• aşkarlanmış, aydın yekun nəticəyə çatmaq.

Agents SDK-nın rəsmi sənədlərinə yaxın təriflə, agent — proqramdır. LLM və alətlər toplusuna çıxışı olmaqla, o, məqsədə çatmaq üçün addımları müstəqil planlaya və onları tool‑call vasitəsilə yerinə yetirə bilir.

Artıq əlində olanlarla paralel aparsaq:

• Adi ChatGPT App-də ChatGPT modeli sizin MCP‑alətlərinizə çağırışları birbaşa orkestrasiya edir.
• Backend-də LLM-agent də eyni cür tapşırığın təsvirinə, alət dəstinə malikdir və hansı tools-u nə qədər addımda çağıracağını, nə vaxt dayanacağını və hansı nəticəni qaytaracağını özü müəyyənləşdirir.

Bizim GiftGenius kontekstində bu belə görünə bilər:

• Agentsiz tətbiq: model birbaşa searchGifts-i, sonra filterByBudget-i, sonra getDetails-i çağırır — hər dəfə yenidən “fikirləşərək”;
• Agentli tətbiq: ChatGPT mcp‑tool çağırır, backend isə agentə tapşırıq verir: “Belə bir profil üçün top‑5 hədiyyə tap”. Agent bir neçə addım edir: əlavə məlumat toplayır, müxtəlif search‑alətlər çağırır, filtrasiya və çeşidləmə edir, yekun kartlar yaradır və artıq hazır strukturlaşdırılmış cavabı qaytarır.

ChatGPT və backend-də LLM-agent — direktor və işçi kimidir. ChatGPT-nin azadlığı daha çoxdur: o, istifadəçi ilə ünsiyyət qurur və hansı strateji məsələləri başlatmağı (mcp tools çağırmağı) qərar verir. LLM-agent isə yalnız backend-də işləyir, istifadəçi ilə ünsiyyət qurmur, amma o da “düşünür” və öz tool-larını çağırır. Bir növ “minimal” ChatGPT.

2. Agent nədən ibarətdir: LLM, təlimatlar, alətlər və vəziyyət

Agent haqqında bir neçə səviyyə kimi düşünmək rahatdır.

Birincisi, “kapotun altında” yenə LLM var. Bu, GPT‑5.1 və ya Agents SDK-nın istifadə etdiyi başqa bir model ola bilər. O, mətn yaradır, addımları planlayır, alətləri seçir — qısası, orkestrasiya kontekstinizdə “düşünmə” ilə məşğul olur.

İkincisi, modelin üzərində təlimatlar gedir. Bu, agentin rolunu, sərhədlərini, üslubunu, alətlərin istifadə qaydalarını müəyyən edən sistem promplarıdır. Siz bunu artıq ChatGPT App üçün etmişdiniz, indi isə bu ayrıca agentə tətbiq olunur.

Üçüncüsü, agent alətləri toplusu var. Bunlar ola bilər:

• TypeScript funksiyaları (klassik function calling);
• HTTP/REST‑alətləri;
• agentin ChatGPT App ilə eyni backend-ə gedə bilməsi üçün MCP‑tools üzərinə “wrapper”lər;
• OpenAI-nin öz “hosted” daxili alətləri (məsələn, web‑search, əgər qoşursunuzsa).

Və nəhayət, vəziyyət və addımlarla iş qaydaları var: sessiya vəziyyəti (session state) necə saxlanılır, ara nəticələr necə yadda qalır, dövrlər necə məhdudlaşdırılır. Bu barədə yaddaş və vəziyyət mövzusundakı növbəti mühazirədə daha dərindən danışacağıq, amma artıq indi yadda saxlamaq faydalıdır ki, agent “birdəfəlik sorğu” deyil, gedişatın saxlanıldığı potensial uzun prosesdir.

Bunu TypeScript‑developeri gözü ilə baxsanız, təxmini belə bir obyekt alınar (Agents SDK TS-ə yaxın psevdokod):

const giftAgent = new Agent({
  model: "gpt-5.1",
  systemPrompt: giftAgentPrompt,
  tools: { searchGifts, filterGifts, checkoutDraft },
  // burada da — yaddaş parametrləri, addım limitləri və s.
});

İndi dəqiq API-lərə varmayaq, obraz önəmlidir: model, təlimatlar, alətlər və davranış parametrləri bir yerdə.

3. Mesaj rolları: system / user / assistant / tool agent dünyasında

Siz artıq Chat Completions-dan system, user, assistant və tool rollarını tanıyırsınız. Agents SDK-də onlar qalır, amma bir az daha tətbiqi məna qazanır.

system rolu agentin şəxsiyyətini və missiyasını təyin edir. Məsələn, GiftGenius agenti üçün bu belə ola bilər: “Sən — hədiyyə seçimi agentisən. Tapşırığın — minimum addımla alıcının profili və büdcəsi əsasında 3–7 uyğun hədiyyə variantı seçmək, sonra isə widget üçün strukturlaşdırılmış JSON hazırlamaq”. Elə burada məhdudiyyətləri də yazırsınız: nələri etməməlidir (məsələn, ayrıca addım olmadan real alış etməmək) və alətlərlə necə işləməlidir.

Agent kontekstində user rolu — mütləq “canlı insan” deyil. Çox vaxt bu, agent üçün “tapşırıqdır”: sizin App, servis və ya başqa bir agent tərəfindən formalaşdırılmış məqsəd. Məsələn, ChatGPT App agenti user mesajı ilə çağıra bilər: “Həmkar‑developerlər üçün 5 hədiyyə ideyası seç, büdcə 50 $, səbəb — ad günü”.

assistant rolu — agentin içində “danışan” modelin dedikləridir. Burada həm ara düşüncələr və planlar, həm də yekun cavab ola bilər. Sizin vəzifəniz — bu mesajların faydalı olması üçün sistem promplarını elə qurmaq və lazım gələrsə, onları loglamaqdır.

tool rolu (və ya konkret SDK-də onun analoqları) alətlər çağırışlarının nəticələrini təsvir edir: “MCP vasitəsilə 50 məhsul tapıldı”, “API time‑out xətası qaytardı”, “DB istifadəçi profilini verdi”. Bu mesajlar assistant mesajları ilə birlikdə agentin run‑dövrü tarixçəsini təşkil edir.

Bunu kiçik bir cədvəldə cəmləmək rahatdır:

system

user

assistant

tool

Bu quruluş vacibdir, çünki məhz onun əsasında run‑dövrü qurulur — bugünkü mühazirənin baş qəhrəmanı.

4. LLM backendinizdə funksiyaları necə çağırır

“Su–cavab” rejiminə öyrəşəndə, sanki LLM sadə sxemlə işləyir: mətn gəldi → model mətnlə cavabladı. Əslində “kapotun altında” hər şey bir az daha mürəkkəbdir və function calling məhz buna görə işləyir.

Model bir sual almır, o, mesajlar siyahısı — dialoq tarixçəsi alır. Orada artıq əvvəlki bütün replikalar durur: sistem təlimatları (“sən kimsən və nə olar/olmaz”), sizin mesajlarınız, modelin keçmiş cavabları, alətlərin nəticələri. Hər addımda model bütün bu lenti (chat‑log) görür və qərar verir: “Sonuna hansı növbəti mesaj əlavə olunmalıdır?”.

Bu əsas fikirdir: LLM həmişə bir addım edir — tarixçənin sonuna növbəti mesajı əlavə edir. O, “keçmişi dəyişmir” və köhnə mesajları redaktə etmir, sadəcə siyahını davam etdirir. Siz sual yazırsınız, model cavab verir. Siz ikinci sualı əlavə edirsiniz, model yenə cavab verir, amma dialoq tarixçəsini (bütün mesajları) nəzərə alaraq.

Function calling də eyni prinsipdə qurulub. “Funksiyanı birbaşa işə salmaq” əvəzinə, model belə edir:

• mövcud alətlər/tools siyahısını və onların təsvirlərini dialoq tarixçəsi ilə birlikdə görür;
• qərar verir: “İndi sadəcə mətnlə cavab verməkdənsə, əvvəlcə filan aləti çağırmaq daha məntiqlidir”;
• və növbəti mesaj kimi tarixçəyə adi mətn deyil, xüsusi formatda belə bir mesaj əlavə edir: “filan tool-u belə arqumentlərlə çağırmaq istəyirəm”.

Sonra artıq model yox, sizin backend tarixçənin sonundakı bu yeni mesajı oxuyur, bunun funksiya çağırışı tələbi olduğunu anlayır və müvafiq aləti çağırır. Daha sonra tarixçəyə daha bir mesaj — alətin nəticəsini əlavə edir və yenidən modelə bütün mesajlar siyahısını göndərir. Model yenə bütün lentə baxır və növbəti addımı yazır: ya başqa bir çağırış, ya da artıq insan-oxunaqlı yekun cavab.

Yəni:

• adi sual‑cavab üçün: “növbəti mesaj” = mətn cavabı;
• function calling üçün: “növbəti mesaj” = funksiya çağırmaq təlimatı və ya funksiyadan sonra cavab.

Heç bir ayrıca “funksiyanı çağır” sehrli əmri yoxdur — bu, modelin zəncirin sonuna əlavə etdiyi növbəti mesajın xüsusi növüdür.

Model backend funksiyalarınızı publik API vasitəsilə çağırmır. O, sadəcə “chatdə yazır” ki, müəyyən parametrlərlə funksiyanı çağırmaq istəyir. Artıq backendiniz yerli funksiyanı çağırır və onun cavabını chata əlavə edir. Və hər şey yenidən başlayır.

5. Agentin run‑dövrü: o necə addım‑addım “düşünür”

Əslində LLM‑agent — serverinizdə agent run‑dövrünü çağıran obyekt/alqoritmdir — bu, “sual → düşün → bəlkə əməl et → yenə düşün → … → yekun cavab” genişləndirilmiş dövrüdür. OpenAI sənədlərində buna bəzən agent loop və ya ReAct‑pattern (Reason + Act + Observe) deyilir.

Konseptual səviyyədə bir agent run-u belə görünür:

1. Agent girişi alır: sistem təlimatları, tapşırıq (user‑mesajı), bəlkə də — cari vəziyyət.
2. Model addım generasiya edir: ya mətn cavabı, ya da plan və bir və ya bir neçə aləti çağırma qərarı.
3. Model tool‑call seçibsə, agent müvafiq aləti kodda çağırır (bu, yerli funksiya, MCP‑tool, HTTP sorğusu, DB çıxışı və s. ola bilər).
4. Alətlərin nəticələri tool mesajları kimi tarixçəyə əlavə olunur.
5. Dövr yeni kontekstlə modelə qayıdır. Model qərar verir: planlamanı davam etdirmək, başqa alət çağırmaq, yoxsa yekun cavabla tapşırığı tamamlamalı.
6. Model aşkar və ya dayandırma şərtlərinə görə run-u tamamladıqda, agent çağıran tərəfə yekun nəticəni qaytarır.

Kiçik diaqram bunu belə göstərir:

flowchart TD
    A[Run başlanğıcı: məqsəd + system] --> B[Modeli çağırmaq]
    B --> C{Model mətnlə
cavab vermək
istəyir, yoxsa tool?}
    C --> D["Mətn cavabı
(assistant)"]
    D --> E{Tapşırıq tamamdır?}
    E -->|Bəli| F[Yekun nəticə]
    E -->|Xeyr| B

    C --> G["Tool-call
(çağırış təsviri)"]
    G --> H[Funksiya / MCP / HTTP çağırışı]
    H --> I["Tool nəticəsi
(tool message)"]
    I --> B

Bunu sadələşdirilmiş TypeScript psevdokoduna çevirsək (real API-dən uzaq, amma məntiqcə düzgün), təxminən belə alınar:

async function runAgent(goal: string) {
  let context = buildInitialContext(goal);

  while (!isFinished(context)) {
    const decision = await callLLM(context); // agentin addımı

    if (decision.type === "tool_call") {		// funksiyanı çağırmaq?
      const toolResult = await callTool(decision.tool, decision.args);	// yerli funksiyanı çağırırıq
      context = appendToolResult(context, toolResult);		// nəticəni siyahının sonuna əlavə edirik
    } else {
      context = appendAssistantMessage(context, decision.message); 
    }

    enforceLimits(context); // addım/vaxt/dövr limiti
  }

  return extractFinalResult(context);
}

Agents SDK bu rutin işlərin böyük hissəsini öz üzərinə götürür: tarixçə saxlanması, tool‑call marşallaşdırılması, təkrar (retry) məntiqi və s. Sizə qalan — konfiqurasiyanı qurmaq və alətlərin özünü implement etməkdir.

Run və step

İki anlayışı fərqləndirmək vacibdir:

• run — hər hansı bir məqsəd üçün agentin bir işə salınması: “bu hal üçün hədiyyələr seç”;
• step — run‑dövrünün bir addımı: modelin konkret çağırışı ki, bu, mətn cavabına və ya tool‑call-a gətirib çıxara bilər.

Monitorinqdə məhz bir run daxilində çoxlu addımlar görəcəksiniz, təhlükəsizlik və xərc limitləri isə tez-tez ya “run-a”, ya da “addıma” qoyulur.

İndi agentin bir run daxilində necə yaşadığını və run‑dövrü ilə addımladığını anladıqdan sonra, gəlin harada həqiqətən bunlara ehtiyac olduğunu, harada isə sadə tools-un kifayət etdiyini baxaq.

5. GiftGenius-də agent harada lazımdır, harada isə artıqdı

Hər şeyə agent yazmağa atılmazdan əvvəl, özünüzə səmimi sual verin: “Burada doğrudan da agent lazımdır?”.

Agent üçün yaxşı ssenari — çoxaddımlı, budaqlanmaları, təkrarları və yalnız promplarla saxlamağa rahat olmayan məntiqi olan vəzifədir.

GiftGenius-də belə bir vəzifə “ağıllı hədiyyə seçimi ustası” ola bilər ki, o:

• önəmli detalları dəqiqləşdirə bilir (alqıcının cinsi, hobbilər, yaxınlıq səviyyəsi);
• bir neçə məhsul mənbəyinə müraciət edə bilir (MCP‑tools vasitəsilə müxtəlif vendorlar);
• nəticələri filtrləyir və reytinqləyir;
• mənbə xətalarında təkrar cəhd edir və ya alternativ yolla gedir;
• sadəcə mətn siyahısı yox, izahlarla və product feed-dən SKU keçidləri ilə strukturlaşdırılmış namizədlər siyahısı qaytarır.

Burada agent “orkestrator” kimi həqiqətən faydalı olacaq, xüsusilə sonra bunu səs/Realtime ssenarisi və ya mürəkkəb kommersiya (ACP) ilə tamamlamalısınızsa.

Amma sadə getGiftDetails(giftId) çağırışı üçün agent lazım deyil: birbaşa ChatGPT-dən çağırılan adi MCP‑tool tam olaraq bu işi görür. Eyni şey “bir addımlıq” ssenarilər üçün də keçərlidir, məsələn “məhsul kartının mətninə əsasən bu hədiyyənin təsvirini de”.

Ümumi sağlam yanaşma belədir: ssenarini “bir normal tool” kimi təsvir etmək mümkündürsə — yəqin ki, agentə ehtiyac yoxdur. Əgər artıq çoxaddımlı workflow-u yoxlamalar və təkrar cəhdlərlə aydın şəkildə yazmağa başlayırsınızsa, böyük ehtimalla agent sizi sevindirəcək.

6. Determinlik: agentin davranışını necə proqnozlaşdırılan etmək

LLM‑agentlər dünyasında determinlik — mürəkkəb mövzudur. Nəzəri olaraq, eyni giriş və eyni ayarlarda eyni əməl planı və eyni tool‑call ardıcıllığını almaq istəyirsiniz. Praktikada model stokastik qalır, amma proqnozlaşdırıla bilməni idarə etmək üçün bir neçə qolu var.

Birincisi, klassika: temperatur və digər generasiya parametrləri. Temperatur nə qədər aşağı olsa, model bir o qədər az “kreativ” və bir o qədər “itaətkar” olur. Hədiyyə seçimi agenti üçün yəqin ki, sıfır olmayan, amma çox da yüksək olmayan azadlıq səviyyəsi istərdiniz, əks halda model hər dəfə eyni aləti çağırmağın yeni üsulunu uyduracaq.

İkincisi, dəqiq sistem təlimatları. “Sən müxtəlif alətləri çağıra və istədiyini edə bilərsən” kimi yayğın davranış təsviri etsəniz, agent bəzən API-lər arasında tullanmasına, bəzən də “havadan” cavab verməyə başlaya bilər. Çox daha yaxşıdır ki, konkret yazasınız: nə zaman aləti çağırmaq, hansı parametrlər uyğundur, xətaları necə şərh etmək və hansı hallarda tapşırığı bitirmək lazımdır.

Məsələn, GiftGenius agenti üçün sistem prompta belə bir parça daxil edilə bilər:

Əgər sənin alıcının tam profili (yaş, cins, səbəb, təxmini büdcə) yoxdursa,
əvvəlcə user-facing kanalla dəqiqləşdirici suallar ver və cavabları gözlə.
Bundan sonra search_gifts alətini dolu profillə çağır.
Məhsulları uydurma, həmişə alətlərin nəticələrinə əsaslan.

Belə göstərişlər qərarların variasiyasını azaldır və davranışı daha determin edir.

Üçüncüsü, alətlərin öz dizaynı. Əgər sizdə “təxminən eyni şeyi” edən üç alət varsa, model qaçılmaz olaraq bəzən birini, bəzən digərini seçəcək. Alətləri kəskin, üst‑üstə düşməyən məsuliyyət zonaları ilə layihələndirmək və bunu təsvirlərində yazmaq daha yaxşıdır.

Nəhayət, guardrails istifadə edə bilərsiniz — agentin hərəkətlərini və modelin nəticələrini yoxlayan qaydalar və sxemlər. Agents SDK-də çıxış məlumatlarının strukturuna nəzarət də daxil olmaqla, daxili yoxlamalar və məhdudiyyətlər dəstəyi var. Model sxem üzrə olmayan bir şey yaratmağa cəhd etsə, onu yumşaq şəkildə düzəldə və ya addımı yenidən təkrarlaya bilərsiniz.

Mini‑nümunə: nəticə formatını sabitləyirik

Tutaq ki, agentin həmişə gifts sahəsi olan JSON qaytarmasını istəyirsiniz və içəridə id, title və score olan obyektlər olmalıdır. Siz aşağıdakıları edə bilərsiniz:

• bu sxemi agent səviyyəsində təsvir edin;
• yekun çıxışın həmin sxemə uyğun olması gərəkdiyini göstərin;
• pozuntu halında — addımı təkrarlayın və ya təhlükəsiz xəta qaytarın.

Psevdokod:

const giftResultSchema = z.object({
  gifts: z.array(z.object({
    id: z.string(),
    title: z.string(),
    score: z.number().min(0).max(1),
  }))
});

// Agentin konfiqində
const agent = new Agent({
  /* ... */
  outputSchema: giftResultSchema,
});

Model qəribə bir şey qaytarmağa cəhd etdikdə, runner validasiya xətası barədə xəbər verəcək və siz ya modeli yenidən soruşa, ya da hadisəni loglaya biləcəksiniz.

7. Idempotentlik: nə üçün agent sizin API-ni iki dəfə çağıra bilər

Əgər determinlik — “eyni girişdə eyni plan” haqqındadırsa, idempotentlik — təkrarların təhlükəsizliyi haqqındadır. Agentlər kontekstində bu iki səbəbə görə kritikdir.

Birincisi, sizdə daha bir retry səviyyəsi yaranır: təkcə HTTP‑klientlər və load‑balancer‑lər yox, elə agentin özü də xəta və ya natamam nəticə alanda alət çağırışını təkrarlamağa qərar verə bilər. İkincisi, real prodakşn ssenarilərində webhooks, növbələr, stream kanalları əlavə olunur — və eyni məntiqi addımı təsadüfən bir neçə dəfə emal edə bilərsiniz.

Siz artıq MCP‑tools səviyyəsində idempotentliyi müzakirə etmisiniz: ikiqat ödəniş etməmək, eyni sifarişi iki dəfə yaratmamaq, sorğularda idempotency key-lərdən istifadə etmək. İndi eyni şey agentin çoxaddımlı təbiəti ilə vurulur.

Təsəvvür edək ki, GiftGenius-da seçilmiş hədiyyələr siyahısına görə ACP/Stripe-də draft‑checkout yaradan create_checkout_session aləti var. Agent şəbəkə xətasına görə bu çağırışı təkrarlamağa qərar versə, iki ayrı sifariş və ikiqat pul çıxılması əsla istəməzsiniz.

Deməli, gərək:

• hər məntiqi əməl üçün xarici idempotency key düşünəsiniz (məsələn, runId + stepIndex və ya açıq şəkildə generasiya edilmiş checkoutDraftId);
• onu backend/ACP‑endpoint-ə ötürəsiniz;
• backend tərəfində bu açarla artıq emal edib‑etmədiyinizi yoxlayasınız və təkrar icra yerinə saxlanmış nəticəni qaytaramalısınız.

Psevdonümunə TypeScript-də:

async function createCheckoutDraft(runId: string, payload: DraftPayload) {
  const key = `gift-checkout-${runId}`;

  const existing = await findDraftByKey(key);
  if (existing) return existing;

  const draft = await stripe.checkout.sessions.create({
    /* ... */,
    idempotencyKey: key, // yaxud öz qatınız (layer) üzərindən
  });

  await saveDraftWithKey(key, draft);
  return draft;
}

Beləliklə, agent hər hansı səbəbdən eyni runId ilə bu aləti iki dəfə çağırsa belə, kodunuz idempotent qalacaq: eyni məntiqi addım → eyni faktiki nəticə.

“Əvvəl yoxlama, sonra əməl”

Idempotentliyin ikinci geniş yayılmış pattern-i — əvvəl vəziyyəti yoxlamaq, sonra əməl etməkdir. Məsələn, sifariş yaratmamışdan əvvəl, həmin clientReferenceId ilə və ya eyni parametrlər toplusu ilə artıq sifarişin olub‑olmadığını yoxlamaq. Bu, xüsusilə uzun workflow-larda rahatdır, burada agent əvvəlki addımda nəsə etdiyini “unudur”.

Safe‑mode/Fake‑mode

İnkişaf mərhələsində təhlükəli alətlər üçün “təhlükəsiz rejim”in olması faydalıdır: real əməl yerinə onlar yalnız nə ediləcəyini loglayır və psevdonəticə qaytarırlar. Agentlər üçün bu, run‑dövrünü döyüş mühitində sınaqdan keçirmək üçün rahat üsuldur — pula və ya məlumatlara risk etmədən.

8. Mini‑praktika: GiftGenius agentini insan dilində təsvir edirik

Artıq run‑dövrü, determinlik və alətlərin idempotentliyi barədə danışdıq. Gəlin bir dəqiqə koddan ayrılıb bütün bunların canlı ssenaridə necə birləşdiyini yoxlayaq.

İndi xırda bir məşq etmək faydalıdır — kağızda (və ya ağlınızda), kodsuz.

Təsəvvür edin ki, sadə bir agent təsvir edirsiniz:

• system

  : sən — hədiyyə seçimi üzrə köməkçisən; həmişə vacib detalları dəqiqləşdirirsən, məhsulları uydurmursan, yalnız alətlərin nəticələrindən istifadə edirsən.

• user

  : həmkarım üçün 50 $‑dək hədiyyə istəyirəm.

Sözlərlə, belə bir agentin hansı addımları etməli olduğunu təsvir edin.

Tipik ssenari belə görünə bilər.

1. Əvvəlcə agent məlumatın yetərli olub‑olmadığını yoxlayır. Yetərli deyilsə, dəqiqləşdirici suallar verir: həmkar təxminən nə işlə məşğuldur (dizayner, developer, menecer), hər hansı tabu varmı (alkoqol, zarafat hədiyyələri), çatdırılma baxımından məhdudiyyətlər varmı. Cavablar ya session state-ə, ya da alət çağırışının parametrlərinə düşür.
2. Sonra agent doldurulmuş profillə search_gifts alətini çağırır: “developer həmkar, büdcə 50, kateqoriya — qadcetlər və ofis”. Alət qiymətlər, kateqoriyalar və məhsul ID-ləri ilə namizədlər siyahısı qaytarır.
3. Daha sonra agent, əgər bəlli olubsa ki, bəzi məhsullar lazım olan regiona çatdırılmır, filter_gifts_by_constraints adlı əlavə aləti çağıra və ya promplarında əl ilə filtrləmə edə bilər. Bundan sonra uyğunluq və dəyərə görə variantları çeşidləyir, bəlkə də öz şərhlərini əlavə edir (“əgər həmkar qəhvəni sevirsə uyğundur”, “remote üçün yaxşı seçim”).
4. Nəhayət, agent ChatGPT App üçün yekun strukturlaşdırılmış cavab hazırlayır: 5–7 hədiyyə siyahısı, qısa təsvirlər, istifadə ilə bağlı ipucları və Checkout keçidləri (və ya növbəti addım — draft‑checkout yaradılması) ilə.

Burada tool‑call-lar harada lazımdır? Aydındır ki, məhsulların axtarışı və filtrasiyasında, əlçatanlığın yoxlanmasında və draft‑checkout yaradılmasında. Hansı addımlar idempotent olmalıdır? İlk növbədə sifarişlər və pulla bağlı bütün əməliyyatlar — draft‑checkout yaradılması, ola bilsin ki, DB-yə tarixçənin yazılması.

9. Agentlərlə ilk addımlarda tipik səhvlər

Səhv №1: agent “məhdudiyyətsiz ikinci ChatGPT” kimi.
Bəzən modelə başqa bir prompt verib buna “agent” demək istəyirsiniz. Nəticədə çox mətn generasiya edən, alətləri xaotik şəkildə çağıran və zəif idarə olunan bir şey alınır. Bunun qarşısını almaq üçün system-də agentin rolunu dəqiq təsvir etmək, alətlər siyahısını məhdudlaşdırmaq və ona konkret missiyalı orkestrator kimi yanaşmaq vacibdir, “ikinci mətn generasiya kainatı” kimi yox.

Səhv №2: alətlərdə idempotentliyin olmaması.
Tərtibatçılar tez-tez köhnə HTTP‑handler‑lərini “olduğu kimi” agentə daşıyırlar, indi runner-in çağırışları avtomatik təkrarlaya biləcəyini nəzərə almadan. Ödəniş və sifarişlərdə bu, çox xoşagəlməz nəticələrə gətirə bilər. Doğru yanaşma — alətləri elə layihələndirməkdir ki, eyni məntiqi açarla təkrar çağırış təkrar əmələ səbəb olmasın.

Səhv №3: modelin çox kreativ ayarları.
Yüksək temperatur tost və şeir uydurmaq üçün əladır, amma çoxaddımlı prosesləri etibarlı orkestrasiya etməli agent üçün bu, proqnozlaşdırılmayan davranış yoludur: model hər dəfə müxtəlif alətlər seçəcək, fərqli planlar yaradacaq və bəzən ümumiyyətlə tools olduğunu “unudacaq”. Agentlərə “xidmət” obyektləri kimi yanaşmaq və onları daha sərt rejimdə saxlamaq məsləhətdir.

Səhv №4: “hər şey üçün” alət.
Bəzən execute_any_sql və ya do_anything_with_orders kimi universal tool yaratmaq və onu agentin ixtiyarına vermək istəyirsiniz. LLM‑kreativliklə birlikdə bu, demək olar ki, zəmanətli təhlükəsizlik riskidir. Tam səlahiyyətli “ilahi” bir alət əvəzinə, səlahiyyət və müqavilələri (contracts) dəqiq olan bir neçə dar ixtisaslı alət daha yaxşıdır.

Səhv №5: run-un açıq yekun meyarlarının olmaması.
Agentə nə vaxt dayanmalı olduğunu izah etməsəniz, o, sonsuz və ya yarı‑sonsuz dövrlərə düşə bilər: nəticələri bir də yoxlamaq, istifadəçidən bir də soruşmaq, eyni xətada aləti bir də çağırmaq. Bu, çox vaxt yalnız yük altında özünü göstərir, hansısa asılılıq qeyri‑stabil olanda. Doğru yol — addım sayına, run vaxtına və eyni xətada təkrar sayına limitlər qoymaq, həmçinin system-də agentin “səmimi şəkildə təslim olmalı” olduğunu yazmaqdır — məntiqli seçimlər tükənəndə.

Səhv №6: agentin vəziyyətində hər şeyi saxlamaq.
Agents SDK session state ilə işi asanlaşdırdığına görə ora hər şeyi yığmaq cazibəsi yaranır: böyük sənədlər, emal olunmamış loglar, həssas məlumatlar. Bu, konteksti şişirdir, dəyəri artırır və təhlükəsizlik riskləri yaradır. Agentin vəziyyəti yalnız işin davamı üçün həqiqətən lazım olanı saxlamalıdır; qalanı — DB-də, loglarda və digər qatlarda, məxfilik nəzərə alınmaqla.

Səhv №7: sadə MCP‑tool kifayət edərkən agentdən istifadə cəhdi.
Bəzən tərtibatçılar sadəcə bir funksiyanı çağırıb nəticə qaytarmaq lazım olanda belə agentdən başlayırlar. Bu, gərəksiz mürəkkəblik əlavə edir: run‑dövrü, vəziyyət, əlavə loglar və potensial nasazlıq nöqtələri yaranır. Əgər ssenari çətin workflow olmadan bir tool‑call-a sığırsa, onu elə belə saxlamaq daha yaxşıdır və agenti yalnız real çoxaddımlılıq yarananda qoşmaq lazımdır.