В первой части я рассказывал про мета-агента (Meta Agent) — свой прототип системы, которая собирает ботов по описанию на естественном языке, и про то, как этот проект занял первое место на внутреннем конкурсе. Напомню концепцию: пользователь говорит «хочу бота» и отгружает требования, а агент проектирует архитектуру и отдает готовый JSON.
Но конкурсный прототип и продакшен-система — это разные вещи. Чтобы реализовать такой функционал для корпоративных пользователей и тем более продавать, нужно сделать так, чтобы наш ИИ-агент для производства ИИ-агентов работал надежно, не один раз, не только на демокейсах и, самое главное, не вытворял что-нибудь неожиданное посреди рабочего процесса. Это значит, что нам нужна инженерная система — с ролями, инструментами, ограничителями и накопленным опытом.
Вторая часть моего лонгрида как раз посвящена тому, как мы реализовали продакшен-решение для создания ИИ-агентов, которое впоследствии стало главным вайб-код-инструментом нашей платформы MWS AI Agents Platform и получило название «ИИ-команда» (AI Force).
Что такое ИИ-команда (AI Force)
Но давайте прежде расскажу о самой фиче, чтобы все были в курсе.
ИИ-команда (AI Force) — это встроенная в MWS AI Agents Platform система на базе большой языковой модели, которая работает как виртуальная команда разработки: текстовое описание, что нужно сделать, на входе — готовый (ну почти) ИИ-агент или бот на выходе. ИИ-команда берет на себя рутинный инженерный цикл создания ИИ-агентов и убирает барьер между идеей и готовым решением. Кто уже имел дело с low-code-платформами, тот знает, что это за барьер. О нем я рассказал в первой части.
Чтобы лучше объяснить, как мы упаковали нашу идею в продакшен-решение, хочу дать одну метафору — она существенно упростит понимание.
Представьте опытного мастера на производстве. У него есть:
Рабочее пространство — станки, верстак, освещение. Среда, в которой он работает.
Ящик с инструментами — молоток, дрель, штангенциркуль. Конкретные инструменты, которыми он делает работу.
Навыки в голове — знание, как работать с конкретным материалом, как читать чертеж.
Методичка — пошаговые инструкции для типовых задач: сначала разметка, потом сверление, потом сборка.
Нормативы — правила, которые он держит в голове всегда: не запускай станок без защиты, не торопись на финальной операции.
Стопоры станка — физические блокировки. Крышка не открыта — станок не включится. Не «попросить быть осторожным», а конструктивное ограничение.
Записная книжка с опытом — куда он пишет: «В прошлый раз этот болт закручивался не так, теперь знаю».
В нашей системе каждый из этих элементов существует в коде:
Аналогия | Что это в ИИ-команде (AI Force) |
Мастер | LLM — языковая модель, которая принимает решения |
Рабочее пространство | Агентная обертка |
Ящик с инструментами | MCP — протокол подключения инструментов |
Инструменты | MCP tools — конкретные вызовы API-платформы |
Навыки в голове | Skills (SKILL.md) — структурированные знания о платформе |
Методичка | Workflows / Recipes — пошаговые флоу |
Нормативы | Rules — правила, которые агент держит в голове |
Стопоры станка | Hooks (PreToolUse / PostToolUse) — инфраструктурные блокировки |
Накопленный опыт | Findings (FINDINGS.md) — база паттернов из реальной работы |
Дальше разберем основные элементы, требующие пояснения.
Ящик с инструментами: MCP
Если вы не сталкивались с MCP раньше, вот для вас небольшой ликбез. Это открытый протокол, который стандартизирует, как ИИ-агенты подключаются к внешним инструментам и сервисам. Anthropic анонсировал его в ноябре 2024-го, с тех пор его приняли OpenAI, Google DeepMind и куча других игроков. По сути, MCP дает ИИ-агентам «ящик с инструментами» под узкую задачу. В нашем случае такой ящик — это FastMCP-сервер на Python, который открывает агенту операции с платформой: создать проект, создать или обновить сценарий, запустить валидацию, протестировать бота в диалоге, опубликовать версию. Примерно двадцать инструментов, каждый со своей схемой входа и выхода.
Ключевое архитектурное решение: агент не знает платформенный API напрямую. Он работает исключительно через MCP. Это намеренная граница — она позволяет контролировать, что агент вообще может сделать, и менять реализацию без изменения агентной логики.
Методичка и нормативы: Workflows и Rules
Агент работает по четкому конвейеру:
discover → plan → build → validate → test → iterate → deploy
Каждый этап — отдельный workflow-файл с четким входом и выходом. Например, discover.md превращает запрос пользователя в Requirements Card и PRD. build-scenario.md берет готовый план и строит один сценарий через MCP-инструменты. test-bot.md прогоняет тест-кейсы и возвращает PASS/FAIL.
Важный момент — PRD как контракт. Прежде чем агент начнет что-либо собирать, пользователь должен явно подтвердить требования. Без этого подтверждения workflow физически не идет дальше. Это аналог Definition of Ready из Agile, только встроенный в агентный процесс.
Rules — это то, что агент держит в голове независимо от этапа. Не ограничения ради ограничений, а выученные уроки. Например: всегда фиксируй bot_id сразу после первого импорта (иначе следующий импорт создаст дубликат вместо обновления). Или: задача закрыта только при 0 FAIL в тестах — никакого «ну оно почти работает». Rules живут в .rules и загружаются в контекст агента при старте любой задачи.
Стопоры станка: почему мягких guardrails недостаточно
Это, пожалуй, самый важный раздел. Потому что интуитивный ответ на вопрос, как сделать агента безопасным, звучит так: добавить в промпт «будь осторожен, не делай ничего деструктивного».
Это не работает.
В июле 2025 года произошел показательный случай: агент Replit удалил production-базу данных пользователя, несмотря на явный запрет это делать. Сам агент написал в логах что-то в духе «я только что уничтожил месяцы работы за секунды». CEO Replit выпустил публичные извинения и сделал вывод о необходимости инфраструктурных изолирующих границ.
Это ровно то, к чему мы пришли самостоятельно.
В нашей вайб-код-системе есть хуки PreToolUse и PostToolUse — слой, который перехватывает каждый вызов инструмента до и после выполнения. На уровне PreToolUse стоят hard gates: проверки, которые физически блокируют операцию при нарушении условий.
Несколько примеров того, что блокируется:
Попытка удалить агента без подтверждения пользователя → дать пользователю верифицировать совершение действия системой.
Попытка импортировать файл без предварительной валидации с нулем ошибок → валидация файла скриптом.
Попытка опубликовать версию, если она не совпадает с протестированной версией → перепроверка решения на основе детерминированной логики.
Попытка повторно импортировать существующего бота вместо использования editor-инструментов → направление системы «на рельсы» .
Попытка начать разработку без подтвержденного PRD → стоп.
Разница принципиальная: это не вероятностная рекомендация модели, это детерминированная проверка на архитектурной границе. Агент не может обойти ее, «рассудив по-другому».
Для сравнения: есть открытый проект Ralph (9k звезд на GitHub), который реализует похожую идею автономного loop: агент итерирует до выполнения всех пунктов PRD, память между итерациями через git-историю и progress.txt. Мы изучали его как паттерн. Но он заточен под разработку кода в целом и не содержит платформо-специфичных guardrails. У нас gates знают семантику конкретной платформы — что значит «валидный импорт», что значит «протестированная версия».
Записная книжка: Findings
Агент работает не в вакууме — он накапливает опыт. В репозитории живет FINDINGS.md — база паттернов, которую система строила в процессе реальной работы.
Структура намеренно типизирована:
RE (Recurring Errors) — ошибки, которые повторяются. Перед нетривиальным шагом агент читает этот список — не затем, чтобы бояться, а затем, чтобы не наступать на одни грабли дважды.
PQ (Platform Quirks) — особенности поведения платформы, которые неочевидны из документации.
WO (Workflow Optimizations) — паттерны, которые работают быстрее.
SI (System Improvements) — предложения по улучшению самой системы. Агент может диагностировать, что что-то устроено неоптимально, и предложить исправление.
Это не просто лог — это живая база знаний, которая реально меняет поведение агента на следующих задачах. Агент ссылается на Findings по ID — так обеспечивается прослеживаемость на каждом шаге.
Где агент находится: Pipeline State Machine
Есть еще одна проблема, которую мы решали отдельно, — это потеря «памяти» агента между сессиями. Встроенного контекстного окна может не хватать для длинных задач. Если сессия прервалась на этапе test, при следующем запуске агент не знает, что уже сделал импорт и получил bot_id, и может начать все заново, создав дубль.
Решение — внешняя machine-readable память: pipeline_state.json хранит текущий этап, залоченные идентификаторы, флаги валидации и тестирования. Это дополнение к встроенной памяти агента, а не замена — для оперативных решений агент использует контекст, для устойчивости между сессиями — state-файл.
Управление через CLI:
python3 scripts/pipeline_state.py show
python3 scripts/pipeline_state.py set-stage test
python3 scripts/pipeline_state.py update-hash bots-by-ai-force/{slug}/bot.json
Бенчмарк и CI: как проверяем, что система работает
Стандартные LLM-бенчмарки вроде MMLU измеряют знания и рассуждения модели, но не то, может ли агент завершить реальную задачу от начала до конца. Для агентного поведения нужен task completion на реальных кейсах.
Мы сделали свой бенчмарк. Принцип простой: агент получает текстовый промпт с задачей → должен в stdout вывести BOT_URL → система автоматически проверяет базовое поведение бота → LLM-judge оценивает качество по критериям.
В CI встроена smoke-проверка: может ли система собрать простейшего бота прямо сейчас. Это регрессионный тест для всего контура: если что-то сломалось в инфраструктуре, платформе или MCP-слое, CI поймает это до того, как сломается что-то в реальной работе.
Архитектура позволяет подключать любой агент через стандартный контракт agent.yaml — это дает возможность сравнивать разные агентные фреймворки на одинаковых задачах. Сейчас активно расширяем набор задач реальными кейсами из внутренних проектов.
Куда мы пришли
Мы пришли к тому, к чему и стремились: реализовали GUI прямо внутри MWS AI Agents Platform. Пользователь пишет задачу в интерфейсе и получает готовое ИИ-решение по своему запросу, не зная ничего про агентный слой под капотом.
Самое интересное в этом проекте — не сама система, а процесс ее построения: каждый раз, когда агент делал что-то неожиданное, это становилось новым Rule, новым gate, новым finding. Система буквально учится на своих ошибках — не в смысле файн-тюнинга, а в смысле инженерного накопления опыта.
Интересно ваше мнение: где граница между «агент делает сам» и «человек контролирует»? И как вы подходите к governance в агентных системах — хуки, внешние ревьюеры, ограниченные среды? Пишите в комментариях.