我做全棧開發已經 24 年多了。看工具更新的時候，我先看工作在哪臺機器上做，再看出了問題由誰喊停。按這兩把尺子量 0.13.1，我的判斷先放在這裏。
這一版最主要的新東西，是把編程 agent 放進模型選擇器裏選用，讓編程 agent 在用戶自己的電腦上工作。這篇文章後面說的旗艦的這條路，指的就是這一條路。
這一版的方向是成立的，因爲編程 agent 的工作地點從服務器挪到了用戶自己的電腦上，而且工具調用要不要放行，決定權還留在聊天裏的用戶手裏。但是旗艦的這條路還沒有被完整跑通，所以已經在用的人值得升，新用戶要先看自己是不是這條路的目標人羣。哪幾類人是這條路的目標人羣，後面「誰該升和誰該等」一節裏逐類寫了。
服務器本身和模型列表
服務器這一層是能跑起來的。這一版的服務器裝好並啓動之後，第一個賬號建出來就是管理員。第一個用戶建完之後，公開註冊會自動關掉，而且設置改完之後也能存住。這些行爲都實際觀察到了。用戶平時是在瀏覽器裏打開 Open WebUI 的，電腦上的瀏覽器和手機上的瀏覽器都可以。用戶就在瀏覽器裏聊天。
文件上傳之後，處理最後走到了完成，抽取出來的文本也存了下來。普通用戶建對話時，結果跟着當時生效的權限設置走，強制權限打開時建對話會被拒絕，把強制權限關回去之後又能建成功。也就是說，Open WebUI 作爲一個平臺底座，在這一版裏是能正常工作的，問題不出在服務器本身能不能啓動。
問題出在旗艦功能不在服務器裏面。這一版的桌面伴侶應用叫 Tether，它的作用是把用戶自己的電腦配對進 Open WebUI。
Tether 是用戶裝在自己電腦上的那個桌面應用。Tether 在這臺電腦上運行的程序是 Open Terminal，而 Open Terminal 是託管這臺電腦上終端和編程 agent 的那個程序。編程 agent 由 Open Terminal 提供，Open WebUI 從已經配對的 Open Terminal 那裏取得編程 agent 的清單，編程 agent 纔會出現在模型選擇器裏。
只裝服務器、不通過 Tether 配對桌面端的時候，終端列表是空的，模型列表也是空的。終端列表是空的，意思就是沒有 Open Terminal 在提供編程 agent，所以模型選擇器里根本沒有編程 agent 可以選。發佈說明裏最顯眼的那一項，就是把編程 agent 放進模型選擇器這一項，在這種裝法下等於不存在。整個 agent 體驗都要靠 Tether 先把用戶自己的電腦配對進來。
先把後面要用的默認模型和一條退路說清楚。默認模型指的是事先定好、沒有另外指定時系統就用的那個模型。如果提供某個 agent 的 Open Terminal 後來不再可用，那麼已經用這個 agent 進行的對話，之後的回覆改由默認模型給出，這個 agent 以前已經寫下的回覆還留着這個 agent 的名字。
Tether 支持 macOS、Windows 和 Linux，它從用戶自己的電腦主動向外連到 Open WebUI，所以用戶不用開入站端口。這一條配對的路這次只在代碼裏覈實過，沒有端到端真跑過。
這一版的包本身也不輕。裝好的體積大約是 7.3 GB，因爲裏面帶了 torch 和 CUDA 這兩個體積很大的依賴；服務器跑起來之後，常駐內存大約是 1.1 GB。你如果打算把它裝在配置很低的機器上，那麼要先把這份體積和內存算進你的計劃裏。
這次的安裝走的是 pip 裝到一臺共享虛擬機上的路，沒有走 Docker 這條路，所以安裝花了多久這件事不能拿來推斷普通安裝。Docker 這條路這次沒有測，我也就不在這裏下判斷。
斷線之後的工作
斷線之後工作還在不在，我的裁定是機制對上了痛點，但是有上限。
因爲這次沒有真跑過斷線重連，所以這一項只能算部分解決，不能算已經驗證解決。
Tether 在用戶自己的電腦上運行的程序是 Open Terminal，終端和編程 agent 都由 Open Terminal 託管。Tether 和 Open Terminal 都把進程放在用戶自己的電腦上運行，所以瀏覽器這邊的連接斷掉之後，進程不會跟着停。斷線期間產生的輸出會被先存進緩衝區，等連接恢復之後，再回放到用戶重新打開的終端視圖裏。
終端輸出的歷史最多留 1 MiB，這個上限在代碼裏是固定的，agent 會話的輸出最多留 16 MiB，這個上限在代碼裏也是固定的。Tether 自己的輸出緩衝區默認是 256 KiB，這個數字是產品給的默認值。這三份緩衝區的上限並不都是同一種定法。
這三份存的不是同一種輸出：1 MiB 那份留的是終端自己產生的輸出歷史，16 MiB 那份留的是 agent 會話運行中產生的輸出，256 KiB 那份是 Tether 在桌面這一側給自己的輸出留的緩衝區。如果斷線期間的輸出超過了這些上限，那麼最早的那部分就會被丟掉，界面上會明確標出來，告訴用戶更早的輸出已經看不到了。
斷開的終端會在 300 秒之後被清掉，agent 會話則會保留 3600 秒，因爲脫離連接的 agent 可能還在忙。Open WebUI 的服務器在這條鏈路裏只做轉發，它不保存任何終端輸出，所以服務器那邊沒有一份副本可以拿來恢復。
這一項必須把話說全：上面這套續接的說法全部來自裝好的代碼，Tether 是桌面圖形應用，這次的環境裏沒有第二臺真機器可以配對，所以斷線再重連的完整過程沒有親眼跑過。你如果衝着斷線續接來用這一版，那麼你要知道，你買的是代碼裏寫明的機制，而不是一份已經實測過的保證。
工具批准的 Auto 檔
每次工具調用都要手動批准，用起來很累；如果全部放行，又太冒險。這一版新加的 Auto 檔想解決的就是這個取捨。
審覈有兩條路線，走哪一條路線由這套部署的管理員設置決定。一條叫 Default，在這條路線裏，審覈由主模型在對話裏面自己做，主模型就是正在處理這次對話的那個模型。另一條叫 Decisions API，在這條路線裏，審覈交給一個外部打分服務來做。
這裏說的證據包，就是系統爲一次工具調用準備的送審材料。這份材料裏裝的是這次調用的工具和工具的參數，另外還有用戶當前的請求和用戶最近的 4 條消息，還有這次調用的執行上下文，也就是這次調用的工具類型和它所走的終端編號。
我的裁定是它把批准改成了預審，方向是對的。會回到你手裏問批准的，是審覈完不成的調用。走 Decisions API 這條路線的時候，證據包超過字節上限，或者審覈超過時間上限，這次審覈都完不成。走哪一條路線都一樣，審覈結束的時候沒有給出有效的判定，這次調用也回到你手裏問批准。所以這一項也是部分解決。
一次真的被審覈過的工具調用，這次沒有跑起來過，因爲測試環境裏既沒有配聊天模型，也沒有打分服務的密鑰。打分服務是這套部署配置的一個外部服務，它給一次工具調用打分，用來判斷這次調用要不要再問用戶。所以審覈跑一整圈的速度和準頭，這次都沒有數據。
Auto 默認是關着的，要管理員打開。打開之後，每一次工具調用都會先送給一個審覈模型看一遍，只有審覈模型判定這次調用不需要再確認的時候，這次調用纔會直接執行。如果審覈模型判定需要確認，那麼這次調用就回到聊天裏問用戶批准。這裏說的審覈模型是一個統稱，具體由誰來審，要看下面兩條路線裏走的是哪一條。
所以審覈模型這個說法，走 Default 路線時指的就是主模型，走 Decisions API 路線時指的就是那個外部打分服務，兩個名字說的不是同一個角色。這裏的 Default 是審覈路線的名字，它不是默認模型。
審覈審不了的時候，結果也是一樣問用戶。走 Decisions API 這條路線的時候，系統會先把材料組成一個證據包，再把這個證據包發給打分服務。
這個證據包裏裝的是工具和工具的參數，另外還有用戶當前的請求和用戶最近的 4 條消息，還有這次調用的執行上下文。如果這個證據包寫成文本之後超過了 65,536 個字節，那麼審覈直接跑不起來，這次調用就改問用戶。
這條路線上的審覈調用還有一個 5 秒的整體超時，超過 5 秒沒有審完，同樣改問用戶。這條路線上打分服務的地址，在產品裏預先設的是 OpenAI 的接口地址，部署可以改成別的地址。
走 Default 這條路線的時候，主模型在對話裏面自己審。主模型審的時候照着一份工具批准的策略文本判斷，裏面寫明什麼樣的調用可以不問用戶就直接執行、什麼樣的調用要先問用戶。這份策略文本，產品本身就帶了一份默認的文本，每套部署也可以改掉它。審得嚴不嚴，最後取決於這套部署現在用着的那份策略文本寫成了什麼樣，也就是產品自帶的那份默認文本，或者這套部署自己改過的那份文本。
所以 Auto 沒有把批准這一關拿掉。每一次審不了、審不完或者材料太大的情況，結果都往問用戶這一邊倒，這個倒向是安全的。
它帶來的另一面也很明確。證據包更大、審覈要花的時間更長的調用，越容易被這些上限擋回來，最後還是要你自己點批准。
工具對話的費用
工具對話太貴這一項，我的裁定是機制成立，但是省多少沒有人能替官方作證。官方原話只說 cost much less，也就是便宜了很多，官方沒有給任何百分比，所以這篇文章裏不會出現省了百分之多少這種數字。
機制本身是說得通的。以前每一輪工具調用，引用說明、記憶召回、技能清單和附加知識都要被重寫進對話開頭。引用說明講的是引用該怎麼標。記憶召回是把先前記住的內容重新調回來。技能清單就是模型能用的技能的那份清單。附加知識是另外附進對話裏的知識內容。
因爲對話開頭每一輪都在變，所以模型服務商沒有辦法把這一段存進緩存裏複用。
這一版把這四樣內容挪到了用戶消息後面的隱藏工具結果裏，對話開頭在多輪請求之間就保持不變了。因爲開頭保持不變，所以服務商可以把開頭這一段從 prompt cache 裏直接取出來用，prompt cache 就是服務商把已經處理過的文本存下來、下一次直接取用的那份緩存。
影響寫在明處：你自己寫的 custom pipes，也就是你自己寫的消息處理代碼，看到的消息佈局變了。最後一條消息可能是一條工具消息，不再一定是用戶消息。如果你維護着這樣的代碼，那麼升級之後要先檢查讀最後一條消息的那部分邏輯。
文件進模型手裏的方式
文件這一項是這次幾個痛點裏解決得最完整的一項，我的裁定是解決了。這次當場驗證過的，是文件上傳、文字抽取和抽取全文存下來這幾步，這幾步不是隻靠讀代碼得出的結論。聊天裏真的把文件用起來的那一步這次沒有跑，關於那一步的說法來自代碼覈實，本節末尾會再說明一次。
這一節要用的門檻先說清楚。這道門檻是 50,000 個字符，它在一份文件被放進聊天的時候才用，文件存下來的時候不用這道門檻。後面說一份文件超過門檻，指的就是它的抽取文本超過了 50,000 個字符。
文字抽取在文件上傳的時候就做，每一份上傳的文件都做，不等到聊天的時候才做。抽出來的全文會被完整存下來，不會因爲字符數超過門檻就被截斷，而且同一份文本還會被切塊並建好索引，留着給後面的檢索用。
這次實測上傳了兩個文件。一個是 1,440 個字符的小文件，另一個是 62,000 個字符的大文件。兩個文件的處理狀態最後都到了完成，而且兩個文件存下來的抽取文本都是全文，因爲大文件超過門檻也照樣存了全文。
50,000 個字符的這道門檻是在文件被放進聊天的時候才用的。單獨一份文件，如果它的抽取文本是 50,000 個字符或者更少，那麼全文直接進上下文，不走檢索。這裏的比較包含正好 50,000 個字符，發佈說明寫的是短於纔算，和代碼裏的比較對不上，以代碼爲準。
如果你掛進聊天的是一整個知識庫，也就是一整組文件作爲一個整體，那麼這道門檻就不適用。系統默認走檢索，除非你對這個知識庫明確選了用全文。
這一項也要留一句沒測到的。聊天補全，就是模型真的用上傳的文件產出一條聊天回覆的那一步，這一步這次沒有跑，因爲測試環境裏沒有配聊天模型。聊天時把單獨一份文件的全文放進上下文的那個分支是代碼覈實過的。這個分支就是：單獨一份文件的抽取文本在 50,000 個字符門檻以內時，系統會把這份文件的全文放進上下文。
管理員對保存的控制
團隊和合規場景裏，管理員管不住對話保存是一個真痛點。我的裁定是這一項解決了，而且是後端硬攔，不是界面上勸一句的那種解決。
開關是一項用戶組權限，名字是 Enforce Temporary Chat，位置在 Admin Panel > Users > Groups > Default Permissions 裏面。
管理員把這項權限打開之後，非管理員用戶新建一段會保存下來的對話，後端會直接拒絕，並返回 403。管理員自己不受這項權限的限制。
這一項是當場翻過設置的。權限打開之後，非管理員的測試用戶建對話被拒，對話列表保持是空的。同一個設置下，管理員建對話成功。把權限關回去之後，非管理員用戶建對話又恢復成功，所以兩個方向都觀察到了。
順帶說一句，側邊對話是另外開的一類對話。在上一版 0.13.0 裏，側邊對話一直不保存。這一版開始，側邊對話會像普通對話一樣保存下來，並出現在對話列表裏。正因爲側邊對話現在會保存，上面這項強制臨時的權限才更有用，因爲管理員多了一個要管住的入口。
服務等級的選擇
發佈說明說用戶可以選服務等級，我的裁定是這一項的名頭比實際內容大得多，它更像這一版的一個短板，而不是一個已經做完整的功能。
這一版點名了三個編程 agent，名字是 Claude Code、Codex 和 Pi。這三個 agent 裏面，只有 Codex 會把服務等級報給 Open WebUI。Claude Code 和 Pi 都不報，所以你用這兩個 agent 的時候，界面里根本不會出現服務等級這一項。這件事不是界面藏起來了，而是這兩個 agent 的代碼裏就只返回了名字，沒有返回等級。
Codex 這邊也只有一個等級。從真 Codex 程序裏拿到的結果很清楚，它下面的 8 個模型每一個都只報了一個等級，名字是 Fast。
Fast 的說明文字寫的是速度 2 倍、使用量增加，小模型上寫的是速度 1.5 倍。
下面說的 Service tier 子菜單顯示的樣子，是從裝好的產品代碼裏讀到的，這次測試裏沒有在真界面裏把這個控件點開過。你在聊天裏打開 Service tier 子菜單的時候，看到的列表第一項是 Default，列表裏剩下的項，就是 agent 報上來的那些等級。
列表裏的 Default 這一檔用的就是 Codex 自己默認的處理方式，選它不會另外發出一條服務等級指令。這個 Default 是服務等級列表裏的第一項，它不是審覈路線裏那條叫 Default 的路線，也不是前面說的默認模型。也就是說，除了 Default 之外，你能多選的就只有 Fast 這一個。
按代碼裏讀到的樣子，更麻煩的一點是說明文字在界面裏被丟掉了。你在聊天裏的 Model controls 裏面打開 Service tier 子菜單，你只會看到 Fast 這個名字。你看不到速度 2 倍、使用量增加這句說明，所以你是在不知道要多付多少使用量的情況下做這個選擇。
這一版的優點和不足
這一版的優點，先說工作地點和批准位置配在了一起。工作在用戶自己的電腦上做，文件和倉庫都在那臺電腦上，所以 agent 不用把代碼搬到遠處去執行。批准這一關也留在聊天裏。一次工具調用只要被送到用戶面前，用戶就是在自己的對話界面裏決定放不放行。Auto 沒有把這一關搬到別的地方去，它只是在調用到達這一關之前先篩一遍，它沒有放行的調用，最後還是回到聊天裏的這一關來等用戶決定。
第二個優點是這一版的失敗方向是一致的。審覈審不了的調用就問用戶，證據包太大的調用也問用戶。提供 agent 的終端不在了，既有對話就改由默認模型回答，而且舊回覆上還留着那個 agent 的名字。每一條退路都往用戶這一邊退，沒有一條是悄悄放行或者悄悄丟掉。
文件管線的處理方式也是一個優點，因爲存下來的文本永遠是全文，門檻只決定用的時候是全文直入還是走檢索，不決定存的時候砍不砍。管理員那項強制臨時的權限也是硬執行，後端直接拒絕，不是把按鈕藏起來就算管住了。
不足同樣要說全。最大的不足是旗艦功能對桌面配對的依賴。沒有配對的桌面端，服務器裝得再好，模型列表也是空的。所以這一版最想賣的體驗，對只裝服務器的人來說第一步就斷了。
Auto 檔的不足有一部分落在 Decisions API 這條路線自己的上限和超時上。走這條路線的時候，證據包超過 65,536 個字節就審不了，審覈超過 5 秒也審不了。所以走這條路線的複雜調用回到手動批准不是偶發情況，而是這個設計本來就會發生的結果。
服務等級的不足前面已經判過了。一個 agent、一個等級、還沒有說明文字，這個選擇目前撐不起發佈說明裏的說法。
升級本身的成本也是不足的一部分。這一版改了數據庫的結構，官方強烈建議生產環境升級之前先備份數據庫和這套部署的相關數據，官方沒有列出相關數據具體包括哪些。如果你跑的是多實例部署，那麼所有實例必須同時更新。實例指的是一份正在運行的 Open WebUI。滾動更新指的是一份一份輪流更新的做法，這種做法不受支持，因爲新舊版本混着跑會因爲數據庫結構對不上而出故障。
誰該升和誰該等
已經在跑 Open WebUI 的人，我的建議是升。這一版帶了安全修復，官方強烈建議所有部署儘快更新。修復的細節要等 CVE 編號分配之後纔會公佈。CVE 編號是給安全漏洞編的公開編號。所以你沒有辦法先看細節再決定。你能做的決定就是先付備份這份成本，然後把這一版升上去。
速度上的改進對已有用戶也是實在的，而且這些數字是官方給的，不是我測的。大對話打開的速度約快了 2 倍，把對話標成已讀或者未讀、去掉一個標籤這類操作快了 4 到 6 倍。往輸入框裏粘貼 16,000 行文本之後再打字，每次擊鍵的等待從 8.6 秒降到了 74 毫秒，官方的說法是約快了 117 倍。
已經在自己電腦上用 Claude Code 或者 Codex 做開發、又想把它們收進同一個聊天界面裏的人，這一版值得一試。前提是你先接受發佈說明裏寫明的三條限制。每段對話只用一個 agent；agent 的回覆不能重新生成，也不能接着往下續寫；你自己發出的消息也不能編輯之後重新發送。
只把 Open WebUI 當聊天前端用的人，這一版的頭條功能不是衝着你來的。你能拿到的好處主要是上面那些速度改進，還有文件處理方式變清楚了，所以你可以按自己的升級節奏來，不用爲了 agent 這一條線趕時間。
需要 agent 這條路先被完整證明、或者跑着多實例又沒有辦法同時更新全部實例的人，我的建議是等。
前一類人等的是桌面配對之後端到端跑通的證據，這次的測試恰好說明這份證據現在還沒有。後一類人等的是自己的維護窗口，因爲混版本運行會直接出故障，這個風險不是靠小心就能繞過去的。
說到底，這一版真正要緊的改變只有一件：編程 agent 工作的地點搬到了用戶自己的電腦上，批准的權力留在了用戶自己的聊天裏。
這次測試的證據能支撐到的地方很明確。服務器能跑，文件處理解決了，管理員控制也解決了。這次測試的證據支撐不到的地方，是桌面配對之後那條完整的 agent 路，還有服務等級子菜單在真界面裏顯示的樣子。用戶在讓這條路碰自己的真實倉庫之前，最好先等這條路有人完整跑通的消息。
覺得有幫助的話，歡迎訂閱這個博客，或者先收藏起來。我會繼續分享 AI、安全和開源方面的乾貨。下一篇我繼續盯編程 agent 在自己機器上工作的這類工具，看看哪一條路先被完整跑通。
來源：Open WebUI 0.13.1 發佈頁面，https://github.com/open-webui/open-webui/releases/tag/v0.13.1