ai-agents-for-beginners

Разгръщане на мащабируеми агенти с Microsoft Foundry

Разгръщане на мащабируеми агенти

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

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

Въведение

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

Цели за учене

След приключване на урока ще знаете как да:

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

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

Също така ще ви трябват:

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

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

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

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

Патерни за разгръщане на агенти

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

1. Агeнти, хоствани от клиент

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

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

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

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

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

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

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

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

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

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

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

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

Маршрутизиране на модел. Не всяка заявка изисква най-мощния (и най-скъп) ви модел. Насочвайте прости заявки — класификация на намерения, кратки фактически отговори — към малък, бърз модел и запазвайте големия модел за истинско разсъждение. 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. В продукция експортирате тези spans към 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-4.1-mini")
    # изпълнението на агента се проследява автоматично вътре в този интервал

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

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

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

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

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

Предприятни съображения при разгръщане

Управление. Хостваните агенти наследяват Foundry RBAC, безопасност на съдържанието и одитно регистриране. Дайте на всеки агент управлявана идентичност с най-малките нужни привилегии — само четене на базата знания, ограничен достъп до 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

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

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

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

  1. Извикване на инструменти — проверка на статус на поръчка и отваряне на заявки за поддръжка.
  2. RAG — отговори на въпроси за политики от база знания (Azure AI Search, с бекъп в памет, за да работи бележникът и без Search ресурс).
  3. Памет — запомняне на клиента през въртенията на разговора.
  4. Маршрутизиране на модел — класификатор на сложност насочва всяка заявка към малък или голям модел.
  5. Кеширане на отговори — повтарящите се въпроси се обслужват от кеша.
  6. Човешко одобрение — върнати суми над праг изискват човешко потвърждение.
  7. Оценъчен pipeline — малък офлайн тестов набор оценява агента и служи като праг за пускане.
  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-4.1-mini" if is_simple(query) else "gpt-4.1"

    # 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  # разгръщайте само ако пропускателят е успешен

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

Валидиране на разгърнат агент с тестове за задимяване

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

Разгръщането „успешно“ само доказва, че контролната площ е приела дефиницията — не доказва, че агентът отговаря. Липсваща зависимост, грешно маршрутизиране на модел или изтекла връзка могат да оставят зелено разгъване, което не връща нищо. Тестът за задимяване хваща това за секунди, при всяко разгръщане, без разходите на пълна оценка.

Този репозитория предлага готов pipeline за тест за задимяване, базиран на AI Smoke Test GitHub Action:

- 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. Кога бихте избрали Хостван Агент пред клиент-хостиран агент?

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

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

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

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

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

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

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

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.