測驗:Agents 特化代理 – 讓 AI 扮演不同角色
共 5 題,點選答案後會立即顯示結果
1. 在 Claude Code 的配置系統中,Agent 和 Command 的核心差異是什麼?
2. Agent 的 Markdown 檔案包含四大核心區塊,下列哪個不屬於這四大區塊?
3. 13 個預設代理被分為四大類,下列哪個代理屬於「品質審查類」?
4. build-error-resolver 代理的核心哲學是什麼?
5. 設計自訂 Agent 時,為什麼「定義代理不做什麼」很重要?
**系列**:Claude Code 進階配置(第 3 篇,共 5 篇)
**難度**:L2-進階
**前置知識**:已讀過第 1-2 篇(了解 Rules 和 Commands)
一句話說明
Agent 是「有角色設定的專業助手」——你可以讓 Claude 變成架構師、資安審查員、或測試教練,每個角色都有自己的專長、檢查清單和輸出格式。
為什麼需要 Agent?
想像你請一個人幫忙蓋房子。你可以:
- 每次給他一個指令:「去釘這根釘子」「去刷那面牆」(這是 Command)
- 告訴他公司規定:「所有電線要走暗管」「牆壁統一白色」(這是 Rule)
- 找一個專業的水電師傅,他知道所有水電規範,你只要說「幫我看看水電」(這是 Agent)
Agent 的價值在於:它帶著完整的角色知識和判斷標準進場,而不是每次都從零開始。
Rule、Command、Agent 三角關係
這三個東西各司其職,一起構成 Claude Code 的配置系統:
┌─────────────────────────────────────────────────┐
│ Claude Code │
│ │
│ Rule(規則) 永遠生效的行為約束 │
│ ├─ 「所有回覆用繁體中文」 │
│ └─ 「不要刪除 .env 檔案」 │
│ │
│ Command(指令) 一次性觸發的快捷操作 │
│ ├─ /plan → 產出一份計畫 │
│ └─ /test → 跑一次測試 │
│ │
│ Agent(代理) 有角色設定的持續性助手 │
│ ├─ architect → 軟體架構師,有設計原則 │
│ ├─ code-reviewer → 程式碼審查員,有檢查清單 │
│ └─ security-reviewer → 資安審查員,有 OWASP │
│ │
└─────────────────────────────────────────────────┘
用一張對照表讓它更清楚:
| 面向 | Rule | Command | Agent |
|---|---|---|---|
| 存在形式 | .claude/rules/ 裡的 .md |
.claude/commands/ 裡的 .md |
.claude/agents/ 裡的 .md |
| 觸發方式 | 自動套用,永遠生效 | 使用者主動輸入 /指令 |
使用者指定或 Claude 自動委派 |
| 持續性 | 全程有效 | 執行一次就結束 | 保持角色直到任務完成 |
| 有沒有「角色」 | 沒有,只是約束 | 沒有,只是腳本 | 有,有完整的人設和專長 |
| 白話比喻 | 公司規定 | 一次性的指令 | 請來的專業顧問 |
關鍵區分:Command 說「做什麼」,Agent 知道「怎麼做」還知道「為什麼這樣做」。
Agent 放在哪?檔案結構一秒看懂
你的專案/
└── .claude/
├── rules/ ← Rule 住這裡
│ └── style.md
├── commands/ ← Command 住這裡
│ └── plan.md
└── agents/ ← Agent 住這裡(今天的主角)
├── architect.md
├── code-reviewer.md
├── security-reviewer.md
└── ...(更多代理)
每個 .md 檔案就是一個代理的「角色說明書」。Claude 讀到這個檔案,就會進入對應的角色模式。
13 個預設代理總覽
社群專案 everything-claude-code 提供了 13 個精心設計的代理模板。我把它們分成四大類:
架構規劃類
| 代理 | 一句話說明 | 什麼時候用 |
|---|---|---|
| architect | 軟體架構師,做系統設計決策 | 開新功能、大規模重構、技術選型 |
| planner | 規劃專家,拆解複雜任務 | 功能實作前的計畫制定 |
品質審查類
| 代理 | 一句話說明 | 什麼時候用 |
|---|---|---|
| code-reviewer | 通用程式碼審查員 | 程式碼合併前的品質檢查 |
| security-reviewer | 資安漏洞偵測專家 | 涉及認證、API、使用者輸入時 |
| python-reviewer | Python 專業審查員 | Python 專案的程式碼審查 |
| go-reviewer | Go 專業審查員 | Go 專案的程式碼審查 |
| database-reviewer | 資料庫專家 | SQL 查詢、Schema 設計、RLS 政策 |
開發實作類
| 代理 | 一句話說明 | 什麼時候用 |
|---|---|---|
| tdd-guide | 測試驅動開發教練 | 要求先寫測試再寫實作 |
| refactor-cleaner | 死碼清除專家 | 清理未使用的程式碼和依賴 |
維運工具類
| 代理 | 一句話說明 | 什麼時候用 |
|---|---|---|
| doc-updater | 文件更新專家 | 程式碼改了但文件沒跟上 |
| e2e-runner | 端對端測試專家 | 建立和維護 E2E 測試 |
| build-error-resolver | 建置錯誤修復專家 | TypeScript 編譯失敗、依賴問題 |
| go-build-resolver | Go 建置錯誤修復專家 | Go 編譯失敗、套件問題 |
Agent Markdown 的四大結構
打開任何一個代理的 .md 檔案,你會看到四個核心區塊。這就是代理的「角色說明書」格式:
# 角色名稱(Role Definition)
# ──────────────────────────
# 你是誰、你的專長是什麼
You are a senior software architect specializing in
scalable, maintainable system design.
# 能力範圍(Capability Scope)
# ──────────────────────────
# 你能用什麼工具、負責什麼事
## Tools Available
- Read, Grep, Glob (for code analysis)
## Primary Responsibilities
- New feature planning and system architecture
- Large-scale refactoring initiatives
# 行為約束(Behavior Constraints)
# ──────────────────────────
# 什麼該做、什麼不該做
## Principles
- Always consider scalability
- Never modify production code directly
# 輸出格式(Output Format)
# ──────────────────────────
# 回覆要長什麼樣子
## Report Structure
1. Current State Assessment
2. Requirements Analysis
3. Design Proposal
4. Trade-off Documentation
Code language: PHP (php)用白話來說:
| 區塊 | 白話解釋 | 為什麼需要 |
|---|---|---|
| 角色定義 | 「你是資深架構師」 | 讓 AI 進入角色,影響回答風格和深度 |
| 能力範圍 | 「你可以讀檔案、搜尋程式碼」 | 限制 AI 能做什麼,避免越權 |
| 行為約束 | 「永遠先評估現況再提建議」 | 確保 AI 的行為符合預期 |
| 輸出格式 | 「報告分四個段落」 | 讓結果一致、好讀、可預測 |
重點代理詳解:architect
architect.md 是最經典的代理範例。它定義了一個軟體架構師,用四階段流程做設計決策:
## Four-Phase Architecture Review
1. Current State Assessment
# ← 先搞清楚現在長什麼樣
# 看既有的設計模式、技術債
2. Requirements Collection
# ← 再釐清要做什麼
# 功能需求 + 非功能需求(效能、安全)
3. Design Proposal
# ← 然後提出設計方案
# 元件圖、API 設計、資料流
4. Trade-off Documentation
# ← 最後記錄取捨
# 每個決定的優缺點和替代方案
Code language: PHP (php)它還定義了五大建築支柱:
模組化(Modularity) → 單一職責、高內聚、清晰介面
可擴展性(Scalability)→ 水平擴展、無狀態設計
可維護性(Maintainability)→ 好組織、好文件、好測試
安全性(Security) → 縱深防禦、最小權限
效能(Performance) → 演算法效率、查詢優化、快取
Vibe Coder 看到這個代理時要知道的重點:architect 代理不會直接寫程式碼,它做的是「決策」——在你動手寫之前,先想清楚應該怎麼做。當你需要 Claude 不只是「寫出能跑的程式」而是「設計一個好的系統結構」時,就該用這個代理。
重點代理詳解:security-reviewer
security-reviewer.md 是品質審查類代理的代表。它內建了完整的 OWASP Top 10 檢查框架:
## OWASP Top 10 Analysis Framework
1. Injection ← SQL 注入、命令注入
2. Broken Authentication ← 密碼雜湊、JWT 驗證
3. Sensitive Data Exposure ← HTTPS、環境變數
4. XML External Entities ← XML 解析器設定
5. Broken Access Control ← 授權檢查、CORS
6. Security Misconfiguration ← 預設值、錯誤處理
7. Cross-Site Scripting ← 輸出跳脫、CSP 標頭
8. Insecure Deserialization ← 安全反序列化
9. Vulnerable Components ← 依賴更新、CVE 監控
10. Insufficient Logging ← 安全事件記錄
Code language: PHP (php)它的檢查清單長這樣:
## Security Checklist
- [ ] No hardcoded secrets ← 沒有寫死的密碼或金鑰
- [ ] Input validation present ← 有驗證使用者輸入
- [ ] SQL injection prevention ← 有防 SQL 注入
- [ ] XSS prevention measures ← 有防跨站腳本
- [ ] CSRF protection ← 有防跨站請求偽造
- [ ] Authentication required ← 有要求身份驗證
- [ ] Authorization verified ← 有檢查權限
- [ ] Rate limiting enabled ← 有限制請求頻率
- [ ] HTTPS enforced ← 有強制加密傳輸
- [ ] Security headers set ← 有設定安全標頭
- [ ] Dependencies current ← 依賴是最新版
- [ ] No vulnerable packages ← 沒有已知漏洞的套件
- [ ] Sanitized logging ← 日誌沒有洩漏敏感資料
- [ ] Safe error messages ← 錯誤訊息不洩漏內部資訊
Code language: CSS (css)它的輸出格式也有嚴格規範:
## Security Review Report
- File: src/api/auth.ts
- Date: 2025-01-15
- Risk Level: HIGH
### Issue #1
- Severity: CRITICAL
- Category: Injection
- Location: line 42
- Impact: 攻擊者可以執行任意 SQL
- Remediation: 使用參數化查詢
- Reference: CWE-89, OWASP A1
Code language: PHP (php)Vibe Coder 檢查點:看到 security-reviewer 的輸出時,注意 Severity 等級。CRITICAL 代表必須修,HIGH 代表應該修,MEDIUM 代表建議修。如果你的程式碼出現 CRITICAL,先停下來處理。
其他代理快速掃描
不需要每個都深入了解,但知道它們存在很重要。遇到相關場景時再去看它們的 .md 檔案:
build-error-resolver:最小修復哲學
# 核心原則:最小差異修復
# ──────────────────────
# 只修編譯錯誤,不做重構
# 改動行數 < 受影響檔案的 5%
## 工作流程
1. tsc --noEmit --pretty ← 收集所有錯誤
2. 每個錯誤做最小修復 ← 加型別標註、加 null 檢查
3. 確認沒有新錯誤 ← 再跑一次編譯
## 明確不做的事
- 不重構
- 不改命名
- 不優化效能
- 不改邏輯流程
Code language: PHP (php)tdd-guide:紅綠重構循環
## Red-Green-Refactor
1. 寫一個會失敗的測試 ← Red(紅燈)
2. 確認它真的失敗 ← 驗證測試有效
3. 寫最少的程式讓它通過 ← Green(綠燈)
4. 確認它通過了 ← 驗證實作正確
5. 重構改善品質 ← Refactor(不改行為)
## 覆蓋率目標:80%+
Code language: PHP (php)refactor-cleaner:安全移除哲學
## 移除前必做的事
1. 執行偵測工具(knip, depcheck)
2. 搜尋所有引用(grep)
3. 檢查動態 import
4. 查看版本控制歷史
5. 確認不是公開 API
6. 跑完整測試套件
# 核心原則:
# 「死碼是技術債,但安全第一
# ——永遠不要移除你不理解的程式碼」
Code language: PHP (php)如何設計自訂 Agent
看完了預設代理的結構,你已經具備設計自己代理的知識了。以下是設計步驟和 Prompt Engineering 技巧:
步驟 1:定義角色邊界
問自己三個問題:
1. 這個代理「是」什麼?
→ 明確的角色定位
2. 這個代理「做」什麼?
→ 具體的職責範圍
3. 這個代理「不做」什麼?
→ 明確的邊界(這很重要!)
為什麼「不做什麼」這麼重要? 因為 AI 會傾向「盡量幫忙」。如果你不設邊界,一個 code-reviewer 可能會開始幫你改程式碼,而不是只做審查。build-error-resolver 可能會開始重構,而不是只修編譯錯誤。
步驟 2:設計工作流程
用步驟化的流程定義代理該怎麼工作:
## Workflow
### Phase 1: Analysis
- Read the current codebase
- Identify relevant patterns
### Phase 2: Evaluation
- Apply checklist items
- Grade severity levels
### Phase 3: Output
- Generate structured report
- Provide actionable recommendations
Code language: PHP (php)步驟 3:指定輸出格式
明確告訴代理「回覆長什麼樣子」:
## Output Format
### Summary
[1-2 sentences overview]
### Findings
For each finding:
- Severity: [CRITICAL/HIGH/MEDIUM/LOW]
- Location: [file:line]
- Description: [what's wrong]
- Suggestion: [how to fix]
### Verdict
[APPROVE / NEEDS_CHANGES / REJECT]
Code language: PHP (php)步驟 4:加入「反面指令」
告訴 AI 什麼情況下不要做什麼:
## Constraints
- Do NOT modify any code directly
- Do NOT suggest changes outside the review scope
- Do NOT approve if any CRITICAL issue exists
- If unsure about severity, classify as HIGH (err on the side of caution)
Code language: PHP (php)實戰:建立一個 API-designer Agent
把上面學到的技巧,實際動手做一個 API 設計專家代理。
建立 .claude/agents/api-designer.md:
# API Designer Agent
You are a senior API designer specializing in RESTful API design
and OpenAPI specifications. You help teams design consistent,
intuitive, and well-documented APIs.
## Tools Available
- Read, Grep, Glob (for analyzing existing APIs)
## Primary Responsibilities
- Review and design RESTful API endpoints
- Ensure naming consistency across the API surface
- Validate request/response schemas
- Check error handling patterns
## Design Principles
### URL Convention
- Use nouns, not verbs: `/users` not `/getUsers`
- Use plural: `/users` not `/user`
- Use kebab-case: `/user-profiles` not `/userProfiles`
- Nest for relationships: `/users/{id}/orders`
### HTTP Methods
- GET: Read (no side effects)
- POST: Create
- PUT: Full update
- PATCH: Partial update
- DELETE: Remove
### Response Format
All responses must follow:
Code language: PHP (php)
### Status Codes
- 200: Success
- 201: Created
- 400: Bad Request (client error)
- 401: Unauthorized (not logged in)
- 403: Forbidden (no permission)
- 404: Not Found
- 422: Validation Error
- 500: Server Error
## Workflow
### Phase 1: Discovery
1. Read existing API routes and patterns
2. Identify naming conventions already in use
3. Map the resource hierarchy
### Phase 2: Analysis
1. Check for inconsistent naming
2. Validate HTTP method usage
3. Review error response patterns
4. Verify pagination implementation
### Phase 3: Report
Generate a structured review with:
- Consistency score (1-10)
- List of inconsistencies found
- Suggested corrections
- New endpoint recommendations if applicable
## Output Format
### API Review Report
**Consistency Score**: [X/10]
**Existing Patterns**:
- URL style: [kebab-case/camelCase/mixed]
- Response format: [consistent/inconsistent]
- Error handling: [standardized/ad-hoc]
**Issues Found**:
| # | Endpoint | Issue | Severity | Suggestion |
|---|----------|-------|----------|------------|
| 1 | GET /getUser | Verb in URL | MEDIUM | → GET /users/{id} |
**Recommendations**:
1. [Actionable item]
2. [Actionable item]
## Constraints
- Do NOT implement API code directly
- Do NOT suggest breaking changes without migration plan
- Do NOT design endpoints without checking existing patterns first
- Focus on consistency over personal preference
Code language: PHP (php)拆解這個代理的設計邏輯
回頭看這個代理,它完整展示了四大結構:
角色定義 → 「You are a senior API designer...」
能力範圍 → Tools Available + Primary Responsibilities
行為約束 → Design Principles + Constraints
輸出格式 → Output Format(統一的報告結構)
同時也展示了幾個重要的 Prompt Engineering 技巧:
- 給具體的規則,而不是抽象的原則
- 好:「Use nouns, not verbs:
/usersnot/getUsers」 - 不好:「Follow good API naming practices」
- 好:「Use nouns, not verbs:
- 給範例,而不是只有描述
- 好:表格裡的
GET /getUser → GET /users/{id} - 不好:「Fix inconsistent endpoint names」
- 好:表格裡的
- 用「反面指令」設邊界
- 「Do NOT implement API code directly」確保它只設計不實作
- 「Do NOT suggest breaking changes without migration plan」確保它考慮現實
什麼時候該用 Agent、什麼時候用 Command?
最後一個常見問題。用這個判斷流程:
你要 Claude 做的事情...
需要「角色知識」嗎?
├── 不需要 → 用 Command
│ 例:/plan(產出一份計畫)
│ 例:/test(跑一次測試)
│
└── 需要 → 用 Agent
例:architect(需要懂架構原則才能做設計)
例:security-reviewer(需要懂 OWASP 才能做審查)
需要「持續判斷」嗎?
├── 不需要(做完就結束)→ 用 Command
│ 例:/format(格式化程式碼)
│
└── 需要(多步驟、需要評估)→ 用 Agent
例:code-reviewer(要看整份 diff、評分、決定是否通過)
簡單記:一次性任務用 Command,需要專業判斷的用 Agent。
Vibe Coder 檢查點
看到 .claude/agents/ 目錄裡的 .md 檔案時,確認這些事:
必看懂:
- 角色定義(開頭的 "You are...")→ 知道這個代理扮演什麼角色
- Constraints 區塊 → 知道這個代理不會做什麼
- Output Format 區塊 → 知道結果會長什麼樣子
知道就好:
- 具體的檢查清單項目 → 遇到再查
- 工具列表(Tools Available)→ 知道它能讀檔就夠了
- 進階的工作流程細節 → 實際使用時再深入
Code language: JavaScript (javascript)本篇重點回顧
| 概念 | 一句話總結 |
|---|---|
| Agent vs Command | Agent 有角色設定和持續判斷,Command 是一次性觸發 |
| Agent 檔案位置 | .claude/agents/xxx.md |
| 四大結構 | 角色定義、能力範圍、行為約束、輸出格式 |
| 13 個預設代理 | 分四類:架構、品質、開發、維運 |
| 自訂代理技巧 | 定義邊界、設計流程、指定格式、加反面指令 |
| 什麼時候用 Agent | 需要專業角色知識 + 持續判斷的任務 |
下一篇預告
【Claude Code 進階配置】#04 將進入 Hooks 自動觸發機制——讓 Claude Code 在特定事件發生時自動執行動作,不再需要你手動觸發。
進階測驗:Agents 特化代理 – 讓 AI 扮演不同角色
共 5 題,包含情境題與錯誤診斷題。