用 Claude Code 久了會發現一種奇怪的 bug：你明確說「先 grep 一下這個 symbol」，它「嗯」一聲，然後直接憑記憶生出一個答案，工具呢？沒叫。又有時候你叫它「直接回答就好不用查」，它反而非要 Bash 一下。

我以前的解釋很俗——prompt 不夠用力、tool description 不夠精準、模型太懶。最近 Maryland 大學的論文〈Model-Adaptive Tool Necessity Reveals the Knowing-Doing Gap in LLM Tool Use〉（arXiv:2605.14038）讓我換了一個視角。模型不是不知道該叫工具——它知道，但在輸出層轉了 90 度。

兩階段分解：認知 vs 執行

論文做了一件方法論層面很值得記住的事——把「LLM 使用工具」這個動作切成兩階段：

  • Cognition（認知）：模型內部是不是相信「這題需要工具」。透過線性 probe 探測 hidden state 的方向，可以直接讀出模型的內部判斷。
  • Execution（執行）：模型實際輸出的 token 是不是 trigger 了 tool call。

兩階段都用 linear probe 抓得到——也就是說，「該不該叫工具」和「實際有沒有叫」都是模型內部明確可解碼的訊號，不是模糊的玄學。

但奇怪的事情就在這裡發生了：這兩個 probe 的方向，在最後一層的最後 token 位置（也就是真正控制下一個 token 生成的那個關鍵點），幾乎是互相垂直的。

中文裡這句話很容易讓人滑過去，所以拆開講一下。「正交」「垂直」在線性代數的語意是：兩個向量沒有相關性，一個的訊號完全 project 不到另一個上。也就是說，模型在前面幾層算出來「我該叫工具」這個結論，到了輸出層被另一套幾何結構接手——這套結構決定要不要產出 tool call token——而這套結構幾乎不看前面那個結論。

認知是一回事，動作是另一回事。中間轉了 90 度，訊號就漏光了。

26.5%-54% 的 mismatch 是怎麼算的

這個數字得搭配論文裡另一個概念才看得懂——Model-Adaptive Tool Necessity。

傳統評估會用標準答案來定義「該不該叫工具」：例如算術題就該用計算器，事實題就該查資料。論文覺得這太外加——對 GPT-5.4 來說是必要的工具，對 Qwen3-8B 可能根本不必要（或反過來）。

所以他們改用模型自己的能力來定義：當一個模型「不用工具會答錯、用了工具會答對」時，這題對這個模型而言工具就是必要的。這個定義方式內生於模型能力，不會被測試者的偏見污染。

定義好「真實必要」之後，再去比對模型實際的行為——結果就出來了：

模型 算術題 mismatch 事實 QA mismatch
Qwen3-4B 26.5% 41.8%
Llama-3.2-3B-Instruct 54.0% —
Qwen3-8B — 30.8%（區間下限）

mismatch 的意思是：模型「該叫卻沒叫」或「不該叫卻叫了」的比例。論文的 Sankey 圖裡，主導的失誤流向是「認知正確，但行動偏離了認知」——模型確實知道該叫工具，但實際輸出時沒叫。前者反過來的情況（認知錯但行動對）很少。

換成 prompt engineer 的語言：你寫了一個 system prompt 叫模型「需要查資料時用 search 工具」，模型內部讀了之後真的相信這題需要查資料——然後輸出層告訴你「不用了，我自己答」。你看到的失敗，不是它沒理解你，是它理解了但動作系統不買單。

對 Claude Code / Codex 使用者意味什麼

論文沒有測 Claude 或 GPT，測的是 Qwen3 和 Llama-3 兩個系列。但這個機制屬於 transformer 後期層的幾何性質，不太可能只發生在開源模型上。我會這樣對應到日常經驗：

1. 不要先怪 prompt。 過去我看到 tool call 不一致的第一反應是改 prompt——加強指令、放 few-shot、調整 tool description。論文暗示這條路有上限：你能影響的多半是 cognition 階段，但 cognition 階段往往已經對了，問題在後面那個轉 90 度的執行階段。改 prompt 不太能改變後期層的幾何結構。

2. 把決策外移。 Claude Code 有「auto-accept」「強制工具呼叫」「禁用 X 工具」這類配置，OpenAI 的 Codex 也有類似的 mode。論文等於給了這些設計一個科學理由——當模型內部的 cognition→action 轉換不可靠時，把這個決策搬出來、由 harness 強制執行，比指望模型「自己學會」更穩。Claude Code 在 systematic-debugging 這類 skill 裡會明確列出「必須用 X 工具」的硬規則，不是冗餘，是補了這個漏。

3. 換更大的模型不一定救得了你。 論文裡 Qwen3-8B 還是有 mismatch（30.8%+）。這個現象不會單純被「更多參數」沖掉，因為它是 transformer 表徵幾何學的結構問題。我不會說放大模型沒有幫助，但「規模化解決一切」這個直覺對 tool use 不適用。

4. A/B 測試 tool prompt 的時候，要留意性能上限。 論文最後留了一句很 prompt engineer 取向的話：常見的歸因（prompt 不夠好、訓練資料不夠）可能忽略後期層幾何結構——這也解釋了「為什麼你怎麼調 tool prompt，效能改善都會卡在某個天花板」。卡住的不是你的 prompt，是模型內部的訊號管線。

「Model-Adaptive」這個方法論本身值得記下

老實說，我覺得這篇論文最值錢的不是 mismatch 數字，是 model-adaptive 那個定義方式。

我做過內部的 LLM eval，過去寫 benchmark 都是「給標準答案、給標準工具用法、看模型有沒有跟上」。讀完這篇論文我意識到這個框架本身有問題——它預設了一個「外部正確」的尺度，但每個模型的內部能力剛好不一樣。

對自己模型而言不必要的工具，叫了反而是 over-tool（context 浪費、延遲增加、引入錯誤）；對自己模型而言必要的工具，沒叫就是 under-tool（直接答錯）。正確的評估，應該以每個模型自己的能力為錨點，這樣才能看清「該叫沒叫」和「不該叫卻叫」這兩條完全不同的失敗模式。

之後我自己做 agent eval，會把這條方法論借過來——先測一輪「無工具基準」，再測一輪「強制工具」，差異那部分就是這個模型對這項工具的真實必要區間。

結尾這條我會帶走

最近兩個禮拜我連續看到兩篇對「LLM Agent 設計直覺」打臉的論文：上一篇 〈Useful Memories Become Faulty When Continuously Updated by LLMs〉說「持續記憶讓 agent 越記越笨」，這篇說「模型知道該叫工具但動作系統不買單」。

共同的訊息是：LLM Agent 不該被當成一個「自我管理一切」的黑箱。記憶該外面管，tool use 該外面 gate，consolidation 該由 harness 觸發而不是模型偷偷自決。模型內部能力很強，但內部的訊號管線在很多地方會 silently 失敗——你看不到、prompt 也救不回來。

工程上的解：把更多決策搬到 harness 層，模型只負責它擅長的部分——理解任務、生成內容、判斷品質。「知道」交給模型，「做」交給程式碼。這聽起來像退步，其實是把 agent 系統設計從「LLM 自己會」拉回「我們知道哪些動作 LLM 不能被信任獨立完成」。

至少這禮拜開始，我自己寫 agent harness，會把「該不該叫這個 tool」做成 hard rule，不再交給模型「自己決定」。

參考資料