工具使用是工程，不是魔法：為何 LLM 寧願胡謅也不願求助？

大型語言模型（LLM）的工具使用能力，並非與生俱來的魔法，而是在提示詞、執行合約與環境共同作用下，被「逼」出來的工程行為。許多開發者誤以為只要賦予模型工具權限，它就會在需要時自主調用，但近期的實驗顯示，模型天性更傾向產出「看似正確」的幻覺。理解這一點，並將工具使用視為一套需要精密設計的基礎設施，是打造可靠 AI 系統的關鍵第一步。這不僅是提示詞工程的延伸，更是系統架構層面的根本轉變。

一個競品分析任務，揭示模型的「惰性」

最近我做了一個簡單的實驗，想利用 OpenAI API 的工具使用功能來執行競品分析。任務很明確：針對一個「為都市雙薪家庭提供規格外蔬菜訂閱服務」的商業企劃，找出市場上的 5 家競爭對手，並以 JSON 格式回傳它們各自的優勢、劣勢與市場區隔。

為了確保資訊的即時性與準確性，我從一開始就賦予了模型（一個類似 gpt-5-mini 的版本）web_search 工具的權限。我預期它會主動上網搜尋，然後根據最新的公開資訊彙整報告。

結果出乎意料。模型確實回傳了 5 家公司的分析，包括 Oisix、らでぃっしゅぼーや、食べチョク等，這些都是日本市場上真實存在的知名品牌，內容看起來也相當合理。然而，整個回傳結果中，沒有附上任何一個引用來源。模型根本沒有使用我給它的 web_search 工具，而是選擇直接根據其內部知識庫，產出了一份「看似正確」的幻覺。

更有趣的轉折發生在後續調整。我僅僅在原有的提示詞中，加入了 3 行明確的指令，要求它「必須使用網路搜尋來驗證資訊」並「為每一項事實附上來源連結」。再次執行後，結果截然不同——不僅所有資訊都附上了來源，連回傳的公司名單本身都產生了變化。這個簡單的對照實驗，非常清晰地暴露了一個核心問題：工具就在那裡，但模型預設並不會主動去使用它。

為什麼模型寧願產生幻覺，也不願使用工具？

這個現象背後的根本原因，在於我們對模型行為的誤解。我們傾向用人類的心智模型去擬人化 LLM，認為它會「思考」並在「需要」時主動尋求外部資訊。但實際上，LLM 的核心機制是序列預測（sequence prediction），它的目標永遠是產出機率最高的下一個 token。

從模型的角度來看，這背後有兩個主要原因：

首先，**產生幻覺的「成本」對模型而言更低。** 模型的核心任務是預測下一個最可能的 token。直接從其龐大的訓練資料中組合出一段流暢、語義通順且「看起來像答案」的文字，在機率分佈上往往是一條更「平坦」的路徑。這就像是走一條熟悉的康莊大道，阻力最小。

其次，**工具呼叫的「成本」相對更高。** 呼叫一個工具，需要模型生成一段結構高度特定、語法嚴格的程式碼或 JSON 物件。這串 token 序列在龐大的語言空間中，屬於極低機率的事件。除非提示詞強烈地將模型引導至這個方向，否則它很難「剛好」走到這條路上，就像是要求它在茫茫大海中精準找到一根針。

這就是「工具使用是基礎設施，不是魔法」這個觀點的核心。我們提供給模型的工具定義（function signatures）、提示詞中的指令、以及後端實際執行工具的環境，共同構成了一套基礎設施。模型的工具使用行為，是我們在這套基礎設施上透過「執行合約」（run contract）所引導、甚至是強迫出來的。這個合約越模糊，模型就越傾向於退回它最擅長的事：編造故事。

模型的目標不是在人類意義上「正確」，而是預測出最可能的 token 序列。我們的任務，就是透過工程手段，讓「呼叫工具並使用其回傳結果」成為那個最可能的序列。

許多研究也佐證了這一點。從奠定基礎的 ReAct (Reasoning and Acting) 框架，到致力於讓模型掌握成千上萬真實世界 API 的 ToolLLM 計畫，其本質都是在研究如何設計更好的「合約」與「基礎設施」，來引導模型在複雜的任務中可靠地執行動作。

如何建立一個強健的工具使用框架？

將工具使用視為工程問題，意味著我們需要用系統化的方法來設計、引導與驗證，而非僅僅是把工具丟給模型然後祈禱它能正確使用。在實務上，這代表幾個關鍵的作法：

1. 在提示詞中建立強制性的「執行合約」：
指令必須極度明確。與其說「你可以使用搜尋工具」，不如說「針對這個問題，你『必須』使用 web_search 工具來尋找答案，禁止使用你的內部知識」。明確的觸發條件與限制，能顯著提高工具被呼叫的機率。這與 OpenAI 的官方文件所建議的最佳實踐是一致的。

2. 將工具的「說明文件」視為提示詞的一部分：
模型是透過工具的名稱（function name）與描述（description）來理解其功能的。一個名為 fetch_data 的工具遠不如 get_real_time_stock_price 來得清晰。工具的描述應該像一份給菜鳥工程師看的 API 文件，精準說明其用途、參數與回傳值。

3. 實作驗證與防護機制（Guardrails）：
絕對不要無條件信任模型的輸出。在接收到模型的工具呼叫請求後，應用程式層應該先進行驗證。例如，參數格式是否正確？呼叫的頻率是否過高？這層驗證是基礎設施不可或缺的一部分，如同 Brex 等公司在建立內部 Agent 框架時所強調的，穩健性來自於多層次的防護。

4. 設計具備自我修正能力的循環（Self-Correction Loop）：
當工具執行失敗或回傳非預期結果時，應該將錯誤訊息回傳給模型，並讓它有機會修正自己的行為。例如，如果一次搜尋沒有結果，提示詞可以引導它「嘗試用不同的關鍵字重新搜尋」。這種讓模型具備自我修正能力的模式，能大幅提升任務的成功率。

總結來說，讓 LLM 可靠地使用工具，是一項涉及提示詞、軟體架構與工作流程設計的綜合性工程挑戰。當我們不再將模型視為一個黑盒的智慧體，而是將其看作一個需要被精確引導、其行為需要被嚴格匡正的強大語言引擎時，我們才真正走在打造可信任 AI 系統的正確道路上。

延伸閱讀

• Yao, S., et al. (2022). "ReAct: Synergizing Reasoning and Acting in Language Models."
• Qin, Y., et al. (2023). "ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs."
• OpenAI. "Function calling." OpenAI API Documentation.
• Brex Engineering. "How we built our own LLM agent framework."
• Madaan, A., et al. (2023). "Self-Refine: Iterative Refinement with Self-Feedback."

我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。