Спроектируй среду для ИИ-агента в своём проекте

Навигация по видео

1. 00:00Почему код перестал быть главным узким местом▶
2. 09:00Демо и долгоживущий продукт▶
3. 14:06Ограничения агента: контекст, память и инструменты▶
4. 21:56Долг по проверке и новый процесс разработки▶
5. 26:35Что входит в harness▶
6. 32:10Контекст и поиск нужных знаний▶
7. 34:56Инструменты и MCP▶
8. 38:05Память между сессиями▶
9. 40:45Тесты продукта и оценка агента▶
10. 42:04Наблюдаемость и трассировка▶
11. 43:56Ограничения и подтверждение действий▶
12. 50:58Уровни зрелости проекта▶
13. 53:17Чем занимается ИИ-инженер▶
14. 59:30Итог: инженерная среда вокруг модели▶

Выбери главу: видео выше начнётся с нужного момента.

Сначала определи границу между демо и продуктом

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

Подготовка к работе с агентом

• Выбрана одна небольшая задача с наблюдаемым результатом.
• Записаны критерии приёмки и ограничения продукта, включая права доступа и обратную совместимость.
• Найдены актуальные файлы, документы и человек, который разрешит противоречия в требованиях.
• Определены команды проверки и действия, требующие согласования перед выполнением.

Дай агенту минимальный достаточный контекст

Начни со спецификации задачи и нескольких проверенных источников: нужных файлов, контрактов, правил и истории решений. Для поиска используй имена и символы, зависимости, историю Git или поиск по документам. Подключай семантический поиск и RAG, если простого поиска недостаточно. Не загружай весь проект в запрос: отметь источник каждого правила и отдельно выясни, какие данные устарели или противоречат друг другу.

Запрос для подготовки контекста

Задача: [одно изменение в проекте].
Критерий приёмки: [что можно проверить].
Сначала найди только файлы, правила и прежние решения, относящиеся к задаче. Для каждого укажи путь или источник и зачем он нужен. Отдельно перечисли недостающие и противоречивые требования; не додумывай их. Предложи план небольшими шагами и проверки для каждого шага. До изменения кода покажи план мне.

Раздели действия, протокол и память

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

Как принять результат агента

• Сравни diff со спецификацией: нет ли лишних файлов, потерянных требований и неподтверждённых предположений.
• Запусти тесты продукта и проверь один реальный пользовательский сценарий.
• Повтори короткий сценарий для самого агента: нашёл ли он нужный источник, вызвал ли допустимый инструмент и остановился ли вовремя.
• Сохрани след выполнения: использованный контекст, вызовы инструментов, ошибки и результаты проверок.
• Оставь агенту изолированную среду; миграции, удаление данных и выпуск в продакшн проводи после одобрения человеком.

Карта минимальной среды для своего проекта

Задача и критерий приёмки: 
Источники контекста и кто их подтвердил: 
Доступные инструменты и предел их прав: 
Нужен ли MCP, почему: 
Что сохранить между сессиями: 
Тест продукта и сценарий оценки агента: 
Что записать в трассировку: 
Какие действия требуют одобрения человека: 
Когда агент должен остановиться: 

Если проект растёт

Дальше развивай только тот слой, где возникла конкретная проблема. Разрозненные знания — повод улучшить поиск и проверить, нужен ли RAG. Потеря прогресса между сессиями — повод хранить решения и следующий шаг. Непонятные сбои — повод добавить трассировку. Много кода без уверенности в результате — повод расширить тесты и сценарии оценки. Уровни зрелости из ролика используй как ориентир для обсуждения команды, а не как обязательный план внедрения всех технологий.