Підключення 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 Router.
Маршрутизація моделей не надає агенту живі дані
Після налаштування маршрутизації моделей агент може вибрати кращий мозок для кожного кроку. Він все ще не може знати, що змінилося після навчальних даних моделі, отримати доступ до приватної бізнес-системи або виконати дію в іншому додатку, якщо інструмент не надає цю можливість.
Саме тут багато проектів агентів накопичують крихкий код. Команда підключає один 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 також публікує машинозчитуваний навик:
Налаштуйте 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 повідомляє про вирішену модель та політику маршрутизації для кожного запиту. Збереження сесій може зберегти консистентність моделі та переваги кешу запитів під час багатокрокової роботи, тоді як поведінка резервного копіювання може відходити від нездорової моделі, коли це необхідно.
З боку інструментів агент перевіряє поточну схему кінцевої точки перед здійсненням платного виклику. Результати виявлення включають інформацію, необхідну для порівняння кандидатів, а результат фактичного виклику стає єдиним зовнішнім доказом, переданим у фінальне завершення.
Разом ці контролі створюють корисний аудитний слід:
мета користувача
-> рішення маршрутизації та вирішена модель
-> виявлені кандидати на інструменти
-> перевірена схема та ціна
-> вибрана кінцева точка та результат
-> фінальне рішення моделі та обґрунтована відповідь
Цей слід є більш цінним, ніж просто доступ до багатьох моделей або багатьох 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 розділяє виявлення та перевірку від виконання, щоб рішення про інструмент можна було зафіксувати перед платним викликом.
