前面我們學了不少東西，尤其是 SKILL 的部分，但......你有沒有想過一個問題呢？
「當所有東西都往當前 AI 塞，難道 Context 會是足夠的嗎？」
畢竟實務開發上內容是非常龐大的，那這樣不是就很容易 Context 爆掉嗎？
所以今天要介紹的 Subagent，也就是請「另一個人」的機制，讓你可以把一些工作外包給另一個獨立的 AI 分身，這樣就不會把你的主對話塞爆了。
在這邊我們要先理解一個概念，也就是「主要 Agent」與「子 Agent」的差別。
首先，這邊我們所講的「主要 Agent」就是你平常在對話的 AI 對話視窗，而「子 Agent」就是你另外請的一名 AI 分身，但它不會跟你在同一個對話視窗裡，它有自己的獨立 context、獨立的世界，它只會把做完的事帶回來（結論）。
所以這邊有一個問題可以讓你思考一下：
主對話的 AI 明明可以自己讀取程式碼，那為什麼 Code Review（程式碼檢查/審查）還要特地外包給另一個人？
其實原因很簡單，跟 Context 有非常大的關聯。
什麼意思呢？
Context 在前面的章節中，我們知道如果塞到超出一定程度，甚至一旦觸發 Auto Compact（Day 6 講的自動壓縮）的話，它就會喪失核心關鍵的重點，所以 Context 的多寡管控非常重要，但實際開發上我們常常會跨非常多檔案，甚至是跨專案，這時候 Context 就會變得非常大，甚至可能超過 AI 的記憶上限，自然而然就會變得很臃腫進而影響判斷力，這就是所謂的「上下文混淆（Context Confusion）」，裡面塞了太多無意義的資訊，反而會讓 AI 做出錯誤的判斷。
Note
「上下文混淆（Context Confusion）」更白話一點解釋就是上傳了 N 份檔案給它參考，但裡面真正需要的只有 1 份，其他的都是干擾資訊，這樣就會讓 AI 做出錯誤的判斷。
所以 Subagent 的設計就是為了解決這個問題，它的出現就會有以下優勢：
整體運作流程就會像是這樣：
那這個跟 SKILL 有什麼關係嗎？當然有，而且關係可大囉～
但是這邊要先打破一個常見的誤會：
子 Agent 是一個全新的獨立 context，昨天寫好的那些 SKILL 它不一定拿得到，所以如果你以為子 Agent 會自動把 SKILL 撿去用，答案是不一定。
為什麼說「不一定」呢？因為這件事是由你決定的。子 Agent 本身是有能力去叫用你專案裡的 SKILL 沒錯，但等一下我們要建立的這位審查者，會被我們限制成只能讀檔跟搜尋，連叫用 SKILL 的能力都沒給它，所以它真的碰不到昨天那份 SKILL。
那......如果它用不到 SKILL 的話，那它該怎麼知道「怎麼做事」呢？這個其實完全依賴於它的定義檔，等一下我們也會來體驗它的建立過程，建立過程也非常簡單，就只是單純的一份 markdown 檔案，而那份檔案的內容就是它的工作說明書（SOP），你必須把角色、步驟、回報格式寫清楚，其實就跟 SKILL 一樣。
依照前面這樣講，是不是就代表 SKILL 跟子 Agent 完全無關呢？也無法使用呢？也不是，其實在 Subagent 的定義上有一個 skills 欄位，可以把現成的 SKILL 預先載入給子 Agent，這樣它就可以使用你之前寫好的 SKILL 去做事了。
所以你可以這樣想：
理解之後，我們也會來實際建立一個 Code Review 的 Subagent 唷。
那 Subagent 要怎麼建立呢？基本上跟昨天的 SKILL 非常像，只是位置換成了 .claude/agents/，而且它更簡單，不需要像 SKILL 一樣，每個技能都用資料夾去區分，因為一個 Subagent 就直接對應一個 markdown 檔案。
首先請你在專案根目錄，一樣以我們的 money-note 專案為例，建立一個 .claude/agents/ 資料夾，然後在裡面建立一份 code-reviewer.md，並且把下面這份第一版貼進去：
---
name: code-reviewer
description: 審查程式碼品質。當使用者要求 code review、審查、檢查程式碼時使用。只讀不改。
tools: Read, Grep, Glob
---
你是 money-note 專案的資深前端審查者。收到審查任務時：
1. 先讀 SPEC.md、CLAUDE.md、DESIGN.md 了解專案的規則
2. 審查指定範圍的程式碼，聚焦：
- bug 風險：邊界情況、資料驗證漏洞、狀態不同步
- 重複邏輯：同樣的事寫了兩遍以上
- 違反專案規則：金額沒轉 number、樣式寫死顏色不用變數
- 命名與可讀性
3. 你只能讀，不能改任何檔案
回報格式：每個問題一條，包含
- 嚴重度：紅（必修）/ 黃（建議）
- 位置：檔案與行數
- 問題描述與建議修法（一句話）
沒有問題就明說沒有問題，不要硬湊。
是不是看到熟悉的 frontmatter 了呢？但，除了 name 跟 description，這次多了一個 tools 欄位，這個欄位是用來限制這個 Subagent 可以使用哪些工具的。
而 tools 欄位的值是 Read, Grep, Glob，這代表這個 Subagent 只能做以下事情：
這是刻意設計的，因為我們希望這個 Subagent 只負責審查程式碼，而不是修改程式碼。
Note
Read是用來讀取檔案內容Grep是用來搜尋檔案內容Glob是用來搜尋檔案路徑
而這個內文也是一樣，你要把它的角色、任務步驟、回報格式寫清楚，這樣它才知道自己該怎麼做事。
別忘了，建立好 Subagent 之後要重新啟動一下，這樣它才會被載入，否則主對話的 AI 是找不到它的。這邊補充一下，只有「第一次建立 .claude/agents/ 這個資料夾」需要重啟，之後在裡面新增或修改檔案，跟 SKILL 一樣是存檔即生效。
那這邊我們先小試身手一下，一樣使用 money-note 專案來示範，請你在 Claude Code 的對話視窗輸入以下：
請 Code Review 這幾個檔案：
- src/App.vue
- src/components/
- src/assets/main.css
請依照 DESIGN.md 內容去檢查是否遵守、375px 可能的跑版、表單 label、鍵盤 focus、按鈕是否至少 44px 這幾個區塊。
Note
src/assets/main.css這是我刻意打不存在的檔案。
接著你應該會遇到一個問題，你會看到主 Agent 自己開始做事情了？！
ㄟ？主 Agent 怎麼自己開始做 Code Review 了？！怎麼不是呼叫子 Agent 來做呢？難道它壞掉了嗎？
不，不對，其實是主 Agent 自己判斷覺得可以自己處理，所以就乾脆自己處理了，這種狀況下，你 description 寫得再漂亮也沒用，因為它覺得自己可以做（固執）。
那我們到底該怎麼做呢？其實很簡單，直接把 code-reviewer 這個名字點名進去就好，像這樣：
請使用 code-reviewer 來檢查這幾個檔案：
- src/App.vue
- src/components/
- src/assets/main.css
請依照 DESIGN.md 內容去檢查是否遵守、375px 可能的跑版、表單 label、鍵盤 focus、按鈕是否至少 44px 這幾個區塊。
接下來，你就會看到對話視窗下面多了一個 code-reviewer 的區塊，這其實就代表主 Agent 已經把這個任務派給子 Agent 了。
對了，還記得我剛剛刻意打錯的 src/assets/main.css 嗎？你可以看到主 Agent 在派工之前先翻了一下資料夾，發現這個檔案根本不存在，然後自己對照 CLAUDE.md 找出這個專案真正的樣式檔是 src/style.css，直接換成那一份送審，中間完全沒有停下來問我。
Note
如果你連「主 Agent 會不會自己做掉」都不想賭，還有一招更保險：在輸入框打一個@，選單就會跳出來，裡面可以選到code-reviewer (agent)，選下去就是保證派給它。
過段時間之後，你就可以看到子 Agent 回報的 Review 結果：
那這個「code-reviewer」是來自於檔案名稱（.md）呢？還是 frontmatter 的 name 呢？其實 AI 認的是 frontmatter 的 name，所以你可以把檔案名稱改成 code-reviewer-1.md，但只要 frontmatter 的 name 還是 code-reviewer，它還是會認得唷！
所以接下來拿到這份 Code Review 報告之後你可以怎麼做呢？大致上做法就跟 Day 12 差不多，你必須要親自去了解這份 Code Review 的報告內容，反正只要有看不懂，搞懂它就對了。
那也差不多到結尾了，這邊也幫你簡單的整理一下今天的重點：
.claude/agents/，寫法跟 SKILL 類似，透過 description 撰寫觸發時機，並透過 tools 做權限控制。@ 選單可以保證分配出去。那麼我們下一篇見。
iThome鐵人賽
看影片追技術