TL;DR
ACE — фреймворк для улучшения LLM через накопление детального контекста вместо сжатия в короткие инструкции. Вместо "перезаписать промпт покороче", ACE постепенно строит comprehensive playbook — структурированный справочник стратегий, типичных ошибок и проверенных решений. Контекст растёт как база знаний: новые инсайты добавляются маленькими порциями (delta updates), старые сохраняются, дубликаты удаляются.
Существующие методы оптимизации промптов страдают от brevity bias — стремятся к кратким, обобщённым инструкциям, теряя доменные детали. Ещё хуже context collapse: когда LLM переписывает весь контекст целиком, он сжимает его в короткое саммари. Исследователи наблюдали как контекст в 18,282 токена схлопнулся до 122 токенов за один шаг — точность упала с 66.7% до 57.1%. Причина: LLM при полной перезаписи склонен обобщать и упрощать, теряя конкретные тактики и edge cases.
ACE решает это через три роли и инкрементальные обновления. Generator пробует решить задачу. Reflector анализирует что сработало/провалилось, извлекает конкретные уроки. Curator добавляет эти уроки в playbook как новые bullet points — не переписывает весь контекст, а дополняет существующий. Каждый пункт — это маленькая единица знания (стратегия, API-особенность, типичная ошибка) с уникальным ID и счётчиками "полезно/вредно". Периодически система чистит дубликаты, но детали сохраняются, не сжимаются в абстракции.
Схема метода
ШАГ 1 (Generator): Решить задачу → траектория рассуждений + код/действия
ШАГ 2 (Reflector): Проанализировать попытку → список конкретных инсайтов:
- Что сработало (стратегии для повторения)
- Где ошибка (типичные проблемы)
- Root cause анализ (почему так произошло)
ШАГ 3 (Curator): Обновить playbook → добавить новые bullet points:
- Формат: ID + тип + контент + счётчики helpful/harmful
- Операции: добавить новое, обновить существующее, удалить дубликаты
- Результат: расширенный playbook для следующей задачиКлючевое отличие от других методов: Шаг 3 — это не LLM перезапись всего контекста, а лёгкая логика слияния маленьких дельт. Благодаря этому можно параллельно обрабатывать много задач и накапливать знания без риска context collapse.
Пример применения
Задача: Ты — менеджер проектов в IT-компании в Москве. За 3 месяца работы с разными подрядчиками накопились кейсы: кто-то срывал сроки, кто-то плохо понимал ТЗ, кто-то делал отлично. Вместо держать это в голове, хочешь построить детальный playbook "Работа с подрядчиками" для себя и коллег.
Применяешь принцип ACE: не краткое саммари "будь строже", а структурированный справочник конкретных стратегий.
Промпт:
Я менеджер проектов, работаю с внешними подрядчиками (дизайнеры, разработчики, SEO).
Хочу накопить детальный playbook — базу проверенных стратегий и типичных проблем.
PLAYBOOK STRUCTURE:
- Каждый пункт — конкретная тактика/ошибка/правило
- Формат: [Тип: стратегия/ошибка/красный_флаг] — [описание]
- Детали важнее краткости — LLM разберётся, мне нужна полнота
ТЕКУЩИЙ PLAYBOOK:
[пусто на старте или вставляешь накопленное]
Я расскажу тебе кейс из работы. Твоя задача:
1. Извлечь КОНКРЕТНЫЕ стратегии/ошибки/паттерны из этого кейса
2. Предложить новые пункты для playbook (детально, не обобщённо)
3. Проверить нет ли дубликатов с существующими
4. Выдать обновлённый PLAYBOOK
КЕЙС: Работали с дизайнером Иваном из студии "Пиксель".
Первый созвон — попросил "современный сайт для стартапа".
Иван сдал макет, но там тёмная тема (мы B2B, нужно доверие, светлые тона).
Переделка заняла неделю. В следующий раз с другим дизайнером сразу показал
3 референса конкурентов + мудборд в Figma — попал с первого раза.Результат:
Модель проанализирует кейс и добавит в playbook конкретные пункты вроде:
- [Стратегия] При брифе дизайнеру — не словами "современный", а 3-5 скриншотов референсов
- [Ошибка] Описывать стиль абстрактно ("стильно", "минимализм") → дизайнер поймёт по-своему
- [Красный флаг] Если дизайнер не задаёт уточняющих вопросов на брифе → вероятно сдаст не то
- [Тактика] Мудборд в Figma/Pinterest перед стартом → на 70% снижает переделки
При следующем кейсе (например, разработчик не уточнил требования к API) — модель дополнит playbook новыми пунктами, но сохранит старые. Через 10-20 кейсов получится детальная база знаний для работы с подрядчиками.
Почему это работает
LLM лучше работает с длинными детальными контекстами, не с краткими обобщениями. Исследование показывает: когда модель получает comprehensive playbook (даже 10-20k токенов), она сама выбирает релевантное на этапе inference. Человеку нужна краткость для запоминания, LLM — нет. Наоборот: чем больше конкретных edge cases, API-особенностей, проверенных тактик в контексте, тем точнее результат. Краткий промпт "будь внимательнее" не даёт модели конкретных рычагов — что именно проверить, какие ошибки частые, как решать типичные проблемы.
Инкрементальные обновления предотвращают context collapse. Когда просишь LLM "перепиши весь промпт", модель склонна сжимать — убирать детали, обобщать, терять нюансы. Это естественно для языковой модели: она оптимизирована на генерацию связного текста, а не на сохранение всех деталей. ACE не переписывает, а добавляет маленькие дельты. Curator получает не "переформулируй контекст", а "вот 3 новых инсайта — добавь их как bullet points". Старое сохраняется, новое дополняет. Дедупликация убирает повторы, но детали остаются.
Разделение ролей повышает качество каждого этапа. Когда одна модель делает всё (решает задачу И анализирует И обновляет контекст), возникает conflict of interest — сложно одновременно генерировать и критиковать себя. ACE разделяет: Generator фокусируется на решении, Reflector — на анализе (может запускаться несколько раз для углубления), Curator — на структурировании. Это как в команде: разработчик пишет код, reviewer находит баги, tech writer документирует — каждый делает своё хорошо.
Рычаги управления для адаптации:
- Число раундов Reflector (1-5) → больше раундов = глубже анализ, но дороже. Для простых задач хватит 1-2.
- Batch size (сколько задач анализировать за раз) → в исследовании 1, но можно 5-10 для ускорения.
- Порог дедупликации → насколько похожие пункты считать дубликатами. Строже = компактнее playbook, мягче = больше деталей.
- Warmup → можно стартовать с пустого playbook (online learning) или прогреть на обучающих примерах (offline warmup).
Шаблон промпта
Базовый шаблон для накопления знаний
Я работаю над {областью/проектом}. Хочу построить детальный playbook —
базу проверенных стратегий, типичных ошибок и edge cases.
ПРИНЦИПЫ PLAYBOOK:
- Детали > краткость (ты LLM, длинный контекст — твоя сила)
- Конкретные тактики, не абстрактные советы
- Формат: [Тип] — [описание]
Типы: стратегия | ошибка | красный_флаг | edge_case | API_особенность
ТЕКУЩИЙ PLAYBOOK:
{вставь существующие пункты или оставь пустым}
---
НОВЫЙ КЕЙС/ЗАДАЧА:
{опиши что произошло, что сработало/не сработало}
---
ЗАДАЧИ:
1. REFLECTOR MODE: Проанализируй кейс
- Что можно извлечь? (стратегии, ошибки, паттерны)
- Почему так произошло? (root cause)
- Что делать в будущем? (конкретные действия)
2. CURATOR MODE: Обнови playbook
- Предложи новые пункты (детально, с примерами)
- Проверь дубликаты с существующими
- Если пункт похож на существующий — уточни разницу или объедини
3. Выдай обновлённый PLAYBOOK (все старые пункты + новые)Что подставлять:
{областью/проектом}— твоя специализация (маркетинг, продажи, код, найм, дизайн){существующие пункты}— скопируй playbook из прошлого ответа{кейс}— опиши конкретную ситуацию: что делал, что получилось, где провал
Multi-turn workflow (симуляция ACE в обычном чате)
Я хочу улучшить {свой промпт/подход к задаче} через итеративное обучение.
Текущий подход:
{опиши свой метод или вставь промпт}
Давай сделаем 3-этапный цикл:
ЭТАП 1 — GENERATOR:
Попробуй решить эту задачу с текущим подходом:
{задача}
ЭТАП 2 — REFLECTOR:
Проанализируй свою попытку:
- Что сработало?
- Где ошибка/недочёт?
- Root cause (почему так вышло?)
- Какие конкретные стратегии можно извлечь?
ЭТАП 3 — CURATOR:
На основе рефлексии предложи обновлённый подход:
- Добавь новые правила/стратегии
- Сохрани то, что работало
- Убери дубликаты
Выдай финальный улучшенный подход для следующей итерации.🚀 Быстрый старт — вставь в чат:
Вот шаблон ACE для накопления знаний. Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить "Базовый шаблон для накопления знаний" выше]LLM спросит о твоей области, первом кейсе и какой формат playbook нужен — потому что для структурирования знаний важно понять контекст и желаемый уровень детализации. Она возьмёт паттерн Reflector→Curator из шаблона и адаптирует под конкретную задачу.
Ограничения
⚠️ Зависимость от качества Reflector: Если модель не может извлечь полезные инсайты из кейса (слабая модель или слишком специфичный домен), playbook наполнится шумом. В исследовании использовали DeepSeek-V3 — для слабых моделей лучше добавить примеры хорошей рефлексии в промпт.
⚠️ Требуется feedback signal: ACE хорошо работает когда есть чёткая обратная связь — execution success/fail для кода, ground truth для задач. В задачах где "правильный ответ" субъективен (креатив, стиль текста), метод даёт меньший эффект. На финансовых задачах без ground truth ACE и другие методы деградировали.
⚠️ Не для всех задач: Простые задачи (HotPotQA — найти факт в документе, Game of 24 — фиксированная стратегия) не нуждаются в длинных playbook. ACE создан для сложных доменов с множеством edge cases и стратегий (агенты, специализированный анализ, код).
⚠️ Overhead на накопление: Нужно несколько итераций чтобы playbook "прогрелся". В offline режиме — запустить на 50-100 обучающих примерах. В online — первые 10-20 задач могут быть хуже baseline, пока контекст не накопится.
Как исследовали
Команда проверила ACE на двух типах задач: агенты (AppWorld — взаимодействие с API, код, окружение) и domain-specific (финансовый анализ FiNER и Formula). Взяли 7 моделей разного размера, сравнили с сильными baseline: ICL (many-shot с демонстрациями), MIPROv2 (Bayesian optimization промптов), GEPA (генетический поиск промптов через рефлексию), Dynamic Cheatsheet (адаптивная память агента).
Тестировали в двух режимах: offline (оптимизация на train, оценка на test) и online (на каждом test примере обновлять контекст и сразу использовать).
Почему пришли к выводам: ACE превзошёл всех на 10.6% (агенты) и 8.6% (финансы) в среднем. Удивительное наблюдение — на AppWorld benchmark, ACE с маленькой open-source моделью DeepSeek-V3 сравнялся с топовым production агентом IBM CUGA (GPT-4.1) на average и превзошёл на сложном test-challenge split (+8.4% TGC). Это показывает: comprehensive context компенсирует меньший размер модели.
Второй важный инсайт — ACE работает без labeled data. На агентских задачах, где есть execution feedback (код выполнился или упал), ACE улучшил baseline на 14.8% вообще не видя ground truth. Значит метод подходит для self-improving агентов, которые учатся на своих ошибках.
Третий — стоимость и скорость. ACE снизил adaptation latency на 82-92% по сравнению с GEPA и Dynamic Cheatsheet, требуя на 75% меньше rollouts и на 84% меньше долларов на токены. Причина: инкрементальные delta updates дешевле полной перезаписи контекста.
Ablation studies показали: Reflector даёт +5-7% к точности (vs без него), multi-epoch adaptation (прогон по train данным несколько раз) даёт ещё +3-4%, offline warmup перед online обучением даёт быстрый старт.
Ресурсы
Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models (2025)
Qizheng Zhang, Changran Hu, Shubhangi Upasani, Boyuan Ma, Fenglu Hong, Vamsidhar Kamanuru, Jay Rainton, Chen Wu, Mengmeng Ji, Hanchen Li, Urmish Thakker, James Zou, Kunle Olukotun
Stanford University, SambaNova Systems, UC Berkeley
AppWorld Leaderboard — бенчмарк агентов, где ACE показал результат
Dynamic Cheatsheet paper — предшественник ACE, адаптивная память агента