Agency-Agents：147 個 Claude Code sub-agent 模板集

過去半年我把 Claude Code 跟 Cursor 拿來當主力寫程式工具，越用越發現一件事：通用 prompt 雖然能解決八成問題，但碰到專業領域（PPC 投放策略、Reddit 社群行銷、Vision Pro 互動設計、無障礙稽核）就明顯掉漆。原因不在模型不夠強，而在「我不知道該用什麼語氣、什麼框架、什麼產出格式去問」。

最近翻 GitHub 找到 msitarzewski 的 agency-agents，第一眼覺得是又一個 prompt 集合，看完後發現它把這件事系統化了 ── 144 個帶人格、帶流程、帶可量測產出的 agent，分 12 個部門，等於是把一整間數位代理商（agency）的角色直接塞進你的編輯器。

這篇紀錄是這幾天把它跑進 Claude Code、Cursor、GitHub Copilot 三套工具的整理筆記，順便跟 awesome-agents、wshobson/agents 這幾個常見的 agent 集合做個對照，看看它的設計哲學到底贏在哪、又該怎麼避免「147 個 agent 反而不知道該叫誰」這個典型陷阱。

一、Agency-Agents 是什麼

Agency-Agents（作者 msitarzewski）的標語很直接 ── A complete AI agency at your fingertips。它不是一個 runtime、也不是一套 framework，本質上就是 144 個 Markdown 檔案，每一個檔案描述一位「員工」的人格設定、工作流程、產出格式，總計超過 10,000 行 prompt。

採 MIT 授權，倉庫已被多家工作室拿去當作內部 prompt 標準的起點。專案維護方式也很 agency 風格 ── 每個部門有自己的子目錄，新增 agent 用 PR 提交，社群討論在 GitHub Discussions 跟 Reddit 上跑。

1.1 核心特徵與規模

從 README 與 repo 結構統計：

• 144 個專業化 agent（README 自述為「The Agency」，內部分類加總 144，部分文件提到擴張中）
• 12 個部門：Engineering、Design、Paid Media、Sales、Marketing、Product、Project Management、Testing、Support、Spatial Computing、Specialized、Game Development（另含 Finance、Academic 等延伸）
• 10,000+ 行人格與流程定義
• 多 IDE 原生支援：Claude Code、GitHub Copilot 直接吃 .md，Cursor 自動轉 .mdc，Gemini CLI、Aider、Windsurf、OpenCode、Kimi Code 都有對應安裝腳本

1.2 12 個部門編制

部門劃分大致對應一間真實 digital agency 的組織圖：

每個 agent 不只是 prompt 模板，README 強調 deep specialization with personality and process ── 也就是「人格 + 工作流程 + 期待產出」三件事必須同時定義。

1.3 跟其他 agent collection 的差別

把 agency-agents 拿去跟其他常見集合比，差異很清楚。

kyrolabs/awesome-agents 是一份「awesome list」，列的是 LangChain、AutoGen、CrewAI、MetaGPT、OpenHands 這類 agent 框架，是給你選工具用的。agency-agents 則完全相反 ── 它不挑工具，假設你已經有 Claude Code 或 Copilot，提供的是內容（人格與流程）。

wshobson/agents 跟 awesome-claude-code 這類集合則更接近 agency-agents 的形態，但 agency-agents 在「組織模型」上做得更深 ── 它用「部門 / 員工」這個比喻把 144 個 agent 收編進清楚的責任邊界，而不只是按能力分類。

二、agent 設計哲學

agency-agents 的真正亮點是 prompt 結構，不是數量。

2.1 為什麼要分部門

直觀來說，144 個 agent 用「能力」分類更精準（前端、後端、SQL、testing、SEO、ads…）。但實務上發現一個問題 ── 當你坐在編輯器前，腦袋裡浮現的不是「我需要前端能力」，而是「我需要一個 frontend developer 幫我看這份 PR」。

部門制是把索引切換成「誰負責」而不是「能力是什麼」，跟人腦的工作分配模式一致。我寫 PR description 的時候會直接想「這應該是 reality-checker 的工作」，而不是「我需要 quality-assurance + production-readiness 兩個能力交集」。

這個切法的代價是某些 agent 跨部門 ── 例如 a11y-auditor 同時屬於 Testing 跟 Design。repo 採用「主歸屬 + 交叉引用」處理，但實作上你會看到部分檔案在多個目錄都有 symlink。

2.2 三件事缺一不可：人格、流程、產出

挑一個常用的 frontend-wizard.md 看，內部結構大致是：

# Frontend Wizard

## Personality
You are a senior frontend engineer who values shipping over perfection.
You write React/Vue/Angular with the same fluency...

## Process
1. Inspect the current component tree...
2. Identify state management boundaries...
3. Propose a minimal diff...

## Deliverables
- Updated component file(s)
- Storybook stories for new variants
- Migration notes if breaking change

## Anti-Patterns
- Don't introduce new dependencies without justification
- Don't refactor unrelated code...

三段式結構（Personality / Process / Deliverables）是整個 repo 的共同 schema。這比單純寫 system prompt 強很多 ── Personality 控制語氣、Process 控制節奏、Deliverables 控制可驗收條件，三者交集才能避免 LLM 自由發揮跑偏。

2.3 真正常用的 4 個 agent

144 個 agent 看起來嚇人，但實測下來 80% 流量集中在十幾個 agent 上。我自己最常觸發的 4 個：

• frontend-wizard ── 寫 React 元件、看現有元件 refactor 提案，產出附 Storybook story
• reality-checker ── PR 上線前的 quality gate，會強制問「rollback 怎麼做」「怎麼驗證」「edge case 有哪些」
• reddit-ninja ── 寫 Reddit 推廣文案，會避開明顯廣告語氣，按各 subreddit 文化調整
• whimsy-injector ── 微互動跟品牌口吻，在 landing page、UI copy、error message 加少量「人味」

reality-checker 跟 whimsy-injector 是我覺得最有趣的設計 ── 它們不是新能力，而是把「上線前的常識」跟「品牌一致性」這兩件容易被忽略的事制度化成 agent。

三、安裝與在三套 IDE 跑起來

agency-agents 的安裝是「同一份來源、各 IDE 自己渲染」。

3.1 兩個關鍵腳本

git clone https://github.com/msitarzewski/agency-agents.git
cd agency-agents

# 互動式安裝，會自動偵測你裝了哪些 IDE
./scripts/install.sh

# 指定單一工具
./scripts/install.sh --tool claude-code

# 先轉換格式（給 Cursor 用 .mdc，給 Gemini CLI 用 extension 格式）
./scripts/convert.sh

install.sh 把 144 個 .md 複製到對應的目錄。

• Claude Code：~/.claude/agents/（每個 .md 變一個 sub-agent，frontmatter 裡 description 欄位給 router 比對）
• GitHub Copilot：原生吃 .md，作為 chat context 載入
• Cursor：convert.sh 會把每個 .md 轉成 .mdc 規則檔放進 .cursor/rules/
• Gemini CLI：包成 extension，用 gemini extension install 載入

3.2 Claude Code 的觸發機制

Claude Code 的 sub-agent router 看 frontmatter 的 description：

---
name: frontend-wizard
description: |
  Use when the user asks for React/Vue/Angular component design,
  refactoring suggestions, or storybook story generation.
tools: [Read, Write, Edit, Bash]
---

所以實務上 agency-agents 的 144 個 .md 不會全部「常駐」消耗 context。Claude Code 的 router 會在 user prompt 進來時做一次 description matching，命中後才把對應的 agent 內容載入。從 token 角度看比想像中省很多。

3.3 三家 IDE 的差別

實測下來：

• Claude Code 體驗最好 ── sub-agent 模型 + 自動 routing，我幾乎不用記 agent 名字
• Cursor 中規中矩 ── .mdc 規則需要使用者用 @ 手動觸發，不像 Claude Code 那樣自動
• GitHub Copilot 最弱 ── 只能用「載入 chat context」的方式，無法做 routing，反而需要手動貼 prompt

四、實測：寫一個 PR description

最有感的對比是這個情境 ── 純 Claude Code vs reality-checker agent 啟動後寫 PR description。

4.1 純 Claude 版本

我給的 prompt：「幫我把這 5 個 commit 寫成 PR description。」純 Claude 給的東西很標準 ── Summary、Changes、Test plan，三段式，沒問題但也沒驚喜。常會漏掉「rollback strategy」、「performance impact」、「security considerations」這些上線前該想的欄位。

4.2 reality-checker 版本

同樣的 5 個 commit，叫 reality-checker 處理，產出多了：

• Risk assessment（這個 PR 改了 auth middleware，列出三個潛在 regression 場景）
• Rollback plan（具體說明 git revert 的順序，跟 DB migration 是不是 reversible）
• Verification checklist（手動測 / 自動測 / staging soak time）
• Edge cases that must be tested（user with empty session、concurrent login、token expired mid-request）

這四個欄位純 Claude 不是不會，是「不會主動想到」。reality-checker 的 Process 段落把它們列為強制步驟，agent 就會逼自己跑完。對 PR review 流程的提速很明顯。

五、風險與真實限制

當然不是無腦讚美。實戰下來有三個明顯坑要注意。

5.1 「147 個」太多會搞死選擇焦慮

repo 文件吹捧 144（部分宣傳資料寫到 147，含後續 PR）個 agent 是賣點，但對使用者是反作用力 ── 我第一週裝完打開 Claude Code 反而手足無措，不知道該叫誰。

我的解法是寫一個 wrapper sub-agent 叫 triage：先收 user prompt，分析後決定要 route 到哪個 specialized agent，再呼叫之。這跟 multi-agent framework 的 supervisor pattern 是同樣概念，但用 Claude Code 的 sub-agent 機制就能做到，不需要外掛 framework。

5.2 人格設定有時候蓋掉指令

whimsy-injector 那種強人格 agent 偶爾會「太愛玩」── 你只是想讓 error message 講人話，它給你寫了帶 emoji 跟雙關語的版本。需要在 user prompt 加「保持中性語氣，避免 emoji」這類 anti-injection 指令。

這個問題反映出 agency-agents 的設計取捨 ── 它選擇強人格是因為有人格才有一致風格，但代價是你得學會 override。

5.3 部門間有重複跟矛盾

Engineering 部門的 security-engineer 跟 Specialized 部門的 pentester 在威脅建模這件事上有 60% 重疊；Marketing 的 growth-hacker 跟 Sales 的 outbound-strategist 在「冷信件文案」的 deliverable 也很像。這些重複沒有真的造成錯誤，但會讓你在做 agent governance 的時候很頭痛 ── 同一件事誰負責、版本變更誰追。

對個人使用者問題不大，對團隊把 agency-agents 當共享資產時，需要建立 agent ownership matrix。

六、跟 multi-agent framework 怎麼搭

最常被問到的問題 ── agency-agents 跟 Microsoft AutoGen、CrewAI、LangGraph 是同一類東西嗎？

不是。三個關鍵差異：

• agency-agents 是 prompt 集合，不是 runtime ── 它沒有 task scheduler、沒有 message bus、沒有 retry policy。執行依賴你用的 IDE（Claude Code、Cursor）的 agent runtime
• 它不處理 agent 之間的對話 ── AutoGen / CrewAI 強項是 agent 互相討論收斂，agency-agents 假設你「一次叫一個 agent」，不對話
• 狀態管理交給 IDE ── memory、session 都靠 Claude Code 的 conversation history 跟 Cursor 的 chat history，agency-agents 自己不存

所以實務上的搭配是：用 LangGraph 寫 orchestration，但 prompt 內容從 agency-agents 借過來。這比同時學 framework + prompt engineering 兩件事輕鬆很多。

七、什麼情境最適合用

整理三個適配度高的情境：

1. 單人或小團隊的內容 / 行銷工作 ── 你需要的是「PPC 文案」「SEO outline」「Reddit 貼文」這類非工程任務的 specialized prompt，agency-agents 直接就能用
2. 需要建立內部 prompt 標準的工作室 ── 直接 fork 一份，把不需要的部門刪掉，保留 5-6 個常用 agent 當 baseline，再客製化
3. 想學 agent 設計但不想從零寫 ── 這 144 個 .md 是非常好的範本，看 frontend-wizard / reality-checker 的結構就知道專業 prompt 該怎麼分段

不適合的情境：需要 agent 之間互動、需要 long-horizon workflow（會跨數小時的研究任務）、需要 sandbox 隔離 ── 這些去看 Deer-flow 或 LangGraph 比較對。

把 agency-agents 想成「Claude Code 的人格資料庫」最貼切 ── 它不增加你的能力，但讓你知道每個能力該用什麼語氣、什麼節奏、什麼產出格式去呼叫。對日常工作流程的提速很實在，特別是那些你「知道大概要做什麼但不知道怎麼開頭」的非工程任務。

參考資料

• msitarzewski/agency-agents GitHub
• agency-agents agents 目錄
• kyrolabs/awesome-agents
• Anthropic：Claude Code sub-agents 文件
• Cursor .mdc rules 規格