別再像寫代碼一樣給AI造工具了，Anthropic內部5條心法讓模型變超人
摘要
你給AI的工具越強大，它可能反而越笨。這是因為我們一直在用確定性思維設計工具，喂給不確定的模型。本文揭示Anthropic內部優化AI工具的完整流程與5條核心原則，幫你徹底扭轉智能體“不好用”的局面。
我們給AI智能體（Agent）打造工具的方式，從根上就錯了。
這是大多數開發者在實踐中碰壁后，才不情愿承認的殘酷現實。我們以為給AI的工具越多、越像標準的API，它的能力就越強。
然而現實恰恰相反——你給AI一把功能齊全的瑞士軍刀，它卻反復用開瓶器去擰螺絲，甚至干脆對著木頭瞎比劃。它會犯錯、會困惑、會陷入低效的循環，最終讓你感嘆：“這AI怎么這么笨？”
問題不在AI，而在我們。我們習慣了為確定性系統編寫軟件，每一行代碼都追求精確、無歧義的輸入輸出。但AI智能體，本質上是一個非確定性系統。用程序員的舊地圖，永遠找不到AI新大陸。
這篇文章，不是又一篇教你寫提示詞的技巧帖。它是一份來自Anthropic內部的實踐復盤，一套完整的、用AI優化AI工具的思維框架和工作流程。它將幫你理解并掌握那5條能讓你的AI智能體脫胎換骨的核心心法。
真正釋放AI潛力的關鍵，在于從“程序員”思維，轉變為“AI教練”思維。
以下是實現這一轉變的5個本質洞察：
- 思維重置AI不是機器，而是“實習生”。停止用機器指令喂養它，要用它能理解的工作流去引導它。
- 流程再造建立“原型-評估-AI協同優化”的閉環，讓數據而非直覺，驅動工具的每一次迭代。
- 設計升維工具的價值核心是“賦能一個工作流”，而不是“簡單封裝一個API”。
- 溝通校準工具的描述和返回信息，就是你與AI的溝通界面，每一個詞都可能決定成敗。
- 情境為王AI的“上下文窗口”是它最寶貴的認知資源，一切設計都應以節省和優化這份“預算”為中心。
一、忘掉API，擁抱工作流
一個常見的錯誤，是把現有的軟件功能或API端點，一對一地封裝成工具丟給AI。
這為什么是錯的？
因為AI和傳統軟件看待世界的方式完全不同。傳統軟件可以不知疲倦地處理海量信息，內存廉價又充足。而AI的“上下文”——也就是它能同時處理的信息量——是極其有限且昂貴的。
想象一下，你要在一個通訊錄里找人。傳統程序會加載整個列表，然后逐一比對，高效無誤。
但如果讓AI用一個返回所有聯系人的 ??list_contacts?? 工具，就等于逼它把整本電話本從頭到尾讀一遍。這不僅浪費了寶貴的上下文空間，還極易出錯。
對AI（以及人類）來說，更自然的方式是直接翻到對應的字母索引頁。
所以，正確的做法是打造面向工作流的工具。
- 錯誤示范提供?
?list_users???、??list_events???、??create_event?? 三個獨立工具。 - 正確示范實現一個?
?schedule_event?? 工具，它在內部處理查找參會者、檢查日歷、最終創建事件的全部邏輯。 - 錯誤示范提供一個?
?read_logs?? 工具，讓AI自己去大海撈針。 - 正確示范實現一個?
?search_logs?? 工具，只返回最相關的幾行日志和前后文。
你的每一個工具，都應該讓AI能夠像人類專家一樣，大刀闊斧地切分和解決問題，而不是陷入瑣碎的操作細節。
Anthropic在對其內部的Slack和Asana工具進行優化時發現1，整合后的工作流工具，相較于零散的API封裝工具，在復雜任務上的成功率實現了大幅躍升。
二、用AI來打磨AI的“武器庫”
如何知道你的工具設計得好不好？答案是：建立一個嚴格的評估體系，然后讓AI幫你找到答案。
這個過程分為三步：構建原型、運行評估、協同優化。
首先，快速構建工具原型。然后，讓Claude這樣的代碼智能體幫你生成大量的評估任務。這些任務必須源于真實世界，足夠復雜，可能需要調用數十次工具才能完成。
例如，一個強評估任務是：“幫我和Jane約個會，討論Acme項目。附上上次會議的紀要，并預定一間會議室?！?/p>
而一個弱評估任務是：“給jane@acme.corp發郵件?！?/p>
接下來，通過API調用，讓評估智能體在循環中自動執行這些任務。在這個過程中，除了驗證結果是否正確，更要讓智能體輸出它的“思考過程”和“反饋”。你會驚訝地發現，AI能告訴你很多你沒想到的問題——比如某個工具描述有歧義，某個參數名讓它困惑，或者兩個工具功能重疊。
最后，把所有失敗的案例、AI的思考過程和反饋，一股腦丟給Claude Code，讓它來分析和重構你的工具代碼。
這個閉環，就是用魔法打敗魔法。
三、你的返回，決定AI的下一步
工具返回給AI的信息，不是越多越好，而是越“有信號”越好。
AI對充滿技術術語的返回內容感到“消化不良”。諸如 ??uuid???、??256px_image_url???、??mime_type??? 這樣的字段，遠不如 ??name???、??image_url???、??file_type?? 來得直接。
一個驚人的發現是，僅僅是將一串無意義的字母數字ID，替換成有語義的、人類可讀的名稱（甚至是簡單的0、1、2索引），就能顯著降低AI在檢索任務中的幻覺率。
更進一步，你可以提供一個 ??response_format?? 參數，讓AI自己決定需要“簡潔”還是“詳細”的返回。一個詳細返回可能消耗200個token，而一個簡潔版可能只需要70個。這在長對話中能省出巨大的上下文預算。
如果返回內容過長，必須進行截斷。但不要粗暴地切掉，而要友好地提示，并引導AI調整策略——比如，“結果超過100條，已截斷。請嘗試使用更精確的搜索條件?！?/p>
錯誤信息也是一樣。返回一個冰冷的 ??InvalidParameter??? 錯誤碼，不如告訴它：“參數 ??user_id?? 不能為空，請輸入有效的用戶ID?！?/p>
每一次返回，都是一次與AI的對話，一次塑造其后續行為的機會。
四、像新人入職一樣，寫工具說明
工具描述和參數說明，是整個系統中杠桿效應最高的地方。它被加載到AI的上下文中，直接決定了AI如何理解和使用你的工具。
你應該像給一位新入職的同事講解內部系統一樣，來寫這份文檔。
把所有你認為理所當然的“常識”都明確寫出來：
- 這個工具的核心目的是什么？
- 某個專有術語代表什么？
- 各個資源之間有什么隱藏的關聯？
- 參數的格式要求是什么？
一個典型的優化案例：參數名 ??user??? 就存在歧義，它到底是指用戶名、用戶ID還是郵箱？改成 ??user_id??，就能消除所有困惑。
Anthropic在沖擊SWE-bench軟件工程基準測試時，正是通過對工具描述進行了一系列精密的微調，才最終讓Claude Sonnet 3.5取得了當時最好的成績2，大幅降低了錯誤率。
五、為工具建立清晰的“勢力范圍”
當AI擁有的工具越來越多時，它會開始犯“選擇困難癥”。特別是當多個工具功能相似時。
使用命名空間是解決這個問題的有效手段。通過清晰的前綴或后綴，為工具劃分好“勢力范圍”。
例如，??asana_search??? 和 ??jira_search??? 就比兩個都叫 ??search??? 的工具要清晰得多。更進一步，??asana_projects_search??? 和 ??asana_users_search?? 則能讓AI的定位更加精準。
這種命名方式，不僅幫助AI做選擇，更重要的是，它將任務的“計算”從AI昂貴的上下文空間，轉移到了更便宜的工具調用本身。AI不再需要思考“我要在Asana里搜什么”，而是直接思考“我需要搜索Asana里的項目”。
這細微的差別，正是從業余到專業的體現。
為AI智能體構建工具，是一門正在興起的新學科。它要求我們放下過去確定性的編程范式，轉而擁抱與非確定性智能體共舞的藝術。
這個過程的核心，不再是追求代碼的邏輯完美，而是追求人機交互的“體感舒適”（Ergonomics）。
今天分享的這套流程和五條心法，是我們（Anthropic）從無數次失敗和成功中提煉出的經驗。它們不是終點，而是你踏上這條新道路的起點。
原文鏈接：??https://www.anthropic.com/engineering/writing-tools-for-agents??
本文轉載自??草臺AI??，作者：RangerEX
