【Claude Code 進階配置】#03 Agents 特化代理:讓 AI 扮演不同角色

測驗:Agents 特化代理 – 讓 AI 扮演不同角色

共 5 題,點選答案後會立即顯示結果

1. 在 Claude Code 的配置系統中,Agent 和 Command 的核心差異是什麼?

  • A. Agent 放在 .claude/commands/ 裡,Command 放在 .claude/agents/
  • B. Agent 永遠自動生效,Command 需要手動觸發
  • C. Agent 有角色設定和持續判斷能力,Command 是一次性觸發的快捷操作
  • D. Agent 只能讀取檔案,Command 可以修改檔案

2. Agent 的 Markdown 檔案包含四大核心區塊,下列哪個不屬於這四大區塊?

  • A. 角色定義(Role Definition)
  • B. 行為約束(Behavior Constraints)
  • C. 輸出格式(Output Format)
  • D. 執行排程(Execution Schedule)

3. 13 個預設代理被分為四大類,下列哪個代理屬於「品質審查類」?

  • A. planner(規劃專家)
  • B. security-reviewer(資安漏洞偵測專家)
  • C. tdd-guide(測試驅動開發教練)
  • D. doc-updater(文件更新專家)

4. build-error-resolver 代理的核心哲學是什麼?

  • A. 徹底重構有問題的程式碼,確保不再出錯
  • B. 最小差異修復:只修編譯錯誤,不做重構,改動行數低於受影響檔案的 5%
  • C. 先優化效能,再修正編譯問題
  • D. 同時修復所有類型的錯誤,包含邏輯錯誤和效能問題

5. 設計自訂 Agent 時,為什麼「定義代理不做什麼」很重要?

  • A. 因為不設限制的話,Agent 會消耗太多運算資源
  • B. 因為 Claude Code 要求每個 Agent 至少要有三條限制規則
  • C. 因為 AI 傾向「盡量幫忙」,不設邊界會導致代理越權,例如審查員開始改程式碼
  • D. 因為「不做什麼」的定義會自動生成對應的 Rule 檔案

**系列**: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)
json { “data”: {}, “meta”: { “page”: 1, “total”: 100 }, “errors”: [] }


### 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 技巧:

  1. 給具體的規則,而不是抽象的原則
    • 好:「Use nouns, not verbs: /users not /getUsers
    • 不好:「Follow good API naming practices」
  2. 給範例,而不是只有描述
    • 好:表格裡的 GET /getUser → GET /users/{id}
    • 不好:「Fix inconsistent endpoint names」
  3. 用「反面指令」設邊界
    • 「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 題,包含情境題與錯誤診斷題。

1. 你正在開發一個電商平台,需要新增「購物車結帳」功能。這個功能涉及多個元件(前端表單、API 路由、資料庫交易、金流串接),你想在動手寫程式之前先做好系統設計。你應該使用哪個代理? 情境題

  • A. planner — 它是規劃專家,負責拆解任務
  • B. architect — 它是軟體架構師,負責系統設計決策
  • C. code-reviewer — 它是程式碼審查員,負責品質檢查
  • D. security-reviewer — 金流功能涉及安全性,應該用資安審查

2. 你的 TypeScript 專案突然編譯失敗,出現了 15 個型別錯誤。你只是想趕快讓建置通過,而不需要改善程式碼品質。你應該使用哪個代理?這個代理會怎麼做? 情境題

$ tsc –noEmit src/api/user.ts(12,5): error TS2322: Type ‘string’ is not assignable to type ‘number’. src/api/order.ts(28,3): error TS2345: Argument of type ‘null’ is not assignable… … (共 15 個錯誤)
  • A. 使用 code-reviewer,它會審查所有錯誤並提供改善建議
  • B. 使用 refactor-cleaner,它會清理有問題的程式碼
  • C. 使用 build-error-resolver,它會用最小差異修復每個錯誤(加型別標註、加 null 檢查),不做重構
  • D. 使用 architect,先重新設計型別系統再修復錯誤

3. 你想建立一個自訂代理來審查團隊的 CSS 程式碼。你寫好了角色定義和檢查清單,但發現這個代理在審查時經常「順便」幫你改了 CSS 程式碼,而不是只做審查。根據文章的 Prompt Engineering 技巧,你最應該加入什麼來解決這個問題? 情境題

  • A. 在角色定義中加入更詳細的專長描述
  • B. 在能力範圍中移除 Write 和 Edit 工具
  • C. 增加更多的檢查清單項目
  • D. 加入「反面指令」,例如 Do NOT modify any code directly

4. 小華想建立一個自訂的 API 設計代理,他寫了以下的代理檔案。根據文章提到的 Agent Markdown 四大結構和設計原則,這個代理最大的問題是什麼? 錯誤診斷

# API Review Agent You are an API review specialist. ## Responsibilities – Review API design – Fix API code – Deploy API changes – Monitor API performance ## Guidelines – Follow good API practices – Make sure APIs work correctly
  • A. 缺少 Tools Available 區塊,代理不知道能用什麼工具
  • B. 職責過於寬泛且缺少邊界限制——一個審查代理不應該「Fix API code」和「Deploy API changes」,且 Guidelines 太抽象沒有具體規則
  • C. 缺少輸出格式定義,代理不知道報告要長什麼樣
  • D. 角色定義太簡短,應該要寫至少三段以上的描述

5. 小美看到 security-reviewer 代理輸出了以下報告。她認為可以先處理其他功能,等下週再來修這個問題。這個判斷對嗎? 錯誤診斷

## Security Review Report – File: src/api/auth.ts – Risk Level: HIGH ### Issue #1 – Severity: CRITICAL – Category: Injection – Location: line 42 – Impact: 攻擊者可以透過登入表單執行任意 SQL – Remediation: 使用參數化查詢取代字串拼接 – Reference: CWE-89, OWASP A1
  • A. 判斷正確,因為 Risk Level 只是 HIGH 而非 CRITICAL,代表可以延後處理
  • B. 判斷正確,因為只有一個 Issue,數量很少表示問題不大
  • C. 判斷錯誤,Issue 的 Severity 是 CRITICAL,代表必須立即修復。SQL 注入漏洞可讓攻擊者存取整個資料庫,不能延後
  • D. 判斷錯誤,因為 auth.ts 是認證相關檔案,任何問題都應該立即處理,不管 Severity 是什麼

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *