ai-agents-for-beginners

Деплоймънт на мащабируеми агенти с Microsoft Foundry

Деплоймънт на мащабируеми агенти

До този момент в курса сте изграждали агенти, които работят на вашия лаптоп, в тетрадка, управлявани чрез az login и няколко променливи на средата. Това е точно правилният начин за учене. Но не е правилният начин за работа на агент, на когото хиляди клиенти разчитат в 3 часа през нощта.

Т този урок е за разликата между „работи на моята машина“ и „работи надеждно и на достъпна цена в продукция“. Ние затваряме тази разлика с помощта на Microsoft Foundry и Microsoft Foundry Agent Service, като изграждаме реален агент за клиентска поддръжка с инструменти, извличане, памет, оценка и мониторинг.

Въведение

Този урок ще обхване:

Цели на обучението

След завършване на този урок ще знаете как да:

Предварителни изисквания

Този урок предполага, че сте преминали през по-ранните уроци и сте запознати със:

Ще имате нужда и от:

От прототип към продукция: какво всъщност се променя

Прототипен агент и продукционен агент споделят същия основен цикъл — разсъждава, вика инструменти, отговаря. Променя се всичко, което е обвито около този цикъл. Моделът е може би 20% от продукционния агент; останалите 80% са оперативният скелет.

Аспект Прототип Продукция
Хостинг Работи в тетрадката ви Работи като хоствана услуга, версионирана и разпространявана
Идентичност Вашият токен az login Управлявана идентичност с обхватено RBAC
Състояние В паметта, губи се при рестарт Екстернализирано (съхранение на нишки, услуга за памет)
Грешки Виждате стека с грешки Повторни опити, резервни варианти, мъртви писма, аларми
Цена „Няколко стотинки“ Следи се на заявка, маршрутизира се, кешира се, бюджетират се разходи
Качество Гледате изхода с очи Автоматично се оценява преди всеки релийз
Доверие Одобрявате всяко действие Политика + човек в цикъла за рискови действия

Запазете тази таблица в ума си. Всеки раздел по-долу съответства на един от тези редове.

Патерни за деплоймънт на агенти

Има три патерна, които ще използвате често в комбинация.

1. Клиентски хоствани агенти

Агентът живее вътре в вашия процес на приложението. Вашият код вика директно доставчика на модел; цикълът на разсъждение работи във вашата услуга. Това е това, което правехме до момента във всеки урок.

2. Хоствани агенти (Foundry Agent Service)

Агентът е регистриран като ресурс в Microsoft Foundry. Foundry хоства цикъла на разсъждение, съхранява нишки, налага сигурност на съдържание и RBAC, и прави агента видим в портала Foundry. Вашето приложение става тънък клиент, който създава нишки и чете отговори.

3. Работни потоци на агенти

Множество агенти (и инструменти) се композират в граф с изрично управление на потока — последователни стъпки, разклонения, възли с човешко одобрение и издръжливи контрольни точки, които могат да спират и продължават. Това е възможност на Microsoft Agent Framework Workflows приложена при мащабиране на деплоймънт.

flowchart TB
    subgraph P1[Клиентски хостван]
        A1[Процес на Вашето приложение] --> M1[Доставчик на модел]
    end
    subgraph P2[Хостван агент]
        A2[Тънък клиент] --> F2[Услуга на Foundry агент]
        F2 --> M2[Модел + Инструменти + Магазин за нишки]
    end
    subgraph P3[Работен процес на агент]
        A3[Оркестратор] --> S1[Агент за триаж]
        S1 --> S2[Агент разрешител]
        S2 --> H[Възел за човешко одобрение]
        H --> S3[Агент за действие]
    end

Жизнен цикъл на агента в Microsoft Foundry

Деплоймънтът на агент не е еднократно „пушване“. Той е цикъл и изглежда много като софтуерен релийз цикъл, защото точно това е.

flowchart LR
    Create[Създай / Автор] --> Version[Версия]
    Version --> Evaluate[Оцени офлайн]
    Evaluate -->|преминава шлюза| Deploy[Разположи хоствано]
    Evaluate -->|не преминава шлюза| Create
    Deploy --> Observe[Наблюдавай онлайн]
    Observe --> Improve[Събери грешки]
    Improve --> Create
    Deploy --> Retire[Изтегли старата версия]

Основната идея, пренесена от Урок 10: офлайн оценката е гейт, а не следваща мисъл. Нова версия на агент не се пуска, освен ако не премине вашите оценъчни прагове. Онлайн наблюдаемостта след това връща реални грешки обратно към офлайн тестовете. Това е целият цикъл.

Стратегии за мащабиране

Мащабирането на агент е различно от мащабирането на безсъстоянен уеб API, защото всяка заявка може да задейства множество скъпи повиквания към модели и инструменти. Четири техники понасят основната тежест.

Обработка на безсъстояни заявки. Не пазете състояние на потребител във вътрешната памет. Съхранявайте нишките от разговори във Foundry thread store или услуга за памет, така че всяка инстанция да може да обработва всяка заявка. Това позволява хоризонтално мащабиране — добавят се инстанции, без sticky сесии.

Маршрутизиране на модели. Не всяка заявка изисква най-мощния (и най-скъпия) ви модел. Маршрутизирайте прости заявки — класификация на намерения, кратки фактически отговори — към малък и бърз модел, а големия модел оставете за истински разсъждения. Foundry Model Router може да направи това вместо вас, или можете да имплементирате лек класификатор сами. В лабораторията ще изградите DIY версия.

Кеширане на отговори. Много запитвания за поддръжка са близнаци („как да рестартирам паролата си?“). Кеширайте отговори на често срещани въпроси и ги сервирайте без да засягате модела изобщо. Дори и умерен кеш хит намалява значително разходите и латентността.

Паралелизъм и обратно налягане. Доставчиците на модел имат лимити за заявките. Ограничете паралелизма, използвайте повторни опити с експоненциално забавяне и нека провалите са грациозни (чаканият отговор „работим по въпроса“ е по-добър от грешка 500).

flowchart LR
    Q[Запитване от потребителя] --> C{Намерена ли е кеширана стойност?}
    C -->|да| R[Връщане на кеширания отговор]
    C -->|не| Router{Сложност?}
    Router -->|проста| SLM[Малък модел]
    Router -->|сложна| LLM[Голям модел]
    SLM --> Out[Отговор]
    LLM --> Out
    Out --> Store[Кеш + проследяване]

Наблюдаемост в продукция

Не можете да управлявате това, което не виждате. Както е описано в Урок 10, Microsoft Agent Framework излъчва OpenTelemetry трасета нативно — всяко повикване на модел, инструмент и стъпка от оркестрацията става span. В продукция ги експортирате към Microsoft Foundry (или какъвто и да е OTel-съвместим бекенд), за да можете:

from agent_framework.observability import get_tracer

tracer = get_tracer()

with tracer.start_as_current_span("support_request") as span:
    span.set_attribute("customer.tier", "enterprise")
    span.set_attribute("routed.model", "gpt-5-nano")
    # изпълнението на агента се проследява автоматично вътре в този интервал

Атрибути като customer.tier и routed.model преобразуват множество трасета във въпроси, на които може да се отговори („дали корпоративните клиенти твърде често се насочват към малкия модел?“).

Оптимизация на разходите

Разходите в продукционните агенти са доминирани от токени. Три лоста, по степен на въздействие:

  1. Подходящ размер на модела. Малък модел, който преминава вашия оценъчен гейт, почти винаги е по-евтин от голям, който също минава. Използвайте оценка, за да докажете, че малкият модел е достатъчен, вместо по умолчание да избирате най-големия от предпазливост.
  2. Маршрутизирайте по сложност. Както горе — плащайте големи цени само за заявки, които изискват голям модел за разсъждение.
  3. Кеширайте агресивно. Най-евтиното повикване на модел е това, което никога не правите.

Оценъчните гейтове и контролът на разходите са една и съща дисциплина, разгледана от две страни: оценката ви казва дъното по качество, маршрутизирането и кешът ви държат възможно най-близо до това дъно по цена.

Предвидености за корпоративен деплоймънт

Управление. Hosted Agents наследяват RBAC, безопасност на съдържанието и одитния журнал на Foundry. Дайте на всеки агент управлявана идентичност с минималните привилегии — само четене на базата знания, обхватен достъп до API за тикети, нищо повече.

Човек в цикъла. Някои действия са твърде важни, за да се автоматизират напълно — издаване на възстановяване, изтриване на акаунт, ескалация към юридическия екип. Microsoft Agent Framework поддържа инструменти с необходимо одобрение: агентът предлага действието, изпълнението спира, човек одобрява или отказва, работният поток продължава. Виждали сте примитива в Урок 6; тук го деплойвате.

MCP в продукция. MCP позволява на вашия агент да използва външни инструменти чрез стандартен интерфейс. В продукция третирайте всеки MCP сървър като ненадеждна граница: фиксирайте версията на сървъра, пускайте го с обхватена идентичност, валидирайте изхода му и никога не му разкривайте тайни. MCP сървърът е зависимост, а зависимостите се създават пачове, одитират се и имат ограничение на честотата.

flowchart TB
    subgraph Dev[Архитектура на разработка]
        D1[Бележник] --> D2[Агенска платформа]
        D2 --> D3[Доставчик на модел]
        D2 --> D4[Локални инструменти]
    end
    subgraph Deploy[Архитектура на разгръщане]
        E1[CI конвейер] --> E2[Портал за оценка]
        E2 -->|успешно| E3[Служба за агент на Foundry]
        E3 --> E4[Версиониран хостван агент]
    end
    subgraph Run[Архитектура на изпълнение]
        F1[Клиентско приложение] --> F2[Хостван агент]
        F2 --> F3[Маршрутизатор на модел]
        F2 --> F4[Azure AI Search RAG]
        F2 --> F5[Услуга за памет]
        F2 --> F6[MCP инструменти]
        F2 --> F7[OTel -> Проследяване на Foundry]
        F2 --> F8[Човешко одобрение]
    end

Тези три диаграми — разработка, деплоймънт, runtime — са един и същ агент на три етапа от живота си. Следващата лаборатория ви води през изграждането му.

Практическа лаборатория: производство-готов агент за клиентска поддръжка

Отворете code_samples/16-python-agent-framework.ipynb и го преминете напълно. Ще съставите агент за клиентска поддръжка на Contoso с всички производствени компоненти:

  1. Извикване на инструменти — проверка на статус на поръчка и отваряне на тикети за поддръжка.
  2. RAG — отговаряне на въпроси за политика от база знания (Azure AI Search, с резервна in-memory функция, така че тетрадката работи без Search ресурс).
  3. Памет — помни клиента през изреченията на разговора.
  4. Маршрутизиране на модели — класификатор по сложност насочва всяка заявка към малък или голям модел.
  5. Кеширане на отговори — повтарящи се въпроси се обслужват от кеш.
  6. Човешко одобрение — възстановявания над прагове спират за подписване от човек.
  7. Оценъчен пайплайн — малък офлайн тестов сет оценява агента и служи като гейт за релийз.
  8. Наблюдаемост — OpenTelemetry проследяване около всяка заявка.

Преглед

Тетрадката е организирана така, че всяка производствена грижа е самостоятелен, изпълним раздел. Сърцето е хендлърът за заявки с маршрутизиране и кеширане:

async def handle_support_request(query: str, customer_id: str) -> str:
    # 1. Обслужвайте от кеша, когато е възможно.
    cached = response_cache.get(normalize(query))
    if cached:
        return cached

    # 2. Насочвайте според сложността, за да контролирате разходите.
    model = "gpt-5-nano" if is_simple(query) else "gpt-5-mini"

    # 3. Стартирайте агента в рамките на трасировъчен спан за наблюдаемост.
    with tracer.start_as_current_span("support_request") as span:
        span.set_attribute("routed.model", model)
        span.set_attribute("customer.id", customer_id)
        response = await support_agent.run(query, model=model)

    # 4. Кеширайте и връщайте.
    response_cache.set(normalize(query), response.text)
    return response.text

Оценъчният гейт за релийз изглежда така:

async def evaluation_gate(agent, test_cases, threshold: float = 0.8) -> bool:
    passed = 0
    for case in test_cases:
        result = await agent.run(case["input"])
        if score_response(result.text, case["expected"]) >= 0.8:
            passed += 1
    pass_rate = passed / len(test_cases)
    print(f"Evaluation pass rate: {pass_rate:.0%} (gate: {threshold:.0%})")
    return pass_rate >= threshold  # внедряване само ако порталът премине проверки

Прочетете всеки ред — тетрадката държи примитивите умишлено малки, за да не е скрито нищо зад фреймворк повикване.

Валидация на деплойван агент със smoke тестове

Оценъчният гейт по-горе се изпълнява офлайн срещу вашия агент обект. След като агентът е деплойнат като Hosted Agent, трябва още една, дори по-евтина проверка: дали деплойнатият endpoint всъщност отговаря?

Успешното деплойване доказва само, че контролният план е приел дефиницията — не доказва, че агентът отговаря. Липсваща зависимост, неправилно маршрутизиране на модел или изтекла връзка може да остави зелено деплойване, което не връща нищо. Smoke тест хваща това за секунди, при всяко деплойване, без разходите на пълна оценка.

Това хранилище предлага готов за използване smoke-тест пайплайн, изградена върху GitHub Action AI Smoke Test:

- name: Smoke-test hosted agent
  uses: JFolberth/ai-smoketest@v1
  with:
    project_endpoint: $
    agent_name: ContosoSupportAgent
    tests_file: tests/lesson-16-smoke-tests.json

Стартирайте го от раздела Actions, след като вашият агент бъде разположен, като предоставите крайна точка на вашия Foundry проект и име на агента. Федеративната идентичност трябва да има ролята Azure AI User с обхват Foundry проект. Помислете за слоевете като за пирамида: тестовете за задимяване (достъпен ли е и отговаря ли?) се изпълняват при всяко разполагане, офлайн оценката (достатъчно ли е добър, за да се пусне?) се прави преди промоция, а онлайн оценката (как се представя в реална среда?) се извършва непрекъснато.

Проверка на знанията

Тествайте разбирането си преди да преминете към задачата.

1. Приблизително колко от един продукционен агент представлява „моделът“ и какво е останалото?

Отговор Моделът е малцинство от системата — често се цитира около 20%. Останалото е оперативният скелет: хостинг и версиониране, идентичност и RBAC, външно състояние, обработка на грешки, проследяване на разходите, оценка и контрол с участието на човек. Преминаването в продукция е предимно изграждане на всичко *около* цикъла на разсъждение.

2. Кога бихте избрали Hosted Agent пред агент, хостван на клиент?

Отговор Когато искате управляема среда на изпълнение с вградена издръжливост (нишки, които продължават да съществуват и могат да се възобновят), наблюдаемост, безопасност на съдържанието и RBAC, и сте готови да пожертвате част от ниско ниво контрол над цикъла на разсъждение срещу по-малка оперативна сложност. Клиентският хостинг е предпочитан, когато ви е необходим пълен контрол върху цикъла или когато вграждате агента в съществуващ бекенд.

3. Защо мащабируем агент трябва да бъде безсъстояние в паметта на своя процес?

Отговор За да може всеки екземпляр да обработва всяка заявка, което позволява хоризонтално мащабиране без фиксирани сесии. Състоянието на разговор с потребител се извежда извън процеса към хранилище за нишки или услуга за памет. Ако състоянието живееше в паметта на процеса, щяхте да го губите при рестарт и не бихте могли свободно да разпределяте натоварването.

4. Какъв проблем решава маршрутизирането на модела и как е свързано с оценката?

Отговор Маршрутизирането изпраща прости заявки към малък, евтин и бърз модел и резервира големия модел за реално разсъждение, контролирайки както латентността, така и разходите. Това е свързано с оценката, защото именно оценката *доказва*, че малкият модел е достатъчно добър за даден клас заявки — маршрутизирането без оценка е предположение.

5. Какво представлява „стража за оценка“ и къде в жизнения цикъл е разположен?

Отговор Стражът за оценка изпълнява офлайн тестов набор срещу нова версия на агента и блокира разгръщането, освен ако процентът на преминаване не достигне прага. Той е разположен между „версия“ и „разгръщане“ в жизнения цикъл, правейки качеството предпоставка за издаване, а не нещо, което се проверява след пускане.

6. Защо MCP сървърът трябва да се третира като небезопасна граница в продукция?

Отговор Защото това е външна зависимост, към която вашият агент прави повиквания. Трябва да фиксирате неговата версия, да го изпълнявате с ограничена идентичност, да валидирате изходите му, да го ограничавате по честота и никога да не му излагате тайни — същата дисциплина, която прилагате към всяка трета страна. Изходите му влизат в разсъждението на вашия агент, затова неизвалидираното доверие крие риск за сигурността.

7. Коя една промяна обикновено има най-голямо въздействие върху разходите за продукционен агент и защо?

Отговор Правилният избор на модела — използване на най-малкия модел, който все още преминава вашия страж за оценка. Разходите са доминирани от токените, а по-малкият модел, който отговаря на критерия за качество, почти винаги е по-евтин от по-голям. Кеширането и маршрутизирането след това намаляват разходите допълнително, но изборът на правилния базов модел има най-голям ефект от първи ред.

8. Каква роля играят атрибутите на спанове като customer.tier и routed.model в наблюдаемостта?

Отговор Те превръщат суровите трасета в отговорими бизнес въпроси. Без атрибути имате стена от спанове; с тях можете да попитате „дали корпоративните клиенти биват прекомерно маршрутизирани към малкия модел?“ или „кой модел обработва най-бавните ни заявки?“ Атрибутите са как разрязвате телеметрията по измерения, които са важни за вашата операция.

Задача

Вземете агента за клиентска поддръжка от лабораторията и го заздравете за конкретен сценарий: агент за поддръжка на абонаментно фактуриране за SaaS компания.

Вашето подаване трябва да:

  1. Замени инструментите с такива, релевантни за фактуриране: get_subscription_status, get_invoice и issue_credit (кредити над $50 изискват одобрение от човек).
  2. Добави три RAG документа, обхващащи политиката за възстановяване на компанията, цикъла на фактуриране и политиката за анулиране.
  3. Разшири набора за оценка до поне осем случая, включително поне два, които трябва да задействат пътя за одобрение от човек, и потвърди, че стражът за оценка правилно преминава или отказва.
  4. Добави един отчет за разходите: след изпълнение на десет смесени заявки през агента, отпечатай колко от тях отидоха към малкия модел, колко към големия модел и колко бяха обслужени от кеша.

Напиши кратък параграф (в markdown клетка), обясняващ кой модел-маршрутизиран правил сте избрали и как бихте го валидирали с истински трафик. Няма единствено правилен отговор — оценяват се дали продукционните съображения са свързани по последователен начин.

Обобщение

В този урок преместихте агент от прототип към продукция с Microsoft Foundry:

Следващият урок поема в обратната посока: вместо да мащабирате агенти към облака, ще ги изнесете надолу на една разработваща машина и ще ги изпълнявате изцяло локално.

Допълнителни ресурси

Предишен урок

Създаване на агенти за употреба на компютър (CUA)

Следващ урок

Създаване на локални AI агенти

Отказ от отговорност: Този документ е преведен с помощта на AI преводачески услуга Co-op Translator. Въпреки че се стремим към точност, моля имайте предвид, че автоматизираните преводи могат да съдържат грешки или неточности. Оригиналният документ на неговия роден език трябва да се счита за авторитетен източник. За критична информация се препоръчва професионален човешки превод. Ние не носим отговорност за каквито и да е недоразумения или неправилни тълкувания, произтичащи от използването на този превод.

This site is open source. Improve this page.