უნარებისა და MCP-სერვერების კატალოგები: რომ გუნდმა ერთი და იგივე ორჯერ არ ააშენოს

ორ კვირაში რამდენიმე სიახლე გამოვიდა ერთსა და იმავეზე: როგორ შევინახოთ AI-ინსტრუმენტების ინსტრუქციები და კავშირები ისე, რომ მთელმა გუნდმა ერთი შემოწმებული ვერსია აიღოს. Camunda-მ მოწონებული ბლოკების კატალოგი გამოუშვა, Workato-მ აჩვენა MCP-სერვერი, რომელიც თავს თვითონ ანახლებს, HubSpot-მა და Google-მა კი უნარები (skills) დაწვრილებით გაარჩიეს. ბიზნესის მფლობელისთვის კითხვა მარტივია: კომპანიაში ვისთან ინახება „როგორ ვაკეთებთ ამას“ და ვინ აგებს პასუხს, როცა ეს იცვლება.

რა გამოვიდა

Camunda-მ 21 ოქტომბერს აღწერა Catalog Camunda Hub-ში გამოგონილი ბანკის მაგალითზე. ორგანიზაციას ერთი კატალოგი აქვს, და მასში კომპეტენციების ცენტრი შემოწმებულ ბლოკებს აქვეყნებს: მოთხოვნა საკრედიტო ბიუროში, პიროვნების შემოწმება, სანქციების სიებით შემოწმება, კლიენტის შეტყობინება. გუნდები ბლოკს პროცესების რედაქტორის მენიუდან იღებენ და მის წინ და მის შემდეგ საკუთარ ნაბიჯებს ამატებენ. ბლოკის სასიცოცხლო ციკლი git-ში ცხოვრობს: კომიტი, შემოწმება, ვერსია, შემდეგ CI მას კატალოგში აქვეყნებს. კომპეტენციების ცენტრი ხედავს, რომელი პროექტი რომელ ვერსიაზეა, და ბლოკის მიმოქცევიდან გამოყვანამდე იცის, ვის შეეხება. ფუნქცია Camunda 8.10-ით გამოდის.

Workato-მ 20 ოქტომბერს მოგვიყვა თავის MCP-სერვერზე Google Workspace-ისთვის. Google-ის შვიდი აპლიკაცია (Gmail, Drive, Calendar, Docs, Sheets, Slides და Contacts) ერთი ინსტრუმენტით არის ხელმისაწვდომი ორი დამხმარით, შვიდი სერვერის ნაცვლად, რომელთა ათობით აღწერა მოდელის კონტექსტში იდება. ათასზე მეტი მოქმედება სერვერის მხარეს ინახება და ფრაზით შეირჩევა, ჯაჭვში მოდელის გარეშე. დღეში ერთხელ სერვერი Google-ის კატალოგს გადის, სადაც ყველა ენდპოინტია აღწერილი, ახალ შესაძლებლობას სენდბოქსში სატესტო ანგარიშზე ატარებს, შემდეგ კი სამი მოდელი მოსამართლის, ოპონენტისა და არბიტრის როლებში წყვეტს, გამოუშვან თუ არა.

HubSpot-მა 14 ოქტომბერს გამოაქვეყნა გარჩევა, რით განსხვავდება უნარები, პლაგინები და MCP-კონექტორები Claude-ში. ფორმულა მარტივია: კონექტორი გარე სერვისზე წვდომაა, უნარი სიტყვებით აღწერილი პროცედურაა, პლაგინი კი შეფუთვაა მთელი გუნდისთვის. უნარი კონექტორის გარეშეც მუშაობს, მაგრამ ცოცხალ მონაცემებს ვერ ხედავს.

Google-მა 13 ოქტომბერს განაახლა უნარების გაშვების ვადები: Gemini-ის აპლიკაციაში უნარები 13 ოქტომბრიდან ნოემბრის შუა რიცხვებამდე ვრცელდება, Workspace-ში უნარები კი, რომლებიც 12 ოქტომბრისთვის იყო დაპირებული, ახალი თარიღის გარეშე გადაიდო. ეს იმ კითხვას ეხება, ღირს თუ არა გუნდის სამუშაო პროცესის აშენება ფუნქციაზე, რომელსაც ჯერ თარიღიც არ აქვს.

Red Hat-მა 16 ოქტომბერს MCP-კარიბჭის გამოსვლა გამოაცხადა Connectivity Link 1.5-ის შემადგენლობაში: კარიბჭისა და სერვერების იზოლაცია გუნდებს შორის, მდგომარეობის გარეშე სესიები, პრომპტებისა და რესურსების მხარდაჭერა, MCP-ის შემზღუდველები. ეს კორპორაციული მასშტაბია, მაგრამ არსი იგივეა: ვიღაცამ უნდა მართოს, რომელ ინსტრუმენტებზე აქვს აგენტს წვდომა.

რისთვის სჭირდება ეს ბიზნესს

ავიღოთ მანქანების გაქირავება სამი მენეჯერით. თითოეულს Word-ში ხელშეკრულების საკუთარი შაბლონი აქვს, კლიენტისთვის წერილის საკუთარი ტექსტი და საკუთარი შეხსენება, რა შეამოწმოს მანქანის დაბრუნებისას. როცა დაზღვევის ფასი იცვლება, მას სამიდან მხოლოდ ერთ შაბლონში ასწორებენ. ეს არის „ერთი და იგივის სამჯერ აშენება“, უბრალოდ AI-ის გარეშე.

სიახლეებში აღწერილი კატალოგი იმავე პრობლემას წყვეტს: ერთი შემოწმებული ვერსია, მას ჰყავს მფლობელი, ცვლილებას აქვს წესი. თავად ინსტრუმენტი ამას არ იძლევა. უნარების საქაღალდე, რომელშიც ყველა იმას დებს, რასაც უნდა, ნახევარ წელიწადში იმავე სამ შაბლონად იქცევა. დასკვნა: კატალოგის შექმნა მაშინ ღირს, როცა ყოველ ჩანაწერს პასუხისმგებელი ჰყავს და გასაგებია, როგორ შეიცვალოს.

როგორ არის ეს ჩემთან

აშშ-ში PDR-კომპანიაში, სადაც 2021 წლიდან ტექნიკური პარტნიორი ვარ, პროექტებს სამნი ვათანხმებთ: მფლობელი, მეორე მუდმივი დეველოპერი და მე. შემდეგ ყოველ პროექტს თავისი მფლობელი ჰყავს. მეორე დეველოპერი AppSheet-ს უძღვება, ჩემზეა სერვერი, ქსელი, ტელეფონია, API და საიტი. კატალოგი, როგორც პროდუქტი, არ გვაქვს, მაგრამ პრინციპი იგივეა: ყოველ ნაწილს ჰყავს ადამიანი, რომელიც მის ვერსიაზე აგებს პასუხს.

იმ ინსტრუმენტების წესები, რომლებიც კოდის წერაში მეხმარება, მოსახერხებელია კოდის გვერდით ინახებოდეს, იმავე რეპოზიტორიში, როგორც დოკუმენტაცია. მაშინ ისინი დამკვეთს კოდთან და ბაზასთან ერთად გადაეცემა, და სისტემის გაგრძელება სხვა დეველოპერსაც შეუძლია. ჩემს საიტზე 2026 წლის ოქტომბერში llms.txt და AI-ასისტენტებისთვის ფაქტების გვერდი დავამატე, რომ ასისტენტმა არ მოიგონოს, რას ვაკეთებ და რა პირობებით. ეფექტის ციფრები არ მაქვს.

Upwork-ზე Google Sheets-ის გარშემო შეკვეთებს შორის, 2021–2025 წლებში, კატალოგის სრულიად პრაქტიკული ვერსიაც იყო: მზა ცხრილების შაბლონების გადატანა ახლებში, 2022-დან 2025 წლამდე. შაბლონი იგივე შემოწმებული ბლოკია, და კითხვა ყოველთვის ერთია: რომელი ვერსიაა სწორი.

Workato და Camunda ჩემთან არ შემიმოწმებია. MCP-სერვერს, რომელიც თავს თვითონ ანახლებს, მხოლოდ ჟურნალით დავაყენებდი: რა და როდის დაამატა თვითონ და ვინ გადახედა ამას.

რას გავაკეთებდი

დავიწყებდი სიით: რომელ ინსტრუქციებს, შაბლონებსა და კავშირებს იყენებს გუნდი ყოველდღე.

ყოველ ჩანაწერს დავუნიშნავდი მფლობელსა და შენახვის ადგილს: ტექნიკური საკითხებისთვის git, გუნდის ინსტრუქციებისთვის საერთო დოკუმენტი ცვლილებების ისტორიით.

HubSpot-ის გარჩევის მსგავსად, წვდომასა და პროცედურას გავმიჯნავდი: CRM-თან კავშირი და წესი „როგორ ვაფორმებთ განაცხადს“ სხვადასხვა სიჩქარით იცვლება.

ახალ ჩანაწერს რეალურ განაცხადზე შემოწმებით გავატარებდი, როგორც Workato ატარებს canary-შემოწმებას სენდბოქსში. კვარტალში ერთხელ ვნახავდი, კატალოგში რას აღარავინ იყენებს, და ამოვიღებდი.

დაკავშირებული მასალები

როგორ აღვწეროთ პროცესის წესები თანამშრომლებისა და ინსტრუმენტებისთვის, სტატიაში ბიზნეს-ლოგიკა: წესები, სტატუსები და უფლებები გავარჩიე. მიდგომა: AI პროცესში, სადაც შედეგის შემოწმება შეიძლება და პროცესის ავტომატიზაცია განაცხადიდან შემდეგ მოქმედებამდე. ქეისები: აშშ-ის PDR-კომპანიის ტექნიკური პარტნიორი და Google Sheets და Apps Script: შეკვეთები Upwork-ზე. იმავე თემაზე: როგორ ვინაწილებ სამუშაოს AI-აგენტთან, რატომ ვაშენებ უფასო ინსტრუმენტებზე და რის უფლებას ვაძლევ აგენტს პროდაქშენ სერვერზე. ადრე: სად იწყება მზა კონექტორთან პროცესის ლოგიკა. თუ თქვენი გუნდის ინსტრუქციები და შაბლონები სამ ადგილას ცხოვრობს, მომიყევით, რომელი იცვლება ყველაზე ხშირად. ამოცანის განხილვა.