engineering architecture

Agent Swarm:當一個 AI 不夠用,NanoClaw 如何協調多個 Agent

NanoClaws.io

NanoClaws.io

@nanoclaws

2026年2月26日

9 分鐘閱讀

Agent Swarm:當一個 AI 不夠用,NanoClaw 如何協調多個 Agent

你請 AI 助理研究競爭對手的產品、整理發現、撰寫比較文件,然後寄給你的團隊。單一 agent 可以完成這些步驟中的每一個——但要做好這些、按順序執行、同時在四個任務之間維持上下文,已經逼近了單一 agent session 能優雅處理的極限。Context window 被塞滿了。Agent 忘記了前面的步驟。最終輸出的品質下降了,因為模型同時在處理太多事情。

這就是 agent swarm 要解決的問題。不是讓一個 agent 做所有事,而是由一個協調者 agent 把任務拆成子任務,然後委派給專門的 agent。研究 agent 搜尋網頁並回傳結構化的發現。寫作 agent 拿到這些發現並撰寫文件。郵件 agent 發送結果。每個 agent 在自己的容器中運作,擁有自己的 context window,專注於一件事。

這個概念不新——CrewAI 和 AutoGen 已經探索多 agent 模式超過一年了。NanoClaw 的做法不同之處在於,swarm 中的每個 agent 都在自己的隔離容器中運行,這意味著適用於單一 agent 對話的安全和隔離保證,自動延伸到多 agent 工作流程。

Swarm 在 NanoClaw 中如何運作

NanoClaw 的 swarm 架構建立在一個簡單的原語上:一個 agent 可以產生其他 agent。當 Claude Code 在容器內運行時,它可用的工具之一就是 agent 委派——描述一個子任務,讓 NanoClaw 啟動一個新容器來處理它。父 agent 在子 agent 完成時取回結果。

協調是透過 Claude 自身的推理自然發生的。你不需要定義工作流程圖或在 YAML 檔案中設定 agent 角色。你描述你想要什麼,Claude 決定是直接處理還是把部分委派給子 agent。這個決策基於讓 Claude 擅長拆解複雜問題的同一種推理能力——它能辨識出任務中有哪些獨立的組成部分會受益於專注的處理。

實際上,這看起來像一棵容器樹。根容器接收你的訊息,決定它需要網頁研究和文件撰寫,產生兩個子容器,等待它們的結果,然後綜合出最終回應。每個子容器都有自己的 CLAUDE.md 上下文、自己掛載的工作區和自己的工具集。研究 agent 啟用了網頁瀏覽;寫作 agent 有對共享工作區的檔案寫入權限。兩者都無法存取對方的上下文或工具。

為什麼容器隔離對 Swarm 很重要 大多數多 agent 框架讓所有 agent 在同一個程序中運行。CrewAI 的 agent 共享一個 Python 執行環境。AutoGen 的 agent 共享一個對話執行緒。這在 demo 中能用,但在規模化時會產生事後難以修復的問題。

第一個問題是爆炸半徑。如果 swarm 中的一個 agent 遇到 prompt injection——一個試圖劫持 agent 行為的惡意網站——注入被限制在那個單一容器中。它無法影響父 agent、無法存取其他子 agent 的上下文,也無法讀取原始使用者的對話歷史。被入侵的容器在完成時被銷毀,父 agent 收到它產生的任何輸出(父 agent 可以在使用前評估品質)。

第二個問題是資源競爭。共享程序中的 agent 競爭相同的 context window、相同的記憶體和相同的 CPU。在 NanoClaw 中,每個容器都有自己的資源。一個正在瀏覽大量網頁的研究 agent 不會拖慢一個正在撰寫文件的寫作 agent。容器在不同的執行緒上並行運行,主機的資源管理負責排程。

第三個問題是憑證範圍。研究 agent 需要網頁存取但不應該有檔案寫入權限。檔案管理 agent 需要磁碟存取但不應該有網頁存取。在共享程序的框架中,強制執行這些邊界需要應用層的權限檢查,而這些檢查可以被繞過。在 NanoClaw 中,邊界就是容器掛載——研究 agent 確實無法寫入磁碟,因為沒有可寫路徑被掛載到它的容器中。

實際的 Swarm 模式

從實際使用中浮現的模式比理論架構更有趣。最常見的是研究與綜合模式:父 agent 產生 3-5 個研究 agent 來平行調查一個問題的不同面向,收集它們的發現,然後產出一個比任何單一 agent 在一次通過中能產出的更全面的綜合答案。

第二個常見模式是草稿與審查。一個 agent 寫初稿,然後產生一個審查 agent 並指示它進行批評。審查者的回饋回到原始 agent(或一個新的撰寫 agent)進行修改。這比單次生成產出明顯更好的結果,因為審查 agent 有一個全新的 context window,可以在沒有撰寫它的認知負擔下評估草稿。

第三個模式是工具專門化。有些任務需要昂貴或有風險的工具——網頁瀏覽、shell 命令執行、檔案系統修改。父 agent 可以把這些操作委派給具有特定工具存取權限的子 agent,保持自己的上下文乾淨、自己的權限最小化。父 agent 永遠不會直接碰檔案系統或網路;它只處理子 agent 回傳的結果。

Swarm 的限制

Swarm 不是免費的。每個子 agent 都是一次獨立的 Claude API 呼叫,意味著獨立的 token 費用。一個產生五個研究 agent 的 swarm,成本大約是單一 agent 做所有研究的五倍。對於簡單的問題——「天氣如何?」或「翻譯這句話」——swarm 純粹是額外開銷。

延遲也會累積。即使是平行執行,父 agent 也必須等待最慢的子 agent 完成才能綜合結果。一個五個 agent 的 swarm,其中一個因為瀏覽慢速網站而花了 30 秒,意味著使用者要等 30 秒加上綜合時間,不管其他四個有多快。

NanoClaw 務實地處理這個問題。Claude 根據任務複雜度決定何時使用 swarm——簡單問題直接回答,複雜的多部分請求則委派。使用者不需要設定 swarm 行為;他們只管提問,系統會根據複雜度調整方法。目標不是到處使用 swarm——而是在它們確實能比單一 agent 產出更好結果的地方使用。

多 agent 的未來不是要取代單一 agent。而是讓單一 agent 在需要時有能力尋求幫助,以安全、隔離且透明的方式。NanoClaw 的每 agent 一容器模型讓這成為可能,而不需要在共享環境中運行多個 agent 所帶來的安全妥協。

掌握最新動態

取得新版本發布、整合功能與 NanoClaw 開發的最新消息。不發垃圾郵件,隨時可取消訂閱。