Agentní dovednosti patří do spravované vrstvy, ne do každé aplikace zvlášť

TL;DR:

• Když tým staví více AI agentů, ruční kopírování instrukcí a postupů mezi projekty se rychle mění v provozní dluh.
• Nový vzor v .NET ukazuje, že agentní dovednosti mohou být publikované centrálně přes MCP server pro sdílení kontextu a schopností.
• Praktický přínos není v samotné knihovně, ale v tom, že pravidla, playbooky a pracovní postupy může spravovat jeden odpovědný tým.
• Centralizace dovedností dává smysl jen tehdy, když máš vyřešené verze, přístupová práva, audit změn a lidskou kontrolu citlivých kroků.
• První dobrý kandidát není všechno, co agent umí, ale opakovaný interní postup, který dnes žije v dokumentech, šablonách nebo hlavách lidí.

Představ si malý tým, který má tři různé AI agenty. Jeden pomáhá s analýzou dat, druhý připravuje podklady pro schvalování nákladů a třetí kontroluje, jestli výstup odpovídá interním pravidlům. Na začátku stačí zkopírovat stejný postup do každého projektu. Po pár týdnech ale někdo upraví pravidla schvalování, jiný přidá novou kontrolu a třetí agent pořád jede podle staré verze.

Tady začíná skutečný problém agentské práce. Nejde jen o to, jak chytrý je model nebo jak dobře je napsané zadání. Jde o to, kde žijí znalosti, postupy a pravidla, podle kterých agent pracuje. Pokud jsou přibalené ke každé aplikaci zvlášť, budeš je dřív nebo později spravovat ručně.

Microsoft Agent Framework teď pro .NET ukazuje konkrétní technický směr: agentní dovednosti se dají objevovat a načítat přímo z Model Context Protocol serveru, zkráceně MCP serveru. MCP je protokol pro sdílení kontextu a schopností mezi nástroji a AI systémy. V praxi to znamená, že agent nemusí mít každý balíček schopností přibalený lokálně. Může se připojit k serveru, zjistit dostupné dovednosti a načíst tu, kterou pro daný úkol potřebuje.

Znalosti pro agenty se oddělují od aplikace

Agentní dovednost je balíček instrukcí, zdrojů a případně skriptů, který agentovi přidává konkrétní schopnost. Může jít o postup pro kontrolu výdajů, analýzu dat, práci s interním formulářem nebo ověření, zda dokument splňuje daná pravidla.

Důležitý posun je v místě správy. Místo aby každá aplikace nesla vlastní kopii dovednosti, centrální tým ji publikuje na serveru. Agent se k němu připojí, uvidí stručný seznam dostupných dovedností a podrobnosti si stáhne až ve chvíli, kdy je opravdu potřebuje. Zdroj popisuje discovery dokument na adrese skill://index.json, tedy index dostupných dovedností, který server agentovi nabízí.

Pro samostatného vývojáře to může znít jako detail implementace. Pro tým, který má víc agentů v různých interních nástrojích, je to ale organizační změna. Firemní know-how se přestává šířit kopírováním složek a začíná se chovat jako spravovaná vrstva.

Kde centralizace pomůže nejrychleji

Nejlepší první kandidát je postup, který se často opakuje a zároveň se občas mění. Typicky pravidla pro schvalování nákladů, kontrolní seznam pro soulad s interními pravidly nebo playbook pro analýzu dat. Pokud ho máš dnes ve sdíleném dokumentu, v šabloně nebo jako dlouhé zadání pro chatbot, je to signál, že by mohl existovat jako agentní dovednost.

Příklad: operations tým spravuje postup pro kontrolu dodavatelských faktur. Agent v účetním nástroji ho používá při předběžné kontrole, jiný agent v týmovém chatu podle něj odpovídá na dotazy a třetí agent pomáhá připravit podklady pro schválení výjimky. Když se pravidlo změní, nechceš hledat tři místa v kódu a doufat, že všude proběhlo nové nasazení aplikace.

Centrální publikování dovednosti tento problém zmenšuje. Jeden odpovědný tým upraví postup na serveru a připojení agenti si novou verzi načtou při další fázi objevování dostupných dovedností. To neznamená, že změna má jít rovnou do produkce bez kontroly. Znamená to, že distribuční mechanismus přestane být hlavní překážkou.

Forma balíčku je také provozní rozhodnutí

.NET implementace popsaná ve zdroji podporuje dvě cesty. První je dovednost publikovaná jako SKILL.md a související zdroje. Server je vystaví jako jednotlivé MCP zdroje a framework je načítá podle potřeby. Druhá cesta je archivovaný balíček dovednosti, například ZIP, TAR nebo gzip komprimovaný TAR, který se stáhne a rozbalí do řízeného místního adresáře.

To není jen technická volba. U menší dovednosti, kde chceš dobře vidět jednotlivé soubory a změny, dává smysl publikování po zdrojích. U většího balíčku s více soubory, testovacími daty nebo pevnou strukturou může být praktičtější archiv. Citlivý obsah, větší objem dat a potřeba auditu změn by měly rozhodovat stejně silně jako pohodlí vývojáře.

Malý tým si může položit jednoduchou otázku: potřebujeme tuto dovednost číst, verzovat a kontrolovat po částech, nebo ji chceme brát jako jeden ucelený balíček? Odpověď ovlivní nejen implementaci, ale i to, kdo změny schvaluje a jak se bude hledat příčina chyby.

Řízení změn je důležitější než snadné načítání

Centrální server s dovednostmi může svádět k představě, že governance je vyřešená. Slovo governance raději přeložme konkrétněji: jde o pravidla odpovědnosti, přístupu, verzování a kontroly změn. Samotné načítání dovedností přes server nic z toho automaticky nezaručuje.

Pokud agent pracuje s finančním schvalováním nebo kontrolou souladu s pravidly, musí být jasné, kdo dovednost upravil, kdy se změna dostala k agentům a co přesně se změnilo. Potřebuješ oddělit testovací a produkční verzi. Potřebuješ vědět, kteří agenti mají k dané dovednosti přístup. A u citlivých rozhodnutí potřebuješ místo, kde člověk výsledek zkontroluje, než se podle něj něco provede.

Praktická hranice je jednoduchá: agent může připravit návrh, vyhledat nesoulad nebo doporučit další krok. Odpovědnost za výjimku, zamítnutí, finanční dopad nebo zásah do práv člověka musí zůstat u určené osoby. Centralizovaná dovednost má člověku dát konzistentní podklad, ne schovat rozhodnutí do automatizace.

Začni jedním postupem, který dnes bolí

Pokud stavíš nebo plánuješ více agentů, neřeš nejdřív univerzální katalog všech schopností. Vyber jeden postup, který se opakuje napříč nástroji a kde už dnes vznikají rozdíly mezi verzemi. Sepiš, kdo ho vlastní, jak se mění, kdo ho smí použít a kde má být lidská kontrola.

Pak rozhodni, jestli má dovednost žít jako několik čitelných zdrojů, nebo jako archivovaný balíček. Přidej minimální pravidla pro verze: co je testovací verze, co je schválená verze a jak poznáš, který agent použil kterou variantu. Teprve potom dává smysl řešit konkrétní knihovnu a napojení.

Hlavní změna není v tom, že agent dostane další schopnost. Hlavní změna je v tom, že schopnosti agentů začneš spravovat jako společnou pracovní infrastrukturu. To je méně efektní než ukázka nového agenta, ale pro reálný provoz mnohem důležitější.

Zdroj

Semantic Kernel / Microsoft Agent Framework: Discover Agent Skills from MCP servers in .NET https://devblogs.microsoft.com/agent-framework/?p=5599