Агентная инженерия: от вайб-кодинга к мультиагентным системам

Основы агентной инженерии и вайб-кодинга: от хаоса к дисциплине

Представьте, что вы пришли в ресторан и сказали повару: «Сделай мне что-нибудь вкусное». Он нарезал ингредиенты наугад, бросил на сковородку и через 10 минут принёс блюдо. Иногда — шедевр. Иногда — несъедобную кашу. А теперь представьте, что этот повар готовит 500 блюд в день, и вы не можете проверить каждое. Именно так выглядит вайб-кодинг без структуры — и именно поэтому в 2026 году инженерное сообщество перешло к агентной инженерии.

Что такое вайб-кодинг и почему он перестал работать

Вайб-кодинг (vibe coding) — термин, введённый Андреем Карпати в 2025 году. Суть проста: вы описываете желаемый результат на естественном языке, а языковая модель сама придумывает реализацию. Не пишете код — формулируете намерение.

Для прототипов это прорыв. Хакатон, личный скрипт, быстрый MVP — за вечер можно получить работающий продукт. Но когда команды попытались выпускать вайб-код в продакшен, начались проблемы. Код выглядел разумным на поверхности, но содержал уязвимости, отсутствие обработки ошибок и архитектуру, которую невозможно поддерживать. Это явление получило название ИИ-шлак (AI slop) — генерация, которая создаёт видимость качества, но на деле увеличивает технический долг.

Проблема не в модели. Проблема в отсутствии процесса. Вайб-кодинг — это «промпт и надейся». А инженерия — это система ограничений, проверок и обратной связи.

Эволюция: четыре эры разработки

Смена парадигм происходила стремительно:

| Стадия | Период | Подход | Роль человека | |---|---|---|---| | Ручной кодинг | До 2023 | Человек пишет весь код | Автор | | AI-Assisted | 2023–2024 | Модель предлагает дополнения | Автор с автодополнением | | Вайб-кодинг | 2025 | Модель генерирует по описаниям | Автор промптов | | Агентная инженерия | 2026 | Агенты автономно планируют, пишут, тестируют | Архитектор и супервайзер |

Ключевой инсайт: агентная инженерия не отменяет инженерные навыки — она перенаправляет их. Вместо написания кода вы проектируете системы, ограничения и циклы обратной связи, которые позволяют агентам работать надёжно.

Что такое AI-агент

AI-агент — программное приложение, которое использует языковую модель для решения задач, взаимодействует с внешней средой через инструменты и способно выполнять действия без подтверждения человека в каждом случае. В отличие от чат-бота, агент не просто отвечает на вопросы — он планирует, вызывает API, читает файлы, пишет код и проверяет результат.

Базовый цикл работы агента выглядит так: получает задачу → размышляет (Reason) → выбирает и вызывает инструмент (Act) → наблюдает результат (Observe) → принимает решение о следующем шаге. Этот паттерн называется ReAct (Reason + Act) и лежит в основе большинства современных агентных систем.

Фреймворк PEV: План → Выполнение → Верификация

Агентная инженерия заменяет хаотичный процесс структурированным циклом PEV — Plan, Execute, Verify.

План (Plan)

Прежде чем агент напишет хоть одну строку кода, вы определяете:

Цель — что значит «готово»? Какие критерии приёмки?

Роли — какой агент за что отвечает: реализация, тестирование, ревью?

Ограничения — архитектурные границы, стек технологий, стайл-гайды.

Гейты качества — какие тесты должны пройти? Какие проверки обязательны?

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

Расплывчатый план порождает расплывчатый код. Точный план с чёткими ограничениями — сфокусированный, проверяемый результат.

Выполнение (Execute)

Агенты работают автономно в рамках заданных ограничений. Агент реализации пишет код, агент тестирования создаёт тесты, агент ревью проверяет стиль и безопасность. Итерация продолжается, пока работа не пройдёт через все гейты качества. Вмешательство человека нужно только когда агенты застревают или компромисс требует суждения.

Верификация (Verify)

Человек проверяет результат: одобрил бы этот PR инженер? Являются ли тесты значимыми? Не внесены ли уязвимости? Верификация — не формальное штампование, а фаза, где инженерное суждение критически важно.

Почему это работает: реальные результаты

Это не теория. Компании уже получают измеримый эффект. TELUS Digital сэкономила более 500 000 часов благодаря 13 000 ИИ-решений. Zapier достигла 89% внедрения ИИ во всей организации. В Stripe внутренняя система Minions создаёт более 1000 смерженных PR в неделю — от назначения задачи до ревью PR нулевое ручное взаимодействие.

Команда Codex в OpenAI создала промышленное приложение объёмом более миллиона строк, где ни одна строка не написана вручную. Продукт поставляется, развертывается, ломается и чинится — всё делают агенты.

Что меняется в навыках инженера

| Традиционный навык | Эквивалент в агентной инженерии | |---|---| | Написание кода | Точное определение намерения | | Отладка | Отладка поведения агента | | Код-ревью | Валидация вывода агента | | Тестирование | Проектирование стратегии тестирования | | Архитектура | Проектирование системы ограничений |

Что остаётся прежним: чтение кода (вы читаете больше, чем когда-либо), осведомленность о безопасности и системное мышление. Что появляется нового: оценка агентов, контекстная инженерия и проектирование харнессов — инфраструктуры ограничений вокруг агентов.

С чего начать

Если вы сейчас занимаетесь вайб-кодингом, добавьте структуру. Пишите спецификацию перед промптом — определите, что значит «готово». Фиксируйте конвенции проекта в отдельном файле (например, CLAUDE.md или .cursorrules). Запускайте тесты перед принятием кода. Тщательно проверяйте диффы — ищите паттерны ИИ-шлака: ненужные абстракции, галлюцинированные API, отсутствие обработки ошибок.

Четыре простых шага превращают хаотичный вайб-кодинг в структурированный процесс. А дальше — масштабирование к мультиагентным системам, о котором пойдёт речь в следующих статьях.

Проектирование мультиагентных систем: роли, архитектура и фреймворк PEV

Один агент — как один рабочий на стройке. Может копать, месить бетон и даже класть кирпичи. Но построить дом в одиночку — нет. Нужны разнорабочие, прораб, инженер-проектировщик и технадзор. Мультиагентная система — это строительная бригада, где каждый участник выполняет свою специализированную роль, а результат достигается за счёт координации.

Что делает систему мультиагентной

Не каждый набор агентов является мультиагентной системой. Запустить пять экземпляров одной модели с одинаковыми промптами — это не система, а пять параллельных копий. Настоящая мультиагентная система (МАС) возникает при выполнении хотя бы одного из условий:

Агенты имеют разные наборы возможных действий — один пишет код, другой тестирует, третий проверяет безопасность.

Агенты имеют разные задачи в системных промптах и их контекст (история сигналов и действий) не является общим.

Именно различие в возможностях и задачах порождает эмерджентность — система может решать задачи, которые ни один отдельный агент не решит.

Ролевая модель агентной команды

Проектирование МАС начинается с определения ролей. Каждая роль — это специализированный агент с чёткой зоной ответственности:

| Роль агента | Что делает | Когда нужен | |---|---|---| | Автор фич | Пишет код реализации по спецификации | Всегда | | Генератор тестов | Создаёт модульные, интеграционные и E2E тесты | Для любой задачи с логикой | | Код-ревьюер | Проверяет стиль, паттерны, потенциальные баги | Перед мержем | | Хранитель архитектуры | Валидирует соответствие структуре проекта | При изменениях в архитектуре | | Сканер безопасности | Выявляет уязвимости и ИИ-шлак | Перед мержем | | Писатель документации | Обновляет документацию под изменения кода | При публичных API | | Релиз-менеджер | Управляет CI/CD и проверками развертывания | На этапе деплоя |

Важно: роли не привязаны к конкретным моделям. Один и тот же движок может выполнять разные роли при разных системных промптах и наборах инструментов. Суть — в разделении ответственности, а не в количестве моделей.

Архитектура: как агенты связаны друг с другом

Между агентами в МАС должна быть определена схема взаимодействия. Три базовых паттерна:

Конвейер (Pipeline)

Самый распространённый паттерн. Агенты работают последовательно, каждый получает артефакт предыдущего:

Прост, предсказуем, легко дебажить. Если что-то пошло не так — вы точно знаете, на каком этапе.

Маршрутизатор (Router + Specialists)

Центральный агент-роутер анализирует входящую задачу и направляет её нужному специалисту. Роутер не выполняет работу сам — он распределяет. Полезен, когда задачи разнородны: одна требует рефакторинга, другая — написания документации, третья — исправления бага.

Состязательный (Adversarial)

Два агента работают в оппозиции: один генерирует решение, другой ищет в нём слабые места. Цикл повторяется, пока критик не найдёт существенных проблем. Особенно эффективен для задач безопасности и качества — по сути, автоматизированный код-ревью с «красным» и «зелёным» агентами.

Углубляем PEV: фреймворк в действии

В первой статье мы познакомились с циклом PEV на базовом уровне. Теперь — как он работает в мультиагентном контексте.

План: проектирование системы

На этапе планирования вы решаете не «что написать», а «как устроить процесс»:

Декомпозиция на задачи — разбейте цель на рабочие единицы, соразмерные возможностям одного агента. Не просите «напиши CRUD API с авторизацией и тестами» — разбейте на: типы данных, сервисы, обработку ошибок, роуты, тесты. Каждый шаг — отдельная задача для агента.

Назначение ролей — определите, какой агент какую задачу выполняет. Автор фич не должен сам себя тестировать — это конфликт интересов, как и в человеческой команде.

Определение гейтов — между каждым этапом конвейера стоит контрольная точка. Тесты должны пройти. Линтер не должен ругаться. Сканер безопасности не должен находить критические уязвимости.

Установка ограничений — архитектурные границы, правила стека, запреты (например, «не использовать any в TypeScript», «не добавлять зависимости без согласования»).

Выполнение: автономная работа агентов

Агенты работают в рамках ограничений, не видя общей картины. Автор фич получает спецификацию и пишет код. Генератор тестов получает код и пишет тесты. Каждый агент видит только свою часть контекста — это и ограничивает ошибки, и повышает фокус.

Автономия не означает изоляцию. Артефакты передаются между агентами: код → тесты → ревью → исправления. Но решение о следующем шаге каждый агент принимает внутри своей зоны ответственности.

Верификация: человек как арбитр

Верификация в МАС — это не проверка одной задачи, а оценка всей цепочки. Человек смотрит на финальный результат и задаёт вопросы: согласуется ли архитектура с существующей кодовой базой? Покрывают ли тесты реальные сценарии, а не только «happy path»? Не внесены ли уязвимости?

Критический нюанс: верификация — это фаза, где инженерное суждение заменяет автоматику. Агенты могут пройти все гейты формально, но решение всё равно может быть неоптимальным с точки зрения архитектуры или бизнес-логики.

Когда мультиагентность — оверинжиниринг

Не каждая задача требует бригады. Если вы пишете скрипт для разового использования — один агент со спецификацией справится лучше и быстрее. Мультиагентные системы оправданы, когда:

Задача имеет чёткие фазы с разными компетенциями (код, тесты, безопасность).

Качество критично и нужен независимый контроль.

Кодовая база большая и изменения затрагивают多个 компонентов.

Нужен масштабируемый процесс, а не разовое решение.

Для прототипов и личных проектов — один агент с хорошей спецификацией. Для продакшена — мультиагентный конвейер с гейтами качества.

Оркестрация агентов и субагентов: конвейеры, координация и контроль

Представьте оркестр без дирижёра. Каждый музыкант — виртуоз, но без координации получается какофония. Оркестрация агентов — это роль дирижёра: не играть на инструменте, а обеспечить, чтобы 30 специалистов сыграли симфонию синхронно. В мультиагентных системах именно оркестрация определяет, будет ли результат хаосом или продуктом.

Конвейер: от спецификации до деплоя

Самый зрелый паттерн оркестрации — конвейер (pipeline). Каждый агент получает входные данные от предыдущего, выполняет свою работу и передаёт результат дальше. Никаких пересечений, никаких конфликтов.

Реальный конвейер из практики Stripe выглядит так: разработчик публикует задачу в Slack → агент (Minion) пишет код → проходит CI → открывает PR → человек проверяет и мёрджит. Между назначением задачи и ревью PR — нулевое ручное взаимодействие. Более 1000 смерженных PR в неделю.

Конвейер работает, потому что каждое звено имеет чёткий вход и выход. Если генератор тестов получил код без типов — он не пытается догадываться, а возвращает ошибку на предыдущий этап. Это и есть гейт качества — контрольная точка, через которую должен пройти артефакт, прежде чем попасть к следующему агенту.

Субагенты: вложенная оркестровка

Когда задача внутри одного этапа конвейера оказывается слишком сложной для одного агента, появляются субагенты — агенты, которых запускает другой агент. Оркестратор делегирует подзадачи и собирает результаты.

Практический пример: агент-автор фичи должен реализовать API-эндпоинт, который затрагивает три сервиса. Вместо того чтобы писать всё сам, он поручает субагентам: первый — обновить схему базы данных, второй — написать бизнес-логику, третий — обновить API-роуты. Каждый субагент работает в изолированном контексте, возвращает результат, оркестратор проверяет согласованность.

Изоляция субагентов критически важна. Git worktree — один из практических инструментов для этого: каждый субагент работает в своей копии репозитория на отдельной ветке. Никаких конфликтов файлов, никаких race condition. Если результат не нужен — worktree удаляется. Если нужен — мёрджится в основную ветку.

Модели координации

Помимо конвейера, существуют и другие схемы взаимодействия агентов:

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

Peer-to-peer. Агенты общаются напрямую друг с другом через стандартизированные протоколы (например, A2A — Agent-to-Agent). Нет центральной точки. Плюс: устойчивость к отказам. Минус: сложнее отлаживать и контролировать.

Иерархическая. Верхний уровень — стратегические агенты, которые разбивают задачи. Средний уровень — тактические агенты, которые планируют последовательности действий. Нижний уровень — исполнительные агенты, которые вызывают инструменты. Каждый уровень делегирует вниз и отчитывается вверх.

Контрольные точки: где человек вмешивается

Даже в полностью автономном конвейере есть места, где вмешательство человека обязательно:

Перед мержем в основную ветку — финальное ревью PR. Агенты могут пройти все автоматические проверки, но архитектурное решение всё равно требует человеческого суждения.

При компромиссных решениях — когда агент обнаруживает конфликт требований (скорость vs безопасность, обратная совместимость vs чистота API), он должен остановиться и запросить решение.

При превышении лимитов — если агент превысил лимит итераций, бюджет токенов или обнаружил аномалию в поведении, процесс останавливается.

Это принцип Human-in-the-Loop (HITL) — человек в цикле. Автоматика работает между контрольными точками, но ключевые решения остаются за инженером.

Метрики: как понять, работает ли оркестрация

Оркестрация без метрик — это дирижёр без слуха. Ключевые показатели:

Процент успеха агентов — какая доля задач завершается без вмешательства человека?

Частота отклонения ревью — насколько часто код-ревьюер или сканер безопасности отклоняют результат?

Время цикла — сколько времени проходит от задачи до готового PR?

Частота багов в проде — снижается ли количество дефектов после внедрения агентного конвейера?

Компания NxCode сообщает, что их CI-валидация отлавливает около 15% кода агентов, который мог бы внести баги. Это не заменяет человеческое ревью, но существенно снижает нагрузку на него.

Антипаттерны оркестрации

Три типичные ошибки, которые превращают оркестрацию в хаос:

Слишком много автономии. Если агент может сам решить, какие инструменты вызывать, в каком порядке и с какими параметрами — без ограничений — он начнёт «tool bombing»: бесконечные вызовы инструментов, каждый из которых порождает новые задачи. Решение: лимит итераций и инструментальных вызовов на один запрос.

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

Отсутствие circuit breaker. Если агент попал в цикл ошибок, система должна это обнаружить и остановиться, а не генерировать токены бесконечно. Решение: мониторинг аномалий в поведении, автоматический kill switch при превышении порогов.

Инструменты и рабочие процессы: харнессы, правила и настройка агентов

Когда новый разработчик приходит в команду, ему дают не просто доступ к репозиторию. Ему дают онбординг-документ, показывают архитектуру, объясняют паттерны и предупреждают о граблях. AI-агенту нужно то же самое — только формализованнее. Именно здесь появляются харнессы, правила и файлы настройки, которые превращают «умную модель» в управляемого участника команды.

CLAUDE.md и .cursorrules: онбординг для агента

CLAUDE.md — это не документация и не README. Это онбординг-документ для AI-агента. Файл, который модель загружает перед каждой задачей и работает в рамках зафиксированных правил. Аналогичные файлы существуют в других средах: .cursorrules для Cursor, .windsurfrules для Windsurf, .github/copilot-instructions.md для Copilot. Принцип одинаковый — формат отличается.

Эффективный CLAUDE.md строится из пяти секций:

Проект — краткое описание, стек, архитектура. Одним абзацем: «SaaS-платформа. Next.js 15, Prisma, PostgreSQL».

Структура директорий — где что лежит. Агент должен знать, куда класть новый файл.

Паттерны кода — один-два примера типичного эндпоинта или компонента. Не описание, а реальный фрагмент. Модель копирует стиль из примера.

Правила — что делать всегда: async/await вместо промисов, валидация через Zod, формат ошибок.

Запрещено — что не делать никогда: any в TypeScript, console.log в продакшене, прямые SQL-запросы.

Три ошибки, которые убивают эффективность CLAUDE.md:

Слишком длинный. Больше 1000 строк — правила начинают противоречить друг другу, и модель выбирает между конфликтующими инструкциями наугад.

Слишком абстрактный. «Пиши чистый код» — бесполезно. «Каждый API-эндпоинт возвращает { data, error, meta }» — работает.

Устаревший. Переименовали директорию, сменили ORM — а CLAUDE.md описывает прошлую архитектуру. Агент генерирует код для проекта, которого больше нет.

Практический совет: начните с 50 строк. Запустите агента, посмотрите, где он ошибается. Добавьте правило. Снова ошибся — добавьте пример. Через неделю у вас будет рабочий документ, выросший из реальных проблем.

Промпт-инженерия для агентов: шесть приёмов

Промпт для агента — это не пожелание. Это спецификация. Чем меньше модель додумывает — тем предсказуемее результат.

Контекст-фрейм. Начните с ограничений, а не с задачи. «Проект: Next.js 15, TypeScript strict, Zod, Prisma. Не используй any. Не добавляй зависимости» — один абзац контекста экономит три итерации переписывания.

Примеры входа-выхода. Два-три примера задают формат точнее, чем абзац требований. user@domain.com → valid: true. test@ → valid: false, причина: нет домена.

Negative prompting. Каждое «не» сужает пространство решений. «Рефакторни processOrder. НЕ меняй сигнатуру. НЕ добавляй зависимости. НЕ трогай /src/core/».

Chunking. Одна задача — один промпт. При большом объёме задачи модель теряет фокус и начинает «срезать углы».

Spec-first. Опишите контракт снаружи: POST /api/orders, тело запроса, варианты ответов — 201, 400, 404, 409. Когда контракт определён, реализация становится механической задачей.

Привязка к реальности. Модели выдумывают методы и пакеты. Решение — дать фрагмент реальной схемы или документации прямо в промпте: «Prisma. Используй ТОЛЬКО findUnique/findFirst/findMany для чтения».

Харнессы: инфраструктура ограничений

Харнесс (harness) — это совокупность ограничений, линтеров, проверок и циклов обратной связи, окружающих агента. Не промпт, не модель — именно инфраструктура, которая делает работу агента predictable.

Харнесс включает:

Линтеры и форматеры — автоматическая проверка стиля кода после каждой генерации. Агент не должен думать о точках с запятой — линтер исправит.

CI-валидация — автоматические тесты запускаются после каждого изменения. Если тесты не прошли — агент получает ошибку и итерирует.

Ограничения на инструменты — allowlist инструментов, которые агент может вызвать. Не «используй любые API», а «вот три разрешённых эндпоинта».

Лимиты итераций — максимальное количество вызовов модели и инструментов на одну задачу. Защита от бесконечных циклов.

Budget control — лимиты по токенам и стоимости. Агент не должен сжигать бюджет на простую задачу.

MCP: стандартизация инструментов

Model Context Protocol (MCP) — протокол, стандартизирующий взаимодействие агентов с внешним миром. Представлен в конце 2024 года, стал де-факто стандартом к 2026-му.

До MCP каждый агент интегрировал каждый инструмент отдельно: N агентов × M инструментов = N×M интеграций. MCP решает это через единый протокол: инструмент один раз оборачивается в MCP-сервер, любой агент подключается по стандартному интерфейсу — итого N+M интеграций.

Архитектура MCP строится на трёх ролях: Host (приложение, в котором живёт агент), Client (компонент, держащий соединение с сервером), Server (процесс, предоставляющий инструменты). Три примитива: Tools (функции для вызова), Resources (данные для чтения), Prompts (шаблоны для типовых сценариев).

Критически важный нюанс: описание инструмента в MCP — это промпт для модели, а не комментарий для человека. «Работает с данными» — бесполезно. «Возвращает список открытых задач проекта. Принимает статус фильтрации. Если задач нет — пустой массив» — агент поймёт и использует.

Практический путь внедрения

Этап 1 — зафиксируйте конвенции в CLAUDE.md (50 строк, расти по мере ошибок). Этап 2 — добавьте CI-валидацию и линтеры в харнесс. Этап 3 — подключите MCP-серверы для инструментов, которые агент использует регулярно. Этап 4 — настройте метрики: процент успеха, частоту отклонений, время цикла.

Каждый этап даёт измеримое улучшение. Не нужно строить идеальную систему с первого дня — нужно закрывать конкретные боли по мере их обнаружения.

Безопасность и контроль качества: защита от ИИ-шлака и уязвимостей

В феврале 2026 года исследователи продемонстрировали атаку на корпоративного агента: письмо содержало скрытую инструкцию, которую агент трактовал как приоритетную задачу, — и переслал конфиденциальные документы на внешний адрес. Ни один фильтр промптов не сработал, потому что атака не содержала «злых слов». Она содержала убедительный контекст. Это не гипотетический сценарий — это смертельная триада (Lethal Trifecta) в действии, и каждая мультиагентная система потенциально уязвима.

ИИ-шлак: невидимый враг качества

ИИ-шлак (AI slop) — код, который выглядит разумным на поверхности, но содержит скрытые дефекты. Не баги в классическом смысле — модель не напишет синтаксическую ошибку. Она напишет нечто хуже: код, который компилируется, проходит тесты happy path, но ломается в edge case, вносит уязвимость или создаёт неподдерживаемую архитектуру.

Пять паттернов ИИ-шлака, которые нужно уметь распознавать:

Галлюцинации API. Модель вызывает метод, которого не существует в вашей версии библиотеки, или использует несуществующий пакет. Код выглядит правдоподобно, потому что модель «видела» похожий паттерн в обучающих данных.

Happy path only. Тесты, которые проверяют только идеальный сценарий. Нет проверки на null, пустые массивы, сетевые ошибки, граничные значения. Формально — тесты есть. Фактически — они не защищают ни от чего.

Security-дыры. Отсутствие санитизации входных данных, хранение секретов в коде, небезопасные десериализации. Модель не знает вашу модель угроз по умолчанию.

Phantom dependencies. Импорт пакета, который не добавлен в package.json. Или наоборот — добавление зависимости, которая конфликтует с существующей.

Устаревший синтаксис. Использование deprecated API или паттернов, которые были актуальны два года назад, но не сегодня.

Как ловить систематически: настройте CI так, чтобы он проверял не только прохождение тестов, но и покрытие, отсутствие deprecated-вызовов, наличие обработки ошибок в каждом catch-блоке, соответствие импортов package.json.

Lethal Trifecta: три условия катастрофы

Lethal Trifecta — модель оценки рисков для агентных систем, предложенная Саймоном Уиллисоном. Три условия, при одновременном наличии которых непрямая prompt-инъекция практически неизбежно превращается в утечку данных:

Private data — агент имеет доступ к приватным данным (почта, документы, база данных, секреты).

Untrusted content — агент потребляет недоверенный контент (веб, письма, вложения, выводы инструментов, сообщения других агентов).

External communication — есть канал наружу (HTTP-запросы, email, комментарии в публичных репозиториях).

Если все три ножки присутствуют — система критически уязвима. Стратегия защиты всегда сводится к «сломать хотя бы одну ножку»:

| Ножка | Как снижать риск | Компромисс | |---|---|---| | Private data | Short-lived токены, per-task scope, data minimization | Агент выполняет меньше задач «автоматом» | | External communication | Allowlist доменов, HITL для публикаций, DLP на выходе | Меньше гибкости в сценариях | | Untrusted content | Маркировка источников, отделение data от control | Выше latency, сложнее UX |

Полезная практика: прогонять Trifecta как короткий архитектурный тест на каждом ревью. Что агент читает? Чему он верит? Что он может сделать вовне? Если хотя бы на один вопрос ответ «почти без ограничений» — пересматривайте архитектуру.

OWASP Agentic Top 10: карта уязвимостей

OWASP выпустил специализированный Top 10 для агентных приложений в 2026 году. Десять категорий угроз, из которых выделим пять наиболее критичных для мультиагентных систем:

ASI01 — Agent Goal Hijack. Внешний контент (письмо, веб-страница, вывод инструмента) содержит скрытую инструкцию, которую агент трактует как приоритетную задачу. Защита: независимый policy/intent gate, явный approval для high-impact действий, маркировка источников контента.

ASI02 — Tool Misuse. Легитимный инструмент вызывается с вредным intent или параметрами. Каскад из нескольких инструментов amplifies последствия. Защита: allowlist инструментов, ограничение blast radius на каждый tool, корреляция опасных цепочек.

ASI06 — Memory & Context Poisoning. Агент сохраняет фрагменты из недоверенных источников в память, а потом переиспользует их как «доверенные». Загрязнение копится постепенно. Защита: сегментация по tenant, trust scoring, TTL/expiry, карантин для сомнительных записей.

ASI07 — Insecure Inter-Agent Communication. Спуфинг, replay, подмена сообщений между агентами в мультиагентной системе. Защита: mTLS/PKI, подпись сообщений, anti-replay (nonce/timestamp), строгая валидация схем.

ASI10 — Rogue Agents. Долгоживущий агент постепенно дрейфует от своих целей, расширяет зону доверия, low-and-slow выходит за рамки. Защита: platform-level kill switch, behavioral baseline и алерты, регулярные ревью целей.

Трёхэтапный roadmap внедрения защиты

Этап 1: Инвентаризация и сокращение поверхности атаки

Проведите Trifecta-аудит: перечислите все данные, к которым имеет доступ агент, все внешние каналы, все потребляемые источники. Запретите лишний egress — агент не должен обращаться к произвольным URL. Включите подробный аудит действий: кто, что, когда, откуда принял решение.

Этап 2: Политики и контроль исполнения

Внедрите независимый policy/intent gate — модуль, который проверяет намерение агента перед выполнением consequential actions. Перейдите на JIT-токены с коротким временем жизни. Сделайте обязательные approvals для high-impact действий: финансовые транзакции, отправка сообщений наружу, изменение критичных данных.

Этап 3: Мониторинг и аварийное реагирование

Сегментируйте память, введите TTL и процедуры очистки. Настройте трассировку цепочек действий (lineage) и корреляцию событий для раннего обнаружения аномалий. Подготовьте регламент аварийного реагирования: kill switch, отзыв токенов, карантин агента.

Главный принцип

Детекторы prompt-инъекции — это слой защиты, а не стена. Реальные кейсы показывают, что обходы классификаторов неизбежны. Самая сильная защита — ограничить последствия: policy enforcement до исполнения, least privilege, JIT-доступы, egress control, sandboxing и kill switch. Агентные системы — это распределённые системы. Без неизменяемых логов, корреляции цепочек и circuit breakers вы не увидите катастрофу до её наступления.