假設你剛在 A 專案開了一個 coding agent 對話，接著用檔案瀏覽器打開 B 專案，準備改一段介面文字。

畫面上已經是 B，你順手送出：「幫我改一下這個按鈕。」

這時候，agent 的工作區在哪裡？

在 Open WebUI，既有 agent 對話會保留自己的 workspace，即使你已經在檔案瀏覽器切到其他資料夾。你看到 B，不代表這個對話已經離開 A。

這個差別值得在第一次寫入之前確認。否則需求寫得再清楚，執行的位置仍可能不是你以為的地方。

同一個工作台，不等於同一份路徑狀態

Open WebUI v0.13.0 把桌面、瀏覽器與 Git 面板放到聊天旁邊，也讓團隊能透過共享檔案接續工作。操作集中之後，很容易產生一個直覺：我在右邊切了專案，左邊的 agent 應該也會跟著切。

但面板靠在一起，並不能證明它們共用同一個「目前位置」。至少要分開看這三件事：

Open WebUI 的 coding agent 有兩條關鍵規則：新對話從 terminal 的目前工作目錄開始；既有對話保留自己的 workspace。

保留工作區不必然是 bug。對還在進行的任務而言，使用者只是去別處找檔案，原本的工作就突然換了目標，也未必合理。問題在於，操作介面是否讓人看得出這個差別。

還要留意，agent 能讀到 B 的檔案，並不足以證明工作目錄在 B。核對時要同時看目錄與專案標記，不能只看「讀到了什麼」。

先做一次不改檔的核對

下面是一套建議演練。先準備已隔離、沒有憑證與正式資料的可丟棄環境，不要拿正在工作的產品專案試。

在裡面放 A、B 兩個小專案，各自準備內容不同、容易辨識的測試標記檔。標記只需要讓人分得出是哪個專案，不需要放任何敏感資訊。

1. 確認所選 terminal 的實際工作目錄是 A，再建立一個已儲存的 agent 對話；coding agent 不適用於暫存對話。
2. 在檔案瀏覽器切到 B，但先不要要求修改任何檔案。
3. 請 agent 使用目前可用的唯讀工具，回報實際執行目錄，並讀取該目錄中預先準備的標記檔。
4. 人工核對工具呼叫與回傳內容，確認目錄、標記及預期任務是否一致。

這裡要看的不是模型回答「我現在在 B」，而是能對得上路徑的實際工具結果。只拿到 B 的檔案內容，也還少了執行目錄這個證據。

可以把第一個請求限制成這樣：

先不要修改檔案。請用目前可用的唯讀工具確認實際執行目錄，再讀取該目錄中我準備的專案標記檔，讓我核對這個對話正在使用哪個工作區。若無法確認，請停下來說明，不要猜測，也不要要求擴大權限。

如果工具無法提供可核對的目錄，這一步就是「未驗證」。不要改用寫入一個檔案的方式試位置，更不要為了讓演練通過而一路開權限。

但這段請求本身不是安全機制。要求唯讀不會自動建立 sandbox；實際允許哪些工具、能碰哪些路徑，仍要由環境與權限設定限制。工具請求會依 Open WebUI 的 tool permission mode 處理，也不能把「有核准介面」理解成所有操作都必然逐次詢問。

要改 B，就明確建立 B 的執行上下文

要開始 B 的任務，先確認所選 terminal，依目前安裝版本支援的方式設定並核對它的工作目錄，再建立新的已儲存 agent 對話。新對話開始後，仍要重做一次目錄與標記核對。

不要省略中間那一步，直接把「開新對話」當成「切到 B」。如果 terminal 的 cwd 還是 A，新對話也沒有理由自動知道你想去 B。

同時看一下實際選中的 agent／model。terminal 或 agent model 不可用時，Open WebUI 會移除該選擇，改用預設模型；不能只憑上一輪用過哪個 agent，就認定這一輪仍是同一個執行者。

目錄與執行者都確認之後，再把任務縮到明確的修改範圍，例如「只改 B 專案某個按鈕的文字，不調整版面與其他元件」。任務邊界不能替代路徑核對，但能讓後續差異更容易驗收。核對結果不符，就先停下來，不要帶著疑問開始改檔。

自己做 agent 前端，別只顯示一條漂亮的麵包屑

如果你正在做類似的 agent 工作台，我會先把「瀏覽位置」與「對話的執行工作區」分欄顯示。兩者不同時，讓差異留在畫面上，而不是用一個資料夾名稱概括所有狀態。

以下是設計建議，不是 Open WebUI 現有功能清單：

• 瀏覽器切到 B、對話仍在 A 時，兩個位置都保留，不要讓其中一個蓋掉另一個。
• 工具結果附上可核對的執行目錄與任務識別，避免接手者只看到脫離上下文的「成功」。
• 待核准的修改顯示實際目標工作區與檔案；核准時，後端仍須確認請求對應的工作區，不能只相信前端顯示的名稱。

固定的路徑狀態列不需要生成式 UI。若進一步要把不同工具的回傳內容做成互動確認卡片，可以從生成式 UI 的元件與工具介面資源比較工具呼叫渲染、元件目錄與 MCP Apps 的實作方式。選好怎麼呈現之後，仍得另外處理執行目標與存取權限；畫出一張確認卡，不會自動完成這些限制。

同樣地，嵌入式工具 UI 的隔離，也不能直接當成整個 terminal 的隔離保證。前端需要把狀態說清楚，後端則要讓核准的目標與真正執行的目標對得起來。

下一個請求，先問它在哪裡

下一次在工作台切到另一個專案，先別急著送出「幫我改一下」。核對所選 terminal 的 cwd、對話的 workspace，以及實際工具結果，再允許那個範圍內的修改。

按鈕文字改得對不對，是後面的驗收。第一個要確認的，是它準備改哪個專案。

參考資料

• Open WebUI：Coding Agents
• Open WebUI v0.13.0：your model gets a computer

本文的 A／B 專案流程為建議演練，未宣稱已安裝、執行或取得測試結果。Coding Agents 為未固定版本的文件，不能據此認定所有既有安裝都具備相同行為，或所有條目都在 v0.13.0 首次加入。發布前請核對實際使用版本。