關於這個提一個我以為很多人都知道，但在公司講課過程中發現其實大家不知道的agent開發的重點技巧：tool-call，無論是function_calling還是MCP調用，都是分顯式和隱式兩種的。 1️⃣隱式調用：現代化的自動工具執行 最近的LLM都內置了自動工具調用能力。比如Gemini（你可以通過au tomatic_function_calling這個flag來控制這個特性）。由於官方文檔和示例都以隱式調用為主，如果你是最近兩個月才開始接觸MCP開發，你使用的很可能一直都是隱式模式。 在隱式模式下，整個工具調用流程對開發者來說是黑盒的。LLM自動判斷是否需要調用工具，自動選擇合適的工具和參數，自動執行工具並整合結果。開發者只需要提供工具列表，然後就能直接獲得最終的自然語言回答。 隱式是更新的技術，也是未來的趨勢，隨著大模型能力的進化，這種也應該會成為主流。 聰明的同學應該猜到了，誇完了，轉折就來了。沒錯，隱式有著暫時難以避免的缺點。

3️⃣顯式調用：精確控制的手動解析模式 相對的，顯式調用模式需要開發者手動處理工具調用的每個環節。你需要在系統提示中明確告訴LLM如何格式化工具調用請求，然後手動解析LLM回答中的工具調用指令，執行對應的工具，最後將結果整合到最終回答中。 這是古法調用MCP的方法（雖然也就傳統了半年而已），隱式只是把這部分也由LLM進行處理。 不過實際上現在實際開發裡使用的顯式調用，也並不是完全古法的。

4️⃣ 半自動回填式顯示調用 方法名稱是我亂起的。具體做法很簡單，你需要在MCP Client中，對於用戶的查詢，給LLM工具列表後，要求它不是自己調用工具，而是返回需要調用的工具的名稱。 接下來，你需要讓Client手動調用MCP Server。由於這部分數據很可能就是普通的API返回的格式化好的JSON data，因此你可以把這個和LLM的應答一起封裝起來返回。 這個方法適應範圍並不那麼寬泛，因為這要求多輪LLM對話，比單次對話還是要麻煩不少的。同時你的MCP HOST最好不是什麼都管的那種完全通用的chat客戶端，這個更適合固定的服務。 但好處就是有了raw data後，你可以完全自由處理數據，數據處理和UI顯示等代碼直接複用以前服務裡的部分即可。而且這種方法兼容並沒有自動工具調用的LLM。我們公司由我主導的新服務就是採用的這種方法，反響不錯。 另外有沒有其他方法，想聽聽各位大佬的經驗： @dotey @chaowxyz @hylarucoder @yihong0618 @pangyusio

Substack 版本：open.substack.com/pub/web3rove...…

Quaily: quaily.com/cryptonerdcn/p/disc...… @lyricwai @QuailyQuaily

一些關於各種誤解的回應：