Tři způsoby, jak agent přesahuje sám sebe: Tools, MCP a A2A

Jazykový model sám o sobě produkuje jen text. Vše, co agent dělá nad rámec toho — prohledávání webu, dotazování databáze, provedení obchodu, delegování úlohy jinému systému — se děje proto, že něco rozšiřuje agenta za pouhé generování textu. Existují tři odlišné mechanismy, jak toho dosáhnout, a pochopení rozdílů mezi nimi je jeden z prakticky nejužitečnějších kousků architektury v celém oboru, protože zvolit ten špatný pro danou úlohu vytváří pozdější reálnou komplexitu.

Tools: dosah v procesu

Nástroj (tool) je diskrétní, atomická funkce, kterou agent může v kontextu zavolat, aby rozšířil své schopnosti — vyhledávání na webu, čtení souboru, dotaz do databáze. Definičním rysem nástroje je, že běží in-process: kód funkce žije uvnitř stejné aplikace jako runtime agenta, takže jeho zavolání je jediný skok bez protokolové hranice k překročení. Stojí za to být přesný v tom, co "in-process" znamená a co ne: tělo funkce nástroje má naprostou volnost provést uvnitř sebe odchozí síťové volání — třeba zavolat na API počasí — aniž by se tím z něj stal druhý mechanismus, MCP. Co dělá z něčeho přímý nástroj, a ne nástroj vystavený přes MCP, je to, kdo vlastní procesní hranici a schéma, ne to, zda se podkladová práce náhodou dotýká sítě.

MCP: dosah mimo proces, přes protokol

Model Context Protocol (MCP) rozšiřuje agenta mimo proces: samostatný program vystavuje nástroje přes standardní protokol, objevované dynamicky za běhu místo natvrdo zakódované předem. Zatímco přímé volání nástroje je jeden skok, volání přes MCP typicky zahrnuje čtyři: model vydá volání nástroje, host pošle JSON-RPC požadavek na MCP server, tento server odvede skutečnou práci a výsledek putuje zpět stejnými dvěma skoky obráceně. Každý z těchto dodatečných skoků je skutečný okruh — praktická cena protokolové hranice, kterou MCP zavádí. Co tato hranice na oplátku dává, je také reálné: nástroje objevované dynamicky při startu session místo zakompilované do aplikace a oprávnění vymezená per server, takže dosah agenta lze rozšířit bez rekompilace čehokoliv nebo udělení plošného přístupu ke všemu, co server náhodou vystavuje.

A2A: dosah do strany, k jinému agentovi

Protokol Agent2Agent (A2A) umožňuje jednomu agentovi delegovat úlohu jinému agentovi, postavenému na zcela odlišném frameworku, aniž by kterákoliv strana musela cokoliv vědět o vnitřní implementaci té druhé. Zatímco Tools i MCP oba dosahují "dolů" — agent rozšiřující sám sebe o schopnost — A2A dosahuje "do strany", k peeru. Mechanika stojí na dvou primitivech, které stojí za to znát podle jména: Agent Card je JSON dokument pro objevování, servírovaný na konvenční adrese, který funguje jako digitální vizitka agenta — co umí, kam posílat požadavky, jak se autentizovat. Agent Skill popisuje jednu konkrétní schopnost, ve které je agent dobrý — jednotku, se kterou Host Agent porovnává při rozhodování, kterému Remote Agentovi práci předat. Paralela s MCP stojí za explicitní vyslovení: MCP server inzeruje své nástroje, aby je host mohl objevit a zavolat; A2A Agent Card inzeruje skills celého agenta, aby ho jiný agent mohl objevit a delegovat na něj.

Volba mezi těmi třemi

V praxi je volba málokdy obtížná, jakmile je rozdíl jasný. Pokud je schopnost něco, co vlastní vaše vlastní aplikace a může to provést in-process, přímý nástroj je nejjednodušší a nejrychlejší. Pokud schopnost žije za samostatným systémem, který by měl být objevitelný a vyměnitelný bez redeployování vašeho agenta, MCP je správný tvar — a v podnikovém prostředí je MCP obvykle správnou hranicí kdekoliv agent překračuje hranici vlastnictví systému, protože oprávnění a audit se vynucují na hranici protokolu. A pokud samotná jednotka práce patří jinému autonomnímu agentovi, A2A je to, co vám umožní na něj delegovat jako na peera, místo abyste ho neohrabaně zabalili, jako by to byla prostá funkce.