DAEDALUS: память агента из самостоятельно придуманных задач, где каждое правило проверено повторным прогоном

ШАГ 0: Обзорщик один раз изучает среду → карта областей и план: сколько задач на какую область
ЦИКЛ (n сессий):
  ШАГ 1: Исследователь придумывает реалистичную задачу + условия успеха, сам её решает (доказывает выполнимость)
  ШАГ 2: Решатель пробует с чистого состояния среды; Судья сверяет итог с условиями успеха
  ШАГ 3: Провал → Экстрактор пишет (или правит) правило по задаче и следу провала → Решатель пробует снова
  ШАГ 4: Исход:
         • 3 успеха подряд, а до этого был хотя бы 1 провал → правило ПРИНЯТО
         • ни одного провала → «слишком легко» → Исследователь усложняет (до 5 раз)
         • 8 провалов → «слишком трудно» → Исследователь упрощает
ШАГ 5: Консолидатор одним вызовом сливает принятые правила в список
ШАГ 6: Список замораживается и вставляется целиком в начало контекста рабочего агента

Шаги выполняются отдельными вызовами агентов. Это цикл с оркестрацией, а не один промпт.

Задача: Вы настроили агента в Claude Code, который работает с API «МойСклад»: сверяет остатки, создаёт заказы, выгружает отчёты. Каждую новую сессию он заново наступает на одни и те же грабли: неправильный формат полей, забытая постраничная выдача, лишние запросы. Готовых тестовых задач и проверяющего скрипта у вас нет. Нужно, чтобы агент начинал работу уже с набором проверенных правил.

Ниже ручная версия метода для тестового аккаунта. Это упрощение, а не оригинал.

Промпт (оркестратору):

Ты — оркестратор. Работаешь на ТЕСТОВОМ аккаунте МойСклад, боевые данные не трогай.
Цель: собрать список проверенных правил для агента, который работает с этим API.

Повтори 10 сессий. В каждой:
1. Роль Исследователь: придумай реалистичную задачу для менеджера интернет-магазина
   (например, «найти товары с остатком ниже 5 и создать заказ поставщику»).
   Выполни её сам, чтобы убедиться, что она выполнима. Запиши условия успеха списком.
2. Роль Решатель (отдельный субагент с чистым контекстом): выполни задачу.
3. Роль Судья: сверь результат с условиями успеха. Ответ: успех / провал + причина.
4. Если провал — роль Экстрактор (видит только текст задачи и ход попытки,
   НЕ видит список условий успеха): напиши одно общее правило,
   которое помогло бы в похожих задачах. Не пиши правило под эту конкретную задачу.
   Решатель пробует снова с этим правилом в контексте. После повторного провала
   Экстрактор правит правило.
5. Правило считается принятым, только если Решатель с ним справился 3 раза подряд,
   а до этого провалился хотя бы раз.
   Решатель ни разу не провалился → задача слишком лёгкая, усложни (до 5 раз).
   Решатель провалился 8 раз → задача слишком трудная, упрости.

В конце: роль Консолидатор объединяет принятые правила в один список,
убирает повторы, сохраняет конкретику. Выдай список в формате для файла AGENTS.md.

Результат: Оркестратор покажет по каждой сессии задачу, попытки Решателя, вердикты Судьи и правила, которые менялись после провалов. На выходе будет короткий список принятых правил, готовый для вставки в начало инструкций агента. Часть сессий закончится без правила: задача оказалась слишком лёгкой или слишком трудной.

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

Сильная сторона: модель хорошо разбирает конкретный провал. Она видит, где именно ошиблась, и формулирует урок. Она также неплохо судит, выполнено ли условие, если условия записаны текстом: Судья в статье совпал с официальными проверками на уровне «существенного согласия».

Как метод это использует: урок из провала — только гипотеза. Её проверяют на самом Решателе: помогло ли правило провалившуюся задачу превратить в стабильный успех. Три успеха подряд вместо одного снижают шанс принять пустое правило из-за случайного везения. Калибровка сложности держит задачи «на краю возможностей» Решателя. Лёгкие задачи не дают уроков, а слишком трудные не решаются даже с правилом.

Рычаги управления: - Число успехов подряд (3 в статье). Больше — строже отбор, но дороже. Меньше — быстрее, но больше шума. - Лимит провалов (8) и число упрощений/усложнений (5). Уменьшай для недорогой пробы. - Что видит Экстрактор. В оригинале он не знает, какие условия успеха провалены. Это заставляет писать общие правила, а не латать конкретную задачу. - Число сессий. Польза заметна уже при небольшом бюджете. - Способ подачи. Статья сообщает: при таком объёме лучше свести правила в один список и вставить целиком в начало, чем подтягивать их по ходу работы.

В статье нет готового текстового промпта. Ниже оригинальная структура сессии с ролями и параметрами из статьи, записанная как инструкция оркестратору. Формулировки реплик восстановлены по описанию ролей.

Ты — оркестратор обучения памяти агента. Среда: {среда}. Тестовые данные, боевые не трогать.
Цель — список проверенных правил (эвристик) для агента {описание_рабочего_агента}.



N_sessions = {число_сессий}
N_s = 3      # успехов подряд для принятия правила
N_f = 8      # провалов, после которых задача считается слишком трудной
N_r = 5      # максимум пересмотров сложности задачи



Один раз изучи среду. Составь список областей (например, {области})
и распредели сессии по ним, чтобы задачи покрывали среду равномерно.



Explorer = Agent("исследователь")
Solver = Agent("решатель")      # чистый контекст перед каждой попыткой
Judge = Agent("судья")
Extractor = Agent("экстрактор") # НЕ видит условия успеха, только задачу и ход попытки

task = Explorer.propose_task(area=из плана)        # инструкция + условия успеха
Explorer.solve(task)                                # докажи, что задача выполнима
heuristic = None; streak = 0; fails = 0; ever_failed = False

While streak < N_s and fails < N_f:
    result = Solver.attempt(task, heuristic)        # с чистого состояния среды
    verdict = Judge.check(result, task.success_conditions)
    If verdict == success:
        streak += 1
    Else:
        fails += 1; streak = 0; ever_failed = True
        heuristic = Extractor.write_or_revise(task.instruction, result.trace, heuristic)
        # правило общее, не заплатка под одну задачу

If streak == N_s and ever_failed:   bank.add(heuristic)             # ПРИНЯТО
If not ever_failed:                  task = Explorer.make_harder(task)   # слишком легко, до N_r раз
If fails == N_f:                     task = Explorer.make_easier(task)   # слишком трудно



Consolidator.merge(bank): убери повторы и пересечения, сохрани конкретные действия.
Выдай один список для вставки в начало контекста агента.

Что подставлять: {среда} — ваш инструмент или API на тестовых данных, {описание_рабочего_агента} — что агент делает в работе, {число_сессий} — для пробы 10–20, {области} — разделы вашей среды.

🚀 Быстрый старт — вставь в чат или в Claude Code:

Вот шаблон метода DAEDALUS. Адаптируй под мою задачу: [твоя среда и что делает агент].
Задавай вопросы, чтобы заполнить поля.

[вставить шаблон выше]

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

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

⚠️ Нужны проверяемые условия успеха: метод работает там, где итог можно сверить с чётким списком условий. Для текстов, креатива и «хорошо/плохо» без критериев он не проверялся.

⚠️ Исследование без Решателя вредит: правила, собранные только по результатам просмотра среды, оказались хуже отсутствия памяти. Пропустить стадию «пробуем и проверяем повтором» нельзя.

⚠️ Нужна оркестрация: метод многоагентный, с циклами и сбросами. Вручную в чате его не пройти. Нужен агентный инструмент с субагентами или автоматизация. В статье это реализовано кодом.

⚠️ Генерация стоит денег: полный прогон на 90 сессий обошёлся примерно в сотню долларов API (в ранних вариантах пайплайна — в двести). Это разовые затраты, при использовании агент тратит столько же или меньше за счёт более коротких траекторий.

⚠️ Судья ошибается: он отвергает часть настоящих успехов, примерно каждый шестой-седьмой. Это безопасная сторона ошибки, но лишние итерации будут.

⚠️ У сильных моделей выигрыш меньше: если агент уже решает большинство задач, запас для улучшения мал. На самом трудном бенчмарке (бизнес-процессы в SaaS) прирост был скромнее, а лучшие методы с готовыми задачами всё равно впереди по некоторым метрикам.

Команда взяла три агентных бенчмарка: управление приложениями кодом (AppWorld), поддержку клиентов в ритейле (τ²-bench) и бизнес-процессы в SaaS (AutomationBench). Сравнивали с агентом без памяти и шестью методами памяти. Пять из шести получали готовые обучающие задачи, у DAEDALUS их не было. Результаты усредняли по пяти прогонам. Вспомогательные роли играла большая модель, Решателя и рабочего агента — меньшая из того же семейства.

Прирост средней успешности над агентом без памяти составил 15.9, 10.0 и 4.3 пункта. Согласованность по пяти прогонам подряд (pass^5) выросла в 1.7–2.2 раза. В четырёх из шести колонок результат оказался в пределах погрешности от лучшего метода с готовыми задачами. Когда DAEDALUS дали те же обучающие задачи, он обошёл остальные методы на всех бенчмарках. Значит, механизм проверки работает сам по себе, а самопридуманные задачи теряют лишь немного.

Самая интересная часть — поэтапное усложнение пайплайна на AppWorld: - Один исследователь без Решателя дал 35.7 против 44.3 у агента без памяти. Хуже, чем ничего. - Добавили следы попыток Решателя — прирост около 16 пунктов. Это главный скачок. - Добавили цикл «провал → правило → повтор до трёх успехов» — ещё +4.5 пункта, шум выбрасывается. - Обзор среды и накопление советов по калибровке сложности почти не меняли качество, зато снизили стоимость генерации на 48%.

Правила, сгенерированные одним семейством моделей, помогали агентам других семейств: все девять комбинаций дали плюс. Правила Qwen помогли GPT-5.4-mini не меньше, чем его собственные (+16.8 против +15.9). Задачи, придуманные пайплайном, ранжировали модели так же, как официальные тесты. Значит, их можно использовать как замену тестового набора там, где его нет.

🔧 Техника: скрыть от Экстрактора условия успеха → правила становятся общими

В оригинале Экстрактор видит только задачу и ход попытки. Если дать ему список невыполненных условий, он начнёт писать заплатки вида «для такого-то заказа делай так-то». Для своих прогонов не показывайте ему вердикт Судьи, только саму задачу и след.

🔧 Техника: единый список в начале контекста → без поиска по ходу работы

Для пробных 10–20 правил не нужен поиск по базе. Сведите их в один блок и вставьте в начало AGENTS.md или CLAUDE.md. В статье такой способ дал результат лучше, чем подача правил по запросу в каждой реплике.

Экстраполяция — ручная версия на живой работе. Её нет в статье, это идея читателя. Метод проверяет правила прогоном, а в обычной работе с агентом вы это делаете постфактум:

Вот правило, которое ты предложил добавить в AGENTS.md: {правило}.
Вот задача, на которой ты ошибся: {задача}.
Реши эту задачу три раза подряд с нуля, имея это правило в контексте.
Если хотя бы раз не справишься — перепиши правило и повтори.
Предложи для файла только то правило, которое сработало все три раза.

Это грубая версия принципа «принимаем правило после повторного успеха на провалившейся задаче». Три раза в одном диалоге без сброса контекста — слабая замена чистым прогонам. Надёжнее запускать каждый раз в новой сессии.

• DAEDALUS: Bootstrapping Agent Memory from Self-Generated Tasks — Antoine Edy, Max Conti, Victor Xing, Marc-Antoine Allard, Nawfal Benhamdane, Gautier Viaud, Illuin Technology.
• Код, сгенерированные задачи, наборы правил и траектории: github.com/illuin-tech/daedalus
• Бенчмарки: AppWorld (Trivedi et al.), τ²-bench (Barres et al.), AutomationBench (Shepard & Salimans).
• Сравнивали с ExpeL, AutoGuide, ERL, ReasoningBank, ACE, PREPING.