Claude Code團隊重建工具3次後學到的4條設計原則

減少工具後，AI反而表現更好了。建構Agent時，最自然的本能是「功能不夠就再加個工具」。Anthropic團隊在開發Claude Code的一年裡發現了相反的規律：每多一個工具，AI就多一分「該不該呼叫」的猶豫成本，而這種成本會不斷累積。

我在自己建構Agent時也掉進了同樣的陷阱，所以Claude Code團隊開發者Thariq分享的這段經歷讓我深有感觸。以下是他們增刪和重新設計工具的完整過程。

一個工具塞兩個職責，AI就會卡住

這是Claude Code團隊遇到的第一個問題。他們需要向使用者提問的功能，就把提問功能塞進了「制定計畫」工具裡。實作速度很快，但AI在制定計畫的同時又要產生問題，當使用者的回答與計畫衝突時，AI無法自行判斷。

第二次嘗試是讓AI用Markdown格式輸出問題，結果AI隨意更改格式或添加多餘的文字。第三次，他們終於把提問功能拆分成專用工具AskUserQuestion，這才開始穩定運作。一個工具一個職責——原則很簡單，但只有親身經歷過才能真正體會。

• 計畫+提問合體 — AI錯誤地兩次呼叫同一工具
• Markdown格式輸出 — AI擅自添加句子或忽略格式
• 專用工具分離 — 結構化回應終於穩定輸出
• 設計再好，如果AI不願意呼叫，就沒有意義

好用的工具某天會變成枷鎖

把工具分離好並不是終點。我把這叫做「工具過期（tool decay）」——曾經不可或缺的工具在模型升級後反而拖後腿的現象。

早期的Claude Code有一個待辦事項工具，系統每5輪就發送提醒：「別忘了你的任務清單。」模型變強之後，這些提醒反而產生了反效果。AI在應該調整清單的時候仍然固執地堅持原計畫。當Opus 4.5實現子Agent協作後，現有的Todo結構根本無法在Agent之間共享任務。

最終他們用Task Tool進行了全面替換。

• TodoWrite替換為Task Tool — 實現了Agent間的依賴關係共享
• 「這個工具還有效嗎？」需要定期審視，與添加新工具同樣重要
• 支援的模型數量越少，這種判斷速度越快
• 工具的形態比數量更重要 — 要匹配模型的能力

把脈絡餵給AI，反而會讓它變差

在增刪工具的過程中，Claude Code團隊發現了一個更根本的規律：讓AI自己去找資訊，比直接注入資訊效果更好。

一開始他們用RAG向量資料庫預載入脈絡。速度快、功能強，但在不同環境下索引會出問題，AI也變得被動——只依賴被提供的資訊。換成給AI一個Grep工具讓它直接搜尋程式碼庫後，脈絡品質提升了。再加上Skills檔案，建構了AI能遞迴探索檔案中參照的其他檔案的結構。

這就是漸進式脈絡發現（progressive disclosure）——不是一次性灌入所有資訊，而是讓AI按需自主發現。

• RAG — 環境依賴性高，AI被動消費脈絡
• Grep + Skills — AI主動探索多層檔案
• 一年內從「找不到脈絡的AI」變成「自己找脈絡的AI」
• 無需添加工具，僅透過Skills檔案就能擴展功能

不增加工具也能擴展AI的能力

漸進式脈絡發現模式還有一個經典案例。使用者問Claude Code的使用方法時，它答不上來。可以把所有使用說明塞進系統提示詞，但這類問題並不常見。不常用的資訊長期佔據脈絡視窗，會降低程式碼撰寫這一核心任務的效能。這就是脈絡雜訊（context rot）。

解決方案是專用子Agent。只有當使用方法的問題出現時，引導Agent才會搜尋文件並只回傳答案。工具數量不變，但AI能做的事情變多了。

• 系統提示詞塞入所有資訊 — 脈絡雜訊導致程式碼品質下降
• 只提供文件連結 — AI把太多結果載入到脈絡中
• 專用子Agent + 搜尋指引 — 只回傳所需答案，乾淨俐落
• 透過改變結構而非增加工具來解決問題

沒有標準答案

增加、刪除、重新設計工具——這個過程沒有標準公式。模型變了，工具就得跟著變；昨天正確的架構，明天可能成為瓶頸。

Anthropic團隊一年來反覆做的一件事是：閱讀AI的輸出，實驗，再修正。歸根結底，能做出優秀Agent的人，是能夠站在AI角度思考的人。