Google已推出Gemini API的一項高度需求功能，允許在單一API呼叫中結合內建工具與自訂函式

Google已推出Gemini API的一項高度需求功能，允許在單一API呼叫中結合內建工具與自訂函式。這項功能目前處於預覽階段，僅支援Gemini 3模型。

工具 context 流通 Gemini 3的核心能力在於「工具context流通」機制，這使得模型能在單次生成中結合Google搜尋、Google地圖、檔案搜尋、URL Context等內建工具，並執行使用者定義的自訂函式。這樣的設計支援複雜的Agent工作流程，例如模型可先從即時網路資料驗證自身，再呼叫特定的商業邏輯函式。

啟用三步驟 實現這項功能需要三個步驟：

• 必須將include_server_side_tool_invocations標誌設為true以啟用工具context流通
• 需要將function_declarations與想使用的內建工具一同納入，以觸發組合行為
• 若使用者未納入function_declarations，工具context流通仍會作用在已包含的內建工具上，只要該標誌已設定

回應格式說明 API的回應會在單一響應中返回多個部分：

• 對於內建工具，API返回toolCall和toolResponse部分以保留伺服器端工具執行的context和結果
• 對於自訂函式，API返回functionCall部分供使用者執行，使用者在下一回合返回functionResponse
• 程式執行工具則返回executableCode和codeExecutionResult
• 所有部分必須在每次後續請求中完整返回給模型，以維護context並啟用工具組合

關鍵欄位說明 API返回的部分包含三個關鍵欄位：

• id（映射呼叫到回應的唯一識別碼，必須在函式回應中使用相同id）
• tool_type（識別特定工具的字面名稱）
• thought_signature（嵌入各部分的加密context）

Context無法在不使用thought_signature的情況下重建；若未在每回合返回所有部分的thought_signature，模型將出錯。

計費與定價 Google搜尋、Google地圖、URL Context和檔案搜尋等工具會返回特定工具類型的使用者可見資料。值得注意的是，toolCall和toolResponse部分在請求中計入prompt_token_count，因為這些中間工具步驟已可見且返回給使用者，形成對話歷史的一部分。此規則的例外是Google搜尋工具，其已套用自有的查詢層級定價模型，不會被重複計費。

已知限制 該功能有幾項限制：

• 啟用include_server_side_tool_invocations標誌時，必須預設為VALIDATED模式，AUTO模式不支援
• 由於Google搜尋等工具依賴位置和時間資訊，若系統指令或函式宣告描述中有衝突的位置與時間資訊，工具組合功能的效果可能不佳

支援工具清單 支援的工具包括：

• 伺服器端工具：Google搜尋、Google地圖、URL Context、檔案搜尋
• 程式執行工具（具有內建的context流通解決方案）
• 客戶端工具：電腦使用和自訂函式（亦具備內建的context流通支援）