最近看 agent 生態的發展，我越來越覺得一件事正在從「方便功能」變成「架構問題」：當 AI Agent 不只是被動等待人指定工具，而是開始可以自己發現工具、判斷能力、串接其他 agent 或外部服務時，工具目錄就不再只是文件。
它會變成系統的一部分，而且是很關鍵的一部分。
以前我們談工具整合，常常會先想到外掛、市集、API 文件、SDK。工程團隊把工具接好，寫一份說明，使用者或開發者知道有這個能力，需要時再去呼叫。這種模式的核心假設是：人知道自己要找什麼，也知道該怎麼判斷一個工具是否適合。
但 agentic workflow 的假設不太一樣。當一個 agent 要完成任務，它可能需要先理解目前有哪些資源可以用：哪些工具能查資料、哪些工具能寫入系統、哪些工具只能讀取、哪些工具需要審核、哪些工具已經過期、哪些工具只適合特定範圍。這些資訊如果只放在 README 或某個人腦袋裡，對 agent 來說幾乎等於不存在。
所以「可發現性」會變重要。
這裡的可發現性，不是單純搜尋得到一個 API endpoint，而是 agent 能夠用穩定、可驗證、可限制的方式知道：這個工具宣稱自己能做什麼、輸入輸出長什麼樣、需要什麼權限、成本大概多少、失敗時怎麼回報、適用範圍在哪裡。換句話說，它需要的不只是工具清單，而是 capability catalog。
站在技術主管的位置，我會把這件事看成三層。
第一層是描述層。工具要能用機器可讀的方式描述自己，而不是只靠自然語言文件。自然語言文件可以給人看，但 agent 執行任務時，需要更明確的結構：名稱、用途、參數 schema、輸出格式、錯誤類型、版本、維護者、資料分類。這些欄位看起來無聊，但少一個就可能讓 agent 在錯的情境呼叫錯的東西。
第二層是治理層。知道有工具，不代表可以用工具。企業系統裡最麻煩的從來不是「能不能接」，而是「誰在什麼條件下可以做什麼」。同一個查詢工具，在測試資料、一般營運資料、敏感個資、財務資料裡，風險完全不同。同一個寫入動作，在草稿、待審核、正式生效三種狀態下，也不是同一件事。
如果工具目錄沒有把權限、範圍、審核點和停用機制一起納入，agent 的自動發現反而會放大風險。它會很勤奮地找到路，然後很勤奮地走進不該走的地方。這不是模型聰不聰明的問題，是架構有沒有把邊界說清楚。
第三層是可觀測層。當 agent 能自己選工具，事後就不能只記錄「任務完成」。我們還要知道它看到了哪些可用能力、為什麼選這個工具、哪些工具被排除、呼叫時拿到什麼回應、是否有 fallback、是否越過成本或風險門檻。否則出問題時，團隊只會看到一段很像魔法的結果，卻不知道中間到底發生什麼事。
我覺得這也是很多企業 AI 導入容易低估的地方。大家會花很多時間討論模型、上下文長度、推理能力、工具呼叫格式，這些都重要；但如果工具目錄本身混亂，後面再好的 agent 都只能在混亂裡努力。就像公司內部如果連「哪個系統是主資料來源」都說不清楚，再漂亮的 BI 儀表板也只是把混亂畫得比較好看而已。
Agent 的工具目錄，其實很像過去微服務架構裡的 service registry，只是它多了一層語意與治理壓力。微服務需要知道服務在哪裡、健康狀態如何、版本是否相容；agent 還要知道這個能力在業務上代表什麼、風險在哪裡、能不能由模型自主決定、什麼情況必須停下來請人確認。
這也意味著，未來做企業 AI，不太可能只靠「把所有工具都接上去」就結束。比較成熟的做法，應該是把工具分級：有些只能讀、有些可以寫草稿、有些可以送審、有些可以在低風險範圍自動執行，有些永遠需要人工確認。工具目錄不只是列出能力，而是把能力放進組織可以接受的責任邊界裡。
我自己會特別在意版本問題。工具的能力會變，欄位會變，權限會變，資料來源也會變。如果 agent 記住的是舊描述，或工具宣告和實際行為不同，就會出現很難追的錯誤。人類工程師看到 API 文件過期，通常還有經驗可以懷疑一下；agent 則很可能照著過期的描述自信執行。這種自信，才是最危險的地方。
所以工具目錄不能只是靜態頁面。它需要測試、需要健康檢查、需要版本治理、需要 deprecation 流程，也需要把實際使用紀錄回饋回來。哪些工具常被 agent 誤用？哪些描述不夠清楚？哪些參數容易造成錯誤？這些都應該變成改善 catalog 的訊號，而不是散落在幾次事故檢討裡。
我喜歡把這件事想成一種「給 AI 用的內部城市地圖」。城市不是只有道路名稱，還有速限、單行道、禁行區、施工公告、消防通道和交通紀錄。你可以讓一台車自己導航，但前提是地圖不能只畫「這裡有路」。它還要知道哪些路可以走、什麼時候不能走、走錯了怎麼回報。
Agent 也是一樣。真正可用的 enterprise agent，不會只是比較會聊天、比較會推理、比較會呼叫工具。它還要活在一個清楚的能力地圖裡：工具有描述、權限有邊界、版本有紀錄、使用有追蹤、錯誤有回饋。
這些東西都不華麗，但很工程。
而很多時候，能不能把 AI 從 demo 帶進日常工作流，差的就是這些不華麗的部分。當 agent 會自己找工具之後，工具目錄就不再是附屬文件；它會變成企業 AI 架構裡的交通規則。規則寫得好，系統會越用越穩；規則寫得亂，越聰明的 agent 只會越快把混亂放大。