Шаблон: работа с агентами и точки HITL
Проектное описание того, как агенты выполняют задачи в действующих процессах команды. Статусы и условия переходов берутся из task-workflow.md, ветки, MR и ревью — из git-workflow.md. Здесь на эти правила ссылаются, определяя запуск, полномочия, адресатов и ожидания агента.
Гайд · Пример · Все формы Подготовки.
1. Область и участники
- Проект, поток, версия/дата, владелец и подтвердившие: …
- Процесс задач и его версия: …; Git-процесс и его версия: …
- Агент/проект платформы и способ подключения инструкций: …
- Кто ставит и разрешает брать задачи, ведёт рабочий диалог и принимает результат: …
- На PoC / Пилоте эти функции выполняют: …
- ИИ-инженер и канал технической помощи: …
2. Как задача попадает в работу агента
Выбрать и настроить один или оба способа. Описание замысла или обсуждение идеи не является разрешением на реализацию.
| Способ | Что заполнить |
|---|---|
| Сообщение в чате | Разрешённый канал; кто может поручать; как сообщение однозначно указывает задачу и согласованный объём; пример «APP-42 можно брать в работу»; где сохраняется подтверждение приёма |
| Статус трекера | Фактический статус/ID, из которого агент берёт задачи; точная выборка (проект, исполнитель, метки и другие условия); кто переводит задачу; когда выполняется выборка; какой переход/запись подтверждает приём |
- Как до запуска проверяются готовность постановки и необходимые входы: …
- Где хранится связь задачи с делом/запуском агента и текущим исполнителем: …
- Как исключаются два параллельных запуска одной задачи при повторе сообщения, повторной выборке или использовании обоих способов: …
- Как обрабатываются пауза, отзыв разрешения, отмена и ошибка приёма: …
Если запрос содержит большой функционал без готовой постановки, сначала уточняются требования и выполняется декомпозиция по гайду требований. Отсутствие готовности не обходится запуском реализации из чата. Повторный запуск или смена канала не создают новую продуктовую задачу автоматически.
3. Выполнение в процессах task и Git
| Точка существующего процесса / ссылка на правило | Что делает агент | Кто принимает решение и где | Действие после решения / переход по исходному правилу |
|---|---|---|---|
| Допуск готовой задачи | … | … | … |
| Выполнение и подготовка MR | … | … | … |
| Готовность к ревью кода/тестов | … | … | … |
| Замечания и повторная проверка | … | … | … |
| Продуктовая приёмка | … | … | … |
| Merge, выпуск и завершение задачи | … | … | … |
| Передача человеку / отмена | … | … | … |
Указать полномочия агента на изменение статусов и операции Git ссылками на правила и доступы. Ошибка изменения статуса фиксируется, а не заменяется сообщением об успехе. Автор не выдаёт собственную сдачу за независимое одобрение.
Маршруты PoC и Пилота
Для PoC выбрать: ИИ-инженер проверяет MR перед командой / вместо её ревьюеров в обозначенной области … . Указать проверки, полномочия, подтверждения и оставшиеся решения клиента: … . ИИ-инженер подбирает калибровочные задачи с командой и ведёт выполнение с агентом.
Для Пилота указать продуктовых адресатов: кто ставит и запускает задачи, отвечает на вопросы, выполняет ревью и приёмку … . MR направляются непосредственно назначенным разработчикам и тестировщикам; техническая помощь ИИ-инженера не становится обязательным промежуточным ревью. Передача инженерного сопровождения между специалистами не меняет продуктовых адресатов автоматически. Обновить инструкции и уведомления: … .
Асинхронный контроль HOTL
Для каждой применимой работы указать режим HITL / HOTL / без плановой ручной проверки: … . При HOTL определить, какой переход не ждёт проверки, кто, в каком объёме и ритме смотрит результат, где сохраняет находку, кто исправляет и при каких событиях возвращается блокирующий контроль: … . Находка направляется через чат с событием, задачей и ревизией. Плановые точки HITL ниже остаются только там, где человек действительно блокирует переход.
4. Точки HITL
HITL (human-in-the-loop) — участие человека, необходимое для продолжения работы. Точки HITL делятся на две группы.
Любой запрос HITL система направляет через чат с указанием наступившего события: например, «создан MR», «MR готов к ревью», «требуется решение по требованиям». Сообщение связывается с задачей и соответствующим материалом — MR, вопросом или результатом проверки. Участники и правила принятия решений определяются процессами команды и применимыми навыками.
Из процессов задач и Git
Эти точки следуют из процесса задач и Git-процесса. Указать применимые переходы и предусмотренные ими обращения к человеку.
| Повод / триггер | Что агент направляет человеку |
|---|---|
| MR готов к предусмотренному процессом ревью кода или тестов | Ссылка на MR и ревизию, результаты проверок и сообщение о готовности к ревью |
| Результат готов к продуктовой приёмке | Ссылка на задачу и предъявленный результат, подтверждения проверок |
| Наступил шаг согласования интеграции или выпуска, если он предусмотрен процессом | Ссылка на изменения и подтверждения готовности к этому шагу |
| Изменение объёма или прекращение работы требует решения по процессу задачи | Выявленное изменение и ссылка на задачу для принятия решения |
По навыкам агента
Эти запросы агент формирует по ходу выполнения на основании своих навыков и выявленных обстоятельств.
| Повод / триггер | Что агент направляет человеку |
|---|---|
| Неопределённое или противоречивое требование | Выявленное расхождение, ссылки на основания и вопрос для решения |
| Нужен выбор за пределами заданных правил | Существенный выбор, варианты и рекомендация агента |
| Нет прогресса или достигнут предел доработок | Результаты попыток, оставшаяся проблема и предложение дальнейшего действия |
| Нет доступа, неисправен инструмент или среда | Обнаруженная проблема и сведения, необходимые для помощи |
Ответ или результат действия сохраняется в принятом процессом источнике и связывается с задачей; чатовый запрос связывается с этим подтверждением. Молчание, автоматическое подтверждение и «посмотрю позже» не разрешают зависимое действие. Напоминание не создаёт новый запрос и не обнуляет ожидание. Противоречащие ответы направляются назначенному владельцу решения.
5. Возобновление, границы итерации и передача
- Кто проверяет, что ответ получен от уполномоченного человека и относится к актуальной постановке: …
- Как фиксируются решение, изменение постановки и действие агента после ответа: …
- Предел циклов, признаки раннего разбора, ответственный: ссылка на регламент доработок …; правила не копировать.
- Как оформляется новый объём отдельно от исправления исходного результата: …
- Порядок передачи: принимающий, контекст, состояние веток/MR, выполненное и остаток, подтверждение принятия: …
- Как агент получает подтверждённое решение об отмене по процессу задач и прекращает зависимые запуски: …
- Как сверяются расхождения статусов трекера, оркестратора и Git; кто разбирает ошибку обновления: …
Для повторно полученных событий указать способ не повторять уже выполненное действие: … . Ошибка изменения статуса фиксируется, а не заменяется ложным сообщением об успехе.
6. Подключение и проверка
- Версия инструкции и способ её загрузки агентом: …
- Подтверждение участников маршрута: …
- Результаты проверки выбранных способов запуска, HITL и переходов: ссылки на FLOW-09/10 журнала PoC … .
При смене маршрута, статусов или правил Git обновить ссылки и проверить затронутый путь по гайду процессов. Подробный регламент доработок остаётся в своём документе; эта форма задаёт его место в работе агента.