如何組建有效率的 AI Agent 團隊

我們如何整理 memory、skills 和專案指令，讓 token 消耗減少 35%，新成員加入不需要任何教學。

如果你用過 AI 寫文章，你大概有過這種感受

每次打開新的對話視窗，都要花幾分鐘重新解釋背景——「我們是做建築五金的」、「語氣要專業」、「數據一定要有引用來源」。你把 AI 調教好了，但換個人來用，又回到原點。

更麻煩的是：隨著你越來越依賴 AI，你塞進去的設定越來越多。某天你發現，還沒開始工作，AI 就已經讀了 5,000 tokens 的背景資料——大部分跟今天的任務完全無關，但你一直在為它付錢。

某天我們在想：如果十個 AI 同時幫忙，而且每個都知道自己的角色、不需要重複教學，那會怎樣？這篇文章就是那個問題的答案。

AI 團隊確實很強，但用了幾個月之後，我們碰到了問題。

規模越大，問題越明顯。5 門課程、20 篇文章、越來越多的自動化工具——我們發現三個坑，幾乎讓整個系統失控。

💸 問題一：Token 燃燒太快

一開始，所有東西都塞在 memory 裡——12 個 AI agent 的分工流程、寫作標準、法規參考資料。幾個月後，memory 膨脹到 5,000 tokens 以上。每次對話還沒開始，AI 就先讀了一大堆跟當下任務無關的東西。其中 80% 根本用不到，但你每一次對話都在為它付費。

後來我們發現：把工作流程搬到 skill 裡，memory 只留一行「要寫文章的時候用這個 skill」，token 馬上降了 35%。Skill 只有在你需要的時候才會被載入，平常不佔空間。

👥 問題二：你辛苦調教好的 AI，換同事來用就像回到原點

你花了好幾個小時訓練 AI 理解你的寫作風格、你的合規要求、你的工作流程。然後同事打開他自己的 Claude，什麼都沒有。他的 AI 不知道我們用 AIA 格式、不知道數據要有來源、不知道我們有一個 /security-check 要跑。他又要花幾個小時重新教。

我們把完整的工作流程寫成 skill，放在 Git repo 裡。同事 clone 下來，打開 Claude Code，AI 自動讀到 CLAUDE.md 和所有 skill——不用教，不用設定，直接能用。

🔍 問題三：記不住那些指令

要用這些 skill，你得記住特定的指令（像是 /aia-rewrite 或 /publish-article）。時間一久，或是換個人來用，根本不會記得有哪些工具可以用。我們的解法是在 CLAUDE.md 裡加了一張「意圖偵測表」——AI 會分析你說的話，主動建議你該用哪個 skill。你只要用中文說「我想寫一篇文章」，AI 就自動建議用寫作工具。不用背指令。

這三個問題，我們用一套三層架構解決了。但先不急著看架構——讓你先看看這套系統實際跑起來是什麼樣子。

實際案例：AIA 防火門課程改寫

用一句話，派出一整個 AI 團隊幫你工作。這不是概念，是我們每天在做的事。

場景：設計師在 Storyboard Wall 上編輯了 4 張便利貼，留下修改意見。然後說了一句話：「我改好了，幫我重寫」。

接下來發生了什麼？

方向設定好了。接下來，看團隊怎麼運作：

A君 把方向種子發給每一個 agent，然後按照三個階段派出團隊。每個階段裡面的 agent 都是同時工作，不用互相等。

這整套工作流程定義在一個 Skill 檔案裡。它不佔用你的 memory token——只有你需要的時候，才會被載入。

教學：怎麼在你的專案裡設定 AI 團隊

不需要記指令。Intent detection table 讓你用自然語言說話，Claude 自動判斷要叫哪個 agent。下面是三個真實對話範例。

大幅降低 Token 使用的方法：三層架構

想像你每天上班的辦公室：

• 桌上的便條紙（CLAUDE.md）— 每天都看，最核心的幾件事。
• 抽屜裡的索引卡（MEMORY.md）— 不是每天用，但你知道「要寫文章就找那張卡」。
• 後面的資料室（Skills）— 完整的手冊和參考資料，只有真正需要的時候才去拿。

核心洞見：不是所有 context 都需要隨時載入。把「永遠相關」和「偶爾相關」分開，讓 AI 在需要時才按需載入後者。

第一層：CLAUDE.md（永遠載入）

這是 AI 的「入職指南」。任何人在專案目錄開啟 Claude Code，AI 都會自動讀取這個檔案。它是你的團隊與 AI 之間的約定。

CLAUDE.md 裡放的是最核心的兩件事：

• 意圖偵測表——AI 看到你說什麼話，就知道該用哪個 skill（下面會詳細講）
• 基本規則——語言設定、內容放哪裡、部署流程等，讓 AI 不用每次重新學

其他所有東西（詳細工作流程、參考資料、個人偏好）都不放這裡——放到 Skill 或 Memory 裡，需要時才載入。

Intent Detection Table——最關鍵的創新

不要要求使用者背記 slash command，直接在 CLAUDE.md 裡寫一張「行為對應 skill」的對照表：

## Behavior Rules — Proactive Skill Suggestion

Do NOT wait for slash commands. Detect user intent:
- Clear intent → auto-use the skill
- Ambiguous intent → suggest the skill

| When the user...                    | Auto-suggest or use...  |
|-------------------------------------|------------------------|
| Discusses writing an article        | /publish-article       |
| Mentions deploying or uploading     | /upload                |
| Says "done" or "finished editing"   | /upload                |
| Reviews content for accuracy        | /content-review        |
| Is about to git push                | /security-check        |

AI 讀了這張表，就會主動建議正確的 skill，不需要任何記憶。這個改變消除了大約 90% 的「我不知道有這個功能」的 onboarding 摩擦。

第二層：Memory（精簡索引）

目標：所有 memory 檔案加起來不超過 4,000 tokens。

Memory 只應該包含四種資訊：

1. 行為規則——每條 3-5 行。AI 應該如何配合你工作。
2. Skill 指標——每個一行。「遇到 X 情況，用 /skill-y」。
3. 設計偏好——簡短。UI 風格、程式碼慣例。
4. 專案索引——連結到詳細檔案，不是詳細內容本身。

# Memory Index

## Behavior Rules
- [feedback_workflow.md](feedback_workflow.md) — Plan before coding, never jump straight to implementation
- [feedback_delegate.md](feedback_delegate.md) — Use sub-agents for execution, don't code directly

## Skill Pointers
- Writing articles → /publish-article
- Deploying → /upload
- Security scan → /security-check (mandatory before every push)

## Preferences
- [feedback_ui_style.md](feedback_ui_style.md) — Large fonts (16-20px), spacious layout

## Active Projects
- [projects_active.md](projects_active.md) — Links to 3 currently active projects

第三層：Skills（由 CLAUDE.md 觸發載入）

Skill 裡面放的是完整的工作流程——可以很長、很詳細，因為平常不會被載入。只有當 CLAUDE.md 的意圖偵測判斷「現在需要這個 skill」時，才會讀進來。

.claude/skills/
├── CATALOG.md              ← All skills overview (human + AI readable)
├── publish-article/
│   ├── SKILL.md            ← Trigger conditions + operation manual
│   └── references/         ← Detailed docs, loaded when needed
├── security-check/
│   └── SKILL.md
├── aia-rewrite/
│   ├── SKILL.md
│   └── references/
│       ├── writing-guide.md
│       └── aia-standards.md

每個 SKILL.md 的 frontmatter 告訴 AI 什麼時候要載入它：

---
name: publish-article
description: Generate blog articles for watersonusa.ai. Use when the user
  says "write article", "generate content", "新文章", or discusses
  creating content for the website.
---

進階技巧一：混合不同 AI 來協作，大幅降低成本

不是所有工作都需要用最貴的 AI。不同的 AI 擅長不同的事，混著用可以省很多錢：

實際成本比較（一篇 3,000 字技術文章）：

混合架構：Opus 只做最終決策（約 10%），Sonnet 做寫作審查（約 50%），Gemini 免費做調查搜尋（約 40%）。

進階技巧二：怎麼調整你的 AI 團隊

團隊建好之後，你不需要懂技術就能調整它。所有的調整都是用講的——跟總指揮（A君）說就好。

想改？直接跟 A君 說：

進階技巧三：用 OGSM 讓團隊有方向感和執行力

用過「方向種子」之後，你會發現下一個問題：起始對齊做到了，但執行過程中怎麼確保大家還在軌道上？12 個 agent 各做各的，誰來確認它們真的把事情做對？

這就是「部署完成」和「目標真正達成」之間的差距。我們用 OGSM 框架填補這個缺口。

黃金法則：每個 G 讀起來都要能感受到目標對象

這是 OGSM 最常被誤用的地方。很多人把 G 寫成任務清單，或把 S 寫成通用方法——導致 15 個 agent 各做各的，沒有人在意建築師到底學到了什麼。

M 層：三個不生產內容的監控 Agent

傳統 AI 團隊只問「做完了嗎？」OGSM 還要問「做好了嗎？」和「讀者學會了嗎？」這三個角色專門負責回答這兩個問題。

最重要的升級：加入外部 Reviewer

5 個內部審查員不夠。當所有 reviewer 都是公司內部角色，就會出現 confirmation bias——大家互相給滿分，沒人真正站在建築師的立場檢驗。

實際案例：AIA 建築師課程 HSW-002

我們在製作「Spring Hinge vs Self-Closing Hinge」這門建築師進修課程時，用了完整的 OGSM v2 工作計畫（18 個角色，其中 3 個外部 reviewer）：

5 個常見反模式

知道什麼是對的不夠，還要能辨識什麼是錯的。以下是 OGSM 最常出現的問題：

與業界最佳實踐的對照

我們的三層架構與 2025-2026 年最新的 AI agent memory 管理模式高度吻合。以下是我們做的事情對應到研究者和從業者使用的術語：

我們已經在做的

接下來可以加的

常見問題