大部分人設計 agent 的思路是加功能：需要搜尋就加搜尋工具、需要查日曆就加日曆工具。工具清單就這樣長到十幾二十個，然後一件事悄悄發生：agent 還是在呼叫工具，只是選的越來越不對，沒有報錯、沒有警告，只有答案品質慢慢變差。今天講這件事背後的力學，以及真實系統的三種對策。

換個定性：Tool Selection 是 N-class 分類

Agent 選工具時做的事是：給定使用者的意圖，從 N 個候選裡挑一個。這是一道 N 選一的分類題，而 N 越大題目越難，這件事有數字：HumanMCP 的量測裡，工具從 10 個增加到 100 個，各家模型的 top-1 命中率掉了約 10%；LongFuncEval 把工具目錄從 8K token 加到 120K token，不同模型的表現下滑從 7.59% 到 85.58% 不等。

更關鍵的發現來自針對 multi-instance 退化的研究（arXiv 2603.22608）：候選數量本身對退化的影響，比 context 長度更強。就算窗口夠大、工具描述夠短，選項變多這件事本身就在傷準確率。「context window 夠大就沒問題」的直覺，在這裡直接失效。

三個獨立的崩潰機制

注意力被稀釋。 工具描述是 context 的一部分，Day 2（Prompt 為什麼有效）的零和競爭對它照樣成立。二十份工具說明書躺在窗口裡，每一份都在跟使用者的問題搶注意力。

語意邊界模糊。 這是最核心的一個。search_docs、search_confluence、search_internal_kb 在語意空間裡擠成一團，使用者說「幫我找上週的會議記錄」，四個工具都沾邊。ToolScope 的研究指出，描述重疊造成的歧義會同時傷檢索和選擇的準確率，而且這跟數量無關：就算只有四個工具，語意邊界糊掉照樣選錯。換更強的模型救不了，因為這是工具設計的問題。

指令遵循品質下降。 工具越多，system prompt 裡「什麼情況用哪個」的邊界條件就越多，而模型的指令遵循品質隨指令複雜度非線性下降。想用「寫更詳細的規則」來救選錯，方向本身就是反的。

三個系統，三種對策

DeerFlow：懶加載。 Day 11（記憶的檢索）介紹過的這個 ByteDance research agent 框架，工具多的時候只給模型一個工具：tool_search。agent 先搜自己需要什麼工具，選中的那個 schema 才注入 prompt。它的文件講得很直白：MCP 工具可能幾十上百個，全部注入 prompt 太貴。代價是多一次呼叫，換到的是每次選擇時窗口乾淨。這正是 Day 8（窗口經濟學）progressive disclosure 的工具版。

HermesAgent：啟動時切割。 依 agent 的用途在初始化時就決定它看得到哪些工具，做研究的看不到部署工具，寫程式的看不到訂票工具。選項數在源頭就被砍下來。

OpenClaw：政策白名單。 OpenClaw（自托管的開源 agent 平台，就是社群常暱稱的「小龍蝦」）用 per-agent 的白名單設定：每個 agent 能用什麼工具是管理面的政策，跟 prompt 無關。這個做法會在明天的權限主題再出現，因為「看得到什麼工具」本身就是一種權限。

三個對策的共同點：減少模型同時看到的選項數。描述寫得再好，也替代不了縮小 N 這件事，因為分類問題的難度就長在 N 上。

可以直接用的三條準則

一、同時可見的工具收在十個上下，更多就引入分層或懶加載。二、語意邊界用參數解，不用名字解：與其開四個 search_* 工具，不如一個 search(source=docs|confluence|kb)，把易混淆的選擇從「分類題」降級成「填參數」。三、描述當 prompt 寫（Day 5 講 schema 時的同一課）：一句話說清楚「什麼時候用我」，跟隔壁工具的差異點寫進去。

適用邊界照慣例標清楚：你的 agent 只有五六個語意分明的工具，以上機制一個都不用上，全展開就是最好的設計。

手腳有了，還缺讓它動的機制

工具定義得再好，它也只是一張能力清單。agent 真正跑起來，靠的是一個循環：模型決定呼叫哪個工具、系統執行、結果回到窗口、模型再決定下一步。這個循環怎麼設計，決定了工具失敗算誰的、任務跑到一半怎麼停、停了怎麼續。明天講 Agentic Loop：agent 的心臟長什麼樣。