Конфигуриране като код, MCP и новите инфраструктурни примитиви, от които вашият инженерен екип се нуждае, за да управлява ИИ в голям мащаб

Инженерните организации, които мащабираха разпределени паркове от устройства през 2010-те, научиха специфичен урок за отклонението на конфигурацията: в момента, в който действителното състояние на системата се отклони от документираното ѝ планирано състояние, екипът, който я управлява, действа въз основа на предположения, а не на доказателства. Този урок беше кодифициран в практики „инфраструктура като код“, работни процеси на GitOps и инструменти за декларативно управление на конфигурацията. Същото отклонение сега се наблюдава и в среди за разработчици на изкуствен интелект, където конфигурациите на агенти, регистрите на инструменти, правилата за маршрутизиране на модели и скелето на промпти се натрупват в инженерните екипи без контрол на версиите, без одитни следи и без систематичен механизъм за откриване кога поведението на производствен агент вече не съответства на първоначалната му спецификация. Сближаването на дисциплината „конфигуриране като код“ с възникващата роля на Model Context Protocol като програмируем интерфейсен слой създава условия за директно справяне с това, но само ако инженерните ръководители вземат обмислени архитектурни решения, преди проблемът да се влоши.

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

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

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

Какво всъщност означава конфигурацията като код за AI инфраструктурата

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

MCP като програмируем интерфейсен слой

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

Управление на регистъра на инструментите

Регистърът на инструментите в MCP-базирана архитектура е авторитетният запис за това кои сървъри на инструменти са достъпни за кои агенти и при какви условия. Без изрично управление, регистрите на инструментите натрупват записи чрез индивидуални екипни решения и губят записи чрез остарявания на сървъри, които не се разпространяват до всички консумиращи агенти. Резултатът е среда, в която агентите могат да извикват инструменти, които са остарели, да извикват различни версии на един и същ инструмент в зависимост от това спрямо коя снимка на регистъра са били инициализирани, или да се провалят тихо, когато даден инструмент бъде премахнат без съответна актуализация за агентите, които зависят от него. Третирането на регистъра на инструментите като артефакт на инфраструктура с версии, с процеси за преглед на промените, еквивалентни на тези, прилагани към API договорите, затваря този режим на отказ.

Маршрутизиране на модела и закрепване на версиите

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

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

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

Измерението „Одит и съответствие“

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

Архитектура на внедряване: Какво да стандартизираме първо

Практическият въпрос за ръководителя на инженерния отдел не е дали да приложи дисциплината „конфигуриране като код“ към инфраструктурата с изкуствен интелект, а откъде да започне, като се има предвид, че повечето екипи вече използват агенти в производство без нея. Най-важната отправна точка е регистърът на MCP сървъра, защото той е граничният слой, който управлява какво може да прави всеки агент. Изразяването на дефинициите на сървъра в декларативен формат, съхраняването им в хранилище със защита на клонове и преглед на промените, както и внедряването им чрез конвейер, който записва състоянието на внедряването, създава одитна следа за наличността на инструментите, без да се изискват промени в съществуващите агенти. Финирането на версиите на модела е вторият приоритет, защото това е конфигурационният параметър, който най-вероятно ще причини тиха поведенческа регресия, когато се променя неформално. Шаблоните за подкани и правилата за сглобяване на контекст са третият приоритет и те изискват най-много организационни промени, тъй като в момента се третират като продуктови артефакти, а не като инфраструктура. Преместването им в контрол на версиите изисква споразумение между продукта и инженерния отдел относно собствеността и процесите на промяна, което е организационно решение, както и техническо.