From Memory to Guide (Spatio-Temporal Composer): превращаем скилы агента в короткие инструкции с границами и сроком действия

ШАГ 0: Агент видит только каталог скилов (названия + краткое описание)
ШАГ 1: Агент формулирует локальную цель, прогресс, блокеры → запрос на Guide
ШАГ 2: СЕЛЕКТОР (вспомогательная модель) получает: профиль задачи + свидетельства
        выполнения + прошлый Guide
        → decision (нужен ли новый Guide), skillRefs (какие скилы), whyNow (почему сейчас)
ШАГ 3: КОМПОЗИТОР собирает Runtime Guide:
        GOAL → ACTIONS → BOUNDARIES (Applies When) → Verification → TERMINATION
ШАГ 4: Агент работает строго внутри Guide
ШАГ 5: Условие завершения сработало → Guide снят → агент перечитывает требования
        задачи → новая цель → снова ШАГ 1

В исследовании шаги 2–3 выполняют отдельные модели в коде. Каждый шаг — отдельный запрос.

Задача: Вы ведёте с Claude Code бэкенд сервиса приёма платежей. Стек: FastAPI, Poetry, PostgreSQL. В библиотеке три скила: «идемпотентность платежей», «миграции БД», «архитектурный рефакторинг». Скил по миграциям написан под pip и requirements.txt. Ваш проект живёт на Poetry. Сейчас агент должен сделать создание и просмотр платежей через ЮKassa. Если дать ему все скилы целиком, он начнёт ставить пакеты через pip, а при первой же ошибке теста решит «улучшить архитектуру».

Промпт (отдельный чат или субагент-«композитор»):

Ты — композитор инструкций. Твоя задача — не выполнять работу, а подготовить
для кодирующего агента короткий Guide на текущий этап.

ПРОФИЛЬ ПРОЕКТА:
FastAPI, Poetry (pip не использовать), PostgreSQL, платежи через ЮKassa.
Правила: все суммы в копейках (int), API v1 не ломать, миграции только через Alembic.

СВИДЕТЕЛЬСТВА ВЫПОЛНЕНИЯ:
Готово: модели Payment, подключение к БД. Тесты на модели проходят.
Текущая цель: эндпоинты создания и просмотра платежа.
Блокеров нет.

ПРОШЛЫЙ GUIDE:
«Каркас проекта и модели» — завершён.

ДОСТУПНЫЕ СКИЛЫ:
1) Идемпотентность платежей — {текст скила}
2) Миграции БД — {текст скила}
3) Архитектурный рефакторинг — {текст скила}

Сначала реши:
- decision: нужен ли новый Guide (Generate / None)
- skillRefs: какие скилы использовать (можно несколько)
- whyNow: какой пробел в работе сейчас и чем выбранные скилы его закрывают

Затем составь Runtime Guide:
- GOAL: одна локальная цель
- ACTIONS: конкретные шаги под ЭТОТ проект (команды Poetry, таблицы, ЮKassa),
  а не общие правила из скилов
- BOUNDARIES: что нельзя делать и когда Guide применим (Applies When)
- VERIFICATION: как проверить, что цель достигнута
- TERMINATION: когда Guide снимается (цель достигнута, сменился этап,
  непреодолимый блокер)

Результат: Композитор вернёт решение, список выбранных скилов (скорее всего, идемпотентность и миграции) и объяснение «почему сейчас». Дальше идёт Guide из пяти блоков. Команды в нём будут переписаны под Poetry. Архитектурный рефакторинг в границах запрещён. Условие завершения привязано к готовности эндпоинтов и прохождению тестов. Этот Guide вы отдаёте кодирующему агенту вместо сырых скилов.

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

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

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

Рычаги управления: - Профиль задачи (правила, стек, запреты) → чем точнее, тем лучше композитор отсекает несовместимое. - Свидетельства выполнения (что сделано, что упало, какие тесты) → без них Guide хуже подстраивается под этап. По абляции без них результат падает на 7 пп. - Условие завершения → без него Guide остаётся «висеть» и мешает. Без жизненного цикла падение 10 пп. - Прошлый Guide → позволяет композитору видеть, что уже закрыто, и не повторять советы. - Число скилов в одном Guide → можно брать несколько, если они закрывают разные части цели.

Ниже ручная версия метода для чата или субагента. В статье самих текстов промптов нет. Шаблон собран по описанным в ней полям: decision, skillRefs, whyNow, цель, действия, границы, условия завершения.

Ты — композитор инструкций. Ты не выполняешь задачу. Ты готовишь для кодирующего
агента короткий Runtime Guide на ТЕКУЩИЙ этап.


{цели проекта, стек, правила, запреты, инструменты}



{что уже сделано, результаты тестов, блокеры, текущая локальная цель}



{прошлый Guide и чем он закончился, или «нет»}



{список скилов: название — когда применять — текст}



decision: Generate или None. None — если действующий Guide ещё не завершён
skillRefs: какие скилы использовать (один или несколько)
whyNow: какой пробел в работе сейчас и что именно эти скилы в нём закрывают



GOAL: одна локальная цель этапа
ACTIONS: конкретные шаги под этот проект (имена файлов, команды, таблицы),
         не общие правила из скилов
BOUNDARIES / Applies When: что нельзя делать; при каких условиях Guide применим
VERIFICATION: как проверить, что цель достигнута
TERMINATION: когда Guide снимается — цель достигнута, сменился этап
             или появился непреодолимый блокер


Если decision = None, верни только .

Плейсхолдеры: - {цели проекта…}: всё, что агент не должен нарушать (менеджер пакетов, версии API, формат данных). - {что уже сделано…}: свежий отчёт агента, а не вся история. - {список скилов}: ваши скилы или файлы инструкций.

🚀 Быстрый старт — вставь в чат:

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

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

LLM спросит про стек, правила проекта, текущий этап и список скилов. Метод работает только тогда, когда Guide привязан к конкретным правилам проекта и конкретному этапу. Без этих данных композитор выдаст те же общие советы, что и скил.

⚠️ Нужен код для полной версии: в исследовании Селектор и Композитор — отдельные модели, встроенные в цикл агента (агент сам запрашивает Guide, система передаёт ему результат). Вручную можно повторить идею, но не автоматизацию.

⚠️ Цена вспомогательных запросов не учтена: экономия токенов в 32% посчитана только для основного агента. Расходы на Селектор и Композитор отдельно не включены.

⚠️ Одна среда и одна модель-исполнитель: проверка шла на одном кодирующем агенте и на бенчмарке самих авторов. Перенос на другие агенты и модели — догадка.

⚠️ Только долгие задачи: метод создан для многочасовой разработки. На короткой правке файла лишний шаг композиции, скорее всего, не окупится.

⚠️ Эффект умеренный: абсолютный прирост успешных прохождений — около 7 пунктов на сложных задачах. Это заметно, но не «агент стал решать всё».

⚠️ Материал неполный: в доступном тексте обрывается раздел со сравнением «только Селектор» и «общий совет без скилов». Поэтому вклад каждого компонента виден только по абляциям.

Авторы взяли 13 длинных задач по разработке ПО из бенчмарка EngramBench. В среднем один прогон шёл 4,3 часа, самый долгий больше 12. Всего вышло 78 прогонов и более 335 часов работы. Исполнитель — Codex с GPT-5.5 на среднем уровне рассуждений. Библиотека — 18 фиксированных скилов, подготовленных заранее.

Основное сравнение: тот же агент и те же скилы, но в одном случае скилы подаются напрямую, в другом идут через Composer. На четырёх самых сложных задачах (около 8,5 часа на прогон) доля подтверждённо пройденных тестов выросла с 29,9% до 37,1%. Это +7,2 пункта. Расход токенов основного агента упал на 32,2%. На остальных девяти задачах число пройденных проверок выросло с 458 до 563 (+22,9% относительно), а токенов ушло на 6,86% меньше.

Затем провели абляции на четырёх задачах: по очереди убирали отдельные части. Без свежих свидетельств выполнения результат падал на 7,03 пункта. Без явного жизненного цикла (условий завершения и повторного чтения требований) — на 10,09 пункта. Инсайт для практики: «когда перестать применять инструкцию» влияет сильнее, чем «как адаптировать». Заодно метод тратит меньше токенов, потому что агент не тянет в контекст лишнее.

Это не часть метода статьи, а возможные переносы идеи на работу без кода.

🔧 Техника: добавить в каждый скил блок «Applies When / Termination» → агент сам понимает, когда скил включать и снимать

## Applies When
Только при создании нового модуля. Не использовать при исправлении багов.

## Verification
Новый модуль проходит линтер и тесты.

## Termination
Модуль создан и тесты зелёные — скил больше не применять в этой сессии.

В статье границы и завершение задаёт Композитор. Здесь вы заранее прописываете их в самом файле скила.

Экстраполяция: правило в CLAUDE.md / AGENTS.md

Перед применением любого скила:
1. Сверь его с правилами проекта (менеджер пакетов, версии API, формат данных).
   Если скил им противоречит — перепиши шаги под проект.
2. Сформулируй локальную цель и условие завершения одной строкой.
3. Когда условие выполнено — скил больше не применяй,
   перечитай требования задачи и выбери следующую цель.

Это ручная имитация цикла Composer без вспомогательной модели. Эффект не проверен, это идея по мотивам статьи.

• From Memory to Guide: Spatio-Temporal Composer for Procedural Coding Memory (Composer Technical Report, v1.0)
• Авторы: Zhixuan Tan, Pengjie Gu, Zhao Li, Yihan Hu, Xu He, Dong Li, Jianye Hao
• Организации: The Chinese University of Hong Kong, Shenzhen; MemoraX AI
• Бенчмарк: EngramBench (Z. Tan et al. 2026)
• Связанные работы: Agentic Context Engineering, ExpeL, Agent Workflow Memory, SEAM, SkVM, SkillSmith