Почему агент каждый раз делает по-новому
Повторяемость агентной задачи зависит от того, сколько плана вынесено из модели в сохранённую структуру. Когда модель при каждом запуске заново решает, какие шаги предпринять, результат плавает: меняется порядок вызовов инструментов, формат отчёта и расход токенов. Когда план лежит в графе шагов или в коде, модель либо вызывается один раз, либо не вызывается вообще, и повтор становится предсказуемым.
Причина в устройстве агентного цикла. Модель получает контекст, выбирает инструмент, получает результат вызова, и всё это добавляется в контекст следующего шага. Входной контекст растёт с каждым шагом, а модель вызывается последовательно. На повторном запуске агент снова планирует шаги и тратит на это токены, а отчёт приходит в другом формате. Пример из разбора про повторный запуск агентных задач: сотрудник отдела закупок просит агента сверить новый прайс-лист поставщика с рыночными ценами и собрать отчёт по позициям, где отклонение выше порога. Агент проходит десяток шагов: читает Excel, ищет рыночные цены, считает отклонения, пишет выводы. При следующем запуске план может оказаться другим, даже если файл не изменился.
Стоимость такого повтора считается условно, но наглядно. Системный промпт с описаниями инструментов занимает 8 000 токенов, каждый шаг добавляет в контекст 1 500 токенов, а шагов десять. Итоговый вход на один прогон складывается примерно в 23 000 токенов, и этот объём уходит заново при каждом повторе. Если задача запускается каждое утро на неизменном файле, вы платите за одно и то же планирование десятки раз. Куда именно утекает контекст в агентах и что даёт prompt cache, разобрано в материале про оплату контекста, а не мышления модели.
Проблема не в модели и не в её способности рассуждать, а в том, что план нигде не фиксируется.
Четыре уровня фиксации: что именно сохраняется после успешного прогона
В разборе выделены четыре способа, которыми агентные системы решают задачу повторного запуска: сохранённый промпт (ChatGPT Scheduled Tasks, задачи по расписанию в Claude Cowork), скиллы (Agent Skills), граф шагов (n8n, Copilot Studio, сценарии в Айве) и код с кэшем действий (Stagehand). Различаются они тем, что система сохраняет после успешного прогона: текст запроса, инструкцию, граф шагов или программу (источник по подходам).
Работает общий принцип: чем большая часть плана вынесена из модели, тем меньше токенов уходит на повторный запуск и тем ближе его результат к предыдущему. Платить приходится устойчивостью к изменениям во входных данных. Зафиксированный план рассчитан на тот вход, под который его составили.
| Уровень | Что сохраняется | Что делает модель при повторе | Вызовов модели на запуск |
|---|---|---|---|
| Сохранённый промпт | Текст запроса и условие запуска | Планирует заново | Столько же, сколько в исходном прогоне |
| Скилл (Agent Skills) | Инструкция: шаги и инструменты | Выбирает шаги внутри инструкции | Примерно как в инструкции, без отдельного планирования |
| Граф шагов | Последовательность узлов | Работает в одном узле анализа | Один |
| Код с кэшем действий | Программа и кэш результатов вызовов | Не участвует, если действия закэшированы | Ноль или минимум |
Столбцы про роль модели и число вызовов для промпта и скилла выведены из общего принципа, а не из замеров: в исходном разборе таких измерений нет. Сравнение по ним стоит воспринимать как ориентир для выбора, а не как точные числа.
Предварительная матрица выбора: редкие и разные задачи - промпт или скилл, регулярный процесс со стабильным входом - граф, массовые повторы на строгом формате - код и кэш. Ниже разберём каждый уровень отдельно: что сохраняется, что делает модель при повторе и какие ограничения идут в комплекте с предсказуемостью.
Отдельная оговорка по поведению при сбоях и изменениях входа. Подробных данных о том, как каждый из четырёх подходов ведёт себя при изменении входных данных или сбое посередине, в разборе нет, кроме общего вывода о падении устойчивости к изменениям входа. Пункты такого рода ниже помечены как следствия из того, что именно сохраняется, без результатов замеров.
Сохранённый промпт: минимум усилий, максимум нестабильности
Уровень 1: система хранит текст запроса и условие запуска. По расписанию или событию она открывает новую сессию и заново проходит весь путь. Примеры из разбора: ChatGPT Scheduled Tasks и задачи по расписанию в Claude Cowork.
- Что сохраняется: только текст запроса и триггер запуска.
- Кто планирует при повторе: модель, с нуля.
- Сколько вызовов модели: столько же, сколько в исходном прогоне.
- Поведение при изменении входа: агент адаптируется к новым данным, но результат может отличаться сильнее, чем ожидалось (следствие из принципа, не измерение).
- Поведение при сбое: промежуточного состояния нет, скорее всего придётся начинать заново (следствие из принципа, не измерение).
Плюсы: запускается за пять минут, поддерживать нечего, гибкость максимальная. Минусы: формат отчёта не гарантирован, расход токенов на каждом запуске полный, повторяемость не обеспечена. Подходит для редких задач, где важна адаптивность, а не строгий формат: разобрать письмо, подготовить черновик, собрать сводку по свежим данным.
Скиллы (Agent Skills): инструкция вместо импровизации
Уровень 2: Agent Skills. Вместо голого текста запроса сохраняется инструкция: как выполнять задачу, какие шаги проходить, какие инструменты использовать и что считается готовым результатом.
- Что сохраняется: инструкция.
- Кто планирует при повторе: модель, но в границах инструкции. Свободное планирование сокращается, вариативность падает (следствие из принципа, не измерение).
- Сколько вызовов модели: обычно столько, сколько шагов описано в инструкции, без отдельного этапа планирования.
- Поведение при изменении входа: если новый случай не описан, инструкцию придётся дополнять (следствие из принципа, не измерение).
- Поведение при сбое: зависит от того, как скилл оформлен; часто можно перезапустить с того же места.
Что это даёт на практике: формат результата стабилизируется, потому что шаги и требования к выводу зафиксированы текстом. Гибкость остаётся, ведь инструкция описывает процесс, а не конкретные данные. Цена: инструкцию нужно поддерживать и обновлять, недетерминизм модели никуда не уходит, а расхождения в деталях сохраняются. Подходит для задач, которые повторяются, но каждый раз с нюансами.
Граф шагов: жёсткая последовательность и экономия токенов
Уровень 3: граф шагов. Процесс сохраняется как последовательность узлов, где каждый узел выполняет конкретное действие: прочитать файл, вызвать API, посчитать, отправить письмо. Примеры: n8n, Copilot Studio, сценарии в Айве.
Ключевое следствие по расходу: если тот же процесс зафиксирован графом, модель вызывается один раз, в узле анализа, и получает уже собранные данные. По расчёту из разбора с цифрами по графу, при входе в 6 000 токенов разница по объёму входа получается примерно в 25 раз, а 10 последовательных вызовов модели превращаются в один.
- Что сохраняется: граф шагов.
- Кто планирует при повторе: никто, план уже зафиксирован.
- Сколько вызовов модели: один.
- Поведение при изменении входа: граф рассчитан на тот вход, под который его составили; при смене схемы файла или источника данных часть узлов придётся перестраивать (следствие из принципа, не измерение).
- Поведение при сбое: можно перезапустить с упавшего узла, если ведётся журнал шагов.
Плюсы: предсказуемая последовательность, экономия на входном контексте, стабильный формат результата, отладка по узлам. Минусы: устойчивость к изменениям входа низкая, граф надо поддерживать, а логика ветвлений быстро усложняется. Подходит для регулярных процессов со стабильным входом: ежедневная сверка прайса, выгрузка отчёта, обработка однотипных заявок.
Рядом с графом стоит тема кэша префикса, и здесь важно не перепутать эффекты. Кэширование префикса снижает цену повторяющейся части контекста: облачные провайдеры тарифицируют кэшированные токены дешевле, а в vLLM Automatic Prefix Caching переиспользуется KV-кэш общего префикса и пропускается его повторное вычисление. Ограничение принципиальное: число последовательных вызовов и задержка при этом остаются прежними. То есть кэш сокращает счёт за токены, но не превращает десятишаговый цикл в один вызов. Именно поэтому граф и код дают более сильный эффект по повторяемости, чем один только кэш.
Код с кэшем действий: максимальная повторяемость для массовых задач
Уровень 4: код с кэшем действий (Stagehand). После успешного прогона сохраняется программа, которая выполняет задачу, и кэш действий, то есть результаты уже полученных вызовов инструментов.
- Что сохраняется: программа плюс кэш действий.
- Кто планирует при повторе: никто, выполняется код.
- Сколько вызовов модели: может быть ноль, если все действия закэшированы, или минимум на обработку новых данных.
- Поведение при изменении входа: код может упасть, если вход не соответствует ожиданиям; нужна проверка схемы и обработка исключений (следствие из принципа, не измерение).
- Поведение при сбое: перезапуск с последнего успешного шага при наличии журнала.
Плюсы: повторяемость максимальная, формат жёсткий, затраты на массовых повторах минимальны. Минусы: разработка и поддержка дороже, адаптивность почти нулевая, а нестандартный вход ломает прогон. Подходит для массовых повторов на строгом формате: разобрать 5 000 однотипных документов, выгрузить данные по фиксированной схеме, обновить статусы по заранее известным правилам.
Недетерминизм инференса: почему температура 0 не гарантирует одинаковость
Температура 0 убирает случайный выбор токена: на каждом шаге берётся самый вероятный. Полной одинаковости это не даёт. В исходном разборе тема не раскрыта, поэтому ниже перечислены типичные источники расхождений, которые стоит проверить в своей конфигурации. Это гипотезы для диагностики, а не результаты замеров.
- Порядок операций с плавающей точкой зависит от размера батча и выбранных ядер GPU, поэтому одинаковый запрос при разной загрузке сервера может дать слегка разные логиты.
- Провайдер может обновить версию модели или стек обслуживания, и поведение изменится без правок в вашем промпте. Стоит проверить, привязан ли рабочий процесс к конкретной версии модели.
- Различия в самом контексте: подставленная дата, порядок найденных документов, случайная выборка из RAG.
Что снижает разброс, если модель всё же остаётся в контуре:
- Structured outputs. Ответ жёстко ограничивается схемой. Формат перестаёт быть предметом творчества модели, а несоответствие схеме отсекается автоматически.
- Фиксация версии модели. Обновления прилетают неожиданно, поэтому версию для рабочего процесса стоит закрепить, а новый вариант отдельно прогонять на наборе своих примеров.
- Расчёты в коде. Арифметику, сравнение с порогом, сортировку и агрегацию лучше держать в коде. В примере с прайс-листом отклонения считает код, а модель формулирует выводы по готовым цифрам.
Комбинация этих приёмов даёт приемлемую стабильность, но не абсолютную гарантию. Если нужна именно повторяемость, план и вычисления выносятся из модели в граф или код, а модель остаётся там, где без неё не обойтись.
Защита от повторных побочных эффектов: идемпотентность и журнал шагов
Есть риск хуже нестабильного формата: агент может повторно отправить письмо, создать запись, выполнить платёж или изменить карточку в CRM. В кейсе с n8n и HubSpot агент формально не имел прав на изменение данных, но downstream-узел всё равно выполнил PATCH и изменил LAB-043 вместо LAB-042. Разбор этого случая и роль детерминированного gateway на границе исполнения собраны в материале про runtime-контроль на n8n, DeepSeek и HubSpot. Механизмы защиты в исходном разборе не описаны, поэтому ниже инженерные приёмы общего характера.
- Идемпотентные ключи. Операция помечается уникальным идентификатором, например ID отчёта плюс период. Повторный запрос с тем же ключом не создаёт второй объект: система возвращает результат первой операции. Нужно там, где API не распознаёт дубли сам.
- Журнал шагов агента. Каждый шаг записывается с входом, выходом и статусом. При сбое видно, где процесс остановился, и работа продолжается с последнего успешного шага вместо полного повтора.
- Durable execution. Состояние выполнения хранится вне процесса, поэтому падение воркера не убивает задачу: она продолжается с последней контрольной точки.
- Разделение ролей. Детерминированный исполнитель применяет только те действия, которые прошли проверку, а модель предлагает. Так устроена методология Agent-Ops 0.4.0: агент предлагает, человек утверждает, программа исполняет, и работает принцип unknown ≠ OK (восемь шагов процесса и роль Guardian).
Закладывать эти механизмы нужно до запуска в продакшн: добавить идемпотентность к потоку, который уже успел наделать дублей, заметно дороже.
Как выбрать подход под ваш процесс
Выбор определяется тремя вопросами: как часто задача повторяется, насколько стабилен вход и насколько строг формат результата.
| Ситуация | Что сохранять | Где остаются риски |
|---|---|---|
| Задача редкая, вход каждый раз новый | Сохранённый промпт | Формат и расход токенов не гарантированы |
| Задача повторяется, детали меняются | Скилл (Agent Skills) | Инструкция не покрывает новый случай, нужна доработка |
| Регулярный процесс со стабильным входом | Граф шагов | Смена схемы входа ломает узлы, граф надо поддерживать |
| Массовые повторы на строгом формате | Код с кэшем действий | Дороже в разработке, плохо переносит нестандартный вход |
Промежуточные случаи решаются комбинацией. Если процесс повторяется, но вход иногда меняется, берите граф с узлом валидации и обработкой исключений, а нестабильный участок оставляйте модели. Если формат критичен, но данные разнородны, кэшируйте в коде только дорогие вызовы, а анализ отдавайте модели через structured outputs.
Чек-лист перед выбором:
- Как часто задача запускается: раз в месяц или каждую ночь?
- Насколько стабилен вход: фиксированная схема файла или свободный текст от людей?
- Насколько строг формат результата и что будет, если он поедет?
- Есть ли побочные эффекты, которые нельзя выполнить дважды?
- Кто будет поддерживать граф или код, когда изменится источник данных?
- Готова ли команда разбирать сбои и смотреть, как проходят прогоны?
Одно практическое предупреждение: код с кэшем стоит брать последним. Пока задача не устоялась, требования меняются каждую неделю, и поддержка программы обойдётся дороже экономии токенов. Обычный путь выглядит так: промпт, затем скилл, затем граф, и только потом код для самых массовых и самых скучных повторов. Как выстраивать спецификации, evaluations и память агента, чтобы проект не утонул в объёме, разобрано в материале о том, почему разработка с ИИ-агентами стала тяжелее.