Արհեստական բանականության ոլորտում գրեթե ամեն շաբաթ հայտնվում է նոր մոդել, agent framework, coding assistant կամ ավտոմատացման գործիք։ Յուրաքանչյուր նոր արտադրանք ներկայացվում է որպես մի բան, որը փոխելու է ծրագրավորման ամբողջ ընթացքը։

Այս արագ փոփոխությունների պատճառով հեշտ է կենտրոնանալ գործիքների վրա և բաց թողնել դրանց հիմքում ընկած գաղափարները։

Իրականում գործիքները փոխվում են շատ ավելի արագ, քան հիմնական ինժեներական սկզբունքները։ Մի համակարգում որոշ հնարավորություններ անվանում են skills, մյուսում՝ rules, workflows, tools կամ agent instructions, բայց հաճախ դրանք լուծում են նույն խնդիրը։

Ուստի ավելի օգտակար է հասկանալ ոչ թե միայն կոնկրետ գործիքները, այլ դրանց աշխատանքի հիմքում գտնվող գաղափարները։

Այս հոդվածում կդիտարկենք AI agent-ների ինժեներիայի 30 կարևոր հասկացություն՝ agent loop-ից և context management-ից մինչև multi-agent համակարգեր, անվտանգություն, tracing և metrics։


Ի՞նչ է agentic engineering-ը

Agentic engineering-ը AI համակարգերի նախագծման մոտեցում է, որտեղ լեզվային մոդելը ոչ միայն պատասխանում է հարցին, այլ կարողանում է՝

  • հասկանալ նպատակը,

  • ընտրել հաջորդ քայլը,

  • օգտագործել արտաքին գործիքներ,

  • ստուգել ստացված արդյունքը,

  • ուղղել սեփական գործողությունները,

  • շարունակել աշխատանքը մինչև ավարտի պայմանը կատարվի։

Սովորական chatbot-ի աշխատանքը հաճախ այսպիսին է․

Հարց → Պատասխան

Agent-ի աշխատանքն ավելի շատ նման է այս հոսքին․

Նպատակ
  ↓
Հաջորդ քայլի ընտրություն
  ↓
Գործիքի օգտագործում
  ↓
Արդյունքի ստուգում
  ↓
Նոր քայլի ընտրություն
  ↓
Ավարտ

Agent-ի օգտակարությունը հենց այս կրկնվող գործընթացի մեջ է։


I. Agent-ների աշխատանքի հիմքերը

1. AI agent

AI agent-ը սովորաբար լեզվային մոդել է, որը մեկ պատասխանով չի ավարտում աշխատանքը։

Այն ստանում է նպատակ, հետո հերթականությամբ որոշում է, թե ինչ գործողություններ պետք է կատարի։ Յուրաքանչյուր նոր քայլ կախված է նախորդ գործողության արդյունքից։

Օրինակ՝ ծրագրավորման agent-ին կարող ենք տալ հետևյալ խնդիրը․

Ուղղիր չանցնող թեստը։

Agent-ը կարող է՝

  1. գործարկել թեստը,

  2. կարդալ սխալի հաղորդագրությունը,

  3. բացել համապատասխան ֆայլը,

  4. փոփոխել կոդը,

  5. կրկին գործարկել թեստը,

  6. շարունակել այնքան ժամանակ, մինչև թեստն անցնի։

Agent-ները հատկապես օգտակար են այն խնդիրների համար, որոնց ամբողջ ընթացքը նախապես հնարավոր չէ հստակ սահմանել։

Օրինակ՝

  • մեծ codebase-ում bug գտնելը,

  • թեմայի ուսումնասիրությունն ու աղբյուրների համեմատումը,

  • support ticket-ների վերլուծությունը,

  • pull request-ի review-ն,

  • infrastructure configuration-ի ստուգումը։

Սակայն agent պետք չէ օգտագործել ամեն ինչի համար։

Եթե քայլերը լիովին կանխատեսելի են, սովորական script-ը հաճախ ավելի արագ, էժան և հուսալի լուծում է։

Պարզ կանոնը հետևյալն է․

  • պարզ պատասխան ստանալու համար օգտագործեք prompt,

  • ֆիքսված քայլերի համար օգտագործեք script,

  • փոփոխվող քայլերով խնդիրների համար օգտագործեք agent։


2. Agent-ի կատարման մոդելը

Agent-ների մեծ մասն աշխատում է երեք հիմնական քայլից բաղկացած ցիկլով․

Think → Act → Observe

Think

Մոդելը ուսումնասիրում է՝

  • օգտագործողի նպատակը,

  • ընթացիկ context-ը,

  • նախկին գործողությունները,

  • հասանելի գործիքները,

  • ստացված արդյունքները։

Այնուհետև որոշում է հաջորդ քայլը։

Act

Agent-ը կատարում է գործողություն։ Սովորաբար սա tool call է։

Գործիքը կարող է՝

  • կարդալ ֆայլ,

  • կատարել shell command,

  • հարցում ուղարկել API-ին,

  • որոնել տվյալների բազայում,

  • բացել documentation,

  • օգտագործել MCP server,

  • առաջադրանք փոխանցել մեկ այլ agent-ի։

Observe

Գործիքի արդյունքը վերադարձվում է մոդելին և ավելացվում ընթացիկ context-ին։

Այժմ agent-ն ունի նոր տեղեկություն և կարող է ընտրել հաջորդ քայլը։

Think → Act → Observe → Think → Act → Observe

Այս մոտեցումը հաճախ անվանում են նաև ReAct կամ agent loop։

Կարևոր է հասկանալ, որ սովորաբար մոդելը ինքնուրույն չի կատարում հրամանները։ Մոդելի շուրջ գոյություն ունի controller կամ agent harness, որը՝

  • ստանում է tool call-ը,

  • ստուգում է այն,

  • կիրառում է permission-ները,

  • կատարում է գործողությունը,

  • արդյունքը վերադարձնում մոդելին։


3. Agent state

Agent state-ը նկարագրում է, թե agent-ն ինչ գիտի տվյալ պահին։

Այն հիմնականում բաղկացած է երկու մասից։

Context window

Context window-ը մոդելի ընթացիկ աշխատանքային հիշողությունն է։

Այն կարող է ներառել՝

  • system prompt-ը,

  • օգտագործողի հաղորդագրությունները,

  • project instruction-ները,

  • նախկին tool call-երը,

  • tool call-երի արդյունքները,

  • բացված ֆայլերի պարունակությունը։

Մոդելը կարող է աշխատել միայն այն տեղեկատվության հետ, որը տվյալ պահին հասանելի է context-ում։

Context-ից դուրս գտնվող state

Մնացած տվյալները կարող են պահպանվել՝

  • ֆայլերում,

  • Git repository-ում,

  • տվյալների բազայում,

  • memory համակարգում,

  • object storage-ում,

  • արտաքին API-ներում,

  • documentation-ում։

Agent-ը չի «իմանում» այդ տվյալների մասին, մինչև դրանք չբերի իր ընթացիկ context։

Սա կարևոր տարբերություն է․

Տվյալին հասանելիություն ունենալը դեռ չի նշանակում, որ agent-ը տվյալ պահին օգտագործում է այդ տվյալը։

Լավ agent architecture-ի կարևոր խնդիրներից մեկն է որոշել՝

  • ինչ պահել context-ում,

  • ինչ պահել դրանից դուրս,

  • երբ ներբեռնել անհրաժեշտ տվյալները,

  • երբ հեռացնել այլևս ոչ անհրաժեշտ տեղեկատվությունը։


4. Agent-ների տարածված կառուցվածքները

Մի քանի agent օգտագործելիս անհրաժեշտ է սահմանել, թե ինչպես են դրանք համագործակցելու։

Planner / Executor

Այս մոդելում մի agent-ը կազմում է պլանը, իսկ մյուսը կատարում է այն։

Օրինակ՝ planner-ը կարող է feature-ի իրականացումը բաժանել հետևյալ քայլերի․

  1. փոփոխել database schema-ն,

  2. ավելացնել API endpoint,

  3. ավելացնել validation,

  4. թարմացնել frontend-ը,

  5. գրել թեստեր,

  6. թարմացնել documentation-ը։

Executor-ը հերթականությամբ կատարում է այդ քայլերը։

Այս կառուցվածքը օգտակար է երկար և բարդ խնդիրների համար, որտեղ agent-ը չպետք է անմիջապես սկսի կոդ գրել։

Router / Specialist

Router agent-ը ուսումնասիրում է խնդիրը և այն փոխանցում համապատասխան մասնագետին։

Օրինակ՝ համակարգում կարող են լինել՝

  • security reviewer,

  • test writer,

  • documentation writer,

  • debugging specialist,

  • database specialist։

Յուրաքանչյուր specialist ունի փոքր prompt և սահմանափակ toolset, ինչի շնորհիվ նրա աշխատանքը դառնում է ավելի կանխատեսելի։

Map / Reduce

Մեծ խնդիրը բաժանվում է փոքր մասերի, որոնք մշակվում են զուգահեռ։

Օրինակ՝ մեծ pull request-ի դեպքում՝

  • մի agent-ը ստուգում է backend ֆայլերը,

  • մյուսը՝ frontend-ը,

  • երրորդը՝ թեստերը,

  • չորրորդը՝ security խնդիրները։

Վերջում aggregator agent-ը միավորում է արդյունքները մեկ ընդհանուր review-ի մեջ։

Multi-agent համակարգերի հաջողությունը մեծապես կախված է handoff-ից՝ մի agent-ից մյուսին փոխանցվող տեղեկատվությունից։

Շատ քիչ context-ի դեպքում specialist-ը չի հասկանա խնդիրը։ Չափազանց շատ context-ի դեպքում այն կարող է կորցնել կենտրոնացումը։


II. Agent-ի կարգավորման շերտը

5. Agent configuration ֆայլեր

Agent-ը սովորաբար սկսում է system prompt-ից, բայց system prompt-ը չի ճանաչում ձեր նախագիծը։

Այն չգիտի՝

  • ինչ package manager եք օգտագործում,

  • ինչ naming convention ունեք,

  • ինչպես է կառուցված repository-ն,

  • ինչ command-ով են գործարկվում թեստերը,

  • ինչ architectural rule-եր կան,

  • ինչ գործողություններ են արգելված։

Այդ պատճառով նախագծերը հաճախ ունեն հատուկ instruction ֆայլ։

Օրինակ՝

  • AGENTS.md

  • CLAUDE.md

  • project rules

  • repository instructions

Պարզ օրինակ․

# Project rules

- Օգտագործիր pnpm, ոչ թե npm։
- Նոր dependency ավելացնելուց առաջ ստուգիր՝ արդյոք այն իսկապես անհրաժեշտ է։
- Մինչև աշխատանքն ավարտելը գործարկիր թեստերն ու lint-ը։
- Երբեք մի կարդա կամ մի փոխիր `.env` ֆայլը։
- Ֆայլը փոփոխելուց առաջ կարդա դրա ամբողջ պարունակությունը։
- Մի կատարիր force push դեպի main branch։

Լավ config ֆայլը պետք է լինի՝

  • կարճ,

  • կոնկրետ,

  • նախագծին համապատասխան,

  • գործնական,

  • պարբերաբար թարմացվող։

Write clean code կամ Follow best practices տեսակի ընդհանուր ցուցումները սովորաբար քիչ արժեք են տալիս։ Մոդելն արդեն գիտի այդ ընդհանուր սկզբունքները։

Config ֆայլի նպատակը agent-ի գուշակությունների քանակը նվազեցնելն է։


6. Վերօգտագործվող workflow ֆայլեր

Config ֆայլի կանոնները միշտ ակտիվ են։ Workflow ֆայլերը բեռնվում են միայն համապատասխան խնդրի դեպքում։

Օրինակ՝ կարելի է ունենալ առանձին workflow-ներ՝

  • API endpoint ավելացնելու,

  • database migration կատարելու,

  • pull request review անելու,

  • documentation թարմացնելու,

  • incident ուսումնասիրելու,

  • test-driven development իրականացնելու համար։

Workflow ֆայլը կարող է ունենալ metadata․

---
name: api-endpoint
description: Օգտագործել նոր API endpoint ավելացնելիս
applies_to:
  - src/**/*.controller.ts
  - src/**/*.service.ts
---

1. Ուսումնասիրիր առկա endpoint-ների կառուցվածքը։
2. Ավելացրու DTO և validation։
3. Իրականացրու endpoint-ը։
4. Ավելացրու authorization check։
5. Գրիր unit և integration թեստեր։
6. Թարմացրու API documentation-ը։

Տարբերությունը կարելի է հիշել այսպես․

  • config ֆայլը սահմանում է մշտական կանոնները,

  • workflow ֆայլը սահմանում է կրկնվող գործընթացը,

  • live prompt-ը նկարագրում է տվյալ պահի կոնկրետ խնդիրը։


7. Workflow framework-ներ

Workflow framework-ը agent-ին պարտադրում է հետևել հստակ աշխատանքային գործընթացի։

Առանց workflow-ի agent-ը կարող է՝

  • չափազանց շուտ սկսել կոդ գրել,

  • բաց թողնել planning-ը,

  • չգործարկել թեստերը,

  • խնդիրը համարել ավարտված առանց ստուգման,

  • սեփական վատ լուծումը ներկայացնել որպես ճիշտ։

Լավ coding workflow-ը կարող է ունենալ հետևյալ փուլերը․

Understand
   ↓
Plan
   ↓
Implement
   ↓
Test
   ↓
Review
   ↓
Improve

Այս մոտեցումը agent-ին դարձնում է ոչ միայն արագ կոդ գեներացնող գործիք, այլ կարգապահ engineering assistant։

Framework-ը չի փոխարինում developer-ին։ Վերջնական պատասխանատվությունը շարունակում է մնալ մարդու վրա։


8. Prompt caching

Agent-ի յուրաքանչյուր քայլում հաճախ կրկնվում է նույն տեղեկատվությունը՝

  • system prompt,

  • project configuration,

  • tool description-ներ,

  • workflow instruction-ներ,

  • անվտանգության կանոններ։

Այս անփոփոխ հատվածը կոչվում է stable prefix։

Prompt caching-ը թույլ է տալիս առաջին հարցման ժամանակ մշակել ամբողջ stable prefix-ը, իսկ հաջորդ հարցումներում վերօգտագործել այն։

Արդյունքում նվազում են՝

  • token usage-ը,

  • արժեքը,

  • response latency-ն։

Սակայն caching-ը չի լուծում վատ context-ի խնդիրը։

Եթե config ֆայլը երկար, հակասական կամ անպետք տեղեկատվությամբ է լցված, cache-ը միայն ավելի էժան կդարձնի այդ վատ context-ի փոխանցումը։

Այն չի դարձնի context-ը ավելի որակյալ։


9. Context rot

Context rot-ը իրավիճակ է, երբ agent-ի աշխատանքի որակը նվազում է չափազանց մեծ և աղմկոտ context-ի պատճառով։

Նույնիսկ եթե մոդելը տեխնիկապես կարող է ընդունել շատ մեծ քանակությամբ token-ներ, դա չի նշանակում, որ այն նույն ճշգրտությամբ կօգտագործի ամբողջ տեղեկատվությունը։

Context-ում կարող են կուտակվել՝

  • հին հաղորդագրություններ,

  • արդեն չկիրառվող կանոններ,

  • մեծ log-եր,

  • անհաջող փորձերի արդյունքներ,

  • կրկնվող documentation,

  • ոչ անհրաժեշտ tool output։

Այս ամենի մեջ կարևոր տեղեկատվությունը դժվար է գտնել։

Լավ կանոնը հետևյալն է․

Յուրաքանչյուր token պետք է արդարացնի context-ում իր ներկայությունը։

Երկար աշխատանքների ընթացքում օգտակար է՝

  • հին քայլերը ամփոփել,

  • log-երը պահել ֆայլերում,

  • նոր session սկսել մաքուր context-ով,

  • ներբեռնել միայն տվյալ պահին անհրաժեշտ տեղեկատվությունը։


III. Agent-ի հնարավորությունների շերտը

10. Model Context Protocol

Model Context Protocol-ը կամ MCP-ն ստանդարտ մեխանիզմ է, որով agent-ները կապվում են արտաքին համակարգերի հետ։

MCP server-ը կարող է agent-ին տրամադրել հասանելիություն՝

  • GitHub-ին,

  • տվյալների բազաներին,

  • documentation-ին,

  • file storage-ին,

  • search engine-ին,

  • ներքին API-ներին,

  • monitoring համակարգերին։

Առանց MCP-ի յուրաքանչյուր ինտեգրման համար հաճախ անհրաժեշտ է գրել առանձին glue code։

MCP-ի առավելությունը ստանդարտացված կապն է։ Սակայն այն կարող է նաև մեծացնել context-ը, քանի որ յուրաքանչյուր գործիքի schema-ն և description-ը token-ներ են զբաղեցնում։

Այս խնդիրը կարելի է մեղմել deferred loading-ով․ սկզբում agent-ը տեսնում է միայն գործիքների կարճ նկարագրությունները, իսկ ամբողջ schema-ն բեռնվում է միայն գործիքն օգտագործելու պահին։

Փոքր անհատական automation-ի համար CLI command-ը կամ script-ը երբեմն ավելի պարզ լուծում է։

Թիմային կամ կազմակերպչական միջավայրում MCP-ն կարող է ապահովել ավելի կառավարելի authentication, permissions և tool discovery։


11. Թարմ documentation-ի ներբեռնում

Լեզվային մոդելների գիտելիքները միշտ ունեն ժամանակային սահմանափակում։

Library-ն կարող է փոխվել, method-ը կարող է deprecated դառնալ, իսկ API parameter-ը՝ վերանվանվել։

Եթե agent-ը հիմնվում է միայն training data-ի վրա, այն կարող է համոզիչ ձևով առաջարկել արդեն չաշխատող լուծում։

Live documentation retrieval-ը թույլ է տալիս agent-ին աշխատանքից առաջ կարդալ՝

  • պաշտոնական documentation-ը,

  • տվյալ version-ի API reference-ը,

  • migration guide-ը,

  • repository-ի իրական կոդը,

  • թարմ օրինակները։

Սա տարբերություն է ստեղծում երկու հարցերի միջև․

Ինչպե՞ս է սովորաբար աշխատում authentication-ը։

և

Ինչպե՞ս է authentication-ը իրականացված հենց այս repository-ում։

Առաջին հարցը պահանջում է ընդհանուր գիտելիք։ Երկրորդը պահանջում է իրական codebase-ի ուսումնասիրություն։


Սովորական որոնման համակարգերը նախատեսված են մարդկանց համար։ Դրանք վերադարձնում են ամբողջական էջեր՝ menu-ներով, գովազդներով, popup-ներով և մեծ քանակությամբ ավելորդ HTML-ով։

Agent-ին հիմնականում անհրաժեշտ է՝

  • մաքրված տեքստ,

  • հիմնական հատվածները,

  • metadata,

  • աղբյուրի ամսաթիվը,

  • կառուցվածքային արդյունք։

AI-native search-ը փորձում է վերադարձնել հենց այդպիսի տեղեկատվություն։

Սա նվազեցնում է parsing-ի համար ծախսվող ժամանակը և context-ի աղմուկը։

Մարդու համար որոնումը հաճախ վերադարձնում է էջերի ցուցակ։ Agent-ի համար լավ որոնումը պետք է վերադարձնի օգտագործելի context։


13. Տեսողական արդյունքների ստեղծում

Agent-ները կարող են ստեղծել ոչ միայն application code, այլ նաև՝

  • UI design,

  • presentation,

  • architecture diagram,

  • video,

  • infographic,

  • documentation visualization։

Օրինակ՝ agent-ը կարող է կարդալ Figma design-ի իրական տվյալները՝

  • spacing,

  • components,

  • typography,

  • variables,

  • colors,

  • layout։

Այնուհետև այդ տվյալների հիման վրա գեներացնել frontend code։

Նույն մոտեցումը կիրառելի է diagram-ների դեպքում։ Եթե agent-ը ճանաչում է .drawio ֆայլի XML կառուցվածքը, այն կարող է infrastructure repository-ի հիման վրա ստեղծել architecture diagram։

Հիմնական գաղափարը պարզ է․

Եթե տեսողական ֆորմատը նկարագրվում է կոդով կամ կառուցվածքային տվյալներով, agent-ը կարող է սովորել գեներացնել այդ ֆորմատը։


14. Երկարաժամկետ հիշողություն

Agent session-ը հաճախ սկսվում է մաքուր վիճակից։ Նախորդ օրվա որոշումները, քննարկումները և նախագծի մանրամասները կարող են հասանելի չլինել։

Persistent memory-ն պահպանում է այն տեղեկությունը, որը պետք է հասանելի լինի նաև հաջորդ session-ներում։

Ամենապարզ տարբերակը MEMORY.md ֆայլն է։

Այն կարող է պարունակել՝

  • architecture decision-ներ,

  • նախագծի պայմանավորվածություններ,

  • կարևոր սահմանափակումներ,

  • նախորդ session-ի ամփոփում,

  • արդեն փորձարկված և չաշխատած լուծումներ։

Սակայն memory ֆայլը նույնպես չպետք է անվերջ մեծանա։

Փոքր նախագծի դեպքում մեկ ֆայլը կարող է բավարար լինել։ Մեծ նախագծում ավելի արդյունավետ է searchable memory-ն, որտեղ agent-ը որոնում է միայն տվյալ պահին անհրաժեշտ հիշողությունները։


Persistent memory-ն պահպանում է այն, ինչ agent-ը սովորել է նախկին աշխատանքներից։

Knowledge search-ը թույլ է տալիս գտնել տեղեկատվություն այն փաստաթղթերից, որոնք agent-ը չի ստեղծել։

Դրանք կարող են լինել՝

  • meeting note-եր,

  • product requirement-ներ,

  • design document-ներ,

  • incident report-ներ,

  • architecture decision record-ներ,

  • internal wiki,

  • նախկին pull request-ներ։

Այս փաստաթղթերը պետք չէ ամբողջությամբ տեղադրել prompt-ի մեջ։

Դրանք կարելի է index անել և որոնել ըստ անհրաժեշտության։

Այսպիսով՝

  • memory-ն օգնում է հիշել անցած session-ները,

  • knowledge search-ը օգնում է գտնել կազմակերպության արդեն գոյություն ունեցող գիտելիքը։


IV. Orchestration և multi-agent համակարգեր

16. Subagent-ներ

Subagent-ը փոքր agent է, որը ստեղծվում է կոնկրետ առաջադրանքի համար։

Parent agent-ը նրան փոխանցում է՝

  • հստակ խնդիր,

  • սահմանափակ context,

  • անհրաժեշտ tool-երը,

  • completion criteria։

Օրինակ՝

name: security-reviewer
description: Ստուգում է կոդը անվտանգության խնդիրների համար
tools:
  - Read
  - Grep
  - Bash
model: medium

Subagent-ի երկու հիմնական առավելություններն են՝

  1. այն կարող է աշխատել մյուս subagent-ների հետ զուգահեռ,

  2. այն չի ծանրաբեռնում parent agent-ի context-ը մանրամասն log-երով։

Subagent-ն ավարտելուց հետո parent-ին պետք է վերադարձնի ոչ թե ամբողջ աշխատանքային պատմությունը, այլ կառուցվածքային ամփոփում։

Օրինակ՝

## Գտնված խնդիրներ

1. Critical: SQL query-ն կառուցվում է string concatenation-ով։
2. High: JWT secret-ը կարող է log արվել։
3. Medium: Login endpoint-ի վրա rate limit չկա։

## Առաջարկվող քայլեր

- Օգտագործել parameterized query։
- Հեռացնել sensitive logging-ը։
- Ավելացնել rate limiting։


17. Agent loop-եր մաքուր context-ով

Երկար աշխատանքների դեպքում նույն session-ը կարող է ծանրանալ հին log-երով և անհաջող փորձերով։

Այլ մոտեցում է յուրաքանչյուր iteration-ը սկսել թարմ context-ով։

Progress-ը պահպանվում է արտաքին համակարգերում՝

  • ֆայլերում,

  • task list-ում,

  • Git commit-ներում,

  • database-ում։

Յուրաքանչյուր iteration-ում agent-ը կարդում է ընթացիկ վիճակը, կատարում մեկ սահմանափակ քայլ և պահպանում արդյունքը։

Այս մոտեցումը հարմար է՝

  • մեծ migration-ների,

  • բազմաթիվ ֆայլերի refactoring-ի,

  • հերթի տարրերի մշակման,

  • մեծ թվով թեստերի ուղղման համար։

Հիմնական նպատակը երկար աշխատանքը շարունակելն է՝ առանց context window-ը աղբով լցնելու։


18. Orchestration գործիքներ

Մի քանի agent գործարկելն ինքնին բարդ չէ։ Դրանց աշխատանքը համակարգելն է դժվար։

Orchestration layer-ը պետք է կարողանա՝

  • ստեղծել task-եր,

  • նշանակել agent-ներ,

  • կառավարել dependency-ները,

  • հետևել progress-ին,

  • չեղարկել կրկնվող աշխատանքը,

  • առանձնացնել workspace-ները,

  • համեմատել և միավորել փոփոխությունները։

Coding agent-ների դեպքում յուրաքանչյուր agent-ին կարելի է տրամադրել առանձին Git worktree։

repository/
├── main/
├── worktree-security/
├── worktree-tests/
└── worktree-docs/

Այսպիսով՝ agent-ները կարող են աշխատել նույն repository-ի վրա՝ առանց անմիջապես նույն ֆայլերը միմյանցից վերագրելու։


19. Cloud-hosted agent-ներ

Managed կամ cloud-hosted agent-ը աշխատում է provider-ի infrastructure-ում։

Provider-ը տրամադրում է՝

  • container կամ sandbox,

  • agent loop,

  • tool execution,

  • session management,

  • streaming API,

  • երբեմն նաև subagent-ների աջակցություն։

Այս մոտեցումը օգտակար է, երբ agent-ը ձեր արտադրանքի մի մասն է և աշխատում է բազմաթիվ օգտատերերի համար։

Անհատական զարգացման դեպքում local agent-ը հաճախ ավելի մատչելի է։

Արտադրանքի դեպքում managed agent-ը նվազեցնում է infrastructure-ի և session orchestration-ի կառուցման անհրաժեշտությունը, բայց ավելացնում է API-ի արժեքը և vendor dependency-ն։


V. Անվտանգության շերտը

20. Sandboxing

Sandboxing-ը սահմանափակում է, թե agent-ը ինչ կարող է կարդալ, փոփոխել կամ ուղարկել ցանցով։

Օրինակ՝ agent-ին կարելի է թույլ տալ աշխատել միայն project directory-ի ներսում և արգելել հասանելիությունը՝

  • SSH key-երին,

  • cloud credential-ներին,

  • .env ֆայլերին,

  • Docker configuration-ին,

  • host filesystem-ին,

  • ներքին ցանցին։

Ավելի ուժեղ մեկուսացման համար agent-ը կարելի է գործարկել Docker container-ում՝ առանց network access-ի։

Sandbox-ի կարևոր հատկությունն այն է, որ սահմանափակումները կիրառվում են մոդելից դուրս։

Նույնիսկ եթե agent-ը որոշի կատարել վտանգավոր գործողություն, համակարգը տեխնիկապես թույլ չի տա դա։

Sandboxing-ի նպատակը հնարավոր վնասի սահմանափակումն է։


21. Permissions

Permission համակարգը որոշում է, թե որ գործողությունները agent-ը կարող է կատարել ավտոմատ, իսկ որոնք պետք է հաստատվեն մարդու կողմից։

Օրինակ՝ կարելի է ավտոմատ թույլատրել՝

  • ֆայլերի ընթերցումը,

  • test command-ների կատարումը,

  • lint-ի գործարկումը,

  • Git diff-ի դիտումը։

Մարդու հաստատում կարող է պահանջվել՝

  • dependency տեղադրելու,

  • database migration կատարելու,

  • production API կանչելու,

  • secret օգտագործելու,

  • Git push կատարելու համար։

Որոշ գործողություններ պետք է ամբողջությամբ արգելվեն․

  • rm -rf,

  • force push դեպի main,

  • .env ֆայլի ընթերցում,

  • curl ... | sh,

  • անծանոթ endpoint-ին տվյալ ուղարկելը։

Tool access ունեցող agent-ի համար permission layer-ը պարտադիր անվտանգության մեխանիզմ է։


22. Hooks

Hook-ը փոքր ստուգում է, որը գործարկվում է agent workflow-ի որոշակի փուլում։

Անվտանգության համար ամենակարևորներից է pre-tool hook-ը։

Այն աշխատում է այս պահին․

Agent-ը ստեղծում է tool call
          ↓
Pre-tool hook-ը ստուգում է գործողությունը
          ↓
Գործողությունը թույլատրվում կամ արգելվում է
          ↓
Tool-ը գործարկվում է

Shell command-ների դեպքում hook-ը կարող է հայտնաբերել՝

  • վտանգավոր file path,

  • pipe-to-shell հրաման,

  • կասկածելի domain,

  • Unicode-ով քողարկված command,

  • environment variable-ի արտահոսք,

  • production resource-ի փոփոխություն։

Hooks-ը չեն փոխարինում sandboxing-ին։

  • Hook-ը փորձում է կանգնեցնել վտանգավոր գործողությունը։

  • Sandbox-ը սահմանափակում է վնասը, եթե գործողությունն այնուամենայնիվ կատարվի։


23. Prompt injection-ից պաշտպանություն

Agent-ը կարող է կարդալ արտաքին բովանդակություն՝

  • repository-ի config ֆայլ,

  • documentation,

  • website,

  • issue,

  • tool output,

  • email,

  • MCP server-ի description։

Այդ բովանդակության մեջ կարող են լինել թաքնված կամ վնասակար հրահանգներ։

Օրինակ՝ repository-ի instruction ֆայլը կարող է agent-ին առաջարկել test log-երը ուղարկել արտաքին endpoint-ին։

Եթե agent-ը կուրորեն վստահի այդ հրահանգին, այն կարող է արտահոսեցնել sensitive տվյալներ։

Պաշտպանության հիմնական սկզբունքն է․

Արտաքին բովանդակությունը դիտարկեք որպես տվյալ, ոչ թե որպես վստահելի հրահանգ։

Պետք է ստուգել ինչպես մուտքային տվյալները, այնպես էլ agent-ի առաջարկած գործողությունները։

Օգտակար մեխանիզմներ են՝

  • allowlist,

  • denylist,

  • sandbox,

  • permissions,

  • pre-tool hooks,

  • command validator,

  • human approval։

Repository-ի հետ եկող agent config-ը կամ MCP server-ը պետք է ստուգել նույն խստությամբ, ինչ executable code-ը։


24. Structural code linting

Սովորական linter-ները հիմնականում ստուգում են՝

  • formatting,

  • import-ներ,

  • naming,

  • syntax,

  • style։

Structural linting-ը ուսումնասիրում է կոդի Abstract Syntax Tree-ը կամ AST-ն։

Այն կարող է հայտնաբերել կոդային կառուցվածքներ, որոնք տեխնիկապես վավեր են, բայց վտանգավոր կամ նախագծում արգելված։

Օրինակ՝ Python-ում․

def process(items=[]):
    ...

Այս default list-ը ստեղծվում է մեկ անգամ և կիսվում է հետագա կանչերի միջև։

AI-ի գեներացրած կոդը կարող է լավ տեսք ունենալ, անցնել formatter-ը և նույնիսկ որոշ թեստեր, բայց ներքին կառուցվածքով լինել թույլ։

Եթե agent-ը հաճախ կրկնում է նույն վատ pattern-ը, այն անընդհատ ձեռքով ուղղելու փոխարեն ավելի լավ է ստեղծել ավտոմատ structural rule։


25. Pre-commit և CI gate-եր

Pre-commit gate-ը ստուգում է կոդը մինչև commit ստեղծելը։

Այն կարող է գործարկել՝

  • formatter,

  • linter,

  • type checker,

  • secret scanner,

  • security scanner,

  • structural linting,

  • unit test-եր։

Եթե ստուգումը չի անցնում, commit-ը չի ստեղծվում։

Սա հատկապես օգտակար է agent-ների համար։ Agent-ը չի հոգնում խիստ ստուգումներից։ Այն կարդում է սխալը, ուղղում կոդը և կրկին փորձում։

Agent-ը գրում է կոդ
        ↓
Pre-commit-ը մերժում է
        ↓
Agent-ը կարդում է սխալը
        ↓
Agent-ը ուղղում է կոդը
        ↓
Commit-ը ստեղծվում է

Pre-commit-ը պաշտպանում է local Git history-ն։

CI-ն նույն ստուգումները գործարկում է մաքուր server environment-ում և պաշտպանում merge-ը։

Լավ նախագծում անհրաժեշտ են երկուսն էլ։


26. Completion criteria և evaluation gate

Agent-ի հայտարարությունը, որ խնդիրը ավարտված է, դեռ ապացույց չէ։

Ավարտի պայմանները պետք է լինեն agent-ից դուրս ստուգվող։

Վատ completion criteria․

Agent-ը կարծում է, որ feature-ը պատրաստ է։

Լավ completion criteria․

- Բոլոր թեստերն անցնում են։
- Lint error չկա։
- Type check-ն անցնում է։
- API contract-ը պահպանված է։
- Security scan-ը critical խնդիր չի գտել։

Evaluation gate-ը յուրաքանչյուր iteration-ից հետո ստուգում է այս պայմանները։

while not evaluator.is_complete():
    agent.run_next_step()

Այս մոտեցումը թույլ չի տալիս agent-ին աշխատանքը վաղաժամ ավարտված հայտարարել։


VI. Observability

27. Tracing

Tracing-ը ցույց է տալիս agent-ի անցած ամբողջ ճանապարհը։

Trace-ը կարող է ներառել՝

  • model call-երը,

  • tool call-երը,

  • subagent-ների աշխատանքը,

  • յուրաքանչյուր քայլի տևողությունը,

  • մուտքային և ելքային տվյալները,

  • օգտագործված model version-ը,

  • error-ները,

  • որոշումների հաջորդականությունը։

Պարզ tool call-երի ցուցակը միշտ չէ, որ բավարար է։ Ավելի օգտակար է tree կառուցվածքը։

User request
└── Planner
    ├── Code analysis
    │   ├── Read file
    │   └── Search references
    ├── Security subagent
    │   └── Scan dependencies
    └── Executor
        ├── Edit file
        ├── Run tests
        └── Fix failure

Tracing-ը թույլ է տալիս հասկանալ ոչ միայն վերջնական արդյունքը, այլ նաև այն, թե agent-ն ինչպես է հասել դրան։


28. Logging

Logging-ը observability-ի հիմքն է։

Յուրաքանչյուր run-ի համար ցանկալի է պահպանել՝

  • session ID,

  • model name և version,

  • prompt,

  • response,

  • token usage,

  • latency,

  • tool name,

  • tool arguments,

  • tool result,

  • error-ներ։

Structured log-ի համար հարմար է JSON Lines ձևաչափը․

{"session_id":"abc","type":"model_call","latency_ms":840,"tokens":1200}
{"session_id":"abc","type":"tool_call","tool":"read_file","latency_ms":12}
{"session_id":"abc","type":"error","message":"Test failed"}

Սկզբնական փուլում հաճախ ավելի անվտանգ է պահպանել ավելի շատ տվյալ և հետագայում որոշել retention policy-ն։

Եթե agent-ը վատ արդյունք է տվել, բայց չեք պահպանել այն context-ը և tool output-ը, որոնք նա տեսել է, խնդիրը վերարտադրելն ու հասկանալը դժվար կլինի։


29. Replay և վերարտադրելիություն

Replay-ը թույլ է տալիս կրկին գործարկել agent-ի նախկին աշխատանքը՝ պահպանված trace-ի կամ log-ի հիման վրա։

Այն օգտակար է՝

  • bug վերարտադրելու,

  • նոր model version-ը հնի հետ համեմատելու,

  • prompt-ի փոփոխությունը գնահատելու,

  • security incident ուսումնասիրելու,

  • tool-ի նոր տարբերակը փորձարկելու համար։

Իդեալական replay-ի համար պետք է պահպանել՝

  • մոդելի ճշգրիտ տարբերակը,

  • system prompt-ը,

  • tool schema-ները,

  • tool output-երը,

  • environment-ի վիճակը,

  • օգտագործված ֆայլերի version-ը։

LLM-ի արդյունքը միշտ չէ, որ ամբողջությամբ deterministic է, սակայն replay-ը թույլ է տալիս հնարավորինս մոտ վերականգնել նույն պայմանները և հասկանալ վարքի փոփոխությունը։


30. Metrics

Metrics-ը ցույց է տալիս, թե agent համակարգն ինչքան արդյունավետ է աշխատում։

Գործընթացային metrics

  • ամբողջ session-ի latency,

  • tool call-ի latency,

  • token usage,

  • մեկ task-ի արժեք,

  • tool call-երի քանակ,

  • retry-ների քանակ,

  • error rate,

  • loop iteration-ների քանակ։

Այս metrics-ը կարող է ցույց տալ, որ agent-ը՝

  • պտտվում է loop-ի մեջ,

  • չափազանց հաճախ է կանչում նույն tool-ը,

  • պարզ խնդրի վրա շատ token է ծախսում,

  • որոշ tool-երի դեպքում հաճախ է ձախողվում։

Արդյունքային metrics

Ավելի կարևոր է չափել իրական արդյունքը։

Օրինակ՝

  • անցա՞ն արդյոք CI թեստերը,

  • merge եղա՞վ pull request-ը,

  • հաջողվե՞ց deployment-ը,

  • ընդունվե՞ց agent-ի պատրաստած պատասխանը,

  • պահանջվե՞ց rollback,

  • քանի՞ manual correction անհրաժեշտ եղավ։

Process metric-ը ցույց է տալիս, թե agent-ն ինչպես աշխատեց։

Outcome metric-ը ցույց է տալիս, թե արդյոք նրա աշխատանքն իրական արժեք ստեղծեց։


Ինչպիսի՞ն կարող է լինել ամբողջական agent architecture-ը

Հասուն agent համակարգը կարող է ունենալ հետևյալ կառուցվածքը․

User Goal
    ↓
Router
    ↓
Planner
    ↓
Executor Agent
    ↙        ↓         ↘
Docs Tool  Code Tool  Search Tool
    ↓         ↓         ↓
         Observations
              ↓
          Evaluator
       ↙              ↘
 Continue working     Complete
       ↓                 ↓
   New iteration      Final result

Ամբողջ համակարգի շուրջ գործում են՝

Configuration
Memory
Knowledge Search
Permissions
Hooks
Sandbox
Logging
Tracing
Metrics

Agent-ի որակը կախված չէ միայն օգտագործվող լեզվային մոդելից։

Նույնքան կարևոր են՝

  • agent-ին տրված գործընթացը,

  • context-ի կառավարումը,

  • tool-երի որակը,

  • անվտանգության սահմանափակումները,

  • completion criteria-ն,

  • observability-ն։


Ինչպե՞ս սկսել

Պետք չէ միանգամից ստեղծել բարդ multi-agent platform։

Սկսելու համար բավարար է հետևյալ հերթականությունը։

Քայլ 1․ ստեղծեք project instruction ֆայլ

Նշեք՝

  • package manager-ը,

  • test և lint command-ները,

  • repository-ի հիմնական կանոնները,

  • արգելված գործողությունները։

Քայլ 2․ սահմանափակեք agent-ի հասանելիությունը

Մի տվեք ամբողջ համակարգի կամ credential-ների հասանելիություն։

Աշխատեցրեք այն project directory-ի կամ container-ի ներսում։

Քայլ 3․ ավելացրեք հստակ ավարտի պայմաններ

Agent-ը չպետք է ինքնուրույն որոշի, որ աշխատանքն ավարտված է։

Օգտագործեք test, lint, CI և այլ արտաքին ստուգումներ։

Քայլ 4․ ավելացրեք մեկ reusable workflow

Սկսեք ամենահաճախ կրկնվող խնդրից, օրինակ՝ API endpoint ավելացնելու կամ pull request review անելու գործընթացից։

Քայլ 5․ միացրեք logging-ը

Պահպանեք model call-երը, tool call-երը, error-ները և latency-ն։

Քայլ 6․ հետո միայն ավելացրեք subagent-ներ

Subagent օգտագործեք այն ժամանակ, երբ խնդիրը իսկապես հնարավոր է բաժանել անկախ մասերի։


Եզրակացություն

Agentic engineering-ը պարզապես ավելի երկար prompt գրելը չէ։

Այն ամբողջական ինժեներական համակարգ է, որտեղ պետք է ճիշտ նախագծել՝

  • agent-ի աշխատանքային ցիկլը,

  • state-ի պահպանումը,

  • context-ի կառավարումը,

  • tool access-ը,

  • multi-agent համագործակցությունը,

  • permissions-ը,

  • sandboxing-ը,

  • evaluation-ը,

  • tracing-ը,

  • metrics-ը։

Լավ agent համակարգը չի կառուցվում միայն ամենաուժեղ մոդելի վրա։

Հաճախ ավելի փոքր մոդելը՝ հստակ workflow-ով, ճիշտ context-ով և խիստ ստուգումներով, կարող է ավելի օգտակար լինել, քան հզոր մոդելը՝ առանց սահմանված գործընթացի։

Գործիքները շարունակելու են փոխվել։ Նոր agent framework-ներ և coding assistant-ներ կշարունակեն հայտնվել։

Բայց հիմնական գաղափարները նույնն են մնալու․

Agent-ին տվեք հստակ նպատակ, անհրաժեշտ context, սահմանափակ tool-եր, անվտանգ միջավայր և արտաքին աշխարհով ստուգվող ավարտի պայմաններ։