內建工具的選用與套用

CCA-F（Claude Certified Architect — Foundations）考試任務說明 2.5——「有效選用並運用內建工具（Read、Write、Edit、Bash、Grep、Glob）」——隸屬於 Domain 2（工具設計與 MCP 整合，佔比 18%），測驗的是考生能否在面對特定檔案系統或 shell 操作時，選出正確的工具而不過度擴權。六個內建工具從外觀看似不多，但 CCA-F 的情境題叢集非常依賴它們：每道程式碼生成、開發者生產力和 CI/CD 相關題目，背後隱含的都是 Claude 正確地調用 Read、Write、Edit、Bash、Grep 或 Glob，選對工具、帶對參數、保持正確的安全姿態。誤判工具邊界——在該用 Edit 的地方用了 Write、在 Glob 就夠用的地方用了 Bash、在問題是檔案探索時卻選了 Grep——是高頻出現的考試陷阱。

這份學習筆記完整走過 CCA-F 考生在選用層面必須熟悉的全部內建工具面向：工具清單與用途對應、每個工具的精確契約、主導考試出題的 Edit vs Write 決策原則、Bash 的風險面、Grep 和 Glob 的「內容 vs 路徑」之別、工具組合流水線（Glob → Read → Edit 的程式碼庫重構流程）、批次操作 vs 精準操作的效能取捨，以及區分生產級 agent 與莽撞實作的安全確認機制。最後的陷阱章節與七題 FAQ，將每個概念錨定回兩個最密集測驗內建工具的考試情境：developer-productivity-with-claude 和 claude-code-for-continuous-integration。

內建工具清單 — 六個工具，六個截然不同的用途

Claude Code 和 Claude Agent SDK 內建六個標準工具。每個工具的職責都被刻意設計得很窄：窄職責讓選用變得明確，降低 Claude 把工具搞混的機率，也給考試提供了清晰的測驗面。CCA-F 要求你將每個工具對應到單一主要用途，並清楚知道這個工具不適合做什麼。

• Read — 將特定檔案的內容載入 context。支援行範圍限制。不是搜尋工具。
• Write — 建立全新檔案，或完整覆寫現有檔案。不是精準修改工具。
• Edit — 對現有檔案進行精準的就地替換。不是建立檔案的工具。
• Bash — 執行任意 shell 命令。六個內建工具中功能最強大、也最危險的一個。
• Grep — 在多個檔案的內容中搜尋模式（正規表達式或字面字串）。不是檔名搜尋工具。
• Glob — 依路徑模式（globbing：**/*.ts、src/**/test_*.py）探索檔案。不是內容搜尋工具。

這六個工具構成 CCA-F 考試的封閉集合：每道涉及檔案或 shell 操作的情境題，都會對應到其中一個。若情境描述「讀取 config.json 的內容」，答案是 Read；若描述「找出每個 import 了 legacy_auth 的檔案」，答案是 Grep；若描述「列出 api/ 目錄下所有 .proto 檔案」，答案是 Glob。出題者刻意使用近義措辭，藉此區分真正掌握邊界的考生和靠猜的考生。

為什麼 Built-In Tool 要與 Bash 並列存在

Bash 在技術上能夠讀取、寫入、編輯、搜尋和 glob 檔案。理論上你可以讓 agent 只有 Bash，並達到 Read、Write、Edit、Grep、Glob 的大部分功能。Anthropic 在 Bash 旁邊另外提供五個專用工具，是因為專用工具比原始 shell 更安全、更可觀測、也更易於 Claude 推理。一次 Read 工具呼叫會以結構化 metadata 記錄「Claude 在這個時間點讀了這個檔案的這幾行」；一次 cat file.txt 的 Bash 呼叫只記錄了一個 shell 字串。專用工具縮小了每個動作的爆炸半徑——Read 不能刪任何東西，Edit 不能建立新檔案，Glob 不能改變任何狀態——同時讓 agent 的執行軌跡可稽核。CCA-F 將「有專用工具可用時優先選專用工具而非 Bash」視為基準設計準則。

Read 工具 — 帶行範圍參數載入檔案內容至 Context

Read 工具將指定檔案的內容載入 Claude 的 context window。Read 是預設的檔案攝取原語：每當 agent 需要看到檔案裡面的東西——原始碼、設定、文件、日誌——Read 就是正確的工具。

Read 工具參數

考試情境最常利用的關鍵參數：

• file_path — 絕對路徑。大多數 Agent SDK 設定不支援相對路徑。
• offset — 選填；起始行號。用於讀取大型檔案的某個窗口。
• limit — 選填；要讀取的行數。與 offset 搭配使用以限定讀取範圍。

offset/limit 這組參數的存在，正是為了解決 context window 壓力：一個 50,000 行的日誌檔絕對不應該一次全部讀入。只拉出相關的 200 行，既避免 context window 被淹沒，也保留了注意力供實際任務使用。

何時使用 Read

Read 適用於 agent 需要某個已知檔案的具體內容的情況。典型的考試措辭，對應到 Read 的如下：

• 「agent 需要查看 config/database.yml 目前的設定值。」
• 「agent 必須查看 src/parser.ts 的第 200 至 250 行，以了解現有實作。」
• 「agent 需要載入 package.json，才能決定要執行哪些腳本。」

何時不該使用 Read

Read 不是檔案探索工具，也不是內容搜尋工具。若情境一開始就說「agent 不知道哪個檔案包含……」，答案是 Grep（搜尋內容）或 Glob（搜尋名稱模式），而不是 Read。情境干擾選項常常把 Read 擺在那裡，作為當底層操作其實是搜尋時的誘人錯誤答案。

Write 工具 — 建立新檔案或完整覆寫，以及何時不該使用它

Write 工具在指定路徑建立新檔案，或完整替換現有檔案的內容。Write 是全有或全無的操作：整個檔案在一次呼叫中寫入；不存在部分寫入的概念。

Write 工具參數

• file_path — 絕對路徑。若檔案已存在，其內容將被完整覆寫。若不存在，則新建（依 SDK 設定，可能同時建立父目錄）。
• content — 要寫入的完整文字內容。

Write 的正確使用時機

Write 只在兩種情況下是正確的：

1. 建立全新檔案 — 要建立的檔案目前不存在。例如：產生新的 migration 檔案、生成全新的設定檔、寫入一個沒有前身的全新測試檔案。
2. 刻意的完整替換 — 現有檔案要被完整替換，且替換並非對原有內容的精準修改。例如：重新生成 lockfile、覆寫建置產物、用真實內容覆蓋佔位範本。

Write 的錯誤使用時機

Write 在下列情況是錯誤的——而這是任務說明 2.5 中測驗頻率最高的單一考點——只要操作是對現有檔案的修改，Write 就是錯的。修改現有檔案的意思是：新內容是舊內容的函數，例如「更改這個函式的回傳型別」、「在這個 struct 中新增一個欄位」、「把 import 中的 legacy_client 替換成 new_client」。這些操作需要 Edit。把 Write 用在這類場景既不安全（必須送出完整內容，任何謄寫錯誤都會靜默地讓程式碼消失），在考試上也代表工具選用錯誤。

為什麼完整覆寫有風險

一次覆寫現有檔案的 Write 呼叫，必須讓 Claude 重新輸出它打算保留的每一行。任何 Claude 遺漏、壓縮或隱約改寫的行，都會靜默地消失。對一個 2,000 行的原始碼檔案而言，完美重現的機率不足以在生產系統中信任。Edit 之所以更安全，是因為未被修改的行根本不需要送出——它們就保留在檔案系統原本的樣子。這個不對稱性正是考試堅持用 Edit 做就地修改的原因。

Edit 工具 — 精準就地修改，優先於對現有檔案使用 Write

Edit 工具對現有檔案進行精準的就地替換。Edit 只送出「修改前」片段和「修改後」片段；檔案中的其餘部分在檔案系統層面完全不受影響。

Edit 工具參數

• file_path — 絕對路徑。檔案必須已存在；Edit 不建立新檔案。
• old_string — 要替換的確切字面片段。空白字元和縮排必須完全吻合。
• new_string — 替換後的片段。
• replace_all — 選填布林值；為 true 時替換所有出現的地方。為 false（預設）時，old_string 在檔案中必須是唯一的，否則呼叫失敗。

何時使用 Edit

Edit 適用於任何對現有檔案的修改，只要該修改可以表達為一個前後字串替換。典型的考試措辭：

• 「將 config.yml 中的 timeout 值從 30 改為 60。」
• 「在 parser.ts 中，將函式 processData 的所有定義改名為 normalizeData。」
• 「在 handler 中，將棄用的 request.Legacy() 呼叫替換成 request.V2()。」

唯一性要求

當 replace_all 為 false 時，old_string 在檔案中必須恰好出現一次。若片段不明確（例如三個都叫 handle() 的函式），Edit 呼叫會失敗，agent 必須消除歧義——通常是在 old_string 中納入更多周圍的 context（函式簽章加上一行具有特徵的內容）。這個唯一性要求是安全機制：它防止一個出於好意的改名，意外地砸中一個碰巧包含相同字串的無關程式行。

Edit 保留無關內容

因為 Edit 只送出差異，其餘的檔案內容不可能因為 Claude 遺漏、改寫或重新縮排某行而損壞。這是 Edit 比 Write 更安全的結構性原因。考試答案若將 Edit 框架為「修改現有檔案的更安全選項」，與 Anthropic 文件的選用規則一致。

Edit vs Write 決策原則 — 檔案已存在用 Edit，全新檔案才用 Write

Edit 和 Write 之間的選擇，是任務說明 2.5 中出現頻率最高的判斷題。CCA-F 的情境題特別被設計成：能獎勵已將這條規則內化的考生，同時懲罰那些只靠模式匹配「我們要寫入檔案，所以應該是 Write」的考生。

一句話說清楚

若檔案已存在且操作是修改其中一部分，用 Edit。只有全新檔案或刻意的完整替換，才用 Write。

決策樹

1. 檔案存在嗎？ 若否，用 Write。若是，繼續。
2. 打算做的修改是對整個檔案的完整、刻意替換嗎？ 若是，Write 可接受。若否，繼續。
3. 修改的是檔案的一部分嗎？ 用 Edit。

為什麼這條規則存在

三個結構性原因：

• 安全 — Edit 不會因為 Claude 忘記重新輸出而遺失內容；Write 會。
• 可觀測性 — Edit 呼叫的 diff 很小、易於稽核。Write 呼叫的「diff」就是整個檔案，工具無法廉價地做 review。
• 成本與延遲 — Edit 只送出一組小小的前後配對。Write 在每次呼叫時都送出完整的檔案內容，對大型檔案來說 token 成本暴增。

常見的干擾選項

考試常常在一道修改情境題中，把 Write 和 Edit 並列為四個選項之一。典型的錯誤答案措辭：

• 「寫入更新後的檔案」——錯誤；更新應使用 Edit。
• 「用新內容覆寫檔案」——錯誤，若只有部分內容在改變。
• 「重新輸出套用修改後的完整檔案」——錯誤；這是 Write 包裝成 Edit 的偽裝。

任何修改情境題的正確答案都是 Edit。

Bash 工具 — Shell 命令執行、風險面與安全考量

Bash 工具在子行程中執行任意 shell 命令，並回傳 stdout、stderr 和 exit code。Bash 是內建工具組中功能最強大的，也因此是最危險的。CCA-F 將 Bash 視為最後手段：只要有專用工具（Read、Write、Edit、Grep、Glob）能表達該操作，就優先使用專用工具。

Bash 工具參數

• command — 要執行的 shell 命令字串。
• timeout — 選填；每次呼叫的掛鐘時間上限。對長時間執行的建置或測試套件來說很重要。
• description — 描述命令意圖的簡短人類可讀標籤。用於日誌記錄和稽核。

Bash 真正適合做什麼

Bash 是以下情況的正確選擇——當操作本質上就是 shell 命令，且沒有對應的專用工具時：

• 執行建置與測試 — npm test、pytest、cargo build、make lint。
• 呼叫版本控制命令 — git status、git log、git diff（部分 SDK 設定透過專用工具提供這些功能；請查閱參考文件）。
• 管理行程與服務 — systemctl、docker compose up、kill。
• 沒有 Claude Code 等效工具的一次性 shell 工具 — 對內部端點的 curl、jq 後處理、對結構化日誌的 awk 欄位擷取。
• 套件管理器操作 — pip install、npm install、apt-get update。

Bash 不適合做什麼

若有專用工具可完成相同操作，就不應使用 Bash：

• 讀取檔案 → Read，不是 cat。
• 寫入檔案 → Write 或 Edit，不是 echo > file 或 sed -i。
• 搜尋內容 → Grep，不是透過 Bash shell out 的 grep。
• 依模式列出檔案 → Glob，不是透過 Bash shell out 的 find。

在有專用工具的情況下使用 Bash，會無謂地擴大爆炸半徑（Bash 可以執行任何命令）、削弱可觀測性（意圖被埋在 shell 字串裡），在考試上會被視為糟糕的設計。

風險面

Bash 命令可以：

• 刪除檔案（rm -rf）。
• 更改設定（sed -i、echo >）。
• 發送網路流量（curl、wget、ssh）。
• 消耗無限資源（失控的 tail -f 或 dd）。
• 洩漏資料（任何讀取本地檔案並將其傳送出去的命令）。

正因如此，在生產環境執行 Bash 的 agent，應結合可接受命令的允許清單（allowlist）、每次呼叫的超時設定，以及——對於破壞性或無邊際的操作——在執行前明確取得人工核准。

Grep 工具 — 跨檔案模式搜尋、正規表達式 vs 字面字串、Context 行

Grep 工具搜尋檔案的內容，尋找指定的模式。Grep 回傳匹配行及其檔案路徑與行號。Grep 是回答「哪些檔案包含 X」或「這個符號出現在哪裡」的首選工具。

Grep 工具參數

典型參數（依 SDK 不同可能有所差異）：

• pattern — 要搜尋的正規表達式或字面字串。
• path — 選填；限定搜尋範圍的目錄或檔案。若省略，Grep 會搜尋整個工作目錄。
• output_mode — 控制匹配結果的回傳方式（帶路徑的行、僅路徑、僅計數）。
• -i / 不分大小寫 — 選填的大小寫不敏感比對。
• -n / 行號 — 在每個匹配結果中包含行號。
• -A / -B / -C — 每個匹配後 / 前 / 前後的 context 行數。用於查看匹配所在的函式或區塊。
• glob — 限定只搜尋符合路徑模式的檔案（例如 *.ts）。

何時使用 Grep

Grep 適用於問題是「哪些行或檔案包含這個模式」的情況。典型的考試措辭：

• 「找出整個程式碼庫中每個使用 process.env.API_KEY 的地方。」
• 「定位 UserSession interface 的定義。」
• 「列出所有 import 了棄用的 utils/legacy.ts 的檔案。」
• 「找出錯誤訊息 invalid token 被觸發的那一行。」

正規表達式 vs 字面字串

Grep 支援正規表達式模式。錨點（^、$）、字元類別（[A-Z]）和捕獲群組都可使用。對於單純的字面字串搜尋——例如找出確切的檔名 schema.sql 每次出現的地方——字面搜尋更快，且避免意外的正規表達式解讀（模式中的字面 $ 若被當作正規表達式，會匹配到行尾）。模式已知是精確字串時用字面形式；需要靈活性時用正規表達式。

Context 行在考試中很重要

Context 旗標（-A、-B、-C）常被忽略，但它們是讓 agent 在匹配所在區塊的脈絡中查看結果的機制。只讀匹配那一行往往產生脫離上下文的判斷；預設讀取 -C 3（前後各三行）通常更合適。情境題若描述 agent「理解包含匹配的函式」，通常就隱含了需要 context 行。

Glob 工具 — 依模式探索檔案，何時優先於 Bash find

Glob 工具依路徑模式探索檔案。Glob 回傳符合的檔案路徑清單，通常依修改時間排序（最新在前）。Glob 是「找出所有 .ts 檔案」或「列出這個目錄下的每個測試檔案」的首選工具。

Glob 工具參數

• pattern — glob 風格的路徑模式。標準萬用字元：*（路徑段內任意字元）、**（任意深度的目錄）、?（單一字元）、字元類別。範例：**/*.ts、src/**/test_*.py、docs/**/*.md。
• path — 選填；glob 的根目錄。若省略，Glob 從工作目錄開始運作。

何時使用 Glob

Glob 適用於問題是「哪些檔案的路徑符合這個模式」的情況。典型的考試措辭：

• 「列出 api/ 目錄下每個 .proto 檔案。」
• 「找出專案中所有符合 test_*.py 的測試檔案。」
• 「探索 docs/ 下所有的 markdown 文件。」
• 「列舉儲存庫中每一個 YAML 設定檔。」

Glob vs Bash find

Bash 的 find 工具能做到 Glob 所有能做的事。CCA-F 優先選 Glob 而非 find 的原因，與一般選用專用工具的理由相同：Glob 更窄、更安全、更可觀測，且不會把爆炸半徑擴大到任意 shell 執行。一個 find 呼叫可以被 pipe 進 rm、mv 或任何其他破壞性命令；Glob 呼叫則不行。在考試上，「用 Bash find 列出檔案」是當 Glob 為正確工具時刻意放置的錯誤答案。

Glob vs Grep — 內容 / 路徑的邊界

這是 Grep/Glob 中被測驗最多的單一區別：

• Grep 在檔案內容中搜尋模式。
• Glob 在檔案路徑中搜尋模式。

「找出所有提及 UserSession 的檔案」是 Grep（內容）。「找出所有名為 user_session.ts 的檔案」是 Glob（路徑）。考試干擾選項慣用地對調這兩個，測驗考生是否已將邊界內化。

工具組合模式 — Glob → Read → Edit 流水線與程式碼庫重構

內建工具被設計來組合使用。CCA-F 考試中最重要的組合是 Glob → Read → Edit 流水線，這是自主程式碼庫重構的標準形態。

標準重構流水線

1. Glob — 列舉可能受影響的檔案。範例：**/*.ts，列出儲存庫下所有 TypeScript 檔案。
2. Grep（選用）— 將清單縮小到內容中確實提及被重構符號的檔案。這能避免讀取無關檔案，讓 context 保持可控。
3. Read — 載入每個候選檔案的內容（通常帶有圍繞匹配點的行範圍），讓 Claude 能推理周圍的程式碼。
4. Edit — 對每個受影響的區域套用精準修改。

為什麼流水線優於單體 Bash

一個簡單粗暴的替代方案是一個 Bash 呼叫：find . -name '*.ts' -exec sed -i 's/oldName/newName/g' {} +。這在掛鐘時間上更快，但有以下問題：

• Claude 沒有機會檢視候選出現的地方。
• 它無法區分有效的改名目標和誤判（例如，出現在註解或字串字面值中的情況）。
• 它繞過了專用工具呼叫所建立的稽核軌跡。

流水線版本耗時更長，但更安全、可觀測且精準度更高——這正是生產 agent 真正需要的，也是 CCA-F 所獎勵的。

流水線內的並行 Read

現代 Claude 模型在工具呼叫彼此獨立時，會積極地並行化。若一次重構需要讀取五個候選檔案，Claude 通常會在一條 assistant 訊息中發出五個 Read tool_use 區塊。對應的 user 訊息必須包含五個匹配的 tool_result 區塊。把這些讀取串列化成五個獨立輪次的實作，既浪費延遲，也違反標準模式。這直接連結到任務說明 1.1（agentic loop 設計），也說明了為什麼這兩個任務常常一起被測驗。

Grep 優先 vs Glob 優先

當目標集合很大（大型 monorepo 中的所有 .ts 檔案：數千個），以 Grep 開頭往往比以 Glob 開頭更好——Grep 的輸出已縮小到實際包含該符號的檔案，而且 Grep 能包含匹配行號，讓後續 Read 呼叫可以用 offset/limit 只載入相關的窗口。當目標集合很小（某個目錄中的一批設定檔），Glob 優先更簡潔。考試獎勵將順序與工作集合規模相匹配的做法。

效能考量 — Bash 做批次操作、Grep 做搜尋、Read 做精準載入

內建工具有不同的效能特性，為操作規模選錯工具是常見的考試陷阱。

Read — 精準、小規模載入

Read 被設計用來載入單一檔案的有限範圍。載入一個檔案的 200 行很便宜；在一次 Read 呼叫中載入 50,000 行的檔案既昂貴又污染 context。對大型檔案使用 Read 時，務必帶上 offset 和 limit。若要逐一掃描 repo 中的每個檔案，Read 是錯誤的工具——正確模式是先用 Glob（或 Grep）縮小範圍，再對少數候選用 Read 載入。

Grep — 批次內容搜尋

Grep 被優化用來掃描多個檔案的內容。對整個儲存庫做一次 Grep 呼叫，遠比用 Read 逐一讀取每個檔案再在 context 內搜尋更高效。「找出包含 X 的檔案」這類操作，Grep 不只是語義上的正確選擇，也是效能上的正確選擇。

Glob — 批次路徑探索

Glob 被優化用來快速回傳符合的檔案路徑清單。對一個擁有 10,000 個檔案的 repo 問 Glob 所有 .ts 檔案是輕而易舉的；要 Read 透過遍歷目錄來列出檔案是不可能的（Read 不是目錄工具）。

Bash — 沒有專用工具的批次操作

Bash 是批次操作沒有專用等效工具時的正確選擇——執行整個測試套件、安裝 200 個依賴套件、呼叫程式碼生成器。當批次操作本身就是「搜尋內容」或「依模式列出檔案」時，Grep 或 Glob 才是正確答案，Bash 是錯的。

規模何時翻轉答案

兩個工作集合規模改變正確工具的例子：

• 讀取一個檔案 → Read。讀取一千個檔案 → 通常先用 Grep 縮小，再選擇性地 Read。
• 修改一行 → Edit。在數百個檔案中修改相同的一行 → 緊湊的 Glob → Read → Edit 流水線，或在受限情況下用一個帶有人工 review 的 Bash 命令。以 Edit 為核心的流水線是 CCA-F 的預設答案，因為它保留了可稽核性。

安全與破壞性操作 — 在執行 Write/Bash 前確認意圖

六個內建工具中，有三個可以改變或破壞狀態：Write、Edit 和 Bash。生產 agent 必須以比唯讀工具更謹慎的態度對待它們的執行。CCA-F 情境題測驗考生是否將這份謹慎設計進 agent 的 loop 中。

三個可變更狀態的工具及其爆炸半徑

• Write — 完整覆寫檔案。在檔案系統層面不可恢復，除非版本控制能攔截。
• Edit — 就地修改。爆炸半徑較窄（一個前後替換），但在版本控制之外仍不可恢復。
• Bash — 任意命令。爆炸半徑是 shell 能觸及的一切——檔案系統、網路、衍生的行程。

權限與 Allowlist

Claude Code 允許設定宣告哪些工具在特定 context 中被許可，以及對 Bash 而言，哪些命令模式被許可。在 CI pipeline 中執行的 agent，可能允許自由使用 Read/Grep/Glob，要求對 Write/Edit 明確核准，並將 Bash 限制在 npm test、npm run build、git status 等 allowlist 中。這個模式——分層權限模型——是 Anthropic 為自主 agent 推薦的預設設計。

破壞性動作的人工確認關卡

對於爆炸半徑超出自動回滾能力的操作——生產資料庫寫入、破壞性 shell 命令、部署到生產基礎設施——agent 應在執行前暫停並請求人工核准。這連結到 plan mode（任務說明 3.4）和人工 review 工作流程（任務說明 5.5），但也是 built-in tool 的考量，因為機械上的暫停就是在 Write/Edit/Bash 呼叫即將觸發時插入的。

試跑與 Plan Mode

Plan mode（任務說明 3.4）讓 agent 提出它打算做的事——哪些 Write 呼叫、哪些 Edit 呼叫、哪些 Bash 調用——但不實際執行。使用者核准計畫後，才開始執行。Plan mode 不是自動更安全的選擇（它增加延遲且會中斷非互動式 pipeline），但對於涉及多個檔案的破壞性重構，它是正確的預設。

在 CI/CD 非互動模式中使用內建工具

claude-code-for-continuous-integration 情境，把內建工具帶進沒有人類監視的自動化 pipeline。工具選用規則不變，但安全姿態需要調整。

透過 -p 旗標進行非互動式執行

當 Claude Code 在 CI 環境中執行（GitHub Actions、GitLab CI、Buildkite），它以非互動模式被呼叫（通常帶有 -p 旗標）。Agent 無法暫停等待人工核准。因此，allowlist 模型成為主要的安全機制：agent 被允許執行的每個 Bash 命令模式都必須事先宣告；任何超出 allowlist 的命令都會中止執行。

唯讀檢查工作

許多 CI 工作是唯讀的：lint 檢查、安全掃描、依賴套件稽核。對這些工作而言，只允許 Read、Grep 和 Glob——拒絕 Write、Edit、Bash——的 agent 設定是合適的。這個窄權限集本身就是安全特性：即使 agent 行為異常，它也無法改變程式碼庫。

程式碼生成 CI 工作

重新生成程式碼產物的工作（從 .proto 檔案執行 codegen、更新生成的 SDK）合理地需要 Write，偶爾也需要 Edit。Bash 通常也需要，用來呼叫程式碼生成器本身。每個可變更狀態的工具的範圍都應縮窄（Write 只允許在 generated/ 目錄下，Bash 只允許特定的 codegen 命令）。

部署工作

部署到生產的工作幾乎絕對不應自由使用 Bash。典型模式是只允許精確的部署命令（例如 kubectl apply -f deploy.yaml），其他一概不許。非互動式 CI 中沒有 plan mode，因此 allowlist 是主要的控制手段。

可觀測性 — 記錄內建工具呼叫

每個內建工具呼叫都是一個結構化事件，生產 agent 應加以記錄。最低記錄面向：

• 工具名稱 — Read、Write、Edit、Bash、Grep、Glob。
• 輸入參數 — file_path、pattern、command 等。對 Bash，記錄完整命令字串；對 Edit，記錄 old_string / new_string 配對（或至少是它們的長度，若程式碼具隱私敏感性）。
• 時間戳與耗時 — 呼叫觸發的時間與所花的時間。
• is_error — 工具是否回報失敗。
• 結果預覽 — 回傳值的截斷快照，供稽核使用。

Agent SDK 的 PreToolUse 和 PostToolUse hook（任務說明 1.5）是附加這類日誌的乾淨位置。在 Claude Code 中，設定層級的日誌記錄處理相同的工作。可觀測性本身不是 built-in tool 的概念，但任何關於內建工具選用的 CCA-F 答案，若不承認所選工具的呼叫必須可稽核，都不算完整。

白話說明

一旦將六個工具錨定在以相同方式分離職責的具體情境上，工具選用就會變得直觀。以下三個類比覆蓋了全部的面向。

類比一：廚房刀具組 — 每個工具一項任務

想像一個整齊的廚師工作台。台上擺著六樣特定工具：放大鏡（Read）、鋼印戳記（Write）、雕刻刀（Edit）、瓦斯噴槍（Bash）、食材索引冊（Grep）和配料抽屜找尋器（Glob）。有經驗的廚師不會用噴槍去寫標籤、不會用雕刻刀從無到有做出一個新盤子、也不會用放大鏡去翻抽屜。每個工具的存在，正是因為其他工具做這件事要嘛太危險、要嘛大材小用。當學徒問「師傅，這個食材放在哪個抽屜？」，師傅拿的是抽屜找尋器，不是噴槍。當師傅想查食材索引冊裡某道料理的配方，他拿的是放大鏡，不是索引冊本身。瓦斯噴槍什麼都能做——只要加夠多配件——但有經驗的廚師只有在沒有更專門的工具時才拿它。這正是 CCA-F 的選用規則：先拿專用工具；只有沒有其他東西適合時，才拿 Bash。

類比二：圖書館目錄系統 — 路徑 vs 內容是根本的分離

走進一間研究型圖書館。這裡有兩套截然不同的查詢系統。一套目錄依書名和館藏編號索引書籍——這是 Glob。另一套目錄依書籍內部的關鍵詞索引書籍——這是 Grep。如果你問館員「你們有一本叫《演算法導論》的書嗎？」，他們帶你去書名目錄（Glob）。如果你問「哪些書討論了 Dijkstra 演算法？」，他們帶你去內容目錄（Grep）。這兩套系統不可互換。書名搜尋無法告訴你一本書裡面寫了什麼；內容搜尋無法列出所有存在的書。新手研究者常常搞混兩者，在書名目錄裡搜尋「Dijkstra 演算法」卻一無所獲——因為沒有書是以那個詞語命名的，即使有幾十本書包含它。CCA-F 考生搞混 Grep 和 Glob，犯的是完全相同的錯誤。Grep 讀的是內容；Glob 讀的是書脊。

類比三：夜市攤位改良 — Edit vs Write 是關於保留已有的東西

一個夜市老闆改良滷肉飯的配方時有兩個選擇。選項 A：嘗一口，覺得要再加一點五香粉，就加進去攪拌（這是 Edit——小幅度、精準，保留其餘所有調味）。選項 B：把整鍋滷汁倒掉，從零開始重新熬一鍋（這是 Write——刻意的完整替換）。選項 B 有時是對的——若整鍋真的壞掉了，無法挽救，你就重新來過。但為了加一撮五香粉就選選項 B，是在冒險：你必須憑記憶重現整個配方，任何一點差錯——某個香料忘了、比例抓錯——都會悄悄毀掉整鍋滷汁。修改檔案時也是同樣的道理。你要改一個函式，就不用重寫整個檔案；你用 Edit。你要產生一個過去不存在的全新設定檔，你用 Write。CCA-F 情境題測的正是這個直覺：考生知道保留已有的東西，比重新輸出它更安全嗎？

考試當天選用哪個類比

• 關於應選哪個內建工具的題目 → 廚房刀具組類比。
• 關於 Grep vs Glob 的題目 → 圖書館目錄系統類比。
• 關於 Edit vs Write 的題目 → 夜市攤位改良類比。

常見考試陷阱

CCA-F 任務說明 2.5 持續圍繞六種關於內建工具選用的陷阱模式出題。全部六種都有社群通過報告記錄在案，並以合理的干擾選項形式出現。

陷阱一：用 Write 修改現有檔案

出現頻率最高的陷阱。情境描述更新、改名、替換或插入現有檔案中的內容，而四個選項之一是「Write 檔案並帶入新內容」。對現有檔案的任何修改，Write 都是錯的。Edit 才是答案。

陷阱二：在有專用工具的情況下使用 Bash

情境提供「用 Bash cat 該檔案」或「用 Bash find 列出檔案」或「用 Bash grep 搜尋內容」等看似合理的選項。當有 Read、Glob 或 Grep 可用於該操作時，Bash 就是錯的——不是因為它做不到，而是因為它無謂地擴大了爆炸半徑。有專用工具時永遠優先選專用工具。

陷阱三：對調 Grep 和 Glob

Grep 搜尋內容，Glob 搜尋路徑。情境題刻意把一個內容形式的問題（「找出每個 import 了 legacy_auth 的檔案」）配上 Glob 作為干擾選項，或把路徑形式的問題（「列出每個 .proto 檔案」）配上 Grep 作為干擾選項。先讀問題中的動詞（提及、包含、import → Grep）或模式形態（*.ts、**/*.py → Glob），再作選擇。

陷阱四：把 Edit 當成建立新檔案的工具

Edit 要求檔案必須已存在。情境偶爾會對全新的檔案（建立新測試、產生新設定）提供 Edit 作為選項。對尚不存在的檔案，Edit 會失敗，因為沒有 old_string 可以匹配。建立全新檔案的正確工具是 Write。

陷阱五：跳過流水線改用單體 Bash 命令

對於跨檔案重構，考試獎勵 Glob → Read → Edit 流水線，而非一個 sed -i 的 Bash 呼叫。即使 Bash 的一行指令更簡短，它的可觀測性更差、更不安全、精準度更低。把重構框架為「一個 Bash 呼叫搞定全部」的情境答案，幾乎總是錯的，專用工具流水線才對。

陷阱六：對大型檔案的 Read 呼叫省略 Offset 和 Limit

在一次不帶 offset/limit 的 Read 呼叫中讀取 50,000 行的日誌檔，會淹沒 context window，通常也讓後續任務失敗。正確的做法是在 Read 呼叫中帶上 offset/limit（或先用 Grep 確認感興趣的行號）。即使 Read 的工具類別是對的，對大型檔案做無邊界 Read 的答案也會被視為不正確的設計。

練習錨點

內建工具選用題在 CCA-F 六個情境中的兩個最為集中。以下是架構骨幹。

Developer-Productivity-With-Claude 情境

這個情境的核心前提是：開發者使用 Claude 驅動的 agent 在大型程式碼庫上工作——bug 調查、多檔案重構、測試撰寫、文件更新。內建工具是 agent 與程式碼庫之間的主要介面，幾乎每道題目都測驗其中一個。預期會有題目測試：

• Glob → Read → Edit 重構流水線。
• Grep vs Glob 選用（找符號的用途 vs 依路徑模式列出檔案）。
• Edit vs Write 選用（修改現有函式 vs 建立新測試檔案）。
• Bash 保留給建置/測試呼叫，不用於讀取檔案或搜尋。
• 大型檔案使用帶有 offset/limit 的 Read，而非無邊界讀取。

Claude-Code-For-Continuous-Integration 情境

這個情境把內建工具帶進自動化非互動式 context。選用規則相同，但安全姿態轉移到 allowlist 和窄權限範圍。預期會有題目測試：

• CI 中的工具權限範圍設定（agent 被允許使用哪些工具）。
• Bash allowlist 設計（被允許的精確命令模式）。
• 何時允許 Write/Edit（僅限 codegen 工作）vs 拒絕（僅限 lint 工作）。
• CI 呼叫的 -p 非互動式旗標，搭配內建工具設定。
• 偵測並拒絕 allowlist 之外的破壞性 Bash 呼叫。

情境出題者有時會交叉引用兩個情境：由 CI 觸發的重構仍使用相同的工具，但權限集比開發者互動式 session 更窄。

FAQ — 內建工具前六大問題

如何決定對一個檔案修改用 Edit 還是 Write？

只要檔案已存在且操作是修改其中一部分，就使用 Edit。只有全新檔案或刻意的完整替換才用 Write。Edit 更安全，因為它只送出前後片段，並在檔案系統層面保留其餘內容——Claude 不需要重新輸出它不打算修改的行。對現有檔案用 Write，會強迫 Claude 重現每一行，任何被遺漏或改寫的行都會靜默消失。CCA-F 將「對修改操作使用 Edit」視為正確答案，「對修改操作使用 Write」是刻意放置的干擾選項。

Grep 和 Glob 在考試中有什麼差異？

Grep 搜尋檔案的內容，尋找模式；Glob 搜尋檔案的路徑，尋找模式。這個邊界是 Grep/Glob 配對中被測驗最多的區別。典型的 Grep 提示聽起來像「找出每個提及、import 或包含 X 的檔案」——動詞指向檔案內部。典型的 Glob 提示聽起來像「列出每個名為 *.ts 的檔案」或「找出 src/ 下的所有檔案」——動詞指向路徑。對路徑形式的問題用 Grep，或對內容形式的問題用 Glob，無論模式怎麼寫都是錯的。

什麼情況下應該用 Bash 而不是專用工具？

當操作本質上就是 shell 命令且沒有專用等效工具時，用 Bash——執行建置、執行測試套件、呼叫套件管理器、驅動 jq 這樣的一次性工具。對已有專用工具的操作，絕對不要用 Bash。cat file.txt 是 Read；echo > file.txt 是 Write；sed -i 是 Edit；grep 是 Grep；find 是 Glob。選 Bash 而放棄專用工具，會把爆炸半徑擴大到任意 shell，削弱可觀測性（意圖被埋在 shell 字串裡），在考試上被視為工具選用不當。

如果傳入正確的 old_string 和 new_string，Edit 能建立新檔案嗎？

不行。Edit 要求檔案必須已存在。對不存在的檔案，沒有 old_string 可以匹配，所以呼叫在任何替換邏輯運行之前就失敗了。建立全新檔案的正確工具是 Write。CCA-F 情境題偶爾會把 Edit 提供為建立全新檔案的干擾選項——這個邊界（Edit 改，Write 建）是刻意設置的考試關卡。

為什麼跨檔案搜尋時 Read 比 Grep 更慢或更昂貴？

Read 將特定檔案的完整指定範圍載入 context。用 Read「搜尋」多個檔案，意味著逐一完整讀取每個檔案，讓 Claude 在 context 中推理內容。這在延遲和 context 壓力上都很昂貴。Grep 執行快速的檔案系統層級掃描，只回傳匹配行，然後讓 agent 針對特定的匹配窗口，帶著 offset/limit 做後續 Read 呼叫。對「哪些檔案包含 X」的問題，Grep 是正確的工具；Read 是在搜尋完成後，用來載入已知檔案的已知範圍的工具。

在生產 agent 中，Write、Edit 和 Bash 呼叫應附加哪些安全措施？

三個層次。第一，一個權限 allowlist，宣告 agent 在當前 context 中可以使用哪些工具——例如，僅做 lint 的 CI 工作可能只允許 Read/Grep/Glob。第二，對 Bash，一個精確命令模式的 allowlist（例如 npm test、npm run build），讓任意 shell 無法執行。第三，對破壞性或高風險的操作，在執行前設置人工核准關卡——在互動式 session 中透過 plan mode 實現，在 SDK 驅動的 agent 中透過明確的核准請求實現。CCA-F 答案中，將工具能力與這些安全控制結合的，優先於單純依賴 Claude 自我約束的。

內建工具如何與 agentic loop 的 stop_reason 互動？

每個內建工具調用都位於 Claude 發出的 tool_use 區塊內，伴隨 stop_reason: "tool_use"。agentic loop 執行工具（Read 載入檔案、Bash 執行命令等），將輸出包裹在帶有對應 tool_use_id 的 tool_result 區塊中，並以 user 訊息的形式附加到對話。迴圈持續，直到 Claude 發出 stop_reason: "end_turn" 或 guard 觸發。這意味著內建工具選用在機制上與任務說明 1.1 緊密耦合：在錯誤位置選了錯誤工具（在該用 Edit 時用 Write）的 agent，仍然遵循相同的迴圈結構，但語義結果是錯的。考試在同一個情境中同時測驗兩個維度——正確的迴圈形態與正確的工具選擇。

延伸閱讀

• Tool reference — Anthropic-provided built-in tools: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/tool-reference
• Claude Code features overview: https://docs.anthropic.com/en/docs/claude-code/overview
• Agent SDK overview: https://docs.anthropic.com/en/docs/claude-code/sdk/sdk-overview
• Tool use with Claude — overview and agentic loop: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/overview
• Writing tools for agents — Anthropic Engineering Blog: https://www.anthropic.com/engineering/writing-tools-for-agents

Related ExamHub topics: 工具介面設計——描述與邊界、MCP Server 與 Claude Code 整合、CLAUDE.md 檔案——層級、範圍與模組化組織、大型程式碼庫探索中的 Context 管理。