Ang natutuhan namin sa pag-release gamit ang ChatGPT Apps SDK

• Praktikal na opsyon ang Apps SDK kung kailangan mo agad ng workflow sa ChatGPT, o kung gusto mong subukan doon ang iyong mga tool bago mamuhunan sa custom na agent stack. Kung kailangan mong kontrolin ang bawat hakbang ng pagkilos ng agent, karaniwan ay hindi ito ang tamang opsyon.

• Piliin ang Apps SDK kung ChatGPT ang dapat maging pangunahing interface at gusto mo ng mga tool at kaunting UI nang hindi bumubuo ng buong chat product. Piliin ang sarili mong agent stack kung kailangan mo ng mahigpit na kontrol sa daloy, memory, mga prompt, at pagsusulat ng data.

• Ang Apps SDK ay angkop sa mga produktong pinagsasama ang chat at ilang maiikling hakbang sa UI. Mas mabilis kang makakapag-release, pero may isinusuko kang kontrol.

• Ang gumana para sa amin ay malinaw na mga tool, malinaw na pagkilos ng widget, at malinaw na mga susunod na hakbang. Sa mga iyon kami umasa para mabuo ang daloy, hindi sa LLM. Pinakanakatulong ang modelo sa pagpapaliwanag ng mga resultang napili na ng system.

• Sa ibaba: kung paano pumili, at pagkatapos ay kung ano ang gumana at hindi gumana.

Karamihan ng mga team ay nagpapatakbo pa rin ng mga AI pilot o gumagamit ng AI para sa mga di-pangunahing gamit na mababa ang panganib at pakinabang. Iilan ang naglalabas ng produktong kritikal sa negosyo na ginagamit ng mga tao linggo-linggo. Isang paraan ang ChatGPT Apps SDK para punan ang puwang na iyon kung layunin mong mapabilang sa ChatGPT sa halip na ikaw mismo ang bumuo ng buong assistant.

Ang mga natutuhan namin ay mula sa isang proyekto para sa kliyente kung saan itinuro ng mga requirement ang ChatGPT bilang pangunahing interface at isang mabilis na landas na hindi nangangailangang pondohan nila ang isang ganap na custom na chat product.

Para sa brief na iyon, tumugma ang Apps SDK dahil kailangan ng kliyente ang sumusunod:

• Walang nakalaang chat product na bubuuin at iho-host—gusto nilang maabot ang mga user sa loob ng ChatGPT, hindi ng isa pang hiwalay na balangkas ng assistant.

• Chat at maliit na UI para sa partikular na gawain—ilang nakatuong hakbang sa widget, hindi isa pang buong produkto sa loob ng workflow.

• Backend behavior na inilalantad sa pamamagitan ng mga MCP tool—karaniwang tool calling, hindi custom na agent runtime na sila ang ganap na namamahala.

• Discovery sa loob ng ChatGPT—dapat makita ng mga user ang workflow kung saan sila nagtatrabaho na.

Kasama ang kliyente, pinagtibay namin ang mga pasyang iyon habang bumubuo. May kapalit pa rin ito: kapag ChatGPT ang nagho-host ng session, hindi mo kontrolado ang panlabas na runtime. Ginagabayan mo ito, ngunit hindi mo ito ganap na kontrolado.

Pinag-uugnay ng Apps SDK app ang tatlong bagay:

1. Agent runtime ng ChatGPT

2. Iyong mga MCP tool

3. Iyong widget UI

Aktuwal na daloy:

1. May hinihiling ang user sa ChatGPT.

2. Maaaring tawagin ng ChatGPT ang isa sa iyong mga MCP tool.

3. Nagbabalik ang iyong server ng naka-structure na resulta ng tool.

4. Binabasa ng ChatGPT ang resulta at nagpapasya sa susunod na hakbang: higit pang tool call, tugon sa user, o pareho. Kung nag-attach ka ng widget sa tool na iyon, maaari itong lumabas sa turn na ito.

5. Nagpapatuloy ang user sa chat o widget—sa pamamagitan ng follow-up na text, pagpili, o tool call na sinimulan ng widget. Ina-update nito ang thread; nagpapatakbo ang ChatGPT ng panibagong turn at inuulit ang hakbang 2–4 hanggang matapos ang gawain.

Ang kombinasyong iyon ng chat, mga aksyon sa backend, at maiikling hakbang sa UI ang mismong layunin. Nangangahulugan din itong ang madaling masirang bahagi ay ang mga handoff sa pagitan ng chat, mga tool, at UI.

Hindi mo kailangang buuin mula sa simula ang chat UI, pagkakabit ng mga tool, mga pattern ng authentication, o widget shell. Para sa maraming produkto, malaki ang nababawas nito sa oras ng pagbuo kaya makapagtutuon ka sa domain logic at mga guardrail.

Ang pagbuo sa loob ng ChatGPT ay hindi katulad ng pagpapatakbo ng sarili mong agent. Hindi mga taktika sa prompt ang mahirap na bahagi ng proyekto. Ang mahirap ay gawing sapat na malinaw ang mga tool, widget, at susunod na hakbang para manatiling magkatugma ang modelo at UI.

Nagbibigay ang Apps SDK ng naiibang anyo ng produkto kumpara sa karaniwan mong frontend, ngunit mahalagang malaman kung saang mga sitwasyon ito pinakamainam.

Gamitin ang Apps SDK kung gusto mong

• Mabilis na mag-release ng workflow sa ChatGPT.

• Hayaan ang ChatGPT na mag-host ng pag-uusap.

• Pagsamahin ang natural na wika at ilang nakatuong hakbang sa UI.

• Iwasang bumuo ng sarili mong chat interface, agent container, at discovery system.

Mahalaga ang huling puntong iyon kapag palagi nang nasa ChatGPT ang iyong mga user.

Bumuo ng sarili mong agent kung kailangan mo ng

• Nakapirming sunod-sunod na daloy na maipapatupad mo sa code.

• Custom na UI at proseso ng pagkumpirma na ganap mong kontrolado.

• Sarili mong modelo para sa memory at state.

• Pagkilos na dapat mahulaan sa bawat pagtakbo.

• Mga trace, log, at metric para sa agent.

Kung ang planner, mga system prompt, at buong workflow ang iyong produkto, karaniwang mas angkop ang custom na stack.

Sa proyekto namin, paulit-ulit na bumabalik ang salitang kontrol: bilis at pamilyar na host sa isang panig; bahagyang pagmamay-ari sa runtime sa kabila. Iyon ang kapalit na tinanggap ng kliyente nang unahin nilang abutin ang mga user sa ChatGPT kaysa kontrolin ang buong stack.

Mukhang madali ang ideal na daloy: humihiling ang user, tumatakbo ang tool, bumabalik ang data, at lumalabas ang widget kapag kailangang pumili.

Sa aktuwal, ang mga handoff ang naging problema. Hindi dekorasyon ang widget. Kapag nasa screen na ito, binabago nito ang nakikita at susunod na ginagawa ng modelo. Ituring ang mga aksyon sa widget bilang pinangalanang event, hindi maluwag na chat.

Simple ang stack sa proyekto: FastMCP, Pydantic, React, at TypeScript. Walang problema sa pagsasama ng mga iyon. Ang mahirap ay pagtugmain ang modelo, mga tool, at UI sa kung ano ang susunod na mangyayari.

Gawing malinaw ang bawat handoff

Hindi na namin itinuring ang mga resulta ng tool bilang hilaw na backend payload. Naging handoff ang bawat ibinalik na resulta.

Ang mahusay na resulta ng tool ay:

• Nagbibigay sa widget ng kailangan nito para mag-render.

• Nagbibigay sa ChatGPT ng mga naka-structure na fact na pagbabatayan ng tugon.

• Kapag kailangan ng daloy, sinasabi nito kung ano ang susunod na dapat mangyari para hindi na manghula ang modelo.

Hindi dapat magpadala ang mga aksyon sa widget ng malabong paliwanag pabalik sa thread. Dapat sabihin ng mga ito kung ano ang ginawa ng user at kung ano ang susunod na dapat mangyari.

Naging mas maaasahan ang system nang luminaw ang mga handoff.

Sinusunod ng modelo ang maikli at malinaw na mga tagubilin kapag nasa output ng tool at mga aksyon sa widget ang mga ito.

Nasa ibaba ang maliit na Pydantic structure na ginamit namin. Nilalaman ng output field ang naka-structure na data na kailangan ng widget kapag nagpapakita ka nito, at ang mga fact na dapat gamitin ng ChatGPT sa session. Naglalaman ang agent_directions field ng maikling linyang nagsasabi kung ano ang susunod na dapat gawin ng assistant. Opsyonal ang Reason.

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

Panatilihing maliit ang mga widget

Isang desisyon lang ang pinangangasiwaan ng mga widget na gumana, at pagkatapos ay ibinabalik ng mga ito ang kontrol. Mas gumana ang maiikling listahan, pagkumpirma, o simpleng review screen kaysa gawing mini app ang widget. Nakatulong pa rin ang kaunting logic sa widget, gaya ng simpleng validation o nakapirming susunod na hakbang, kapag gusto naming maging mas tiyak ang daloy.

Ikatlong panauhan sa mga mensahe ng widget

Hindi na namin isinulat ang mga follow-up ng widget na parang chat mula sa user (“I selected…,” “I confirmed…”). Isinulat namin ang mga ito bilang maiikling ulat tungkol sa ginawa ng user (“The user selected…,” “The user confirmed…”). Sinubukan namin ang paraang ito dahil idinaragdag ng ChatGPT ang mga mensahe ng widget bilang tool message sa halip na user message.

Mga direktang aksyon kapag malinaw ang susunod na hakbang

Kung malinaw na ipinahihiwatig ng button ang susunod na tool call, mas gumana ang direktang pagpapatakbo nito ng widget kaysa pilitin ang isa pang chat turn. Nalalapat lang ito kung hindi kailangan ng susunod na tool call ng input mula sa ChatGPT.

Nakatulong ito sa pagpapatupad ng mga tiyak na daloy at nagpababa rin ng latency dahil naiwasan ang isa pang chat turn.

Pangangasiwa ng error

Kapag nabigo ang tool call, ibinalik namin mula sa tool ang tamang mga MCP error code at maiikli at simpleng mensahe. Sa gayon, may totoong mababasa ang ChatGPT tungkol sa mga nabigong call para maipaliwanag nito ang problema sa user at/o pumili ng makatuwirang susunod na hakbang.

Pamamahala ng context ng tool

Pinanatili namin sa aming server ang state ng session. Nagpapadala ang ChatGPT ng context na saklaw ng session kasama ng mga tool call; sa FastMCP, binigyan namin ang bawat tool ng Context parameter para mabasa at ma-update ng handler ang state na iyon.

• Nasa session ang mga stable ID at naunang resulta sa halip na hilingin sa ChatGPT na ipasa muli ang mga ito bilang tool argument sa bawat call.

• Kapag nagkaroon ng mga loop sa tool call, natutukoy namin ang mga dobleng call at nakapagbabalik ng malinaw na error sa resulta ng tool.

• Nanatili sa amin ang mga session log para sa pag-debug at suporta.

Noong una, nagpapakita kami ng widget, ipinapalagay na “naintindihan” iyon ng modelo, at naghihintay sa tamang follow-up na tool call. Minsan, nangyayari ito. Madalas, hindi.

Kung walang malinaw na handoff, maaaring magbuod ang ChatGPT kahit aksyon ang gusto namin, hilingin sa user na ulitin ang pinili, o patuloy na magplano kahit dapat nang huminto.

Ang solusyon ay tahasang ilagay ang susunod na hakbang sa mga naka-structure na output at widget payload, hindi umasa na mahihinuha iyon ng modelo.

Sinubukan naming maging maparaan sa paghahati ng mga tugon sa output ng tool, nakatagong metadata, at chat text ayon sa dokumentasyon ng Apps SDK. Ngunit hindi namin mabasa sa mga widget ang nakatagong metadata. Kaya hindi namin ito nagamit.

Inilalarawan sa dokumentasyon ng Apps SDK ang mga tool na maaari mong alisin sa listahan ng mga tool ng agent para hindi nito piliin ang mga iyon, habang natatawag pa rin ang mga ito mula sa widget. Nang itinakda namin ang visibility sa app-only, hindi na rin magamit ang mga tool na iyon mula sa widget, hindi lang mula sa agent. Hindi kami nakabuo ng setup kung saan hindi nakikita ng agent ang isang tool ngunit nakikita pa rin iyon ng widget.

Mas masama ang katahimikan o pangkalahatang mensaheng “tagumpay” kapag walang kapaki-pakinabang na nangyari kaysa sa direktang error. Kaya itinuring namin ang mga pagkabigo ng tool at widget bilang mga pangunahing output: kung hindi makapagpatuloy ang isang hakbang, sinabi namin ito sa simpleng pananalita at nagbalik ng tahasang error, sa halip na hayaang nakatitig ang mga user sa widget na nag-render ngunit hindi sila naiusad. Napahusay nito ang usability at ginawang mas maaasahan ang pagkilos ng modelo.

Kung ang layunin mo ay magkaroon ng workflow sa ChatGPT na mas kaunti ang custom na platform work, praktikal na paraan ang Apps SDK para makamit iyon. Ipinagpapalit mo ang kaunting kontrol para sa bilis at para maabot ang mga user kung saan sila nagtatrabaho na.

Kung kailangan mong kontrolin ang bawat sangay ng daloy, ang UI, at kung sino ang nagpapasya sa bawat hakbang, planuhin sa simula pa lang ang sarili mong agent stack. Malamang na hindi magtatagal ay kulangin sa iyo ang pagbuo lamang sa loob ng ChatGPT.

Maaari mo ring gamitin ang Apps SDK para patakbuhin ang iyong MCP server sa loob ng ChatGPT bago mo mismo buuin ang chat, authentication, at pagkakabit ng agent, at pagkatapos ay lumipat sa sarili mong stack kapag kailangan na ng produkto.

Susunod na hakbang para sa mga team na nasa ganitong kalagayan: pumili ng isang workflow na may malinaw na resulta, isulat ang mga handoff sa pagitan ng chat, mga tool, at widget, at pagkatapos ay masusing subukan ang mga retry at error bago maglaan ng maraming oras sa pag-tune ng prompt.