Open WebUI 0.12.1 新增外部 App 加入頻道的功能。管理者可登錄符合 Apps 介面的服務、檢視它要求的權限，再讓頻道管理者把核准的 App 加入特定頻道。對自架使用者來說，第一個問題不只是「能不能叫 App 回答」，還包括它能讀取哪些訊息、回覆會被誰看見，以及出問題時由誰處理。
這項整合把工具服務帶進團隊討論脈絡，也讓頻道內容成為新的資料入口。發布說明列出功能與設定方式，沒有替任何部署環境完成安全評估；實際風險仍取決於授權選擇、頻道內容、App 維運方式與伺服器網路設定。
一、0.12.1 的外部 App 如何參與頻道？
外部 App 可依獲准權限接收提及、讀取訊息，或發布、更新自己的訊息；要回覆提及，還需核准訊息寫入權限。它必須由管理者登錄並啟用，再由有權限的頻道建立者或管理者加入頻道。
外部 App 是在自己的伺服器運作、遵循 Open WebUI Apps 介面的服務。管理者通常需要服務提供的 App URL 與 API key（應用程式介面金鑰），Open WebUI 會從端點讀取 App 資訊、檢視它要求的 scopes（權限範圍），再由管理者選擇核准哪些能力。
若 App 沒有發布資訊清單，也可以手動填入名稱、公鑰與要求的權限。公鑰是用來驗證 App 簽署連線證明的資料；手動填寫時，管理者需另外確認它確實來自 App 營運者，並核對所要求的權限。
安裝完成後，頻道建立者或管理者從頻道成員清單加入 App。使用者在該頻道以 @ 提及它，App 可依實作與授權在頻道回覆；支援按鈕互動的 App，也可在按鈕操作後回傳僅提問者可見的私人回覆。頻道回覆會像一般訊息一樣留在頻道歷史中，其他成員都看得到；私人回覆則只對該使用者顯示。兩種回應的可見性不同，設計自動化流程時應先決定哪些內容可以公開留存。
Open WebUI 官方發布說明將這項更新描述為「External apps in channels」，並指出管理者能檢視 App 要求的權限及設定誰可以使用。這代表管理介面提供授權選項，不代表每個 App 都已由 Open WebUI 或部署者驗證其資料處理方式。App 服務由誰營運、收到的資料如何保存與使用，仍需向服務提供者確認。
符合 Apps 介面的服務需維持與 Open WebUI 的連線，並處理提及或按鈕操作等事件。若組織只需要定時貼上通知，可先評估頻道 webhook 或一般 API 機器人，避免讓服務取得不必要的訊息讀取權限。
「Apps are external services that join channels as members.」可譯為「App 是以成員身分加入頻道的外部服務。」這是 Open WebUI Apps 文件對功能定位的說明，點出它具有頻道成員的資料接觸位置，授權範圍因此值得在加入前確認。
二、誰能核准 App，頻道裡的訊息誰看得到？
管理者決定哪些 App 可安裝、核准它要求的權限與使用者範圍；頻道建立者或管理者決定 App 是否加入特定頻道。App 能接收的內容由授權範圍和已加入的頻道共同決定。
管理者在安裝時會看到 App 要求的權限，並可取消不需要授予的項目。常見權限的差異如下，實際核准仍應依 App 的用途判斷：
| 權限範圍 | App 可取得的能力 | 適合核對的問題 |
|---|---|---|
接收提及（channels:mentions:read） | 接收已加入頻道中提及 App 的訊息；不因此取得其他訊息或歷史 | 是否只需收到點名 App 的要求？ |
讀取訊息與歷史（channels:messages:read） | 接收已加入頻道的提及，以及每則新訊息、編輯與刪除事件；也可讀取訊息和討論串歷史 | App 是否需要完整頻道脈絡？ |
發送與更新訊息（channels:messages:write） | 發送頻道訊息、更新 App 自己的訊息；回覆提及或在頻道發布按鈕操作結果時需要此權限 | 哪些輸出會公開留存在頻道？ |
讀取頻道資料（channels:read） | 列出 App 已加入頻道的名稱、類型及是否為私人頻道 | 工作是否需要辨認頻道資訊？ |
接收提及可核准 channels:mentions:read；若也核准 channels:messages:read，提及事件同樣會送達，但 App 另外能接收該頻道的所有新訊息、編輯與刪除事件，並讀取歷史。要讓 App 在頻道回覆提及，還需 channels:messages:write；讀取權限不會自動授予寫入能力。按鈕操作事件會送到 App；若 App 只以私人訊息回覆按鈕操作者，不需額外 scope，若要在頻道發文或更新自己的訊息，則需 channels:messages:write。
每項 scope 僅適用於 App 已加入的頻道，因此「具備讀取訊息權限」與「可讀到哪個頻道」是兩個不同判斷。可先將 App 放進測試頻道，再決定是否加入工作頻道；含客戶資料、憑證或個人資訊的頻道，應確認它是否需要讀取歷史和所有新訊息。
另一層控制是 App 的 Access（可使用者範圍）。管理者可開放所有使用者，或限制在指定使用者及群組。這決定誰能提及 App、操作按鈕或將它加入頻道；加入頻道仍需具備該頻道的讀取權限。管理者需分別檢查「誰能使用」與「App 加入哪些頻道」。
App 可發布頻道訊息時，訊息會以 App 名稱出現並保留在頻道歷史。按鈕則可能觸發另一輪處理，結果可以只回覆給點擊者，也可能寫入整個頻道。部署者應把這些輸出視為正式的頻道內容，為錯誤回覆、重複貼文或處理逾時設定負責人與處理方式。像是 App 已收到請求但回覆逾時，不能只因介面顯示失敗就直接重送敏感指令，應先確認服務端是否已執行動作。
Open WebUI 的官方文件提醒，若 App 獲准讀取已加入頻道的訊息與歷史，它會收到該頻道發布的每則訊息並讀取歷史。這項說明可用來理解產品內的授權效果，但無法替代對 App 服務商的資料政策、保存期限、記錄方式和下游處理的查核。自架 Open WebUI 也不會自動限制 App 端如何處理已收到的資料，必要時需透過服務合約、內部規範或自管 App 實作補足。
三、自架部署要先確認端點、憑證與網路路徑
確認 Open WebUI 伺服器能直接連到 App 端點、憑證與 API key 有效，並檢查 App 的權限及連線狀態。若 App 位於私有網路或只使用 HTTP，需額外設定允許來源並理解其安全影響。
App URL 的連線由 Open WebUI 伺服器發起，瀏覽器能連線並不能證明伺服器端也可連到 App。官方文件指出，Apps 連線不使用 HTTP_PROXY、HTTPS_PROXY 或 NO_PROXY 代理設定，因此部署環境必須能從 Open WebUI 主機直接解析並連到 App 主機。
容器內的 127.0.0.1 指向 Open WebUI 容器本身；App 若跑在主機或另一個容器，需採用該部署網路可到達的主機名稱或服務名稱。設定好網址不代表網路上真的可達，防火牆、DNS、連接埠、反向代理和 WebSocket 升級支援都可能影響握手。
一般情況下，App 端點必須使用 HTTPS，且網域解析結果須符合 Open WebUI 的連線限制。若開發測試中的服務位於本機、私有網路，或必須使用純 HTTP，官方提供 APP_ALLOWED_PRIVATE_ORIGINS 設定，讓管理者明確列出可接受的來源。
比對會包含協定、主機和連接埠；設定錯誤可能導致所有 App 端點都無法載入。這個允許清單是部署者自行放寬限制，應只加入必要來源，並評估來源的認證、傳輸保護及網路隔離，不宜不加區分地允許整個內網。
憑證也有維運依賴。Open WebUI 會加密儲存 App 的 API key 和連線憑證，金鑰來自 WEBUI_SECRET_KEY。官方文件提醒，多個 Open WebUI 執行個體需要保持同一個穩定值；若輪替這個值，既有 App 可能無法繼續連線，需重新安裝或輸入憑證並加回頻道。升級、備份還原、擴充多個 worker 前，維運者應納入這些憑證與連線狀態的恢復流程。
連線狀態可以在管理者的 Apps 頁面檢視。若顯示持續 Connecting 或 Disconnected，可檢查 App URL、DNS、TLS 憑證、API key、公鑰、代理是否支援 WebSocket，以及 App 端服務日誌。Open WebUI 文件提供常見錯誤訊息及排查方向。
狀態顯示已連線只代表連線握手完成，無法證明 App 輸出正確或資料使用符合組織要求。因此功能測試、權限審查和服務端檢查應分開完成。
Open WebUI 官方文件的連線說明指出，系統需要「a direct network path to every app」，也就是伺服器到每個 App 都必須有直接網路路徑。這項要求有助於定位失敗來源：連線由 Open WebUI 主機發起，瀏覽器能開啟 App 網站，並不能證明伺服器端也能連到同一個端點。
「Apps only act in channels, so both are needed.」可譯為「App 只在頻道中運作，因此 Apps 與 Channels 都必須啟用。」這是 Open WebUI 官方 Apps 設定文件對前置條件的說明。啟用功能只是讓管理介面和連線流程可用，之後仍需逐一核准服務、設定使用者範圍和頻道成員。
四、用測試頻道和最小權限決定是否擴大使用
先界定工作需求與資料敏感度，再用測試頻道驗證最低必要權限、輸出可見性和移除流程。通過測試後，才依使用者、頻道和維運責任逐步擴大。
評估前先描述 App 要解決的具體工作，例如整理被提及的問題、查詢內部服務資料或提交簡短狀態。再問它為了完成工作，是否必須讀取整段頻道歷史，還是只需收到被提及的內容；回答是否必須對所有人可見；按鈕操作會不會改動既有訊息或建立外部副作用。把需求說清楚，才能判斷是否真的需要訊息讀取、寫入或頻道資訊權限。
接著確認服務的營運者、資料保存方式、故障回報窗口和版本更新責任。使用第三方服務時，應向服務提供者確認訊息會被傳送到哪裡、保存多久、是否用於其他目的，以及是否有刪除或事件稽核機制。若 App 是自行開發，則需確認日誌是否意外保存個資或密鑰、錯誤處理是否重複執行，以及停用或移除後如何撤銷服務端憑證。產品文件列出的是協定和介面能力，不包含部署者與 App 維運者之間的責任分工。
測試頻道宜使用可替代的虛構內容，逐項確認提及是否送達、App 是否讀到不相關訊息、回覆會顯示給哪些人、按鈕是否執行預期操作、連線失敗時的錯誤是否可理解。測試也要涵蓋權限收回、App 停用及移除成員後的行為。移除 App 會取消它的頻道成員資格與部分憑證，但已發布在頻道中的訊息仍會保留，這些歷史訊息可能仍包含使用者輸入的資料，需依組織的內容保留政策處理。
可用以下單一檢查流程作為上線前的紀錄：
- 寫下 App 的用途、預期輸入、輸出對象及故障負責人。
- 核對每項要求的權限，只核准完成用途所需的範圍，並限制可使用的使用者或群組。
- 檢查 App URL、TLS 憑證、API key、直接網路可達性，以及私有來源允許設定。
- 在低敏感度測試頻道驗證提及、讀取、回覆、按鈕、逾時和移除行為。
- 記錄核准者、頻道範圍、App 服務維運窗口與停用後的資料處置方式。
若測試結果顯示 App 必須取得超出工作需求的頻道內容，或服務提供者無法說明資料處理及故障處置方式，就應重新設計流程、限制頻道或暫緩接入。Open WebUI 0.12.1 增加的是管理和協作入口，是否採用仍應由資料最小化、實際網路條件與維護能力共同決定。
- Open WebUI 外部 App 是由管理者安裝並授權的服務，之後由有權限的頻道管理者加入個別頻道。
channels:mentions:read可接收提及，channels:messages:read涵蓋頻道新訊息、編輯與刪除事件及歷史；回覆提及另需channels:messages:write。- 自架環境要從 Open WebUI 伺服器檢查 App 端點、DNS、憑證、API key 及必要的私有網路允許設定。
- 先以測試頻道和最低必要權限驗證，再決定是否放進含敏感內容的工作頻道。
五、常見問題：App 權限與頻道可見性
先確認 App 必須接收哪些事件、能讀取哪些頻道內容，以及回覆要對誰可見。提及讀取、完整訊息讀取與頻道寫入是不同能力，應依工作需要分別核准。
Q1：Open WebUI 會自動提供可以安裝的 App 清單嗎？
Open WebUI 提供新增 App 的管理流程，但管理者仍需取得 App 的端點與 API key，手動登錄服務並審查要求的權限。它不會因為升級就自動替每個環境完成服務選擇或安全核可。
Q2：App 加入頻道後能看到哪些訊息？
依核准的權限而異。channels:mentions:read 可接收提及；channels:messages:read 也會接收提及，但另外涵蓋 App 加入頻道後的每則新訊息、編輯與刪除事件及歷史。要讓 App 在頻道回覆提及，還需核准 channels:messages:write。按鈕操作可送達 App；私人按鈕回覆不需額外權限，若要在頻道發文或更新 App 自己的訊息則需要寫入權限。這些能力只在 App 已加入的頻道內生效。
Q3：怎麼限制誰能使用 App，或讓它離開頻道？
管理者可將可使用者範圍設為所有人，或限制特定使用者及群組。頻道建立者或管理者可從頻道成員清單加入或移除 App。移除成員不會自動刪除它過去已發布的訊息。
Q4：App 網站在瀏覽器打得開，為什麼 Open WebUI 仍連不上？
連線是由 Open WebUI 伺服器發起，因此需從該伺服器檢查 DNS、網路路由、防火牆、TLS 憑證和端點設定。若服務位於私有網路或使用 HTTP，還需確認允許來源設定正確，並檢視管理介面的連線錯誤與 App 端日誌。
