MiniMax M3 工具呼叫指南

EverydayChicHubAug 27, 2026

是的，MiniMax M3 支援工具呼叫。

MiniMax 將 M3 特別定位於程式設計及代理式工作負載，這些工作負載涉及自主任務分解、工具呼叫和多步驟推理。該模型亦支援高達 1M token 的上下文視窗，旨在協助長時間執行的代理與程式設計工作流程。

但工具呼叫並不表示 MiniMax M3 會直接執行你的 API 或函式。

實際流程如下：

定義工具
    ↓
將工具傳送給 MiniMax M3
    ↓
M3 回傳 tool_calls
    ↓
你的應用程式執行函式
    ↓
將結果傳回 M3
    ↓
M3 繼續執行或回傳最終答案

理解這個迴圈是在代理程式中正確使用 MiniMax M3 的關鍵。

什麼是 MiniMax M3 工具呼叫？

一般 LLM 請求的格式如下：

使用者 → 模型 → 回答

模型接收文字並回傳文字。

這適用於模型能從既有上下文回答的問題。

但假設使用者問：

東京現在的天氣如何？

模型不應自行編造即時天氣資料。

透過工具呼叫，你可以讓 M3 存取像這樣的函式：

get_weather(city)

工作流程變成：

使用者
  ↓
MiniMax M3
  ↓
get_weather(city="Tokyo")
  ↓
你的天氣 API
  ↓
目前天氣結果
  ↓
MiniMax M3
  ↓
最終回答

M3 決定 應該使用哪個工具以及它需要哪些參數。

你的應用程式決定 工具實際上做什麼。

MiniMax M3 工具呼叫 API

MiniMax 目前的文字生成 API 文件包含 MiniMax-M3 作為支援的模型，並提供：

tools
tool_choice
tool_calls

文件記載的端點為：

POST /v1/text/chatcompletion_v2

而目前 M3 模型的識別碼為：

MiniMax-M3

MiniMax 文件記載兩種tool_choice模式：

auto
none

使用 自動，M3 會自行判斷是否需要呼叫工具。

使用 none，工具使用會停用。

步驟 1：定義工具

假設我們想要 M3 檢查天氣資訊。

我們先向模型描述此函式：

{
  "type": "function",
  "function": {
    "name": "get_weather",
    "description": "Get the current weather for a city",
    "parameters": {
      "type": "object",
      "properties": {
        "city": {
          "type": "string",
          "description": "The city to get weather for"
        }
      },
      "required": ["city"]
    }
  }
}

MiniMax 目前支援 函式 作為工具類型。其 API 結構需要函式名稱、描述與參數定義。

此結構的品質至關重要。

如果你的工具描述模糊，模型在決定何時呼叫它時，能獲得的資訊就越少。

比較：

不佳：
取得資料。

而：

較佳：
取得指定城市的目前天氣、氣溫和天氣狀況。
當使用者詢問目前或未來天氣時，使用此工具。

第二個描述能提供模型更明確的工具選擇指引。

步驟 2：將工具傳送給 MiniMax M3

簡化後的 Python 請求範例如下：

import requests

url = "https://api.minimax.io/v1/text/chatcompletion_v2"

headers = {
    "Authorization": "Bearer YOUR_MINIMAX_API_KEY",
    "Content-Type": "application/json"
}

payload = {
    "model": "MiniMax-M3",
    "messages": [
        {
            "role": "user",
            "content": "What's the weather in Tokyo?"
        }
    ],
    "tools": [
        {
            "type": "function",
            "function": {
                "name": "get_weather",
                "description": "Get the current weather for a city",
                "parameters": {
                    "type": "object",
                    "properties": {
                        "city": {
                            "type": "string"
                        }
                    },
                    "required": ["city"]
                }
            }
        }
    ],
    "tool_choice": "auto"
}

response = requests.post(
    url,
    headers=headers,
    json=payload
)

data = response.json()
print(data)

目前的 MiniMax API 文件明確列出 MiniMax-M3 以及 tools 和 tool_choice 此端點的請求欄位。

步驟 3：讀取 M3 的工具呼叫

如果 M3 判斷需要工具，助理回應可包含一個 tool_calls 陣列。

MiniMax 使用以下欄位記錄每次呼叫：

id
type
function.name
function.arguments

概念上，結果可能如下所示：

{
  "tool_calls": [
    {
      "id": "call_123",
      "type": "function",
      "function": {
        "name": "get_weather",
        "arguments": "{\"city\":\"Tokyo\"}"
      }
    }
  ]
}

重點是：

M3 尚未執行任何操作。

它已產生一個結構化請求，內容為：

請執行 get_weather，參數為 city="Tokyo"。

您的應用程式現在需要解析參數並執行實際的函式。

步驟 4：在您的應用程式中執行工具

例如：

import json

tool_call = data["choices"][0]["message"]["tool_calls"][0]

function_name = tool_call["function"]["name"]
arguments = json.loads(
    tool_call["function"]["arguments"]
)

if function_name == "get_weather":
    result = get_weather(**arguments)

您自己的函式可能會呼叫真實的天氣服務並回傳：

{
  "city": "Tokyo",
  "temperature": 29,
  "condition": "Rain"
}

此結果來自你的工具，而非 MiniMax。

在開發正式環境的代理程式時，這個區別至關重要。

步驟 5：將工具結果傳回 M3

現在對話需要繼續進行。

您的應用程式應保留 M3 中包含工具呼叫的助理訊息，並將您函式的結果加入對話。

模型接著就能使用真實結果來產生最終答案。

MiniMax 特別說明，多輪函式呼叫的對話應保留完整的助理回應，包括工具呼叫資訊，如此才不會失去推理的連續性。

從概念上來說，歷史記錄會變成：

使用者：
東京的天氣如何？

助理：

[tool call: get_weather(city=”Tokyo”)]

工具：東京：29°C，雨助理：東京目前 29°C，正在下雨。

這就是基本的 Agent 迴圈。

為什麼你必須保留工具呼叫記錄

這是 MiniMax 文件中最重要的實作細節之一。

當工具呼叫發生時，不要只保留可見的文字。

保留完整的助理訊息。

為什麼？

因為下一個模型請求需要理解：

它請求了哪個工具
它產生了哪些參數
哪個結果屬於哪個呼叫
它目前處於任務的哪個步驟

如果丟棄該狀態，多步驟工具工作流程可能會變得不一致。

當代理執行更多呼叫時，這變得越來越重要。

使用多個工具

真正的代理通常會公開多個函式。

程式碼代理程式可能提供：

read_file
search_code
write_file
run_command
run_tests
git_diff

商務助理可能提供：

search_customer
get_order
issue_refund
create_ticket
send_email

使用者不需要指定要呼叫哪一個函式。

使用 tool_choice="auto"，模型可以根據要求從可用的工具中選取。

例如：

使用者：
找出登入測試失敗的原因並修正問題。

編碼代理程式可以執行以下操作：

search_code
    ↓
read_file
    ↓
run_tests
    ↓
read_file
    ↓
write_file
    ↓
run_tests
    ↓
git_diff

這就是工具呼叫轉變為 代理程式工作流程。

為什麼 MiniMax M3 專為此打造

工具呼叫本身並非 M3 獨有。

GPT、Claude、Gemini、Qwen、GLM 以及許多其他模型也支援工具。

M3 之所以有趣，在於 MiniMax 將模型高度聚焦於 長時間的工具執行.

MiniMax 表示 M3 具備自主任務分解、工具呼叫與多步驟推理能力。

該公司也發布了一項長時間執行的 CUDA 最佳化實驗，其中 M3 完成了：

147 項基準測試提交
1,959 次工具呼叫

在約 24 小時的自主最佳化工作流程中。

這並不表示每個應用程式都應該執行數千次工具呼叫。

這展示了 MiniMax 所追求的長期行為類型。

MiniMax M3 上下文視窗

M3 支援最高 1M 個上下文 tokens.

MiniMax 表示，其 M3 API 支援最高 1M 上下文，並保證最低基礎架構上下文為 512K token。

為什麼這對工具呼叫很重要？

因為長時間執行的代理會累積上下文。

在許多步驟之後，模型可能需要記住：

原始使用者指令
系統指令
先前的工具呼叫
工具結果
原始碼
檔案
錯誤
方案
中間決策

例如：

初始提示
+ 儲存庫上下文
+ 20 次工具呼叫
+ 20 個工具結果
+ 測試輸出
+ 修改後的程式碼
+ 額外的使用者指示

這一切都會消耗上下文。

大型上下文視窗讓 M3 在長時間執行的工作流程中擁有更多容量，而不會立即丟棄先前的狀態。

用於程式設計代理的 MiniMax M3

程式設計是 M3 工具呼叫最清晰的使用案例之一。

模型本身不會直接編輯你的儲存庫。

相反地，你的代理框架會提供工具，例如：

read_file(path)
write_file(path, content)
search_code(query)
run_command(command)
run_tests()

接著，M3 就能使用這些工具來完成任務。

例如：

修復此專案中的驗證錯誤。

工作流程可能會變成：

1. 搜尋驗證程式碼
2. 檢查相關檔案
3. 執行失敗的測試
4. 找出可能的原因
5. 修改實作
6. 再次執行測試
7. 檢查錯誤
8. 再進行一次變更
9. 驗證最終結果

這遠比一次性提示更接近實際的軟體工程，例如：

撰寫一個登入函式。

MiniMax 明確將 M3 定位於程式碼代理與自動化工作流程，而非僅限於單純的程式碼補全。

MiniMax M3 亦為多模態

M3 原生即為多模態。

MiniMax 表示，多模態訓練從一開始便已納入，而非日後另外加上獨立適配器；該模型也將視覺理解視為其代理能力的一部分。

這可將工具型代理擴展到文字以外的領域。

例如：

檢視截圖
      ↓
理解 UI 狀態
      ↓
決定下一步動作
      ↓
呼叫電腦／工具動作
      ↓
檢視結果
      ↓
繼續

這對於瀏覽器代理、電腦操作任務、視覺 QA 以及多模態開發工作流程都很實用。

MiniMax M3 工具呼叫與簡單函式呼叫

區分這兩個概念會很有幫助。

簡易函式呼叫

使用者提出問題
→ 模型選擇一個工具
→ 工具回傳資料
→ 模型回答

範例：

東京的天氣如何？

代理式工具呼叫

使用者提供一個目標
→ 模型規劃
→ 呼叫工具
→ 評估結果
→ 呼叫另一個工具
→ 變更計畫
→ 呼叫更多工具
→ 驗證結果
→ 完成目標

範例：

找出這個儲存庫中的錯誤、修正它，並確認測試通過。

M3 在第二個類別中更有趣得多。

MiniMax M3 工具呼叫的常見錯誤

1. 期望 M3 執行函式

並不會。

M3 會產生工具請求，並由你的應用程式執行。

2. 未保留助理的工具呼叫訊息

在多輪工作流程中，請保留與該工具呼叫相關的完整助理回應。MiniMax 在其相容性文件中特別指出了這點。

3. 使用模糊的工具描述

請勿定義：

do_task

而你可以定義：

search_customer_by_email

清晰明確的工具能讓模型更有可能做出正確選擇。

4. 賦予工具過多權限

如果你公開：

run_command

你的應用程式仍應執行權限、驗證、沙箱與安全規則。

模型不應成為你的基礎架構允許執行何事的最終決定者。

5. 將長上下文視為無限記憶體

1M 的上下文視窗雖大，但仍有限。

長期的代理程式執行應有意識地管理上下文，而不是無止盡地持續附加所有內容。

MiniMax M3 能否與 OpenAI 相容的工作流程搭配使用？

MiniMax 為其文字模型生態系統提供 OpenAI 相容的 API 支援，其工具呼叫架構遵循熟悉的概念，例如 tools、assistant tool_calls，以及工具結果訊息。

MiniMax 的 API 文件正圍繞 M3 持續演進，因此在正式環境整合時，您應一律以目前的 M3 API 文件為權威來源，以確認確切的端點與支援的欄位。

在多模型 Agent 堆疊中使用 MiniMax 模型

如果您的整個 Agent 都是圍繞 MiniMax 建構，直接整合 MiniMax 會是合理的做法。

但許多 Agent 開發者會測試多種模型。

您可能會想比較：

MiniMax
GLM
Qwen
DeepSeek
Claude
GPT
Gemini

工具呼叫的品質可能會因您的實際結構與工作流程而有所不同。

某個模型可能更擅長選擇工具。

另一個可能更擅長編寫程式。

另一種選擇在長時間的代理迴圈中可能更便宜。

這正是統一模型閘道派上用場的地方。

使用 TokenHub 進行代理開發

TokenHub 為支援的模型提供 OpenAI 相容的 API 閘道，並記錄與 Claude Code、Codex、Cursor、Cline、Aider、OpenCode 及其他開發代理的整合方式。

其 OpenAI 相容的 Base URL 為：

https://us-api.tokenhub.com/v1

你不需要為了每個模型提供者重寫整個代理架構，而是可以保留共同的 API 層，並從 TokenHub 目前的目錄中選擇模型。

在評估工具呼叫模型時，這特別有用，因為你可以執行相同的代理、相同的工具定義和相同的任務在不同的支援模型上。

一律使用 TokenHub 即時模型清單中顯示的確切模型 ID。

MiniMax M3 適合工具呼叫嗎？

MiniMax M3 明顯是針對大量使用工具的代理工作流程而設計。

最值得評估它的理由如下：

原生工具呼叫
多步驟推理
以程式碼為強項
高達 1M 上下文
長時間執行的代理設計
原生多模態能力

它是否是你產品的最佳工具呼叫模型，仍然取決於你自己的代理。

客服代理和編碼代理可能偏好不同的模型。

正確的評估不是：

M3 支援工具嗎？

有的。

更好的問題是：

M3 能否可靠地完成 我實際的工作流程 使用 我實際的工具 以可接受的成本與延遲？

常見問題

MiniMax M3 是否支援工具呼叫？

是的。MiniMax 目前的 API 文件支援 tools 與 tool_choice 用於 MiniMax-M3。

MiniMax M3 的模型 ID 是什麼？

目前的直接 API 模型名稱是：

MiniMax-M3

MiniMax M3 支援哪些 tool_choice 值？

目前的文字 API 文件說明：

auto
none

MiniMax M3 會自行執行工具嗎？

不會。模型會產生工具呼叫與參數，由你的應用程式執行外部函式。

MiniMax M3 想要呼叫工具時會回傳什麼？

助理回應可以包含一個 tool_calls 一個包含工具呼叫 ID、函式名稱與 JSON 格式引數的陣列。

MiniMax M3 是否支援 1M 的上下文視窗？

是的。MiniMax 表示 M3 的上下文長度最高可達 1M tokens。

MiniMax M3 適合用於程式碼代理（coding agent）嗎？

是的。程式碼與代理型任務是 M3 的兩大主要目標工作負載。

圍繞工作流程打造你的 Agent，而非單一供應商。

MiniMax M3 的工具呼叫功能之所以實用，在於它是更廣泛代理設計的一部分：模型能分解任務、呼叫工具、處理結果，並在長工作流程中持續執行。

不過，對於正式環境中的代理，仍值得測試多個模型。

TokenHub 為支援的模型提供統一的 API 層，讓你無須為每家供應商重新建置整合，即可比較不同具備代理能力的 LLM。

推薦的內部連結

連結 TokenHub 到首頁或模型目錄。
連結 OpenAI 相容 API 到 TokenHub API Docs。
之後連結 適用於智能體與工具呼叫的最佳中文 LLM 到對應的部落格。
如有的話，將相關的 GLM、Qwen、DeepSeek 或 Kimi 名稱連結至其 TokenHub 模型頁面。

下一頁GLM 5.2 OpenRouter API 指南

本頁目錄