MiniMax M3 工具调用指南

是的，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

使用 auto，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，正在下雨。

这就是基本的智能体循环。

为什么必须保留工具调用历史

这是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 token的上下文。

MiniMax表示，其M3 API支持高达1M上下文，并保证基础设施上下文最低为512K tokens。

为什么这对工具调用很重要？

因为长期运行的智能体会累积上下文。

经过多个步骤后，模型可能需要记住：

• 原始用户指令
• 系统指令
• 之前的工具调用
• 工具结果
• 源代码
• 文件
• 错误
• 方案
• 中间决策

例如：

初始提示
+ 仓库上下文
+ 20 次工具调用
+ 20 个工具结果
+ 测试输出
+ 修改后的代码
+ 附加的用户指令

这些都会消耗上下文。

大上下文窗口为 M3 提供更大容量，能够处理长时间运行的工作流，而不会立即丢弃早期状态。

面向编程智能体的 MiniMax M3

编程是 M3 工具调用最清晰的使用场景之一。

模型本身不直接编辑你的仓库。

相反，你的智能体框架会提供如下工具：

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

然后，M3 可以使用这些工具完成任务。

例如：

修复此项目中的身份验证 bug。

工作流可能变为：

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 文档作为权威依据，了解确切的端点和支持的字段。

在多模型智能体栈中使用 MiniMax 模型

如果你的整个智能体都是围绕 MiniMax 构建的，直接集成 MiniMax 是有意义的。

但许多智能体开发者会测试多个模型。

你可能想比较：

• 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 显然专为工具调用密集的 Agent 工作流而设计。

评估它的最强理由有：

• 原生工具调用
• 多步推理
• 强代码能力
• 最高 1M 上下文
• 长时间运行 Agent 设计
• 原生多模态能力

它是否是你产品的最佳工具调用模型，仍取决于你自己的智能体。

客服智能体和编程智能体可能偏好不同的模型。

正确的评估不是：

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 token 的上下文。

MiniMax M3 适合编码智能体吗？

是的。编码和智能体任务是 M3 的两大主要目标工作负载。

围绕工作流而非单一提供商构建智能体

MiniMax M3 的工具调用之所以有用，是因为它是更广泛的智能体设计的一部分：模型可以分解任务、调用工具、处理结果，并在长工作流中继续运行。

不过，对于生产智能体，仍值得测试不止一个模型。

TokenHub 为支持的模型提供统一 API 层，让你无需针对每个提供商重建集成，即可比较不同的具备智能体能力的 LLM。

推荐内部链接

• 链接 TokenHub 到首页或模型目录。
• 链接 OpenAI 兼容 API 到 TokenHub API 文档。
• 之后链接 面向智能体与工具调用的最佳中文大语言模型 到相应的博客。
• 如可用，将相关的 GLM、Qwen、DeepSeek 或 Kimi 名称链接到其 TokenHub 模型页面。