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

減少工具之後，AI反而表現更好。建構Agent嘅時候，最自然嘅本能係「功能唔夠就再加個工具」。Anthropic團隊喺開發Claude Code嘅一年入面發現咗相反嘅規律：每多一個工具，AI就多一分「應唔應該call」嘅猶豫成本，而呢種成本會不斷累積。

我自己建構Agent嘅時候都跌落同一個陷阱，所以Claude Code團隊開發者Thariq分享嘅呢段經歷令我好有感觸。以下係佢哋增刪同重新設計工具嘅完整過程。

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

呢個係Claude Code團隊遇到嘅第一個問題。佢哋需要向用戶提問嘅功能，就將提問功能塞入咗「制定計劃」工具入面。實作速度好快，但AI喺制定計劃嘅同時又要產生問題，當用戶嘅回答同計劃衝突嘅時候，AI冇辦法自行判斷。

第二次嘗試係畀AI用Markdown格式輸出問題，結果AI隨意更改格式或者加多餘嘅文字。第三次，佢哋終於將提問功能拆分成專用工具AskUserQuestion，呢個時候先至開始穩定運作。一個工具一個職責——原則好簡單，但只有親身經歷過先至真正體會到。

• 計劃+提問合體 — AI錯誤噉兩次call同一個工具
• Markdown格式輸出 — AI擅自加句子或者忽略格式
• 專用工具分離 — 結構化回應終於穩定輸出
• 設計再好，如果AI唔願意call，就冇意義

好用嘅工具某日會變成枷鎖

將工具分離好並唔係終點。我將呢個叫做「工具過期（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角度思考嘅人。