# 多代理架構：亂拆只會適得其反

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

## Canonical

https://tonylee.im/zh-HK/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

「拆多幾個代理係咪會聰明啲？」視乎情況。Anthropic研究顯示多代理可以贏單代理90% - 但前提係揀啱架構模式。

## Summary

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

## Outline

- 四大架構模式
  - 子代理模式（Subagents）
  - 技能模式（Skills）
  - 交接模式（Handoffs）
  - 路由模式（Router）
- 場景對比：邊個模式贏？
  - 場景一：一次性任務
  - 場景二：重複性任務
  - 場景三：跨領域任務
- 揀模式嘅決策指南
- 最重要嘅一條建議

## Content

「將我個代理拆成幾個，係咪會變聰明啲？」呢個問題我最近收到好多次。答案係：視乎情況。

Anthropic 嘅研究數據顯示，多代理架構可以喺表現上贏過單代理高達 90% - 但前提係你揀咗啱嘅架構模式。如果唔理三七廿一就拆，唔單止冇提升，反而會引入額外嘅延遲、token 消耗同協調成本。

呢篇文章會拆解四種主流嘅多代理模式，用實際場景比較佢哋嘅優劣，幫你判斷幾時應該拆、幾時應該留。

## 四大架構模式

### 子代理模式（Subagents）

主代理將專業任務分派俾子代理，每個子代理就好似一個工具噉俾主代理呼叫。

- 天然支持並行執行 - 幾個子代理可以同時跑
- 所有通訊都要經過主代理路由，主代理係唯一嘅協調者
- 適合需要同時處理多個獨立領域嘅場景

好處係分工清晰，壞處係主代理變成瓶頸 - 所有結果都要匯報返去佢度做彙整。

### 技能模式（Skills）

單一代理按需載入專業提示詞同能力包。代理本身唔變，但佢嘅行為會根據載入嘅技能動態調整。

- 架構最輕量，唔使管理多個代理實例
- 上下文會累積 - 每一次互動嘅記憶都保留喺同一個上下文入面
- 特別適合需要跨步驟共享狀態嘅重複性任務

技能模式嘅優勢在於簡單同低開銷。但當上下文累積到某個程度，效能就會開始下降。

### 交接模式（Handoffs）

活躍代理喺每個階段完成之後，將控制權交俾下一個代理。好似接力賽 - 棒交出去就收唔返。

- 嚴格順序執行，冇辦法並行
- 每個代理專注處理流程中嘅一個環節
- 上下文喺交接時傳遞，但每個代理只睇到佢需要嘅部分

適用於有明確階段劃分嘅流水線式工作流，例如：分析 → 規劃 → 實現 → 審查。

### 路由模式（Router）

一個分類器喺最前面，根據請求類型將任務分派到對應嘅處理代理，最後聚合結果。

- 無狀態設計 - 路由器本身唔保留任何上下文
- 支持並行分派，唔同請求可以同時處理
- 適合需要處理多種類型請求嘅系統

路由模式同子代理模式有啲似，但路由器本身唔做任何實質工作，佢只係負責分流同聚合。

## 場景對比：邊個模式贏？

### 場景一：一次性任務

一個簡單嘅任務，例如「幫我寫個函數計算折扣」。

- **子代理**：4 次呼叫（路由 + 分派 + 執行 + 彙整）
- **其他模式**：3 次呼叫
- **結論**：單代理已經夠用，拆開反而多咗開銷

對於呢類直接嘅任務，多代理完全係殺雞用牛刀。

### 場景二：重複性任務

需要多次迭代嘅工作，例如「審查呢十個 Pull Request」。

- **子代理**：每次都要經主代理路由，累計 8 次呼叫
- **技能 / 交接模式**：狀態保留令重複工作更高效，累計 5 次呼叫（少 40%）
- **結論**：有狀態嘅模式完勝

當任務需要重複執行，上下文保留帶嚟嘅效率優勢會隨住迭代次數放大。

### 場景三：跨領域任務

需要同時處理前端、後端、數據庫嘅任務，例如「加一個新嘅 API endpoint 連埋前端表單」。

- **子代理 / 路由模式**：5 次呼叫，約 9K tokens - 並行處理唔同領域
- **技能模式**：所有嘢塞喺同一個上下文，約 15K tokens
- **結論**：並行模式節省 67% token 消耗

跨領域任務係多代理架構最能發揮價值嘅場景。將唔同領域隔離到獨立代理，可以避免上下文膨脹，同時利用並行執行加速。

## 揀模式嘅決策指南

| 場景特徵 | 建議模式 |
|---------|---------|
| 一次性、簡單任務 | 單代理（唔使拆） |
| 重複性、需要記憶 | 技能模式 / 交接模式 |
| 跨領域、可並行 | 子代理模式 / 路由模式 |
| 嚴格順序流水線 | 交接模式 |

## 最重要嘅一條建議

由單代理開始。寫好嘅提示詞。只有當你撞到明確嘅樽頸 - 上下文爆咗、任務太多元、需要並行加速 - 先至考慮拆成多代理。

好多團隊犯嘅錯誤係一開始就設計過度複雜嘅多代理系統。事實上，一個寫得好嘅單代理配合精準嘅提示詞，已經可以處理到大部分場景。多代理架構係解決特定問題嘅工具，唔係銀彈。

先確認你個問題真係需要多代理嚟解決，然後再根據場景特徵揀啱嘅模式。噉先至係正確嘅做法。

## Related URLs

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

## Citation

- Author: Tony Lee
- Site: tonylee.im
- Canonical URL: https://tonylee.im/zh-HK/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-HK/blog/
This content is original and authored by Tony Lee. Please attribute when quoting or referencing.