Подключение LLM достаточно для того, чтобы приложение генерировало текст. Но этого недостаточно, чтобы AI-агент выполнил реальную задачу.
Попросите модель подвести итоги документа, уже находящегося в ее контексте, и уровень модели будет достаточен. Попросите ее сравнить цены конкурентов на сегодня, обогатить запись о компании, проверить социальную учетную запись или выбрать лучший API для незнакомой задачи, и недостающая половина станет очевидной: агенту нужен надежный способ доступа к внешним системам.
Таким образом, производственный агент принимает два отдельных решения:
- Какая модель должна обрабатывать этот шаг?
- Какой инструмент или API должны предоставить данные или действие?
AIHubMix решает первую задачу с помощью единого доступа к моделям и маршрутизации моделей во время запроса. Monid решает вторую задачу с помощью обнаружения инструментов во время выполнения, инспекции схем и выполнения по модели "плати за вызов". Продукты находятся на разных уровнях одной и той же архитектуры.
Раскрытие информации: Эта статья была создана в рамках сотрудничества по контенту с Monid. AIHubMix — это платформа моделей, обсуждаемая ниже; Monid — это платформа инструментов. Каждую из них можно использовать независимо.
Две проблемы маршрутизации внутри AI-агента
Запуск агента редко представляет собой один однородный вызов модели. Исследовательский агент может классифицировать запрос, искать актуальную информацию, извлекать структурированные факты, сравнивать результаты и писать окончательный ответ. Эти шаги требуют различных возможностей.
То же самое верно и вне модели. Задача по исследованию компании может потребовать API поиска сегодня, конечную точку обогащения компании завтра и инструмент автоматизации браузера на следующей неделе. Если каждая модель и инструмент жестко закодированы на этапе сборки, каждая новая задача становится проектом интеграции.
Эти два уровня параллельны:
| Уровень модели | Уровень инструмента | |
|---|---|---|
| Основное решение | Какая модель должна ответить? | Какой API должен быть вызван? |
| Время выбора | На запрос | На задачу, во время выполнения |
| Входные данные | Запрос, модальность, требования к качеству и задержке | Цель, необходимые данные или действие, схема и цена |
| Выходные данные | Завершение модели | Внешние данные или выполненное действие |
| Пример | AIHubMix | Monid |
Это разделение имеет значение. Лучшая модель не может создать доступ к живым данным, а более крупный каталог инструментов не может рассуждать о данных, которые она возвращает. Агенту нужны обе возможности с четким контрактом между ними.
Monid представляет дополнительный взгляд со стороны инструмента в Почему AI-агенту нужны две интеграции. Со стороны модели архитектурный урок остается тем же: держите выбор модели и выбор инструмента независимыми, а затем оптимизируйте каждый уровень для своей задачи.
Почему одна фиксированная модель становится дорогой в цикле агента
Использование одной модели повсюду выглядит просто. На практике это заставляет каждый шаг принимать одинаковый компромисс между возможностями, задержкой и ценой.
Рассмотрим агента по исследованию рынка:
- Классификация намерений короткая и механическая.
- Выбор инструмента требует надежного следования инструкциям.
- Извлечение полей из возвращаемого JSON в основном является трансформацией.
- Окончательный отчет может потребовать более сильного рассуждения и лучшего написания.
Отправка всех четырех шагов в самую мощную модель тратит деньги на рутинную работу. Отправка всех четырех в самую дешевую модель может снизить качество единственного вывода, который читает пользователь. По мере роста цикла агента этот компромисс повторяется в каждом вызове.
AIHubMix предоставляет совместимый с OpenAI конечный пункт по широкому каталогу моделей. Существующая интеграция SDK OpenAI может указывать на AIHubMix, изменив API-ключ и base_url:
from openai import OpenAI
client = OpenAI(
api_key="<AIHUBMIX_API_KEY>",
base_url="https://aihubmix.com/v1",
)
response = client.chat.completions.create(
model="auto:balanced",
messages=[
{"role": "user", "content": "Классифицируйте этот запрос и предложите следующий шаг."}
],
)
Установка model на auto перемещает выбор модели в путь запроса. Маршрутизатор анализирует задачу и определяет подходящую модель. Суффикс политики делает цель оптимизации явной:
| Значение маршрутизатора | Приоритет | Типичный шаг агента |
|---|---|---|
auto |
Сначала стоимость | Пакетная работа и рутинные трансформации |
auto:balanced |
Возможности, стоимость и задержка | Работа общего назначения агента |
auto:quality_first |
Сначала возможности | Сложное рассуждение и окончательные результаты |
auto:latency_critical |
Сначала скорость | Интерактивные циклы и легкое планирование |
Маршрутизация не добавляет отдельную плату. Запрос выставляется по списочной цене модели, которая фактически его обработала. Разрешенная модель и детали маршрутизации отображаются в ответе, включая заголовок X-Aihubmix-Router-Resolved-Model, так что решение остается наблюдаемым, а не становится черным ящиком.
Полное поведение, поддерживаемые конечные точки, политики и текущие ограничения задокументированы в руководстве по маршрутизатору AIHubMix LLM.
Маршрутизация моделей не предоставляет агенту живые данные
После настройки маршрутизации моделей агент может выбрать лучший мозг для каждого шага. Тем не менее, он все еще не может знать, что изменилось после данных обучения модели, получить доступ к частной бизнес-системе или выполнить действие в другом приложении, если инструмент не предоставляет эту возможность.
Здесь многие проекты агентов накапливают хрупкий код. Команда подключает один API поиска, затем один API сканирования, затем один API обогащения. Каждая интеграция вводит еще одну учетную запись, учетные данные, формат запроса, модель ошибок и отношения по выставлению счетов. Описания инструментов часто копируются в системный запрос и медленно устаревают.
Режим сбоя опасен, потому что он может выглядеть успешным. Модель может создать правдоподобный вызов против устаревшей схемы, получить неполный ответ и продолжить, как будто задача была выполнена успешно. Инспекция схемы во время выполнения безопаснее, чем просить модель запомнить контракт API из обучения или из старого запроса.
Поэтому уровень инструмента должен ответить на три вопроса перед выполнением:
- Какой инструмент может удовлетворить эту цель?
- Какая схема и цена применимы прямо сейчас?
- Какой результат фактически вернул вызов?
Обнаружение инструментов — это второй уровень маршрутизации
Monid превращает доступ к инструментам в рабочий процесс обнаружения-инспекции-выполнения. Вместо того чтобы требовать от разработчика предсказать каждый API, который может понадобиться агенту, агент может искать в каталоге на естественном языке, инспектировать контракт кандидата и выполнять выбранную конечную точку.
Основной поток выглядит так:
# 1. Найдите инструменты, соответствующие цели
monid discover -q "найти текущие цены на продукты с публичной веб-страницы"
# 2. Прочитайте схему и цены выбранной конечной точки
monid inspect -p PROVIDER_SLUG -e ENDPOINT_PATH
# 3. Выполните только после того, как агент проверил контракт
monid run -p PROVIDER_SLUG -e ENDPOINT_PATH \
--query '{"url":"https://example.com/product"}'
Обнаружение и инспекция позволяют агенту сравнивать варианты, прежде чем он что-либо потратит. Выполнение выставляется по модели ценообразования выбранной конечной точки. Разработчик сохраняет одну интеграцию, в то время как агент получает доступ к инструментам от нескольких поставщиков.
Для сред выполнения агентов, которые могут читать инструкции по настройке, Monid также публикует машиночитаемое умение:
Set up https://monid.ai/SKILL.md
Документация по рабочему процессу Monid объясняет стадии каталога, инспекции и выполнения более подробно.
Как работают вместе два уровня
Шлюз модели и уровень инструмента должны оставаться отдельными компонентами с небольшим, четким переходом:
- Агент получает цель пользователя.
- AIHubMix маршрутизирует планировочный вызов к соответствующей модели.
- План выявляет недостающую информацию или необходимое внешнее действие.
- Monid обнаруживает кандидатов на инструменты и раскрывает их схемы и цены.
- Агент выбирает и запускает инструмент в рамках своих полномочий и бюджета.
- Инструмент возвращает факты или результат действия.
- AIHubMix маршрутизирует вызов синтеза в соответствии с требуемым качеством, стоимостью или задержкой.
- Агент возвращает ответ, основанный на результате инструмента.
В упрощенном Python вызовы со стороны модели могут оставаться неизменными, в то время как результат инструмента вставляется в контекст:
from openai import OpenAI
client = OpenAI(
api_key="<AIHUBMIX_API_KEY>",
base_url="https://aihubmix.com/v1",
)
# Быстрая модель достаточна для легкого планировочного шага.
plan = client.chat.completions.create(
model="auto:latency_critical",
messages=[
{
"role": "user",
"content": "Спланируйте, как сравнить текущие цены на эти продукты.",
}
],
)
# Ваш агент использует Monid для обнаружения, инспекции и запуска подходящего инструмента.
# Замените эти заполнители на структурированный результат, возвращенный этим вызовом.
tool_result = {
"source": "<source-url>",
"data": "<structured-tool-result>",
}
report = client.chat.completions.create(
model="auto:quality_first",
messages=[
{
"role": "system",
"content": (
"Напишите краткое сравнение. Используйте только предоставленный результат инструмента, "
"сохраняйте URL источников и указывайте, когда значение отсутствует."
),
},
{"role": "user", "content": str(tool_result)},
],
)
Важная деталь не в количестве строк. Дело в том, что ни один из выборов не нужно постоянно встраивать в логику приложения. Модель может изменяться по мере изменения запроса, а инструмент может изменяться по мере изменения задачи.
Контроль затрат должен быть на обоих уровнях
Затраты на модель и инструмент используют разные единицы, поэтому их следует измерять отдельно.
На уровне модели разрешенная модель определяет ценообразование токенов. AIHubMix делает это решение отслеживаемым и позволяет разработчикам выбирать политику маршрутизации или ограничивать модели, которые может использовать API-ключ. Рутинные шаги могут предпочитать стоимость или задержку, в то время как пользовательские выходные данные могут предпочитать качество.
На уровне инструмента конечная точка может взимать плату за вызов или за результат. Monid раскрывает цены во время инспекции, перед выполнением. Агент может отклонить конечную точку, которая превышает его бюджет, предпочесть проверенный вариант или запросить одобрение перед необычно дорогой операцией.
Полезные производственные контроли включают:
- Список разрешенных моделей или потолок цен для каждого API-ключа.
- Максимальный бюджет на вызов инструмента для каждой задачи.
- Списки разрешенных поставщиков или конечных точек для регулируемых данных.
- Журналы, которые связывают решение маршрутизации модели с вызовом инструмента и окончательным ответом.
- Явное подтверждение перед необратимыми или чувствительными действиями.
- Валидация выходных данных, чтобы данные инструмента рассматривались как ненадежный ввод, а не как инструкции.
Это разделение также упрощает отладку затрат. Если выполнение становится дорогим, журналы токенов показывают, рассуждал ли агент слишком много, в то время как журналы инструментов показывают, извлекал ли он слишком много. Исправления различны, и архитектура должна сохранять это различие.
Надежность требует свежих контрактов и видимых решений
Динамический выбор не должен означать непредсказуемое поведение.
Со стороны модели AIHubMix сообщает разрешенную модель и политику маршрутизации для каждого запроса. Привязка сессии может сохранить согласованность модели и преимущества кэширования запросов в многоповоротной работе, в то время как поведение резервирования может уйти от нездоровой модели, когда это необходимо.
Со стороны инструмента агент инспектирует текущую схему конечной точки перед тем, как сделать платный вызов. Результаты обнаружения включают информацию, необходимую для сравнения кандидатов, а результат фактического вызова становится единственным внешним доказательством, переданным в окончательное завершение.
Вместе эти контроли создают полезный след аудита:
user goal
-> routing decision and resolved model
-> discovered tool candidates
-> inspected schema and price
-> selected endpoint and result
-> final model decision and grounded response
Этот след более ценен, чем просто доступ к многим моделям или многим API. Он объясняет, почему агент сделал каждый выбор и какие доказательства поддерживали его ответ.
Когда вам не нужны оба уровня
Не каждый рабочий процесс выигрывает от выбора во время выполнения.
Если приложение отправляет один стабильный запрос одной протестированной модели, указание этой модели напрямую проще и более предсказуемо, чем маршрутизация. Если запланированный конвейер всегда вызывает один известный API, интеграция этого API напрямую может быть яснее, чем добавление уровня обнаружения.
Двухуровневая архитектура оправдывает свое место, когда разнообразие является частью рабочей нагрузки:
- Запросы достаточно различаются, чтобы лучшая модель менялась с шагом.
- Агенты делают несколько вызовов модели и нуждаются в контроле совокупных затрат или задержки.
- Необходимые инструменты не могут быть полностью предсказаны на этапе сборки.
- Внешние данные должны быть актуальными, и их источник должен быть видимым.
- Команда хочет добавлять возможности, не добавляя новую интеграцию поставщика для каждой из них.
Используйте уровень модели, уровень инструмента или оба в зависимости от решений, которые ваше приложение действительно должно принимать.
Стройте агента вокруг решений, а не зависимостей
Производственный AI-агент не определяется тем, сколько моделей или API он может достичь. Он определяется тем, может ли он выбрать правильную возможность для текущего шага, работать в рамках бюджета и объяснять, что произошло.
AIHubMix предоставляет агенту единый конечный пункт модели и маршрутизацию во время запроса с учетом приоритетов стоимости, качества и задержки. Monid предоставляет ему обнаружение инструментов во время выполнения, актуальные схемы, видимые цены и выполнение через внешних поставщиков.
Один уровень решает, как агент мыслит. Другой решает, как он узнает и действует. Сохранение этих решений отдельно приводит к агенту, который легче расширять, наблюдать и контролировать.
Начните с быстрого старта AIHubMix, а затем подключите сторону инструмента через Monid.
Часто задаваемые вопросы
Что такое маршрутизация моделей для AI-агентов?
Маршрутизация моделей выбирает модель для каждого запроса на основе таких факторов, как тип задачи, возможности, стоимость и задержка. С помощью AIHubMix установка model на auto или политику, такую как auto:quality_first, позволяет выбирать во время запроса, сохраняя совместимость с API OpenAI.
Почему AI-агенту нужны инструменты, если LLM уже обладает знаниями?
LLM генерирует ответы на основе контекста, который он получает, и того, что он узнал во время обучения. Он не может надежно знать текущие цены, запрашивать частную базу данных или выполнять внешнее действие без подключенного инструмента. Инструменты предоставляют живые данные и выполнение; модель планирует и интерпретирует результат.
Является ли шлюз модели тем же, что и сервер MCP или платформа инструментов?
Нет. Шлюз модели маршрутизует запросы на вывод к моделям. Серверы MCP и платформы инструментов открывают внешние возможности для агента. Они решают дополнительные проблемы интеграции и могут использоваться вместе.
Могут ли AIHubMix и Monid использоваться независимо?
Да. AIHubMix может маршрутизировать вызовы модели для приложений без динамических требований к инструментам. Monid может предоставить обнаружение инструментов для агентов, использующих другого поставщика модели или шлюз. Использование обоих полезно, когда агенту нужен выбор во время выполнения на обоих уровнях.
Как я могу сохранить автоматическую маршрутизацию подотчетной?
Записывайте разрешенную модель, политику маршрутизации, кандидата на инструмент, проверенную цену, выбранную конечную точку и возвращенный результат для каждой задачи. AIHubMix раскрывает детали маршрутизации модели в ответе, в то время как Monid отделяет обнаружение и инспекцию от выполнения, чтобы решение по инструменту можно было зафиксировать до платного вызова.




