MCP 應用程式詳解：代理商何時應該顯示螢幕（以及何時應該保持無頭模式）

MCP 應用 讓AI代理向你展示一個螢幕，而不是一大段文字。工具呼叫會以可操作的儀錶板、表單或核准卡的形式傳回，直接在Claude或ChatGPT中呈現。你點擊，代理看到你的選擇，對話繼續進行。.

這確實是個很有用的想法。但這種想法也容易讓人想把使用者介面強加在所有東西上。所以在你這麼做之前，請先回答這個所有排名頁面都會忽略的問題： 你們的哪些工作流程實際上需要螢幕，哪些工作流程根本不應該有真人參與聊天？

我在 Claude Code 上運行著 10 多個自主品牌容器。在過去的 30 天裡，撰寫這篇文章的容器運行了… 涵蓋 20 項技能的 404 個已安排工作. 在這些404錯誤出現期間，沒有一個人參與對話。 MCP Apps對這些錯誤並不會產生任何影響。但是，在我的業務中，有一個環節只需要一個螢幕就能改變一切，而這正是我最不擅長的。這就是本指南要講的內容。.

先說明一下，免得大家誤會：JonOps 目前沒有執行 MCP 應用程式。這只是維運人員的評估，評估過程中規範文件是開啟的，日誌則顯示在另一台顯示器上。.

MCP 應用是什麼（簡單易懂版）

模型上下文協定 (MCP) 是一種標準，它允許 AI 模型與外部工具（例如您的日曆、CRM 和資料庫）進行通訊。如果您需要複習一下，請從以下內容開始： MCP 伺服器究竟是什麼？. 直到今年，這些工具返回的所有內容都是文字、結構化資料或圖像。模型讀取這些數據並進行總結。.

MCP 應用 更改返回類型。現在，一個工具可以說“我帶有一個用戶界面”，而聊天應用程式（ 主持人）將該介面以內聯方式呈現在對話中。您可以篩選圖表。表單帶有真正的下拉式選單。 PDF 檔案中包含可點選核准或標記的條款。.

MCP Apps 的由來

該擴展方案於2025年11月提出，並於同年正式生效。 首次正式MCP延期日期為2026年1月26日. 它並非從零開始發明，而是標準化了兩個早期專案驗證過的模式：社群建構的 MCP-UI 和 OpenAI 的 ChatGPT 應用 SDK。 Anthropic、OpenAI 和 MCP-UI 的維護者共同開發了共享版本，因此同一個應用程式無需編寫特定於客戶端的程式碼即可在 Claude 和 ChatGPT 中渲染。.

MCP 應用底層工作原理

你不需要自己動手搭建一個來理解它，但機制部分會在後面解釋所有陷阱，所以這裡是簡短版本：

1. 該工具聲明了一個用戶介面。. 它的描述包含 _meta.ui.resourceUri 指向一個的字段 ui:// MCP 伺服器上的資源。.
2. 主機取得該資源。. 這是一個 HTML 頁面，通常捆綁了自己的 JavaScript 和 CSS。.
3. 主機在沙盒化的 iframe 中渲染它。 在對話內部，沙盒機制會阻止應用程式存取父頁面、您的 cookie 或任何其他不應該存取的內容。.
4. 應用程式和主機之間的對話 postMessage, 使用 JSON-RPC。該應用程式可以呼叫其伺服器上的工具、向聊天發送訊息，或靜默地更新模型的上下文（「使用者選擇了選項 B」）。.

有一個細節對成本影響很大：工具加工的結果可以拆分。用於模型的零件會被拆解成兩個部分。 內容; 螢幕顯示的豐富數據進入 結構化內容. 因此，一個包含 500 行的表格可以存在於 UI 中，而無需在模型的上下文視窗中消耗 500 行令牌。.

如果主機不支援 MCP 應用程式怎麼辦？該工具仍然有效，只是會回退到純文字模式。使用者介面是一個漸進式增強功能，並非強制要求。.

MCP 應用、MCP 伺服器和 MCP 工具：單表差異

這是該主題下搜尋量最高的誤解，但其實比那些專業術語所描述的要簡單得多。以下是搜尋引擎結果頁面 (SERP) 上的一句精闢解釋： 伺服器提供連接，應用程式提供體驗。. 以下是全部情況：

	MCP伺服器	MCP 工具	MCP應用程式
它是什麼	將人工智慧與外部系統連接起來的程序	伺服器公開的一個函數（「create_task」、「search_orders」）	附加到工具上的互動式使用者介面，渲染在聊天視窗中
誰能看到輸出結果	沒人直接參與。是管道工程。	模型（以文字或資料形式）	你（作為螢幕）和模型（作為你提交的事件）
需要有人在場嗎？	不	不	沒錯，這就是關鍵。
可以在無頭定時任務中運作嗎？	是的	是的	最終還是會顯示文本，所以使用者介面部分就浪費了。
例子	日曆伺服器	“查找開放槽位”	一個可視化的周視圖，您可以在其中點擊您想要的時間段。

每個 MCP 應用都依賴 MCP 伺服器。並非每個伺服器都需要應用。我的大多數應用程式甚至不需要伺服器：正如我測量的那樣… MCP閘道故障, 此容器中的 39 個即時技能檔案完全不呼叫 MCP 工具，所有整合工作均透過純 REST 完成。如果您想深入了解工具層本身，我已介紹過。 MCP 工具以及我實際運作的工具 它們分別已經解釋過了，所以我就不再贅述了。.

MCP 應用目前運作的地區（以及無法運作的地區）

客戶支援是大多數解釋性文章容易過時的地方，因此我在撰寫本文當天（2026 年 10 月 23 日）查閱了官方的 MCP 擴展客戶端矩陣。以下主機支援 MCP 應用：

• 克勞德 在網路上和 克勞德桌面
• ChatGPT
• VS Code （GitHub Copilot）和 游標
• Microsoft 365 Copilot
• 鵝 （Block 的開源代理，參考實作）
• 郵差, MCPJam, Archestra.AI 和 PostHog 程式碼

MCP 應用程式清單中未包含下列工具：MCP Inspector、fast-agent 和 mcpc CLI。尤其值得注意的是，對於像我一樣運行代理程式的使用者而言，, 克勞德·科德也沒有被列入名單。. 這很合理。調度程式在 00:05 啟動的終端會話沒有地方可以繪製 iframe。.

這個生態系統是真實存在的，而且是由消費者塑造的。

一些知名公司已經推出了應用程式：Asana、Slack、Canva、Figma、Hex、Amplitude、monday.com、Zillow、Spotify 和 Expedia 都出現在了目前的榜單中。但請注意這些應用的模式。幾乎每一款應用程式都針對使用者在聊天中想要查看、選擇或確認某些內容的情況。 Slack 的應用程式可以草擬訊息並在發布前顯示預覽。 Asana 的應用程式可以將計劃聊天轉化為一個項目，用戶可以在項目上線前查看它。目前還沒有人開發用於在用戶休息時運行的 MCP 應用。.

它有多成熟？

既成熟到可以使用，又足夠年輕到會謹慎使用。官方SDK，, @modelcontextprotocol/ext-apps, Thoughtworks 今年發布了 2.x 系列產品（2.0.3 於 2026 年 9 月 25 日發布，2.x 需要 Node 20 或更高版本），其網路協定與 1.x 版本相同。 Thoughtworks 將 MCP Apps 納入了… “評估” 在 2026 年 4 月的技術雷達報告中，這項技術被列入其中，並提出了一個合理的警告：團隊應該評估相比純文本而言，增加的複雜性是否值得他們承擔。這種直覺是正確的，也是下一節將要探討的。.

操作員測試：此工作流程需要螢幕顯示還是定時任務？

我採用的規則是這樣的，寫在一張便條紙上就行了：

MCP 應用適用於需要人類做出決策的時刻。其他所有應用都應該保持無頭模式。.

只有當以下三個條件同時成立時，螢幕才值得建造：

1. 跑步時有人在場。. 如果任務是由調度程序觸發的，那麼就沒有人可以點擊它。.
2. 人必須做出判斷。. 批准、拒絕、選擇、編輯、探索。如果他們每次都只是蓋章通過，那就把蓋章過程自動化。.
3. 這項決定確實讓文本變得更糟。. 比較三張圖片選項、掃描差異、篩選表格。如果一句話加上一個「是/否」就能搞定，那麼使用者介面就顯得多餘了。.

我自己的艦隊，經過了測試

我擷取了過去30天（2026年9月23日至10月22日）的日誌。 404 次計畫運行，涵蓋 20 項技能：361 個任務成功完成，18 個任務順利跳過，1 個任務失敗，24 個任務根本沒有寫入結果行。以下是任務的詳細情況：

工作流程	運行（30 天）	有人在場嗎？	需要做出決定嗎？	判決
每日部落格文章（就是這篇）	29	不	只有之後，在審查時才會出現這種情況。	無頭
社交行程（2 張海報）	60	不	不	無頭
郵件分類 + 回覆草稿	60	不	是的，在發送任何內容之前。	無頭模式運行，螢幕用於發送
反向連結拓展（查找+執行）	63	不	很少	無頭
社區回覆草稿（社交挖掘機）	30	不	是的，每一稿	無頭奔跑，螢幕決定
每週搜尋和分析概覽	4	不	是的，解讀它	實時儀表板的候選者

請再閱讀右側欄。. 跑動中根本不需要螢幕。. 這 跑動所引發的決定 確實如此。幾乎所有 MCP Apps 的文章都忽略了這一點，因為它們都是在聊天視窗中撰寫的，而聊天視窗中總是有人在場。 自主代理設定, 之後，人類會異步地出現，面對著特工留給他們的一堆東西。.

因此，誠實的運營商建議是：不要安裝 MCP 應用。 在 你的代理人。把他們派到… 交接點, 代理的輸出結果等待你的判斷。.

MCP 應用在小型企業中發揮作用的三個方面

有了這條規則，以下是我實際會考慮的三種用途，並按它們能為小型團隊節省多少金錢和時間進行排名。.

1. 審核隊列（我最需要的那個）

以下是令人不安的事實。我的經紀人會將所有對外發布的內容（部落格文章、電子郵件草稿、保單諮詢）歸檔到 Asana 中名為「草稿（待審批）」的版塊。截至今天早上，該版塊已存放了… 共有 198 個任務，其中 194 個仍處於待處理狀態。沒有一個任務在創建後超過一分鐘就被人工關閉。最老的任務已經等了 128 天。. 已開放的卡片中有 116 張是部落格文章評論，今晚的文章又增加了一張。.

我寫了一整篇文章來解釋為什麼 只有當有人完成閉環時，循環中的人才算數。. 代理人正在履行職責。系統卡在審核環節，因為審核需要打開另一個工具，找到卡片，打開鏈接，然後做出決定。.

這正是 MCP 應用的用武之地。想像一下：你已經在 Claude 中，輸入“有什麼待辦事項？”，然後螢幕上不再是連結列表，而是一張卡片，每張卡片對應一個草稿。卡片上包含標題、首段、圖片以及三個按鈕：批准、編輯、拒絕。點擊一下即可將決定寫回追蹤器。這就是 MCP 團隊所倡導的「文件審核」模式，並將其應用於單人企業。.

坦白說：更漂亮的介面並不能解決無人問津的問題。關鍵不在於使用者介面，而是讓使用者自己做決定。 你一天中大部分時間都花在哪裡？, 因此，審核不再是一項單獨的任務。在建立任何內容之前，請先測試簡易版本：Asana 已經在 Claude 中內建了一個互動式連接器。如果您使用 Claude，而您的隊列位於 Asana 中，請在編寫任何程式碼之前先嘗試一下。.

2. 您實際探索的即時指標

我每週的搜尋和分析都會產生一個排名靠後的頁面列表。如果是文字形式，這倒沒什麼問題。但後續的追問（「只顯示九月份的文章」、「按展示次數排序」、「第七行是什麼？」）恰恰是 MCP 官方部落格用來論證 MCP 應用合理性的那種循環往復的提問。一個可以篩選並直接將使用者選擇回饋給模型的表格，遠比五個額外的提示好得多。經驗法則：如果你總是就同一個輸出提出後續問題，那它最好是一個頁面。.

3. 用於設定工作的設定精靈

啟用新的品牌容器意味著要做出數十個相互關聯的選擇：類別、表單 ID、社交平台、日程安排等等。如果透過聊天完成，那簡直就是二十輪「選哪一個？」的拉鋸戰。而使用表單一次顯示所有選項，並預先填入預設值和驗證功能，則只需產生一個乾淨的配置物件即可。雖然設定過程並不頻繁，但每次都至關重要，因為錯誤的答案會被複製到之後的每次運行中。.

注意一下什麼是… 不是 這份清單上的內容包括：任何按計畫運行的流程。如果你正在繪製自己的業務流程圖，卻無法確定哪些工作流程位於這條線的哪一側，那麼這正是我在工作中與人們一起探討的問題。 自動化策略會議. 通常答案是「螢幕越少，切換越流暢」。“

需要注意的陷阱：延遲、模型無法看到的 iframe 以及您無法控制的主機使用者體驗

每個功能頁面都會顯示示範。以下是文件和早期建構者對演示結束後會發生什麼情況的描述。.

模型無法看到 iframe

這一點對審批隊列的影響最大。代理程式只能知道應用程式明確傳送給它的內容：提交的表單、上下文更新、工具呼叫。如果您在應用程式內編輯草稿，並在未點擊「批准」的情況下關閉標籤頁，“ 模型什麼也沒看到。. 你的修改已被刪除，但經紀人仍然認為草稿處於待審核狀態。.

解決之道在於設計規格：每個應用程式都需要一個明確的提交按鈕，而且決策必須記錄在持久的地方（例如你的追蹤系統或資料庫），而不僅僅是聊天記錄。對話記錄並非審計追蹤。.

每一次點擊都可能是一次往返。

UI觸發的工具呼叫仍然是工具呼叫。如果每次點擊都向MCP伺服器發送請求，MCP伺服器再向API發送請求，API回應請求，即使沒有進行任何繁重的操作，應用程式也會感覺卡頓。優秀的應用程式會採用批次處理方式：讓使用者在本地完成所有選擇，然後發送一個已提交的結果。這也能避免builder.io flags中存在的隱性問題，即應用每次拖曳滑桿都會觸發事件流，從而造成上下文臃腫。.

主機擁有該幀

你無法控制面板的大小、是否固定顯示或捲動隱藏，也無法控制它與宿主程式本身設計的搭配效果。同一個應用程式在 Claude Desktop 中可能看起來很棒，但在其他地方卻會顯得擁擠不堪。谷歌的 A2UI 團隊也對 iframe 提出了同樣的批評（設計系統衝突、冗餘的捲軸），並正在推廣一種聲明式的替代方案 A2UI。在 A2UI 中，伺服器發送 JSON 描述，宿主程式則使用其原生元件來繪製面板。對於簡單的批准/拒絕卡片來說，這種方法可能更適用。在投入大量資源開發自訂 HTML 之前，不妨先專注在 A2UI 的發展。.

安全性：沙盒機制，預設不安全

MCP 應用程式運行在沙盒化的 iframe 中，範本可以在渲染前進行審核，訊息以可記錄的 JSON-RPC 格式傳送，並且主機可以在應用觸發工具呼叫之前徵得您的同意。這是一個可靠的模型。但是，應用的可靠性取決於背後的伺服器。如果主機允許 UI 在未經請求的情況下呼叫敏感工具，那麼 UI 仍然可能造成損害。因此，您應該像使用自己的憑證驗證任何程式碼一樣驗證伺服器。 對 423 個 Claude 代理模板進行審核 這提醒我們，在這個生態系統中，權限的發放是多麼隨意。.

Thoughtworks提出的問題

與純文字相比，增加複雜性是否值得？對於簡單的「是/否」決策，通常並不值得。一條精心編寫的訊息，只需回覆“批准”或“告訴我需要修改什麼”，就足以滿足需求。只有當決策真正需要視覺輔助時，才應該開發應用程式：例如圖片、差異對比、並排選項、表格等。.

MCP 應用常見問題解答

什麼是MCP應用？

MCP 應用是模型上下文協議 (MCP) 的官方擴展，它允許工具返回互動式使用者介面（例如儀表板、表單、圖表或批准卡），這些介面會直接渲染在聊天視窗中，而不是以純文字形式顯示。 MCP 應用於 2026 年 1 月 26 日正式上線。.

MCP 和 MCP Apps 的主要差異是什麼？

MCP 協定將 AI 模型與工具和資料連接起來。 MCP 應用是 MCP 協定的擴展，它增加了一個視覺化層：工具的輸出結果可以點擊，而點擊操作會回饋給模型。所有 MCP 應用都使用 MCP 協定；大多數 MCP 伺服器不需要應用。.

ChatGPT 應用可以使用 MCP 應用嗎？

是的。 ChatGPT 已列入官方客戶端支援列表，而 MCP Apps 標準的部分內容也源自 OpenAI 的 Apps SDK。 Claude（網頁版和桌面版）、VS Code、Cursor、Microsoft 365 Copilot 和 Goose 也都支援它。.

MCP Apps 是否能在 Claude Code 或其他終端代理程式中運作？

截至 2026 年 10 月，Claude Code 尚未列入 MCP Apps 的官方支援清單。由於 MCP Apps 具有優雅降級機制，具有使用者介面的工具仍會在終端中傳回文字結果，因此不會出現任何問題。只是不會顯示螢幕而已。.

我需要編寫程式碼才能使用MCP應用程式嗎？

到 使用 不，它們不會。將 Asana、Canva 或 Figma 等應用程式連接到支援的主機，它就會出現在您的對話中。 建造 是的，你需要寫一個 MCP 伺服器以及一個 HTML/JavaScript 介面，通常會使用官方的 @modelcontextprotocol/ext-apps SDK。.

MCP應用程式安全嗎？

它們運行在沙盒化的 iframe 中，無法讀取宿主頁面或您的 cookie，而且宿主可以要求應用在呼叫工具前獲得您的許可。沙盒保護的是宿主，而不是伺服器內部的資料。請僅連接您在聊天之外也信任並願意授予相同存取權限的伺服器。.

小型企業是否應該開發 MCP 應用？

僅適用於需要人工判斷的工作流程，而文字會增加判斷難度。審批佇列、資料探索和設定精靈都屬於此類。而計劃的自動化流程、無人問津的報告以及任何在你睡覺時運行的程序則不屬於此類。.

結論：減少經紀人的螢幕操作，提升交接效率

MCP Apps 是今年 MCP 最棒的創新之一。它們能將工具輸出轉換為可供實際使用的內容，且無需編寫任何客戶端特定的程式碼，即可在 Claude、ChatGPT 以及越來越多的其他主機平台上實現這項功能。.

但操作員的教訓才是最枯燥的。我上個月的 404 計劃運行完全不需要螢幕。真正需要螢幕的是… 我：一個包含 194 張卡片的審批隊列，至今無人處理。如果您正在運行 人工智慧員工 我敢打賭，你自己的情況也差不多。瓶頸不在於經紀人，而在於交接環節。.

所以我的步驟如下。首先，找到你的客服人員等待你回應的時刻。其次，試著使用你工具中已有的應用（就我而言，是 Asana 的應用）。只有當決策仍然需要點擊五次、切換三個標籤頁才能完成時，才為這一時刻創建一個 MCP 應用，其中包含一個明確的提交按鈕，並永久記錄你的決策。其他所有操作都保持無頭模式。這就是… 負責我業務製作的代理商 保持無聊，這正是你想要的。.

如果您希望在自己的企業中劃清界限，區分哪些事情應該自行運轉，哪些事情需要您花兩分鐘進行評判，, 預約自動化策略會議. 我們先來找到你們的交接點。.