Что проверить перед запуском агента, который сам берёт задачи
Представим небольшую команду разработки. В обсуждении ошибки сотрудник просит агента исправить расчёт, а позже коллега уточняет условия. Агент уже работает с кодом. Руководителю нужно понимать, какая просьба стала заданием, где видны затруднения и кто принимает изменение. Повод разобрать этот процесс — открытый прототип dsh-superagent команды DeepSeek. Он рассчитан на один репозиторий GitHub, принимает задания от разрешённых участников или по правилам команды и может возвращать результат в виде pull request — предложения изменить код. Авторы обозначают его как исследовательский код, который нужно проверять и адаптировать перед использованием. Для первого знакомства возьмите тестовый репозиторий с учебными данными. Выберите маленькую задачу с понятным результатом: например, исправить расчёт доставки для одного региона. До запуска запишите ожидаемое поведение. Так три проверки ниже дадут конкретный ответ о вашем процессе. Задайте один разрешённый способ постановки задачи. Например, ответственный оставляет явное поручение в обсуждении ошибки и указывает, что должно измениться. Обычные рассуждения коллег в той же ветке остаются контекстом. Если агент принимает задания по правилу, запишите условие этого правила так, чтобы его мог проверить другой человек. В тестовом репозитории сравните три ситуации: явное поручение от разрешённого участника, похожую фразу от участника без такого права и сообщение с недостающим условием. Для каждой заранее определите исход: начать работу, оставить сообщение без исполнения или запросить уточнение. Затем проверьте, какое задание действительно появилось и к какому исходному сообщению оно привязано. Отдельно добавьте уточнение после начала работы. Ответственный должен видеть, что именно изменилось в задаче и продолжает ли агент ту же работу. Иначе два человека могут получить разные представления о том, что сейчас исправляют. Подготовьте безопасную причину остановки в учебной среде: уберите нужный тестовый файл или задайте противоречивые требования. Посмотрите, сможет ли ответственный понять причину по состоянию задачи, не перечитывая весь разговор. В посте нашего канала «Кай · ИИ для бизнеса» разобрали, какие задачи выполняет прототип DeepSeek для одного репозитория. Этот пример пригодится, когда будете описывать границы своего пилота. https://t.me/kaiforbiz/118 Для передачи человеку полезно сохранить четыре вещи: исходное поручение, уже сделанные изменения, причину остановки и вопрос, на который нужен ответ. Назначьте сотрудника, который принимает такие задачи. Статус «ждёт человека» должен вести к понятному следующему действию. Проверьте и возобновление. После ответа сотрудника должна продолжиться нужная задача с учётом сохранённых изменений. Перед повторным запуском сверяйте, какие действия уже выполнены, есть ли ветка и открытый pull request. Это помогает избежать второй работы над тем же исправлением. В документации прототипа предусмотрены состояния ожидания ответа и проверки. Наличие таких состояний в описании полезно, но при пилоте важно увидеть их в собственной цепочке: от сообщения сотрудника до передачи результата на проверку. Для первого пилота выберите ручное принятие pull request. Назначьте проверяющего и критерии готовности до постановки задачи. Для примера с доставкой это могут быть правильная сумма для нужного региона, сохранение расчёта для остальных регионов и понятное описание изменения. Попросите приложить к результату перечень изменённых файлов, выполненные проверки и нерешённые вопросы. Проверяющий должен сопоставить исправление с исходным поручением и последними уточнениями. Если код менялся после одобрения, установите правило повторной проверки актуальной версии и закрепите его настройками репозитория. Обсудите заранее, что делать с частично выполненной задачей. Полезный итог иногда состоит из…
Источник: vc.ru — vc.ru/ai/3239963-proverka-pered-zapusk-agenta-dlya-avtomatizatsii-zadach
