工具介面設計 — 清晰描述與邊界

Tool Interface Design 是 Claude Certified Architect — Foundations（CCA-F）考試 Domain 2 中被考最深的主題。任務說明 2.1——「設計具備清晰 description 與 boundary 的有效 tool interface」——在 Domain 內佔比 18%，熱度評分 0.73，原因在於整個客服情境（Customer Support Resolution Agent）的核心，就在於架構師是否理解：Tool Interface Design 不是寫 schema 的練習，而是一個路由練習。最具代表性的樣題，把 analyze_content 和 analyze_document 這兩個只有骨架 description 的工具並列，要求考生找出誤路由的修法；錯誤答案都集中在「加 few-shot examples」或「合併兩個工具」，正確答案永遠是「擴充 description 並加入明確的 boundary」。如果你把 Tool Interface Design 看錯，你就等於看錯了 Domain 2 的一半，以及 Domain 1 的一大塊。

這份學習筆記完整涵蓋 CCA-F 考生需要掌握的 Tool Interface Design 面向：tool schema（name、description、input_schema）如何分解成選擇訊號、description 欄位為何是 LLM 進行 tool selection 的主要機制、「purpose-specific」的意義以及為何把泛用工具拆成有明確 input/output contract 的 purpose-specific tool 優於合併、如何透過重新命名（analyze_content → extract_web_results 模式）消除重疊、系統提示的關鍵字靈敏度何時能覆蓋 tool description，以及讓 893/1000 通過者和 650/1000 落榜者產生差距的精確考試陷阱。每個章節都以客服情境為錨，因為那正是 minimal description 在考試當天造成最戲劇性 Tool Interface Design 失敗的地方。

為何 Tool Interface Design 重要 — Description 驅動選擇

Claude 看工具的方式，和你在 IDE 裡看到的完全不同。它看到的是一份扁平的 JSON 物件清單——每個物件有 name、description 和 input_schema——在每一輪的開頭插入系統上下文中。當 Claude 的 agentic loop 產出 stop_reason: "tool_use" 時，究竟呼叫哪個工具，幾乎完全取決於將使用者意圖對比每個已註冊工具的 description 文字所做的模式比對。Tool Interface Design 因此是一門寫作的學問：在情境模糊或提示漂移的情況下，仍能讓 description 明確地把 Claude 引導到正確的工具。

CCA-F 考試指南明確將「tool description 作為路由機制」列為基礎能力，社群通過報告（Kishor Kukreja，893/1000；Rick Hightower，985/1000）也一致指出 description 品質是 Domain 2 題目中影響最大的單一槓桿。如果兩個工具的 description 有重疊，Claude 就靠猜。如果某個工具的 description 比另一個模糊，Claude 會路由到較具體的那個，即使那個是錯的。Tool Interface Design 不是門面工程——它是方向盤。

三欄位 Tool Schema

無論是直接 API 還是 MCP 代管，每個 Claude 工具定義都分解為三個帶有選擇權重的欄位：

1. name — 簡短識別符（snake_case）。用於工具呼叫和日誌記錄。當 description 薄弱時，對選擇的貢獻微弱。
2. description — 大約 100–500 個 token 的自然語言字串。主導性的選擇訊號。必須包含用途、輸入、輸出、範例與 boundary。
3. input_schema — 描述必要與選填參數的 JSON Schema。限制的是工具如何被呼叫，而非是否被選中。

CCA-F 考試測驗的，是考生是否理解這三個欄位的非對稱權重。一個寫得好的 description 可以彌補一個弱 name；一個完美的 input_schema 卻無法彌補一個弱 description。

為何任務說明中會出現「清晰 Boundary」

Domain 2.1 的措辭是「設計具備清晰 description 與 boundary 的有效 tool interface」——兩個名詞，不是一個。Description 告訴 Claude 工具能做什麼；boundary 告訴 Claude 工具不做什麼。一個名為 analyze_content 且說明只有「analyzes content」的客服工具，有 description 但沒有 boundary。加上「僅在 search_web 回傳的網頁搜尋結果上使用此工具。請勿用於客戶上傳的文件——改用 analyze_document。」就引入了一個 boundary，並消除了樣題中不斷出現的誤路由問題。

客服情境 — Minimal Description 的失效之處

客服問題解決 Agent（Customer Support Resolution Agent）是 CCA-F 六大考試情境之一，也是 Tool Interface Design 失效最典型的舞台。這個情境通常呈現一個連接了數個工具的 agent：

• search_knowledge_base — 擷取內部政策與 FAQ 文章。
• search_web — 搜尋公開網路上的外部資訊。
• analyze_content — description 簡短為「analyzes content」。
• analyze_document — description 簡短為「analyzes a document」。
• create_ticket — 升級至人工客服。

當客戶問「你能查一下最近 Anthropic 使用政策有什麼改變嗎？」，Claude 正確地呼叫 search_web，取得網頁結果，然後必須在 analyze_content 與 analyze_document 之間選一個來擷取答案。由於兩個工具都只有一行 description，Claude 只能靠猜。有一半的嘗試，它會選 analyze_document，即使輸入是網頁搜尋結果而非文件——工具要麼靜默失敗，要麼因為 input schema 不匹配而回傳格式錯誤的輸出。

Minimal Description 的失效模式

一個 minimal description 長這樣：

{
  "name": "analyze_content",
  "description": "Analyzes content.",
  "input_schema": { ... }
}

Claude 看到的是「一個對內容做某些事的工具」。當兄弟工具 analyze_document 有著同樣簡略的 description，Claude 就沒有原則性的方式區分兩者。選擇變成一場擲硬幣，偏向哪個工具取決於使用者最新訊息中哪個名稱最符合表面關鍵字——訊息中出現「document」，就會把 Claude 往 analyze_document 推，即使實際流入的資料是網頁搜尋結果。

擴充 Description 的修法

擴充後的版本，將用途、輸入、輸出、範例與明確的 boundary 都編碼進去：

{
  "name": "extract_web_results",
  "description": "Extracts structured information from web search results returned by search_web. Accepts an array of SearchResult objects (title, url, snippet). Returns a summary paragraph plus a list of cited URLs. Use this tool whenever you need to synthesize information from the public web. Do NOT use this tool for customer-uploaded documents — use analyze_document for that purpose.",
  "input_schema": { ... }
}

兩個改進相互疊加。第一，工具名稱從 analyze_content 改為 extract_web_results，消除了與 analyze_document 的關鍵字重疊。第二，description 現在編碼了工具接收什麼、產出什麼、何時使用，以及——最重要的——何時不使用。

Tool Description 作為主要選擇機制

四個訊號，一個主導

Claude 選擇工具時，有四個訊號相互競爭：

1. Description 文字（主導）——最豐富的用途與範疇自然語言描述。
2. 工具名稱（次要）——弱關鍵字訊號；當 description 相似時有輔助作用。
3. Input schema（第三）——排除其必要參數在當前上下文中無法填入的工具。
4. 系統提示提示（條件性）——可以偏置選擇，但無法覆蓋一個有明確 boundary 的 description。

CCA-F 考試測驗的是考生是否理解這個排名。認為「在系統提示加更多指令」是誤路由解法的考生，會在客服情境上失分。改寫 description 的考生才能通過。

Description 品質評估準則

生產等級的 tool description 滿足全部六項標準：

• 用途說明 — 一句話描述工具的功能。
• Input contract — 工具預期的資料，依類型與來源說明。
• Output contract — 工具回傳的內容，依結構說明。
• 正面範例 — 1–2 個調用範例（「當使用者詢問 X 時使用」）。
• 負面 boundary — 明確的「不適用於 Y；請改用 Z」。
• 邊緣案例備注 — 錯誤條件、速率限制、前置狀態。

遺漏 boundary 是最常見的失效模式；試圖用單一範例取代 boundary 是第二常見的失效模式。

Purpose-Specific Tool vs 泛用工具

拆分 vs 合併的決策

直覺上，工具數量越少或許越好——認知負擔低、agent 設定更簡單。CCA-F 考試會懲罰這種直覺。當兩個工具在用途上有重疊，正確的架構決策是將它們拆分成有更窄、不重疊 description 的 purpose-specific tool，而不是合併成一個涵蓋所有行為的泛用工具。

為什麼？一個名為 analyze 且 description 說「analyzes web results, documents, images, and emails」的合併工具，迫使 Claude 從上下文推斷輸入類型，然後在工具內部做分支。Claude 無法可靠地做到這一點，因為分支發生在工具選擇之後，在工具實作內部——Claude 的選擇機制只在工具之間的邊界運作，不在工具內部運作。

重命名以消除歧義的模式

拆分的配套模式是重命名工具以消除關鍵字重疊。CCA-F 樣題中的經典範例：

• 之前：analyze_content + analyze_document（都以 analyze_ 開頭，都聲稱「analyze」）
• 之後：extract_web_results + parse_customer_document（沒有共同前綴，沒有共同動詞）

重命名操作不是門面工程——它移除了在 description 薄弱時把 Claude 往錯誤工具推的偶發性 token 重疊。配合擴充後的 description，「重命名＋描述」模式是 CCA-F 針對誤路由情境的標準答案。

Input 與 Output Contract

Input Schema 作為約束

input_schema 是 JSON Schema。它的工作是告訴 Claude 哪些參數是必要的、哪些是選填的、它們的類型、enum 約束和值域。設計良好的 input schema 具備：

• 只有工具真正需要的欄位（沒有廚房水槽式的參數）。
• 有意義的必要 vs 選填區分。
• 有封閉集合的地方使用 enum 值（例如 priority: "low" | "medium" | "high"）。
• 巢狀欄位上有 description，不只是頂層物件。

緊湊的 input schema 作為次要選擇訊號：如果某個工具需要 search_query_id 參數，而當前上下文沒有這個 ID，Claude 會降低對那個工具的優先順序，即使 description 看起來符合。

Output 形狀作為交接 Contract

同樣重要的是 output 形狀。回傳 { "result": "..." } 的工具，與回傳 { "summary": "...", "citations": [...], "confidence": 0.87 } 的工具，創造的下游可能性截然不同。第二種形式讓協調 agent 能做出結構化決策（「如果 confidence < 0.7，呼叫 create_ticket」），而第一種迫使協調者重新解析非結構化文字。

對於 MCP 工具，回應封裝中還帶有 isError、errorCategory 和 isRetryable 欄位——涵蓋於配套主題「MCP Tools 的結構化錯誤回應」中——它們是 output contract 的一部分，即使它們位於面向使用者的 content 之外。

Boundary 定義 — 工具「不做什麼」

三段式 Boundary 子句

生產等級的 boundary 子句有三個部分：

1. 正面範疇 — 「在[條件 X 成立時]使用此工具。」
2. 負面範疇 — 「在[條件 Y 成立時]請勿使用此工具。」
3. 重導 — 「對於[條件 Y]，改用[其他工具名稱]。」

應用於客服情境的範例：

處理 search_web 的輸出時使用 extract_web_results。不適用於客戶上傳的檔案——請改用 parse_customer_document。

就這一句話，消除了 minimal description 版本中的誤路由失效模式。

跨工具家族的 Boundary

Boundary 應在可能被混淆的工具之間成對撰寫。create_ticket 和 extract_web_results 之間不需要 boundary 子句，因為沒有合理的使用者意圖會路由到兩者。但 analyze_document 和 extract_web_results 之間絕對需要，因為兩者都消耗文字、都產出摘要。

系統提示的關鍵字靈敏度與 Tool Description

系統提示何時偏置選擇

如果系統提示說「你是一個文件分析 agent」，而使用者問了一個一般性問題，Claude 會被偏向 description 中提到「document」的工具——即使使用者的真實意圖是網頁搜尋。這種關鍵字靈敏度，正是為何在 tool description 薄弱時必須謹慎撰寫系統提示。

但修法不是從系統提示中移除關鍵字——修法是強化 tool description，讓工具之間的 boundary 對系統提示引發的偏置具有足夠的抵抗力。

Description 優先原則

在 CCA-F 考試情境中，正確的診斷順序是：

1. 首先，檢查 tool description。它們是 minimal 的嗎？有重疊嗎？有說明 boundary 嗎？
2. 只有在 description 已達生產等級的情況下，才檢查系統提示是否有關鍵字偏置。
3. 只有在兩者都正確的情況下，才考慮 tool_choice 覆蓋。

顛倒這個順序——先怪系統提示——的考生，在誤路由題目上始終選錯答案。

白話說明 Tool Interface Design

抽象的 schema 討論，一旦錨定在具體類比上就會豁然開朗。以下三個類比涵蓋了 Tool Interface Design 的完整面貌。

類比一：工具箱與貼標籤的格層

想像一位木工師傅的工具箱。裡面的工具——槌子、螺絲起子、扳手、鑿子——只有在師傅能快速在壓力下挑出正確工具時才有用。如果每個格層都只貼著「工具」，師傅就得一個個開來找。如果標籤寫「槌子——打釘用，不適合鎖螺絲——鎖螺絲請用螺絲起子」，師傅每次都能選對，即使在昏暗的光線下也一樣。

Claude 的 tool registry 運作方式完全相同。description 欄位就是格層上的標籤。Minimal description（「analyzes content」）是貼著「工具」的格層——沒用。有 boundary 的 description（「從網頁搜尋結果擷取結構化資料；不適用於客戶上傳的檔案——那些請用 parse_customer_document」）是貼著「槌子——打釘用，不鎖螺絲」的格層——清晰無歧義。

這個類比對應了每個 Tool Interface Design 概念：

• 工具名稱 是格層正面的短貼紙。
• tool description 是下方的完整標籤。
• tool boundary 是標籤上的「不適用於...」附注。
• purpose-specific tool 是單一用途的格層（每格一用，不是「所有緊固件都塞一格」）。
• input/output contract 是格層形狀的匹配——扳手塞不進螺絲起子格。

類比二：急診室的分診台

醫院急診室有多位專科醫師——心臟科、骨科、神經科、小兒科。門口的分診護理師將每位進來的病患導到正確的專科。如果護理師的路由目錄寫著「王醫師看病人」和「李醫師看病人」（minimal description），護理師只能靠猜，病患就會被送錯。如果目錄寫著「王醫師看胸痛、呼吸困難與心血管急症；不收小兒或骨科案例——那些去找李醫師或陳醫師」，護理師就能正確分診。

Claude 是分診護理師。每個工具是專科醫師。Tool description 是路由目錄。目錄中沒有明確 boundary，護理師（Claude）就無法可靠地分診。有了 boundary——「這個情況用這位專科；不是那個情況；那個情況用那位專科」——即使是邊緣案例，路由也會變得確定性十足。

這個類比特別有助於理解為何合併是錯的。把心臟科和骨科合併成「一般科」，對分診護理師沒有幫助——它迫使那位一般科醫師在內部重新分診，而這正是 agentic system 無法可靠做到的事。

類比三：大學圖書館的專科參考館員

一間大型學術圖書館有多位各有專業的參考館員——理工、人文、善本書、數位典藏。讀者走到服務台提問。服務台有每位館員的說明卡片，寫著他們負責的範圍。

如果卡片只寫「參考館員」（minimal description），讀者（或負責引導讀者的初階助理）只能靠猜。如果卡片寫「善本書館員——處理 1900 年以前的印刷品與手稿；不處理純數位來源——請洽數位典藏館員」，路由就清晰無疑。

注意擴充後的卡片做了什麼：給出正面範疇（「1900 年以前的印刷品」）、負面範疇（「非純數位」），以及重導（「請洽數位典藏館員」）。這正是 Claude tool description 的三段式 boundary 子句模式。

考試當天選用哪個類比

• 關於 tool description 品質與 boundary 的題目 → 工具箱類比。
• 關於路由歧義與誤選的題目 → 急診分診類比。
• 關於 purpose-specific vs 泛用工具，以及重命名消除歧義模式的題目 → 圖書館參考館員類比。

Description vs Few-Shot 的陷阱 — Description 勝出

這是 CCA-F Domain 2 中被考最頻繁的陷阱，值得獨立成節。

情境呈現兩個工具之間的誤路由。四個答案選項：

• (A) 在系統提示中加 3–5 個 few-shot examples，示範代表性使用者查詢的正確工具選擇。
• (B) 擴充 tool description 以包含正面範疇、負面範疇與重導子句。
• (C) 將兩個工具合併成一個有內部分支邏輯的泛用工具。
• (D) 訓練一個小型分類器，在 Claude 看到請求之前先做路由。

正確答案是 (B)。為什麼？

• 系統提示中的 few-shot examples（A）是局部的且脆弱的。對範例中的情況有效，但遇到新措辭就退化。此外，每一輪都要消耗額外的 token。
• 擴充後的 description（B）是全局的——適用於每一輪、每種措辭、每個新情況。這也是 Anthropic 官方 tool-use 文件所認定的正確機制。
• 合併（C）讓問題更嚴重，迫使 Claude 在工具內部推斷輸入類型，而不是在選擇邊界上做。
• 外部分類器（D）引入新的失敗點，並完全繞過 agentic 架構。

Tool 粒度 — 可組合細粒度 vs 單體多功能

一個相關的架構決策是工具粒度。給定一組相關功能，你應該暴露一個帶有 mode 參數的大工具，還是多個各做一件事的小工具？

單體方法

一個工具，多種模式：

{
  "name": "analyze",
  "description": "Analyzes content. Pass mode: 'web' for web results, 'document' for documents, 'email' for emails.",
  "input_schema": {
    "type": "object",
    "properties": {
      "mode": { "enum": ["web", "document", "email"] },
      "content": { "type": "string" }
    }
  }
}

可組合方法

多個工具，每個對應一個用途：

[
  { "name": "extract_web_results", "description": "..." },
  { "name": "parse_customer_document", "description": "..." },
  { "name": "summarize_email_thread", "description": "..." }
]

在 CCA-F 中誰勝出？

可組合方法在大多數 CCA-F 情境中勝出，尤其是客服情境。原因：

• Purpose-specific tool 有更緊湊的 boundary 和更清晰的 description。
• Input/output contract 是每個工具獨立的，而非跨模式聯集的形狀。
• 選擇發生在工具邊界（Claude 的強項），而非工具內部（agent 的弱項）。

單體方法只在各模式共享真正相同的 input/output contract、僅差在一個無關緊要的設定旗標時才正確——在實務上這種情況很罕見。

Description 反模式

CCA-F 考試指南和 Anthropic 工程部落格都收斂到一份簡短的 description 反模式清單：

• 模糊動詞 — 「analyzes」、「processes」、「handles」。改用具體動詞：「extracts citations from」、「parses PDF headers of」、「summarizes thread replies」。
• 缺少範疇 — 「Analyzes content」但沒有說明是哪種內容。加入輸入類型與來源。
• 缺少前置條件 — 需要先前狀態的工具（例如必須先呼叫 search_web）卻未在 description 中說明。
• 沒有負面 boundary — Description 只說工具能做什麼，從不說不能做什麼。
• 過載的 description — 單一 description 試圖涵蓋三項任務；拆成三個工具。
• 複製貼上的 description — 兩個工具的 description 幾乎一模一樣，只差一個名詞。

這份清單上的每個反模式，都對應到客服情境中至少一個已記錄的失效模式。

上線前測試 Tool Description

生產等級的 Tool Interface Design 包含一個 description 測試步驟。常用方法：

• 選擇評估（Selection evals） — 整理使用者查詢配上預期工具名稱，透過帶有已註冊工具的 Claude 跑一遍，量測選擇準確率。
• Boundary 探針 — 設計坐落在兩個工具之間的邊界查詢，用來量測 boundary 子句是否夠強。
• 消融測試（Ablation testing） — 暫時移除某個工具的 description 欄位（從 boundary 開始移除），觀察準確率下降，找出哪些 description 元素承載最多權重。

CCA-F 不要求考生實作這些評估，但它確實獎勵認識到 description 品質是可評估的、而不只是美觀問題的考生。

常見考試陷阱 — Tool Interface Design

CCA-F 考試大量利用六種與 Tool Interface Design 相關、反覆出現的陷阱模式。把每一種都操練到反應直覺為止。

陷阱一：用 Few-Shot Examples 取代擴充 Description

上文已詳細說明。當誤路由情境出現，陷阱答案說「在系統提示加範例」。正確答案說「擴充 description」。

陷阱二：合併取代拆分

說「把兩個工具合併成一個帶有 mode 參數的工具」的答案選項，幾乎永遠是錯的。拆分是 CCA-F 的預設。

陷阱三：用 tool_choice 強制覆蓋選擇

說「使用 tool_choice: forced 繞過 Claude 的選擇判斷」的答案選項，除非情境明確要求確定性結構化輸出，否則是錯的。強制覆蓋繞開了選擇機制，等於承認 description 已經壞掉。

陷阱四：加更多工具而不是改善 Description

陷阱：「加一個路由工具，讓它選出正確的工具再呼叫」。這增加了間接層，卻沒有修正底層的 description 問題。正確答案仍然是修正現有工具的 description。

陷阱五：重命名但不擴充

一個微妙的陷阱：答案選項說「把 analyze_content 重命名為 extract_web_results」，但沒有同時擴充 description。光是重命名是不夠的——description 仍然承載著路由訊號。正確答案是重命名＋擴充同時進行。

陷阱六：把 Description 內容移進系統提示

說「把 tool description 的內容移進系統提示」的答案選項是錯的。Description 是 Claude 在選擇時才看到的每工具元資料；系統提示是會話層級的指令，偏置但不取代 description。

練習錨點 — Task 2.1 情境題

與 Tool Interface Design 相關的 CCA-F 練習題，集中在客服問題解決 Agent 情境，以及程度較輕的開發者生產力情境。

錨點 A：analyze_content vs analyze_document 誤路由

一個客服 agent 設定了 search_web、search_knowledge_base、analyze_content 和 analyze_document。使用者回報，當他們詢問最新的外部資訊時，agent 有時出現工具錯誤。調查顯示，Claude 偶爾在網頁搜尋結果上呼叫 analyze_document。最佳修法是什麼？

• (A) 在系統提示加 few-shot examples，將使用者查詢對應到工具。
• (B) 將 analyze_content 重命名為 extract_web_results，並擴充兩個 description 以包含明確的範疇、範例與「不適用於...」重導子句。
• (C) 將 analyze_content 和 analyze_document 合併成一個帶有 mode 參數的工具。
• (D) 在每次 search_web 呼叫後，強制 tool_choice 為 analyze_content。

正確答案：(B)。重命名消除關鍵字重疊；擴充後的 description 提供路由訊號；boundary 子句消除邊緣案例的誤路由。

錨點 B：開發者生產力 Agent 的 Minimal Description

一個程式碼助理 agent 有 read_file、write_file、search_code、analyze_code 等工具。使用者回報，當他們詢問「找出所有處理認證的地方」時，search_code 和 analyze_code 會被互換使用。根本原因是什麼？

正確答案：兩個 description 都缺少區分「尋找符合項目」（search_code）與「推理程式碼語義」（analyze_code）的 boundary 子句。 修法是在兩個 description 中加入範疇＋負面範疇＋重導子句。

錨點 C：合併情境

一個團隊提議用一個接受 source_type 參數的 ask_anything 工具，取代四個 purpose-specific tool（search_kb、search_web、extract_web_results、parse_customer_document）。考試層面上的批評是什麼？

正確答案：合併移除了每個工具的 input/output contract 和 description boundary，迫使 Claude 在工具內部做分支，而不是在工具邊界上選擇。原本的 purpose-specific 設計在架構上是正確的；合併是退步。

錨點 D：系統提示 vs Description 優先順序

一個團隊有誤路由 bug。他們提議（i）擴充 tool description 或（ii）調整系統提示的關鍵字提示。應先做哪一個，為什麼？

正確答案：先擴充 tool description。Description 是主要選擇訊號；系統提示是次要的。在不修 description 的情況下調整系統提示，只會產生脆弱的路由，遇到新的使用者措辭就失效。

錨點 E：撰寫 Boundary 子句

給定兩個用途重疊的工具，為第一個工具寫 boundary 子句。預期模式：

「在[正面範疇條件]時使用 <tool_a>。當[負面範疇條件]時，請勿使用 <tool_a>——改用 <tool_b>。」

能穩定產出這個三段式模式的考生，在 CCA-F Task 2.1 題目上的得分率一貫較高。

Tool Interface Design 常見問題

Claude tool 定義中，對 CCA-F 而言最重要的欄位是哪個？

description 欄位。它是 Claude 在已註冊工具之間做選擇時的主要選擇訊號。name 的貢獻很微弱；input_schema 限制工具如何被呼叫，而非是否被選中。CCA-F 明確測驗這三個欄位的非對稱權重——在 description 仍薄弱的情況下過度投資 input_schema 設計的考生，在 Domain 2 題目上始終答錯。

兩個工具誤路由時，應該在系統提示加 few-shot examples，還是擴充 tool description？

擴充 tool description。這是 CCA-F Domain 2 中出現頻率最高的陷阱。系統提示中的 few-shot examples 是脆弱的（遇到新措辭就失效）、耗 token（每輪都要付費），且沒有解決底層選擇機制。Tool description 才是選擇機制。正確的修法是改寫兩個 description，加入正面範疇、負面範疇與重導子句——通常還要重命名其中一個工具以消除關鍵字重疊。

什麼是「purpose-specific tool」，CCA-F 為何偏好它而不是泛用工具？

Purpose-specific tool 是 interface——name、description、input contract、output contract——緊密聚焦於單一明確任務的工具（例如，extract_web_results 只用於 search_web 的輸出）。CCA-F 偏好 purpose-specific tool，因為更窄的 boundary 讓 description 更乾淨、選擇更可靠、誤路由更少。analyze_content 這類泛用工具迫使 Claude 在工具內部而非在選擇邊界推斷輸入類型——而那是做這個決定的錯誤層次。

什麼是 tool boundary，如何撰寫？

Tool boundary 是 description 中明確的「不適用於」子句，告訴 Claude 工具的範疇限制，並在超出範疇時重導至兄弟工具。Boundary 分三段撰寫：正面範疇（「在 X 時使用此工具」）、負面範疇（「在 Y 時請勿使用此工具」），以及重導（「對於 Y，改用 tool_z」）。在可能被混淆的工具之間成對套用 boundary 子句。三段式模式是 CCA-F 消除誤路由的標準答案。

寫得好的系統提示能修正 tool description 薄弱造成的誤路由嗎？

不能。寫得好的系統提示可以偏置選擇，但無法在新措辭的情況下穩定地覆蓋薄弱的 description。CCA-F 考試獎勵 description 優先的診斷順序：先檢查 tool description，其次調整系統提示，最後才考慮 tool_choice 覆蓋。顛倒這個順序的考生，在誤路由題目上始終選錯。

應該把兩個相似的工具合併成一個帶有 mode 參數的工具，還是拆成 purpose-specific tool？

拆分。CCA-F 的預設是把泛用工具拆成有更緊湊 description、不重疊 boundary，以及每工具獨立 input/output contract 的 purpose-specific tool。合併迫使 Claude 在工具內部做分支，而那是錯誤的層次——選擇必須發生在工具邊界，Claude 在那裡很強，而不是在工具內部，agent 在那裡很弱。唯一的例外是各「模式」確實共享完全相同的 input/output contract，且只差在一個無關緊要的旗標的情況——在實務上這很罕見。

工具名稱重要嗎，還是只有 description 重要？

Description 主導，但名稱也不是完全被忽略。當兩個工具的 description 相似，名稱關鍵字重疊（analyze_content vs analyze_document）可能把 Claude 推向錯誤的選擇。CCA-F 的標準修法是重命名＋擴充同時進行：重命名以消除關鍵字重疊（extract_web_results vs parse_customer_document），並擴充 description 以帶有明確的 boundary 子句。光是重命名不夠；光是擴充通常已足夠；兩者同時做是最穩健的模式。

延伸閱讀

• CCA-F 考試指南（官方 PDF）: https://everpath-course-content.s3-accelerate.amazonaws.com/instructor/8lsy243ftffjjy1cx9lm3o2bw/public/1773274827/Claude+Certified+Architect+%E2%80%93+Foundations+Certification+Exam+Guide.pdf
• Define tools — best practices for tool descriptions and tool_choice: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/implement-tool-use
• Writing tools for agents — Anthropic Engineering Blog: https://www.anthropic.com/engineering/writing-tools-for-agents
• Tool use with Claude — overview and agentic loop: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/overview
• Handle tool calls — tool_result format and error responses: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/handle-tool-calls
• 社群通過報告（Kishor Kukreja，893/1000）: https://medium.com/@kishorkukreja/i-passed-anthropics-claude-certified-architect-foundations-exam-with-a-score-of-893-1000-2206c27efd6c

相關 ExamHub 主題：MCP Tools 的結構化錯誤回應、Agent 間的 Tool 分配與 Tool Choice 設定、將 MCP Server 整合進 Claude Code 與 Agent 工作流程、內建工具選擇與應用。