設計AI代理工具的首選方法

AI回答與人類回答之間的差距往往不在於智能水平，而在於細節的準確性。基於真實數據的清晰、具體回答遠優於流暢的猜測。更智能的模型固然有幫助，但精心設計的工具才能真正彌合這一差距。

本文概述了一種在代理工具設計中被證明有效的方法。它並非唯一途徑，但已在多種代理中驗證有效，因此成為筆者的首選。

工具為何至關重要

代理並非直接處理原始數據，而是通過你提供的數據接口來工作。工具名稱、描述和參數每次都會影響模型的決策。以下是一些常見的失敗模式：

• 模糊的工具導致決策不明確：如果兩個工具能回答同一問題，代理必須猜測，而猜錯的概率相當高。
• 描述不佳導致工具從未被使用：描述是代理決定何時調用工具的唯一指南。
• 粒度是一個權衡：接受原始SQL的工具將精確性負擔轉嫁給模型，並可能引發糟糕的查詢。按對象類型設計一個工具雖好，但若超過50種類型，代理每次需在非常相似的選項中抉擇。沒有通用的粒度，它取決於你的具體領域。

例如，考慮get_opportunity和get_opportunity_health兩個工具。對於理解數據模型的人類來説，區別可能清晰，但對於試圖決定使用哪個工具的模型，它們似乎相同。這可能導致不可預測的調用，有時會遺漏用户要求的健康更新。通常的解決方法是合併這兩個工具或重命名以增加清晰度。

更多工具不代表更好結果

當代理忽略某些事項時，本能反應是添加另一個工具。然而，這種本能有其侷限。Anthropic的工具使用文檔顯示，Claude在工具數量超過30到50個時，選擇準確率下降。超過這一閾值，每個新工具會與鄰近工具競爭代理的注意力，而非擴展其能力。目標應是擁有能有效解決實際問題的最小工具集。

工具設計是代理大部分真實智能的所在，無論設計者是否有意為之。

從系統提示詞開始

沒有強大的系統提示詞，就無法創建有效的工具。提示詞定義了代理的身份、操作領域以及預期被問及的問題。工具服務於這一目的，而非反之。

如果跳過此步驟，會導致臃腫。模糊的提示詞如“幫助用户處理他們的Salesforce數據”會使模式中的所有內容都顯得相關。具體的提示詞，例如“幫助收入團隊識別有風險的管道並解釋賬户變化”，能迅速明確哪些重要——風險信號和變更歷史，而非通用CRUD操作。精心定義的提示詞幾乎毫不費力地設定清晰的工具邊界，但前提是它必須足夠具體以確立這些邊界。

如何判斷工具是否應該存在

拋開技術細節——目標很直接：給定用户的問題，代理應該確切知道使用哪個工具。

一個有用的測試是：你能確定這個工具回答的問題沒有其他工具能同樣好地回答嗎？如果不能，暫時不要添加——等待真實問題顯示需求。“它在模式中”或“端點存在”這樣的理由並不充分。出於這些原因添加的工具往往最終未被使用，或稍後與其他工具衝突。

利用代理設計工具

我們過程中一個令人驚訝的點是，我們使用代理來構建代理的工具。

一旦你有了紮實的系統提示詞和一組好的示例問題，將兩者連同你的數據結構（如JSON模式、數據庫模式或API規範）提供給LLM，並要求它建議能夠回答這些問題的工具。

這之所以有效，是因為進行設計的模型思考方式類似於最終將使用這些工具的代理。它模擬了決策過程，因此能更好地識別人類僅從模式設計時可能忽視的歧義或空白。

一個快速示例。

對於處理Salesforce的RevOps代理，其提示詞關於管道健康和賬户風險，問題如“本季度哪些交易有風險”、“Acme Corp最近有什麼變化”以及“為什麼這個機會的階段發生了變更”，一個合理的初稿包括：

• get_pipeline_risk_signals(owner, quarter)——通過停滯時間、階段迴歸或缺失下一步標記的交易
• get_account_activity(account_id, since_date)——字段變更、電子郵件和會議的時間線
• get_field_change_history(object_id, field_name)——特定字段的原始審計跟蹤

值得注意的是，第三個問題凸顯了字段級別歷史的需求，這與賬户級別活動不同。如果僅從模式設計，你可能錯誤假設get_account_activity也能處理這種情況——直到測試揭示它不能。

實施，然後真實測試

使用兩種類型的問題：工具設計用於的問題（應立即可用）和代理未曾遇到的新問題（這是真正的測試，揭示工具是否能泛化，還是你只是構建了一個查找表）。

關注代理如何得出答案，而不僅僅是是否正確。存在三種潛在錯誤：使用了錯誤的工具；使用了正確的工具但參數錯誤；將多個工具鏈式組合，而一個精心設計的工具本應足夠。每種錯誤指向不同的修復——描述、參數或粒度——因此避免將所有錯誤歸為“代理搞錯了”。

出錯時，詢問代理原因

不要僅僅修復工具就繼續——詢問代理什麼能幫助它正確回答。它通常能準確指出問題所在：鄰接工具的描述不清晰、參數需要示例、或兩個工具應合併。代理對於其決策過程有直接洞察，而你在稍後閲讀轉錄時無法獲得。

持續迭代直至性能穩定

重複循環——實施，測試已知和新問題，藉助代理診斷，優化——直到達到真實標準，而非僅僅是感覺。每輪跟蹤一組新問題的“正確工具、正確參數、正確答案”率。當該比率保持穩定時，你就完成了——不是因為代理完美，而是因為你不再遇到工具設計問題，而是面對孤立的邊緣情況，這是更小的問題。

這個過程不是一次性的設計。它更像產品迭代而非編寫API規範：發佈，觀察實際行為，優化。關鍵區別在於，該過程中最有價值的設計夥伴是代理本身。