MCP და A2A: აირჩიეთ პროტოკოლის საზღვარი, არა ბრენდების ომი
შეადარეთ MCP, A2A და პირდაპირი API დანიშნულებით, შესაძლებლობების აღმოჩენით, ავტორიზაციით, ხანგრძლივი სამუშაოთი, მარცხის რეჟიმებით და იმ საზღვრით, რომელიც თითოეულმა უნდა დაიკავოს.
Dali
Dali არის AI agent systems სტუდია. დავითი - engineering/product, ლიანა - operations/workflow fit. Production აგენტები არსებულ tools-ში.
David Hakobyan · LinkedIn · Dali
MCP სტანდარტიზებს, როგორ უკავშირდება ხელოვნური ინტელექტის აპლიკაცია ინსტრუმენტებს, მონაცემთა წყაროებს და დაკავშირებულ კონტექსტს. A2A სტანდარტიზებს, როგორ პოულობენ ერთმანეთს დამოუკიდებელი აგენტები და თანამშრომლობენ ამოცანებზე შიდა მეხსიერებისა და ინსტრუმენტების რეალიზაციის გაზიარების გარეშე. პირდაპირი API ხშირად საკმარისია, როცა ერთი გუნდი სრულად ფლობს ერთ დახურულ ინტეგრაციას და არ სჭირდება გადატანადი აღმოჩენა ჰოსტებსა ან მომწოდებლებს შორის. ბევრი საწარმოო სისტემა გამოიყენებს ორივეს: A2A აგენტებს შორის, MCP კი თითოეული აგენტიდან მის ინსტრუმენტებამდე.
ეს სხვადასხვა საზღვარია და არა კონკურენტი ჩარჩოების ბრენდები. ქვემოთ მოცემული პროტოკოლის დეტალები პირველად დოკუმენტაციასთან გადამოწმებულია 2026-08-11-ზე. სპეციფიკაციები კვლავ იცვლება, ამიტომ დიზაინის დაფიქსირებამდე ხელახლა წაიკითხეთ MCP-ისა და A2A-ის აქტუალური გვერდები.
რისთვის არის თითოეული პროტოკოლი
Model Context Protocol (MCP)
MCP არის ღია სტანდარტი ხელოვნური ინტელექტის აპლიკაციების გარე სისტემებთან დასაკავშირებლად: მონაცემთა წყაროები, ინსტრუმენტები და სამუშაო პროცესები (MCP intro, docs path 2026-07-28). არქიტექტურა არის ჰოსტი / კლიენტი / სერვერი: ხელოვნური ინტელექტის აპლიკაცია არის ჰოსტი, თითოეულ სერვერთან კავშირს ამუშავებს კლიენტი, ხოლო სერვერები აწვდიან კონტექსტს (MCP architecture). სერვერებს შეუძლიათ გამოავლინონ ინსტრუმენტები გამოძახებადი ქმედებებისთვის, რესურსები კონტექსტური მონაცემებით და შაბლონები გამეორებადი შაბლონების სახით (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 announcement). 2025-06-23-ზე პროექტი გადავიდა Linux Foundation-ის ქვეშ მსხვილი ტექნოლოგიური კოლაბორატორების მონაწილეობით (Google donation post; Linux Foundation launch). 2026-08-11-ის შემოწმებისას A2A დოკუმენტაციაში მითითებული იყო სპეციფიკაციის უახლესი გამოშვებული ვერსია 1.0.0 (A2A specification).
A2A-ის ძირითადი ელემენტებია Agent Card შესაძლებლობების JSON მეტამონაცემებით, ამოცანები მდგომარეობის მქონე სამუშაო ერთეულების სახით, შეტყობინებები, ნაწილები და არტეფაქტები (A2A key concepts). აგენტებს შეუძლიათ ურთიერთქმედება მოთხოვნა/პასუხით და პერიოდული გამოკითხვით, Server-Sent Events ნაკადური გადაცემით და გამომგზავნი შეტყობინებებით ხანგრძლივი სამუშაოსთვის (A2A key concepts; Google A2A announcement). დაშორებული აგენტები რჩებიან გაუმჭვირვალე: კოლაბორატორებს არ სჭირდებათ ერთმანეთის შიდა მეხსიერება, ინსტრუმენტები ან პროპრიეტარული ლოგიკა (A2A home; A2A specification).
ოფიციალური A2A რეკომენდაცია პირდაპირია: MCP გამოიყენეთ ინსტრუმენტებისთვის, A2A კი აგენტებისთვის (A2A home; A2A and MCP).
Google-ის 2026-03-18 დეველოპერის სახელმძღვანელო იმავე ხაზს ავლებს: MCP ინსტრუმენტებისა და მონაცემებისთვის, A2A აღმოჩენისა და აგენტებს შორის თანამშრომლობისთვის, მათ შორის Agent Card ცნობილ მისამართზე, მაგალითად /.well-known/agent-card.json (Developer's Guide to AI Agent Protocols).
პროტოკოლის საზღვრების რუკა
ენობრივად ნეიტრალური რუკა: MCP არის ინსტრუმენტებისა და მონაცემების ვერტიკალური საზღვარი; A2A არის ჰორიზონტალური აგენტთაშორისი საზღვარი; პირდაპირი API არის მარტივი გზა, როცა ერთი აპლიკაცია ფლობს დახურულ ინტეგრაციას.
თუ ჯერ კიდევ წყვეტთ, საკმარისია თუ არა ერთი აგენტი პროტოკოლების არჩევამდე, დაიწყეთ გვერდით მრავალი აგენტი თუ ერთი აგენტი. თუ ჯერ კიდევ ირჩევთ ჩარჩოებს და არა კავშირის პროტოკოლებს, იხილეთ ღია ჩარჩოები და ასისტენტები.
შედარების ცხრილი
როგორ წაიკითხოთ ეს ცხრილი: აირჩიეთ საზღვარი, რომელიც ემთხვევა მონაწილეებსა და მფლობელობის მოდელს, და არა ლოგო, რომელიც დემოში გამოჩნდა.
პროტოკოლის ქცევის სტრიქონები ასახავს პირველად დოკუმენტაციას, გადამოწმებულს 2026-08-11-ზე.
| განზომილება | MCP | A2A | პირდაპირი API (საკუთარი ინტეგრაცია) |
|---|---|---|---|
| დანიშნულება | ხელოვნური ინტელექტის აპლიკაციის დაკავშირება ინსტრუმენტებთან, მონაცემთა წყაროებთან და დაკავშირებულ კონტექსტთან | დამოუკიდებელ აგენტებს მისცეს აღმოჩენა, შეტყობინებების გაცვლა და ამოცანებზე თანამშრომლობა | გამოიძახოს კონკრეტული სერვისი, რომელსაც თქვენი აპლიკაცია უკვე ფლობს |
| მონაწილეები | ჰოსტი (ხელოვნური ინტელექტის აპლიკაცია), MCP კლიენტი, MCP სერვერი | მომხმარებელი, A2A კლიენტური აგენტი, A2A სერვერი (დაშორებული აგენტი) | თქვენი აპლიკაცია და სამიზნე API |
| აღმოჩენა | სერვერის შესაძლებლობების აღმოჩენა; ინსტრუმენტების, რესურსებისა და შაბლონების სია | Agent Card მეტამონაცემები (იდენტობა, უნარები, საბოლოო წერტილი, ავტორიზაციის მოთხოვნები) | თქვენი კოდი და დოკუმენტაცია; Agent Card სტანდარტი არ არის აუცილებელი |
| ტრანსპორტი | JSON-RPC მონაცემთა ფენა; stdio და Streamable HTTP (ოფციონალური SSE) | HTTP(S); JSON-RPC და სხვა მიბმები; SSE ნაკადური გადაცემა; ოფციონალური გამომგზავნი webhook-ები | რასაც API უკვე იყენებს (REST, gRPC, SDK, რიგი) |
| ამოცანის მოდელი | ინსტრუმენტის, რესურსისა და შაბლონის პრიმიტივები; ოფციონალური Tasks გაფართოება ხანგრძლივი სამუშაოს სახელურებისთვის | მდგომარეობის მქონე Task სასიცოცხლო ციკლი შეტყობინებებით, არტეფაქტებით და მრავალრაუნდიანი კონტექსტით | თქვენი საკუთარი მოთხოვნა/პასუხის ან დავალების მოდელი |
| ავტორიზაციის საზღვარი | სერვერმა და ჰოსტმა უნდა უზრუნველყონ ავტორიზაცია; უსაფრთხოების სახელმძღვანელო კრძალავს ტოკენის გატარებას და მოითხოვს მინიმალურ პრივილეგიებს | ავტორიზაციის მოთხოვნები გამოცხადებულია Agent Card-ზე; სანდო მონაცემები ჩვეულებრივ სტანდარტული HTTP სქემებით; აგენტები რჩებიან გაუმჭვირვალე | თქვენი API კარიბჭე, OAuth, სერვისის ანგარიშები და უფლებათა დიაპაზონი |
| ნაკადური გადაცემა / ხანგრძლივი სამუშაო | შეტყობინებები და პროგრესის საშუალებები; Tasks გაფართოება მდგრადი სამუშაოსთვის | შექმნილია ხანგრძლივი ამოცანებისთვის: პერიოდული გამოკითხვა, SSE ნაკადური გადაცემა, გამომგზავნი შეტყობინებები | მხოლოდ თუ თქვენ აშენებთ ასინქრონულ დავალებებსა და სტატუსის საბოლოო წერტილებს |
| მარცხის დამუშავება | ინსტრუმენტის/შესრულების შეცდომები და უსაფრთხოების მარცხის კლასები სახელმძღვანელოში; კლიენტმა უნდა დაამუშაოს გამოტოვებული შესაძლებლობები და ავტორიზაციის მარცხები | სპეციფიკაციით განსაზღვრული ამოცანის შეცდომები (not found, not cancelable, unsupported operation, content type, auth failures) პლუს ამოცანის საბოლოო მდგომარეობები | თქვენი 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, როცა ყველა შემდეგი მართალია.
- ერთი აპლიკაცია ფლობს ინტეგრაციას ბოლომდე.
- ინსტრუმენტების ზედაპირი მცირე და სტაბილურია.
- არ გჭირდებათ, რომ რამდენიმე ხელოვნური ინტელექტის ჰოსტმა (მაგალითად სამუშაო მაგიდის აპლიკაცია, IDE, საუბრის პროდუქტი და ოპერაციული აგენტი) გაიზიაროს ერთი და იგივე გადატანადი სერვერი.
- უკვე გაქვთ ავტორიზაცია, ჟურნალირება და მორიგე მხარდაჭერა ამ API-სთვის.
პროტოკოლი იმართლებს თავს, როცა აღმოჩენა, ხელახალი გამოყენება ან ჯგუფთაშორისი თავსებადობა უფრო მნიშვნელოვანია, ვიდრე კიდევ ერთი ზედაპირის დაცვისა და მონიტორინგის ღირებულება. Google-ის საკუთარი პროტოკოლების სახელმძღვანელო პრაქტიკულ წესს ასე აყალიბებს: დაამატეთ პროტოკოლები, როცა გჭირდებათ, დაიწყეთ ინსტრუმენტებისა და მონაცემების წვდომით და არა ყველა სტანდარტის პირველივე დღეს დაყენებით (Developer's Guide to AI Agent Protocols).
ჰიპოთეტური მაგალითი: ერთი მხარდაჭერის აგენტი თქვენს სერვერულ ნაწილში, რომელიც მხოლოდ განაცხადებს ქმნის თქვენს მხარდაჭერის API-ში, შეიძლება დარჩეს პირად ფუნქცია-ინსტრუმენტზე. ამ გზისთვის MCP ან A2A არ გჭირდებათ.
ჰიპოთეტური კონტრმაგალითი: იგივე განაცხადის ქმედებები ხელმისაწვდომი უნდა იყოს Claude Desktop-ისთვის, შიდა ოპერაციული აგენტისთვის და კოდირების ასისტენტისთვის. მაშინ საერთო MCP სერვერი (რეალური ავტორიზაციითა და მინიმალური პრივილეგიებით) უფრო ძლიერია, ვიდრე სამი მორგებული გარსი.
გაერთიანებული არქიტექტურა: ორივე პროტოკოლი ერთდროულად
ოფიციალური A2A დოკუმენტაცია პირდაპირ აღწერს კომპლემენტარულ ნიმუშს: აგენტურმა აპლიკაციამ შეიძლება სხვა აგენტებთან A2A-ით ისაუბროს, ხოლო თითოეულმა აგენტმა საკუთარი ინსტრუმენტები და რესურსები MCP-ით გამოიყენოს (A2A and MCP).
სასარგებლო მენტალური მოდელი:
მომხმარებელი / კლიენტური აგენტი
|
| A2A (ამოცანები, შეტყობინებები, არტეფაქტები)
v
დაშორებული სპეციალისტი აგენტი
|
| MCP (ინსტრუმენტები, რესურსები)
v
API, მონაცემთა ბაზები, ფაილები, SaaS სისტემები
A2A დოკუმენტაციის ავტოსერვისის სცენარი ამ განცალკევებას კონკრეტულს ხდის: მრავალრაუნდიანი საუბარი და მომწოდებლებთან თანამშრომლობა რჩება A2A-ზე, ხოლო დიაგნოსტიკური სკანერები და სახელმძღვანელოები არის MCP ინსტრუმენტები (A2A and MCP). ეს საზღვრის გადაწყვეტილებაა და არა ბრენდის პრეფერენცია.
დაშორებული აგენტის შეტყობინებები და ინსტრუმენტების შედეგები მაინც ეჯიბრებიან გაშვების გარემოს ყურადღებას. დააპროექტეთ მათი შენახვა და ვადის გასვლა კონტექსტის ინჟინერიის სასიცოცხლო ციკლით და არ ჩაყაროთ ყოველი დატვირთვა მოდელის ფანჯარაში.
„აგენტის“ საწარმოო მნიშვნელობისთვის დემონსტრაციულ საუბართან შედარებით იხილეთ რა არის საწარმოო AI აგენტი.
მარცხის რეჟიმები, რომლებიც აბრევიატურებზე უფრო მნიშვნელოვანია
პროტოკოლები არ აშორებს საოპერაციო მარცხს. ისინი გადაადგილებენ, სად ჩანს მარცხი.
MCP-ის მხარის მარცხის რეჟიმები
MCP უსაფრთხოების სახელმძღვანელო ტოკენის გატარებას ანტინიმუშად მიიჩნევს: სერვერები არ უნდა იღებდნენ ტოკენებს, რომლებიც თვითონ MCP სერვერისთვის არ არის გამოშვებული (MCP security best practices). იგივე სახელმძღვანელო ფარავს confused deputy რისკებს შუამავალ OAuth სქემებში, SSRF-ს მეტამონაცემების აღმოჩენისას, სესიის გატაცებას, არაუსაფრთხო ლოკალური სერვერის გაშვებას და ზედმეტად ფართო უფლებათა დიაპაზონს (MCP security best practices).
ოპერატორის შედეგები, თუ ამას უგულებელყოფთ:
- ერთი ზედმეტად ფართო უფლებების ინსტრუმენტი ხდება დაზიანების გავრცელების არეალი ყველა ჰოსტისთვის, რომელიც სერვერს დაუკავშირდა.
- აუდიტის ჟურნალები კარგავს კლიენტის ნამდვილ იდენტობას, როცა ტოკენები ბრმად გადაიგზავნება.
- „MCP ჩართულია“ იქცევა უსაფრთხოების ცრუ შეგრძნებად.
პრაქტიკული ინსტრუმენტების კონტროლისთვის ეს გვერდი დააწყვილეთ უსაფრთხო ინსტრუმენტების გამოძახებასთან ბიზნეს აგენტებისთვის და მოთხოვნის ინექციისგან დაცვასთან ინსტრუმენტიანი აგენტებისთვის.
A2A-ის მხარის მარცხის რეჟიმები
A2A ვარაუდობს, რომ დაშორებული აგენტები გაუმჭვირვალე კოლაბორატორებია და არა გამჭვირვალე ინსტრუმენტ-ფუნქციები (A2A specification). ამით სხვა მარცხის რეჟიმები იქმნება:
- ამოცანის მფლობელობის გადანაცვლება: ხანგრძლივი ამოცანა სრულდება, მარცხდება, უქმდება ან ელოდება შეყვანას, და საბოლოო მდგომარეობას არავინ ფლობს.
- შესაძლებლობების შეუსაბამობა: Agent Card-მა დაპირდა უნარი, რომელსაც დაშორებული აგენტი თქვენს ავტორიზაციაზე ან შიგთავსის ტიპებზე რეალურად ვერ ასრულებს.
- გაუმჭვირვალე გადაცემის დაკარგვა: შეზღუდვები იკარგება მრავალრაუნდიან შეტყობინებებზე, თუ კონტრაქტები სუსტია.
- ავტორიზაციის თეატრი: აღმოჩენა შედარებით საჯაროა, მაგრამ რეალური უნარების ავტორიზაცია არასრულია.
რეკომენდაცია: თუ A2A-ს შემოიღებთ, დანიშნეთ მფლობელი მთელი ამოცანის გზისთვის და არა მხოლოდ თითოეული აგენტის გამშვები მოდულისთვის. ტოპოლოგია მაინც მნიშვნელოვანია; პროტოკოლის არჩევანი არ ცვლის მრავალაგენტიანი მფლობელობის დისციპლინას.
საერთო საწარმოო მარცხის რეჟიმები
ესინი ჩნდება, MCP-ს იყენებთ, A2A-ს, ორივეს თუ არცერთს:
- არ არის ადამიანური კონტროლის წერტილები შეუქცევად ჩაწერებზე.
- არ არის შეფასება ბოლოდან ბოლომდე სამუშაო პროცესისთვის.
- არ არის კვალები, რომლებიც მოდელის გადაწყვეტილებებს ინსტრუმენტების ან დაშორებული აგენტის შედეგებთან აკავშირებს.
დააპროექტეთ ამის წინააღმდეგ საწარმოო აგენტის მარცხის რეჟიმებით და აგენტის დაკვირვებადობით.
გადაწყვეტილების შემოწმების სია
გამოიყენეთ როგორც დაშვების / უარყოფის ფილტრი რომელიმე პროტოკოლის იმპლემენტაციამდე.
- ვინ არის მეორე მხარე? სტრუქტურირებული ინსტრუმენტი ან მონაცემთა სისტემა მიუთითებს MCP-ზე ან პირდაპირ API-ზე. დამოუკიდებელი აგენტი საკუთარი მსჯელობითა და უნარებით მიუთითებს A2A-ზე.
- ვინ ფლობს ავტორიზაციასა და დაზიანების გავრცელების არეალს? თუ ავტორიზაციის საზღვარს ვერ ასახელებთ, ზედაპირი არ გახსნათ.
- სჭირდება თუ არა რამდენიმე ჰოსტს იგივე ინსტრუმენტები? დიახ - MCP-ის სასარგებლოდ. არა - პირადი API-ის ან პროცესშიდა ინსტრუმენტების სასარგებლოდ.
- სჭირდება თუ არა სხვადასხვა გუნდის ან მომწოდებლის აგენტებს შიდა მოწყობის გაზიარების გარეშე თანამშრომლობა? დიახ - A2A-ის სასარგებლოდ. არა - ერთი აგენტის ინსტრუმენტებით სასარგებლოდ.
- არის თუ არა სამუშაო ხანგრძლივი სტატუსით, არტეფაქტებით ან ადამიანის მოლოდინის მდგომარეობებით? A2A შექმნილია ასეთი კლასის ამოცანებისთვის. MCP-ს შეუძლია ხანგრძლივი სამუშაო გაფართოებებითა და შეტყობინებებით, მაგრამ ის მაინც ინსტრუმენტის/კონტექსტის პროტოკოლია და არა თანაბარუფლებიანი აგენტების ქსელი.
- შეგიძლიათ დააკვირდეთ და გააუქმოთ სამუშაო? თუ გზის ჟურნალირება, გაუქმება ან შეჩერება შეუძლებელია, პროტოკოლის არჩევანი ნაადრევია.
- ხელმისაწვდომია თუ არა უფრო მარტივი გზა? უპირატესობა მიანიჭეთ ყველაზე თხელ საზღვარს, რომელიც მოთხოვნას აკმაყოფილებს.
ხშირი კითხვები
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). ჩარჩოები აირჩიეთ პროტოკოლის საზღვრებისგან ცალკე.
შემდეგი ნაბიჯი
ქაღალდზე დახაზეთ ერთი სამუშაო პროცესი:
- რომელი სისტემებია ინსტრუმენტები ან მონაცემთა წყაროები;
- რომელი მონაწილეებია დამოუკიდებელი აგენტები;
- რომელი ქმედებებია შეუქცევადი და საჭიროებს ადამიანურ კონტროლის წერტილებს;
- ვინ ფლობს ავტორიზაციას, ჟურნალებსა და გაუქმებას.
შემდეგ ამ საზღვრებიდან აირჩიეთ MCP, A2A, პირდაპირი API ან კომბინირებული სტეკი.
თუ გინდათ დახმარება, რომ ეს რუკა კონტროლირებად საწარმოო გზად გადაიქცეს, ისაუბრეთ Dali-სთან გადაწყვეტილებებზე. მოიტანეთ სამუშაო პროცესი, აღრიცხვის სისტემები და დამტკიცების წესები - არა პრეფერირებული პროტოკოლის ბრენდი.