TL;DR
Когда просишь модель решить сложную многошаговую задачу, она часто "застревает" на ошибке в середине и везёт её до конца. Исследователи изучили 326 провалов лучших AI-агентов на сложных научных задачах и нашли три системных слабости: план разваливается при первой же неудаче (46% ошибок), решения из предыдущих шагов не переносятся дальше (23%), никто не проверяет промежуточные результаты (31%). Даже сильнейший агент — Gemini Deep Research — справился лишь с третью задач.
DelveAgent — это фреймворк из трёх модулей, который напрямую закрывает каждую слабость. Адаптивный цикл планирования перестраивает план после каждого промежуточного результата, а не держится за исходный любой ценой. Двухуровневая память ведёт два журнала одновременно: что сработало (паттерны решений) и что нужно помнить (факты, ограничения, формулы). Иерархическая проверка работает на двух уровнях — детальная проверка каждого шага и глобальная проверка всего ответа в конце.
Принципы фреймворка — три отдельных промпт-слоя, которые можно дословно внедрить в обычный диалог с LLM. Метод работает за один длинный промпт или через серию запросов с явными фазами проверки.
Схема метода
(Один расширенный промпт ИЛИ три последовательных запроса)
ФАЗА 1 — Планирование (начало диалога)
→ Детальный пошаговый план с критериями проверки каждого шага
→ Фиксация ключевых фактов и ограничений задачи
ФАЗА 2 — Выполнение (цикл на каждый шаг)
→ Выполнить шаг
→ Локальная проверка: корректны ли детали этого шага?
→ Пересмотр плана: нужно ли скорректировать следующие шаги?
→ Обновить журнал "что сработало"
ФАЗА 3 — Финальная рефлексия (конец)
→ Глобальная проверка: отвечает ли итог на исходный вопрос?
→ Нет ли внутренних противоречий?
→ Если нашёл — исправь и укажи что было не так
Пример применения
Задача: У тебя небольшое кафе в Москве, хочешь понять — стоит ли открывать второй вид выручки: доставка ланч-боксов в офисы. Нужен структурированный анализ с цифрами, рисками и решением.
Промпт:
Оцени перспективность запуска доставки ланч-боксов в офисы
для кафе ~30 посадочных мест в Москве (ЮЗАО, средний чек 600₽).
Цель: принять решение — запускать или нет, и если да — как именно.
Прежде чем начать — составь пошаговый план анализа.
Для каждого шага укажи: что исследуем, какие данные нужны,
по каким критериям решим что шаг выполнен корректно.
Зафикси ключевые факты и ограничения прямо сейчас:
— бюджет на запуск: до 150 000₽
— команда: 2 повара, 1 управляющий
— рабочие часы: 8:00–20:00
— целевой радиус доставки: 3 км
После каждого шага анализа добавляй сюда:
— какой подход сработал, что скорректировал, что важно помнить дальше
Для каждого шага из плана выполни по порядку:
1. Проведи анализ по шагу
2. [Локальная проверка] Проверь: учтены ли все ограничения из KnowledgeBase?
Нет ли противоречий с предыдущими шагами?
3. [Пересмотр плана] Нужно ли скорректировать следующие шаги с учётом выводов?
4. Обнови ExperienceBase
После завершения всех шагов — глобальная проверка итога:
— Отвечает ли вывод на исходный вопрос "запускать или нет"?
— Учтены ли все ограничения из KnowledgeBase?
— Нет ли внутренних противоречий между шагами?
— Если нашёл проблемы — исправь и явно укажи что пересмотрел.
Финальный ответ: решение + 3 первых шага при запуске / 2 причины отказа.
Результат: Модель выдаст структуру из явных фаз. Сначала — план анализа с критериями проверки каждого шага. Затем каждый шаг с двумя маркерами: локальная проверка (противоречий нет / вот что скорректировал) и пересмотр следующих шагов. В Memory-блоке будет накапливаться журнал выводов. В конце — явная глобальная рефлексия и финальное решение с обоснованием. Если модель нашла противоречие — она его назовёт, а не замолчит.
Почему это работает
LLM плохо держит план под давлением. Когда задача длинная и многошаговая, модель "съезжает" — первая ошибка в шаге 2 незаметно ломает шаги 3, 4, 5. Это не баг конкретной модели, это системный паттерн: модель генерирует следующий токен, опираясь на предыдущий контекст. Если контекст испорчен — ошибка множится.
LLM хорошо следует явным структурам. Когда в промпте прописаны конкретные действия ("после каждого шага проверь противоречия"), модель выполняет их буквально. Структура
Два журнала закрывают два разных разрыва. KnowledgeBase фиксирует факты до начала — модель не "теряет" ограничения в середине длинного ответа. ExperienceBase копит выводы по ходу — модель реально переносит инсайт из шага 2 в шаг 5, а не начинает с нуля. Финальная FinalReflection — это независимый аудитор, который смотрит на весь ответ целиком, а не на последний кусок.
Рычаги управления:
- KnowledgeBase — добавь или убери ограничения. Больше ограничений → строже ответ
- ExperienceBase — убери, если задача простая. Оставь, если шагов > 4
- Количество шагов в плане → явно попроси "не более 5 шагов" для экономии
- FinalReflection → добавь конкретный критерий ("проверь, не превышает ли итоговый бюджет 150 000₽")
Шаблон промпта
{задача} — опиши кратко что нужно сделать и какой результат нужен.
Составь пошаговый план выполнения задачи.
Для каждого шага: что делаем, что проверим, как поймём что шаг верный.
Ключевые факты и ограничения:
{ограничение_1}
{ограничение_2}
{ограничение_3}
[Заполняется по ходу выполнения: что сработало, что скорректировал]
Для каждого шага плана:
1. Выполни шаг
2. [Локальная проверка] Учтены ли ограничения? Нет ли противоречий?
3. [Пересмотр плана] Нужно ли скорректировать следующие шаги?
4. Обнови ExperienceBase
Глобальная проверка итога:
— Отвечает ли на исходную задачу?
— Нет ли противоречий между шагами?
— Соблюдены ли все ограничения из KnowledgeBase?
Исправь если нашёл проблему. Укажи что именно пересмотрел.
Финал: {формат_результата}
Плейсхолдеры:
- {задача} — что нужно сделать и зачем
- {ограничение_1-3} — бюджет, сроки, аудитория, доступные ресурсы
- {формат_результата} — например "решение + 3 первых шага" или "таблица плюсов и минусов"
🚀 Быстрый старт — вставь в чат:
Вот шаблон DelveAgent Framework. Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про ограничения задачи и желаемый формат результата — потому что KnowledgeBase и FinalReflection нужно заполнить конкретикой, иначе проверка будет пустой. Она возьмёт паттерн из шаблона и адаптирует под твою задачу.
Ограничения
⚠️ Простые задачи: Метод избыточен для вопросов с одним шагом — модель будет имитировать процесс там, где он не нужен. Используй для задач с 4+ зависимыми шагами.
⚠️ Контекстное окно: Длинный промпт + несколько итераций ExperienceBase + финальная рефлексия могут съесть много токенов. В длинных задачах чисти ExperienceBase каждые 3-4 шага — оставляй только ключевые выводы.
⚠️ Экспериментальный дизайн: Даже сам DelveAgent не превзошёл базовый уровень в задачах создания экспериментальных протоколов с нуля. Метод лучше работает на аналитике и многошаговом рассуждении, чем на открытом творческом синтезе.
⚠️ Фактическая точность: Двухуровневая проверка снижает внутренние противоречия, но не защищает от галлюцинаций — если модель уверенно придумала факт, она так же уверенно его "проверит". Для задач где точность критична — верифицируй факты отдельно.
Ресурсы
Название: Deep Research in Physical Sciences: A Multi-Agent Framework and Comprehensive Benchmark
Авторы: Yigeng Jiang, Tengchao Yang, Taoyong Cui и др.
Организации: Shanghai Artificial Intelligence Laboratory, Xiamen University, Institute of Physics (Chinese Academy of Sciences), Tongji University, UCL, Wuhan University
Бенчмарк: PhySciBench — 200 вопросов по физике и химии, 6 категорий задач
Агенты-бейслайны: Gemini Deep Research, OpenAI Deep Research, ODR-smolagents