Բլոգ

Թարմացվել է 11 րոպե կարդալուԳործակալների ստեղծում և գործարկումՀամեմատություն

MCP և A2A. ընտրեք արձանագրային սահմանը, ոչ թե բրենդային պատերազմը

Համեմատեք MCP-ը, A2A-ն և ուղիղ API-ները ըստ նպատակի, հայտնաբերման, թույլտվության, երկարատև աշխատանքի, ձախողման ձևերի և այն սահմանի, որի համար յուրաքանչյուրը պետք է պատասխանատու լինի։

Dali

Dali-ն AI agent systems ստուդիա է։ Դավիթը՝ engineering/product, Լիանան՝ operations/workflow fit։ Production գործակալներ առկա tools-ում։

David Hakobyan · LinkedIn · Dali

Արձանագրային սահմանների գծապատկեր` ուղիղ API-ներ, MCP գործիքային և տվյալների սերվերներ, ինչպես նաև A2A համագործակցություն անկախ գործակալների միջև

MCP-ը ստանդարտացնում է, թե ինչպես է AI հավելվածը միանում գործիքներին, տվյալների աղբյուրներին և դրանց հետ կապված համատեքստին։ A2A-ն ստանդարտացնում է, թե ինչպես են անկախ գործակալները գտնում միմյանց և համագործակցում առաջադրանքների վրա առանց ներքին հիշողությունը կամ գործիքների իրականացումները կիսելու։ **Ուղիղ API**-ն հաճախ բավական է, երբ մեկ թիմ ամբողջությամբ տնօրինում է մեկ փակ ինտեգրում և կարիք չկա տեղափոխելի հայտնաբերման տարբեր հոսթերի կամ մատակարարների միջև։ Շատ արտադրական համակարգեր կօգտագործեն **երկուսն էլ** A2A գործակալների միջև, MCP յուրաքանչյուր գործակալից դեպի իր գործիքները։

Սրանք տարբեր սահմաններ են, ոչ թե մրցակից շրջանակային բրենդներ։ Ստորև նշված արձանագրային մանրամասները ստուգված են առաջնային փաստաթղթերով 2026-08-11 ամսաթվով։ Սպեցիֆիկացիաները շարունակում են զարգանալ, ուստի դիզայնը վերջնականացնելուց առաջ նորից կարդացեք MCP-ի և A2A-ի ընթացիկ էջերը։

Ինչի համար է յուրաքանչյուր արձանագրությունը

Model Context Protocol (MCP)

MCP-ը բաց ստանդարտ է AI հավելվածները արտաքին համակարգերի հետ կապելու համար, ինչպիսիք են տվյալների աղբյուրները, գործիքները և աշխատընթացները (MCP intro, docs path 2026-07-28)։ Ճարտարապետությունը host / client / server է AI հավելվածը հիմնական հավելվածն է, յուրաքանչյուր սերվերային կապը վարում է հաճախորդը, իսկ սերվերները տրամադրում են համատեքստ ([MCP architecture](https://modelcontextprotocol.io/docs/2026-07-28/learn/architecture))։ Սերվերները կարող են տրամադրել **tools** կանչվող գործողություններ, resources համատեքստային տվյալներ, և **prompts** վերօգտագործելի ձևանմուշներ (MCP architecture)։ Տվյալների շերտը օգտագործում է JSON-RPC 2.0։ Տրանսպորտները ներառում են stdio տեղային գործընթացների հաղորդակցության համար, և **Streamable HTTP** հեռավոր սերվերների համար, ինչպես նաև ընտրովի Server-Sent Events` հոսքային փոխանցման համար (MCP architecture

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

Agent2Agent protocol (A2A)

A2A-ն բաց արձանագրություն է անկախ, հաճախ անթափանց գործակալային հավելվածների միջև հաղորդակցության և համատեղելի աշխատանքի համար (A2A home; A2A specification)։ Google-ը A2A-ն հայտարարեց 2025-04-09-ին և նշեց, որ այն լրացնում է MCP-ը, որը գործակալներին տալիս է գործիքներ և համատեքստ (Google A2A announcement2025-06-23-ին նախագիծը տեղափոխվեց Linux Foundation-ի ներքո` խոշոր տեխնոլոգիական գործընկերների մասնակցությամբ (Google donation post; Linux Foundation launch)։ 2026-08-11-ի դրությամբ A2A-ի փաստաթղթերում վերջին թողարկված սպեցիֆիկացիայի տարբերակը նշված էր որպես 1.0.0 (A2A specification

A2A-ի հիմնական տարրերն են Agent Card JSON հնարավորությունների մետատվյալներ, **tasks**-ը վիճակ պահող աշխատանքային միավորներ, ինչպես նաև messages-ը, parts-ը և artifacts-ը (A2A key concepts)։ Գործակալները կարող են փոխազդել հարցում ու պատասխան եղանակով պարբերական ստուգմամբ, Server-Sent Events հոսքով և երկարատև աշխատանքի համար մղվող ծանուցումներով ([A2A key concepts](https://a2a-protocol.org/latest/topics/key-concepts/); [Google A2A announcement](https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/))։ Հեռավոր գործակալները մնում են անթափանց, այսինքն համագործակիցները չպետք է կարիք ունենան միմյանց ներքին հիշողությանը, գործիքներին կամ սեփական տրամաբանությանը (A2A home; A2A specification

Պաշտոնական A2A ուղեցույցը հստակ է MCP-ը գործիքների համար է, A2A-ն գործակալների (A2A home; A2A and MCP)։ Google-ի 2026-03-18 մշակողների ուղեցույցը նույն բաժանումն է առաջարկում MCP գործիքների և տվյալների համար, A2A հայտնաբերման և գործակալների համագործակցության համար, ներառյալ Agent Card-երը հայտնի ստանդարտ URL-ում, օրինակ /.well-known/agent-card.json (Developer's Guide to AI Agent Protocols

Արձանագրային սահմանների քարտեզ

Արձանագրային սահմանների քարտեզ` օգտատեր և հաճախորդ գործակալ, MCP կապեր գործակալից դեպի գործիքային և տվյալների սերվերներ, A2A կապեր անկախ գործակալների միջև, և ուղիղ API ուղի մեկ փակ սեփական ինտեգրման համար

Լեզվից անկախ քարտեզ MCP-ը գործիքների և տվյալների ուղղահայաց սահմանն է, A2A-ն գործակալից գործակալ հորիզոնական սահմանը, իսկ ուղիղ API-ն պարզ ուղին է, երբ մեկ հավելված տնօրինում է փակ ինտեգրումը։

Եթե դեռ որոշում եք, թե արդյոք մեկ գործակալը բավարար է մինչև արձանագրություններ ընտրելը, սկսեք բազմագործակալ և մեկ գործակալ մոտեցումների համեմատությունից։ Եթե դեռ ընտրում եք շրջանակներ, այլ ոչ թե կապի արձանագրություններ, տեսեք բաց շրջանակներ և օգնականներ էջը։

Համեմատական աղյուսակ

Այս աղյուսակը կարդալու եղանակը հետևյալն է` ընտրեք այն սահմանը, որը համապատասխանում է մասնակիցներին և պատասխանատվության մոդելին, ոչ թե այն լոգոն, որը տեսել եք որևէ ցուցադրության մեջ։

Արձանագրային վարքագծի տողերը արտացոլում են առաջնային փաստաթղթերը, որոնք ստուգվել են 2026-08-11-ին։

ՉափանիշMCPA2AՈւղիղ API (սեփական ինտեգրում)
ՆպատակՄիացնել AI հավելվածը գործիքներին, տվյալների աղբյուրներին և հարակից համատեքստինԹույլ տալ անկախ գործակալներին հայտնաբերել, հաղորդակցվել և համագործակցել առաջադրանքների շուրջԿանչել կոնկրետ ծառայություն, որն արդեն ձեր հավելվածի վերահսկողության տակ է
ՄասնակիցներՀիմնական հավելված` AI հավելված, MCP հաճախորդ, MCP սերվերՕգտատեր, A2A հաճախորդ գործակալ, A2A սերվեր` հեռավոր գործակալՁեր հավելվածը և թիրախային API-ն
ՀայտնաբերումՍերվերի հնարավորությունների հայտնաբերում, tools/resources/prompts ցուցակAgent Card մետատվյալներ` ինքնություն, հմտություններ, հասցեակետ, թույլտվության պահանջներՁեր կոդն ու փաստաթղթերը, առանց Agent Card ստանդարտի պարտադիր պահանջի
ՏրանսպորտJSON-RPC տվյալների շերտ, stdio և Streamable HTTP` ընտրովի SSE-ովHTTP(S), JSON-RPC և այլ կապումներ, SSE հոսք, ընտրովի մղվող հետկանչերԱյն, ինչ API-ն արդեն օգտագործում է` REST, gRPC, SDK կամ հերթ
Առաջադրանքի մոդելTool/resource/prompt պաշտոնական տարրեր, ինչպես նաև երկարատև աշխատանքների համար ընտրովի Tasks ընդլայնումՎիճակ պահող Task կյանքի ցիկլ` messages և artifacts տարրերով ու բազմաքայլ համատեքստովՁեր սեփական հարցում ու պատասխան կամ աշխատանքի մոդելը
Թույլտվության սահմանՍերվերը և հիմնական հավելվածը պետք է ապահովեն վավերացումը, իսկ անվտանգության ուղեցույցը արգելում է նշանների կույր փոխանցումը և շեշտում նվազագույն անհրաժեշտ իրավասություններըՎավերացման պահանջները հայտարարվում են Agent Card-ում, մուտքային տվյալները սովորաբար գնում են ստանդարտ HTTP սխեմաներով, իսկ գործակալները մնում են անթափանցՁեր API անցակետը, OAuth-ը, ծառայողական հաշիվները և իրավասության շրջանակները
Հոսք / երկարատև աշխատանքԾանուցումներ և առաջընթացի օգտակար միջոցներ, ինչպես նաև կայուն աշխատանքի համար Tasks ընդլայնումՆախագծված է երկարատև առաջադրանքների համար` պարբերական ստուգում, SSE հոսք, մղվող ծանուցումներՄիայն այն դեպքում, եթե դուք ինքներդ եք կառուցում ասինխրոն աշխատանքներ և վիճակի վերջնակետեր
Ձախողումների մշակումԳործիքի կատարման սխալներ և անվտանգության ձախողման դասեր ուղեցույցում, հաճախորդը պետք է մշակի բացակայող հնարավորություններն ու վավերացման խափանումներըԲնութագրով սահմանված առաջադրանքի սխալներ` չի գտնվել, չի կարող չեղարկվել, չաջակցվող գործողություն, բովանդակության տեսակ, վավերացման խափանում, ինչպես նաև առաջադրանքի վերջնական վիճակներՁեր HTTP կոդերը, կրկնափորձերը և DLQ նախագծումը
Երբ չօգտագործելMCP-ը մի օգտագործեք որպես բազմագործակալ համագործակցության փոխարինող կամ որպես անվճար անվտանգության վերահսկիչA2A-ն մի օգտագործեք որպես գործիքային կանչի արձանագրություն կամ պարզ մասնավոր API-ն փաթաթելու միջոցԽուսափեք մեկանգամյա API-ների բազմացումից, երբ բազմաթիվ հոսթերի նույն շարժական գործիքային մակերեսն է պետք

Աղբյուրներ արձանագրային սյունակների համար` MCP architecture, MCP security best practices, A2A key concepts, A2A and MCP, A2A specification, Google A2A announcement, Google developer guide (2026-03-18)։

Երբ է ուղիղ API-ն ավելի պարզ

Խորհուրդ. պահեք ուղիղ API-ն, երբ հետևյալ բոլոր պայմանները ճիշտ են։

  1. Մեկ հավելված ամբողջությամբ տնօրինում է ինտեգրումը։
  2. Գործիքային մակերեսը փոքր է և կայուն։
  3. Պետք չէ, որ մի քանի AI հոսթ` օրինակ աշխատասեղանային հավելվածը, IDE-ն, զրույցի արտադրանքը և գործառնական գործակալը, կիսեն նույն տեղափոխելի սերվերը։
  4. Այդ API-ի համար դուք արդեն ունեք վավերացում, գրանցամատյաններ և հերթապահ սպասարկում։

Արձանագրությունն արդարացնում է իրեն, երբ հայտնաբերումը, վերօգտագործումը կամ միջթիմային համատեղելիությունը ավելի կարևոր են, քան ևս մեկ պաշտպանվող ու մոնիթորվող մակերես ունենալու ծախսը։ Google-ի սեփական արձանագրային ուղեցույցը գործնական կանոնը ձևակերպում է այսպես` արձանագրությունները ավելացրեք այն ժամանակ, երբ դրանք պետք են, և սկսեք գործիքներից ու տվյալների հասանելիությունից, ոչ թե առաջին իսկ օրը բոլոր ստանդարտները տեղադրելուց (Developer's Guide to AI Agent Protocols

Հիպոթետիկ օրինակ` ձեր սերվերային մասի մեկ աջակցության գործակալ, որը միայն ձեր օգնության սեղանի API-ում տոմսեր է ստեղծում, կարող է մնալ մասնավոր ֆունկցիոնալ գործիքի վրա։ Այդ ուղու համար ձեզ պետք չեն ոչ MCP, ոչ A2A։

Հիպոթետիկ հակաօրինակ` նույն տոմսային գործողությունները պետք է հասանելի լինեն Claude Desktop-ին, ներքին գործառնական գործակալին և ծրագրավորման օգնականին։ Այդ դեպքում ընդհանուր MCP սերվերը, իրական վավերացմամբ և նվազագույն անհրաժեշտ իրավասություններով, ավելի ուժեղ ընտրություն է, քան երեք առանձին փաթեթումները։

Համակցված ճարտարապետություն. երկու արձանագրությունները միասին

Պաշտոնական A2A փաստաթղթերը լրացնող օրինաչափությունը նկարագրում են ուղիղ` գործակալային հավելվածը կարող է A2A-ով խոսել այլ գործակալների հետ, իսկ յուրաքանչյուր գործակալ իր գործիքների և ռեսուրսների համար օգտագործում է MCP (A2A and MCP

Օգտակար մտավոր մոդելը հետևյալն է։

Օգտատեր / հաճախորդ գործակալ
        |
        | A2A (tasks, messages, artifacts)
        v
  Հեռավոր մասնագիտացված գործակալ
        |
        | MCP (tools, resources)
        v
  API-ներ, տվյալների բազաներ, ֆայլեր, SaaS համակարգեր

A2A փաստաթղթերի ավտո-վերանորոգման արհեստանոցի սցենարը այդ բաժանումը դարձնում է շոշափելի` բազմաքայլ զրույցը և մատակարարների հետ համագործակցությունը մնում են A2A-ի վրա, մինչդեռ ախտորոշիչ սկաներներն ու ձեռնարկները MCP գործիքներ են (A2A and MCP)։ Սա սահմանի ընտրություն է, ոչ թե բրենդային նախասիրություն։

Հեռավոր գործակալների հաղորդագրություններն ու գործիքային արդյունքները միևնույն է մրցում են կատարման միջավայրի ուշադրության համար։ Նախագծեք դրանց պահման ժամկետներն ու ավարտը համատեքստի կյանքի ցիկլով` ամեն տվյալային բեռը մոդելի պատուհանի մեջ չլցնելով։

«Գործակալ» բառի արտադրական իմաստի համար, ոչ թե ցուցադրական զրույցի, տեսեք ինչ է արտադրական AI գործակալը հոդվածը։

Ձախողման ձևեր, որոնք ավելի կարևոր են, քան հապավումները

Արձանագրությունները չեն վերացնում գործառնական ձախողումները։ Նրանք պարզապես տեղափոխում են, թե որտեղ են այդ ձախողումները երևում։

MCP կողմի ձախողման ձևեր

MCP-ի անվտանգության ուղեցույցը նշանների կույր փոխանցումը համարում է հակաօրինակ` սերվերները չպետք է ընդունեն նշաններ, որոնք տրված չեն հենց MCP սերվերի համար (MCP security best practices)։ Նույն ուղեցույցը նաև ծածկում է շփոթված միջնորդի ռիսկերը միջնորդավորված OAuth-ի դեպքում, SSRF-ը մետատվյալների հայտնաբերման ընթացքում, աշխատաշրջանի առևանգումը, վտանգավոր տեղային սերվերի գործարկումը և չափազանց լայն իրավասության շրջանակները (MCP security best practices

Օպերատորական հետևանքները, եթե այս ուղեցույցը անտեսեք, հետևյալն են։

  • Մեկ չափից ավելի լայն գործիքը դառնում է վնասման շառավիղ բոլոր հոսթերի համար, որոնք միացել են սերվերին։
  • Աուդիտի մատյանները կորցնում են իրական հաճախորդի ինքնությունը, երբ նշանները կուրորեն փոխանցվում են։
  • «MCP-ը միացված է» արտահայտությունը դառնում է կեղծ անվտանգության զգացում։

Գործնական գործիքային դարպասների համար այս էջը զուգակցեք անվտանգ գործիքային կանչեր բիզնես գործակալների համար և հուշման ներարկումից պաշտպանություն գործիքային գործակալների համար հոդվածների հետ։

A2A կողմի ձախողման ձևեր

A2A-ն ենթադրում է, որ հեռավոր գործակալները անթափանց համագործակիցներ են, ոչ թե թափանցիկ գործիքային գործառույթներ (A2A specification)։ Սա առաջացնում է այլ ձախողման ձևեր։

  • Առաջադրանքի պատասխանատվության շեղում: երկարատև առաջադրանքը ավարտվում է, ձախողվում է, չեղարկվում է կամ սպասում է մուտքի, և ոչ ոք չի տնօրինում վերջնական վիճակը։
  • Հնարավորությունների անհամապատասխանություն: Agent Card-ը խոստացել է մի հմտություն, որը հեռավոր գործակալը ձեր վավերացման կամ բովանդակության տեսակների պայմաններում իրականում չի կարող կատարել։
  • Անթափանց փոխանցման կորուստ: սահմանափակումները կորչում են բազմաքայլ հաղորդագրությունների ընթացքում, եթե ձեր պայմանագրերը թույլ են։
  • Թույլտվության ձևականություն: հայտնաբերումը մասամբ բաց է, բայց իրական հմտությունների թույլտվությունը թերի է։

Խորհուրդ. եթե ներդնում եք A2A, նշանակեք պատասխանատու ամբողջ առաջադրանքի ուղու համար, ոչ միայն յուրաքանչյուր գործակալի գործարկելի ֆայլի համար։ Տոպոլոգիան միևնույն է կարևոր է, և արձանագրության ընտրությունը չի փոխարինում բազմագործակալ պատասխանատվության կարգապահությանը։

Ընդհանուր արտադրական ձախողման ձևեր

Սրանք ի հայտ են գալիս անկախ նրանից` օգտագործում եք MCP, A2A, երկուսը միասին, թե ոչ մեկը։

  • Մարդկային դարպասներ չկան անշրջելի գրառումների համար։
  • Չկա ամբողջ ուղու աշխատընթացի գնահատում։
  • Չկան հետագծեր, որոնք կապում են մոդելի որոշումները գործիքների կամ հեռավոր գործակալի արդյունքների հետ։

Դրանց դեմ նախագծեք արտադրական գործակալի ձախողման ձևեր և գործակալի դիտելիություն նյութերի օգնությամբ։

Որոշման ստուգաթերթ

Օգտագործեք սա որպես «գնալ կամ չգնալ» զտիչ, նախքան որևէ արձանագրություն իրականացնելը։

  1. Ո՞վ է մյուս կողմը։ Կառուցվածքային գործիքը կամ տվյալների համակարգը հուշում է MCP կամ ուղիղ API։ Անկախ գործակալը, որն ունի իր դատողությունը և հմտությունները, հուշում է A2A։
  2. Ո՞վ է տնօրինում վավերացումը և վնասման շառավիղը։ Եթե չեք կարող անվանել թույլտվության սահմանը, մի բացեք այդ մակերեսը։
  3. Մի քանի հոսթերի նույն գործիքներն են պե՞տք։ Այո տարբերակը հօգուտ MCP-ի է։ Ոչ տարբերակը հօգուտ մասնավոր API-ի կամ ներկառուցված գործիքների է։
  4. Տարբեր թիմերի կամ մատակարարների գործակալները պե՞տք է համագործակցեն առանց ներքին կառուցվածքը կիսելու։ Այո տարբերակը հօգուտ A2A-ի է։ Ոչ տարբերակը հօգուտ մեկ գործակալի է` իր գործիքներով։
  5. Աշխատանքը երկարատե՞վ է` վիճակով, արտեֆակտներով կամ մարդկային սպասման փուլերով։ A2A-ն նախագծված է հենց այդ դասի առաջադրանքների համար։ MCP-ը կարող է աջակցել երկարատև աշխատանքին ընդլայնումներով և ծանուցումներով, բայց այն շարունակում է լինել գործիք/համատեքստ արձանագրություն, ոչ թե հավասար գործընկեր գործակալների ցանց։
  6. Կարո՞ղ եք դիտարկել և չեղարկել աշխատանքը։ Եթե ուղին չեք կարող գրանցել, հետ կանչել կամ կանգնեցնել, արձանագրության ընտրությունը վաղաժամ է։
  7. Կա՞ ավելի պարզ ուղի։ Նախընտրեք ամենաբարակ սահմանը, որը բավարարում է պահանջը։

ՀՏՀ

MCP-ը և A2A-ն մրցակիցնե՞ր են

Ոչ, համենայնդեպս ոչ ըստ առաջնային արձանագրային գրականության։ Թե Google-ի A2A գործարկումը, թե պաշտոնական A2A փաստաթղթերը A2A-ն դիրքավորում են որպես MCP-ի լրացում (Google A2A announcement; A2A and MCP

Կարո՞ղ եմ գործակալը ներկայացնել այնպես, կարծես դա MCP գործիք է

Երբեմն հստակ սահմանված հմտությունը կարող է գործիքային թվալ, և A2A փաստաթղթերը նշում են, որ A2A սերվերը կարող է որոշ հմտություններ տրամադրել MCP-ի հետ համատեղելի ձևով։ Նույն փաստաթղթերը նաև ասում են, որ A2A-ի ուժը ճկուն և վիճակ պահող համագործակցությունն է` սովորական գործիքային կանչից դուրս (A2A and MCPԽորհուրդ. մի կրճատեք հավասար գործընկեր գործակալներին մինչև գործիքներ միայն այն պատճառով, որ չեք ուզում սովորել երկրորդ սահմանը։

Առաջին փորձնական տարբերակի համար երկու արձանագրություննե՞րն էլ են պետք

Սովորաբար ոչ։ Խորհուրդ. սկսեք այն սահմանից, որն իրականում հատում է ձեր փորձնական տարբերակը։ Առաջին արտադրական գործակալների մեծ մասին ավելի շատ պետք են անվտանգ գործիքներ, քան բազմավաճառող գործակալային ցանց։ A2A ավելացրեք այն ժամանակ, երբ անկախ գործակալներն ու հայտնաբերումը դառնում են իրական պահանջ (Developer's Guide to AI Agent Protocols

MCP-ի կամ A2A-ի ընտրությունը ընտրո՞ւմ է իմ շրջանակը

Ոչ։ A2A-ն բացահայտ գործակալների մշակման հավաքակազմ չէ, իսկ MCP-ը կապի արձանագրություն է, ոչ թե համակարգման կատարման միջավայր (A2A home; MCP intro)։ Շրջանակները ընտրեք արձանագրային սահմաններից առանձին։

Հաջորդ քայլ

Թղթի վրա քարտեզագրեք մեկ աշխատընթաց։

  1. Որ համակարգերն են գործիքներ կամ տվյալների աղբյուրներ։
  2. Որ մասնակիցներն են անկախ գործակալներ։
  3. Որ գործողություններն են անշրջելի և պահանջում են մարդկային դարպասներ։
  4. Ով է տնօրինում վավերացումը, գրանցամատյանները և չեղարկումը։

Այնուհետև այդ սահմանների հիման վրա ընտրեք MCP, A2A, ուղիղ API կամ համակցված տեխնիկական հավաքածու։

Եթե ուզում եք օգնություն` այդ քարտեզը դարպասներով պաշտպանված արտադրական ուղու վերածելու համար, խոսեք Dali-ի հետ լուծումներ էջում։ Բերեք աշխատընթացը, գրանցումների հիմնական համակարգերը և հաստատման կանոնները, ոչ թե նախընտրելի արձանագրության բրենդը։