Microsoft rozšiřuje Copilot Studio o nové prostředí postavené na GitHub Copilot harnessu. Název může vyvolat dojem, že jde především o propojení s GitHubem nebo o funkci určenou vývojářům. Ve skutečnosti je jeho význam širší. Copilot Studio získává řídicí vrstvu, která umožňuje agentům samostatně plánovat složitější práci, používat nástroje, zpracovávat soubory, vyhodnocovat průběžné výsledky a hledat jiný postup, pokud původní cesta nevede k cíli.
Microsoft tuto novou funkcionalitu pozicuje pro komplexní vícekrokové firemní procesy, které nelze snadno popsat pevnou posloupností podmínek a akcí. GitHub Copilot harness ale přináší také jiný model účtování. Použití agentů a workflows v runtime se měří prostřednictvím Copilot Credits. Spotřeba může vznikat také během tvorby, například při tvorbě pomocí přirozeného jazyka, testování v Preview a evaluacích. Ruční tvorba agenta se podle aktuálního přehledu Microsoftu neúčtuje. Licence Microsoft 365 Copilot účtované použití GitHub Copilot harnessu nepokrývá.
Novinka proto není jen dalším rozšířením funkcí Copilot Studia. Mění způsob, jakým je potřeba navrhovat architekturu agentů, vybírat vhodné automatizační technologie a řídit jejich provozní náklady.
Samotný jazykový model umí porozumět zadání, analyzovat informace a navrhnout odpověď nebo další krok. To ale ještě nestačí k tomu, aby dokončil proces spolehlivě. Agent potřebuje řídicí vrstvu, která propojí model s instrukcemi, kontextem, nástroji, daty a výsledkem. Tato vrstva se označuje jako harness. V češtině pro tento pojem zatím nemáme zavedený přesný ekvivalent. Prakticky jej lze chápat jako řídicí a běhové prostředí agenta.
Harness určuje, jak agent postupuje od požadavku k výsledku. Rozhoduje, jaký kontext předat modelu, kdy použít znalostní zdroj, který nástroj zavolat a co udělat s jeho odpovědí. Zajišťuje také pokračování práce mezi jednotlivými kroky a kontroluje, zda se agent stále přibližuje k zadanému cíli.
Zjednodušeně lze rozdíl popsat takto.
Představme si požadavek na zpracování dodavatelské faktury. Model může dokument přečíst, rozpoznat dodavatele a navrhnout kontrolu proti objednávce. Harness ale musí zajistit, aby agent skutečně otevřel příslušný systém, našel objednávku, porovnal hodnoty, vyhodnotil odchylku a podle výsledku pokračoval dalším krokem.
Právě schopnosti harnessu rozhodují, zda agent pouze odpovídá na otázky, následuje předem připravené konverzační cesty, nebo dokáže samostatně řešit delší úkol s proměnlivým průběhem.
GitHub Copilot harness využívá agentní prostředí, které stojí za pokročilými schopnostmi GitHub Copilotu. Neznamená to ale, že agent musí pracovat se zdrojovým kódem, používat GitHub repozitář nebo být určen pouze vývojářům.
GitHub Copilot pro vývojáře pomáhá při tvorbě a úpravách softwaru. GitHub Copilot harness v Copilot Studiu přenáší jeho způsob plánování a práce s nástroji do širších firemních procesů.
Agent postavený na tomto harnessu může dostat cíl, rozdělit jej na jednotlivé kroky a průběžně rozhodovat, jaké nástroje použije. Může pracovat s konektory, znalostními zdroji, MCP servery, skills a dalšími agenty. Nové prostředí podporuje také práci se soubory Wordu, Excelu, PowerPointu a PDF, paměť mezi interakcemi a hledání alternativní cesty po neúspěšném kroku. Co je důležité, paměť agenta je trvalá přes více sessions a je dedikovaná konkrétnímu uživateli.
Kód může být jedním z prostředků, které agent na pozadí použije. Nemusí však být hlavním výstupem a autor agenta jej nemusí ručně vytvářet. Formulaci, že GitHub Copilot harness dává Copilot Studiu schopnosti programování a reasoning, proto není vhodné chápat tak, že se Copilot Studio mění na vývojářský nástroj. Přesnější je říci, že agent získává flexibilnější prostředí pro dokončení složitých úkolů.
GitHub Copilot harness dává největší smysl tam, kde proces nemá jednu předem známou cestu a další krok závisí na tom, co agent během práce zjistí. Vhodnými příklady mohou být:
Při přípravě obchodní nabídky může agent například načíst informace z CRM, vyhledat odpovídající produktovou dokumentaci, zohlednit předchozí komunikaci, připravit návrh dokumentu a doplnit finanční podklady. Pokud některé informace chybí, může se pokusit je získat jiným nástrojem nebo úkol předat specializovanému agentovi.
Tradiční automatizace by pro každý takový stav potřebovala předem připravenou větev. Agent s GitHub Copilot harness může pracovat s cílem, průběžným stavem a dostupnými nástroji. Nejde tedy jen o chytřejší chat. Jde o schopnost organizovat a dokončovat práci napříč dokumenty, daty, podnikovými systémy a dalšími (specializovanými) agenty.
Tato flexibilita ale neznamená, že GitHub Copilot harness automaticky nahradí klasické agenty nebo Power Automate. U dobře definovaného procesu může být pevná a předvídatelná automatizace rychlejší, levnější a jednodušší na správu.
Způsob účtování je pro správné pochopení nové funkce zásadní.
Agenti, workflows a aplikace běžící na GitHub Copilot harnessu používají usage based billing. Spotřeba se měří prostřednictvím Copilot Credits a zahrnuje použití jazykových modelů, nástrojů, znalostních zdrojů, MCP serverů a samotného harnessu.
Na rozdíl od Standard harnessu může účtování začít již během tvorby. Copilot Credits mohou spotřebovávat například tyto činnosti:
Spotřeba tedy nevzniká až ve chvíli, kdy je agent publikovaný uživatelům. Může se objevit už během vývoje a ladění. Microsoft tuto skutečnost opakovaně uvádí přímo v dokumentaci nového prostředí.
Licence Microsoft 365 Copilot tuto spotřebu nepokrývá. Uživatel může mít licenci Microsoft 365 Copilot, ale použití agenta nebo workflow na GitHub Copilot harnessu se přesto účtuje podle skutečné spotřeby.
Jde o samostatný provozní model, který odpovídá tomu, že agent může vykonávat dlouhou a výpočetně náročnou práci, používat různé modely a volat několik nástrojů bez přímé interakce s uživatelem.
Pokud chce organizace využít scénáře zahrnuté v licenci Microsoft 365 Copilot, musí zvolit odpovídajícího agenta používajícího Copilot chat nebo Standard harness. Tím ale získá jiný rozsah schopností. GitHub Copilot harness nelze zachovat a pouze změnou licence odstranit jeho účtování dle aktuální spotřeby. Přehled harnessů uvádí pro GitHub Copilot harness účtování pomocí Copilot Credits, zatímco Copilot chat a Standard harness mohou podle konkrétního scénáře používat spotřební model nebo zahrnuté použití Microsoft 365 Copilotu.
Rozdíl mezi jednotlivými harnessy není pouze v jejich schopnostech. Liší se také okamžikem, kdy může vzniknout spotřeba, a podmínkami, za kterých je použití zahrnuto do licence Microsoft 365 Copilot.
U Copilot chat a Standard harnessu se základní model účtování nemění. Ruční tvorba agenta, testovací panel a standardní authoring nejsou samy o sobě účtovány. Při produkčním používání ale záleží na tom, kdo agenta používá, v jakém kanálu běží a zda uživatel má licenci Microsoft 365 Copilot.
GitHub Copilot harness má odlišný model. Usage based billing se u něj vztahuje na tvorbu i vlastní běh. Spotřeba může vzniknout při tvorbě pomocí přirozeného jazyka, evaluacích, testování i při samotném používání agenta nebo workflow.
| Oblast | Copilot chat harness | Standard harness | GitHub Copilot harness |
|---|---|---|---|
| Ruční tvorba agenta | Neúčtuje se | Neúčtuje se | Neúčtuje se |
| Tvorba pomocí přirozeného jazyka | Není relevantní | Neúčtuje se | Usage based billing |
| Evaluace | Není relevantní | Neúčtuje se | Usage based billing |
| Testovací panel a preview | Neúčtuje se | Neúčtuje se | Usage based billing |
| Externí kanály | Není relevantní | Podle ceníku | Usage based billing |
| Uživatel bez licence Microsoft 365 Copilot | Podle publikovaného ceníku | Podle ceníku | Usage based billing |
| Uživatel s licencí Microsoft 365 Copilot | V rámci fair use se neúčtuje | V rámci fair use se neúčtuje | Usage based billing |
| Standardní, prémiové a vlastní konektory | Samotná integrace se neúčtuje | Samotná integrace se neúčtuje | Samotná integrace se neúčtuje |
| Správa v Power Platform admin center | Neúčtuje se | Neúčtuje se | Neúčtuje se |
Tabulka: Porovnání účtování v jednotlivých fází životního cyklu agenta při použití konkrétního harnessu
Označení „neúčtuje se“ se vztahuje na konkrétní funkci uvedenou v tabulce. Neznamená to automaticky, že celý scénář nemůže vyžadovat další licence, kapacitu nebo placené konektory.
Zahrnuté použití pro uživatele s licencí Microsoft 365 Copilot se vztahuje na zaměstnanecké scénáře, ve kterých agent pracuje pod identitou autentizovaného licencovaného uživatele. U Agent Flows platí zahrnutí do ceny pouze pro běhy spuštěné triggerem When an agent calls the flow. Agent Flows, které používají jiné triggery, spotřebovávají Copilot Credits podle standardního ceníku.
Volba harnessu je proto současně funkčním, architektonickým a finančním rozhodnutím.
Přehled usage based billing pro GitHub Copilot harness najdete zde.
Microsoft nyní rozlišuje GitHub Copilot harness, Standard harness a Copilot chat harness. Pro běžného uživatele je jednodušší přiřadit si je k prostředím, ve kterých dnes agenty vytváří.
Copilot chat harness používají deklarativní agenti, kteří rozšiřují Microsoft 365 Copilot. Nejjednodušší cestou k jejich vytvoření je Agent Builder přímo v Microsoft 365 Copilotu. Autor může pomocí přirozeného jazyka popsat účel agenta, přidat vlastní instrukce, zdroje znalostí a podporované akce. Výsledný agent používá orchestrátor, modely a služby Microsoft 365 Copilotu.
Typickým scénářem je specializovaný znalostní asistent, který odpovídá nad interní dokumentací, projektovými podklady nebo produktovými materiály. Microsoft 365 Copilot zůstává hlavním prostředím pro konverzaci a deklarativní agent jej přizpůsobuje konkrétnímu účelu.
Agent Builder není jediný nástroj, kterým lze deklarativního agenta vytvořit. Lze použít také Copilot Studio nebo Microsoft 365 Agents Toolkit. Pro základní orientaci ale platí praktická pomůcka.
Agent Builder obvykle znamená Copilot chat harness.
Standard harness představuje prostředí, které většina uživatelů zná jako původní nebo klasické Copilot Studio. Obsahuje topics, otázky, podmínky, proměnné, actions, nástroje a Agent Flows.
Autor má větší kontrolu nad průběhem konverzace a může přesně navrhnout důležité části procesu. Standard harness je vhodný pro strukturované a opakovatelné scénáře, kde má agent kombinovat přirozený jazyk s pravidly a předvídatelnými kroky.
Příkladem může být HR agent, který zjistí typ požadavku, položí potřebné otázky, ověří vstupní údaje a založí požadavek v příslušném systému.
Klasické Copilot Studio s topics a Agent Flows znamená Standard harness.
GitHub Copilot harness používá nové prostředí Copilot Studia. Je určený pro komplexnější práci, při které agent potřebuje samostatně rozhodovat, plánovat, pracovat se soubory a měnit postup podle průběžných výsledků.
Nejde pouze o modernizovanou obrazovku původního Copilot Studia. Nové prostředí používá odlišnou architekturu, způsob orchestrace a licenční model. Nové prostředí bylo uvedeno na trh ve finálním vydání 4. srpna 2026.
Nové prostředí Copilot Studia znamená GitHub Copilot harness.
Harness není vlastnost, kterou lze u existujícího agenta libovolně změnit podobně jako název, model nebo znalostní zdroj. Je součástí typu artefaktu a prostředí, ve kterém agent vzniká.
Copilot Studio umožňuje přecházet mezi novým prostředím a přístupem ke standardním agentům a Agent Flows. To ale neznamená, že se při změně prostředí převede konkrétní agent na jiný harness. Agenty a workflows vytvořené v novém prostředí nelze automaticky převést do klasického prostředí a naopak.
Výběr harnessu by proto měl proběhnout už během návrhu řešení, nikoliv až po dokončení vývoje.
Pojem „harness“ může působit příliš technicky. Pro pochopení rozdílů je proto jednodušší použít jeden konkrétní scénář a sledovat, jak by jej jednotlivé varianty řešily.
Představme si interního HR asistenta pro služební automobily. Všechny tři harnessy mohou pracovat se stejnou oblastí. Jejich role a způsob řešení však budou odlišné. Copilot chat harness rozšiřuje Microsoft 365 Copilot o specializované znalosti. Standard harness je vhodný pro strukturované konverzace a předem navržené procesy. GitHub Copilot harness se zaměřuje na složitější úkoly, při kterých musí agent samostatně plánovat, pracovat s více nástroji a přizpůsobovat další postup průběžným výsledkům.
Uživatel otevře Microsoft 365 Copilot a zeptá se:
Jaká jsou pravidla pro přidělení služebního automobilu?
Agent vyhledá relevantní interní směrnici, zohlední instrukce, které dostal od autora, a připraví odpověď v prostředí Microsoft 365 Copilotu. Může vysvětlit, které pracovní pozice mají nárok na automobil, jaké existují kategorie vozidel a jak probíhá jejich schvalování.
Takový agent nevytváří samostatnou agentní aplikaci. Rozšiřuje stávající Microsoft 365 Copilot o konkrétní odbornou oblast. Microsoft pro tento typ řešení používá označení „deklarativní agent“. Deklarativní agent může obsahovat vlastní instrukce, podnikové znalosti a podporované akce, ale nadále využívá základní konverzační a bezpečnostní prostředí Microsoft 365 Copilotu.
Nejjednodušší cestou k vytvoření takového agenta je Agent Builder v Microsoft 365 Copilotu. Agent Builder ale není samotný harness. Jde o autorský nástroj. Stejný typ deklarativního agenta lze připravit také v Copilot Studiu nebo pomocí Microsoft 365 Agents Toolkitu.
Copilot chat harness je vhodný hlavně tehdy, když chceme uživateli zpřístupnit firemní znalosti ve známém prostředí Microsoft 365 Copilotu. Agent může být vybaven také akcemi, jeho hlavní rolí je však specializovat Copilot pro určitou oblast, nikoliv řídit rozsáhlou vlastní aplikaci s přesně navrženými dialogovými cestami.
Uživatel otevře samostatného HR agenta a zadá:
Chci požádat o služební automobil.
Agent se nejprve zeptá na informace, které nejsou k dispozici v profilu uživatele. Zjistí zemi, pracovní pozici, požadovanou kategorii vozidla nebo předpokládaný roční nájezd. Poté ověří nárok podle interních pravidel, vyžádá souhlas nadřízeného a pomocí Agent Flow nebo připojeného nástroje vytvoří požadavek v příslušném systému. Tady už nejde pouze o odpověď nad firemní dokumentací. Agent vede uživatele konkrétním procesem, kontroluje povinné údaje a provádí transakční operace. Standard harness odpovídá prostředí, které většina uživatelů zná jako klasické Copilot Studio. Chování agenta lze řídit pomocí topics, otázek, podmínek, proměnných, pravidel a akcí. Autor může přesně určit části konverzace, ve kterých je důležitý předvídatelný průběh, a propojit je s generativními funkcemi nebo nástroji.
Standard harness je vhodný například pro HR požadavky, IT podporu, onboarding, registraci zákazníka nebo objednávkové procesy. Společným znakem je struktura. Organizace zná požadované kroky, pravidla i možné výsledky a potřebuje mít nad jejich provedením vysokou míru kontroly.
Uživatel zadá širší cíl:
Připrav moji žádost o služební automobil, ověř nárok, najdi vhodné dostupné varianty a připrav všechny podklady ke schválení.
Agent musí nejprve sestavit plán. Může potřebovat získat informace z HR systému, načíst aktuální směrnici, zjistit rozpočet podle pracovní pozice, projít katalog dostupných vozidel, porovnat několik nabídek a připravit dokument se zdůvodněním výběru.
Pokud některý údaj chybí, agent se jej pokusí získat prostřednictvím jiného nástroje nebo požádá uživatele o doplnění. Pokud požadované vozidlo překračuje limit, může vyhledat vhodnou alternativu. Pokud narazí na výjimku v pravidlech, připraví podklady pro individuální schválení. Výsledkem nemusí být jen odpověď, ale také upravený dokument, tabulka s porovnáním nebo sada připravených kroků pro navazující workflow.
GitHub Copilot harness je navržen pro podobné komplexní a vícekrokové úkoly. Agent postupuje podle cíle, samostatně plánuje další kroky, používá nástroje a vyhodnocuje jejich výsledky. Podporuje práci se soubory Wordu, Excelu, PowerPointu a PDF, skills, paměť, konektory, MCP servery, workflows a spolupráci s dalšími agenty. Pokud některý krok selže, může se pokusit najít alternativní cestu.
Tento scénář by bylo možné vytvořit také pomocí Standard harnessu a velkého množství větvení. Vývojář nebo maker by ale musel předem navrhnout většinu možných cest. GitHub Copilot harness přesouvá větší část rozhodování na agenta, což přináší vyšší flexibilitu, ale také nižší předvídatelnost, náročnější testování a spotřební účtování pomocí Copilot Credits.
Rozdíl není v tom, že by jeden harness byl určen pro HR a jiný pro obchod nebo finance. Všechny tři lze použít ve stejné podnikové oblasti. Liší se typem práce, který má agent vykonávat.
| Oblast | Copilot chat harness | Standard harness | GitHub Copilot harness |
|---|---|---|---|
| Hlavní účel | Specializace Microsoft 365 Copilotu | Vlastní řízený agent | Komplexní otevřené úkoly |
| Typické prostředí | Agent Builder a Microsoft 365 Copilot | Klasické Copilot Studio | Nové Copilot Studio |
| Způsob řízení | Orchestrace Microsoft 365 Copilotu | Topics, instrukce, pravidla a generativní orchestrace | Cíl, instrukce, nástroje a průběžné plánování |
| Dialog a proces | Omezenější vlastní řízení | Vysoká kontrola nad konverzací | Méně explicitních cest, více rozhodování při běhu |
| Práce se soubory | Doplňková | Doplňková | Klíčová schopnost |
| Typická autonomie | Nižší | Střední | Vyšší |
| Typický scénář | Znalostní asistent | Procesní agent | Komplexní případ s výjimkami |
| Účtování | Podle licence a scénáře | Podle licence a scénáře | Vždy usage based billing |
Tabulka 2: Porovnání funkcí v jednotlivých harness
Rozhodování lze zjednodušit podle očekávaného výsledku.
Nejdůležitější rozdíl tedy není pouze v počtu funkcí. Každý harness představuje jiný vztah mezi autorem a agentem.
U Copilot chat harnessu autor specializuje existující Microsoft 365 Copilot. U Standard harnessu autor navrhuje vlastní konverzační a procesní cesty. U GitHub Copilot harnessu definuje cíl, instrukce, nástroje a hranice, zatímco větší část konkrétního postupu sestavuje agent až během práce.
Další důležitou otázkou je, kde vytvořit související automatizaci. Rozšíření Copilot Studia neznamená, že by všechny existující flows měly být přesunuty do agentní platformy.
Pokud proces přesně ví, co má udělat, bývá Power Automate nejpřirozenější volbou. Platí to například pro automatizace, které reagují na událost, běží podle plánu, synchronizují data nebo provádějí pevně definované podmínky.
Typickými příklady jsou:
Tyto scénáře nepotřebují reasoning ani autonomní plánování. Power Automate pro ně nabízí široké možnosti integrace, sdílení, správy, monitoringu a ALM.
Agent Flows patří ke Standard harnessu. Jsou deterministické, takže při stejných vstupech mají provést stejnou posloupnost kroků. Mohou být spuštěny agentem, událostí, plánem nebo ručně a spotřebovávají kapacitu Copilot Studia podle provedených akcí.
Největší smysl mají tehdy, když jsou přirozenou součástí agenta. Agent nejprve pochopí požadavek uživatele a získá potřebné parametry. Agent Flow poté provede přesně definovanou operaci, například vyhledání objednávky, vytvoření požadavku nebo aktualizaci CRM.
Agent rozhoduje, kdy je potřeba operaci provést. Flow zajišťuje její předvídatelné vykonání.
Agent Flow používaný jako nástroj agenta musí obsahovat odpovídající trigger a odpověď pro agenta a musí být dostupný ve stejném prostředí.
Nové workflows vznikají v prostředí GitHub Copilot harnessu. Nabízejí přepracované prostředí pro tvorbu, nativní AI akce, předávání práce agentům a testování jednotlivých uzlů. Mohou kombinovat deterministické kroky s částmi, které vyžadují úsudek nebo adaptaci.
Workflow může například přijmout dokument, provést základní kontrolu a následně předat obsah agentovi. Agent určí typ dokumentu, vyhodnotí odchylky a vrátí rozhodnutí, podle kterého workflow pokračuje.
Nejde tedy pouze o nový název pro Agent Flow. Jde o jinou kategorii automatizace postavenou na novém harnessu.
Dobrá architektura nemusí používat pouze jednu platformu. Copilot Studio může řešit porozumění, rozhodování a komunikaci s uživatelem. Power Automate může dál zajišťovat předvídatelné integrační a transakční kroky.
Copilot Studio výrazně snižuje bariéru pro tvorbu agentů. Citizen developer může během krátké doby připojit firemní data, přidat nástroje, nastavit event trigger a publikovat řešení dalším uživatelům.
To je jedna z hlavních výhod platformy. Současně se ale část architektonického a finančního rozhodování přesouvá k autorům, kteří nemusí znát rozdíly mezi harnessy, typy flows a způsoby účtování.
Jednoduchý znalostní agent může vzniknout v GitHub Copilot harnessu, přestože by stačil Agent Builder. Běžná synchronizace dat může být postavena jako AI workflow, přestože by ji Power Automate vyřešil přímočařeji, předvídatelněji a bez zbytečného agentního rozhodování. Agent může být spuštěn při každé změně v systému, přestože by mohl předem odfiltrovat většinu událostí jednoduchý flow.
Není nutné vždy používat bagr, když by stačila obyčejná lopata. Může vzniknout neočekávaná spotřeba Copilot Credits.
Smyslem governance není citizen development zastavit. Musí vytvořit bezpečné mantinely a jasnou cestu od osobního experimentu k produkčnímu řešení. Organizace by měla minimálně rozlišit prostředí pro:
Každý produkční agent by měl mít jasně určeného vlastníka, obchodní účel, cílovou skupinu, datovou klasifikaci, zvolený harness, povolené nástroje, provozní rozpočet a způsob monitoringu. Součástí správy by měl být také proces pro agenty, kteří už nejsou používáni, nebo jejich vlastník odešel z organizace.
Data policies mohou řídit, jaké zdroje znalostí či informací, konektory, HTTP endpointy, skills a publikační kanály mohou autoři používat. Mohou také omezit event triggery a automatické evaluace.
Microsoft výslovně uvádí, že event triggery může být vhodné blokovat nejen kvůli riziku úniku dat, ale také kvůli nežádoucí spotřebě nebo vyčerpání kvót.
Event trigger může agenta aktivovat bez přímého požadavku uživatele. Například trigger spuštěný každých deset minut posílá agentovi vstup při každém běhu a jeho aktivita se započítává do spotřeby.
Vhodným design principem proto může být předběžná filtrace pomocí Power Automate. Deterministický flow nejprve ověří, zda má událost skutečný význam. Agenta zavolá pouze tehdy, když je potřeba reasoning, práce s dokumentem nebo řešení výjimky.
FinOps u agentů nezačíná kontrolou faktury. Začíná už rozhodnutím, jakou technologii pro daný scénář použít.
Před zahájením vývoje je vhodné odhadnout:
Microsoft pro tento účel poskytuje Agent Usage Estimator, který umožňuje odhadovat měsíční spotřebu Copilot Credits pro více agentů a scénářů. Nejde o závazný cenový kalkulátor, ale o nástroj pro plánování kapacity a ověření business case. V době přípravy článku Agent Usage Estimator ještě neobsahoval GitHub Copilot harness.
Po nasazení lze spotřebu sledovat v analytice Copilot Studia a v Power Platform admin center. Administrátoři mají k dispozici informace o spotřebovaných kreditech, produktech, funkcích a prostředích, ve kterých spotřeba vznikla.
Samotný počet kreditů ale neříká, zda je agent drahý nebo levný. Náklady je potřeba porovnat s hodnotou výsledku.
Lepšími ukazateli proto mohou být:
Copilot Studio nabízí také možnosti odhadu časových a finančních úspor, které mohou pomoci porovnat nový proces s původním způsobem práce.
GitHub Copilot harness výrazně rozšiřuje možnosti Copilot Studia. Není ale náhradou za všechny existující agenty a automatizace.
Pro základní rozhodování lze použít následující pravidla:
GitHub Copilot harness není pouze další technickou funkcí. Posouvá hranici mezi klasickou automatizací a agentní prací. Umožňuje řešit procesy, které byly pro tradiční flows příliš proměnlivé nebo složité, současně ale vyžaduje jiný přístup k architektuře, testování a řízení nákladů.
Nejdůležitější otázka proto není, zda použít nový harness. Důležité je vědět, kde jeho autonomie přinese vyšší hodnotu než to, kolik bude stát.
Pomůžeme vám připravit vhodné scénáře AI pro vaše M365 Copilot prostředí.
Pomůžeme vám připravit vhodné scénáře AI pro vaše M365 Copilot prostředí.
