Почему долгая работа агента нас успокаивает

Зачастую то, что агент долго работает, перебирает файлы и использует инструменты, даёт нам внутреннее успокоение: кажется, что он всё делает правильно, ведь задачу он получил и точно понимает, что ему нужно делать.

Но сама активность агента ещё не подтверждает, что он движется к нужному результату. Если он неверно понял задачу в самом начале, то может очень последовательно развивать эту ошибку, добавляя к ней новые решения, файлы и потраченные токены.

Чем позже мы заметим расхождение, тем больше придётся разбирать и переделывать. Поэтому длинный автономный запуск без промежуточной проверки для меня сейчас выглядит не как экономия времени, а как риск дать небольшой ошибке спокойно вырасти в готовый неправильный результат.

Почему подробного описания всё равно недостаточно

Допустим, я прошу агента добавить новый раздел в личный кабинет. У меня в голове уже есть весь путь пользователя: откуда он туда приходит, что должен увидеть, какие действия доступны и куда ведёт кнопка назад. В задаче я могу подробно описать назначение раздела и основные элементы, но забыть про права доступа, пустое состояние или поведение при ошибке — просто потому, что для меня эти детали кажутся очевидными.

Агенту всё равно придётся принять решения по каждому пропущенному месту. По отдельности они могут выглядеть логично и даже соответствовать коду проекта, но вместе дадут совсем не тот пользовательский путь, который я представлял.

Поэтому хорошая постановка задачи для меня сейчас определяется не количеством текста. Важно, чтобы перед началом работы агент изучил проект, сопоставил задачу с уже принятыми решениями и сам спросил о том, чего ему не хватает. Тогда мне не нужно заранее угадывать все возможные вопросы — их находит тот, кому по этой информации предстоит выполнять задачу.

Как я сейчас готовлю задачу к запуску

Сейчас я начинаю достаточно свободно: базово описываю задачу, рассказываю, что хочу увидеть, какие нюансы уже заметил и какие примеры считаю важными. Я не пытаюсь вручную собрать идеальный бриф, заранее найти весь контекст и угадать каждый вопрос, который может появиться у агента.

Дальше подключаются скиллы — сохранённые процедуры, которые я разработал под собственный процесс. Сначала агент изучает кодовую базу, документацию и принятые решения, а затем начинает задавать по одному вопросу. Мне остаётся принимать решения там, где их действительно нельзя получить из проекта.

При этом отдельный скилл решает только локальную задачу. Он может объяснить агенту, как провести исследование или проверить код, но не заменит единую систему разработки: откуда появилась задача, где лежат принятые решения, когда нужно подключить человека и что вообще считается готовым результатом. Без этой связи даже хороший скилл остаётся ещё одним изолированным промптом.

Что связывает скиллы в одну систему

В моей системе эта схема работает внутри Hermes Agent, но самих скиллов для неё недостаточно. Решения о компании, продуктах и проектах хранятся в отдельных связанных материалах. Каждая задача ссылается на нужный проект и документацию, которые агент обязан прочитать до того, как начнёт задавать вопросы.

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

Скилл задаёт порядок отдельного этапа, а связанная база знаний даёт ему контекст для решений.

Чем заканчивается разбор задачи

У этого этапа есть конкретный финал. Перед реализацией должна появиться карта решений, по которой агент сможет выполнить задачу без необходимости додумывать продукт за меня. Она не обязана быть огромным техническим заданием, но в ней должны быть зафиксированы:

  • что именно мы делаем и для кого;
  • какой результат должен остаться после работы;
  • какие решения уже приняты и их нельзя менять;
  • что агент может решить самостоятельно;
  • какие состояния, ограничения и крайние случаи нужно учесть;
  • как будет проверяться готовый результат;
  • в каких ситуациях нужно остановиться и позвать человека.

После разбора агент показывает мне карту решений. Я либо подтверждаю её, либо возвращаю с одним конкретным решением. Пока карта не подтверждена, задача не уходит в реализацию.

Что происходит после разбора

Когда карта решений согласована, отдельный скилл создаёт Issue — зафиксированную задачу в проекте — и превращает большую работу в несколько маленьких частей. Для каждой части он записывает границы, зависимости, порядок выполнения и способ проверки. Контекст после этого остаётся не только в истории переписки: следующий агент открывает конкретную Issue и связанные с ней материалы.

Это мой маршрут именно для разработки. Каждая часть выполняется в своей ветке или worktree — отдельной рабочей копии проекта. Скилл разработки сначала сверяет Issue с реальным состоянием проекта, затем меняет только нужную часть и запускает предусмотренные проверки. Изменения одной задачи остаются в своей рабочей копии и не смешиваются с остальными.

Когда работа готова, включается скилл завершения. Он проверяет условия Issue, синхронизирует ветку с актуальной версией проекта, повторно запускает нужные проверки и только после этого сливает изменения. Следующая часть начинается уже от проверенного состояния проекта.

В исследовании, работе с документами или операционном процессе Git не обязателен. Вместо ветки остаётся отдельная задача и своя версия итогового артефакта, но граница работы, проверка результата и точка решения человека сохраняются.

Агент должен уметь остановиться сам

После запуска я не хочу следить за каждым действием агента, проверять каждый прочитанный файл и подтверждать каждую команду. Поэтому условия остановки задаются заранее. Агент должен остановиться, если:

  • источники или принятые решения противоречат друг другу;
  • для продолжения не хватает обязательного доступа;
  • одна и та же проверка повторно падает по одной причине;
  • требуется продуктовое решение, которого нет в карте;
  • следующий шаг затрагивает production, деньги или данные пользователей;
  • достигнут лимит времени, шагов или стоимости.

В OpenAI Agents SDK параметр max_turns ограничивает только число циклов агента: после превышения run завершается ошибкой MaxTurnsExceeded. Это не лимит токенов, денег или времени. Такие бюджеты нужно задавать отдельно в используемом runtime или во внешнем процессе, если он это поддерживает.

После остановки агент должен вернуть не очередной длинный отчёт, а текущее состояние: что уже сделано и проверено, где возник блокер и какое одно решение требуется от человека.

Как этот принцип работает в AI-юристе

В кейсе kAIros с AI-юристом задача системы не звучит как «изучи документы и помоги юристу». У неё есть конкретный рабочий контур: получить договор, приложения и связанную переписку, найти спорные условия и собрать проект протокола разногласий.

На входе заранее понятен набор документов, на выходе — проект протокола и обновлённая версия договора. Система может самостоятельно разбирать материалы и готовить изменения, но финальные риски и формулировки проверяет юрист.

Если у вас есть процесс, в котором агент долго работает, а результат всё равно приходится разбирать и переделывать вручную, принесите на разбор одну такую задачу. Сначала определим для неё результат, проверку и условия остановки, а уже потом решим, что можно передать агенту.

Источники