如何組建有效率的 AI Agent 團隊
我們如何整理 memory、skills 和專案指令,讓 token 消耗減少 35%,新成員加入不需要任何教學。
重點一覽
| 問題 | Memory 檔案無限成長、context window 浪費、無法與隊友共享 AI 設定 |
|---|---|
| 解法 | 三層架構:CLAUDE.md + 精簡 MEMORY.md + 按需載入的 Skills |
| 成果 | token 消耗減少約 35%、新成員零教學 onboarding、25 個以上可重用 skills |
| 適用範圍 | 主要針對 Claude Code,但概念適用於任何 AI coding agent |
| 模板 | 下載 .md 框架模板 |
如果你用過 AI 寫文章,你大概有過這種感受
每次打開新的對話視窗,都要花幾分鐘重新解釋背景——「我們是做建築五金的」、「語氣要專業」、「數據一定要有引用來源」。你把 AI 調教好了,但換個人來用,又回到原點。
更麻煩的是:隨著你越來越依賴 AI,你塞進去的設定越來越多。某天你發現,還沒開始工作,AI 就已經讀了 5,000 tokens 的背景資料——大部分跟今天的任務完全無關,但你一直在為它付錢。
某天我們在想:如果十個 AI 同時幫忙,而且每個都知道自己的角色、不需要重複教學,那會怎樣?這篇文章就是那個問題的答案。
先認識你的 AI 總指揮
我叫它「A君」——你也可以幫它取任何你喜歡的名字。
A君 不是普通的聊天 AI。它是一個指揮官——它理解你團隊的慣例、記住你過去做過的決定、知道要派誰去做哪件事。
你只跟 A君 說話。你告訴它你想做什麼,它負責理解需求、安排團隊、分配工作、整合結果。你不需要直接跟 12 個 agent 溝通。
就像你跟一位很熟悉公司流程的專案經理合作——你說需求,它去協調團隊交付成果。而且明天開一個新對話,它還是知道所有背景。
為什麼要用團隊,不是一個 AI 就好?
一個 AI 一次只能做一件事。它寫稿的時候不能同時查資料,校對的時候不能同時審法規。你等它做完一步,再給下一步,一篇 60 頁的課程要來回幾十次。
AI 團隊不一樣。 5 個 agent 同時研究、寫稿、設計互動,完成後另外 5 個 agent 同時審查文法、法規、引用來源、AIA 合規、敘事邏輯。原本要 3 小時的工作,15 分鐘做完。
而且每個 agent 有自己的專長。寫作的不用懂法規驗證,校對的不用懂 SEO。就像真正的團隊一樣——專業分工,並行處理。
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 張便利貼,留下修改意見。然後說了一句話:「我改好了,幫我重寫」。
接下來發生了什麼?
🎯 第零步:設定方向種子
12 個 AI 同時工作,最怕的是什麼?每個人跑不同方向。
所以在派出團隊之前,總指揮會先設定一個「方向種子」——一段簡短的任務描述,確保所有 agent 瞄準同一個目標:
「這是建築師取得 AIA 學分的教育課程。
語氣要專業但不枯燥。所有數據都要有引用來源——即使不放在投影片上,講稿裡也一定要標明出處。
不能有產品推銷的內容出現在文章裡面。」
每一個 agent——不管是調查員、寫手、還是審查員——都會收到這段方向種子。這確保 12 個人寫出來的東西風格一致、目標一致、品質標準一致。
方向設定好了。接下來,看團隊怎麼運作:
A君 把方向種子發給每一個 agent,然後按照三個階段派出團隊。每個階段裡面的 agent 都是同時工作,不用互相等。
五個 AI 同時開工
你給了指令,這五個角色立刻同時啟動:
⏱ 五個角色同時完成,大約 3-5 分鐘
另外五個 AI 同時檢查品質
初稿完成後,馬上交給五個審查員——也是同時跑:
⏱ 五個審查員同時完成,大約 2-3 分鐘
組裝完成,一鍵上線
從你說「開始」到文章上線:大約 10 分鐘
12 個 AI 並行處理,品質經過五層獨立審查,自動部署。
這整套工作流程定義在一個 Skill 檔案裡。它不佔用你的 memory token——只有你需要的時候,才會被載入。
想直接用在自己的專案裡?Fork 我們的 Starter Kit,開 Claude Code 就能開始。
Fork Starter Kit →教學:怎麼在你的專案裡設定 AI 團隊
不需要記指令。Intent detection table 讓你用自然語言說話,Claude 自動判斷要叫哪個 agent。下面是三個真實對話範例。
範例 1 — 寫一篇新文章
/publish-article。讓我先查 content-plan.md...找到了 CS-6「Pool Gate Code Framework: ISPSC vs. IBC vs. IRC」,內容計劃已有這個主題。範圍是住宅還是商業設施?
✅ Gemini Flash — 研究最新州立法規差異
✅ Sonnet — 寫英文主版本
✅ Sonnet — 寫中文版
✅ Sonnet — 寫 Web AEO 版(FAQ schema)
三版文章已產生。要
/upload 部署嗎?範例 2 — 改寫 AIA 課程
派出 12 角色 agent:
🔍 × 2 研究中... ✍️ × 2 寫稿中... 📋 × 5 審查中... 💻 × 1 整合中...
(約 3 分鐘後)
全部完成。共修改 Slide 11, 12, 13, 20, 21。要部署嗎?
/upload → push to GitHub → Vercel 部署中... 約 1 分鐘後上線 ✅範例 3 — 日常一句話指令
/aia-rewrite 裡的 Fact Verification 角色)派出 Gemini Flash 逐項核實...
找到 2 個問題:
1. ISPSC 305.2.5 → 應為 ISPSC 305.3.3
2. NFPA 80 引用 2022 版 → 2025 版已於今年 1 月發布
要我直接修正嗎?
/upload → 上線 ✅/aia-rewrite 這個指令的存在。Intent detection table 讓 Claude 在你用自然語言說話的時候,自動選擇正確的工具。這就是三層架構的核心價值——skill 的複雜度對使用者透明。
大幅降低 Token 使用的方法:三層架構
想像你每天上班的辦公室:
- 桌上的便條紙(CLAUDE.md)— 每天都看,最核心的幾件事。
- 抽屜裡的索引卡(MEMORY.md)— 不是每天用,但你知道「要寫文章就找那張卡」。
- 後面的資料室(Skills)— 完整的手冊和參考資料,只有真正需要的時候才去拿。
第二層:Memory(MEMORY.md) → 精簡索引,只放指標(約 200 tokens)
第三層:Skills(SKILL.md) → 完整手冊,只有被觸發時才載入
核心洞見:不是所有 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 只應該包含四種資訊:
- 行為規則——每條 3-5 行。AI 應該如何配合你工作。
- Skill 指標——每個一行。「遇到 X 情況,用 /skill-y」。
- 設計偏好——簡短。UI 風格、程式碼慣例。
- 專案索引——連結到詳細檔案,不是詳細內容本身。
# 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
skill/references/,只有該 skill 被觸發時才載入。
第三層: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 字技術文章):
| 做法 | 估算成本 | 時間 |
|---|---|---|
| 全程使用 Claude Opus | $3 – $5 | 60-90 分鐘 |
| 全程使用 Claude Sonnet | $0.8 – $1.2 | 30-45 分鐘 |
| 混合架構(本文方法) | $0.40 – $0.55 | 10-15 分鐘 |
混合架構:Opus 只做最終決策(約 10%),Sonnet 做寫作審查(約 50%),Gemini 免費做調查搜尋(約 40%)。
省錢原則:免費的先用完
Gemini 每天免費 1,000 次——調查、校對、搜尋都丟給它。Codex 月費 $20 包到底——程式碼的事交給它。Claude 只做需要高品質判斷的核心工作。這樣每個月的 AI 開銷可以控制在很合理的範圍。
進階技巧二:怎麼調整你的 AI 團隊
團隊建好之後,你不需要懂技術就能調整它。所有的調整都是用講的——跟總指揮(A君)說就好。
你的 AI 團隊目前長這樣:
想改?直接跟 A君 說:
改現有角色的行為
「我覺得寫手的語氣太嚴肅了,可以幽默一點嗎?」
→ A君 會更新寫手的設定,下次派出去就會用新的語氣。
加一個新角色
「我需要一個專門做 SEO 優化的 agent」
→ A君 不會直接建角色。它會先問你幾個問題:
「好的。讓我確認一下這個 SEO agent 的範圍:
• 它主要負責關鍵字研究、meta tags 優化、還是內容結構調整?還是全部?
• 它需要跟寫手協作嗎?還是獨立作業?
• 你希望它用什麼工具查資料?Gemini 搜尋?還是你有特定的 SEO 工具?
• 產出格式是什麼?一份建議清單?還是直接改文章?」
→ 你回答完之後,A君 才會建立這個角色,確保它做的事情跟你想的一樣。
看目前的團隊設定
「列出目前所有的 agent 和它們負責的事」
→ A君 會列出完整的團隊名單和每個人的角色。
你不需要懂技術。 方向設定、角色分配、品質控制——這些都是 A君 的工作。你只要告訴它你想要什麼結果,它會自己安排團隊去完成。
使用時要注意的事
指令要講清楚。「幫我寫一篇文章」比「幫我做點什麼」好一百倍。AI 不會讀心,你講得越具體,結果越好。
結果一定要檢查。AI 團隊會幫你做到 90%,但最後的 10% 還是你的專業判斷。特別是數字和法規引用,永遠自己再看一遍。
不滿意就說。跟 A君 說「這段語氣不對」或「這個案例換一個」,它會馬上派團隊重做。不要將就。
機密資料不要丟進去。API 金鑰、密碼、客戶個資——這些絕對不要放在任何檔案裡。AI 在 push 前會做安全掃描,但預防永遠比補救好。
與業界最佳實踐的對照
我們的三層架構與 2025-2026 年最新的 AI agent memory 管理模式高度吻合。以下是我們做的事情對應到研究者和從業者使用的術語:
我們已經在做的
| 技術 | 業界術語 | 我們的實作 |
|---|---|---|
| 三層分離 | Memory Tiering | CLAUDE.md + MEMORY.md + Skills |
| 索引指標 | Pointer Index System | MEMORY.md 只放一行指標 |
| 按需載入 | Progressive Disclosure / Selective Re-injection | Skills 只有被觸發時才載入 |
| 子 agent 摘要 | Sub-agent Distillation | 12 個角色 agent 向 orchestrator 回報摘要 |
| 透過 repo 共享設定 | Shared Project Config | CLAUDE.md + Skills 放在 GitHub |
| 行為觸發 | Intent Detection | CLAUDE.md 的行為對應 skill 對照表 |
接下來可以加的
| 技術 | 做什麼 | 如何實作 |
|---|---|---|
| AutoCompact | context 使用到約 92% 時自動壓縮對話 | 在 CLAUDE.md 加上:「在長對話中,主動摘要已完成的任務」 |
| AutoDream | 背景 agent 自動整理 memory(合併重複、清除過時) | 建立一個 /memory-cleanup skill 定期執行 |
| Memory Decay | 舊 memory 自動過期 | 在 memory 檔案加上日期,超過 90 天就標記為待審查 |
| MCP Integration | 從 GitHub Issues、Slack、Jira 拉取 context | 我們已經用 Supabase 做 storyboard 同步——延伸這個模式 |
| Small Model Filter | 輕量模型預先過濾 memory 相關性 | 用 Haiku 在注入 context 前評分 memory 的相關程度 |
常見問題
這套方法只能用在 Claude Code 嗎?
CLAUDE.md 機制是 Claude Code 獨有的。但背後的原則——精簡的永遠載入 context、按需載入的詳細文件、基於 intent 的觸發——適用於任何 AI agent 系統。你可以用 Cursor 的 rules 檔案、GitHub Copilot workspace 設定,或是自訂 system prompt 實現同樣的結構。
怎麼判斷某個東西應該放在 skill 還是留在 memory?
用這個過濾條件:如果你會把它放在交給新員工第一天就看的文件裡,它就屬於 skill。如果你會在 10 秒的口頭交接裡說它,它就屬於 memory。步驟流程、參考資料、多步驟工作流程,以及任何超過五行的東西,幾乎都應該是 skill。
Skill 變得很大怎麼辦?
這很正常,也完全沒問題。Skills 可以有 references/ 子目錄,放任意多的檔案。Skill 的 SKILL.md 扮演目錄的角色——它指定在哪些子任務中要載入哪些參考檔案。一個複雜的發布工作流程 skill 可能有 10 個參考檔案加起來好幾千行,但只有你真的在發布的時候,這些重量才會出現在你的 context 裡。
多個專案共用的 skills 怎麼處理?
Claude Code 支援兩個 skills 位置:專案層級(repo 裡的 .claude/skills/,透過 git 共享)和使用者層級(你機器上的 ~/.claude/skills/,私人的)。通用工具型的 skills,例如安全掃描或 git 操作,放在使用者層級。專案特定的 skills,例如課程改寫或文章發布,放在專案層級。
這套 AI 團隊架構怎麼維護?會不會越來越亂?
維護的關鍵是定期執行「memory 清理」——每隔一到兩個月,檢查 MEMORY.md 有沒有過時的索引,把長度超過五行的規則搬到 skill 裡。可以建立一個 /memory-cleanup skill 讓 AI 幫你做這件事。Skill 本身只要在工作流程改變時更新就好,不需要頻繁維護。
團隊多人協作時,每個人的 AI 設定要怎麼同步?
把 CLAUDE.md 和 .claude/skills/ 放進 Git repo,所有人 clone 下來就自動取得相同的設定。個人的喜好(例如語氣偏好、常用快捷鍵)放在本機的 ~/.claude/ 目錄,不 commit 進 repo。這樣團隊共享的工作流程統一,個人設定各自保留。
準備好了嗎?從最簡單的地方開始。
不用一次把所有東西搬過去。先把 CLAUDE.md 設定好,加一張意圖偵測表——這一步就能消除 90% 的指令記憶問題。其他的可以慢慢來。