61 個 Markdown 檔讓你的 IDE 變成 AI 公司：agency-agents 爆紅背後的技術邏輯

一個 GitHub 專案，沒有任何可執行程式碼，只有 61 個 Markdown 檔案，7 天內拿到 10,000 顆星。截至 3/14 已經衝到 39,300 星。

這不是什麼新框架或新語言。agency-agents 做的事情只有一件：用 Markdown 定義 AI 的專業人格。

聽起來荒謬，但它戳中了一個真實的問題。

你的 AI 助手什麼都會，所以什麼都做不好

用過 Claude Code 或 Cursor 的人都有這個經驗：你請 AI 寫一個 REST API，它給你一個「還行」的版本。能跑，但缺少認證考量、沒有速率限制、錯誤處理敷衍、命名風格前後不一。

問題不在模型能力。GPT-5.4、Claude Opus 4.6、Gemini 3.1 Pro——這些模型的知識量早就超過任何單一工程師。問題在於 context window 裡塞了太多可能性，模型不知道你要哪一種。

你問「幫我設計 API」，模型在 REST、GraphQL、gRPC 之間游移。你問「幫我寫測試」，模型不確定你要 unit test 還是 integration test，最後給你一個不痛不癢的折衷。

agency-agents 的解法直覺到令人意外：把模型的注意力鎖定在一個角色上。

一個 Markdown 檔怎麼定義一個「專家」

打開 agency-agents 的任何一個 agent 定義檔，結構大概長這樣：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

# Backend Architect

## Identity
你是一個有 15 年經驗的後端架構師，專精分散式系統和 API 設計。
你對效能有偏執，對過度設計有過敏反應。

## Core Mission
設計可維護、可擴展的後端系統。每個決策都要能回答「為什麼選這個而不是那個」。

## Critical Rules
- 每個 endpoint 必須有認證和速率限制
- 資料庫操作必須考慮 N+1 問題
- 錯誤回傳必須包含 correlation ID
- API 版本控制從第一天就要做

## Success Metrics
- API 回應時間 p99 < 200ms
- 測試覆蓋率 > 80%
- 零個未處理的 error case

沒有程式碼。沒有依賴。沒有 npm install。

但當你把這份檔案載入 Claude Code 作為 agent 定義，模型的行為會出現明顯變化。它不再給你「通用版本」的 API，而是直接帶上認證層、考慮速率限制、主動處理錯誤邊界。

原理很單純：system prompt 越具體，模型的輸出品質越高。這不是什麼新發現。但 agency-agents 把它工程化了。

9 個部門、112 個角色

agency-agents 用企業組織架構的方式分類 agent：

有些角色名稱看起來很搞笑——Whimsy Injector（專門幫產品加入趣味性的 agent）、Reality Checker（專門潑冷水的 agent）。但這恰恰是重點：每個角色都有明確的職責邊界，而不是一個什麼都能做的通用 AI。

跨平台安裝：一份定義，多個 IDE

技術上最聰明的設計是跨平台相容性。同一份 agent 定義可以用在：

• Claude Code：直接放進 ~/.claude/agents/ 目錄
• Cursor：轉換成 .mdc rule 檔案
• Aider：合併成 CONVENTIONS.md
• Windsurf、Gemini CLI、OpenCode：各有對應的安裝腳本

1
2
3

# 自動轉換並安裝到你的 IDE
./scripts/convert.sh
./scripts/install.sh

兩行指令。agent 定義是純 Markdown，轉換腳本負責適配各平台的格式差異。這代表團隊可以版本控制這些 agent 定義，像管理程式碼一樣管理 AI 行為。

多 Agent 協作：同時叫 8 個專家開會

單一 agent 就能提升品質，但真正的殺手功能是 multi-agent orchestration。

專案文件裡有一個叫「Nexus Spatial Discovery Exercise」的範例：同時啟動 8 個 agent——Backend Architect 負責 API 設計、Security Engineer 做威脅建模、QA Engineer 寫測試計畫、Frontend Developer 做 UI 原型——然後把各自的輸出彙整成一份完整的產品評估報告。

這跟傳統的 multi-agent framework（AutoGen、CrewAI、LangGraph）有本質差異。那些框架需要你寫 Python 程式碼來定義 agent 之間的通訊協議和工作流程。agency-agents 不需要——你的 IDE 就是 orchestrator。

在 Claude Code 裡，你可以用 Agent tool 同時啟動多個 subagent，每個載入不同的 persona markdown。不需要額外的框架、不需要 API key 管理、不需要佈署基礎設施。

為什麼純 Markdown 反而是優勢

初看之下「只有 Markdown 沒有程式碼」像是缺陷。但仔細想想，這其實是最佳設計決策：

1. 零依賴——不會因為某個 Python 套件版本衝突而壞掉。不需要 Docker。不需要 GPU。

2. 人類可讀——任何人都能打開一個 agent 定義檔，三分鐘內理解它做什麼、不做什麼。新人 onboarding 的成本趨近於零。

3. 可 diff、可 review——agent 行為的每一次修改都能在 git diff 裡看到。Code review agent 定義跟 review 程式碼一樣自然。

4. 可組合——你可以 fork 一個 agent、調整幾行描述、產生一個完全不同行為的變體。不需要理解任何框架的 API。

5. 模型無關——同一份定義可以餵給 Claude、GPT、Gemini、Llama。切換模型不需要改 agent 定義。

這讓我想到 Linus Torvalds 的觀點：好的抽象應該讓特殊情況消失。agency-agents 把「如何讓 AI 寫出更好的程式碼」這個複雜問題，簡化成「寫一份更好的 Markdown」。

跟 NemoClaw、OpenClaw 形成的生態位

同一週，AI agent 生態出現了三個層次：

• NVIDIA NemoClaw（3/16 GTC 發布）：企業級 AI agent 平台，需要 GPU 叢集、Kubernetes、完整的 MLOps 管線。目標客戶是大公司。
• OpenClaw（210K 星）：個人 AI 助手閘道器，連接 50+ 整合（WhatsApp、Telegram、Slack）。目標用戶是個人。
• agency-agents（39K 星）：開發者工作流 agent，純 Markdown，零基礎設施。目標用戶是寫程式的人。

三個專案解決三個不同的問題，但指向同一個趨勢：AI 從「一個大模型回答所有問題」轉向「多個專業化角色各司其職」。

實際用起來的限制

我認為需要誠實說幾個限制：

context window 消耗——每載入一個 agent 定義，就吃掉一段 context。如果同時跑 8 個 agent，主 session 的可用 context 會被壓縮。在 Claude Code 裡，subagent 有獨立的 context window，問題比較小。但在 Cursor 裡，所有 rules 共享同一個 context。

品質參差不齊——112 個 agent 不可能每個都是精品。Engineering 類的 agent 定義明顯比 Marketing 類的更成熟，可能因為貢獻者大多是工程師。

不是萬能藥——如果你的問題是「模型本身能力不夠」，換一個 persona 不會讓它突然變強。persona 做的是聚焦，不是升級。

團隊協作成本——當團隊開始自訂 agent 定義，你需要一套 review 流程來確保品質。這本身就是一項管理工作。

你可以現在就做的三件事

1. 試一個 Engineering agent——不需要裝整個專案。到 GitHub 上複製 engineering-backend-architect.md 的內容，丟進你的 Claude Code agents 目錄或 Cursor rules，然後用它設計一個 API。跟你平常不帶 persona 的結果比較一下。

2. 寫你自己的 agent——根據你團隊的 coding standards，寫一份 200 行的 Markdown agent 定義。把你們的命名規範、錯誤處理方式、測試策略全部寫進去。這比任何 linter 都有效。

3. 版本控制 agent 定義——開一個 agents/ 目錄放進你的 repo。讓 agent 定義跟著程式碼一起演進。當有人改了 agent 的行為，PR review 自然會 catch 到。

Multi-agent 這條路才剛開始。但 agency-agents 證明了一件事：有時候最有效的工具，不是最複雜的框架，而是一份寫得夠好的文件。