# Anthropic 智能體架構 合併子智能體：系統精簡實操指南

> Anthropic智能體架構合併子智能體指南指出，盲目堆砌多智能體不僅增加延遲還會丟失細節；把子智能體摺疊為帶技能的單主循環，能讓系統運行速度大幅提升。

來源：https://www.starbox.work/zh-hant/insights/ai-news/2026-10-25-anthropic-agent-fold-subagents/（星盒AI 知識中心，更新於 2026-10-25）

2026 年 10 月 22 日，Anthropic Applied AI 團隊發佈了一份關於企業智能體構建的重磅指南。這份關於 **Anthropic 智能體架構 合併子智能體** 的指南明確指出：不少企業把業務組織架構照搬成了多智能體架構，導致系統極度臃腫。他們在多家企業實測中發現，把路由器、規劃器和各類領域子智能體摺疊進單個主循環，配合漸進式披露技能，整體表現反而比多智能體編排更好，任務耗時顯著縮短。

很多市場負責人和企業技術團隊以為智能體越多越智能，做個客服都要拆出意圖識別、路由分發、多輪推薦等五六個子 [Agent](/zh-hant/glossary/agent/)。這種堆砌正在拖垮企業系統的響應速度。

## Anthropic 智能體架構：為什麼必須考慮合併子智能體？

多智能體系統之所以變慢，本質上是資訊在不同[上下文窗口](/zh-hant/glossary/context-window/)之間搬運時出現了損耗。

一家做工業零部件出海的企業負責人曾向我抱怨，他們搭建的海外客戶答疑 Agent 每次回答都要轉圈五六秒。排查後發現，用戶進來的第一句話，先被意圖分類子智能體處理，再丟給檢索子智能體，接着交給行業術語修正子智能體，最後才由主編排器彙總。

每個子智能體都有獨立的上下文和提示詞，互相傳遞資訊就像玩「傳話遊戲」。Anthropic 在指南中指出了這種架構的典型代價：

1. **上下文丟失**：各個子智能體只拿到上一級修剪後的摘要，丟失了原始對話的細節與語境。
2. **提示詞打架**：各個業務團隊往系統裏塞規則，拼湊成一個混亂的大提示詞（Frankenprompt），導致輸出風格四分五裂。
3. **延遲與成本翻倍**：每次子智能體調用都是一次完整的模型推理與網絡往返。Anthropic 的客戶案例顯示，將多智能體架構重構為單個主循環後，任務運行時間得到明顯改善。

隨着模型能力提升，像 Opus 4.5、Opus 5.5 這類模型自帶自主規劃與反思能力，過去靠外掛多個子智能體來做流程控制的做法，很多已經不再必要。

## 智能體Skills模式：把上下文握在同一個主循環裏

Anthropic 提出的替代方案，是用「帶技能的單智能體循環」取代複雜的編排網絡。

這種做法的核心機制是漸進式披露：主 Agent 在開始時只加載工具和技能的簡要描述，不把成堆的業務規則一次性塞進初始提示詞。模型根據任務推進，在需要某項能力時，再去動態讀取對應的技能定義。

在這種模式下，整個任務都在同一個上下文窗口中運行。模型自己在首輪交互中列出計劃，工具返回數據後，模型看着原始結果當場調整下一步，而不是等待編排器層層轉譯。Anthropic 團隊在開發 Claude Code 時，就通過技能與工具的漸進式披露，將初始[系統提示詞](/zh-hant/glossary/system-prompt/)精簡了超過 80%。

少建一個子智能體，就少了一次上下文割裂，企業得到的回覆也更具連貫性。

## 多智能體架構優化清單：3 個合併信號與 2 個保留邊界

並不是所有子智能體都要立刻砍掉。Anthropic 指出，獨立子智能體在驗證、並行隔離和黑盒權限隔離上依然有價值。

為了幫企業理清改造優先級，我根據 Anthropic 官方指南整理了一份架構自查清單。對照這 5 個關鍵指標，團隊能一眼看懂哪些組件該收斂，哪些該保留：

| 評估維度 | 診斷現象 | 架構建議 | 改造動作 |
| :--- | :--- | :--- | :--- |
| **合併信號 1** | 子智能體之間高頻互相傳話，最終回覆常常丟失原始對話細節 | 摺疊進主循環 | 取消中間 Agent，將領域規則轉為主循環可調用的 Skills |
| **合併信號 2** | 單純為了按業務部門分工（如退貨、開票）設立了大量獨立路由子 Agent | 摺疊進主循環 | 收回中央團隊統一維護主提示詞，用輕量數據工具替代路由 |
| **合併信號 3** | 用戶交互延遲居高不下，調用鏈路中存在超過 3 次串行模型推理 | 摺疊進主循環 | 合併為單循環多工具調用，利用 harness 並行執行工具取回數據 |
| **保留邊界 1** | 主智能體上下文窗口因長線數據暴漲出現明顯的性能退化 | 保留子智能體 | 剝離出獨立子 Agent 處理海量數據，僅向主循環返回精煉結論 |
| **保留邊界 2** | 需要同時發起多路互不依賴的探索任務（如多來源獨立調研） | 保留子智能體 | 保留多智能體並行模式，任務結束後立即銷燬獨立上下文 |

## 從星盒的實踐看：精簡鏈路才能讓業務跑得動

星盒AI 在服務 500+ 家企業的過程中，也經歷過類似的認知迭代。

平台部署了 300+ 組實戰智能體，過去我們發現，很多企業在做內容生成時，總想讓一個 Agent 負責寫標題、一個 Agent 負責改錯別字、另一個負責配圖。這樣層層嵌套下來，一次生成要等兩分多鐘，前線業務員根本沒有耐心等待。

後來在「新媒體內容工廠」的落地中，我們將寫作邏輯重構為基於品牌知識庫和選題庫的垂直寫稿智能體，把九個維度的表達規則收斂到穩定的技能定義中。單條內容創作時間直接縮短到 5–10 分鐘，團隊人力成本降低約 90%，單人日產出達到 50–100 條。

工具鏈越短，資訊流轉越不容易變形。把控制權放回給模型本身，只在關鍵卡點設好工具攔截，往往是性價比最高的技術路線。

## 結語

軟件工程領域有一條規律：組織架構是什麼樣，系統架構往往就會長成什麼樣。

當業務團隊各自為戰時，系統就會生造出一堆互相踢皮球的子智能體。Anthropic 這次給出的指南是在提醒所有人：當基礎大模型變得更聰明，過去靠拼湊多智能體來彌補模型不足的過渡方案，已經到了該精簡的時候。