Architektura agenta AI: Routing modeli i odkrywanie narzędzi

Podłączenie LLM wystarczy, aby aplikacja generowała tekst. To jednak nie wystarczy, aby agent AI wykonał zadanie w rzeczywistym świecie.

Poproś model o podsumowanie dokumentu już znajdującego się w jego kontekście, a warstwa modelu będzie wystarczająca. Poproś go o porównanie cen konkurencji z dzisiaj, wzbogacenie rekordu firmy, sprawdzenie konta w mediach społecznościowych lub wybór najlepszego API do nieznanego zadania, a brakująca połowa staje się oczywista: agent potrzebuje niezawodnego sposobu na dotarcie do systemów zewnętrznych.

Agent produkcyjny podejmuje zatem dwie oddzielne decyzje:

1. Który model powinien obsłużyć ten krok?
2. Które narzędzie lub API powinno dostarczyć dane lub akcję?

AIHubMix zajmuje się pierwszą decyzją, oferując zjednoczony dostęp do modeli i routing modeli w czasie żądania. Monid zajmuje się drugą decyzją, oferując odkrywanie narzędzi w czasie działania, inspekcję schematów i wykonanie na zasadzie płatności za wywołanie. Produkty te znajdują się na różnych warstwach tej samej architektury.

Ujawnienie: Artykuł ten został stworzony w ramach współpracy treściowej z Monid. AIHubMix to platforma modeli omówiona poniżej; Monid to platforma narzędzi. Każda z nich może być używana niezależnie.

Dwa problemy routingu wewnątrz agenta AI

Uruchomienie agenta rzadko polega na jednym jednolitym wywołaniu modelu. Agent badawczy może sklasyfikować żądanie, wyszukać aktualne informacje, wyodrębnić uporządkowane fakty, porównać wyniki i napisać ostateczną odpowiedź. Te kroki wymagają różnych możliwości.

To samo dotyczy sytuacji poza modelem. Zadanie badawcze dotyczące firmy może wymagać API wyszukiwania dzisiaj, punktu końcowego wzbogacania firmy jutro, a narzędzia automatyzacji przeglądarki w przyszłym tygodniu. Jeśli każdy model i narzędzie są zakodowane na stałe w czasie budowy, każde nowe zadanie staje się projektem integracyjnym.

Te dwie warstwy są równoległe:

To rozdzielenie ma znaczenie. Lepszy model nie może stworzyć dostępu do danych na żywo, a większy katalog narzędzi nie może rozumować nad danymi, które zwraca. Agent potrzebuje obu możliwości, z wyraźnym kontraktem między nimi.

Monid przedstawia komplementarny widok strony narzędzi w Dlaczego agent AI potrzebuje dwóch integracji. Z perspektywy modelu lekcja architektoniczna jest ta sama: utrzymuj niezależność wyboru modelu i wyboru narzędzia, a następnie optymalizuj każdą warstwę do jej własnej pracy.

Dlaczego jeden stały model staje się drogi w pętli agenta

Używanie jednego modelu wszędzie wydaje się proste. W praktyce zmusza to każdy krok do akceptacji tej samej wymiany między możliwościami, opóźnieniem a ceną.

Rozważ agenta badań rynkowych:

• Klasyfikacja intencji jest krótka i mechaniczna.
• Wybór narzędzia wymaga niezawodnego przestrzegania instrukcji.
• Wyodrębnianie pól z zwróconego JSON to głównie transformacja.
• Ostateczny raport może wymagać silniejszego rozumowania i lepszego pisania.

Wysyłanie wszystkich czterech kroków do najbardziej zdolnego modelu marnuje pieniądze na rutynowej pracy. Wysyłanie wszystkich czterech do najtańszego modelu może obniżyć jakość jedynego wyjścia, które użytkownik czyta. W miarę jak pętla agenta rośnie, ten kompromis powtarza się w każdym wywołaniu.

AIHubMix zapewnia punkt końcowy zgodny z OpenAI w szerokim katalogu modeli. Istniejąca integracja SDK OpenAI może wskazywać na AIHubMix, zmieniając klucz API i 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": "Sklasyfikuj to żądanie i zaproponuj następny krok."}
    ],
)

Ustawienie model na auto przenosi wybór modelu do ścieżki żądania. Router analizuje zadanie i przypisuje je do odpowiedniego modelu. Sufiks polityki czyni cel optymalizacji wyraźnym:

Routing nie dodaje osobnej opłaty. Żądanie jest rozliczane według ceny katalogowej modelu, który faktycznie je obsłużył. Rozwiązany model i szczegóły routingu są ujawniane w odpowiedzi, w tym nagłówek X-Aihubmix-Router-Resolved-Model, dzięki czemu decyzja pozostaje widoczna, a nie staje się czarną skrzynką.

Pełne zachowanie, obsługiwane punkty końcowe, polityki i aktualne ograniczenia są udokumentowane w przewodniku AIHubMix LLM Router.

Routing modeli nie daje agentowi danych na żywo

Po skonfigurowaniu routingu modeli agent może wybrać lepszy mózg dla każdego kroku. Nadal nie może wiedzieć, co się zmieniło po danych treningowych modelu, uzyskać dostęp do prywatnego systemu biznesowego ani wykonać akcji w innej aplikacji, chyba że narzędzie zapewnia tę możliwość.

To tutaj wiele projektów agentów gromadzi kruchy kod. Zespół łączy jedno API wyszukiwania, potem jedno API skrobania, a następnie jedno API wzbogacania. Każda integracja wprowadza kolejne konto, poświadczenie, format żądania, model błędu i relację rozliczeniową. Opisy narzędzi często są kopiowane do podpowiedzi systemowej i powoli stają się nieaktualne.

Tryb awarii jest niebezpieczny, ponieważ może wyglądać na udany. Model może wygenerować wiarygodne wywołanie przeciwko nieaktualnemu schematowi, otrzymać niekompletną odpowiedź i kontynuować, jak gdyby zadanie się powiodło. Inspekcja schematu w czasie działania jest bezpieczniejsza niż proszenie modelu o zapamiętanie kontraktu API z treningu lub z starej podpowiedzi.

Warstwa narzędzi powinna zatem odpowiedzieć na trzy pytania przed wykonaniem:

1. Jakie narzędzie może zaspokoić ten cel?
2. Jaki schemat i cena obowiązują w tej chwili?
3. Jaki wynik faktycznie zwróciło wywołanie?

Odkrywanie narzędzi jest drugą warstwą routingu

Monid przekształca dostęp do narzędzi w workflow odkrywania-inspekcji-wykonania. Zamiast wymagać od programisty przewidywania każdego API, które agent może potrzebować, agent może przeszukiwać katalog w języku naturalnym, inspekcjonować kontrakt kandydata i wykonywać wybrany punkt końcowy.

Podstawowy przepływ wygląda tak:

# 1. Znajdź narzędzia, które pasują do celu
monid discover -q "znajdź aktualne ceny produktów z publicznej strony internetowej"

# 2. Przeczytaj schemat i ceny wybranego punktu końcowego
monid inspect -p PROVIDER_SLUG -e ENDPOINT_PATH

# 3. Wykonaj tylko po tym, jak agent sprawdził kontrakt
monid run -p PROVIDER_SLUG -e ENDPOINT_PATH \
  --query '{"url":"https://example.com/product"}'

Odkrywanie i inspekcja pozwalają agentowi porównać opcje, zanim wyda jakiekolwiek pieniądze. Wykonanie jest rozliczane zgodnie z modelem cenowym wybranego punktu końcowego. Programista utrzymuje jedną integrację, podczas gdy agent zyskuje dostęp do narzędzi z różnych dostawców.

Dla czasów działania agenta, które mogą czytać instrukcje konfiguracyjne, Monid publikuje również umiejętność czytelną maszynowo:

Skonfiguruj https://monid.ai/SKILL.md

Dokumentacja workflow Monid wyjaśnia etapy katalogu, inspekcji i wykonania w większych szczegółach.

Jak dwie warstwy współpracują ze sobą

Brama modelu i warstwa narzędzi powinny pozostać oddzielnymi komponentami z małym, wyraźnym przekazaniem:

1. Agent otrzymuje cel użytkownika.
2. AIHubMix kieruje wywołanie planowania do odpowiedniego modelu.
3. Plan identyfikuje brakujące informacje lub wymaganą akcję zewnętrzną.
4. Monid odkrywa kandydatów na narzędzia i ujawnia ich schematy i ceny.
5. Agent wybiera i uruchamia narzędzie w ramach swoich uprawnień i budżetu.
6. Narzędzie zwraca fakty lub wynik akcji.
7. AIHubMix kieruje wywołanie syntezy zgodnie z wymaganą jakością, kosztem lub opóźnieniem.
8. Agent zwraca odpowiedź opartą na wyniku narzędzia.

W uproszczonym Pythonie wywołania po stronie modelu mogą pozostać niezmienione, podczas gdy wynik narzędzia jest wstawiany jako kontekst:

from openai import OpenAI

client = OpenAI(
    api_key="<AIHUBMIX_API_KEY>",
    base_url="https://aihubmix.com/v1",
)

# Szybki model jest wystarczający do lekkiego kroku planowania.
plan = client.chat.completions.create(
    model="auto:latency_critical",
    messages=[
        {
            "role": "user",
            "content": "Zaplanuj, jak porównać aktualne ceny tych produktów.",
        }
    ],
)

# Twój agent używa Monid do odkrywania, inspekcji i uruchamiania odpowiedniego narzędzia.
# Zastąp te miejsca wynikami strukturalnymi zwróconymi przez to wywołanie.
tool_result = {
    "source": "<source-url>",
    "data": "<structured-tool-result>",
}

report = client.chat.completions.create(
    model="auto:quality_first",
    messages=[
        {
            "role": "system",
            "content": (
                "Napisz zwięzłe porównanie. Użyj tylko dostarczonego wyniku narzędzia, "
                "zachowaj źródłowe URL-e i wskaź, kiedy wartość jest brakująca."
            ),
        },
        {"role": "user", "content": str(tool_result)},
    ],
)

Ważnym szczegółem nie jest liczba linii. Chodzi o to, że żadna z decyzji nie musi być na stałe osadzona w logice aplikacji. Model może się zmieniać w miarę zmiany podpowiedzi, a narzędzie może się zmieniać w miarę zmiany zadania.

Kontrola kosztów należy do obu warstw

Koszty modeli i narzędzi używają różnych jednostek, więc powinny być mierzone oddzielnie.

Na warstwie modelu rozwiązany model określa ceny tokenów. AIHubMix sprawia, że ta decyzja jest śledzona i pozwala programistom wybrać politykę routingu lub ograniczyć modele, które klucz API może używać. Rutynowe kroki mogą preferować koszt lub opóźnienie, podczas gdy wyjścia skierowane do użytkownika mogą preferować jakość.

Na warstwie narzędzi punkt końcowy może pobierać opłatę za wywołanie lub za wynik. Monid ujawnia ceny podczas inspekcji, przed wykonaniem. Agent może odrzucić punkt końcowy, który przekracza jego budżet, preferować zweryfikowaną opcję lub poprosić o zatwierdzenie przed nietypowo drogą operacją.

Przydatne kontrole produkcyjne obejmują:

• Lista dozwolonych modeli lub sufit cenowy dla każdego klucza API.
• Maksymalny budżet na wywołanie narzędzia na zadanie.
• Listy dozwolonych dostawców lub punktów końcowych dla regulowanych danych.
• Dzienniki łączące decyzję o routingu modelu z wywołaniem narzędzia i ostateczną odpowiedzią.
• Wyraźne potwierdzenie przed nieodwracalnymi lub wrażliwymi działaniami.
• Walidacja wyjścia, aby dane narzędzi były traktowane jako niezaufane wejście, a nie jako instrukcje.

To rozdzielenie ułatwia również debugowanie kosztów. Jeśli wykonanie staje się drogie, dzienniki tokenów pokazują, czy agent zbyt dużo rozumował, podczas gdy dzienniki narzędzi pokazują, czy zbyt dużo pobrał. Naprawy są różne, a architektura powinna zachować tę różnicę.

Niezawodność wymaga świeżych kontraktów i widocznych decyzji

Dynamika wyboru nie powinna oznaczać nieprzewidywalnego zachowania.

Po stronie modelu AIHubMix raportuje rozwiązany model i politykę routingu dla każdego żądania. Utrzymywanie spójności modelu i korzyści z pamięci podręcznej podpowiedzi w pracy wieloetapowej, podczas gdy zachowanie awaryjne może odejść od niezdrowego modelu, gdy to konieczne.

Po stronie narzędzi agent inspekcjonuje aktualny schemat punktu końcowego przed dokonaniem płatnego wywołania. Wyniki odkrywania zawierają informacje potrzebne do porównania kandydatów, a wynik faktycznego wywołania staje się jedynym zewnętrznym dowodem przekazywanym do ostatecznego ukończenia.

Razem te kontrole tworzą użyteczny ślad audytu:

cel użytkownika
  -> decyzja o routingu i rozwiązany model
  -> odkryte kandydaty na narzędzia
  -> inspekcja schematu i ceny
  -> wybrany punkt końcowy i wynik
  -> ostateczna decyzja modelu i ugruntowana odpowiedź

Taki ślad jest bardziej wartościowy niż po prostu dostęp do wielu modeli lub wielu API. Wyjaśnia, dlaczego agent podjął każdą decyzję i jakie dowody wspierały jego odpowiedź.

Kiedy nie potrzebujesz obu warstw

Nie każdy workflow korzysta z wyboru w czasie działania.

Jeśli aplikacja wysyła jedną stabilną podpowiedź do jednego benchmarkowanego modelu, bezpośrednie określenie tego modelu jest prostsze i bardziej deterministyczne niż routing. Jeśli zaplanowany pipeline zawsze wywołuje jedno znane API, bezpośrednia integracja tego API może być jaśniejsza niż dodawanie warstwy odkrywania.

Architektura dwu-warstwowa zasługuje na swoje miejsce, gdy różnorodność jest częścią obciążenia:

• Podpowiedzi różnią się na tyle, że najlepszy model zmienia się w zależności od kroku.
• Agenci wykonują wiele wywołań modelu i muszą kontrolować skumulowane koszty lub opóźnienia.
• Wymagane narzędzia nie mogą być w pełni przewidziane w czasie budowy.
• Dane zewnętrzne muszą być aktualne, a ich źródło musi być widoczne.
• Zespół chce dodać możliwości bez dodawania nowej integracji dostawcy dla każdej z nich.

Użyj warstwy modelu, warstwy narzędzi lub obu zgodnie z decyzjami, które Twoja aplikacja rzeczywiście musi podjąć.

Buduj agenta wokół decyzji, a nie zależności

Produkcja agenta AI nie jest definiowana przez to, ile modeli lub API może osiągnąć. Jest definiowana przez to, czy może wybrać odpowiednią możliwość dla bieżącego kroku, działać w ramach budżetu i wyjaśnić, co się wydarzyło.

AIHubMix daje agentowi zjednoczony punkt końcowy modelu i routing w czasie żądania w oparciu o priorytety kosztów, jakości i opóźnienia. Monid zapewnia odkrywanie narzędzi w czasie działania, aktualne schematy, widoczne ceny i wykonanie wśród zewnętrznych dostawców.

Jedna warstwa decyduje, jak agent myśli. Druga decyduje, jak się dowiaduje i działa. Utrzymanie tych decyzji oddzielnie produkuje agenta, który jest łatwiejszy do rozszerzenia, obserwacji i kontroli.

Rozpocznij od szybkiego startu AIHubMix, a następnie połącz stronę narzędziową przez Monid.

FAQ

Czym jest routing modeli dla agentów AI?

Routing modeli wybiera model dla każdego żądania na podstawie czynników takich jak typ zadania, możliwości, koszt i opóźnienie. Dzięki AIHubMix ustawienie model na auto lub politykę taką jak auto:quality_first umożliwia wybór w czasie żądania, zachowując zgodność z API OpenAI.

Dlaczego agent AI potrzebuje narzędzi, jeśli LLM już ma wiedzę?

LLM generuje odpowiedzi na podstawie kontekstu, który otrzymuje, i tego, czego nauczył się podczas treningu. Nie może wiarygodnie znać aktualnych cen, zapytać prywatnej bazy danych ani wykonać akcji zewnętrznej bez podłączonego narzędzia. Narzędzia dostarczają dane na żywo i wykonanie; model planuje i interpretuje wynik.

Czy brama modelu jest tym samym co serwer MCP lub platforma narzędziowa?

Nie. Brama modelu kieruje żądania wnioskowania do modeli. Serwery MCP i platformy narzędziowe ujawniają zewnętrzne możliwości agentowi. Rozwiązują komplementarne problemy integracyjne i mogą być używane razem.

Czy AIHubMix i Monid mogą być używane niezależnie?

Tak. AIHubMix może kierować wywołaniami modeli dla aplikacji, które nie mają dynamicznych wymagań dotyczących narzędzi. Monid może zapewnić odkrywanie narzędzi dla agentów korzystających z innego dostawcy modeli lub bramy. Używanie obu jest przydatne, gdy agent potrzebuje wyboru w czasie działania w obu warstwach.

Jak mogę utrzymać automatyczny routing w audycie?

Zarejestruj rozwiązany model, politykę routingu, kandydata na narzędzie, inspekcję ceny, wybrany punkt końcowy i zwrócony wynik dla każdego zadania. AIHubMix ujawnia szczegóły routingu modelu w odpowiedzi, podczas gdy Monid oddziela odkrywanie i inspekcję od wykonania, aby decyzja dotycząca narzędzia mogła być zarejestrowana przed płatnym wywołaniem.