Свързването на LLM е достатъчно, за да накара едно приложение да генерира текст. То не е достатъчно, за да накара AI агент да завърши реална задача.
Помолете модел да обобщи документ, който вече е в контекста му, и слоевете на модела са достатъчни. Помолете го да сравни цените на конкурентите днес, да обогати запис на компания, да провери социален акаунт или да избере най-добрия API за непозната работа, и липсващата половина става очевидна: агентът се нуждае от надежден начин да достигне до външни системи.
Следователно производственият агент взема две отделни решения:
- Кой модел трябва да се справи с тази стъпка?
- Кой инструмент или API трябва да предостави данните или действието?
AIHubMix адресира първото решение с обединен достъп до модели и маршрутизиране на модели в момента на заявката. Monid адресира второто с откриване на инструменти в реално време, инспекция на схеми и изпълнение на принципа "плащане на повикване". Продуктите се намират на различни слоеве на същата архитектура.
Разкритие: Тази статия беше създадена в рамките на сътрудничество за съдържание с Monid. AIHubMix е платформата за модели, обсъдена по-долу; Monid е платформата за инструменти. Всеки от тях може да се използва независимо.
Двата маршрутизиращи проблема в AI агента
Изпълнението на агента рядко е едно хомогенно извикване на модел. Изследователският агент може да класифицира заявка, да търси актуална информация, да извлече структурирани факти, да сравни резултати и да напише окончателен отговор. Тези стъпки изискват различни способности.
Същото важи и извън модела. Задачата за проучване на компания може да се нуждае от API за търсене днес, от крайна точка за обогатяване на компания утре и от инструмент за автоматизация на браузъра следващата седмица. Ако всеки модел и инструмент е закодиран по време на изграждане, всяка нова задача става проект за интеграция.
Двата слоя са паралелни:
| Слой на модела | Слой на инструмента | |
|---|---|---|
| Основно решение | Кой модел трябва да отговори? | Кой API трябва да бъде извикан? |
| Време за избор | На заявка | На задача, в реално време |
| Вход | Подсказка, модалност, нужди от качество и латентност | Цел, необходими данни или действие, схема и цена |
| Изход | Завършване на модел | Външни данни или изпълнено действие |
| Пример | AIHubMix | Monid |
Тази разделеност е важна. По-добър модел не може да създаде достъп до живи данни, а по-голям каталог от инструменти не може да разсъждава върху данните, които връща. Агентът се нуждае от двете способности, с ясна договореност между тях.
Monid представя допълнителния поглед от страна на инструмента в Защо AI агентът се нуждае от две интеграции. От страна на модела архитектурният урок е същият: поддържайте избора на модел и избора на инструмент независими, след това оптимизирайте всеки слой за собствената му работа.
Защо един фиксиран модел става скъп в цикъл на агент
Използването на един модел навсякъде изглежда просто. На практика, то принуждава всяка стъпка да приема същия компромис между способност, латентност и цена.
Помислете за агент за пазарни изследвания:
- Класификацията на намеренията е кратка и механична.
- Изборът на инструмент изисква надеждно следване на инструкции.
- Извличането на полета от върнат JSON е предимно трансформация.
- Окончателният доклад може да изисква по-силно разсъждение и по-добро писане.
Изпращането на всичките четири стъпки до най-способния модел харчи пари за рутинна работа. Изпращането на всичките четири до най-евтиния модел може да намали качеството на единствения изход, който потребителят чете. С нарастването на цикъла на агента, този компромис се повтаря при всяко извикване.
AIHubMix предоставя OpenAI-съвместима крайна точка в широк каталог от модели. Съществуваща интеграция на OpenAI SDK може да насочи към 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 от обучението или от стара подсказка.
Слойът на инструмента следователно трябва да отговори на три въпроса преди изпълнение:
- Кой инструмент може да задоволи тази цел?
- Коя схема и цена важат в момента?
- Какъв резултат всъщност е върнало извикването?
Откритие на инструменти е вторият маршрутизиращ слой
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 позволява избор в момента на заявката, запазвайки съвместимост с OpenAI API.
Защо AI агентът се нуждае от инструменти, ако LLM вече има знания?
LLM генерира отговори от контекста, който получава, и от това, което е научил по време на обучението. Той не може надеждно да знае текущите цени, да запитва частна база данни или да извършва външно действие без свързан инструмент. Инструментите предоставят живи данни и изпълнение; моделът планира и интерпретира резултата.
Дали моделният шлюз е същият като MCP сървър или платформа за инструменти?
Не. Моделният шлюз маршрутизира заявки за инференция към модели. MCP сървърите и платформите за инструменти разкриват външни способности на агент. Те решават допълнителни интеграционни проблеми и могат да се използват заедно.
Могат ли AIHubMix и Monid да се използват независимо?
Да. AIHubMix може да маршрутизира извиквания на модели за приложения без динамични изисквания за инструменти. Monid може да предостави откритие на инструменти на агенти, използващи друг доставчик на модели или шлюз. Използването на двете е полезно, когато агентът се нуждае от избор в реално време на двата слоя.
Как мога да запазя автоматичната маршрутизация одитируема?
Записвайте разрешения модел, политика на маршрутизиране, кандидат за инструмент, инспектирана цена, избрана крайна точка и върнат резултат за всяка задача. AIHubMix разкрива детайли за маршрутизация на модела в отговора, докато Monid отделя откритията и инспекцията от изпълнението, така че решението за инструмента да може да бъде записано преди платеното извикване.
