Připravte agenty a pracovní postupy pro týmy
Produkční agenti mají řešit konkrétní úkoly s ověřenou konfigurací, workflow, záměrně vybranými daty, nástroji, prompty, přístupem a monitoringem. Vyhněte se publikování obecných asistentů, kteří mohou vidět příliš mnoho a nemají vlastníka.
Výchozí hodnoty při založení organizace
Před vytvořením prvních agentů zkontrolujte čtyři samostatné výchozí hodnoty organizace a workspace. Default LLM connection dodává modelové připojení podporovaným cestám vytváření; Default agent a Default agent for quick actions vybírají agenty pro různé vstupy do produktu. Workspace si vytváří vlastního výchozího agenta. Změna výchozího připojení nepřepíná existující agenty.
Při založení nové organizace vznikne také Quick Actions Agent, pokud existuje potřebná systémová šablona. Nastaví se jako quick-actions default, má povolený Desktop App, organizace dostane Use a tým Admins Write. Chybí-li systémová šablona, tento agent se nevytvoří. Nejde o automatické doplnění do starších organizací. V existující organizaci vybírejte agenta patřícího do této organizace s povoleným Desktop App. Viz Quick Actions při onboardingu.
Vytvoření prvního pilotního agenta od začátku
Pro prvního agenta vyberte konkrétní práci zaměřenou na čtení. Příklad Tender Review — Pilot prochází schválené zadávací podklady, vytahuje požadavky a termíny, označuje mezery a navrhuje upřesňující otázky. Nepodává nabídku, nekontaktuje dodavatele ani nemění externí systém.
Prvního agenta vytvořte od začátku, aby vlastník prošel všechna nastavení:
- Otevřete Agents, zvolte Create Agent a zadejte název, popis a odpovědného vlastníka, ze kterých je jasný konkrétní úkol.
- V Configuration vyberte schválené AI Connection a Model Name. Pokud model podporuje Reasoning effort, nastavte Medium. Pro první hodnocení ponechte výchozí teplotu, maximální délku, presence penalty, frequency penalty a Agent harness.
- Přidejte System Message s rolí, hranicí zdrojů, očekávaným výstupem, eskalací a zakázanými akcemi. Upravte hodnoty v hranatých závorkách v příkladu níže.
- Připojte ověřenou soukromou kolekci z přípravy prvních pilotních dat.
- Platform Tools ponechte vypnuté, pokud je scénář prokazatelně nepotřebuje. V tomto příkladu povolte Grounding with Google Search jen pro aktuální veřejné ověření a Web scraper jen pro schválené veřejné adresy. Nesouvisející Platform Tools a připojení s právem zápisu nepřipojujte.
- Přiřaďte pouze skills popisující opakovatelné kroky, například extrakci povinných požadavků, porovnání nabídky s požadavky a návrh upřesňujících otázek. Stabilní roli a hranice držte v System Message; opakovatelné postupy a jejich nástroje ve skills.
- Agenta ponechte Private a otestujte známou odpověď, chybějící odpověď, rozporné dokumenty, požadavek mimo rozsah a instrukci k zakázané akci.
- Ověřte dohledatelnost odpovědí v pilotních podkladech, přiznanou nejistotu a správné argumenty i výsledky použitých nástrojů v Tool Executions.
- Před laděním parametrů modelu opravte prompt, data nebo skill. Po úspěšných soukromých testech použijte bezpečné pilotní sdílení, dejte jednomu týmu Can Use a vlastníkům ponechte úpravy.
Jsi Tender Review Pilot pro [společnost nebo tým].
Procházej pouze schválené zadávací podklady připojené k tomuto agentovi. Vytahuj povinné požadavky, termíny, hodnoticí kritéria, rizika a otevřené otázky. U každého podstatného zjištění uveď zdrojový dokument a dostupné umístění.
Pokud důkazy chybí, jsou zastaralé nebo rozporné, řekni to a požádej o lidskou kontrolu. Nevymýšlej požadavky, nepodávej nabídku, nekontaktuj dodavatele, neměň externí systémy a nezpřístupňuj materiály mimo pilotní publikum. Schválené veřejné webové nástroje použij jen při výslovném požadavku na aktuální externí ověření a tyto důkazy označ odděleně od zadávacích podkladů.
Kontrolní seznam produkčního agenta
Před sdílením agenta s týmem zkontrolujte:
- Název a popis: uživatelé mohou identifikovat úkol, který vykonává.
- Vlastník: jedna osoba nebo tým vlastní změny a incidenty.
- Připojení modelu: model/poskytovatel je schválen pro pracovní zátěž.
- Výzva: role, hranice, styl výstupu, eskalace a chování při odmítnutí jsou explicitní.
- Data: sbírky dat, paměť, soubory a připojené zdroje jsou záměrné.
- Sdílené nástroje: nástroje pro služební účet jsou schváleny pro publikum agenta.
- Soukromé nástroje: nástroje vlastněné uživateli jsou vyžadovány pouze tehdy, když je důležitý kontext uživatele.
- Platform Tools: pokročilé nástroje jsou povoleny pouze tehdy, když je potřebuje úkol.
- Přístup: soukromý pro vývoj, týmově sdílený pro pilot, organizace široce pouze po schválení.
- Monitoring: konverzace, zpětná vazba, provádění nástrojů, analytika a historie mají vlastníka.
Problémy s konfigurací agenta
| Příznak | Pravděpodobná příčina | Akce administrátora |
|---|---|---|
| Agent říká, že nemá data | Sbírka dat, paměť nebo připojení není připojeno nebo není sdíleno | Připojte zdroj a otestujte získání |
| Agent nemůže zavolat nástroj | Chybí připojení, soukromé připojení patří jinému uživateli, nebo je funkce zakázána | Zkontrolujte přidělené nástroje a správu připojení |
| Agent žádá o schválení příliš často | Funkce zápisu jsou správně v režimu potvrzení, nebo je příliš mnoho operací modelováno jako zápisy | Udržujte potvrzení pro rizikové akce; zjemněte návrh nástroje pro bezpečné čtení |
| Agent dává nekonzistentní odpovědi | Výzva je příliš široká, zdroj dat je zastaralý, nebo nastavení modelu je nevhodné | Zúžte výzvu, obnovte data a otestujte s známými případy |
| Uživatelé mohou upravovat produkční chování | Tým má přístup k úpravám/zápisům místo přístupu k použití | Omezte přístup k úpravám na vlastníky |
Příprava pracovního postupu
Používejte pracovní postupy pro opakované procesy s předvídatelnými kroky. Pracovní postup by měl mít známé vstupy, jasné závislosti uzlů, bezpečné chování při chybách a cestu zpět pro zápisové akce.
Před publikováním:
- Pojmenujte pracovní postup podle obchodního procesu.
- Definujte požadované vstupy a očekávaný výstup.
- Používejte uzly pro čtení před uzly pro zápis, kdykoli je to možné.
- Udržujte uzly pro zápis za potvrzením, když je dopad vysoký.
- Testujte na neprodukčních záznamech.
- Zkontrolujte provádění nástrojů pro každou akci připojení.
- Zkontrolujte historii pracovního postupu po každé významné úpravě.
- Sdílejte s jedním pilotním týmem před rozšířením přístupu.
Spouštění schváleného workflow agentem
Otestované workflow uložte a aktivujte. Pilotnímu agentovi zapněte Configuration → System Tools → Workflows, vyberte dané workflow a uložte přes Submit. Pokud nemá běžet pravidelně, ponechte pilotní workflow v režimu Schedule → On Demand.
Výslovně požádejte o jeden běh, ověřte potvrzení nástroje a potom Build → Workflows → Runs a výstupy uzlů. Potvrzení dokládá jen předání ke spuštění; nepotvrzuje dokončení a nevrací výsledek do chatu. Před použitím vstupu ověřte výstupy spouštěče a mapování uzlů. Přístup, vstup a ochranu před rekurzí popisuje spouštění workflow agentem. Task created zůstává samostatnou událostní cestou.
Převod příjmu úkolů na workflow
Původní volby výchozího agenta a automatického spouštění v task workspace už neřídí zpracování úkolů. Výchozí agent chatu workspace má jiný účel. Požadované chování převeďte na Task created → Agent → Update task a spouštěč připojte ke správnému prostoru. Agenta vyberte na uzlu Agent a namapujte prompt i ID úkolu. Původní nastavení pracovního prostoru toto workflow automaticky nevytvoří.
Testujte vytvořením jednoho nového úkolu; ruční Run není pro workflow Task created dostupné. Ověřte běh workflow, vybraného agenta a výsledný stav úkolu. Výstup vyžadující kontrolu přepněte do Review. Vlastník workflow potřebuje zobrazení úkolů pro spouštěč a právo úprav/zápisu pro vytváření nebo aktualizaci úkolů. Viz Workflow nad úkoly.
Otestované workflow sdílejte výběrem přístupu v builderu. Sdílení s vlastními týmy a s celou organizací má odlišná oprávnění; stejný okruh uživatelů ověřte samostatně u pracovního prostoru úkolů.
Příklady pracovních postupů
| Pracovní postup | Doporučené kontroly |
|---|---|
| Žádost o podporu -> problém v Jira -> oznámení na Slacku | Vytvoření v Jira a příspěvek na Slacku vyžadují potvrzení během pilotu |
| Vyhledání obchodu v HubSpotu -> příprava schůzky -> návrh kalendáře | Čtení z CRM může být přímé; aktualizace kalendáře potřebují kontext uživatele nebo potvrzení |
| Příjem incidentu webhooku -> klasifikace -> vytvoření úkolu | Webhook má pojmenovaný API klíč, vzorovou zátěž a plán pro opakování selhání |
| Obnovení dat -> shrnutí -> soubor zprávy | Používejte bezpečné testovací složky a zkontrolujte generované soubory před nasazením do týmu |
Pokud pracovní postup změnil nesprávný záznam
- Pozastavte nebo zúžte sdílení pracovního postupu.
- Otevřete provádění nástrojů a najděte zápisovou akci.
- Zaznamenejte název funkce, argumenty, výsledek, stav schválení, uživatele a časové razítko.
- Zkontrolujte výstup předchozího uzlu, který dodal ID záznamu.
- Potvrďte, zda mělo připojení příliš široká oprávnění.
- Přidejte potvrzení, přísnější parametry nebo validační krok.
- Znovu testujte na bezpečných záznamech.
- Znovu povolte přístup pouze po schválení vlastníka.
Šablony
Používejte šablony pouze poté, co má agent osvědčenou konfiguraci. Šablona může zkopírovat užitečné výzvy, nástroje, předpoklady o datech a Platform Tools do nových agentů, takže špatná šablona rychle šíří problémy.
U existujícího agenta nejprve uložte konfiguraci přes Submit a potom použijte Save as new template. Propojená System Message představuje společné chování: editace přes Library nebo Override existing template ovlivní propojené agenty, ostatní nastavení zůstávají samostatná. Před úpravou týmové šablony ověřte editaci a přístup.
Před publikováním šablony:
- odstraňte testovací přihlašovací údaje a návrhové výzvy,
- potvrďte výchozí přístupy,
- zkontrolujte Platform Tools,
- zdokumentujte zamýšlené publikum,
- vytvořte jednoho agenta ze šablony a otestujte ho od začátku do konce.
Po spuštění pilotu sledujte využití, auditní důkazy a rizika, než rozšíříte přístup.