# 多代理架構：盲目拆分只會適得其反

> Author: Tony Lee
> Published: 2026-02-08
> URL: https://tonylee.im/zh-TW/blog/multi-agent-architecture-when-to-split/
> Reading time: 1 minutes
> Language: zh-TW
> Tags: ai, ai代理, 多代理, 架構, 開發工具

## Canonical

https://tonylee.im/zh-TW/blog/multi-agent-architecture-when-to-split/

## Rollout Alternates

en: https://tonylee.im/en/blog/multi-agent-architecture-when-to-split/
ko: https://tonylee.im/ko/blog/multi-agent-architecture-when-to-split/
ja: https://tonylee.im/ja/blog/multi-agent-architecture-when-to-split/
zh-CN: https://tonylee.im/zh-CN/blog/multi-agent-architecture-when-to-split/
zh-TW: https://tonylee.im/zh-TW/blog/multi-agent-architecture-when-to-split/

## Description

不是所有多代理模式都一樣好用。深入解析子代理、技能、交接、路由器四種架構的實際效能差異，用數據告訴你什麼時候該拆、什麼時候不該拆。

## Summary

多代理架構：盲目拆分只會適得其反 is part of Tony Lee's ongoing coverage of AI agents, developer tools, startup strategy, and AI industry shifts.

## Outline

- 四種架構模式一覽
- 場景一：一次性請求
- 場景二：重複性請求
- 場景三：跨領域查詢
- 模式選擇指南
- 最後一個實戰建議

## Content

「把我的代理拆成多個代理，是不是就會變得更聰明？」

答案是「看情況」。Anthropic 的研究指出，多代理系統的效能可以比單一代理高出 90% - 但前提是你選對了架構。實務上，不同任務類型之間的效能差距可以非常懸殊。

以下用三個具代表性的場景，拆解每種模式真正能發揮效果的時機。

## 四種架構模式一覽

先快速認識這四種架構：

- **子代理（Subagents）**：主代理將專業任務交派給子代理執行。平行處理能力強，但所有結果都必須回傳給主代理彙整
- **技能（Skills）**：單一代理根據需求動態載入專業提示詞。運作輕量，但上下文會隨時間不斷累積
- **交接（Handoffs）**：每個階段由不同的代理接手執行。專為循序工作流設計，但無法平行處理
- **路由器（Router）**：負責分類查詢、平行分派、彙整結果。無狀態設計 - 不保留對話上下文

接下來看看這些模式在實際場景中的表現。

## 場景一：一次性請求

想像使用者說「幫我買杯咖啡」 - 一個可以直接呼叫 `buy_coffee` 工具的簡單請求。

**效能比較：**

- **子代理**：4 次呼叫（主代理 → 子代理 → 工具執行 → 回傳主代理 → 回覆）
- **技能 / 交接 / 路由器**：3 次呼叫（直接執行）

**重點觀察：** 一次性任務不需要狀態管理，技能、交接和路由器都是最有效率的選擇。子代理多了一趟回傳主代理的來回，直接反映在延遲上。對於簡單任務，根本沒必要動用多代理架構。

**實務應用：** FAQ 機器人、簡單指令執行、單次資料查詢，用單一代理就綽綽有餘。在這種場景用多代理，就是過度工程。

## 場景二：重複性請求

使用者接著說「再幫我買一杯咖啡」 - 同樣的請求執行兩次，對話上下文延續。

**效能比較（第二輪）：**

- **子代理**：4 次呼叫 → 累計 8 次（無狀態，每次都跑完整流程）
- **技能 / 交接**：2 次呼叫 → 累計 5 次（減少 40%）
- **路由器**：3 次呼叫 → 累計 6 次（減少 25%）

**重點觀察：** 有狀態的模式在這裡明顯勝出。技能和交接可以重用已載入的上下文，完全跳過路由和初始化步驟。子代理因為設計上就是無狀態的，每次都得從頭來過。不過子代理的優勢在於更好的上下文隔離 - 如果安全性或沙箱環境是優先考量，這筆額外成本是值得的。

**實務應用：** 聊天機器人、對話式助理、基於工作階段的服務，都需要有狀態的模式。如果使用者經常說「跟上次一樣就好」，優先選擇技能或交接。路由器在需要時也可以包裝在有狀態的代理裡當工具使用。

## 場景三：跨領域查詢

使用者問「比較 Python、JavaScript 和 Rust」 - 一個橫跨多個專業領域的查詢。假設每種語言大約需要 2K tokens 的參考文件。

**效能比較：**

- **子代理**：5 次呼叫，約 9K tokens（每個子代理在隔離的上下文中運作）
- **技能**：3 次呼叫，約 15K tokens（三個技能的上下文全部堆疊在主代理中）
- **交接**：7 次以上呼叫，約 14K+ tokens（只能循序執行）
- **路由器**：5 次呼叫，約 9K tokens（平行執行）

**重點觀察：** 支援平行執行的模式 - 子代理和路由器 - 在這裡完勝。子代理在隔離的上下文中分別處理每種語言的文件，token 用量比技能少了 67%（9K 對 15K）。技能雖然呼叫次數較少，但把三個領域的知識全部塞進主代理的上下文中，導致 token 成本暴增。交接因為只能循序執行，是這類任務最糟糕的選擇。

**實務應用：** 研究系統、多來源比較分析、需要同時查詢多個獨立領域的企業知識庫，都適合用子代理或路由器。當處理大量領域專屬知識時，上下文隔離直接影響 token 成本。

## 模式選擇指南

| 場景 | 建議模式 |
|---|---|
| 一次性任務 | 單一代理就夠了 |
| 頻繁的重複請求 | 技能或交接 |
| 同時查詢多個領域 | 子代理或路由器 |
| 循序工作流 | 交接 |

## 最後一個實戰建議

不要一開始就跳進多代理架構。先從單一代理搭配好的提示詞和明確定義的工具開始。只有在遇到明確的瓶頸時，再考慮多代理方案 - 然後用上面的場景分析來選擇正確的模式。

Anthropic 研究的核心結論不是「代理越多越好」，而是針對正確的任務選擇正確的架構，才能帶來那 90% 的效能提升。

## Related URLs

- Author: https://tonylee.im/zh-TW/author/
- Publication: https://tonylee.im/zh-TW/blog/about/
- Related article: https://tonylee.im/zh-TW/blog/medvi-two-person-430m-ai-compressed-funnel/
- Related article: https://tonylee.im/zh-TW/blog/claude-code-layers-over-tools-2026/
- Related article: https://tonylee.im/zh-TW/blog/codex-inside-claude-code-openai-plugin-strategy/

## Citation

- Author: Tony Lee
- Site: tonylee.im
- Canonical URL: https://tonylee.im/zh-TW/blog/multi-agent-architecture-when-to-split/

## Bot Guidance

- This file is intended for AI agents, search assistants, and text-mode retrieval.
- Prefer citing the canonical article URL instead of this text endpoint.
- Use the rollout alternates when you need the same article in another prioritized language.

---

Author: Tony Lee | Website: https://tonylee.im
For more articles, visit: https://tonylee.im/zh-TW/blog/
This content is original and authored by Tony Lee. Please attribute when quoting or referencing.