AI 智能體進化論：頂尖開發者如何為 Claude 打造高效工具？

你的 AI 智能體（Agent）是否感覺有點笨拙，無法發揮全部潛力？問題可能不在 AI 本身，而在於你給它的「工具」。本文將揭示 Anthropic 的內部心法，分享如何打造、評估並優化 AI 工具，甚至讓 Claude 協助你完成這一切，讓你的 AI 應用程式效能倍增。

你有沒有過這種感覺？你手上有一個像 Claude 這樣強大的大型語言模型（LLM），理論上它應該能自動處理複雜任務，但實際運作起來卻總是有點卡卡的，不夠聰明。這就像你請了一位米其林星級主廚，卻只給他一把鈍刀和幾個不新鮮的食材。

問題的根源，往往不是主廚的能力，而是我們提供給他的工具。

AI 智能體（Agent）的效能，與我們賦予它的工具有著最直接的關係。這篇文章，就是要分享我們在 Anthropic 內部，透過無數次實驗總結出的經驗：如何打造高品質的工具，如何進行全面的評估，以及最有趣的部分——如何與 Claude 這類的 AI 協作，讓它自己來優化自己的工具。

所以，AI 的「工具」到底是什麼？

在我們深入探討之前，得先釐清一個觀念。傳統的軟體開發，就像是寫一份精確的食譜。只要輸入相同的食材（inputs），每一步都完全照做，最終產出的菜餚（output）永遠都會一模一樣。這就是所謂的「確定性系統」（deterministic systems）。

但 AI 智能體不一樣。它更像一位有創造力的廚師，即使拿到相同的食材，也可能根據當下的靈感，做出稍微不同的變化。它是一個「非確定性系統」（non-deterministic systems），充滿了變數與可能性。

因此，為 AI 設計的「工具」，是一種全新的軟體。它不再是死板的指令集，而更像是在確定性系統與非確定性智能體之間建立的一份「合約」。當使用者問「今天出門要帶傘嗎？」，智能體可能會呼叫天氣工具，也可能從自身知識回答，甚至會反問地點。它可能會出錯，也可能找不到合適的工具。

這意味著我們必須徹底改變思維。我們設計的不再是給其他開發者用的 API，而是給一個充滿不確定性、需要引導的「數位大腦」使用的工具。

如何打造高效工具？一個不斷循環的開發流程

想打造出讓 AI 用得順手的工具，並不是一蹴可幾的事。這是一個不斷「打造、評估、學習」的循環過程。

步驟一：別想太多，先動手做個原型

要預測 AI 會覺得哪些工具「順手」，哪些會讓它「困惑」，光靠想像是沒用的。最好的方法就是直接動手。

你可以利用像 Claude Code 這樣的工具，快速生成你的工具原型。一個小技巧是，提供它相關的軟體庫、API 或 SDK 文件，特別是那些 LLM 友善的純文字文件（很多開源專案會提供 llms.txt 這種檔案），這會讓它事半功倍。

原型寫好後，將它包裝成本地的 模型上下文協議（MCP）伺服器 或 桌面擴充功能（DXT），就可以在 Claude Code 或 Claude 桌面應用程式中進行測試。你也可以直接透過 Anthropic API 進行程式化測試。

親自測試你的工具，感受一下流程是否順暢，並收集使用者的回饋，這能幫助你建立對使用情境的直覺。

步驟二：是時候來場嚴格的「大考」了

原型有了，接下來你需要衡量 Claude 使用這些工具的表現如何。這就需要一套全面的評估機制。

忘掉那些過於簡單的「沙盒」環境吧！你需要的是源於真實世界、具有足夠複雜度的評估任務。一個好的評估任務，可能需要 AI 連續呼叫多個、甚至數十個工具才能完成。

看看這兩組任務的差別：

• 好的評估任務範例：

  • 「幫我跟 Jane 約下週開會，討論最新的 Acme 公司專案。從上次的專案規劃會議紀錄中附加筆記，並預訂一間會議室。」
  • 「客戶 ID 9182 回報他一次購買被重複收費了三次。找出所有相關的日誌記錄，並判斷是否有其他客戶也受到影響。」

• 較弱的評估任務範例：

  • 「跟 jane @ acme.corp 約下週開會。」
  • 「搜尋 customer_id=9182 的付款日誌。」

看到差別了嗎？好的任務更貼近真實的工作流程。

每個評估任務都應該有一個可驗證的結果。最簡單的方式是比對字串，複雜一點則可以讓另一個 Claude 實例來判斷結果是否正確。同時，你也可以在系統提示（System Prompt）中，要求 AI 在呼叫工具前回傳它的「推理過程」和「反饋」，這能觸發它的「思維鏈（Chain-of-Thought）」行為，提升解決問題的智慧。

步驟三：讓 AI 成為你的最佳分析師

評估跑完，一堆數據攤在眼前，然後呢？

這時候，AI 智能體本身就是你最好的合作夥伴。它們能幫你發現從工具描述互相矛盾，到工具實作效率低下等各種問題。但請記住一個重點：大型語言模型並不總是直話直說，它「沒說什麼」往往比它「說了什麼」更重要。

仔細觀察你的 AI 在哪些地方卡住或感到困惑。閱讀它的推理過程（CoT），找出那些不順暢的地方。你甚至可以把整個評估過程的腳本（包含工具呼叫和回傳）直接貼給 Claude Code，它是一位分析腳本和重構工具的專家，能確保你在修改後，工具的實作和描述依然保持一致。

事實上，這篇文章裡的大部分建議，都來自於我們內部不斷用 Claude Code 優化工具的實踐。透過這種方式，我們發現效能提升甚至超越了由專家研究員手動撰寫的工具。

打造高效工具的五大黃金準則

在經歷了無數次的迭代循環後，我們提煉出了幾個關鍵的設計準則。

準則一：少即是多，別讓你的 AI 選擇困難

一個常見的誤區是，以為給 AI 的工具越多越好。但事實恰恰相反。如果只是簡單地將現有的 API 功能一對一地封裝成工具，往往會造成反效果。

AI 智能體的「上下文（context）」是有限的，就像人的短期記憶一樣。而傳統電腦的記憶體則幾乎是無限的。想像一下，在通訊錄裡找一個人，傳統軟體可以快速遍歷整個列表。但如果一個工具回傳了「所有」聯絡人，讓 AI 一個個去讀，那無疑是在浪費它寶貴的上下文空間。

更聰明、更自然的方式，是像人一樣，直接跳到相關的頁面（例如按字母排序查找）。

所以，你應該設計的是針對特定高影響力工作流程的工具。例如，與其提供 list_users、list_events、create_event 三個工具，不如整合一個 schedule_event 工具，一步到位地完成查找空閒時間並安排活動。

準則二：整理你的工具箱，命名是一門藝術

當你的 AI 可以取用數十甚至數百種工具時，混亂就會產生。如果工具功能重疊或用途模糊，AI 很容易就會用錯。

命名空間（Namespacing） 是個簡單卻有效的解決方案。透過給相關工具加上共同的前綴來分組，可以幫助 AI 在正確的時間選擇正確的工具。例如：

• 按服務分類：asana_search, jira_search
• 按資源分類：asana_projects_search, asana_users_search

這樣做不僅減少了 AI 上下文需要載入的工具數量，也將一部分運算負擔從 AI 的「大腦」轉移到了工具本身，從而降低了出錯的風險。

準則三：只說重點，AI 的「注意力」很寶貴

工具的回傳內容也同樣重要。請務必只回傳高價值的、與上下文高度相關的資訊。

AI 更擅長處理自然語言的名稱或術語，而不是像 uuid 這種神秘的技術標識符。我們發現，僅僅是將一長串無意義的字母數字 ID 解析成語意更豐富的語言，就能顯著提高 Claude 在檢索任務中的準確性並減少幻覺。

在某些情況下，你也可以提供彈性。例如，新增一個 response_format 參數，讓 AI 可以選擇回傳「精簡（concise）」或「詳細（detailed）」的結果。精簡版可能只包含核心內容，而詳細版則包含各種 ID，方便後續的工具呼叫。

準則四：精打細算，教你的 AI 節省「腦容量」

上下文品質很重要，但「數量」同樣需要優化。工具的上下文長度是有限的，因此你需要實作像是分頁（pagination）、範圍選擇（range selection） 和 過濾（filtering） 等功能。

如果你的工具回傳結果被截斷了，一定要給予清晰的提示，引導 AI 採取更節省 Token 的策略，例如進行多次小範圍的精準搜尋，而不是一次大範圍的模糊搜尋。

同樣地，錯誤訊息也至關重要。與其回傳一個冰冷的錯誤碼，不如提供一個有幫助的回應，清楚地說明問題所在，並給出修正建議。

看看這個對比：

• 無用的錯誤： {"error": {"code": "RESOURCE_NOT_FOUND"}}
• 有用的錯誤： 「# 資源未找到：無效的 userId。您的請求失敗，因為 userId ‘john.doe @ acme.corp’ 不存在或格式錯誤。有效的 userId 範例為：‘192829814…’。您可以嘗試呼叫 user_search() 來解決此問題。」

後者顯然能更好地引導 AI 走上正確的道路。

準則五：最強大的槓桿——一句好的描述勝過千行程式碼

終於，我們來到了最有效、也最常被忽略的一環：為你的工具撰寫描述（prompt-engineering your tool descriptions）。

工具的描述和規格會被載入到 AI 的上下文中，直接影響它的行為。撰寫時，想像一下你正在向一位新加入團隊的同事解釋這個工具。把那些你可能認為理所當然的背景知識——特定的查詢格式、專業術語的定義、資源之間的關係——全部明確地寫出來。

避免模糊不清，特別是參數命名。不要用一個模糊的 user，而是用一個明確的 user_id。

微小的改動就能帶來巨大的效能提升。例如，Claude Sonnet 3.5 在 SWE-bench 驗證評估中取得頂尖表現，正是因為我們對工具描述進行了精確的微調，從而大幅降低了錯誤率。

展望未來：與 AI 共同進化的開發新模式

為 AI 智能體打造工具，要求我們將軟體開發的思維模式，從可預測的確定性世界，轉向充滿變化的非確定性世界。

透過我們所描述的這種迭代式、以評估為驅動的開發流程，你會發現高效的工具都具備一些共通特點：它們目標明確、善用 AI 的上下文、可以靈活組合，並能讓 AI 直觀地解決真實世界的問題。

未來，隨著 LLM 本身和 MCP 這類互動協議的不斷升級，AI 與世界互動的方式也將不斷進化。但只要我們堅持這種系統性的優化方法，就能確保我們手中的工具，能與日益強大的 AI 並肩前行，共同成長。

文章來源

https://www.anthropic.com/engineering/writing-tools-for-agents