Боевой воркфлоу в современных AI-IDE: управление контекстом и MCP без деградации

Номинальный размер контекстного окна современных моделей перевалил за сотни тысяч токенов, однако любой практикующий разработчик знает: если свалить в одну сессию логи за три часа, дампы базы и двадцать несвязанных файлов, точность рассуждений модели резко падает. Этот эффект мы называем Context Pollution (загрязнение рабочего контекста).

1. Почему раздутый контекст убивает точность

Механизм внимания трансформеров теряет разрешающую способность в середине длинного промпта, особенно когда в истории диалога накапливаются отвергнутые гипотезы и старые стектрейсы. Чтобы агент работал со стабильной точностью на репозиториях свыше 100 000 строк кода, необходимо управлять его вниманием так же бережно, как оперативной памятью в высоконагруженном сервисе.

• Одна задача — одна изолированная сессия: никогда не смешивайте в одном треде рефакторинг слоя БД и вёрстку фронтенд-компонента;
• Делегирование разведки субагенту: поиск по сотням файлов и чтение объёмных логов лучше поручить read-only субагенту, который вернёт в основной контекст сжатую выжимку на 30 строк;
• Явная фиксация точек входа: передавайте точные пути к интерфейсам и моделям, от которых строится изменение.

2. Архитектура прогрессивного раскрытия (Progressive Disclosure)

Вместо того чтобы хранить гигантский системный промпт на 3 000 строк, который загружается при каждом сообщении, мы на курсе внедряем модульную структуру .agents/. Корневой файл AGENTS.md занимает не более 80–120 строк и содержит только ядро архитектуры и навигационную карту по узкоспециализированным навыкам (skills/).

3. Гигиена инструментов MCP и защита окружения

Подключение Model Context Protocol (MCP) даёт агенту прямой доступ к схеме БД, документации и браузерному DevTools. Однако избыток активных MCP-серверов съедает тысячи токенов только на описание JSON-схем инструментов:

#!/usr/bin/env bash
set -euo pipefail

echo "[1/3] Проверка чистоты рабочей ветки и миграций..."
uv run alembic check

echo "[2/3] Форматирование и статический анализ Ruff..."
uv run ruff check --fix src/ tests/
uv run ruff format --check src/ tests/

echo "[3/3] Строгая проверка типов Mypy..."
uv run mypy src/

echo "✓ Локальный гейт верификации успешно пройден."

4. Четырёхшаговый цикл инженерной сессии

На лабораторных стендах VibeCoder School студенты отрабатывают строгий цикл выполнения фичи:

1. Phase 1 — Research & Plan: агент в режиме чтения исследует затронутые модули и формирует краткий план изменений (какие DTO, какие Use Cases, нужна ли миграция Alembic).
2. Phase 2 — Schema & Contracts: сначала создаются модели, интерфейсы репозиториев и сигнатуры методов со строгими тайпхинтами.
3. Phase 3 — Implementation & DI Wiring: реализация логики и обязательная регистрация новых классов в провайдерах DI-контейнера.
4. Phase 4 — Verification Gate: прогон линтеров, тайпчекера и интеграционных тестов до получения зелёного статуса.

Читайте также в инженерном блоге