給 Agent 一雙真正好用的手：工具設計比工具數量更重要

一句話講清楚：工具對Agent嘅價值，唔在於「接咗幾多API」，而在於佢能唔可以被穩定理解、正確調用、出錯後繼續修正。一個Agent再識判斷，如果只能講唔做得，價值都好有限。查數據、發消息、改文件、下訂單，都要靠工具完成。

於是好多團隊開始拼命接能力：十幾個搜索接口、幾十個業務API、各種數據庫同腳本入口。數量睇起嚟好壯觀，效果卻未必同步變好。

對人嚟講，「呢個接口大概用得」已經夠；對Agent嚟講，名字、參數、返回值同錯誤信息，都會影響佢下一步係咪行得啱

工具設計，本質係畀Agent設計操作界面

假設你畀Agent一個叫process嘅工具，只寫一句「處理用戶請求」，參數裏面仲有幾個含義不明嘅字段。人類工程師或者可以靠經驗估出嚟，Agent就好容易傳錯參數、選錯時機，失敗咗仲唔知點改。

傳錯參數、選錯時機、失敗唔識改

與其將四個數據庫接口原樣暴露，不如提供一個清楚嘅createRefundCase

失敗時唔好只回400，最好直接講係「缺少訂單號」定「金額超出可退範圍」

一個好有用嘅思路叫ACI（Agent-Computer Interface），佢關注嘅唔係頁面靚唔靚，而係模型能唔能快速理解目標、約束同後果。

可理解、可約束、可修復，比「能調通」更重要

工具要少啲「底層接口味」，多啲「任務動作味」。例如將退款相關嘅底層操作封裝成一個createRefundCase，唔係逐個數據庫接口暴露。

ACI係畀Agent設計操作界面嘅核心框架

工具太多都會帶嚟新問題，令上下文爆滿。Tool Search會先檢索候選工具，再將少量相關工具放入上下文，避免每輪都將整套工具箱攤開。

Tool Search：檢索+篩選，減少上下文負擔

另一種做法叫Programmatic Tool Calling，畀Agent將多個動作組織成一段程序式調用，處理成批讀取、篩選、彙總時更省輪次更穩。

Programmatic Tool Calling：將多個動作組織成一段程序，提升穩定性

from langchain.tools import tool
from pydantic import BaseModel, Field

class RefundInput(BaseModel):
 order_id: str = Field(description="訂單編號")
 amount: float = Field(description="退款金額")

@tool(args_schema=RefundInput)
def create_refund_case(order_id: str, amount: float) -> str:
 """創建退款案例，成功時返回案例ID，失敗時返回錯誤描述"""
 if not order_id:
 return "錯誤：缺少訂單號，請提供有效訂單編號"
 if amount > 1000:
 return "錯誤：金額超出可退範圍（上限1000），請調整金額"
 case_id = f"REF-{order_id}"
 return f"成功創建退款案例：{case_id}"

呢段代碼展示咗三件事：工具名貼近任務，參數收緊，錯誤可修。

args_schema越清楚，模型越唔容易亂填

失敗時畀出可執行提示，Agent先知下一步要核對訂單號，唔係機械重試

現實裏，好多問題並唔係模型唔識用工具，而係工具冇為模型被使用呢件事做好準備。

說明含糊、參數寬鬆、失敗信息貧瘠，最後都會變成Agent嘅「能力問題」

工具設計嘅目標：令Agent少猜、少誤用、能修正，而唔係單純接多啲接口