大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



給一個人解數學題，你會給他什麼工具？

紙筆是最低限度，但手算很慢。

計算機好一些，但進階功能要學。

電腦最強大，但你得會寫程式。

工具的選擇不取決於題目，而取決於使用者的能力。

Claude Code 團隊的 Thariq 最近 分享了一系列工具設計經驗，核心主張很明確：設計 agent 工具不是列功能清單，而是學會「像 agent 一樣看世界」。

他用四個實戰案例，展示了這套方法論怎麼落地。

懶人包

⭐ Podcast 輕鬆聽：兩個 AI 用 8 分鐘拆解 Claude Code 團隊怎麼設計工具，為什麼工具越少反而越強

Thariq 用了一個很直覺的比喻。

想像你拿到一道困難的數學題，你會想要什麼工具？

答案取決於你自己的技能。

紙筆是最低限度，但你只能靠手算。

計算機好一些，但你得知道怎麼操作進階功能。

電腦是最快最強的選項，但前提是你會寫程式。

Agent 工具設計的邏輯完全一樣。

你要給模型的工具，必須契合它當前的能力。

但問題來了：你怎麼知道模型的能力邊界在哪裡？

Thariq 的回答很直接：觀察、閱讀它的輸出、不斷實驗。

你要學會像 agent 一樣看世界。

這不是一句漂亮的口號，而是一套真的在用的工作方法。

以下四個案例，就是他們在 Claude Code 開發過程中「觀察模型行為、然後調整工具」的具體過程。

Claude Code 有一個叫 AskUserQuestion 的工具，讓模型在需要釐清使用者意圖時主動提問。

這個工具的目的是改善模型的「引導式提問」能力，讓使用者回答問題時不會覺得很麻煩。

但這個工具不是第一次就做對的。

第一次嘗試：在計畫工具加參數。

他們在 ExitPlanTool 上加了一個問題陣列，讓模型在提交計畫時可以順便提問。

這是最容易實作的方式，但模型被搞混了。

同時要提交計畫又要提問？

如果使用者的回答跟計畫矛盾呢？

模型需要呼叫兩次 ExitPlanTool 嗎？

這個設計把兩個不同意圖塞進同一個工具，模型無法處理。

第二次嘗試：改輸出格式。

他們修改了 Claude 的輸出指令，讓它用特殊 Markdown 格式輸出問題清單，例如用括號標示選項。

然後由前端解析並顯示為 UI。

模型大致上能做到，但不穩定。

有時候會多加幾句話，有時候省略選項，有時候直接用不同格式。

格式化輸出聽起來是最通用的做法，但模型的輸出不能保證一致。

第三次嘗試：做成獨立工具。

最後他們做了一個專用工具，模型可以在任何時候呼叫它。

呼叫時會顯示一個 modal 畫面，擋住 agent 的執行迴圈，等使用者回答完才繼續。

這次成功了。

模型「喜歡」呼叫這個工具，輸出品質也很好。

它同時解決了結構化輸出的問題，還讓使用者可以在 Agent SDK 或 skill 中組合使用。

Thariq 在這裡下了一個關鍵判斷：「即使設計最好的工具，如果 Claude 不懂怎麼呼叫它，就沒用。」

工具設計的成功標準不只是功能正確，更重要的是模型能不能自然地理解和使用它。

這是三次迭代最大的教訓。

Claude Code 剛推出時，團隊發現模型需要一個 Todo list 才能維持任務追蹤。

他們做了 TodoWrite 工具，讓模型在開始工作時列出待辦事項，完成一項就勾掉一項。

但即使有了 Todo list，模型還是會忘記要做什麼。

他們的應對方式是每 5 輪插入一次系統提醒，提醒模型它的目標是什麼。

這在當時是有效的。

但模型進步了。

更強的模型不但不需要被提醒，反而覺得提醒是一種限制。

系統提醒讓模型認為它必須死守 Todo list 上的項目，不敢修改清單。

原本的輔助工具，變成了新的束縛。

與此同時，Opus 4.5 在使用子代理方面進步了很多。

但子代理之間怎麼協調共享的 Todo list？

舊的 TodoWrite 設計沒有考慮這個場景。

所以他們用 Task Tool 取代了 TodoWrite。

跟 Todo 不同的是，Task 的設計重心是讓 agent 之間互相溝通。

Task 支援依賴關係、可以跨子代理共享更新、模型可以自行修改和刪除。

Thariq 在這裡的觀察很值得記住：「隨著模型能力提升，你以前需要的工具可能正在限制它們。」

這意味著工具設計不能一次定案。

你必須不斷回頭檢視先前的假設，看看當初的輔助設計是否已經過時。

Thariq 也補了一句實務建議：支援少量能力相近的模型比支援大量差異模型容易管理，因為工具假設的更新成本更低。

Claude Code 最初用 RAG 向量資料庫來提供脈絡。

RAG 很快很強大，但有幾個問題：需要索引設置、跨環境容易壞掉，而且最根本的問題是，脈絡是「被給予」的，不是模型自己找的。

團隊做了一個轉變：如果 Claude 可以在網路上搜尋，為什麼不讓它搜尋程式碼？

他們給了 Claude 一個 Grep 工具，讓它自己搜尋檔案、自己建構脈絡。

這個轉變背後的觀察是：模型越聰明，就越擅長自己建構所需的脈絡，前提是你給它對的工具。

後來他們引入 Agent Skills，正式建立了「漸進式揭露」的概念。

模型可以讀取 skill 檔案，而這些檔案又引用其他檔案，模型可以遞迴搜尋多層檔案，找到它需要的精確脈絡。

實際上，很多 skill 的用途就是給 Claude 更多搜尋能力，例如告訴它怎麼使用某個 API 或查詢某個資料庫。

一年之內，Claude 從「基本無法自建脈絡」進化到「能做多層遞迴搜尋，精確找到需要的資訊」。

漸進式揭露現在是 Claude Code 團隊新增功能的預設策略，而且它有一個很重要的特性：不需要加新工具。

這一點在 Claude Code Guide 子代理的案例中更加明顯。

Claude Code 目前大約有 20 個工具，團隊對新增工具設了很高的門檻，因為每多一個工具就讓模型多了一個需要思考的選項。

他們發現 Claude 不太了解自己的使用方式。

使用者問怎麼加 MCP、某個 slash command 做什麼，Claude 答不上來。

把這些資訊放進 system prompt 是一個選項，但使用者很少問這類問題，放了會增加 context rot (脈絡腐蝕)，干擾 Claude Code 的主要工作：寫程式。

他們先試了漸進式揭露，給 Claude 一個文件連結讓它自己搜尋。

但 Claude 會載入大量結果到脈絡裡，試圖找到正確答案，效率很低。

最終方案是建立一個專門的「Claude Code 使用指南」子代理，它有搜尋文件的詳細指令，知道怎麼有效搜尋和回傳精確答案。

這個案例的重點不是技術細節，而是設計思路：他們在不新增工具的情況下，擴展了 Claude 的行動空間。

如果你在找一套嚴格的工具設計規則，Thariq 會讓你失望。

他在結尾明確說：設計模型的工具，是藝術而不是科學。

它高度取決於你使用的模型、agent 的目標，以及它運作的環境。

但四個案例加在一起，確實指向一個清晰的方法論：

這些做法打破了兩個常見迷思。

第一個是「工具越多越好」，Claude Code 的經驗證明工具太多反而增加模型的認知負擔。

第二個是「一次設計到位」，四個案例都顯示工具設計是持續迭代的過程，不是一次定案的規格表。

常常實驗，讀你的模型輸出，嘗試新東西。

像 agent 一樣看世界。

參考資料：Lessons from Building Claude Code: Seeing like an Agent