你的AI同事在后臺瞎忙？這個工具讓你看見它在干嘛

你有沒有遇到過這種情況：讓AI寫代碼，它說"好的，我來處理"，然后終端里滾過幾行日志，幾分鐘后遞給你一個結果——但你完全不知道它中間干了什么，更不知道如果出錯了該怎么找回剛才的狀態？

這就是多智能體（Multi-Agent，多個AI協作完成復雜任務）的痛點。作者volition79在GitHub上開源的Sonol Multi Agent，試圖用一張本地儀表盤解決這個問題。

一張圖看懂：它到底在解決什么

原文的核心邏輯可以用作者自己的話概括：「一旦任務變大，就很難看清整體計劃、在執行前審查它，以及跟蹤每個子智能體在做什么。」

Sonol的解法是把流程切成三塊，用可視化串起來：

1. 結構化規劃：把用戶的單一請求拆解成可執行的子任務清單

2. 人工審查節點：在真正執行前，彈出一個UI儀表盤讓你點頭或修改

3. 實時執行看板：多個子智能體并行干活時，你能看到誰在忙什么、卡在哪一步

這三個環節對應系統里的兩個技能包：sonol-multi-agent負責前兩塊（規劃+審批流），sonol-agent-runtime負責最后一塊（運行時狀態同步）。必須一起裝，缺一不可。

為什么非得"本地優先"？

作者花了相當篇幅解釋這個設計選擇，而且語氣很直接：「很多多智能體系統是云優先的。規劃器擁有狀態，儀表盤擁有狀態，過段時間瀏覽器會話開始感覺比實際干活的機器更重要。」

他想要完全相反的東西。

這不是潔癖。作者列了三個實際場景：

? 斷網或瀏覽器崩潰：云端狀態可能直接丟失，本地文件還在

? 調試時能直接翻日志：不用登錄某個Web后臺找trace ID

? 恢復執行更可控：從本地檢查點重啟，而不是等云端服務恢復

說白了，他把"狀態所有權"從瀏覽器手里搶了回來，還給用戶的文件系統。

實測環境：Codex CLI和Claude Code

作者明確列出了測試過的環境：

? Codex CLI（OpenAI的終端編碼工具）

? Claude Code（Anthropic的同類工具）在macOS上

后者還踩了個坑——第一次運行遇到環境特定問題，把終端報錯文本貼給作者后修好了。這個細節挺有意思：它暗示這套系統對路徑處理、運行時行為還比較敏感，不是開箱即用的黑箱。

作者也坦誠說了想要哪類反饋：

? 規劃質量：拆解的任務清單是否合理、可執行

? 運行時穩定性：長時間任務會不會丟狀態

? 恢復體驗：出錯了能不能從中間節點續跑

他特意加了一句：「這種反饋比只看demo的反應有用得多，因為整個項目的重點是讓多智能體工作流在真實開發環境里可用。」

這玩意適合誰？

不是所有人。如果你用ChatGPT網頁版偶爾問兩句代碼，完全沒必要折騰。

但如果你是那種會把復雜需求扔給Claude Code、讓它自動改十幾個文件的開發者，這個工具填補了一個真實空白：從"黑箱執行"到"白箱可審"。

作者的目標寫得很清楚：「不只是讓多智能體工作流成為可能，而是讓它們更容易跟蹤、更容易信任、更容易在出錯時恢復。」

三個"更容易"，對應的是當前AI編碼工具的三個真實痛點。

怎么用？

項目托管在GitHub（volition79/sonol-multi-agent），README里有完整安裝指引。需要同時裝兩個技能包，然后對著一個真實任務跑一遍——作者特別強調"真實任務"，不是玩demo。

如果你試完想給反饋，直奔那三個問題：規劃質量、運行時穩定性、恢復體驗。作者明顯更關心"這玩意能不能扛住生產環境"，而不是"這界面好不好看"。

這態度本身，可能比工具更值得注意。