Agenci napędzane konfiguracją: stwórz jeden środowisko działania, szybko się specjalizuj

Zwykła firma nie potrzebuje pięćdziesięciu niespowiązanych agentów. Potrzebuje jedynie kilku wzorców agentów, które można szybko dostosować do różnych zespołów, dziedzin i procesów pracy.

To dotyczy przede wszystkim zastosowań sztucznej inteligencji w dużych przedsiębiorstwach, opartych na danych, raportowaniu, analizie i wsparciu decyzyjnym. Jedna grupa prosi o asystenta do analizy przychodów, inna o analityka łańcucha dostaw, a jeszcze inna o osobę sprawdzającą ryzyko. Wydają się to oddzielne produkty, ale w rzeczywistości są to warianty jednego systemu:

• orkiestrator, który interpretuje żądanie i kieruje pracę,
• agent zajmujący się danymi lub informacjami, który analizuje problem,
• wąsko specjalistyczne funkcje do zadań o określonej strukturze, takie jak generowanie zapytań SQL, pobieranie dokumentów, sprawdzanie polityk lub formatowanie wyników, oraz
• warstwa odpowiedzi, która przekształca surowe wyniki w coś, co interesariusz może odczytać.

To spostrzeżenie dotyczy agentów sterowanych konfiguracją. Zamiast tworzyć każdy przypadek użycia jako osobnego agenta z z góry ustalonymi poleceniami, narzędziami i strukturą sterowania, tworzy się jeden silny agent bazowy, którego zachowanie można dostosowywać. Konfiguracja decyduje o tym, które umiejętności zostaną załadowane, jakie narzędzia mogą być używane, do których źródeł danych można uzyskać dostęp, jaka będzie forma wyniku oraz jakie zasady mają zastosowanie. W dojrzałym rozwiązaniu takie konfiguracje znajdują się również poza zainstalowanym obrazem, w dedykowanym katalogu konfiguracji agentów, gdzie mogą być zarządzane i aktualizowane samodzielnie. Korzyścią jest model dostarczania, który jest szybszy, bezpieczniejszy i łatwiejszy do skalowania we współpracy z ekspertami z danej dziedziny.

Dla organizacji, które chcą przejść od rozproszonych demonstracji do rzeczywistego portfela agentów produkcyjnych, konfiguracja to coś więcej niż tylko wygoda – jest jednym z głównych źródeł szybkości.

Główna idea

Agent napędzany konfiguracją można traktować jako środowisko działania, które można wielokrotnie wykorzystywać, w którym to konfiguracja, a nie kod, w dużej mierze określa, czym jest ten agent.

Kod zawiera stałą strukturę:

• obsługę wiadomości,
• orchestrację i kierowanie ruchem,
• wykonywanie narzędzi,
• pamięć i stan,
• zasady bezpieczeństwa,
• logowanie i możliwości monitorowania,
• haki do oceny oraz
• granice bezpieczeństwa.

Konfiguracja dostarcza wszystko to, co się zmienia:

• definicję promptu systemowego i roli,
• dostępne umiejętności lub podagenty,
• dozwolone narzędzia i łączniki danych,
• model oraz jego ustawienia inferencji,
• schemat wyjścia wraz z regułami formatowania,
• moment eskalacji sytuacji,
• ograniczenia wynikające z danej dziedziny oraz
• parametry na poziomie użytkownika i środowiska.

Równie ważne jest to, że konfiguracja zazwyczaj znajduje się poza plikiem binarnym aplikacji lub obrazem kontenera. Gdy w grę wchodzą różne domeny, użytkownicy oraz warianty agentów, wbudowana konfiguracja spowalnia cały proces. Każda modyfikacja zachowania wymaga ponownego rozruchu, każda edycja interfejsu prowadzi do nowej wersji aplikacji, a każda poprawka dotycząca domeny musi konkurować z podstawowymi zadaniami inżynieryjnymi.

Bardziej dojrzałym podejściem jest wyeksponowanie tych definicji do zarządzanego katalogu, który bazowy agent korzysta podczas działania. W ten sposób konfiguracja staje się samodzielnym, kontrolowanym zasobem, a nie sztywno zdefiniowanym dodatkiem do środowiska wykonawczego.

Rozdzielenie to jest skuteczne, ponieważ większość różnic pomiędzy agentami przedsiębiorstw nie wynika z aspektów architektonicznych, lecz z zachowań i kontekstu. Agent analizy sprzedaży oraz agent analizy zakupów rzadko potrzebują różnych silników orkiestracji – wymagają one innych instrukcji, dostępu do narzędzi, systemów źródłowych oraz określonych standardów formatowania, a wszystko to stanowi kwestie konfiguracji.

Dlaczego ten model pasuje do rzeczywistości przedsiębiorstw

Przypady użycia agentów przedsiębiorstw zazwyczaj można podzielić na określone kategorie. Wiele organizacji szuka przede wszystkim agentów dostarczających dane i informacje, które odpowiadają na pytania takie jak:

• Gdzie w tym tygodniu nastąpiła zmiana w procesie konwersji?
• Którzy klienci są narażeni na najwyższe ryzyko odejścia?
• Dlaczego w regionie południowo-wschodnim spadła terminowość dostaw?
• Jakie były główne problemy operacyjne w ciągu ostatnich trzydziestu dni?
• Sprawdź najnowsze zmiany w KPI i przedstaw je w formie opisu odpowiedniego dla zarządu.

Pytania pochodzą z różnych funkcji, ale mechanizm stojący za nimi jest podobny:

1. Określenie, czego chce użytkownik.
2. Wybór odpowiednich funkcji wyszukiwania, SQL lub analitycznych.
3. Zbieranie danych strukturalnych i niestrukturalnych.
4. Zastosowanie reguł rozumowania charakterystycznych dla danej dziedziny.
5. Kształtowanie odpowiedzi dostosowanej do odbiorcy.

Ten schemat powtarza się wciąż na nowo, a zmienia się jedynie konfiguracja wokół niego. Dlatego agent podstawowy w połączeniu z konfiguracją jest lepszy niż oddzielny agent dla każdego przypadku użycia.

Przewaga w dostarczaniu: zbuduj raz, specjalizuj się szybko

Największą korzyścią strategiczną jest szybkość dostarczania rozwiązań. Gdy zespół platformy stworzy solidnego agenta podstawowego, zespoły produktowe i specjaliści od danej dziedziny nie muszą zaczynać od zera przy każdej prośbie. Tworzą nowe zachowanie, pisząc pakiet konfiguracyjny, który określa:

• rola biznesowa, jaką pełni agent,
• słownictwo biznesowe, które musi rozumieć,
• źródła danych, z którymi może pracować,
• umiejętności specjalistyczne, których może używać,
• formaty odpowiedzi, które musi zwracać, oraz
• zasady zgodności, których musi przestrzegać.

Rozmowy na temat harmonogramów również ulegają zmianie. Zespół, który wcześniej obiecywał „cztery tygodnie na stworzenie nowego agenta do analiz finansowych”, może teraz odpowiedzieć: „Czas działania jest dostępny. Konfigurujemy profil finansowy, podłączamy zatwierdzone narzędzia do przetwarzania danych, uzgadniamy warunki wyników i testujemy z zespołem odpowiedzialnym za daną domenę”. To zupełnie inny sposób realizacji zadań.

Szybkość wynika z rozwiązywania trudnych problemów inżynieryjnych tylko raz: wywoływanie narzędzi, kierowanie ruchem, rejestrowanie audytu, śledzenie działań, obsługa prób ponownych i błędów, zarządzanie stanem, egzekwowanie zasad oraz weryfikacja wyników.

Dlaczego specjaliści od danej dziedziny zyskują wpływ

Kluczową zaletą jest to, że inżynierowie platformy oraz specjaliści od danej dziedziny mają bardziej przejrzysty punkt kontaktu. W wielu projektach AI w przedsiębiorstwach problemem jest to, że każda mała zmiana w zachowaniu wymaga czasu na prace inżynieryjne. Jakiś interesariusz twierdzi, że struktura odpowiedzi jest błędna, lub że używana jest niewłaściwa definicja metryki, albo że przed odpowiedzią należy skonsultować się z dokumentem polityki. Jeśli takie reguły są ukryte w kodzie, każda zmiana staje się zadaniem programistycznym.

Zmiany konfiguracji pomagają to zrównoważyć. Zespół platformy odpowiada za trwałe środowisko działania, a specjaliści od danej dziedziny kształtują zachowanie poprzez ustrukturyzowane dane wejściowe:

• szablony zapytań,
• reguły danej dziedziny,
• definicje metryk,
• źródła, które są dozwolone,
• warunki wyzwalające eskalację oraz
• wymagania dotyczące wyników.

Inżynieria nie znika. Przenosi się do pracy z większym wpływem: buduje platformę, warstwę sterowania, ograniczenia bezpieczeństwa oraz umiejętności wielokrotnego wykorzystania, podczas gdy eksperci z danej dziedziny określają, w jaki sposób te możliwości mają zastosowanie w konkretnym kontekście biznesowym. To właśnie taki podział pracy jest wymagany przy szybkim dostarczaniu rozwiązań korporacyjnych.

Konkretowy wzorzec korporacyjny

Dla wielu organizacji rozsądna architektura początkowa składa się z czterech części.

1. Podstawowy orkiestrator

Orkiestrator przyjmuje żądanie użytkownika, klasyfikuje zadanie, decyduje, jakie możliwości są potrzebne, i zarządza całym procesem pracy. Jego konfiguracja może określać zasady routingu, progi pewności, dostępne podagenty dla danego użytkownika lub funkcji, zachowanie awaryjne oraz wszelkie wymagania dotyczące zatwierdzeń lub udziału człowieka.

2. Agent danych i wglądów

To jest warstwa analityka ogólnego, odpowiedzialna za rozumowanie, dekompozycję i syntezę. Jej konfiguracja może określać jej profil biznesowy, glosariusz dziedzinowy, definicje KPI, procedury analityczne oraz strukturę wyjściową dostosowaną do różnych grup odbiorców.

3. Umiejętności specjalistyczne lub podagenty

Są to elementy zajmujące się wąskimi, wysokowartościowymi zadaniami, które odnoszą korzyść z bardziej precyzyjnych instrukcji oraz lepszego dostępu do narzędzi. Typowymi przykładami są generowanie i naprawa zapytań SQL, wyszukiwanie semantyczne w dokumentacji, określanie formatu wykresów, formatowanie narracyjne dla streszczeń kierowniczych, wyjaśnianie anomalii oraz przegląd polityk lub wymogów prawnych. Specjaliści mogą być sami konfigurowalni, ale ich funkcje są ograniczone i poddawalne testom.

4. Przeformatowujący wyjście

Bardzo wiele korporacyjnych procesów pracy zawodzi, mimo że podstawowa odpowiedź jest poprawna, po prostu dlatego, że przychodzi w niewłaściwej formie. Różni odbiorcy potrzebują różnych formatów: widok analityka z założeniami i szczegółami zapytań, streszczenie dla kierownictwa z krótkimi rekomendacjami, JSON dla systemów poniżej w łańcuchu przetwarzania, raport w formacie Markdown dla procesów opartych na wiedzy lub punkty gotowe do umieszczenia na slajdach dla aktualizacji kierownictwa. Dlatego konfigurowalna warstwa wyjściowa to nie tylko element dekoracyjny – jest częścią produktu.

Co powinno być w konfiguracji

Korzystna zasada: stabilna struktura procesu powinna znajdować się w kodzie, natomiast zmiany zależne od kontekstu – w konfiguracji. W praktyce konfiguracja zazwyczaj obejmuje następujące grupy:

• Tożsamość agenta: jego nazwa i rola, instrukcje systemu, ton, styl odpowiedzi oraz cel biznesowy, któremu służy.
• Co może robić: jakie umiejętności rejestrowe należy załadować, które grupy narzędzi są dozwolone lub zabronione, model do użycia oraz wszelkie modyfikacje parametrów.
• Znajomość dziedziny: hasła glosariusza, definicje tabel i miar, zasady biznesowe, istotne wymiary i filtry oraz źródła, którym można ufać.
• Zasady działania: kiedy przekazać sprawę na wyższy poziom, jakie walidacje należy przeprowadzić, które kroki wymagają zatwierdzenia, a także polityka ponawiania prób, limity czasowe i obowiązki redakcyjne.
• Forma odpowiedzi: schemat, styl formatowania, czy wymagane są cytaty, jaka powinna być długość odpowiedzi oraz dla kogo jest przeznaczona.
• Gdzie działa: ustawienia dla poszczególnych użytkowników, polityki według regionu, flagi środowiskowe, identyfikatory połączeń oraz włączniki funkcji.

Biorąc pod uwagę taki podział, uruchomienie nowego przypadku użycia często oznacza łączenie elementów, które już istnieją.

Konfiguracja zewnętrzna jako zasada projektowa

Agenty sterowane konfiguracją stają się znacznie bardziej przydatne, gdy konfiguracja jest zewnętrzna, co oznacza, że zachowanie agenta nie jest definiowane wyłącznie przez pliki zawarte w obrazie usługi. Zamiast tego działający system pobiera definicje agentów z zewnętrznego źródła prawdy. Tym źródłem mogą być pliki w wersjach, baza danych, usługa rejestru lub aplikacja z poziomu sterowania, a kluczowy jest tu aspekt architektoniczny: zachowanie może ulec zmianie bez konieczności przepisywania kodu w czasie uruchomienia.

Powodem jest to, że dwa cykle wypuszczania produktu zostają od siebie oddzielone, mimo że nie powinny być ze sobą powiązane: jeden dotyczy środowiska wykonawczego, a drugi zachowania agenta. Środowisko wykonawcze zmienia się wraz z aktualizacjami orkiestracji, mechanizmów bezpieczeństwa, połączników lub podstawowych funkcji platformy. Zachowanie agenta zmienia się, gdy zespół odpowiedzialny za dany obszar edytuje definicje, uprawnienia narzędzi, instrukcje, kontrakty wyjściowe lub zasady dotyczące danego przypadku użycia. Jeśli połączy się je razem, każda modyfikacja zachowania agenta powoduje spowolnienie działania całej organizacji.

Krok do dojrzałości: katalog konfiguracji agentów

Gdy istnieje wiele wariantów agentów, katalog konfiguracji agentów staje się niezbędny. Jest to zarządzany rejestr definicji agentów, które mogą być wdrażane w wspólnym środowisku wykonawczym – miejsce, gdzie zespoły przechowują, sprawdzają, wersjonują, zatwierdzają i promują konfiguracje bez konieczności modyfikowania obrazu bazowego. Jedna pozycja w katalogu może zawierać:

• kto jest agentem i do czego służy,
• wskazówki ułożone warstwowo w pakietach promptów,
• umiejętności i podagenty, które są aktywowane,
• łączniki i grupy narzędzi, które zostały zatwierdzone,
• schematy odpowiedzi oraz zasady ich generowania,
• definicje biznesowe i inne metadane z danej dziedziny,
• zasady eskalacji i bezpieczeństwa, a także
• historia wersji oraz ich pozycja w procesie promocji.

Baza wykonawcza robi wtedy coś prostego, ale skutecznego. Po wywołaniu znajduje odpowiedni wpis w katalogu, ładuje dozwolone funkcjonalności i działa w ramach tych ograniczeń. Ten silnik staje się stabilnym narzędziem, a katalog stanowi platformę, na której zmieniają się zachowania specyficzne dla danego biznesu.

Korzyści operacyjne wynikające z katalogu

Katalog zewnętrzny poprawia nie tylko elastyczność. Codzienne operacje również stają się łatwiejsze:

• zmiana promptu domeny nie zmusza do ponownego utworzenia obrazu usługi,
• nowy schemat wyjściowy może zostać wdrożony bez ingerencji w środowisko działania,
• konfiguracje specyficzne dla poszczególnych użytkowników mogą być zarządzane w jednym miejscu,
• odwrócenie zmian staje się kwestią konfiguracji, a nie pełnego ponownego wdrożenia,
• audytorzy mogą bezpośrednio czytać definicje zachowań, oraz
• zespoły platformowe mogą w kontrolowany sposób udostępnić samousługę zespołom produktowym i domenowym.

Jest to szczególnie cenne w przypadkach, gdy wiele scenariuszy użytkowych ma podobną strukturę. Gdy system potrafi już kierować żądaniami, wywoływać narzędzia SQL, pobierać definicje i formatować odpowiedzi, pipeline wdrożeniowy nie powinien stanowić wąskiego gardła za każdym razem, gdy jakiś zespół chce wprowadzić zmianę.

W porównaniu z rozprzestrzenianiem się agentów zapisanych w kodzie

Bез warstwy konfiguracji programy agentów korporacyjnych popadają w typową pułapkę, w której każdy przypadek użycia ma własną bazę kodu, a przynajmniej swoją mocno zmodyfikowaną implementację. Szybko pojawiają się problemy: duplikacja logiki pomiędzy zespołami, niespójne zachowanie pod względem bezpieczeństwa, nagłe zmiany trudne do wyśledzenia, powtarzająca się praca nad integracją, fragmentaryczna możliwość obserwacji, rosnące koszty konserwacji oraz wolniejsze wdrażanie nowych przypadków użycia.

Podejście oparte na konfiguracji zapewnia bardziej spójną platformę. Baza kodu pozostaje mniejsza, ulepszenia są stosowane we wielu agentach, zarządzanie staje się łatwiejsze, a testowanie bardziej systematyczne. Organizacja dzięki temu osiąga możliwość ponownego wykorzystania zasobów, a nie ich chaotyczny rozrost. Jest to szczególnie ważne w programach analitycznych, gdzie przypadki użycia są przeważnie podobne, a pisanie kodu dla każdego z nich osobno tylko zwiększa koszty, których można uniknąć.

Traktowanie konfiguracji jako interfejsu produktu

Warto traktować konfigurację jako część interfejsu produktu, a nie jako szczegół implementacji. To właśnie ona określa, w jaki sposób można bezpiecznie tworzyć nowe zachowania agentów. Dobra konfiguracja jest uporządkowana i nie powstała przypadkowo, jest weryfikowana przed uruchomieniem, posiada wersje, nadaje się do testowania, może być sprawdzana zarówno przez inżynierów, jak i specjalistów od danej dziedziny, ułatwia porównywanie różnych wersji, jest przechowywana poza obrazem uruchomieniowym oraz może być przekazywana pomiędzy środowiskami za pomocą kontrolowanego katalogu.

Na przykład agent do analizy operacji może być zdefiniowany poprzez rolę („Analityk wydajności operacji”), dozwolone umiejętności (sql_runner, doc_retriever, chart_formatter), zestaw podstawowych instrukcji (glosariusz pojęć związanych z operacjami, definicje KPI oraz lista kontrolna przyczyn podstawowych), tryb wyjścia (streszczenie dla kierownictwa wraz z tabelą dowodów) oraz mechanizm zapobiegający spekulacjom w sytuacji niepełnego zakresu danych. To jest lepsze niż przechowywanie tych samych decyzji w kodzie imperatywnym i rozproszonych ciągach instrukcji, a jeszcze lepsze, gdy definicje są zarządzane w zewnętrznym katalogu, a nie zawierane bezpośrednio w pliku instalacyjnym.

Czego powinien oferować sam katalog

Aby konfiguracja stanowiła rzeczywistą powierzchnię operacyjną, katalog musi posiadać własne funkcje na poziomie produktu. Przynajmniej:

• weryfikacja definicji agentów według określonego schematu,
• kontrola wersji z rejestrem zmian,
• metadane wskazujące, kto jest właścicielem danej rzeczy,
• procesy pracy służące do przeglądania i zatwierdzania,
• ścieżki promocji pomiędzy środowiskiem rozwojowym, testowym a produkcyjnym,
• odniesienia do zależnych umiejętności, narzędzi i schematów,
• różnice pomiędzy wersjami,
• wrócenie do wcześniej zatwierdzonych konfiguracji oraz
• ślad audytowy pokazujący, kto co zmienił i dlaczego.

Bardziej rozwinięte katalogi mogą zawierać szablony dla popularnych rodzin agentów. Standardowy szablon „agenta insight” może już obejmować zatwierdzone ścieżki przekierowania, specjalistów od SQL, formatery tekstu oraz domyślne zasady zarządzania, dzięki czemu nowe przypadki użycia wychodzą od sprawdzonej bazy, a nie od pustej strony.

Rola rejestru umiejętności

Gdy architekturą są agenci sterowane konfiguracją, rejestr umiejętności często pełni rolę systemu operacyjnego. Jest to uporządkowana lista możliwości wielokrotnego użycia, które podstawowy agent może załadować, przy czym każda umiejętność powinna mieć

Tutaj specjaliści z danej dziedziny mogą wnieść istotny wkład. Pracownicy finansowi mogą pomóc w ustaleniu zasad i oczekiwań dotyczących formatowania informacji finansowych, osoby odpowiedzialne za operacje mogą zdefiniować heurystyki do badania anomalii, a zespół ds. zarządzania może określić, jak powinien wyglądać format odpowiedzi zgodnej z wymogami. Zespół platformy nie buduje agenta za każdym razem – zapewnia stabilny mechanizm do ładowania i łączenia specjalistycznych możliwości, a katalog decyduje, które z nich są aktywne dla danej definicji.

Orkiestrator jest ważniejszy, a nie mniej

Część ludzi, słysząc „oparte na konfiguracji”, zakłada uproszczony system jednego agenta, ale zazwyczaj jest inaczej. Agent bazowy, który można skonfigurować, funkcjonuje najlepiej w połączeniu z zdolnym orkiestratorem, który pełni rolę decydenta w czasie wykonywania zadań i wybiera specjalistyczne zachowania w oparciu o zadanie oraz aktualną konfigurację.

Weźmy jeden wniosek biznesowy. Może on wymagać klasyfikacji intencji, wyszukiwania definicji metryk, pisania zapytań SQL do magazynu, naprawy błędnych zapytań, streszczania uzyskanych informacji i w końcu przekształcenia ich w odpowiedź dla kierownictwa. Orkiestrator zarządza tą sekwencją, a konfiguracja podaje mu informacje o tym, co jest dozwolone, preferowane i wymagane oraz jak powinna wyglądać ostateczna odpowiedź. Dzięki temu zapewniona jest zarówno możliwość ponownego użycia, jak i kontrola.

Zarządzanie poprawia się, gdy zachowania są jasno określone

Systemy AI dla przedsiębiorstw oceniane są pod kątem kontroli oraz użyteczności, a projektowanie oparte na konfiguracji jest pomocne, ponieważ ujawnia ich zachowanie. Nikt nie musi przeglądać kodu, aby dowiedzieć się, co dany agent może robić. Zespoły mogą otworzyć ustrukturyzowaną konfigurację i od razu zobaczyć aktywowane narzędzia, zatwierdzone źródła danych, wymagany schemat wyjściowy, używany model, zasady dotyczące danego użytkownika oraz moment, w którym konieczna jest interwencja człowieka.

Ta przejrzystość ułatwia audyt, weryfikację zgodności, zarządzanie wersjami, analizę incydentów, przenoszenie środowisk oraz kontrolowane eksperymenty. Konfiguracja stanowi zatem zarówno mechanizm zarządzania, jak i przyspieszający procesy element – umieszczenie jej w katalogu dodatkowo wzmacnia tę funkcję, ponieważ definicja zachowania staje się niezależnie poddawalna weryfikacji, przenoszeniu i audytowi.

Ustrukturyzowane warianty upraszczają testowanie

Testowalność to zaletę, której nie docenia się wystarczająco. Jeśli każdy agent jest budowany na zamówienie, każdy z nich musi być testowany jak odrębny produkt. Jeśli zmienność polega głównie na konfiguracji nakładanej na wspólny środowisko działania, testowanie staje się bardziej systematyczne:

• podstawowe środowisko działania jest testowane raz w celu sprawdzenia podstawowej niezawodności,
• każda umiejętność jest testowana niezależnie pod kątem jakości wykonywanych zadań,
• każdy pakiet konfiguracyjny jest sprawdzany pod kątem zgodności z zasadami oraz poprawności wyników, a także
• każda ścieżka realizacji jest testowana od początku do końca.

W praktyce prowadzi to do strategii oceny składającej się z testów platformy dla wspólnego kodu, testów umiejętności dla specyficznych zachowań specjalistycznych, testów konfiguracji pod kątem oczekiwań w danej dziedzinie oraz testów procesowych typu „golden set” dla kompletnych zadań biznesowych. Jest to o wiele bardziej zrównoważone podejście niż traktowanie każdego żądania agenta jako pojedynczej aplikacji.

Gdzie pasuje LangGraph

LangGraph pasuje do tego modelu, ponieważ jest to framework orkiestracji niskiego poziomu, a nie narzędzie do tworzenia agentów z góry określonych reguł, co jest dokładnie powodem, dla którego sprawdza się w platformach korporacyjnych. Zespoły kontrolują układ grafu, sposób przemieszczania się stanów, wywołania narzędzi, funkcje checkpointingu, kroki zatwierdzania przez ludzi oraz to, co można skonfigurować w czasie wykonywania. Nie dostarcza gotowego produktu agenta opartego na konfiguracji, ale oferuje elementy niezbędne do jego stworzenia.

Konkretnie parametry RunnableConfig oraz configurable ułatwiają przenoszenie zachowań w czasie wykonywania do zkompilowanego grafu, dzięki czemu podstawowy graf może zostać skompilowany raz, a następnie zmieniać się w zależności od promptów, modeli, narzędzi i polityk przy każdym wywołaniu. Na poziomie koncepcyjnym to właśnie potrzebuje podstawowy agent sterowany konfiguracją.

Minimalny przykład

Idea leżąca u podstaw jest prosta do sformułowania: stworzyć jeden podstawowy graf, zachować węzły jako ogólne elementy, czerpać zachowanie z konfiguracji w czasie wykonywania, wyszukiwać narzędzia i umiejętności w rejestrach oraz egzekwować umowy wyjściowe przed zwracaniem wyników. Minimalny przykład rozpoczyna się od importów:

from typing import TypedDict, Annotated, Sequence
from langchain_core.messages import BaseMessage, SystemMessage
from langchain_core.runnables import RunnableConfig
from langchain_openai import ChatOpenAI
from langgraph.graph import StateGraph, START, END
from langgraph.graph.message import add_messages

i kontynuuje opis stanu, jednego ogólnego węzła modelu oraz połączeń w grafie:

class AgentState(TypedDict):
    messages: Annotated[Sequence[BaseMessage], add_messages]
def call_model(state: AgentState, config: RunnableConfig):
    configurable = config.get("configurable", {})
    persona_prompt = configurable.get(
        "system_prompt", "You are a helpful assistant."
    )
    model_name = configurable.get("model", "gpt-4o-mini")    model = ChatOpenAI(model=model_name, temperature=0)
    messages = [SystemMessage(content=persona_prompt)] + list(state["messages"])    response = model.invoke(messages)
    return {"messages": [response]}
builder = StateGraph(AgentState)
builder.add_node("agent", call_model)
builder.add_edge(START, "agent")
builder.add_edge("agent", END)base_agent = builder.compile()

Jest celowo prosty, ale pokazuje istotę sprawy: wykres pozostaje niezmienny, a zachowanie zmienia się w zależności od konfiguracji. Ten sam wykres można następnie wywołać przy różnych konfiguracjach. To czyni go specjalistą od SQL:

config_analyst = {
    "configurable": {
        "system_prompt": "You are a Senior SQL Expert. Return only raw query executions.",
        "model": "gpt-4o"
    }
}

events = base_agent.stream(
    {"messages": [("user", "How many users signed up today?")]},
    config=config_analyst
)

Ktoś inny przekształca to w copywritera:

config_writer = {
    "configurable": {
        "system_prompt": "You are a witty Marketing Copywriter. Use punchy sentences.",
        "model": "gpt-4o-mini"
    }
}

events = base_agent.stream(
    {"messages": [("user", "Write a hook for a landing page.")]},
    config=config_writer
)

Zastosowanie w produkcji wykracza poza jedynie modyfikację promptów i modeli. Obejmuje ono również strukturalne ładowanie możliwości: wyszukiwanie w rejestrze umiejętności, uprawnienia narzędzi, walidację schematów, zasady routingu oraz zatwierdzone definicje agentów pobierane z zewnętrznego katalogu.

Rozszerzenie dla przedsiębiorstw

Rzeczywista konfiguracja agenta do przetwarzania danych i wytwarzania wniosków mogłaby wyglądać mniej więcej tak, w zarysie:

agent_id: operations_insight_agent
role: Operations Performance Analyst
system_prompt: |
  You are an enterprise operations analyst.
  Use only approved data and definitions.
  Distinguish clearly between observed facts, hypotheses, and recommendations.

skills:
  - metric_definition_lookup
  - sql_query_generator
  - sql_error_repair
  - executive_summary_formattertools:
  - warehouse_readonly
  - document_retrieveroutput:
  mode: executive_summary
  schema: ops_insight_response_v2
  include_citations: trueguardrails:
  no_speculation_without_evidence: true
  escalate_on_low_confidence: true

Dokładny format ma mniejsze znaczenie niż dyscyplina stojąca za nim. Agent specjalizujący się w określonej dziedzinie można stworzyć na podstawie konfiguracji, zamiast implementować go od zera, a w dojrzałej platformie taka konfiguracja jest zazwyczaj ładowana z katalogu, a nie kopiowana do obrazu usługi.

Kto jest odpowiedzialny za co

Aby model funkcjonował prawidłowo, zespół platformy musi mieć kontrolę nad bazą elementów wielokrotnego użycia. Obejmuje to środowisko wykonawcze do orkiestracji, schemat i narzędzie walidacji konfiguracji, katalog wraz z warstwą rozwiązywania problemów, rejestr umiejętności i narzędzie do ich ładowania, wspólne łączniki oraz otulacze narzędzi, możliwości obserwowalności wraz z śledzeniem i rejestracją działań, narzędzia do oceny, procesy wdrażania oraz egzekwowanie zasad i bezpieczeństwa. Wysiłki inżynieryjne w tym obszarze przynoszą nieproporcjonalnie duże korzyści i się kumulują, ponieważ każda nowa konfiguracja agenta korzysta z tej samej infrastruktury.

Zespoły zajmujące się domenami nie powinny być zmuszane do pracy nad inżynierią frameworków. One dostarczają wiedzy, która przekształca agenta w narzędzie przydatne dla konkretnego biznesu: definicje, akceptowalne sposoby rozumowania, heurystyki decyzyjne, zatwierdzone interpretacje danych, przypadki krawędziowe, to, co faktyczni interesariusze preferują widzieć, oraz przykłady do oceny. Silna platforma oparta na konfiguracjach umożliwia wykorzystanie tych wkładów w praktyce, co jest jednym z najwyraźniejszych sposobów na skalowanie dostarczania rozwiązań AI bez przekształcania centralnego zespołu inżynieryjnego w wąskie gardło.

Zasady projektowe zapewniające poprawne funkcjonowanie

Część zasad ma tendencję do odróżniania solidnych systemów opartych na konfiguracjach od tych kruchych.

• Zachowaj podstawowego agenta wąskiego, ale silnego. Powinien on obsługiwać wspólne mechanizmy, a nie gromadzić każdą wyjątkową sytuację specyficzną dla danego obszaru. Logika biznesowa, która może znajdować się w konfiguracji lub specjalistycznych umiejętnościach, nie powinna być przechowywana w czasie wykonywania programu.
• Zachowaj specjalistyczne umiejętności skoncentrowane. Im węższy zakres umiejętności, tym łatwiej jest ją ocenić, ulepszyć i bezpiecznie ponownie wykorzystać. Umiejętność sql_error_repair jest lepsza od niejasnej umiejętności typu „robić rzeczy z danymi”.
• Szczegółowo waliduj konfigurację. Konfiguracja to nie tekst nieformalny. Używaj schematów, pól obowiązkowych, wartości domyślnych oraz sprawdzeń kompatybilności, ponieważ zła konfiguracja może być równie niebezpieczna jak zły kod, szczególnie gdy zostanie wyeksportowana i udostępniona oddzielnie od czasu wykonywania programu.

Eksternalizuj wcześnie. Rozpoczęcie od plików konfiguracyjnych w repozytorium jest w porządku, ale jeśli celem jest platforma korporacyjna z wieloma wariantami, eksternalizacja powinna być jasnym celem projektowym od samego początku. W przeciwnym razie organizacja odkryje, że stworzyła system działający w czasie rzeczywistym, który można skonfigurować, oraz model operacyjny, którego nie da się skonfigurować.

Wymagaj przestrzegania umów na granicach. Jeśli dana funkcja musi zwracać dane w formacie SQL, sprawdź, czy rzeczywiście je zwraca, a jeśli narzędzie formatujące musi generować JSON zgodne ze schematem, zweryfikuj to przed wysłaniem odpowiedzi.

Rozdzielaj routowanie od specjalistycznej wiedzy. Orkiestrator decyduje, kiedy użyć danej funkcji, a ta funkcja pozostaje skoncentrowana i doskonała w wykonywaniu swojego jedynego zadania.

Zrób zachowanie widocznym. Przy każdym wywołaniu powinno być łatwe do zobaczenia, jaka konfiguracja została użyta, jakie umiejętności załadowane, jakie narzędzia wywołane oraz jaka była logika przyjętej ścieżki.

Częste przyczyny awarii

To wzorzec jest potężny, ale powtarzają się kilka błędów.

• Nadmiernie obszerna konfiguracja. Gdy konfiguracja staje się miejscem gromadzenia wszystkich skrajnych przypadków, system staje się nieczytelny i kruchy. Konfiguracja powinna odzwierciedlać kontrolowane zmiany, a nie zastępować projektowanie oprogramowania.
• Słabe granice między umiejętnościami. Jeśli umiejętności mocno się nakładają, orkiestrator nie może podjąć jasnej decyzji, co powoduje zamieszanie w ocenie. Umiejętności wielokrotnego użycia wymagają jasnego celu i interfejsu.

Brak pętli oceny domen. System konfigurowalny przyspiesza dostarczanie wyników tylko wtedy, gdy eksperci od domen biorą udział w definiowaniu instrukcji, zasad, przykładów oraz standardów jakości odpowiedzi. W przeciwnym razie zespoły tworzą jedynie szybszą drogę do generycznych wyników.

Niejednolite umowy dotyczące wyników. Wiele niepowodzeń w przedsiębiorstwach występuje na ostatnim etapie. Agent, który nie może w sposób niezawodny generować oczekiwanej struktury, podważa zarówno integrację, jak i zaufanie.

Powiązana logika polityk. Gdy zasady i reguły dostępu są rozdzielone pomiędzy kodem, instrukcjami oraz ustawieniami wdrożenia, zarządzanie staje się trudne. Należy zachować jasność w mechanizmach kontroli.

Dlaczego ma to znaczenie strategiczne

Długoterminowa wartość agentów sterowanych konfiguracją polega nie tylko na elegancji ich działania. Umożliwiają one bardziej skalowalny model operacyjny przedsiębiorstwa. Organizacje mogą znacznie szybciej wdrażać podobne przypadki użycia agentów, ponownie wykorzystywać sprawdzoną infrastrukturę zamiast ją kopiować, angażować specjalistów w dane dziedziny bez konieczności przekształcania każdej zmiany w zadanie programistyczne, poprawiać zarządzanie dzięki wyraźnym definicjom zachowań, zarządzać wariantami za pomocą zewnętrznego katalogu, a nie poprzez powtarzane przeprowadzanie aktualizacji, testować systematycznie na wspólnych środowiskach działania oraz specjalistycznych konfiguracjach, a także tworzyć wewnętrzną bazę umiejętności zamiast gromady jednorazowych botów.

Dla firm, których główne możliwości w zakresie sztucznej inteligencji leżą w procesach przetwarzania danych i wytwarzania wniosków, jest to szczególnie kuszące, ponieważ te przypadki zastosowania mają wspólną podstawę. Tworzenie każdego z nich osobno rzadko jest rozwiązaniem skutecznym. Skuteczniejsze okazuje się budowanie solidnej bazy, umożliwianie dostępu do odpowiednich ustawień oraz pozwolenie na rozwój specjalistycznych zachowań poprzez kontrolowaną kompozycję.

Jakie to ma znaczenie dla platform agentów korporacyjnych

Najskuteczniejsze platformy agentów korporacyjnych prawdopodobnie nie będą tymi, które tworzą najbardziej dostosowane agenty. Będą to platformy, które przekształcają wspólne wzorce agentów w infrastrukturę, którą można skonfigurować. Agent bazowy, który czerpie swoje umiejętności, narzędzia, instrukcje i zasady z ustawień, nie jest sposobem na skrócenie drogi – to dojrzała decyzja architektoniczna, która staje się jeszcze skuteczniejsza, gdy te ustawienia znajdują się w zewnętrznym katalogu.

Umożliwia zespołom inżynieryjnym szybkie działanie bez utraty kontroli, a specjalistom od danej dziedziny daje rzeczywistą rolę w kształtowaniu zachowania systemu. Pasuje również do podstawowej rzeczywistości większości portfeli AI w przedsiębiorstwach, gdzie wiele przypadków użycia wygląda inaczej na pierwszy rzut oka, ale jest strukturalnie podobnych w swojej istocie.