Гайд: онбординг агентов в проект
Онбординг — первая неделя PoC. ИИ-инженер адаптирует исходные инструкции агентов к продукту и процессам клиента, подключает агентов и навыки и проверяет минимальный рабочий путь. На PoC работу ведёт ИИ-инженер сопровождения; ИИ-инженер клиента участвует и осваивает настройку. Это онбординг платформы в проект, а не проверка самостоятельности клиента.
План PoC: неделя 1 — онбординг; неделя 2 — простые задачи; недели 3–4 — целевые задачи будущего Пилота.
1. Предусловия
Предусловия проверяются для выбранной схемы первой работы: допустимы облачная платформа, копия исходников и временные Git, трекер и среды. До онбординга должны быть разрешены развилки, от которых зависит этот путь; решения о следующих периодах могут оставаться открытыми с ответственными и сроками. Техническая проверка временной системы не подтверждает подключение её целевого аналога.
До старта PoC заполняется чек-лист готовности. Для онбординга нужны:
| Условие | Проверяемое подтверждение |
|---|---|
| Платформа развёрнута и функционирует либо выделен проект в облаке поставщика | Адрес проекта, ответственный за платформу и успешный проверочный запуск агента с доступом к журналу выполнения |
| Подготовлено рабочее место ИИ-инженера | Локальный агент подключён к нужному проекту на платформе либо доступно рабочее место ИИ-инженера на платформе; проверены вход, чтение литературы и разрешённые операции её изменения |
| Обеспечены связности и доступы инженера | Проверены его аккаунты, сеть и нужные операции из выбранного рабочего места: каталог исходных материалов, Git внедрения, литература проекта, трекер и средства диагностики |
| Настроены интеграции платформы | Из рабочего контура платформы проверены доступы к чату, трекеру, репозиториям, CI, хранилищу артефактов и DEV; указаны аккаунты и права. Доступ инженера не подтверждает доступ платформы |
| Подключены обязательные модели | Проверены основная text-to-text и зрение, допустима одна модель. Решения по лёгкой модели и TTS/STT заполнены в реестре |
| Собраны исходные материалы | Доступны описание продукта, кодовой базы и процессов, правила HITL и Git, инфраструктура, данные и известные ограничения. Пробелы перечислены, назначены эксперты для ответов |
| Определены источники и место результата | Указаны каталог исходных материалов дистрибутивной методологии, Git материалов внедрения, репозиторий литературы проекта, базовая ветка, правила MR и способ подключения литературы к платформе |
| Подготовлена задача минимального прохода | Однозначная небольшая правка, критерии результата, исходная ветка, выделенная DEV и способ проверки. Есть права на создание feature-ветки и MR, сборку, публикацию и деплой |
| Назначены участники проверки | Имена ИИ-инженера сопровождения, ИИ-инженера клиента и экспертов по продукту, коду и процессам; время ответов и проверок на неделе онбординга |
Платформа и подключения проверяются до предметной адаптации. Готовые проектные агенты и навыки не являются предусловием: их начальный комплект — результат онбординга. Если литература клиента уже есть, она используется и дорабатывается.
Формы адресов, версий, доступов и результатов собраны в шаблоне онбординга. Ключи и пароли в материалы и промпты не включаются.
2. Первичный онбординг
К этому моменту репозиторий внедрения содержит заполненные материалы Подготовки, версию исходной методологии и принятые проектные уточнения. Их использовать вместе с каталог исходных материалов. Процедура адаптации методологии определяет правила проекта, а шаги ниже превращают их в работающих агентов и навыки.
Инженер подключается к платформе своим локальным агентом либо работает через рабочее место ИИ-инженера на платформе. Оба способа используют одни источники и сохраняют результат в литературу проекта; локальная история диалога не должна оставаться единственным местом хранения правил.
- Выбрать материалы для адаптации. Открыть каталог исходных материалов и материалы внедрения, записать ссылки и версии. Hub содержит промпты демо-проектов, универсальные навыки, в том числе чтения PDF/DOCX, и другие дистрибутивные материалы. Выбрать подходящие основы с учётом продукта и инструментов клиента.
- Запустить адаптацию. Передать агенту промпт ниже с реальными ссылками. Агент изучает материалы, выявляет отличия проекта и задаёт вопросы по всем развилкам. Решения принимают назначенные владельцы соответствующих областей.
- Сохранить журнал онбординга. Агент ведёт в Git внедрения журнал в свободной форме: использованные материалы, вопросы и ответы, решения и их источники, открытые вопросы, изменения литературы и результаты проверок. Дополняет его по ходу работы; подтверждённые решения учитывает в литературе проекта. Описание журнала · Шаблон журнала.
- Сформировать начальный MR в литературу проекта. Адаптировать агентов, промпты, навыки и заметки: продуктовый контекст, процесс задач, Git/MR, маршрут агента и HITL, проектные команды, проверки, деплой и диагностику. Удалить или заменить настройки и правила, относящиеся только к демо-проекту.
- Проверить и подключить версию. Инженер и профильные участники проверяют изменения в своих областях. По процессу проекта подключить проверенную ревизию литературы к тестовому запуску агента. MR с файлами без подтверждения, что агент использует эту версию, не означает готовности.
Промпт первичной адаптации
Посмотри дистрибутивную литературу агента: [ссылка на каталог исходных материалов], и материалы внедрения: [ссылка на Git внедрения].
Адаптируй материалы каталог исходных материалов к проекту и сформируй начальный MR в литературу проекта: [ссылка на репозиторий и базовую ветку].
В процессе анализа задавай вопросы по всем развилкам, чтобы сразу получить качественных агентов и навыки. Для каждого вопроса укажи, что нужно решить, какие варианты видишь и на что повлияет ответ. Не выбирай за команду правила продукта, процесса, прав и инфраструктуры, если они не определены в материалах.
Используй промпты демо-проектов как основу для адаптации, а универсальные навыки — по применимости. Сохрани подтверждённые правила клиента. Перенеси ответы и решения из диалога в проектные материалы.
Создай в Git внедрения журнал онбординга по описанию и шаблону. Веди его в свободной форме по ходу диалога, изменений и проверок; сохраняй ссылки на источники и следующие шаги.
В MR опиши состав агентов и навыков, источники и версии, принятые решения, открытые вопросы и способ подключения литературы. Подготовь инструкции для минимального прохода: сообщение в чате → чтение задачи → решение в feature-ветке → проверки → сборка и публикация артефакта → деплой на DEV → MR и отчёт со ссылками.
3. Проверка агентов и работа с промптами
Из локального агента или рабочего места ИИ-инженера на платформе выполнить пробные вызовы, проверить маршрутизацию задания, доступность навыков и применение проектных правил. Изменения промптов сохранять в MR литературы с причиной и результатом повторной проверки.
Затем запустить новую задачу сообщением в подключённом чате, чтобы проверить рабочий вход в платформу. Проверка только из локального агента не заменяет этот проход.
- В сообщении указать ссылку на подготовленную задачу и поручить выполнить её до MR и деплоя на выделенную DEV.
- Наблюдать по журналам, какие агенты и навыки использованы, какую постановку агент прочитал и какие действия выполнил.
- При ошибке исправить её причину: интеграцию, настройку, промпт, навык или исходное правило. Сохранить изменение и повторить затронутую проверку.
- В завершение получить успешный сквозной проход на зафиксированной версии литературы. Ручной обход сломанного шага не считается доказательством способности агента выполнить этот шаг.
Инженер помогает в настройке и диагностике; это штатная часть онбординга. Для итогового прохода изменение кода, сборку, деплой и создание MR выполняет агент через настроенные средства, а не человек вместо него.
4. Минимум для завершения онбординга
Минимум фиксируется как подмножество каталога умений PoC. Для каждого умения подтверждаются техническое выполнение и качество содержания/результата.
| Шаг | Умения журнала | Подтверждение |
|---|---|---|
| Получить поручение из чата и прочитать задачу | COM-11, COM-01 | Ссылка на сообщение, запуск и прочитанную постановку; агент верно определил задачу и требуемый результат |
| Использовать литературу проекта | FLOW-07 | Версия литературы и следы применения нужных агентов, навыков и правил в новой задаче |
| Выполнить небольшое изменение в feature-ветке | DEV-01, DEV-02 | Корректная база ветки, diff и сборка; изменение соответствует задаче и известным правилам проекта |
| Проверить результат | QA-07, QA-11 | Smoke и необходимые проверки затронутого поведения; отчёт с ожидаемым/фактическим результатом и ограничениями. Готовый набор автотестов не обязателен |
| Выполнить деплой на DEV | DEV-06 | SHA → сборка → неизменяемый ID артефакта в хранилище → деплой на выделенный стенд; фактическая версия и проверка готовности |
| Создать MR и сообщить результат | COM-04, COM-11 | MR кода с правильной целевой веткой, связью с задачей и доказательствами; ответ в чате со ссылками на MR, стенд и проверки |
Итоговый кейс FLOW-11 связывает все эти шаги в один проход. MR литературы и MR кода пробной задачи — два разных результата; в журнале указываются оба.
Обработка замечаний в задачах и MR, спорные поручения, расширенные HITL-сценарии, приёмка и merge не входят в минимум недели 1. Их проверяют на простых и целевых задачах недель 2–4. Предварительные вопросы при адаптации литературы остаются частью онбординга; это не тестирование циклов замечаний к продуктовой задаче.
Если отдельный каталоговый кейс содержит дополнительные условия, они проверяются по его правилам применимости. Например, специальные проверки служебных деплойных веток нужны только при использовании такой схемы. Успех минимума не означает, что весь каталог PoC пройден.
5. Результат недели
Параллельно онбордингу ИИ-инженер создаёт агента внедрения, который помогает собирать показатели, вести журналы и готовить материалы по ходу внедрения. Версию агента и результат первого запуска сохраняют в журнале PoC; проверку расчётов и сводок продолжают на следующих неделях. Это отдельная работа первой недели: минимальный путь онбординга продукта по FLOW-11 сохраняет свой состав.
Онбординг завершён, когда подключена зафиксированная версия проектной литературы и минимальный проход подтверждён по обеим осям. В журнале PoC сохраняются:
- MR литературы, исходные версии каталог исходных материалов и материалов внедрения, подключённая ревизия и результаты проверки агентов/навыков;
- сообщение в чате, задача, feature-ветка и MR кода, артефакт, запись деплоя и доказательства проверок;
- результаты минимального набора и FLOW-11, проверившие и дата;
- открытые вопросы вне минимального пути и действия на неделю 2.
Открытый вопрос, мешающий минимальному проходу, не считается завершённым онбордингом. При нехватке времени РП обновляют план и фиксируют причину; календарное окончание первой недели не заменяет результат.