Оркестрация на AI агенти: откази, одобрения и повторни опити

Няколко агента, които работят по един и същ проект – това звучи изключително ефективно. Единият планира работата, друг се занимава с дизайна, а трети пише кода. Това работи, докато не спре да работи. А сривовете се случват по-често, отколкото бихте искали.

Предотвратяването на тези сривове изисква внимателно проектиране на работните процеси. Затова нека разгледаме какво прави оркестрираните работни процеси ненадеждни и да проучим най-добрите практики за оркестрация, които осигуряват надеждност в продукционна среда.

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

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

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

Нека разгледаме какво се случва, след като дадете задача на оркестратор.

Да разгледаме пример от уъркшопа на Perplexity за Computer: изграждане на табло за анализ на клиентски акаунти с информация от Salesforce, Snowflake, имейл, календар и последни новини.

Разбиране на целта и планиране на работата. Оркестраторът започва от желания резултат и го разделя на задачи с ясно определени зависимости. В нашия пример с таблото това включва събиране на информация от различни източници и превръщането ѝ в завършен краен продукт. Планиращият компонент определя кои стъпки зависят от други и кои могат да се изпълняват независимо.
Насочване на задачите към подходящите агенти. Оркестраторът идентифицира задачите, чиито зависимости са удовлетворени, и делегира работата на специализирани агенти или модели. Зависимите задачи изчакват предпоставките си. Perplexity Computer използва множество водещи модели, като насочва различните части на работния процес към системи, подходящи за съответните задачи. Това позволява и независимата работа да се изпълнява паралелно.
Изпълнение на извиквания на инструменти в контролирани среди. Агентите взаимодействат със средата си чрез инструменти като уеб търсене, API, свързани приложения, файлови операции или изпълнение на код. Слоят за изпълнение извършва тези действия и връща резултатите на агентите.
Предаване на резултати и контекст между агентите. След като даден агент приключи задачата си, следващият агент надолу по веригата се нуждае от съответния резултат, за да продължи. Записът за предаване може да съдържа идентификатор на задачата, препратка към резултата, версия на схемата и метаданни за източника. Оркестраторът координира тези предавания, като същевременно поддържа контекста, необходим за следващите стъпки. Важното е, че агентите не са длъжни да пренасят цялата история на работата на всички останали агенти в собствените си контекстни прозорци.
Записване на състоянието на изпълнение отделно от контекста на агентите. Когато агентите започват, завършват или не успяват да изпълнят задачи, механизмът за изпълнение актуализира постоянен запис на работния процес със статусите на задачите, опитите за изпълнение, препратките към резултатите и оставащата работа. Този запис позволява на оркестратора да проследява напредъка и да възобновява работата след прекъсвания, без да разчита на LLM да реконструира работния процес от историята на разговора.
Валидиране на резултатите и вземане на решение за следващата стъпка. Когато дадена задача върне резултат, слоят за оркестрация проверява дали изходните данни отговарят на очаквания договор и дали зависимостите на следващата задача са изпълнени. Ако бъде открит проблем, работният процес може да се върне към по-ранна стъпка за корекция или да бъде поставен на пауза. В противен случай той продължава към завършване.

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

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

Следователно оркестрацията е полезна в три сценария:

Задачите изискват различни специализации. Един проект за програмиране например може да се възползва от отделни агенти за планиране, дизайн, разработка и преглед.
Независимите задачи могат да се изпълняват паралелно. Вместо един агент да изпълнява всичко последователно, множество агенти могат да работят едновременно и да връщат резултатите си на оркестратор.
Проблемът е с отворен край. Може да се наложи агентите да изследват различни подходи, да вземат решения и да си сътрудничат, вместо да следват предварително зададена последователност.

Извън тези случаи оркестрацията е просто скъпа мода. Повече агенти означават и повече координация и потенциално по-високи разходи за токени.

„Обикновено започвам с най-простия вариант и надграждам оттам. Ако знаем стъпките и те са повторяеми, това вероятно е работен процес. Виждам причина да въведа множество агенти само когато те имат различни отговорности, разрешения или потребители“, казва Josh Spilker, ръководител на маркетинга в търсачките в AirOps.

Дори и тогава претеглете ползите спрямо допълнителните извиквания на модели, предаванията, забавянето и точките на отказ.

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

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

Диаграма на централизирана оркестрация: един оркестратор получава заявката на потребителя и делегира на агенти за проучване, анализ и дизайн, всеки от които използва собствени инструменти, а резултатите им се обединяват в крайно табло.

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

При децентрализираната оркестрация агентите се координират по-директно, вместо да разчитат на един мениджър да взема всяко решение. Те могат да обменят съобщения, да четат споделено състояние и самостоятелно да определят следващите си стъпки.

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

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

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

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

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

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

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

Как се сравняват тези архитектури:

Критерии	Централизирана	Децентрализирана	Йерархична
Отговорност за изпълнението	Един оркестратор контролира делегирането	Агентите се координират помежду си или чрез споделено състояние	Отговорността е разпределена между нивата на оркестрация
Консистентност на състоянието	По-лесно се координира чрез една контролна точка	Изисква изрична синхронизация и обработка на конфликти	Изисква координация в рамките на разклоненията и между тях
Изолиране на откази	Централният контролер може да се превърне в критична зависимост	Отделните агенти могат да откажат независимо един от друг, но споделената инфраструктура остава критична	Отказите могат да бъдат ограничени в рамките на разклоненията, ако системата е проектирана за възстановяване
Прилагане на политики	Общите контроли могат да се прилагат централизирано	Политиките трябва да се прилагат последователно от всички участници	Контролите могат да се прилагат на глобално ниво и на ниво домейн
Оперативна сложност	Като цяло по-ниска	По-висока сложност на координацията	По-висока сложност поради множество слоеве на оркестрация

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

Ето три модела на изпълнение:

Последователни работни процеси: Агентите работят в предварително определен ред, като резултатът на един агент се превръща във входни данни за друг.
Паралелно изпълнение: Независими агенти работят едновременно.
Изпълнение, базирано на предаване: Контролът преминава между специализирани агенти с напредването на задачата. Това е полезно, когато друг агент е по-добре подготвен да се справи със следващата стъпка, макар че при всяко предаване трябва да се запазва информацията, необходима за продължаване.

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

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

Предаване между агенти със загуба на информация. Оркестраторът предава обобщен план на специализиран агент, но в обобщението липсват ограничения, зависимости или подробности за изпълнението.
Преждевременно обединяване на резултати (fan-in). Агент надолу по веригата започва да обединява резултати, преди всички задачи нагоре по веригата да са приключили.
Недетерминирани актуализации на споделеното състояние. Паралелни агенти записват в едни и същи ключове на състоянието без ясно дефинирана семантика на сливане. В зависимост от това как рамката обработва актуализациите, това може да доведе до загубени записи, дублирани данни, резултати, зависещи от реда, или конфликтни промени.
Разминаване между контролни точки и странични ефекти. Задача извършва външна операция, но успешното ѝ изпълнение не е трайно записано, преди изпълнителят (worker) да се срине. При възстановяване оркестраторът вижда незавършена задача и я изпълнява отново.
Състезания (race conditions) при възобновяване след човешко одобрение. Поставянето на пауза и възобновяването на изпълнението създават собствени проблеми със синхронизацията.
Цикли на делегиране и умножаване на повторните опити. Агентите многократно си прехвърлят работа, защото отговорностите им се припокриват, зависимостите са кръгови или условията за завършване са двусмислени.
Контроли на ниво инструкции, погрешно възприемани като сигурност при изпълнение. Оркестраторът може да укаже на агентите да не осъществяват достъп до определени ресурси или да не извършват чувствителни действия, но инструкциите към модела не налагат разрешения на операционната система, мрежови ограничения или граници на оторизация. Проучването в областта на инженерната сигурност на Perplexity показва защо агентите могат да преминават границите на сигурността, докато преследват легитимни цели, дори без злонамерени инструкции

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

Неясните цели и липсата на ясно определение за завършеност често водят до разочароващи резултати, генерирани от агентите. Решението е договор за промпта (обхват на работата за агента): договорете целта, ограниченията, формата на резултата и условията за неуспех преди да започне изпълнението.

Например ето как бихте могли да дефинирате договор за агент, отговорен за отстраняването на периодично проваляващ се интеграционен тест:

Цел: Да се установи и отстрани причината за нестабилен интеграционен тест на API за плащане (checkout).
Входни данни: Изходен код на теста, логове от неуспешни CI изпълнения, последни къмити и релевантният код на приложението.
Ограничения: Не деактивирайте тестове, не отслабвайте проверките (assertions) и не променяйте несвързано поведение на приложението.
Очакван резултат: Пач на кода, обяснение на основната причина и резултати от изпълнението на тестовете.
Критерии за приемане: Тестът, който досега се проваляше, преминава успешно в 10 последователни изпълнения, а съответният пакет от регресионни тестове също преминава.
Условия за неуспех: Основната причина не може да бъде установена, корекцията въвежда регресии или необходимата тестова среда не е налична.

Но има още една важна част: кога агентът трябва да спре?

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

Да се върнем към нашия пример с CI. Бихте могли да дефинирате следните условия за спиране:

Успех: Корекцията преминава 10 последователни изпълнения на теста и съответния пакет от регресионни тестове.
Лимит на итерациите: Агентът може да опита не повече от две кандидат-корекции.
Бюджет за изпълнение: Агентът трябва да спре след 60 минути, дори ако проблемът остане нерешен.
Лимит на делегирането: Агентът може да делегира работа на един специализиран агент, без по-нататъшно делегиране към подагенти.
Частично завършване: Ако и двата опита са неуспешни или времевият лимит изтече, агентът връща своите констатации, опитаните промени и резултатите от тестовете.
Блокирано изпълнение: Ако тестовата среда не е налична, агентът спира и докладва за пречката, вместо да твърди, че е успял.

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

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

Разгледайте този пример: status: completed се отнася до възложената на агента работа, а не до целия работен процес. Тъй като тестовете все още са в състояние pending, оркестраторът не бива да одобрява крайния резултат.

json

{
  "task_id": "fix-42",
  "status": "completed",
  "artifact_ref": "patch-17",
  "test_status": "pending",
  "blockers": []
}

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

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

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

Да речем, че вашият CI агент задейства изпълнение на тестове, но времето за изчакване на API заявката изтича. Дали изпълнението на тестовете не е успяло да стартира, или CI услугата го е поставила на опашка и е загубила отговора?

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

Временни грешки (429, 503): Опитайте отново с ограничено експоненциално отлагане (backoff) и случайно отклонение (jitter), като спазвате Retry-After, когато е предоставен.
Грешки при валидиране или разрешения (400, 403): Спрете или отстранете основния проблем, вместо да повтаряте същата заявка.
Двусмислени резултати (изтичане на времето след възможен запис): Проверете дали операцията е успяла, преди да я опитате отново.

Забележка: Дори грешките, при които е възможен повторен опит, се нуждаят от ограничения. Задайте време за изчакване за всяко извикване на инструмент, ограничете броя на повторните опити и общото време за тях и наложете общ краен срок за работния процес, за да не могат вложените агенти да рестартират непрекъснато една и съща операция. Ако дадена зависимост многократно се проваля, използвайте прекъсвач (circuit breaker), за да спрете временно заявките.

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

Когато не можете да установите какво се е случило, спрете и ескалирайте.

Пример за логиката на повторните опити за нашия CI агент, изразена като псевдокод:

python

op_id = get_or_create_operation_id(
    task_id=task_id,
    patch_id=patch_id,
    action="start_ci_run"
)

try:
    return ci.start_run(commit, request_id=op_id)
except TimeoutError:
    run = ci.find_by_request_id(op_id)
    if run:
        return run

    if ci.supports_idempotency:
        return bounded_retry(
            lambda: ci.start_run(commit, request_id=op_id)
        )

    raise NeedsReconciliation(op_id)

Бележка към кода: Примерът предполага, че CI API поддържа търсене на изпълнения по идентификатор на заявка. Параметърът request_id предотвратява дубликати само ако доставчикът изрично гарантира идемпотентност. Функцията bounded_retry() е илюстративен псевдокод. В продукционна среда повторните опити трябва да бъдат ограничени както от бюджет за повторни опити за всяка операция (максимален брой опити или изминало време), така и от общия краен срок на работния процес.

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

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

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

Например Effort Mode в Perplexity Computer ви позволява да изберете колко усилие заслужава дадена задача, без ръчно да избирате модел. Изберете Light, Standard, High или Ultra и Perplexity автоматично избира оркестриращия модел и неговото ниво на разсъждение. След това този оркестратор делегира подзадачи на поддържащи агенти, които могат да използват модели от различни доставчици.

Perplexity оценява конфигурациите на моделите по качество и цена, като предпочита по-евтини варианти, които дават сравними резултати. Можете също да използвате контролите Custom, ако предпочитате сами да изберете модела и нивото на разсъждение.

При паралелизма лимитът трябва да се определя от вашата инфраструктура и външните зависимости. Проверете лимитите за заявки и токени на споделените API, след което направете тест под натоварване на работния процес с нарастваща степен на паралелност. Наблюдавайте дали пропускателната способност се подобрява, или заявките започват да се натрупват на опашка, да се забавят или да връщат грешки 429.

За да поддържате потреблението на ресурси предвидимо, налагайте лимити за ресурсите и контроли за планиране:

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

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

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

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

За действия, които изискват човешко одобрение, поставете изпълнението на пауза и запазете точната предложена операция:

нейните параметри
нейния целеви ресурс
своя къмит или версия на състоянието
решението на проверяващия

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

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

Спилкер също не подкрепя идеята напълно автономните агенти от край до край да се възприемат като цел. „За мен по-добрият подход е да се изградят няколко фокусирани агента с ясни отговорности, дефинирани разрешения и човешки преглед в правилните моменти. Пак постигате ефективност, без да се отказвате от пълния контрол“, заключава той.

Случвало ли ви се е агент да докладва Success, когато всъщност се е провалил? Досадно, ако не и вбесяващо, а поправката не е бърза, защото крайното съобщение на агента невинаги ще ви каже къде нещата са се объркали.

За да разследвате, проследете какво се е случило по време на изпълнението и проверете резултатите независимо. Така че нека отделим малко време за изолиране и разрешаване на проблема.

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

Семантичните конвенции за GenAI на OpenTelemetry предоставят стандартизиран начин за описване на тези операции. Например invoke_workflow обозначава изпълнение на работен процес, invoke_agent – извикване на агент, а execute_tool – извикване на инструмент. Всяка операция може да бъде записана като span с нейното времетраене, статус и съответните метаданни.

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

plaintext

invoke_agent  generate_patch   OK
execute_tool  start_ci_run     OK  run_id=9812
execute_tool  get_ci_result    TIMEOUT

agent_response: "Success"

Илюстративно трасиране на изпълнение.

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

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

Все пак трябва да валидирате констатациите на рецензента, където е възможно, а ако използвате оценители, базирани на LLM, за многократни оценявания, калибрирайте преценките им спрямо примери, прегледани от хора.

Досега проследихте какво са изпълнили агентите и проверихте дали резултатите им са правилни. Но какво се случва, когато работник се срине по средата на задача или времето за изчакване на API изтече, след като заявката вече е приета? Изненадващо, вашият работен процес може да се държи отлично при нормални условия, но да се провали по време на възстановяване.

За да проверите това, умишлено внесете грешки в тестова среда:

Симулирайте изтичане на времето за изчакване на API
Предизвиквайте срив на работниците между външните записи и контролните точки
Връщайте неправилно форматирани резултати от инструменти
Оставяйте одобренията да изтекат

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

Да кажем, че вашият CI агент изпраща заявка за стартиране на тестово изпълнение, но времето за изчакване на отговора от API изтича. Агентът опитва отново, получава успешен отговор и съобщава Success. Всичко изглежда наред, докато не проверите CI услугата и не откриете, че вместо едно са създадени две тестови изпълнения.

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

Добавяйте откритите откази към регресионните си тестове, за да не ги въведат отново бъдещи промени.

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

Изолираните агенти могат да изпълняват правилно отделните си задачи, но заедно да дават непоследователни резултати. Представете си агент по продажбите, който извлича условията за клиента в 10:00, агент по ценообразуването, който изчислява оферта с актуализирани цени в 10:05, и правен агент, който проверява договор, променен в 10:07. Всеки агент работи с различна моментна снимка на бизнеса, така че резултатите им може да си противоречат.

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

Задайте ограничения на няколко нива: максимален брой повторни опити за извикване на инструменти, максимален брой итерации на агента, дълбочина на делегиране и общ краен срок за работния процес. Класифицирайте отказите, преди да опитате отново. При временни отговори 429 спазвайте Retry-After, когато е зададен. В противен случай използвайте ограничено експоненциално забавяне (backoff) със случайно отклонение (jitter).

Спрете да повтаряте непроменени заявки след грешки при валидиране или с разрешенията. Ако дадена услуга надолу по веригата отказва многократно, прекъсвач (circuit breaker) може да попречи на агентите да генерират допълнително натоварване.

Механизмът за възстановяване зависи от средата за изпълнение. При LangGraph постоянен checkpointer като PostgresSaver съхранява състоянието на графа под thread_id, което позволява изпълнението да продължи от запазеното състояние. При Temporal друг работник може да реконструира работен процес, като възпроизведе историята на събитията му. По време на възпроизвеждането той използва повторно записаните преди това резултати от активностите.

Ако приложението бъде внедрено наново, докато работните процеси все още се изпълняват, запазеното състояние и историите на изпълнение може вече да не са съвместими. Temporal решава този проблем чрез Worker Versioning и коригиране (patching) на работните процеси. При системи, базирани на контролни точки, планирайте миграциите на схемата и тествайте възстановяването спрямо съществуващите запазени състояния, преди да внедрите несъвместими промени.

Изпълнете едни и същи представителни задачи многократно и разграничавайте pass@k (дали поне един от k опита е успешен) от pass^k (дали всички k опита са успешни)

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

Какво е оркестрация на AI агенти?

Как работи оркестрацията на AI агенти: поглед отвътре в механизма за изпълнение

Кога трябва да използвате оркестрация на AI агенти?

Архитектури за оркестрация на AI агенти и техните компромиси

Централизирана оркестрация

Децентрализирана оркестрация

Йерархична оркестрация

Последователно, паралелно и базирано на предаване изпълнение

Често срещани грешки при оркестрацията на ИИ агенти

7 най-добри практики за оркестрация на ИИ агенти за надеждност в продукционна среда

1. Определете изрични договори за задачите, критерии за приемане и условия за спиране

2. Поддържайте оркестраторите олекотени и налагайте структурирано предаване

3. Съхранявайте трайно състоянието на работния процес и контролирайте нарастването на контекста

4. Проектирайте повторни опити, съобразени с грешките, и възстановимо изпълнение на инструменти

5. Маршрутизирайте и паралелизирайте работата с изрични бюджети за ресурси

6. Налагайте одобрения и изолирайте изпълнението на агентите

7. Проверявайте резултатите независимо и тествайте поведението при възстановяване

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

Прегледайте резултата независимо

Инжектирайте грешки, за да тествате възстановяването

Често задавани въпроси за оркестрацията на AI агенти

Защо изолираните AI агенти се провалят в корпоративен мащаб?

Как да предотвратите безкрайни цикли на повторни опити при AI агентите?

Как да възобновите работен процес на AI агент след срив?

Как да тествате надеждността на оркестрацията на AI агенти?