A Microsoft AutoGen karbantartási módba kerül: mi lesz a Microsoft ügynök-keretrendszereivel?

A Microsoft félreérthetetlenül lezárt egy korszakot: az AutoGen, a cég nyílt forráskódú, több AI-ügynököt összehangoló keretrendszere új funkciót már nem kap, a gondozását pedig a közösség veszi át. Az AutoGen karbantartási mód a projekt GitHub-oldalán olvasható közlemény szerint annyit jelent, hogy a jövőben csak hibajavítások, biztonsági javítások és dokumentációs frissítések várhatók, az új projekteknek pedig a cég már a Microsoft Agent Frameworköt ajánlja. Aki az elmúlt két évben AutoGenre építette az első ügynökös prototípusát vagy egy élesben futó belső eszközét, annak most döntenie kell arról, hogy marad, átköltözik vagy egészen más irányba indul.

A döntést nem könnyíti meg, hogy a Microsoftnak közben több ügynökös terméke is van: az Agent Framework a fejlesztőknek szól, a Copilot Studio a kódot nem író üzleti felhasználóknak, a kettő között pedig ott a Microsoft 365 Copilot a maga beépített ügynökeivel. A 2026. szeptember 22-i állapot szerint sorra vesszük, mi történt pontosan, mit hozott az Agent Framework szeptember 18-án kiadott 1.19-es verziója az MCP-munkamenetek és a biztonsági korlátok terén, mikor jobb választás egy Microsoft 365-ös cégnek a Copilot Studio és mikor egy nyílt eszköz. A végén kapsz egy migrációs tervet is, amellyel a váltás nem hétvégi tűzoltás lesz, hanem nyugodt, mérhető projekt.

Röviden

• Az AutoGen a GitHub-oldalán közzétett közlemény szerint karbantartási módba került: új funkciót nem kap, közösségi gondozásba kerül, a meglévő telepítések viszont továbbra is működnek, így sürgős teendő elsősorban az ügyféladatot kezelő ügynököknél van.
• A lemaradás már most látszik: a PyPI adatai szerint az autogen-agentchat csomag utolsó kiadása a 2025. szeptember 30-i 0.7.5-ös verzió, így az új modellfunkciók és protokollváltozások hónapról hónapra nagyobb szakadékot nyitnak.
• A Microsoft hivatalos utódja a nyílt forráskódú, MIT-licences Microsoft Agent Framework, amely 2026. április 2-án érte el az 1.0-s verziót és egyetlen fejlesztőkészletben egyesíti az AutoGen és a Semantic Kernel örökségét.
• A Python-csomag 2026. szeptember 18-i 1.19.0-s kiadása az MCP-kéréseket és -munkameneteket a hívó identitásához köti, hívásonként külön munkamenetet nyit, a skill-archívumokat ZIP-formátumra korlátozza és ellenőrzi a lenyomatukat, az MCP sampling visszahívást pedig elavultnak jelöli.
• Egy Microsoft 365-öt használó KKV-nál a belső, munkatársaknak szóló ügynökökre gyakran a Copilot Studio a gyorsabb út, mert a Microsoft 365 Copilot-licenccel rendelkező felhasználók ezeknél nem terhelik a kreditkeretet, nyilvános vagy egyedi logikájú ügynöknél viszont az Agent Framework vagy egy n8n-alapú megoldás jellemzően rugalmasabb.
• A migrációt leltárral, tesztkészlettel és párhuzamos futtatással érdemes végezni, egy képzeletbeli, három ügynökből álló rendszer átköltöztetése saját becslésünk szerint nagyjából 60 fejlesztői órát és hat naptári hetet vesz igénybe.

Mit jelent az AutoGen karbantartási mód a meglévő telepítéseknek?

Az AutoGen karbantartási mód azt jelenti, hogy a keretrendszer továbbra is letölthető és működik, de új funkciót nem kap, a támogatása pedig a közösségre száll át. Rövid távon tehát semmi nem áll le, hosszabb távon viszont minden hónappal nő a lemaradás a modellek, a protokollok és a biztonsági elvárások fejlődéséhez képest.

Az AutoGen GitHub-tárhelyének nyitóoldalán ma ez a mondat fogad (saját fordításunkban): „Az AutoGen mostantól karbantartási módban van. Nem kap új funkciókat vagy fejlesztéseket, a jövőben pedig a közösség kezeli.” A közlemény azt is jelzi, hogy a támogatási csatornákon a válaszok korlátozottak lehetnek, a projekt a továbbiakban csak hibajavításokat, biztonsági javításokat és dokumentációs fejlesztéseket kap. Az új projekteknek a Microsoft kifejezetten a Microsoft Agent Frameworköt ajánlja, amelyet ugyanitt „az AutoGen vállalati használatra kész utódjaként” mutat be, stabil API-kkal és hosszú távú támogatási vállalással.

Az AutoGen a Microsoft Research műhelyéből indult, majd gyorsan a több ügynökös rendszerek egyik legismertebb kísérleti terepe lett. A 2025 elején megjelent 0.4-es újraírás eseményvezérelt magot és egy magasabb szintű, csapatokba szervezett ügynököket kezelő réteget hozott, a projekt egyik alapítói köre pedig már korábban AG2 néven saját közösségi ágat indított a régebbi, 0.2-es API-ra építve. A hivatalos Microsoft-vonal fejlődése viszont a PyPI kiadási története szerint gyakorlatilag egy éve megállt: az autogen-agentchat csomag legutóbbi kiadása a 0.7.5-ös, amely 2025. szeptember 30-án jelent meg, vagyis egy nappal azelőtt, hogy az Agent Framework első nyilvános előzetes kiadása megjelent.

Mi történik a meglévő kóddal a gyakorlatban?

A jó hír az, hogy egy telepített, rögzített verziójú AutoGen-alkalmazás holnap reggel ugyanúgy elindul, mint ma. A karbantartási mód nem kapcsolja ki a szervereket és nem töröl csomagokat a PyPI-ről, a kód tehát addig működik, amíg a környezete nem változik. Csakhogy egy AI-ügynök környezete folyamatosan változik, ezért a gondok jellemzően négy irányból érkeznek.

• Függőségek elsodródása. Az ügynök mögött ott van a modellszolgáltató Python-csomagja, a HTTP-kliens, a Python-verzió és az operációs rendszer. Ha ezek frissülnek, egy nem fejlesztett keretrendszer előbb-utóbb összeakad velük, a hibát pedig már te javítod, nem a Microsoft.
• Hiányzó modellfunkciók. A Microsoft AutoGenről szóló migrációs útmutatója (utolsó frissítés: 2026. augusztus 25.) maga írja, hogy az AutoGenben nem érhető el sem az OpenAI, sem az Azure OpenAI Responses API-ja, amelyre az újabb ügynökös funkciók jó része épül.
• Protokollváltozások. Az MCP (Model Context Protocol) az a nyílt szabvány, amelyen keresztül az AI-ügynökök külső eszközöket és adatforrásokat érnek el. A 2026. július 28-i MCP-specifikáció állapotmentes működésre vált, megszünteti a korábbi kézfogást és az Mcp-Session-Id fejlécet, a régi HTTP+SSE átvitelt pedig 12 hónapos átmenettel elavultnak jelöli. Egy új funkciót már nem kapó keretrendszer ezt a váltást várhatóan nem fogja lekövetni.
• Lassabb biztonsági reakció. A biztonsági javítás ígéret marad, de közösségi kézben és korlátozott válaszidővel, ami egy ügyféladatot kezelő ügynöknél kényelmetlen kockázat.

Háromféle AutoGen-telepítés, háromféle sürgősség

Nem minden AutoGen-projekt egyformán sürgős. Egy tavalyi hackathonon összerakott notebookkal semmi dolgod, egy ügyfélportál mögött futó ügynökkel viszont igen. Az alábbi táblázat a saját javaslatunkat mutatja arra, hogyan sorold be a meglévő telepítéseidet.

Aki a harmadik sorba tartozik, annak nem érdemes a tökéletes pillanatra várnia, mert a kockázat nem egy nagy bejelentéssel érkezik, hanem apránként, egy-egy el nem végzett frissítés formájában.

Mi az a Microsoft Agent Framework és miért egységesít a Microsoft?

A Microsoft Agent Framework (MAF) a Microsoft nyílt forráskódú, .NET-re és Pythonra készült fejlesztőkészlete AI-ügynökök és több ügynökből álló munkafolyamatok építésére, amely az AutoGen és a Semantic Kernel közös utódja. A Microsoft azért egységesít, hogy a két párhuzamos keretrendszer helyett egyetlen, hosszú távon támogatott alapra építsenek a fejlesztők.

A Microsoftnál évekig két ügynökös keretrendszer élt egymás mellett. Az AutoGen volt a kutatói, kísérletező vonal, amely a több ügynökös együttműködés mintáit (csoportos beszélgetés, menedzserügynök, egymásnak átadott feladatok) tette népszerűvé. A Semantic Kernel volt a vállalati vonal, amely a .NET-es cégeknél a stabil integrációért, a telemetriáért és a bővítményrendszerért felelt. Egy fejlesztőcsapatnak így gyakran úgy kellett választania, hogy vagy az izgalmasabb mintákat kapja meg, vagy a nyugodtabb üzemeltetést.

A Microsoft Agent Framework 1.0-s verzióját bejelentő, 2026. április 3-i Microsoft-blogbejegyzés szerint az új keretrendszer a Semantic Kernel vállalati alapjait és az AutoGen innovatív orkesztrációs mintáit egyesíti egyetlen nyílt forráskódú fejlesztőkészletben. Az 1.0 a bejegyzés megfogalmazásában éles használatra szánt kiadás stabil API-kkal és hosszú távú támogatási vállalással. A csomag .NET-hez a NuGeten (Microsoft.Agents.AI), Pythonhoz a PyPI-n (agent-framework) érhető el, gyári csatlakozói pedig a Microsoft Foundryhoz, az Azure OpenAI-hoz, az OpenAI-hoz, az Anthropic Claude-hoz, az Amazon Bedrockhoz, a Google Geminihez és az Ollamához kapcsolódnak. Ugyanez a sors jutott a Semantic Kernelnek is: a GitHub-oldala ma azzal nyit, hogy a Semantic Kernelből Microsoft Agent Framework lett, amely a vállalati használatra kész utódja.

Milyen gyorsan fejlődik az Agent Framework?

A tempó az, ami egy AutoGen-felhasználót leginkább meglephet. A hivatalos változásnapló szerint a Python-csomagból az 1.0.0 (április 2.) és az 1.19.0 (szeptember 18.) között 169 nap alatt 25 újabb kiadás jelent meg, ami átlagosan nagyjából hetente egy verziót jelent. Ez jó hír, mert a hibák és a biztonsági rések gyorsan javulnak, de fegyelmet is kíván, mert a változásnapló az 1.x ágon belül is tételesen jelöli a visszafelé nem kompatibilis, [BREAKING] címkéjű változásokat. Az 1.19.0-ban például négy ilyen tétel szerepel, ezek közül egy béta állapotú csomagot érint.

Fontos apróság, hogy a Python és a .NET változat külön számozást követ. Ugyanazon a napon, 2026. szeptember 18-án jelent meg a Python 1.19.0 és a .NET 1.22.0, a .NET 1.19.0 pedig már augusztus 22-én kijött, egészen más tartalommal. Ha tehát a fejlesztőd vagy a beszállítód azt mondja, hogy „már az 1.19-en vagyunk”, érdemes visszakérdezni, melyik nyelvi változatról beszél.

Hol a helye a Copilot Studiónak és a Foundrynak?

A Microsoft ügynökös kínálata 2026 őszén négy jól elkülönülő rétegből áll, a félreértések nagy része pedig abból fakad, hogy ezeket egy kalap alá veszik. Az alábbi áttekintés a saját összefoglalásunk a hivatalos dokumentációk alapján.

A rétegek nem zárják ki egymást. Az Agent Framework 1.0-s bejelentése szerint a keretrendszerrel épített ügynökök a Microsoft Foundryn felügyelt szolgáltatásként vagy Azure Durable Functionsként is futtathatók, a változásnapló pedig egy külön Copilot Studio-integrációs csomagot (agent-framework-copilotstudio) is jegyez, amellyel egy Copilot Studióban összerakott ügynök kódból is meghívható. Egy KKV-nál ez a gyakorlatban azt jelenti, hogy nem kell egyszer és mindenkorra dönteni: a munkatársaknak szóló egyszerű ügynök maradhat a Copilot Studióban, a bonyolultabb, ügyféladatot kezelő logika pedig futhat Agent Frameworkben.

Agent Framework 1.19: MCP-munkamenet hatókör és biztonsági korlátok

Az Agent Framework Python-csomagjának 2026. szeptember 18-án megjelent 1.19.0-s kiadása elsősorban biztonsági és elszigetelési változásokat hozott: az MCP-kérések és -munkamenetek a hívó identitásához kötődnek, minden hívás saját munkamenetet kap, a letölthető skill-csomagokat pedig ellenőrzött ZIP-archívumokra korlátozták. Ez nem látványos funkció, de egy ügyféladatot kezelő ügynöknél pontosan ez számít.

Kezdjük az alapfogalommal. Az MCP-munkamenet az a kapcsolat, amelyen keresztül az ügynök egy MCP-szerverrel (például egy CRM-et, számlázót vagy fájltárat kiszolgáló eszközzel) beszélget, a hatókör pedig azt határozza meg, kié ez a kapcsolat és meddig él. Ha a munkamenet túl tágan van értelmezve, előfordulhat, hogy egy korábbi hívás kapcsolata egy későbbi, más felhasználótól érkező hívásnál is használatban marad. Egy egyfelhasználós belső eszköznél ez legfeljebb furcsa hiba, egy több ügyfelet kiszolgáló ügynöknél viszont adatvédelmi kockázat.

Vegyünk egy képzeletbeli budapesti könyvelőirodát, amelynek ügyfélportálján egy ügynök válaszol a számlákkal kapcsolatos kérdésekre, a háttérben egy MCP-szerveren keresztül olvasva a könyvelési rendszert. Délelőtt tízkor az A Kft. ügyvezetője kérdez, két perccel később a B Bt. pénzügyese. Ha a két kérés ugyanabban az MCP-munkamenetben fut, a legrosszabb esetben a második válasz az első ügyfél jogosultságaival készül. Az 1.19.0 változásnaplója szerint a keretrendszer mostantól a helyes hívási identitáshoz, eredethez és tulajdonoshoz köti és hitelesíti az MCP-kéréseket és -munkameneteket, a deklaratív munkafolyamatoknál pedig a szolgáltatóalapú MCP-munkameneteket hívásonként külön hatókörbe helyezi. Ez utóbbit a fejlesztők [BREAKING] változásként jelölték, vagyis a meglévő kódot át kell nézni hozzá.

A változásnapló legfontosabb tételei közérthetően

A Microsoft Agent Framework hivatalos Python-változásnaplója alapján az 1.19.0 biztonsági szempontból lényeges módosításai a következők.

• Hívásonkénti MCP-munkamenetek. A deklaratív munkafolyamatokban minden hívás saját MCP-munkamenetet kap, így az egyik ügyfél kapcsolata nem öröklődik át a másikra.
• Identitáshoz kötött MCP-kérések. A kéréseket és a munkameneteket a keretrendszer a tényleges hívó identitásához, eredetéhez és tulajdonosához köti és ennek megfelelően hitelesíti.
• Csak ellenőrzött skill-archívumok. A skill olyan előre csomagolt képesség (utasítás, szkript, erőforrás), amelyet az ügynök MCP-n keresztül tölthet be. Ezeket mostantól csak ZIP-formátumban fogadja el a keretrendszer, a lenyomatukat (digest) ellenőrzi, a nem egyértelmű MCP-konfigurációs egyezéseket pedig elutasítja.
• Elavult MCP sampling visszahívás. A sampling az MCP-nek az a képessége, amellyel a szerver kérheti, hogy a kliens modellje generáljon neki szöveget. A 2026. július 28-i MCP-specifikáció ezt elavultnak jelölte, az Agent Framework pedig most ezt a döntést követte.
• Szigorúbb biztonsági címkék. A keretrendszer információáramlás-szabályozó címkéi jelölik, mennyire bizalmas vagy megbízható egy adat, az 1.19.0-ban ezek érvényesítése szigorodott.
• Belső eszközdiagnosztika és eszközszintű láthatóság. Az eszközök diagnosztikai adatai alapértelmezetten belső használatúak maradnak, új vezérlőkkel pedig eszközönként szabályozható, melyik eszköz látható az ügynök adott üzemmódjában.
• Explicit sütikezelés. A HTTP-sütik megőrzését mostantól kifejezetten be kell állítani mind a keretrendszer által létrehozott, mind a hívó által átadott klienseknél, ami szintén [BREAKING] változás.

Az egy héttel korábbi, szeptember 10-i 1.18.0 ugyanebbe az irányba mutatott: felső időkorlátot és leállási okot kapott az eszközhívási ciklus, a titkos kulcsokat tároló SecretString maszkolt értékként viselkedik (így kisebb az esélye, hogy egy kulcs véletlenül a naplókba kerüljön), az MCP-fejlécek pedig csak az adott átviteli kérésre érvényesek. A .NET oldalon a szeptember 18-i 1.22.0 hozta a hívásonkénti MCP-munkameneteket, az augusztus 22-i .NET 1.19.0 pedig az MCP hosszú futású feladatait átállította a 2026. július 28-i specifikáció Tasks-kiterjesztésére.

Miért számít ez akkor is, ha nem fejlesztesz?

Egy cégvezetőnek nem kell tudnia, mi az a digest vagy a sampling, de tudnia kell, milyen kérdést tegyen fel annak, aki az ügynökét építi vagy üzemelteti. A szeptemberi hírek (a LiteLLM MCP-hitelesítésében aktívan kihasznált bejelentkezés-megkerülés, illetve a spanyol adatvédelmi hatóság által vizsgált, feltehetően ügynök által végrehajtott adatszivárgás) azt mutatják, hogy az ügynökök és az eszközeik közötti kapcsolat ma az egyik legérzékenyebb pont.

Ha a céged ügyféladatot kezelő ügynököt futtat, három kérdést érdemes feltenned a beszállítónak. Melyik keretrendszer melyik verzióján fut az ügynök és mikor frissítettétek utoljára? Minden ügyfél kérése külön munkamenetben, a saját jogosultságaival fut? Van írásos folyamatotok arra, hogy a biztonsági kiadásokat (mint most az 1.19.0) mennyi időn belül telepítitek? Ha a válasz bizonytalan, az önmagában is jelzés.

Mit tegyél, ha már Agent Frameworköt használsz?

• Olvasd át a változásnapló [BREAKING] tételeit a jelenlegi verziód és az 1.19.0 között, mert a hetenkénti kiadások miatt ez akár tucatnyi tétel is lehet.
• Ha deklaratív (YAML-alapú) munkafolyamatokat használsz MCP-vel, teszteld külön, hogy a hívásonkénti munkamenet nem töri-e meg a több lépésen átívelő logikát.
• Keresd meg a kódban az MCP sampling visszahívás használatát, majd tervezd meg a kiváltását, mert az elavult funkciók a következő főbb kiadásokban eltűnhetnek.
• Ellenőrizd, hogy a skill-csomagjaid ZIP-formátumúak-e és megbízható forrásból származnak-e.
• Nézd át a HTTP-sütik kezelését azoknál a klienseknél, amelyeket a keretrendszernek kívülről adsz át.

AutoGen és Agent Framework fogalmai egymás mellett

Az AutoGenről az Agent Frameworkre való átállás nem újraírás a nulláról, mert az alapok ismerősek: az ügynök itt is egy modellkliens köré épül, utasításokat és eszközöket kap. A legnagyobb különbség az állapotkezelésben és a több ügynök összehangolásában van, ahol az AutoGen csapatait típusos, gráfalapú munkafolyamatok váltják.

A Microsoft hivatalos migrációs útmutatója ezt saját fordításunkban így foglalja össze: „Az alapok ismerősek. Továbbra is egy modellkliens köré hozod létre az ügynököket, utasításokat adsz és eszközöket csatolsz.” A részletekben viszont annyi az eltérés, hogy egy komolyabb AutoGen-rendszert nem érdemes sorról sorra átírni, hanem a mintákat kell lefordítani. Az alábbi táblázat az útmutató (utolsó frissítés: 2026. augusztus 25.) megfeleltetéseit mutatja, a jobb oldali oszlop a saját magyarázatunk.

Három különbség, amely a költségeidet is érinti

Az első az állapotkezelés. Az AutoGen AssistantAgentje a saját állapotában tartotta a beszélgetés előzményét, az Agent Framework Agentje viszont állapotmentes, az előzményt egy AgentSession nevű munkamenet-objektum hordozza, amelyet külső tárolóba (például adatbázisba) is menthetsz. Ez elsőre plusz munka, cserébe egy újraindított szerver után sem vész el, hol tartott az ügyfél ügye, ráadásul több példányban is futtathatod ugyanazt az ügynököt.

A második a többkörös alapviselkedés. Az útmutató szerint az AssistantAgent alapesetben egyetlen kört fut, hacsak nem emeled meg a max_tool_iterations értékét, az Agent viszont alapból addig hívogatja az eszközeit, amíg be nem fejezi a feladatot. Ez kényelmes, de ugyanazzal a kéréssel több modellhívás és így több token keletkezhet. A szeptember 10-i 1.18.0-ban az eszközhívási ciklus felső időkorlátot és a leállás okát jelző visszajelzést kapott, ezzel a lehetőséggel pedig érdemes élni.

A harmadik az emberi jóváhagyás és a mentés. Az Agent Framework munkafolyamatai meg tudnak állni, hogy egy ember jóváhagyjon egy lépést (például egy ajánlat elküldését), majd onnan folytatódnak, ahol abbamaradtak, a futás állapota pedig menthető és visszatölthető. Az útmutató kifejezetten kiemeli, hogy az AutoGen Team-absztrakciójában ez a kérés-válasz mechanizmus nem létezik. Egy KKV-nál ez az a pont, ahol egy ügynökből felelősen vállalható munkatárs lesz, hiszen a pénzt vagy ügyféladatot érintő lépések előtt mindig ott lehet egy emberi igen.

Ami nem vihető át egy az egyben

Az útmutató őszintén jelzi azt is, hogy nem minden AutoGen-képességnek van ma még pontos megfelelője. Az AutoGen például beágyazott és kísérleti elosztott futtatókörnyezetet is kínált, az Agent Framework viszont jelenleg az egy folyamaton belüli összeállításra összpontosít, az elosztott futtatás a tervek között szerepel. Az egymásnak feladatot átadó, Swarm-jellegű mintákhoz a változásnaplóban is szereplő handoff-orkesztráció áll a legközelebb, de a pontos viselkedést minden esetben tesztelni kell. Ha a rendszered ilyen különlegességekre épül, a migráció előtt nézd át az útmutató aktuális változatát.

Copilot Studio vagy nyílt eszközök egy Microsoft 365-ös cégnél?

Ha az ügynököt a saját munkatársaid használják Teamsben vagy a Microsoft 365-ben, a feladat pedig jól leírható (belső tudásbázis, űrlap, jóváhagyás), a Copilot Studio a gyorsabb és kisebb kockázatú út. Ha az ügynök ügyfeleket szolgál ki, nem Microsoft-rendszerekkel dolgozik vagy egyedi logikát igényel, a nyílt eszközök, például az Agent Framework vagy az n8n, rugalmasabbak.

A Copilot Studio a Microsoft grafikus, kevés kódot igénylő ügynökkészítő felülete, amely a Microsoft 365-be, a Teamsbe és a SharePointba simul bele. A legnagyobb előnye nem a technológia, hanem a környezet: a jogosultságokat a meglévő Microsoft-fiókok kezelik, az ügynök ott jelenik meg, ahol a kollégák amúgy is dolgoznak, külön szervert pedig nem kell üzemeltetni. A hátránya ugyanennek a zárt környezetnek a másik oldala: a díjazás kreditalapú, az ügynök logikája a platform keretei között mozog, egy nagy forgalmú, ügyfeleknek szóló szolgáltatásnál pedig a kreditszámla gyorsan nőhet.

A nyílt oldalon az Agent Framework a fejlesztőknek szóló, kódalapú eszköz, amely MIT-licences, tehát maga a keretrendszer ingyenes. Az n8n egy vizuális munkafolyamat-automatizáló platform több mint 1 500 integrációval, amely önállóan hosztolva (fair-code licenccel) és felhőszolgáltatásként is elérhető, a Microsoft-oldalon pedig szintén erős: az Excel-, Teams- és Outlook-node-okat az elmúlt kiadásokban rendszeresen javították. Az automatizációs platformok (Zapier, Make, n8n) részletes összevetése egy külön téma, itt csak azt nézzük, hogyan illeszkednek egy Microsoft 365-ös cég ügynökös döntésébe.

Két képzeletbeli példa

Vegyünk egy képzeletbeli, 22 fős székesfehérvári mérnökirodát, amely teljes egészében Microsoft 365-ön dolgozik, a szabályzatai SharePointban vannak, a projektkommunikáció Teamsben zajlik. Itt egy olyan belső ügynök, amely megválaszolja a szabadságolási, kiküldetési és beszerzési kérdéseket, tipikusan Copilot Studio-feladat. Az ügynök néhány nap alatt összerakható, a jogosultságokat a meglévő fiókok adják, ha pedig a kérdezők Microsoft 365 Copilot-licenccel rendelkeznek, a használat nem terheli a kreditkeretet. Fejlesztőt ide felesleges bevonni.

Most vegyünk egy képzeletbeli debreceni webshopot, amely WooCommerce-en fut, a könyvelése egy magyar számlázóprogramban van, a belső levelezése viszont Outlookban. Az oldalon egy rendelésstátuszt és visszárut kezelő ügynököt szeretnének, amely havonta több ezer vásárlóval beszél. Itt a Copilot Studio kreditalapú díjazása és a nem Microsoft-rendszerek integrációja miatt jellemzően jobban jár a cég egy Agent Frameworkre vagy n8n-re épülő megoldással, ahol a modellt és a futtatás helyét is maga választja meg. Ha korábban AutoGennel kísérleteztek ilyen ügynökkel, a természetes következő lépés az Agent Framework, ha pedig a logika inkább integrációkból áll, mint gondolkodásból, az n8n egyszerűbb.

Mennyibe kerül a Copilot Studio és mennyibe egy saját ügynök?

A Microsoft hivatalos árazása szerint a Copilot Studio kapacitáscsomagja havi 200 dollár 25 000 Copilot Creditért, a használatalapú díj pedig 0,01 dollár kreditenként. A Microsoft 365 Copilot ára felhasználónként havi 30 dollár éves fizetéssel, a licenccel rendelkező munkatársak belső ügynökhasználata pedig nem fogyaszt kreditet. Az Agent Framework ingyenes, ott a modell és a futtatás kerül pénzbe.

A számoláshoz először azt kell látni, mi fogyasztja a kreditet. A Microsoft Learn Copilot Studio-számlázási oldala (utolsó frissítés: 2026. augusztus 3.) tételesen megadja, melyik ügynökfunkció hány kreditbe kerül. Az alábbi táblázatban a forintos értékek saját becslések a 0,01 dolláros használatalapú díjjal és kerekített 320 Ft-os dollárárfolyammal számolva.

A Microsoft Copilot Studio 2026. júniusi licencelési útmutatója két további részletet rögzít, amelyek egy kisebb cégnél sokat számítanak. A kapacitáscsomagot éves elszámolással kínálják, a fel nem használt kreditek pedig nem vihetők át a következő hónapra, vagyis egy csendesebb hónapban a kifizetett keret egy része egyszerűen elvész. Az előre megvásárolt kreditegységekkel (Pre-Purchase Plan) a Microsoft árazási oldala szerint akár 20% is megtakarítható, ez azonban inkább a kiszámítható, nagyobb fogyasztású cégeknek éri meg.

Kidolgozott példa: webes ügyfélszolgálati ügynök Copilot Studióban

Tegyük fel, hogy egy képzeletbeli, 18 fős győri alkatrész-kereskedés a weboldalára tesz egy Copilot Studióban épített ügyfélszolgálati ügynököt. Havonta 1 200 beszélgetéssel számolunk, beszélgetésenként átlagosan három generatív válasszal (3 × 2 = 6 kredit) és egy ügynöki művelettel, például egy rendelésstátusz lekérdezésével (5 kredit), ami beszélgetésenként 11 kreditet jelent. Mivel a vásárlók nem a cég Microsoft 365 Copilot-licences munkatársai, minden kredit számít.

• Havi kreditigény: 1 200 × 11 = 13 200 kredit.
• Használatalapú díjjal: 13 200 × 0,01 = 132 dollár, ami kerekített 320 Ft-os árfolyammal nagyjából 42 240 Ft havonta.
• Kapacitáscsomaggal: 200 dollár, azaz 64 000 Ft havonta, amiből 11 800 kredit kihasználatlanul elvész.
• Fordulópont: a csomag havi 20 000 kredit felett kezd jobban megérni a használatalapú díjnál (200 dollár / 0,01 dollár).
• Dupla forgalomnál: 2 400 beszélgetés 26 400 kreditet jelent, ez használatalapú díjjal 264 dollár (84 480 Ft), egy csomaggal és a felette lévő 1 400 kredit használatalapú kifizetésével 214 dollár (68 480 Ft).

A belső használat egészen más képet mutat. Ha a mérnökirodás példában nyolc munkatárs kap Microsoft 365 Copilot-licencet, az havi 8 × 30 = 240 dollár, vagyis éves fizetés mellett havonta nagyjából 76 800 Ft, cserébe a Teamsre, a SharePointra és a Microsoft 365 Copilotra épített Copilot Studio-ügynökeik a licencelési útmutató szerint külön díj nélkül, méltányos használati korlátok mellett futnak. Ha más licencváltozatban vagy kisebb csomagban gondolkodsz, a Copilot Studio-jogosultságokat vásárlás előtt érdemes a licencpartnerrel tételesen tisztázni, mert a díjmentesség feltételei licencenként eltérhetnek.

És mennyibe kerül ugyanez Agent Frameworkkel?

Az Agent Frameworknél nincs kredit, a futási költség a modell tokenárából és a szerverből áll. Maradjunk a győri példánál és becsüljük beszélgetésenként 4 000 bemeneti tokennel (rendszerutasítás, előzmény, eszközválaszok) és 800 kimeneti tokennel. Havonta ez 4,8 millió bemeneti és 0,96 millió kimeneti token. Ha a legdrágább frontmodellek egyikével, az OpenAI GPT-6 Astra szeptember 3-án bejelentett listaárával számolunk (10 dollár millió bemeneti és 50 dollár millió kimeneti tokenenként), a havi modellköltség 48 + 48 = 96 dollár, vagyis nagyjából 30 720 Ft. Egy olcsóbb modellel ennek a töredéke, a gondolkodó modellek rejtett gondolkodási tokenjei viszont felfelé is módosíthatják a számot.

Ehhez jön a futtatókörnyezet (saját szerver, felhőszolgáltatás vagy a Microsoft Foundry) és a legnagyobb tétel, a fejlesztés és a karbantartás. Egy egyszerű ügyfélszolgálati ügynök megépítése saját becslésünk szerint néhány tucat fejlesztői óra, a hetente frissülő keretrendszer követése pedig havonta még néhány óra. A tanulság ezért nem az, hogy a nyílt út mindig olcsóbb. A futási költség ritkán dönt, sokkal inkább az, hogy van-e a cégnek olyan fejlesztője vagy partnere, aki a kódot hosszú távon karbantartja. Ha nincs, a Copilot Studio kreditszámlája valójában a karbantartás ára, amelyet a Microsoft vesz le a válladról.

Mikor nem éri meg Agent Frameworkre váltani?

Nem éri meg váltani, ha az AutoGen-projekt lezárt kísérlet volt, ha nincs a cégnél olyan Python- vagy .NET-fejlesztő, aki a hetente frissülő keretrendszert követi, vagy ha az ügynök valójában egy egyszerű, néhány eszközt hívó automatizmus. Ilyenkor az archiválás, a Copilot Studio vagy egy n8n-munkafolyamat olcsóbb és tartósabb megoldás.

Tapasztalatunk szerint a KKV-knál futó AutoGen-projektek jó része nem a bonyolult, egymással vitatkozó ügynökcsapatokról szól, hanem egyetlen ügynökről, amely két-három eszközt hív: kiolvas egy táblázatot, lekérdez egy CRM-et, majd megír egy összefoglalót. Egy ilyen feladathoz felesleges egy fejlesztői keretrendszert karbantartani, egy vizuális munkafolyamat-eszköz AI-ügynök node-ja vagy egy Copilot Studio-ügynök ugyanezt kevesebb kóddal és kevesebb üzemeltetési teherrel adja. A váltás ilyenkor nem migráció, hanem egyszerűsítés, ami önmagában is megtakarítás.

Ha a céged nem a Microsoft-világban él, érdemes a Microsofton kívüli lehetőségeket is mérlegelni. Az OpenAI például szeptember 10-én nyilvános bétába küldte az Agents API-t, amely munkamenet-kezelést, kontextustömörítést és alügynököket ad, az AgentStack elemzése szerint viszont triggerkezelés, connector-könyvtár és költségláthatóság nélkül. Ez inkább egy harmadik út a fejlesztőknek, mint az AutoGen egyenes utódja. Végül ott a maradás lehetősége is: ha az AutoGen-rendszered zárt hálózatban fut, nincs külső felhasználója és a lecserélése 2027-re be van ütemezve, a rögzített verziók és a rendszeres függőségfigyelés mellett néhány hónapig nyugodtan kitarthatsz. Aki a 0.2-es API-hoz ragaszkodna, annak ott az AG2 közösségi ága, ennek támogatási modellje és ütemezése azonban teljesen független a Microsofttól.

Migrációs terv fájdalom nélkül, lépésről lépésre

A fájdalommentes AutoGen-migráció titka nem a gyorsaság, hanem a sorrend: előbb leltár és tesztkészlet, utána az átültetés, végül egy olyan párhuzamos futtatási időszak, amikor a régi és az új rendszer ugyanazokat a kéréseket kapja. Így az átállás napján már számokkal tudod, hogy az új ügynök legalább olyan jó, mint a régi.

Az alábbi lépéssort egy képzeletbeli, három ügynökből, hat eszközből és egy MCP-szerverből álló AutoGen-rendszerre írtuk, amely egy kisebb cégnél ajánlatokat készít elő a beérkező érdeklődésekből.

• Készíts leltárt. Írd össze az összes ügynököt, eszközt, MCP-szervert, modellszolgáltatót és környezeti változót, valamint azt, hogy ki használja az ügynököt és milyen adatokhoz fér hozzá. A leltár nélkül a migráció közben derülnek ki a meglepetések.
• Sorold be kockázat szerint. A korábbi táblázat alapján döntsd el, melyik ügynök sürgős és melyik várhat, a legnagyobb kockázatú rendszert pedig vedd előre.
• Rögzítsd a régi rendszert. Fagyaszd be az AutoGen és a függőségek pontos verzióit, hogy a régi ügynök stabilan fusson, amíg az új elkészül.
• Építs tesztkészletet. Gyűjts 30 és 50 közötti valódi, anonimizált kérést a várt eredménnyel, majd mérd rajtuk a helyes válaszok arányát, a futási időt és a tokenköltséget. Ez lesz a mérce az átállásnál.
• Ültesd át az ügynököket és az eszközöket. Az AssistantAgentből Agent, a FunctionToolból @tool dekorátorral jelölt függvény lesz. Kezdd a legegyszerűbb ügynökkel, továbblépni pedig csak akkor érdemes, ha az új ügynök a tesztkészleten hozza a régi eredményt.
• Építsd újra a munkafolyamatot. A csapatokból Workflow lesz, az előzményt AgentSession hordozza, a pénzt vagy ügyféladatot érintő lépések elé pedig tegyél emberi jóváhagyási pontot a kérés-válasz mechanizmussal.
• Kösd be az MCP-t és a jogosultságokat. Használd a keretrendszer MCP-eszközeit, ügyelj rá, hogy minden hívás a saját munkamenetében és a legszűkebb szükséges jogosultsággal fusson, a titkos kulcsokat pedig tárold a naplóktól elkülönítve.
• Kapcsold be a megfigyelhetőséget és a korlátokat. Állíts be időkorlátot az eszközhívási ciklusra, havi tokenkeretet és OpenTelemetry-alapú naplózást, hogy lásd, melyik ügynök mennyit dolgozik és mennyibe kerül.
• Futtasd párhuzamosan. Két hétig kapja meg ugyanazt a kérést a régi és az új rendszer is, de csak a régi válasza menjen ki. Hasonlítsd össze az eredményeket a tesztkészlet mérőszámai alapján.
• Állj át és tartsd meg a visszaút lehetőségét. Az átállás után 30 napig őrizd meg a régi rendszer futtatható változatát, utána archiváld.

A táblázat óraszámai saját becslések egy jól dokumentált, rendezett kódbázisra. Ha az eredeti fejlesztő már nincs a cégnél, a kódban nincsenek tesztek vagy az ügynök több, dokumentálatlan belső rendszerhez nyúl, a leltárra és a tesztkészletre szánt időt nyugodtan duplázd meg, mert jellemzően itt csúsznak el a projektek.

Milyen buktatókra figyelj a migráció közben?

A leggyakoribb buktatók a megváltozott alapviselkedésből adódnak: az Agent Framework ügynöke alapból többkörös és állapotmentes, a hetente érkező kiadások pedig visszafelé nem kompatibilis változásokat is hozhatnak. Mindegyik jól kezelhető, ha a projekt elején tudsz róluk és a tesztkészleted figyeli őket.

• Elszálló tokenköltség. Mivel az Agent alapból addig hívogatja az eszközeit, amíg be nem fejezi a feladatot, ugyanaz a kérés több modellhívást generálhat, mint az AutoGenben. Állíts be iterációs és időkorlátot, a tesztkészleten mért tokenfogyasztást pedig hasonlítsd össze a régivel.
• Elveszett előzmény. Az állapotmentes ügynök nem emlékszik semmire, ha a munkamenetet nem mented el. Egy félbehagyott reklamáció közepén, újraindítás után érkező „Miben segíthetek?” az ügyfélnél rosszabb, mint egy lassú válasz.
• Rögzítetlen verziók. Heti kiadási ütem mellett a pontos verziórögzítés kötelező. Frissíteni tudatosan, a változásnapló [BREAKING] tételeinek átolvasása után érdemes, nem egy automatikus függőségfrissítés mellékhatásaként.
• Verziószám-zavar. A Python és a .NET változat külön számozást követ, ezért egy „1.19-es” hivatkozás két különböző kiadást jelenthet. A dokumentációban és a beszállítói szerződésben mindig a nyelvet is rögzítsd.
• Telemetria és adatvédelem. A változásnapló szerint az 1.13.0 óta a csomagokban folyamatszintű funkcióhasználati telemetria is van. A GDPR-áttekintésnél nézd meg, pontosan mit jelez a keretrendszer és hogyan szabályozható, ahogyan azt is, hogy a modellhívások melyik régióban futnak.
• Beszállítói kötődés. A Microsoft Foundry felügyelt futtatása kényelmes, de minél több platformszolgáltatásra épülsz, annál nehezebb később máshová költözni. Ha a függetlenség fontos, tartsd az ügynök logikáját a keretrendszerben, a platformspecifikus részeket pedig egy vékony rétegben.

Kitekintés: merre tart a Microsoft ügynökös kínálata 2027-ig

A Microsoft iránya a források alapján egyértelmű: a kódból épített ügynököknek az Agent Framework az egyetlen hosszú távú út, a kódot nem író felhasználóknak a Copilot Studio, a kettő között pedig egyre több az átjárás. Az AutoGen a közösségé lett, a Semantic Kernel pedig beolvadt az utódjába.

A saját olvasatunk szerint a következő egy évben három dolog várható. Az első a szoros protokollkövetés: a .NET 1.19.0 már augusztusban átállt az MCP 2026. július 28-i specifikációjának Tasks-kiterjesztésére, a Python 1.19.0 pedig a specifikációval összhangban elavultnak jelölte az MCP sampling visszahívást. Mivel a specifikáció a régi HTTP+SSE átvitelt 12 hónapos átmenettel vezeti ki, ez a határidő saját számításunk szerint 2027 nyarán jár le, addigra pedig az AutoGenre épülő MCP-integrációk egy része valószínűleg kompatibilitási gondokba ütközik. Ez jó, gyakorlatias határidő a saját migrációd ütemezéséhez is.

A második a biztonsági keményítés folytatása. Az 1.18.0 és az 1.19.0 tételeinek jó része már most elszigetelésről, jogosultságokról és ellenőrzött csomagokról szól, az ügynökökhöz kapcsolódó szeptemberi biztonsági hírek után pedig ez az irány aligha fordul meg. A harmadik a verseny: az OpenAI Agents API bétája már most alternatívát kínál a fejlesztőknek, a szeptember 29-i DevDay pedig további bejelentéseket hozhat, így a Microsoft várhatóan tovább erősíti az Agent Framework nyitottságát (több modellszolgáltató, MCP, A2A). Egy magyar KKV-nak ebből annyi a tanulság, hogy a keretrendszer-választás ma kevésbé kockázatos, mint két éve volt, feltéve, hogy a cég nyílt protokollokra (MCP) épít és az üzleti logikáját nem köti szorosan egyetlen platformhoz.

Miben segít a Convergo?

Ha a céged AutoGenre, Semantic Kernelre vagy más ügynökös megoldásra épít, szívesen segítünk felmérni, mi fut nálatok, mekkora a kockázat és mi a legésszerűbb következő lépés. Az IT audit és digitális tanácsadás keretében elkészítjük a leltárt és a kockázati besorolást, az egyedi AI-integráció szolgáltatásunkkal pedig átültetjük az ügynököket a Microsoft Agent Frameworkre, tesztkészlettel és párhuzamos futtatással. Ha kiderül, hogy egy egyszerűbb eszköz is elég, a workflow automatizáció keretében n8n-alapú megoldást építünk. Az első lépés egy ingyenes egyeztetés, ahol közösen átnézzük a meglévő rendszeredet.