Руководство по вызову инструментов MiniMax M3
Да, MiniMax M3 поддерживает вызов инструментов.
MiniMax позиционирует M3 специально для задач программирования и агентных сценариев, включающих автономное разложение задач, вызов инструментов и многошаговые рассуждения. Модель также поддерживает контекстное окно до 1M токенов, что призвано помогать в длительных агентных и кодинговых рабочих процессах.
Но вызов инструментов не означает, что 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 Tool Calling API
Текущая документация API генерации текста MiniMax включает 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)
Текущая документация API MiniMax явно перечисляет 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 поддерживает до 1 млн токенов контекста.
MiniMax заявляет, что его API M3 поддерживает контекст до 1M с гарантированным минимальным контекстом инфраструктуры в 512K токенов.
Почему это важно для вызова инструментов?
Потому что длинные агенты накапливают контекст.
После множества шагов модели может потребоваться запомнить:
- Первоначальные инструкции пользователя
- Системные инструкции
- Предыдущие вызовы инструментов
- Результаты инструментов
- Исходный код
- Файлы
- Ошибки
- Планы
- Промежуточные решения
Например:
Исходный запрос
+ контекст репозитория
+ 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 утверждает, что мультимодальное обучение было включено с самого начала, а не добавлено позже в виде отдельного адаптера, и модель поддерживает визуальное понимание как часть своих агентских возможностей.
Это может расширить возможности инструментальных агентов за пределы текста.
Например:
Проверить скриншот
↓
Понять состояние интерфейса
↓
Определить следующее действие
↓
Вызвать действие компьютера/инструмента
↓
Проверить результат
↓
ПродолжитьЭто полезно для браузерных агентов, задач по управлению компьютером, визуального 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 для своей экосистемы текстовых моделей, а её схема вызова инструментов следует знакомым концепциям, таким как инструменты, ассистент tool_calls, и сообщения с результатами инструментов.
Документация API MiniMax активно развивается вокруг M3, поэтому в производственных интеграциях всегда используйте актуальную документацию API M3 в качестве источника истины в отношении точного эндпоинта и поддерживаемых полей.
Использование моделей MiniMax в мультимодельном стеке агентов
Если весь ваш агент построен вокруг MiniMax, прямая интеграция MiniMax может иметь смысл.
Но многие разработчики агентов тестируют несколько моделей.
Возможно, вам захочется сравнить:
- MiniMax
- GLM
- Qwen
- DeepSeek
- Claude
- GPT
- Gemini
Качество вызова инструментов может различаться в зависимости от ваших реальных схем и рабочих процессов.
Одна модель может лучше выбирать инструменты.
Другая может быть лучше в написании кода.
Другая может быть дешевле для длинных циклов агента.
Именно здесь пригодится единый шлюз моделей.
Использование TokenHub для разработки агентов
TokenHub предоставляет API-шлюз, совместимый с OpenAI, для поддерживаемых моделей и документирует интеграции с такими инструментами, как Claude Code, Codex, Cursor, Cline, Aider, OpenCode и другими агентами разработчика.
Его базовый URL, совместимый с OpenAI:
https://us-api.tokenhub.com/v1
Вместо того чтобы переписывать всю архитектуру агента для каждого поставщика моделей, вы можете сохранить общий API-слой и выбирать модели из текущего каталога TokenHub.
Это особенно полезно при оценке моделей с вызовом инструментов, поскольку вы можете запускать того же агента, те же определения инструментов и те же задачи на разных поддерживаемых моделях.
Всегда используйте точный идентификатор модели, указанный в актуальном списке моделей TokenHub.
Подходит ли MiniMax M3 для вызова инструментов?
MiniMax M3 явно спроектирован для агентных процессов с активным использованием инструментов.
Самые веские причины рассмотреть его:
- Нативный вызов инструментов
- Многошаговое рассуждение
- Сильная ориентация на код
- Контекст до 1M
- Проектирование для длительных агентных сценариев
- Нативная мультимодальная поддержка
Является ли она лучшей моделью для вызова инструментов для вашего продукта, по-прежнему зависит от вашего собственного агента.
Агент поддержки клиентов и агент для написания кода могут предпочитать разные модели.
Правильная оценка — это не:
Поддерживает ли M3 инструменты?
Поддерживает.
Более правильный вопрос:
Может ли M3 надёжно выполнить мой реальный рабочий процесс используя мои реальные инструменты при приемлемой стоимости и задержке?
FAQ
Поддерживает ли MiniMax M3 вызов инструментов?
Да. Текущая документация API MiniMax поддерживает tools и tool_choice для MiniMax-M3.
Какой идентификатор модели MiniMax M3?
Текущее имя модели для прямого API:
MiniMax-M3
Какие значения параметра tool_choice поддерживает MiniMax M3?
В текущей документации текстового API указано:
auto
none
Выполняет ли MiniMax M3 инструменты самостоятельно?
Нет. Модель генерирует вызов инструмента и аргументы. Ваше приложение выполняет внешнюю функцию.
Что возвращает MiniMax M3, когда хочет вызвать инструмент?
Ответ ассистента может содержать “tool_calls массив, содержащий ID вызова инструмента, имя функции и аргументы в формате JSON.
Поддерживает ли MiniMax M3 контекстное окно размером 1M?
Да. MiniMax утверждает, что M3 поддерживает до 1M токенов контекста.
Подходит ли MiniMax M3 для агентов, пишущих код?
Да. Написание кода и агентные задачи — две основные целевые нагрузки M3.
Стройте своего агента вокруг рабочего процесса, а не вокруг одного провайдера.
Вызов инструментов MiniMax M3 полезен, поскольку является частью более широкой архитектуры агента: модель может разбивать задачи, вызывать инструменты, обрабатывать результаты и продолжать работу на протяжении длительных рабочих процессов.
Однако для продакшн-агента всё же стоит протестировать более одной модели.
TokenHub предоставляет единый API-слой для поддерживаемых моделей, позволяя сравнивать различные LLM с поддержкой агентных функций без перестройки вашей интеграции под каждого провайдера.
Рекомендуемые внутренние ссылки
- Привяжите TokenHub к главной странице или каталогу моделей.
- Привяжите OpenAI-совместимый API к документации TokenHub API.
- Позже привяжите Лучшие китайские LLM для агентов и вызова инструментов к соответствующему блогу.
- Связывайте соответствующие названия моделей GLM, Qwen, DeepSeek или Kimi с их страницами на TokenHub, если такие страницы доступны.