У Walmart уже больше 20 тысяч разработчиков и дата-сайентистов, которые «строят агентов как сумасшедшие». На этом фоне архитектура AI-агентов перестает быть игрушкой для демо и становится обычной инженерной проблемой: как не утонуть в промптах, копипасте и хаотичных вызовах инструментов. Именно об этом на QCon AI говорил технический fellow Walmart Global Tech Джейк Манникс, сообщает InfoQ.
Манникс описал знакомую многим картину без лишней романтики. Формально индустрия получила новый способ программирования на естественном языке, о котором Андрей Карпати заговорил вскоре после релиза ChatGPT 30 ноября 2022 года. По факту же, если смотреть на продакшен-агентов, мы часто оказываемся в мире «1975-го»: один большой файл, все намешано в одном месте, переходы почти как GOTO, а логика прыгает туда-сюда уже не по воле разработчика, а по воле модели. Для команды это означает предсказуемые проблемы старого доброго монолита, только теперь они замаскированы под «агентность» и дополнительно осложнены недетерминизмом LLM.
Что именно не так с нынешними агентами
Главная претензия Манникса не к самим моделям, а к способу, которым индустрия обвязала их инструментами. Он отдельно прошелся по Model Context Protocol, который за последний год стал де-факто стандартом для подключения внешних возможностей к агентам. Идея здравая: вынести специализированные действия в отдельные серверы, чтобы Slack отвечал за Slack, платежный стек за платежи, а агент только связывал эти куски в рантайме. Это действительно шаг вперед по сравнению с режимом «каждый пишет один и тот же инструмент заново». Но есть проблема: на практике многие реализации MCP сводятся к тому, что имя инструмента, его описание и схема параметров просто целиком вставляются в системный промпт. Получается не интерфейс в привычном инженерном смысле, а огромная текстовая простыня, на которой держится полприложения.
Отсюда вылезают довольно приземленные баги. Если у компании внутренние документы называют задачи stories, а Jira-инструмент оперирует tickets, модель должна каждый раз сама догадываться, что речь об одном и том же. Если в конкретном контексте всегда нужен фиксированный organization ID, она должна не забывать подставлять его при каждом вызове. Если рядом есть два похожих инструмента, различающихся нюансами, LLM снова обязана угадать правильный. Для прототипа это терпимо. Для продакшена, где агент связан с корпоративными системами, правами доступа и живыми бизнес-процессами, это уже не «мелкая шероховатость», а нормальный источник аварий, утечек и дорогостоящего ручного разбора.
Манникс отдельно подчеркнул еще одну неприятную вещь: хороший MCP-инструмент нельзя просто честно выгрузить из OpenAPI-спеки и считать работу сделанной. По его словам, из такой автоматизации обычно получается мусор: сотни эндпоинтов без нормальной гранулярности, с плохими описаниями и без учета того, как LLM вообще принимает решения. Нормальный инструмент для агента требует ручного дизайна. Нужно понять, сколько операций реально должно быть доступно модели, какие параметры ей необходимы, как сформулировать описание, чтобы она не путалась, и где провести границу между удобством и безопасностью. Иначе вместо программируемого интерфейса команда получает еще один пакет скрытой сложности, только теперь в JSON-схемах и подсказках для модели.
Что Манникс предлагает взамен
Ключевая идея доклада довольно инженерная и оттого полезная: между агентом и реальными инструментами нужен промежуточный протокольный слой. Не еще одна «магическая платформа», а прослойка, которая позволяет собирать версионированные и инкапсулированные virtual tools, или виртуальные инструменты. Это уже похоже не на копипасту в промпт, а на нормальную разработку, где есть интерфейсы, адаптеры и контролируемые зависимости. Такой слой, по Манниксу, дает сразу несколько практических преимуществ. Во-первых, появляется mapping интерфейсов: можно аккуратно связать бизнес-термины одной команды с конкретными полями и параметрами реального инструмента. Во-вторых, становится возможна динамическая проекция схемы: агенту показывают не всю исходную сложность backend-интерфейса, а только тот срез, который нужен в текущем сценарии. В-третьих, можно встроить runtime taint tracking, то есть отслеживание «зараженных» данных, чтобы заранее пресекать рискованную передачу чувствительной информации наружу.
Последний пункт особенно важен для крупных компаний, потому что спор вокруг агентных систем давно вышел за пределы «умеет ли модель позвать API». В enterprise-контуре главный вопрос другой: как не замедлить команды бесконечными согласованиями, но и не открыть случайный канал для утечки данных. Манникс как раз делает акцент на том, что защиту нужно встраивать в архитектуру, а не навешивать поверх нее постфактум. Если промежуточный слой понимает, какие данные откуда пришли, куда они текут и какие ограничения на них наложены, он может срезать опасный маршрут до того, как модель отправит лишнее внешнему инструменту. Для разработчиков это хороший сигнал: безопасность агентной системы можно обсуждать не только в терминах политик и ревью, но и как часть контрактов между компонентами.
Для русскоязычной IT-аудитории здесь, пожалуй, важнее всего не сам Walmart и не очередной спор о будущем MCP. Важнее то, что архитектура AI-агентов начинает проходить тот же путь, что когда-то прошел обычный корпоративный софт: от «быстро склеили, работает же» к интерфейсам, версиям, повторному использованию и контролю данных. Если команда уже делает внутренних помощников для разработчиков, аналитиков, HR или саппорта, доклад Манникса звучит как неприятное, но полезное напоминание: агент — это не промпт с функциями, а система, которой нужны те же инженерные дисциплины, что и любому другому продакшен-сервису. И чем раньше компании перестанут относиться к промпту как к месту, где можно спрятать всю бизнес-логику сразу, тем меньше будет сюрпризов на следующем витке внедрения.
Следующий большой вопрос уже не в том, приживется ли сама идея виртуальных инструментов, а в том, кто первым превратит ее в удобный стандарт разработки. Если этого не случится, рынок рискует застрять в странном промежуточном состоянии: с модными агентами снаружи и с архитектурой эпохи BASIC внутри.