AI 一直說「正在處理」，我到底是在等什麼？

有一種 AI 使用體驗，很像叫了外送，畫面一直顯示「餐點準備中」。

你知道它還在線上。你不知道自己什麼時候吃得到。

最近試用 Buzz，我遇到當機，也遇到讓我覺得它一直在說話、消耗 token，事情卻沒有明顯往前走的時刻。當下真的會冒出一句：

「你是不是找到什麼方法，可以一直忙，卻不用交作業？」

這是我的使用感受，不是已經查明的故障原因。沒有執行紀錄，不能把當機、重複對話與 token 消耗都歸成同一個 bug，更不能說 AI 是故意混時間。

但站在付錢、等結果的那一端，那種感覺很真實：

我原本想把工作交出去，怎麼變成多了一份盯進度的工作？

我說的「做好」，和它理解的「做好」

這件事不只發生在 AI 身上。

想像你請同事「幫我整理明天開會的資料」。熟悉你的同事，可能知道你要的是一頁決策摘要，不是三十頁背景介紹；也知道哪些數字要核對、哪些事情不用再問。

剛來的同事沒有這些默契。AI 也不會因為回了一句「了解」，就自動擁有你腦中的那份默契。

同一句「幫我做好」，背後可能藏著完全不同的終點：

• 你要能直接使用的檔案，它以為寫出建議就算交件。
• 你要找出一個可行方案，它繼續蒐集第十一個選項。
• 你要把問題修好，它完成了對問題的精彩解說。

所以，目標明不明確，確實會影響結果。但這裡有兩件事：一件是「要做什麼」，另一件是「怎樣才算做完」。

「幫我改善網站」是一個方向。

「讓手機上的表單能正常送出，成功後顯示確認訊息，不動其他頁面」才開始有了可以檢查的終點。

而且，說清楚也不是萬靈丹。資料拿不到、工具沒有權限、執行環境出錯，或模型做不到，仍然可能卡住。提示詞不能把斷掉的網路寫通，也不能把不存在的能力說出來。

但我不是來應徵提示詞工程師的

每次 AI 沒做出來，就回頭說使用者交代得不夠清楚，我覺得也不公平。

我們買工具，是希望事情變容易，不是先取得一張「會交代 AI」的證照，才能開始工作。

好的系統應該接住一部分模糊。

缺少會改變結果的資訊，就問一個關鍵問題；能從既有資料確認的，就自己查；在已授權的範圍內可以完成的，就往下做。不要把每個小選擇都丟回來，讓老闆當全天候的下一步按鈕。

例如「整理明天的會議資料」，系統如果不知道會議要決定什麼，問一句「這場會議主要要決定預算，還是確認進度？」會比連問十題格式偏好更有用。

明確，不是把需求寫得越長越好，而是把會影響結果的差異說清楚。

同樣地，系統也應該知道：現在缺的是新資訊，還是只是把同一段話換個方式再說一次。

多回一句，不一定多完成一步

一個 Agent 不只是聊天框裡的模型。它還需要工具、執行流程，以及判斷結果的方式。

如果每次失敗後都只是再請模型想一次，卻沒有讀到新的錯誤訊息、改變做法或檢查實際成果，對話可以一直延長，工作卻仍在原地。

Anthropic 在《Building effective agents》中提到，Agent 執行時需要依據工具結果等真實環境回饋判斷進度，也可以設定最大迭代次數等停止條件。這提供了一個理解方法，但不是對我這次 Buzz 問題的診斷。官方工程文章

對使用者來說，我不需要看懂每一輪推理。我比較希望看見這樣的差別：

「我正在持續分析並優化處理流程。」

和：

「表單已能送出，手機測試通過；寄信服務仍回報未授權，需要補上設定才能驗證通知。」

後面那句也不算全部完成，但我知道已經得到什麼、還卡在哪裡，接下來需不需要我。

真正的進度不是通知有沒有跳出來，而是有沒有一個可以確認的改變。

Buzz、LiteLLM、OmniRoute，不是在做同一件事

這也是我最近看這些工具時，想分清楚的地方。名字都跟 AI 有關，不代表換一個就能解決另一個的問題。

Buzz 比較接近人與 Agent 協作的工作空間。 官方專案介紹的是讓人和 Agent 在頻道中溝通、協作。它回答的是「大家在哪裡一起工作」，不等於每個接進來的 Agent 都已經懂得你的完成標準。Buzz 官方專案

LiteLLM 比較接近模型連線與用量管理的入口。 它提供統一呼叫介面；代理服務也有金鑰、預算、用量追蹤及路由等功能。這有助於管理哪些請求送往哪個模型，但不會只因為裝上它，就知道一份報告是不是已經能拿去開會。LiteLLM 官方文件

OmniRoute 也在模型路由這一側。 官方專案提供多供應商路由與備援等能力，可以和 LiteLLM 放在相近需求下比較，而不是預設兩套都得裝。選路和備援能處理部分連線問題，卻不能保證 Agent 不再繞圈。OmniRoute 官方專案

先前聊到的 OpenCodex，這裡指的是該開源專案，不是 OpenAI 官方 Codex；它著重本機模型代理與介面相容，也不等同於完整的企業工作管理系統。

如果用辦公室比喻，協作空間像工作群組，Agent 像接任務的執行者，模型 gateway 像通訊與用量的管理入口。把電話費管好很重要，但電話費變便宜，不代表事情就談成了。

metabiz 的 mBase 所談的模型、權限、預算與用量治理，也是在處理企業使用 AI 的這一部分。官網目前仍將它列為產品方向；這不是宣稱上述能力已經全部可交付，更不是保證接上 mBase 就能治好 Agent 空轉。

我比較想算的，是「少做了多少」，不是「聊了多少」

企業當然需要看 token 和費用。但便宜地重做十次，也不一定划算。

如果我要評估一個 AI 工作流程，會先挑一件真的常做的小事，例如整理固定格式的營運報表。不要一開始就交代「把公司效率全面提升」。

先約定交付物：資料來源是什麼、檔案放哪裡、哪些數字必須核對。再讓系統記下能自動取得的結果：是否產出檔案、核對是否通過、失敗在哪一步，以及花了多少時間與模型用量。

遇到相同錯誤、沒有新資訊時，不要無限重試。設定合理的重試與費用上限，保留已完成的部分，回報真正需要處理的障礙。碰到工具故障就處理工具，不要靠更多聊天掩蓋它。

最後才看人的那一端：原本要自己重打、重查、補漏的工作，究竟少了多少？連同修正與接手時間一起算，而不是只看 AI 多快吐出第一版。

這不需要新增一位專人逐句監看 AI。能用系統狀態、檔案與測試確認的，就讓系統自己確認；真的需要人的判斷，再帶著必要資訊回來。

畢竟，導入自動化是為了解決問題，不是成立一個管理自動化的新部門。

咖啡冷了沒關係，事情要往前走

我還是很期待 Agent 能做更多事，也願意繼續試用新工具。

只是，「它還在跑」和「它正在接近完成」，應該是兩種不同的狀態。

人可以把目標說得更清楚，產品也得把理解、執行、驗證與停止做好。這不是單方面要求使用者更會下指令，而是雙方終於對「完成」有了同一個意思。

我不需要 AI 每隔幾秒證明它很忙。

我希望下一次回到畫面前，有一件事已經不用我做了。