別把 Agent 架構畫成組織架構圖：一篇掘金長文，把「拆不拆子代理」攤成兩欄對照

先把背景補上。2026 年 10 月 22 日，Anthropic 應用 AI 團隊發布一篇企業實踐復盤，其中提到一個真實案例：某公司做了客服 Agent，按業務線掛了十幾個「專家子代理」，管訂單的、管物流的、管退款的、管帳戶的，分工圖畫得清清楚楚。結果一上線就露餡，用戶的提問從來不會乖乖只落在一個格子裡，一句跨領域的請求，就得在幾個子代理之間來回轉手。每次轉手，前一個子代理只交出一段壓縮過的摘要；對外說話的語氣，全看最後接話的是哪位專家；層數一多，用戶光等它們內部交接就要等半天。

10 月 27 日，掘金作者 LEE 以〈別把 Agent 架構畫成組織架構圖，子代理該不該拆，用任務級 Eval 說話〉為題，把這篇復盤整理成一篇 22 分鐘的長文，在開發者圈被轉發圍觀。文章的核心主張很直接：拿到需求的第一反應不該是「該拆成幾個子代理」，而是「你憑什麼拆」。

子代理買的是隔離，付的是傳話費

文章先把「子代理」講成大白話：它並非更懂業務的模型，本質上就是單開了一個新聊天視窗的模型。它有自己獨立的提示詞與工具，看不到主對話先前聊了什麼，全靠外面的協調器派活、傳話。

拆出子代理能換到三樣東西：上下文隔離（視窗乾淨，適合獨立調研或黑盒驗收）、並行（幾個互不相幹的子任務各自開新視窗同時跑）、權限邊界（不同子代理只發不同工具，互不越權）。

但帳不是只算一面。每拆一個子代理，都在付三筆「傳話費」：每次交接都要把過程壓成一段二手摘要，細節在壓縮中流失；每個子代理都要單走一輪提示詞與模型調用，層數一多耗時翻倍；每個團隊各管各的提示詞與測試，最後沒人對用戶拿到的最終結果負責。

兩種走法並排放著看

文章的另一條路是「單循環」：不搞分身，從頭到尾只有一個模型守著同一個上下文視窗。每一輪由模型決定要調哪些工具，外層的運行框架幫它並發執行，把原始結果原封不動塞回同一個視窗；模型看完結果，自己決定下一步是繼續查、問用戶，還是直接給答案。

原文用一張對照表把兩條路攤開，幾個關鍵維度如下：

• 記憶與上下文：子代理各自獨立視窗，交接靠傳摘要，容易丟細節；單循環同一視窗，前面查出的原始資料後面隨時可看。
• 並行能力：子代理天然適合多開視窗各跑各的；單循環靠單輪同時發多個工具調用並發，結果回同一視窗。
• 耗時與成本：子代理循環套循環、來回傳話，通常更慢更貴；單循環少掉中間交接輪次，通常更快更省。
• 團隊維護：子代理各管各的提示詞與局部測試，容易互踢皮球；單循環的主提示詞與端到端體驗有人兜底。
• 最大風險：子代理的風險是傳話失真與說話口氣割裂；單循環的風險是視窗塞太滿、提示詞與工具沒設計好。

一句話總結原文的立場：拆子代理，本質上是用「傳話丟資訊」和「變慢」，去換視窗隔離、並發與權限隔離。這筆買賣劃不劃算，看任務本身，不看架構圖畫得漂不漂亮。

Agent 為什麼會長成部門組織圖

長文接著追問成因：大公司做 Agent，最容易踩的坑是按部門分地盤。起點通常很單純，公司想做一個統一入口的超級 Agent，但訂單歸 A 組、物流歸 B 組、帳戶歸 C 組，怎麼推進最不得罪人？各組先閉門造自己的子代理，平臺組最後在頭頂加個總調度，或把各組的 Agent 包成 MCP 工具掛給主 Agent。

這種做法在組織管理上最省事，落到系統裡卻會炸出毛病，原文列了幾項：子代理之間不共享完整紀錄，來回倒手幾次，用戶的原始訴求就漏光了；每個組都發自己的子代理，最後攢出幾百個功能撞車的 Agent；每個團隊都往主提示詞裡塞兩句「必須遵守某某規定」，規則前後打架，Agent 說話像換了好幾個人，原文稱之為「縫合怪提示詞」。

最扎心的一條是各自刷分、沒人管總結果：每個組只拿自己那畝三分地的測試集刷分，單看每個子代理都是 95 分，串起來用戶還是辦不成事，回報給管理層的是一堆灌水的局部高分。這也是標題裡「任務級 Eval」的由來：判斷該不該拆、該不該收回，標準應放在端到端任務的測試數據，而非局部指標。

圍觀的工程師在想什麼

這篇長文在掘金被轉發的樣貌，其實延續了開發者圈近期對 Agent 架構的兩派拉鋸。有人把重心放在「能跑」與「能上線」之間的落差，例如先前那篇被轉瘋的從 while 迴圈到生產級 Agent 迴圈長文，討論的正是同一條主循環在概念與工程之間的距離；也有人關注多 Agent 協作的實際體感，像 V2EX 上兩個 Agent 互相討論把問題解決的圍觀，就把「多 Agent 到底是分工還是內耗」聊成了玩笑與省思。

LEE 的這篇整理沒有把話說死。文中引述的復盤並未主張「子代理沒用」，而是把問題倒過來：先讓一個模型在同一個視窗把活幹完，哪一塊真的頂不住了，再拿任務級的測試數據說話。順著這個思路，長文後半還談了已拆散的子代理怎麼安全收回、收回之後多個團隊怎麼一起幹活，底層框架的原始碼則留在文末延伸閱讀。

至於那家客服公司最後有沒有把十幾個專家子代理收攏回單循環，來源正文沒有給出後續，這裡也就不替它補上一個結局。架構圖好畫，傳話費難省，這筆帳最終還是得由任務數據來結。