Çoxmərhələli proseslər: model tərəfindən avtomatik orkestrasiya və dövrlərə nəzarət

1. Çoxmərhələli run nədir və “birdəfəlik” sorğudan nə ilə fərqlənir

Siz yalnız ChatGPT App və MCP tools ilə işləyəndə mənzərə kifayət qədər xətti idi: istifadəçi sorğusu gəldi → GPT bir və ya bir neçə aləti çağırmağa qərar verdi → siz istifadəçiyə cavab verdiniz. Bu, alətin içində nisbətən daha mürəkkəb işlər görsəniz belə, yenə də “bir məntiqi addım” sayıla bilər.

Agent üçün run — bu, məqsəd + addımlar silsiləsi deməkdir. Artıq “bir prompt — bir cavab” kimi düşünmür, tapşırığı agentin əvvəldən axıra qədər apardığı mini-layihə kimi qəbul edirik.

Fərqi belə təsəvvür etmək olar:

Burada vacib məqam: planlaşdırmanı tam şəkildə modelin ixtiyarına vermək məcburiyyətində deyilsiniz. Adətən hibrid alınır: ssenarinin iri fazalarını sərt şəkildə kodlaşdırırsınız (məsələn, “əvvəl tələbləri topla, sonra hədiyyələri seç, sonra kartı hazırla”), hər faza daxilində isə agentə alətlərindən kifayət qədər sərbəst istifadə etməyə icazə verirsiniz.

Kiçik analogiya

Birdəfəlik alət çağırışı — kuryeri çağırmaq kimidir: “bir sənədi götür və ofisə gətir”.

Çoxmərhələli agent run — şəxsi köməkçi kimidir: “Həmkarımın ad gününə hədiyyə hazırla: nələr xoşuna gəlir öyrən, bir neçə variant seç, çatdırılmanı yoxla və hamısını səliqəli bir prezentasiyaya yığ”. Köməkçi yolda hansı hərəkətləri görəcəyinə özü qərar verir.

Bir az sonra bu cür çoxmərhələli run-ların artıq tanış olduğunuz Apps SDK → MCP → backend yığınına necə yerləşdiyini də göstərəcəyik ki, ChatGPT və vidcet üçün agent məntiqi adi və səliqəli bir MCP-aləti kimi görünsün.

2. Model addımları özü necə planlayır: yüksəkdən baxış

Agents SDK terminlərində danışsaq, hər bir run rahatlıqla üçlük kimi təqdim oluna bilər:

1. Goal (məqsəd): agentin system/user-təlimatlarına düşən tapşırığın mətn təsviri.
2. Tools: yaxşı təsvirlər və JSON Schema ilə təqdim olunan alətlər dəsti.
3. State: addımlar tarixi və sizin kənarda saxladığınız strukturlu vəziyyət (DB, Redis, nə olur-olsun).

Sonra tanış run-dövrü işə düşür: model məqsədə və mövcud alətlərə baxır və hər addımda qərar verir:

• “Məndə kifayət qədər informasiya var — istifadəçiyə yekun nəticəni verə bilərəm”;
• və ya “Mənə X alətini bu arqumentlərlə çağırmaq lazımdır”;
• və ya “Alətin nəticəsini aldım, indi onu şərh etmək, filtrləmək, bəlkə də başqa aləti çağırmaq lazımdır”.

Psixoloji səviyyədə ideya belə görünür (xatırladıram, bu düşüncə modelidir, real API deyil):

while (!done && steps < MAX_STEPS) {
  const modelResponse = await callModel({
    system: agentPolicy,
    messages: history,
    tools,
  });

  if (modelResponse.type === "tool_call") {
    const toolResult = await callTool(modelResponse.toolName, modelResponse.args);
    history.push({ role: "tool", content: toolResult });
  } else {
    // yekun cavab
    done = true;
    return modelResponse.content;
  }

  steps++;
}

Real Agents SDK-də bu dövr artıq həyata keçirilib və kitabxananın içində “gizlədilib”. Siz agenti deklarativ təsvir edirsiniz, SDK isə yekun cavab alınana və ya addım/vaxt limitlərinə dirənənə qədər modeli və alətləri dövrə salır.

Arxitektorun vəzifəsi ondan ibarətdir ki:

• məqsədi və system-təlimatı elə formalaşdırsın ki, model məntiqli addımlar planlaşdırsın;
• mənaca üst-üstə düşməyən alətlər dəsti qursun;
• addım və vaxt məhdudiyyətləri təyin etsin;
• hansı addımların paralel ola biləcəyini əvvəlcədən düşünsün.

Məqsəd, alətlər və vəziyyət barədə təsəvvürümüz olanda növbəti sual — bu məqsədə hansı addımlarla getməkdir. Bütün addımlar eyni deyil: bəziləri ciddi şəkildə ardıcıldır, bəziləri paralelləşdirilə bilər.

3. Ardıcıllıqla və paralel addımlar

Artıq agentin run-dövrü barədə baza anlayışımız var, indi belə prosesin içində addımların ümumiyyətlə necə tiplərə bölündüyünü aydınlaşdıraq. Agent workflow-da iki böyük tip var: ardıcıl və paralel.

Ardıcıllıqla addımlar

Bu o vaxtdır ki, A addımının nəticəsi B addımı üçün kritikdir. Məsələn, bizim tədris GiftGeniusində:

1. Əvvəlcə hədiyyə alanın kim olduğunu başa düşmək lazımdır: həmkar, qohum, yaşı, maraqları.
2. Sonra search_gifts aləti ilə namizədlər dəsti seçmək.
3. Daha sonra onları büdcə və məhdudiyyətlərə görə süzmək.
4. Sonra vidcet üçün kartları səliqəli şəkildə tərtib etmək.
5. Və yalnız bundan sonra, bəlkə də checkout-a keçidi təklif etmək.

Hər növbəti addım əvvəlkinin məlumatlarından asılıdır, buna görə icra ciddi şəkildə ardıcıl olur.

Psevdo-kodda agent davranışı bunun kimi “daxili plan”a bənzəyə bilər:

1. İstifadəçidən alan şəxs və büdcə barədə suallar ver
2. Aləti çağır: search_gifts(profile, budget)
3. Aləti çağır: filter_by_constraints(gifts, constraints)
4. Yekun siyahını və təsviri formalaşdır

Model belə siyahını kod şəklində yazmır, amma onu bu cür struktura tərəf system-təlimatlar, dialoq nümunələri və alət təsvirləri ilə yönləndirə bilərik.

Paralel addımlar

Bəzən addımları müstəqil yerinə yetirmək olar. Məsələn, hədiyyə təkliflərini eyni anda üç mağazadan müqayisə etmək istəyirik:

• search_gifts_amazon
• search_gifts_etsy
• search_gifts_local_store

Agent baxımından bu üç müstəqil alət çağırışıdır və ümumi cavab vaxtını azaltmaq üçün paralel işə salına bilər.

Agents SDK-də (və ümumən müasir agent çərçivələrində) model bir addımda birdən çox çağırış təklif edirsə, alətlərin paralel çağırışlarına tez-tez daxili dəstək var. Kanonik ssenari: model cavabda belə çağırışların siyahısını təsvir edir, SDK onları eyni vaxtda çağırır, nəticələri toplayır və növbəti model addımına bir sıra tool-mesajları kimi əlavə edir.

Planlaşdırma baxımından bu belə görünür:

// Agentin addımı: model üç aləti çağırmağa qərar verdi
const calls = [
  { name: "search_gifts_amazon", args: {...} },
  { name: "search_gifts_etsy", args: {...} },
  { name: "search_gifts_local_store", args: {...} },
];

const results = await Promise.all(
  calls.map(c => callTool(c.name, c.args))
);

// Sonra bütün nəticələr növbəti model addımından əvvəl kontekstə əlavə olunur

Əgər siz JS/TS-də frontend yazmısınızsa, paralel sorğu ideyasına artıq rast gəlmisiniz: məsələn, bir neçə fetch()-i eyni anda Promise.all ilə işə salanda. İndi eyni ideya agentin run-dövrünün içində ortaya çıxır, yalnız nəyin paralel icra oluna biləcəyinə dair qərarı çox vaxt model özü verir.

4. GiftGenius üçün workflow nümunəsi: addımlar, məqsədlər və alətlər

Ardıcıllıqla addımlar bölməsində artıq intuisiya ilə GiftGenius davranışını mərhələlərə böldük. İndi isə eyni çoxmərhələli ssenarini agent workflow-u kimi formallaşdıraq: məqsədi, addımları təsvir edək və onları agentin alətləri və konfiqurasiyası ilə bağlayaq. Hələ konkret Agents SDK API-sinə bağlanmayacaq, strukturu izah edib bir az şərti TypeScript-kod əlavə edəcəyik.

Məqsəd (goal)

Məqsəd belə səslənsin:

İstifadəçiyə konkret alıcı üçün, büdcəni, səbəbləri və çatdırılma məhdudiyyətlərini nəzərə alaraq 3–5 hədiyyə variantı seçməyə kömək etmək və GiftGenius vidceti üçün hədiyyə kartlarının strukturlu siyahısını vermək.

Əsas addımlar

Minimum 4 addımdan ibarət variantı təsvir edək:

1. Alan şəxs kontekstinin dəqiqləşdirilməsi
   Məqsəd: hədiyyə kimin üçündür (yaş, cins, maraqlar, donorla münasibət), həmçinin büdcə və tədbir tarixi barədə məlumat toplamaq.
   Alətlər: bəlkə ümumiyyətlə alətsiz, sırf model ↔ istifadəçi dialoqu.
2. Hədiyyələrin axtarışı və ilkin seçimi
   Məqsəd: “xam” hədiyyə seçimi əldə etmək.
   Alətlər: search_gifts(profile, budget) — kataloqa/axtarış sisteminə gedib namizədlər siyahısını qaytaran alət.
3. Filtrləmə və çeşidləmə
   Məqsəd: uyğun olmayan variantları kənarlaşdırmaq (regiona çatdırılma yoxdur, büdcəni aşır, uyğun olmayan məhdudiyyətlər) və aidiyyətə görə sortlamaq.
   Alətlər: filter_and_score_gifts(candidates, constraints) — təmiz, idempotent alət.
4. Nəticənin vidcet üçün formatlanması
   Məqsəd: məlumatları UI üçün rahat formata salmaq: başlıq, qısa təsvir, şəkil, qiymət, CTA.
   Alətlər: format_gift_cards(gifts) — həm kod aləti (struktur generasiyası), həm də LLM-aləti (estetik mətnlər) ola bilər.

Agent konfiqurasiyasında bu necə görünə bilər

Şərti agent konstruktorumuz olsun (psevdo-kod):

import { createAgent } from "@acme/agents-sdk";
import { tools } from "./gift-tools";

export const giftAgent = createAgent({
  name: "gift-guru",
  system: `
    Sən GiftGenius agentisən, hədiyyə seçməyə kömək edirsən.
    Məqsəd: həqiqətən almaq mümkün olan 3–5 variant təklif et,
    alıcının profilini, büdcəni və çatdırılma məhdudiyyətlərini nəzərə al.
    Əvvəl vacib detallarını dəqiqləşdir, sonra axtarış və filtrləmə alətlərindən istifadə et.
    Büdcəni və əsas maraqları hələ bilmirsənsə, alətləri çağırma.
    Səndə hədiyyə kartlarının aydın siyahısı olanda işi tamamla.
  `,
  tools, // burada search_gifts, filter_and_score_gifts, format_gift_cards olacaq
  maxSteps: 12,
  timeoutMs: 15000,
});

Bir neçə detallara diqqət yetirin:

• System-təlimatda agentə açıq şəkildə öncə detalları dəqiqləşdirməsini, sonra axtarış alətlərindən istifadə etməsini deyirik. Bu, modelin kontekst çox bulanıq ikən alətləri çağırmağa başlaması riskini azaldır.
• maxSteps limitini qoymuşuq ki, agent sonsuz dövrə düşməsin.
• timeoutMs ona görə lazımdır ki, bütün run istifadəçinin yarım ömrünü almasın.

5. Model tərəfindən avtomatik orkestrasiya: nəyi modelə buraxmaq, nəyi sərt sabitləmək

Agent — modelin sərbəstliyi ilə sizin qoyduğunuz sərt struktur arasında balansdır.

Modele həddən artıq azadlıq versəniz və sərhədlər qoymasanız, “yaradıcı qarışıqlıq” alacaqsınız: lazımsız alət çağırışları, təkrarlanan addımlar, anlaşılmaz dövrlər. Əksinə, hər şeyi backend-də sonlu avtomat kimi sərt kodlaşdırsanız, model ağıllı icraçı yox, mətn dekoratoruna çevrilər.

Adətən modelə nələri etibar edirlər

GiftGenius və oxşar ssenarilərdə modelə etibar etmək məntiqlidir:

• istifadəçiyə veriləcək sualların formalaşdırılması (maraqları necə dəqiqləşdirmək, büdcəni necə nəzakətlə soruşmaq);
• məlumatın axtarışa başlamaq üçün kifayət edib-etməməsinə qərar vermək;
• eyni faza daxilində konkret hansı alətlərin istifadə olunacağını seçmək (məs., bir neçə mağaza axtarış alətindən hansını seçmək);
• təsvirlərin, izahların, müqayisələrin mətnlərini yaratmaq.

Nələri daha yaxşı sərt şəkildə sabitləmək lazımdır

Bununla yanaşı, əvvəlcədən aşağıdakıları sabitləmək məqsədəuyğundur:

• ssenarinin iri fazaları (“Məlumatın toplanması” → “Axtarış” → “Filtrləmə” → “Formatlama” → “Final”);
• addım və vaxt limitləri;
• agentin “dayanmalı” olduğu şərtlər və istifadəçiyə açıq şəkildə problemin izah edilməsi (məs., büdcə 5 dollar, amma sabaha çatdırılmalı bahalı elektron cihaz lazımdır);
• alətlərin idempotentlik siyasəti və retry strategiyaları.

Hibrid nümunə: fazalar state kimi, detalları model həll edir

Agentin state-də phase sahəsini saxlaya bilərsiniz; dəyərlər "collect_profile" | "search" | "filter" | "format" | "done" ola bilər. O zaman sizin backend (və ya Agents SDK-nın özüdürsə, istifadəçi state machine dəstəyi ilə) hansı fazada hansı alətlərin əlçatan olduğunu idarə edəcək.

Psevdo-kod:

type Phase = "collect_profile" | "search" | "filter" | "format" | "done";

interface GiftAgentState {
  phase: Phase;
  profile?: UserProfile;
  candidates?: GiftCandidate[];
  finalGifts?: GiftCard[];
}

Agent üçün system-təlimata fazaların qısa təsvirini daxil edə, siz isə koddakı mövcud fazaya uyğun olaraq modelə göstərilən alətlər siyahısını məhdudlaşdıra bilərsiniz. Bu, tool gating nümunəsidir; workflow mövzusunda bunu daha ətraflı müzakirə edirik.

6. Sonsuz dövrlərə və faydasız təkrarlara nəzarət

Agentə nəzarətsiz run-dövrü versəniz, gec-tez o, deadline ərəfəsindəki tələbə kimi davranmağa başlayacaq: işi təhvil verməmək üçün sonsuz “dəqiqləşdirmə və yenidən yazma”. Bizim vəzifəmiz — onun ilişib qalmamasını təmin etməkdir.

Üç tipik sonsuz dövr mənbəyi var:

1. Model cavabına əmin deyil və alətə eyni sorğunu cüzi dəyişikliklərlə təkrar-təkrar göndərir.
2. Alət stabil olaraq xəta və ya boş nəticə qaytarır, agent isə israrla “yenidən cəhd edir”.
3. Agent iki alət arasında ilişib qalır: gah birini, gah o birini çağırır, amma yekun cavaba yaxınlaşmır.

Addım limiti (maxSteps)

Ən sadə və mütləq mexanizm — addım sayını məhdudlaşdırmaqdır. Agents SDK-nın əksər reallaşdırmalarında maxSteps-i run işə salarkən və ya agent konfiqurasiyasında göstərə bilərsiniz. Limitə çatılan kimi SDK run-u xüsusi statusla tamamlayır (məsələn, aborted_by_max_steps). Sonra bunu istifadəçiyə necə göstərməyə siz qərar verirsiniz.

GiftGenius-də adekvat hədiyyə seçimi ~10 addıma sığa bilər (bir neçə dəqiqləşdirmə, bir neçə axtarış, filtrləmə, formatlama). Məsələn, ehtiyatla 12–15 addım qoyuruq və limitə çatanda vəziyyəti səliqə ilə emal edirik:

const run = await giftAgent.run({
  input: userGoal,
  maxSteps: 12, // defoltu yenidən təyin edirik
});

if (run.status === "max_steps_exceeded") {
  // İstifadəçiyə dürüst mesaj göstəririk
}

Vaxt limiti (timeout)

Bəzən problem addım sayında yox, ümumi müddətdədir. Alətlər ləng ola bilər, şəbəkə — qeyri-sabit. Ona görə timeoutMs-i həm ayrı-ayrı alət çağırışları, həm də bütün run səviyyəsində göstərmək faydalıdır.

Məsələn, belə qərar verə bilərsiniz ki:

• hər bir xarici API çağırışı (tərəfdaşda hədiyyə axtarışı) 3–5 saniyədən çox çəkməməlidir;
• bütün hədiyyəseçmə run-u 15 saniyəyə sığmalıdır.

Timeout işə düşərsə, run-u səliqə ilə tamamlayırsınız, bəlkə də istifadəçiyə qismən nəticə və “mənbələrin bir hissəsi vaxtında cavab vermədi” kimi dürüst izahat göstərirsiniz.

Təkrarlamaların aşkarlanması

Daha inkişaf etmiş (amma faydalı) pattern — eyni arqumentlərlə təkrarlanan alət çağırışlarını aşkarlamaqdır. Görürsünüzsə ki, agent ardıcıl üç dəfə search_gifts(profile, budget)-i eyni parametrlərlə çağırıb, deməli o, ilişib qalıb.

State-ə (toolName, argsHash) açarı üzrə çağırış sayğacı əlavə edə bilərsiniz və bu sayğac həddi keçəndə ya:

• run-u dayandırıb istifadəçiyə anlaşılan xəta qaytarın;
• ya da modelə əlavə təlimat verin: “bu aləti eyni parametrlərlə artıq üç dəfə çağırmısan, strategiyanı dəyişməyə çalış və ya istifadəçidən soruş”.

Psevdo-kod:

function shouldAbortToolCall(toolName: string, args: unknown, state: GiftAgentState) {
  const key = `${toolName}:${hashArgs(args)}`;
  const count = state.toolCallCounts[key] ?? 0;

  if (count >= 3) return true;

  state.toolCallCounts[key] = count + 1;
  return false;
}

Burada hashArgs — arqumentlərin istənilən deterministik seriyalaşdırma funksiyasıdır (məsələn, açarları sıraya salan JSON.stringify).

7. Tapşırığın tamamlanması üçün aydın meyarlar

“Oyuncaqlıq” agentlə production agent arasındakı əsas fərqlərdən biri — aydın tamamlanma meyarlarının olmasıdır. Onlar yoxdursa, model ya işi çox tez bitirə bilər (“budur hansısa hədiyyələr, davamını özünüz edin”), ya da əksinə, nəticəni sonsuz yaxşılaşdırmağa cəhd edər.

GiftGenius-də sadə qayda qoya bilərik:

• Agent onda tamamlanır ki, 3-dən 5-ə qədər hədiyyə olsun və sahələr doldurulsun: id, title, shortDescription, price, imageUrl, purchaseUrl, və bunlar büdcə və çatdırılma üzrə filtrlərdən keçmiş olsun.
• Əgər maksimum N axtarış və filtrləmə cəhdindən sonra uyğun hədiyyələrin sayı 3-dən azdırsa, agent istifadəçiyə dürüstcə bildirir ki, münasib heç nə tapılmadı və büdcəni genişləndirməyi və ya məhdudiyyətləri yumşaltmağı təklif edir.

Bu meyarları birbaşa agentin system-təlimatında və/və ya run-dan sonrakı nəticə yoxlamasında kodlaşdıra bilərsiniz.

Run-dan sonra nəticənin yoxlanmasına nümunə:

if (run.status === "completed") {
  const gifts = run.output.gifts; // tutalım, agentimiz strukturlu JSON qaytarır

  if (!gifts || gifts.length < 3) {
    // Agent "tamamlandı", amma nəticə zəifdir — belə edə bilərsiniz:
    // 1) dürüst izahat göstərin,
    // 2) istifadəçiyə şərtləri dəyişməyi təklif edin.
  } else {
    // Hər şey qaydasındadır — hədiyyə vidcetini göstəririk
  }
}

Modeldən biznes uğurunu sehrli şəkildə “anlamağı” gözləməyin. Tərtibatçı kimi “qənaətbəxş” nəticənin şərtlərini açıq şəkildə formalaşdırmalı və onları yoxlamalısınız.

8. Orkestrasiya məhz harada reallaşdırılır: agent, backend, vidcet

Əvvəllər demişdik ki, orkestrasiya müxtəlif səviyyələrdə yaşaya bilər: agentdə, backend-də, vidcetdə.

Çoxmərhələli proseslər baxımından məntiq təxminən belədir.

Agent (Agents SDK) “fikir” workflow-una cavabdehdir:

• məqsədi addımlara necə bölmək;
• hansı alətləri hansı ardıcıllıqla çağırmaq;
• istifadəçiyə hansı əlavə sualları vermək.

Backend adətən təmin edir:

• alətlərin reallaşdırılması (axtarış, filtr, commerce və s.);
• state və checkpointlərin saxlanması;
• sərt biznes-məhdudiyyətləri (büdcə tavanları, hüquqlar, region əlçatanlığı).

Vidcet (Apps SDK) idarə edir:

• proqresin göstərilməsi (stepper, progress bar, “4-dən 2-ci addım”);
• giriş formaları;
• UX xırdalıqları, məsələn, bütün məlumatlar tamamlanmayıbsa düymələrin söndürülməsi.

Yaxşı praktika — belə düşünməkdir: agent alətlərin işini və dialoqu “rejissor” kimi idarə edir, UI-vidcet isə istifadəçi təcrübəsini “rejissor” kimi qurur. Onlar strukturlu məlumatlar vasitəsilə anlaşırlar (ToolOutput, agent run output).

9. Mini-kod nümunəsi: GiftGenius çoxmərhələli agentini MCP-alətindən işə salmaq

İndi, mühazirənin əvvəlində vəd etdiyimiz kimi, yeni konsepsiyanı artıq tanış olduğunuz Apps SDK → MCP → backend yığını ilə bağlayaq və kiçik bir nümunə göstərək: MCP-aləti agent run-unu necə çağıra bilər.

Təsəvvür edin ki, sizin app/mcp/route.ts faylında run_gift_workflow adlı alət var; o:

• istifadəçinin mətn sorğusunu (onun məqsədini) qəbul edir;
• giftAgent agentini işə salır;
• vidcet üçün strukturlu nəticə qaytarır.

Kod sadələşdirilib və şərtidir, amma qoşulma barədə təsəvvür yaradır:

// app/mcp/route.ts
import { server } from "@modelcontextprotocol/sdk/server";
import { z } from "zod";
import { giftAgent } from "@/agents/giftAgent";

server.registerTool(
  "run_gift_workflow",
  {
    title: "Hədiyyələri seç",
    description: "Çoxmərhələli hədiyyəseçmə agentini işə salır",
    inputSchema: {
      userGoal: z
        .string()
        .describe("İstifadəçinin tapşırığı, məsələn: həmkara $50-ə qədər hədiyyə istəyirəm"),
    },
  },
  async ({ userGoal }) => { 		
    const run = await giftAgent.run({		// burada agenti 12 addım və 15 s timeout ilə işə salırıq
      input: userGoal,
      maxSteps: 12,
      timeoutMs: 15000,
    });

    return {
      status: run.status,
      gifts: run.output?.gifts ?? [],
      debug: run.debugInfo, // sonra silmək olar
    };
  }
);

Sonra ChatGPT App bu MCP-aləti digər alətlər kimi çağıra bilər, sizin GiftGenius vidcetiniz isə gifts əsasında UI quracaq. Siz “kapağın altında” çoxmərhələli workflow əldə edirsiniz, halbuki xaricdən ChatGPT üçün hər şey bir səliqəli alət kimi görünür.

10. Çoxmərhələli prosesləri layihələndirərkən tipik səhvlər

Səhv № 1: “Qoy model özü başa düşsün, mən sadəcə bütün alətləri verəcəyəm”.
Agentə mənaca üst-üstə düşən onlarla alət, aydın system-təlimat və fazalar olmadan əlçatan olduqda model çaş-baş qalır: eyni şeyi müxtəlif yollarla çağırır, sorğuları dublikatlaşdırır, dövrlərə düşür. Dizayna vaxt ayırmaq daha yaxşıdır: ssenarini fazalara bölmək, hər fazada alətlər siyahısını məhdudlaşdırmaq və strategiyanı system-prompta açıq yazmaq.

Səhv № 2: Addım və vaxt limitlərinin olmaması.
Əgər maxSteps və timeout qoymasanız, production-da tezliklə resurs yeyən, istifadəçiyə isə heç nə göstərməyən “sərgərdan” run-lar əldə edəcəksiniz. Limitlər “opsiya” deyil, əsas gigiyenadır. Eyni zamanda, limit aşılan halları mənalı şəkildə emal etmək vacibdir, sadəcə səssiz 500 atmaq yox.

Səhv № 3: Aydın tamamlanma meyarlarının olmaması.
Model run-u ona “bəsdir” kimi görünəndə bitirir, amma onun “bəsdir” anlayışı biznes tələblərindən uzaq ola bilər. Uğur meyarlarını (neçə hədiyyə, hansı sahələr, hansı filtrlərdən keçib) formalizləşdirməsəniz və yoxlamasanız, UX qeyri-sabit olacaq: bu gün beş əla variant, sabah bir “orta” və üç dublikat.

Səhv № 4: Təkrarlanan alət çağırışlarının izlənməməsi.
Agent belə bir pattern-də ilişə bilər: “xəta aldım → sorğunu 2 söz dəyişdim → eyni aləti yenə çağırdım”. Əgər (toolName, args) üzrə təkrarlanan çağırışları izləməsəniz, bu dövrlər loglara baxana qədər görünməz qalacaq. Sadə sayğaclar və arqument hash-ləri çox kömək edir.

Səhv № 5: Orkestrasiyanın biznes-məntiq reallaşdırması ilə bir alətdə qarışdırılması.
Bəzən bütün workflow-u bir MCP-alətin və ya agent funksiyasının içinə “gizlətməyə” çalışırlar: həm axtarış, həm filtr, həm formatlama, həm də qərarvermə. Nəticədə agentin mənası itir: model prosesə addım-addım nəzarət edə bilmir, şəffaflıq və ssenari hissələrini yenidən istifadə imkanı itir. Ayrı mərhələləri müstəqil alətlərə çıxarmaq və agentə onların kompozisiyasını vermək daha yaxşıdır.

Səhv № 6: State və checkpointlərlə əlaqənin olmaması.
State və checkpoint saxlanmadan çoxmərhələli proses kövrək monoliti xatırladır: ortada nəsə düşsə, istifadəçi hər şeyi sıfırdan başlamalı olur. Bu, xüsusən, istifadəçi addımlar arasında geri-qayıdanda və ya zamandan sonra qayıdanda kritikdir. State store istifadə edin, fazanı, profili, namizədləri saxlayın və agentə lazım olan yerdən davam etməyə imkan verin.

Səhv № 7: UX qatının nəzərdən qaçırılması.
Bəzən tərtibatçılar agentin daxili workflow-u ilə həddən artıq məşğul olur və unudurlar ki, istifadəçi yalnız vidceti və çatdakı mesajları görür. UI-da aydın proqres, “hədiyyələri axtarırıq…”, “variantları filtrləyirik…” kimi statuslar yoxdursa, istifadəçi App-ın “ilişdiyini” və ya “heç nə etmədiyini” düşünəcək, agent arxa planda mürəkkəb prosesi orkestrasiya etsə belə. Çoxmərhələli run-u planlayanda, onun interfeysə necə əks olunacağını da dərhal düşünün.