Човешкото пречка в многоагентните системи: Как да препроектирате инженерните работни процеси, когато вашите агенти изпреварват вашия надзор

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

Допълнителен материал към по-широката ни работа по управление на агенти и готовност за производство. Вижте „Агентите с изкуствен интелект се нуждаят от идентичност, разрешения и одитни следи: Инженерната архитектура, която повечето екипи нямат, за инфраструктурата за идентичност и разрешения, която е в основата на безопасната работа на агенти в голям мащаб“.

Защо процесите на преглед на наследени продукти се прекъсват при едновременно натоварване на агенти

Традиционните работни процеси за заявки за изтегляне (pull request) са проектирани около нивата на човешко авторство. Старши инженер може да отвори от три до пет заявки за изпълнение (PR) седмично; екип от осем души създава управляема опашка за преглед. Флот от десет кодиращи агенти, работещи в паралелни работни потоци, може да генерира този обем за един следобед. Опашката за преглед не просто се удължава; тя се влошава качествено, защото под натиск от време проверяващите преминават от оценяване на коректността и намерението за проектиране към сканиране за повърхностни грешки. Това е режимът на неуспех, който е най-важен: не че агентите създават лош код, а че процесът на преглед спира да го засича. Търговското последствие е, че нивата на дефекти се увеличават точно с увеличаването на скоростта на внедряване, което утежнява техническия дълг и въвежда риск от регресия в най-лошия възможен момент.

Преосмисляне на проблема с надзора като архитектурен проблем

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

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

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

Модели на оркестрация, които запазват човешката четливост

Топология „супервайзор-агент“

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

Тръбопроводи с контролно-пропускателен контрол

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

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

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

Изисквания за интеграция на инструменти

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

Управление и приемственост на одита

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