Co jsme se naučili při nasazení ChatGPT Apps SDK

• Apps SDK je praktickou volbou, pokud potřebujete brzy spustit pracovní postup v ChatGPT nebo si v něm chcete nástroje vyzkoušet, než investujete do vlastní sady agentů. Pokud potřebujete mít pod kontrolou každý aspekt chování agenta, obvykle vhodnou volbou není.

• Apps SDK zvolte, pokud má být hlavním rozhraním ChatGPT a chcete nástroje doplnit menšími prvky uživatelského rozhraní, aniž byste vytvářeli celý chatovací produkt. Vlastní sadi agentů zvolte, pokud potřebujete důsledně řídit průběh, paměť, prompty a zápisy.

• Apps SDK se hodí pro produkty kombinující chat s několika krátkými kroky v uživatelském rozhraní. Produkt nasadíte rychleji, ale vzdáte se části kontroly.

• Nám se osvědčily jednoznačné nástroje, jasně definované chování widgetů a zřejmé další kroky. Průběh jsme určovali podle nich, ne podle LLM. Model byl nejužitečnější při vysvětlování výsledků, o nichž už systém rozhodl.

• Níže se dozvíte, jak se rozhodnout a co se osvědčilo či neosvědčilo.

Většina týmů stále provozuje pouze pilotní projekty AI nebo ji nasazuje k okrajovým účelům s nízkým rizikem i přínosem. Jen málo týmů nasadí produkt zásadní pro chod firmy, který uživatelé používají každý týden. ChatGPT Apps SDK může tento nedostatek překlenout, pokud chcete řešení začlenit do ChatGPT, místo abyste celého asistenta vytvářeli sami.

Naše poznatky vycházejí ze spolupráce s klientem, jehož požadavky směřovaly k využití ChatGPT jako hlavního rozhraní a k rychlému řešení, které nevyžadovalo financovat plně zakázkový chatovací produkt.

Apps SDK toto zadání splňovalo, protože klient potřeboval:

• Žádný samostatný chatovací produkt, který by musel vytvořit a hostovat – chtěl oslovit uživatele v ChatGPT, ne vytvářet další samostatné rozhraní asistenta.

• Chat a malé uživatelské rozhraní pro konkrétní úlohy – několik cílených kroků ve widgetu, ne druhý plnohodnotný produkt v rámci pracovního postupu.

• Funkce backendu zpřístupněné prostřednictvím nástrojů MCP – standardní volání nástrojů, ne vlastní běhové prostředí agenta spravované od začátku do konce.

• Objevitelnost v ChatGPT – uživatelé mají pracovní postupy najít tam, kde už pracují.

Během vývoje jsme tato rozhodnutí průběžně ověřovali s klientem. Stále však platí určitý kompromis: pokud relaci hostuje ChatGPT, nemáte pod kontrolou vnější běhové prostředí. Můžete je usměrňovat, ale ne zcela ovládat.

Aplikace využívající Apps SDK propojuje tři prvky:

1. Běhové prostředí agenta v ChatGPT

2. Vaše nástroje MCP

3. Uživatelské rozhraní vašeho widgetu

Praktický průběh:

1. Uživatel o něco požádá ChatGPT.

2. ChatGPT může zavolat některý z vašich nástrojů MCP.

3. Váš server vrátí strukturovaný výsledek nástroje.

4. ChatGPT výsledek přečte a rozhodne o dalším kroku: dalších voláních nástrojů, odpovědi uživateli nebo obojím. Pokud jste k danému nástroji připojili widget, může se v tomto kole zobrazit.

5. Uživatel pokračuje v chatu nebo ve widgetu (navazujícím textem, volbou či voláním nástroje spuštěným z widgetu). Tím se aktualizuje vlákno, ChatGPT spustí další kolo a kroky 2–4 se opakují, dokud není úloha hotová.

Právě tato kombinace chatu, akcí backendu a krátkých kroků v uživatelském rozhraní je podstatou řešení. Zároveň to znamená, že nejkřehčími místy jsou předávky mezi chatem, nástroji a uživatelským rozhraním.

Nemusíte od základů vytvářet chatovací rozhraní, propojení nástrojů, způsoby ověřování ani obálku widgetu. U mnoha produktů to výrazně zkracuje dobu vývoje, takže se můžete soustředit na doménovou logiku a bezpečnostní mantinely.

Vývoj uvnitř ChatGPT není totéž jako provoz vlastního agenta. Nejtěžší částí projektu nebyly triky s prompty. Šlo o to popsat nástroje, widgety a další kroky natolik jednoznačně, aby model a uživatelské rozhraní zůstaly sladěné.

Apps SDK nabízí jinou podobu produktu než běžný frontend, proto je důležité vědět, pro jaké situace se hodí nejlépe.

Apps SDK použijte, když chcete

• Rychle nasadit pracovní postup v ChatGPT.

• Nechat konverzaci hostovat v ChatGPT.

• Kombinovat přirozený jazyk s několika cílenými kroky v uživatelském rozhraní.

• Vyhnout se vývoji vlastního chatovacího rozhraní, kontejneru agenta a mechanismu objevování.

Poslední bod je důležitý, pokud vaši uživatelé už běžně pracují v ChatGPT.

Pokud potřebujete, vytvořte vlastního agenta

• Pevný postup krok za krokem, který lze vynutit v kódu.

• Vlastní uživatelské rozhraní a potvrzovací proces, nad kterým máte kompletní kontrolu.

• Vlastní model paměti a stavu.

• Chování, které musí být předvídatelné při každém spuštění.

• Trasování, protokoly a metriky agenta.

Pokud jsou plánovač, systémové prompty a celý pracovní postup vaším produktem, obvykle se lépe hodí vlastní sada.

Během spolupráce se stále vracelo jedno slovo: kontrola. Na jedné straně rychlost a známé hostitelské prostředí, na druhé jen částečná správa běhového prostředí. Tento kompromis klient přijal, když dal před úplnou správou sady přednost kontaktu s uživateli v ChatGPT.

Ideální průběh zní jednoduše: uživatel zadá požadavek, nástroj se spustí, data se vrátí a ve chvíli, kdy je třeba zvolit možnost, se zobrazí widget.

V praxi bylo problémem předávání. Widget není pouhá dekorace. Jakmile se zobrazí, změní to, co model vidí a co udělá dál. S akcemi widgetu zacházejte jako s pojmenovanými událostmi, ne jako s volnou konverzací.

Technologická sada použitá při spolupráci byl přímočarý: FastMCP, Pydantic, React a TypeScript. Jejich integrace proběhla bez problémů. Skutečnou výzvou bylo sladit model, nástroje a uživatelské rozhraní v tom, co se má stát dál.

Zajistěte, aby byla každé předání zřejmé

Přestali jsme s výsledky nástrojů zacházet jako s nezpracovanými daty backendu. Každé vrácení hodnoty se stalo předáním.

Kvalitní výsledek nástroje:

• Poskytne widgetu vše potřebné k vykreslení.

• Poskytne ChatGPT strukturovaná fakta, o něž může opřít odpověď.

• Pokud to postup vyžaduje, uvede, co se má stát dál, aby model nemusel hádat.

Akce widgetu by do vlákna neměly posílat vágní text. Měly by uvést, co uživatel udělal a co se má stát dál.

Jakmile byly předávky jasné, spolehlivost se zvýšila.

Model se řídí krátkými a jasnými pokyny, jsou-li součástí výstupu nástroje a akcí widgetu.

Níže je jednoduchá struktura Pydantic, kterou jsme použili. Pole output obsahuje strukturovaná data potřebná k zobrazení widgetu a fakta, která má ChatGPT v relaci použít. Pole agent_directions obsahuje krátký pokyn, co má asistent udělat dál. Pole reason je volitelné.

1from typing import Generic, TypeVar2
3from pydantic import BaseModel4
5T = TypeVar("T")6
7class AgentDirections(BaseModel):8 assistant_instruction: str9 reason: str | None = None10
11class ToolResults(BaseModel, Generic[T]):12 agent_directions: AgentDirections13 output: T

Udržujte widgety malé

Osvědčené widgety zprostředkovaly jediné rozhodnutí a poté předaly řízení zpět. Krátké seznamy, potvrzení nebo kompaktní obrazovka kontroly fungovaly lépe než proměna widgetu v malou aplikaci. Trocha logiky ve widgetu, například jednoduché ověření nebo pevně daný další krok, přesto pomohla, když jsme chtěli dosáhnout determinističtějšího průběhu.

Třetí osoba ve zprávách widgetu

Navazující zprávy widgetu jsme přestali psát jako chatové zprávy uživatele („Vybral jsem…“, „Potvrdil jsem…“). Psali jsme je jako krátká hlášení o tom, co uživatel udělal („Uživatel vybral…“, „Uživatel potvrdil…“). Tento přístup jsme vyzkoušeli, protože ChatGPT přidával zprávy widgetu jako zprávy nástroje, nikoli uživatele.

Přímé akce, když je další krok zřejmý

Pokud tlačítko jasně určovalo další volání nástroje, osvědčilo se spouštět je přímo z widgetu namísto vynucení dalšího kola chatu. To platí pouze v případě, že další volání nástroje nepotřebuje vstupy z ChatGPT.

Pomohlo to vynutit deterministický průběh a zkrátilo odezvu, protože odpadlo další kolo chatu.

Zpracování chyb

Když volání nástroje selhalo, vrátili jsme správné chybové kódy MCP a stručná, srozumitelná hlášení nástroje. ChatGPT tak při neúspěšném volání obdržel konkrétní informaci, podle níž mohl uživateli vysvětlit problém a případně zvolit rozumný další krok.

Správa kontextu nástrojů

Stav relace jsme uchovávali na svém serveru. ChatGPT posílá s voláním nástroje kontext omezený na danou relaci. Ve FastMCP jsme každému nástroji přidali parametr kontextu, aby obslužná rutina mohla tento stav číst a aktualizovat.

• Stabilní ID a dřívější výsledky jsme ukládali do relace, místo abychom žádali ChatGPT, aby je při každém volání znovu předával jako argumenty nástroje.

• Když se objevily smyčky volání nástrojů, mohli jsme zachytit duplicitní volání a ve výsledku nástroje vrátit jasnou chybu.

• Protokoly relace zůstávaly u nás pro účely ladění a podpory.

Zpočátku jsme zobrazili widget, předpokládali, že model vše „pochopil“, a čekali na správné navazující volání nástroje. Někdy k němu došlo. Často však ne.

Bez jasné předávky mohl ChatGPT shrnout situaci, když jsme chtěli provést akci, požádat uživatele, aby zopakoval svou volbu, nebo pokračovat v plánování, když už měl skončit.

Řešením bylo další krok výslovně uvést ve strukturovaných výstupech a datech widgetu, nikoli doufat, že jej model odvodí.

Podle dokumentace Apps SDK jsme se pokusili důmyslně rozdělit odpovědi mezi výstup nástroje, skrytá metadata a text chatu. Ve widgetech jsme však skrytá metadata nemohli číst. Proto jsme tento přístup nemohli použít.

Dokumentace Apps SDK popisuje nástroje, které lze skrýt ze seznamu nástrojů agenta, aby je nevybíral, a přitom je stále volat z widgetu. Když jsme viditelnost nastavili pouze pro aplikaci, přestaly být tyto nástroje dostupné i z widgetu, nejen z agenta. Nikdy se nám nepodařilo nastavit prostředí tak, aby agent nástroj neviděl, ale widget ano.

Ticho nebo obecné hlášení „úspěchu“, když se nic užitečného nestalo, bylo horší než přímá chyba. Selhání nástrojů a widgetů jsme proto považovali za plnohodnotné výstupy: pokud krok nemohl pokračovat, srozumitelně jsme to uvedli a vrátili explicitní chybu, místo abychom uživatele nechali hledět na vykreslený widget, který je neposunul dál. Tím se zlepšila použitelnost a chování modelu bylo spolehlivější.

Pokud chcete vytvořit pracovní postup v ChatGPT s menším množstvím vlastního vývoje platformy, Apps SDK představuje praktické řešení. Část kontroly vyměníte za rychlost a možnost oslovit uživatele tam, kde už pracují.

Pokud potřebujete ovládat každou větev postupu, uživatelské rozhraní i rozhodování o každém kroku, počítejte od začátku s vlastní sadou agentů. Vývoj pouze uvnitř ChatGPT vám pravděpodobně časem přestane stačit.

Apps SDK můžete také použít k provozu svého serveru MCP uvnitř ChatGPT, než sami vytvoříte chat, ověřování a infrastrukturu agenta. Až to produkt bude vyžadovat, přejdete na vlastní sadu.

Další krok pro týmy ve stejné situaci: vyberte jeden pracovní postup s jasným výsledkem, popište předávky mezi chatem, nástroji a widgety a před rozsáhlejším laděním promptů důkladně otestujte opakované pokusy a chyby.