主導覽

運用 ChatGPT Apps SDK 推出產品的經驗與心得

實際運用 ChatGPT Apps SDK 推出產品的經驗，顯示這套架構適合哪些情境，又有哪些情況需要更多控制權。

執行摘要

  • 如果你需要盡快在 ChatGPT 中推出工作流程，或想先在其中測試工具，再投資打造自訂智慧體技術堆疊，Apps SDK 是務實的選擇。但如果你需要完全掌控智慧體每一步的行為，通常就不適合。

  • 若要以 ChatGPT 作為主要介面，並在不打造完整對話產品的情況下結合工具與少量 UI，請選擇 Apps SDK。若需要嚴密掌控流程、記憶、提示詞與寫入操作，請選擇自己的智慧體技術堆疊。

  • Apps SDK 適合將對話與少數簡短 UI 步驟結合的產品。你能更快推出產品，但會犧牲部分控制權。

  • 我們實證有效的方法，是明確定義工具、小工具的行為和後續步驟。我們依靠這些要素來確立流程，而非依賴 LLM。模型最能發揮價值之處，是解釋系統已經選定的結果。

  • 下文將先說明如何選擇，再分享哪些做法有效、哪些無效。

多數團隊仍停留在 AI 試驗階段，或只將 AI 用於風險與回報皆低的非核心用途。真正推出使用者每週都會接觸的業務關鍵產品者寥寥可數。如果你的目標是進駐 ChatGPT，而非自行打造整套助理，ChatGPT Apps SDK 是縮小這項落差的一種方式。

為何選用 Apps SDK

這些心得來自一次客戶合作：需求明確指向以 ChatGPT 為主要介面，並尋求一條快速路徑，無須投入資金打造完整的客製化對話產品。

依照這項需求，Apps SDK 相當合適，因為客戶需要：

  • 不必打造及託管專用對話產品，他們想透過 ChatGPT 觸及使用者，而不是再做一個獨立的助理介面。

  • 對話加上小型的任務專用 UI，只需幾個用途明確的小工具步驟，不必在工作流程中再加入一套完整產品。

  • 透過 MCP 工具提供後端功能，採用標準工具呼叫，不必自行端到端掌控客製化智慧體執行環境。

  • 可在 ChatGPT 中被使用者發現，讓使用者在原本工作的地方接觸這套工作流程。

我們在開發過程中與客戶一同驗證了這些選擇。這項取捨依然存在：由 ChatGPT 託管工作階段時，外層執行環境並不由你掌控。你可以引導執行流程，卻無法完全控制。

Apps SDK 提供什麼

Apps SDK 應用程式會串連三項要素：

  1. ChatGPT 的智慧體執行環境

  2. 你的 MCP 工具

  3. 你的小工具 UI

實際流程如下：

  1. 使用者向 ChatGPT 提出需求。

  2. ChatGPT 可能會呼叫你的一項 MCP 工具。

  3. 你的伺服器傳回結構化的工具結果。

  4. ChatGPT 讀取結果並決定下一步：繼續呼叫工具、回覆使用者，或兩者並行。如果你為這項工具附加了小工具，小工具就能在這一輪顯示。

  5. 使用者可以繼續在對話或小工具中操作，例如輸入後續文字、做出選擇，或透過小工具觸發工具呼叫。使用者的操作會更新討論串，接著 ChatGPT 執行下一輪，並重複步驟 2 至 4，直到任務完成。

重點就在於結合對話、後端操作和簡短的 UI 步驟，而最脆弱的環節是對話、工具與 UI 之間的交接。

你不必從頭重建對話 UI、工具串接、身分驗證機制或小工具框架。對許多產品而言，這能大幅縮短開發時間，讓你專注於領域邏輯與防護機制。

在 ChatGPT 中開發，並不等於執行自己的智慧體。這個專案的難點不在提示詞技巧。真正的挑戰，是把工具、小工具和後續步驟定義得夠明確，讓模型與 UI 保持一致。

如何選擇

Apps SDK 採用不同於一般前端的產品形態，但務必了解這套架構最適合哪些情境。

適合選用 Apps SDK 的情況

  • 快速推出 ChatGPT 工作流程。

  • 讓 ChatGPT 託管對話。

  • 結合自然語言與少數聚焦的 UI 步驟。

  • 無須自行打造對話介面、智慧體容器，也無須自行解決產品曝光。

如果使用者本來就經常使用 ChatGPT，最後一點尤其重要。

適合自行打造智慧體的情況

  • 需要可在程式碼中強制執行的固定逐步流程。

  • 需要由你端到端掌控的自訂 UI 與確認路徑。

  • 需要自己的記憶與狀態模型。

  • 每次執行的行為都必須可預測。

  • 需要智慧體的追蹤資料、日誌和指標。

如果規劃器、系統提示詞和完整工作流程就是你的產品，自訂技術堆疊通常更合適。

取捨一覽

問題

ChatGPT Apps SDK

自有智慧體

使用體驗位於何處？

ChatGPT 內

你的產品內

由誰執行各個對話步驟？

ChatGPT，由你的工具與 UI 引導

你的智慧體系統

需要建置多少 UI？

對話中用途明確的小工具

依需求而定

對提示詞有多少控制權？

間接控制

完全控制

固定、可重複的流程容易建立嗎？

需要審慎設計

較容易以程式碼強制執行

首次推出所需時間

通常較快

初期通常較慢

由你負責的平台工作

較少

較多

日後改變方向的空間

較少

較多

這次合作中反覆出現的關鍵詞是「控制權」：一端是速度和使用者熟悉的環境，另一端則是對執行環境僅有部分掌控權。客戶優先選擇在 ChatGPT 中接觸使用者，而不是掌控完整技術堆疊，因此接受這項取捨。

難點所在

理想流程聽來很簡單：使用者提出需求、工具執行、資料傳回，遇到需要選擇時便顯示小工具。

實務上的痛點卻是交接。小工具並非裝飾。一旦出現在畫面上，就會改變模型接收的資訊和下一步動作。應將小工具操作視為具名事件，而不是鬆散的對話。

這次合作採用的技術堆疊很單純：FastMCP、Pydantic、React、TypeScript。整合這些技術並不困難，真正的難題是讓模型、工具和 UI 對接下來要做的事取得共識。

有效的做法

讓每次交接都清楚明確

我們不再將工具結果視為原始後端承載資料，而是把每次傳回結果都當作一次交接。

完善的工具結果會：

  • 提供小工具顯示所需的資料。

  • 向 ChatGPT 提供結構化事實，作為回覆依據。

  • 必要時明確指出接下來該做什麼，讓模型不必猜測。

小工具操作不應將含糊的文字傳回討論串，而應清楚說明使用者做了什麼，以及接下來該做什麼。

交接變得清楚後，系統也變得更可靠。

只要工具輸出和小工具操作中包含簡短明確的指示，模型就能遵循。

以下是我們使用的一個簡單 Pydantic 結構。output 欄位包含顯示小工具所需的結構化資料，以及 ChatGPT 在工作階段中應使用的事實。agent_directions 欄位則是一行簡短文字，說明助理下一步該做什麼。reason 欄位為選填。

Python

from typing import Generic, TypeVar
from pydantic import BaseModel
T = TypeVar("T")
class AgentDirections(BaseModel): assistant_instruction: str reason: str | None = None
class ToolResults(BaseModel, Generic[T]): agent_directions: AgentDirections output: T

保持小工具精簡

有效的小工具一次只讓使用者做一項決定，完成後便交還控制權。簡短清單、確認操作或精簡的審閱畫面，都比把小工具變成迷你應用程式更有效。若想讓流程更具確定性，仍可在小工具中加入少量邏輯，例如簡單驗證或固定的下一步。

小工具訊息採用第三人稱

我們不再把小工具的後續訊息寫成使用者的對話口吻，例如「我選擇了……」或「我確認了……」。我們改用簡短報告描述使用者的操作，例如「使用者選擇了……」或「使用者確認了……」。我們之所以嘗試這種寫法，是因為 ChatGPT 會把小工具傳回的訊息歸類為工具訊息，而不是使用者訊息。

下一步明確時直接執行操作

如果按鈕已明確對應下一次工具呼叫，讓小工具直接觸發呼叫，比強制再進行一輪對話更有效。只有在下一次工具呼叫不需要 ChatGPT 提供輸入時，才適合採用這種做法。

由小工具直接觸發呼叫，有助於強制執行確定性流程，還能省去另一輪對話並降低延遲

錯誤處理

工具呼叫失敗時，我們會從工具傳回正確的 MCP 錯誤代碼和簡短易懂的訊息。如此一來，ChatGPT 在呼叫失敗時就有實際資訊可讀，能向使用者解釋問題及/或選擇合理的下一步。

工具情境管理

我們將工作階段狀態保留在自己的伺服器上。ChatGPT 會隨工具呼叫傳送工作階段專屬的上下文；在 FastMCP 中，我們為每項工具提供 Context 參數，讓處理常式能讀取及更新工作階段狀態。

  • 固定 ID 和先前結果都存放在工作階段中，因此不必要求 ChatGPT 在每次呼叫時，再次以工具引數傳入固定 ID 和先前結果。

  • 若出現工具呼叫迴圈，我們可以攔截重複呼叫，並透過工具結果傳回明確錯誤。

  • 工作階段日誌則保留在我們的伺服器上，供偵錯和支援使用。

無效的做法

假設模型會推斷下一步

初期，我們會顯示小工具，假設模型已經「理解」，然後等待正確的後續工具呼叫。偶爾成功，多半不會。

如果交接不夠明確，ChatGPT 可能在應執行操作時改做摘要、要求使用者重複選擇，或在應停止時繼續規劃。

解決方法是在結構化輸出和小工具承載資料中明確寫出下一步，而不是期待模型自行推斷。

將語意分散在不同層級

按照 Apps SDK 文件的做法，我們曾嘗試將回應拆分到工具輸出、隱藏中繼資料和對話文字中。但小工具無法讀取隱藏中繼資料，因此這個做法行不通。

對模型隱藏工具

Apps SDK 文件說明，有些工具可以不顯示在智慧體的工具清單中，讓智慧體不會選用，但小工具仍可呼叫。可是，當我們將可見性設為「app-only」時，這些工具不僅不再供智慧體使用，小工具也無法呼叫。我們一直無法完成智慧體看不到工具、小工具卻仍能使用的設定。

不明確的錯誤

沒有任何回應，或在毫無實質結果時只顯示籠統的「成功」，都比直接回報錯誤更糟。因此，我們將工具和小工具失敗正式納入輸出：如果某個步驟無法繼續，就用淺白文字說明並傳回明確錯誤，不讓使用者只能盯著已顯示卻無法推進流程的小工具。這種做法改善了易用性，也讓模型的行為更可靠。

結語

如果你的目標是在 ChatGPT 中建立工作流程，同時減少客製化平台的開發工作，Apps SDK 是務實的選擇。你以部分控制權換取速度，也能在使用者原本工作的環境中接觸他們。

如果需要掌控流程的每個分支、UI，以及每一步由誰決定，就應從一開始規劃自己的智慧體技術堆疊。若只在 ChatGPT 中開發，產品很可能終究會超出 Apps SDK 架構的適用範圍。

你也可以先透過 Apps SDK 在 ChatGPT 中執行 MCP 伺服器，之後再自行建置對話、身分驗證和智慧體串接機制。產品需要時，便可轉移至自有技術堆疊。

處境相似的團隊接下來可以這樣做：挑選一個結果明確的工作流程，寫下對話、工具和小工具之間的交接方式，再針對重試和錯誤情境進行壓力測試，完成後才投入大量時間調校提示詞。

作者

Malan Evans