企業把訂單、會員與知識庫接給 AI，常以為工具越多，代理就越能幫忙。但使用者問「這筆訂單能不能退」，AI 可能選到取消訂單，而不是查詢退貨資格。問題不一定出在模型不夠強，而是工具名稱太像、用途不清楚，或一次提供了太多選項。
近期訊號：工具也需要被搜尋
2026 年 8 月 25 日發表於 arXiv 的 SCOUT 預印本，描述 PayPal 環境中以搜尋挑選相關工具、再提供給代理的做法。這是作者報告的特定實作，並非通用成效保證。Firebase 在 8 月 11 日也分享技能啟用與端到端評估方法。兩者提醒我們：除了接通系統，還要確認代理能找到並正確使用能力。以下是米亞科技的導入建議。
先把工具寫成業務看得懂的服務
每個工具都應有清楚的用途、適用情境、不適用情境、必要輸入、輸出與負責人。例如「查詢退貨資格」只回傳規則與訂單狀態；「建立退貨申請」會產生新案件；「執行退款」則會改變金流。三者不能只用相似名稱區分。也要標明是否寫入資料、是否需要核准，以及失敗時代表未執行還是結果未知。
按任務挑選，再載入細節
可以把工具目錄想成圖書館索引：先用需求找到少量候選，再讀取完整操作規格。MCP 是連接工具的一種方式，工具探索則是另一層設計，並不會因為接上 MCP 就自動完成。工具數量不多時，清楚分組可能已足夠；擴大後再考慮結合關鍵字與語意搜尋。候選過少會漏掉正確工具，過多又增加判斷負擔，應以真實任務調整。
找得到，不代表可以執行
目錄應先依使用者、部門與資料範圍過濾可見工具；實際呼叫時，後端仍須重新檢查身分與權限。搜尋排名不是授權，工具說明也不能替代核准。目錄記錄應經審核、保留版本與停用狀態，避免過期介面或未受信任的描述混入。涉及寫入時，還要確認參數與核准對象一致。
用退貨流程做一個小型驗收
以下是假設情境，並非客戶實績。客服要求「幫我看能不能退」，系統應查詢資格並說明依據，不應直接退款；要求「建立申請」才可進入申請流程；沒有退款權限的人，即使知道工具名稱也不能執行。測試還應包含同名客戶、缺少訂單號、工具停用、搜尋沒有結果，以及使用者途中更改意思。資訊不足時應詢問或交接，不能猜一個工具繼續。
衡量完成工作，不只看省下多少 Token
先以既有整合建立基準，再比較選對工具比例、任務完成率、錯誤寫入次數、延遲與人工修正時間。工具探索本身也需要成本與時間，縮短提示不一定讓整段流程更快。每次改名、換版本或新增工具，都應重跑代表性案例，保留選了哪個工具、依據哪版目錄與後端是否允許的紀錄。
米亞科技的建議
先挑一條客服或申請流程，整理少量常用工具與容易混淆的需求，再把網站、APP、既有 API、權限與後台紀錄接起來。企業 AI 整合的價值，會逐步從「能連多少系統」轉向「能否在正確情境下，安全而穩定地完成工作」。工具目錄就是讓這件事可管理、可驗收的起點。
References: SCOUT — arXiv preprint, 2026-08-25; Firebase — Eval-driven development, 2026-08-11