Управление контекстом

Контекст стал главным ограничением

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

Поэтому у дисциплины появилось название — контекст-инжиниринг. Название новое, суть инженерная и знакомая: ограниченный ресурс, конкурирующие потребители, бюджет, деградация под нагрузкой и необходимость измерять, а не надеяться.

Главная ошибка при переходе к агентам — считать окно контекста складом. Чем больше положили, тем хуже работает: деградация начинается задолго до формального предела.

Про что эта статья

Про две связанные вещи, которые обычно обсуждают отдельно:

• Контекст в проекте. Кодовая база, файлы правил, skills, документация — что агент видит, когда работает с вашим репозиторием, и сколько это стоит в токенах.
• Контекст в системе. Продакшн-агент: память, retrieval, разделение на суб-агентов, компакция длинных сессий, измерение деградации.

Материал собран из публичных докладов практиков — конференции AI Engineer, NDC, Developer Summit, разборы инженеров Anthropic, Elastic, Neo4j, Datadog, Arize, Cognition, LangChain, Notion, Tesla, ZS Associates и других. Отбирались выступления, где называют механику и цифры, а не общие рассуждения о будущем. Из 41 доклада извлечено около 380 конкретных наблюдений; в статью вошли те, что можно применить или проверить.

Чего здесь нет

Нет обзора инструментов и нет советов вида «используйте RAG». Есть разбор компромиссов: где retrieval помогает, а где не работает по конструкции; когда компакция спасает сессию, а когда тихо съедает ваши правила; почему пять инструментов иногда лучше сорока шести.

Отдельно оговорюсь про качество данных. Часть цифр — из лабораторных замеров с методологией (например, тест Chroma на восемнадцати моделях). Часть — из практики отдельных команд, где методологии нет, и это порядок величины, а не измерение. Такие места помечены в тексте. Там, где источники противоречат друг другу — а по компакции они противоречат прямо, — приведены обе позиции: дисциплине примерно год, устоявшегося свода правил ещё нет.

Как читать

Разделы идут от диагноза к практике: сначала почему контекст ломается, затем четыре техники управления (компакция, retrieval, структура, память), потом организация контекста в кодовой базе и разделение между агентами, и в конце — эксплуатация: как измерять деградацию и во что она обходится. В конце — сводный чек-лист.

Если времени мало, начните с первого раздела и чек-листа: первый объясняет, почему ваш агент «тупеет» на длинной сессии, а чек-лист даёт порядок действий.

Статья основана на публичных выступлениях; все цифры — со слов докладчиков. Ссылки на источники приведены прямо в тексте.

Почему контекст ломается раньше, чем кончается окно

Типичный разбор инцидента с агентом выглядит так: он отработал десяток шагов чисто, а потом начал вызывать бессмысленные инструменты, забывать задачу и выдавать мусор. Marina Wyss в своём курсе по context engineering описывает этот сценарий как самый частый и указывает порог примерно на 15–20 шагах — с оговоркой, что это наблюдение практиков, а не измерение. Первая гипотеза команды почти всегда одна: «плохая модель, возьмём поумнее». Вторая — «мало места, возьмём окно побольше». Обе неверны, и это не вопрос вкуса — это измерено.

Деградация начинается задолго до предела окна

Главный факт, вокруг которого строится всё остальное, дало исследование Chroma. Прогнали 18 фронтир-моделей — GPT-4.1, Claude 4, Gemini 2.5, Qwen 3 и другие — на растущей длине входа. Качество падало у каждой без исключения, и падало непрерывно, а не обрывалось в точке лимита. Ключевая цифра: модель с окном 200k может показывать заметную деградацию уже на 50k токенов. Ведущая JetBrains в разборе устройства агентов пересказывает тот же замер и формулирует вывод жёстче: это свойство моделей, а не баг харнесса. «Больше контекста» и «лучше контекст» — разные вещи.

Дальше начинаются рабочие правила практиков, и они интересны тем, что расходятся в цифрах, но сходятся в порядке величины.

Dex Horthy из HumanLayer на YC Root Access рассказывал, что весь их процесс (research → plan → implement) построен так, чтобы утилизация окна никогда не превышала 40%. Как только приближается — план обновляется («это сделано, переходим к следующей фазе») и открывается новое окно. Рабочий объём окна они оценивают примерно в 170k токенов и говорят прямо: чем меньше из них потратишь на работу, тем лучше результат.

Elvin Aghammadzada из DataRobot на AI Engineer ссылается на ту же работу про context rot и называет более ранний порог: производительность начинает падать примерно с 25% занятости окна, то есть у окна на 1M токенов проблемы начинаются где-то с 256K. Он же вводит удобную рамку «smart zone / dumb zone»: до ~40% модель в умной зоне, дальше — в тупой. Обещание «бесконечного окна» от лабораторий он называет красивой ложью, которая ломает мышление про RAG и MCP.

Стоит сказать честно: и 40%, и 25% — эвристики без опубликованной методики. Aghammadzada своих замеров не приводит, а ссылается на чужую статью; Horthy описывает дисциплину команды из трёх человек. Порядок величины они дают одинаковый: рабочая зона — это первая треть окна, а не «пока влезает».

Чем именно портится контекст

Деградация — не одна болезнь. Lance Martin из LangChain, опираясь на классификацию Drew Breunig, раскладывает её на четыре режима, и то же деление независимо повторяют Google Cloud в своём обучающем материале: poisoning (в контекст попала галлюцинация и дальше цитируется снова и снова), distraction (контекст так длинен, что модель переопирается на недавнюю историю вместо построения нового плана — начинает пересказывать свои прошлые действия вместо синтеза), confusion (лишние детали уводят в неверный ответ), clash (два куска контекста противоречат друг другу). Лечатся они по-разному, и «увеличим окно» не лечит ни один.

Lost in the middle. Модели надёжно достают то, что лежит в начале и в конце контекста, а середина проваливается. Marina Wyss приводит цифру: перенос релевантной информации из начала в середину роняет точность более чем на 30 процентных пунктов. Ragunath Jawahar на Developer Summit объясняет практическое следствие: системный промпт и AGENTS.md держатся долго, потому что стоят на переднем крае окна, а вот исходные инструкции агента, засыпанные 50 000 токенов tool-выводов, фактически исчезают. Формально они в контексте. Практически — нет.

Отвлечение на инструменты. Это самый недооценённый механизм, потому что он срабатывает при полностью свободном окне. Lance Martin ссылается на исследование по RAG-over-tools: качество деградирует примерно после 30 инструментов и полностью разваливается около 100. Marina Wyss приводит бенчмарк, который отделяет проблему бюджета от проблемы рассуждения.

Что произошло: 46 инструментов ломают модель, которой хватало окна

• Кто: бенчмарк GeoEngine, квантованная Llama 3.1 8B — в пересказе Marina Wyss.
• Что делали: дали модели все 46 доступных инструментов; контекст при этом спокойно помещался в окно.
• Результат: провал бенчмарка. С 19 инструментами та же модель отработала нормально.
• Вывод: инструментов было не слишком много для окна — слишком много для рассуждения. Пространство решения растёт быстрее, чем способность модели в нём выбирать. Для справки: 40+ определений инструментов — это ещё и около 10 000 токенов до начала работы.

Тот же вывод с другой стороны даёт Carly Richmond из Elastic: в их Elastic Agent Builder агенту выдают 5 инструментов из 24 возможных — и по соображениям безопасности, и чтобы не сбивать с толку. Чем больше инструментов, тем чаще модель выбирает не тот.

Противоречия. Emre, solution architect OpenAI, на Build Hour показывал их в чистом виде: системный промпт говорит «никогда не возвращаю деньги при неактивной гарантии», результат инструмента говорит «VIP-клиентам возврат положен», агент выдаёт полный возврат. Там же он демонстрирует context burst — turn 2 занимает 300–400 токенов, turn 3 после единственного вызова get_refund перепрыгивает за 3000. Отдельно Emre перечисляет источники poisoning, и список неприятный: лоссовая суммаризация, свободноформатная накапливающаяся заметка, старый summary, перетирающий новый. То есть отравление заходит через собственный механизм сжатия — к этому мы вернёмся во втором разделе.

Мусор от поиска. Leonie Monigatti из Elastic отмечает механику, которую легко проглядеть: агент неплохо отсеивает нерелевантную выдачу поиска в моменте — рассуждает над ней и отбрасывает, — но сами результаты остаются лежать в окне. В длинных сессиях накопленный отсев начинает сбивать агента.

Почему «подождём окно побольше» не работает

Dan Biderman, сооснователь Engram (ранее Mosaic, лаборатория Chris Ré в Стэнфорде), в разговоре на Latent Space формулирует это так: можно скормить модели N токенов и не получить ошибки — но это не значит, что она способна рассуждать о них холистически. Все вопросы continual learning и памяти он считает «вопросами длинного контекста в маскировке» и прямо говорит, что эффект деградации сохранится и на окне в 10 миллионов токенов. Если бы окно было бесконечным, ограничением осталась бы порча контекста.

У длинного окна есть и физическая цена. Самая конкретная системная цифра во всём материале — оттуда же, от Biderman: Llama-70B, одна статья Википедии (десятки килобайт текста) разворачивается примерно в 80 ГБ KV-состояния в памяти GPU — при том что все параметры модели в bf16 занимают около 140 ГБ. Состояние от одного документа сопоставимо с самой моделью. Отсюда, кстати, растёт их идея «убить prefill»: перенести работу в обучение заранее и загружать готовое состояние.

К этому добавляется простая экономика. Разбор The Working Thesis напоминает, что LLM — «мозг в банке» без состояния: харнесс пересылает весь транскрипт на каждом ходу, и на 50-м круге ты заново отправляешь 49 предыдущих — 50 000 токенов на каждом круге, помноженные на десятки кругов. Manus, по пересказу Marina Wyss, добавляет ценовую сторону: для Claude Sonnet кешированные входные токены стоят 30 центов за миллион против $3 за некешированные — разница в десять раз, а агент делает 30–40 API-вызовов на задачу. Любая правка ранней части контекста инвалидирует кеш и заставляет пересчитать всё.

И даже без денег есть налог на качество: тот же разбор The Working Thesis описывает ситуацию, когда старое сообщение об ошибке всё ещё лежит в транскрипте — и модель принимается чинить баг, починенный тридцать кругов назад.

Окно занято ещё до твоего первого слова

Про это забывают чаще всего. Ragunath Jawahar приводит полную опись «пустого» окна кодинг-агента: системный промпт агента, определения всех встроенных инструментов (имя, описание, параметры), метаданные окружения, AGENTS.md/CLAUDE.md/правила курсора, подключённые MCP-серверы, описания skills, memory и preferences, описания сабагентов. По его оценке, только системный промпт плюс определения инструментов — это 10–50k токенов в зависимости от конфигурации MCP.

IndyDevDan измерял это на своей конфигурации: 24,1k токенов на MCP-инструменты — 12% всего окна Opus; узкий конфиг только с Firecrawl обходится в 6k, экономия около 20k на старте. Отдельно у него CLAUDE.md на 23 000 токенов съедал ~10% окна; после урезания до 43 строк файл стал весить ~350 токенов, и на старте свободно 92% окна. Aghammadzada из DataRobot называет ещё более грубую цифру для тяжёлых конфигураций: 15 MCP-серверов — это больше 100 000 токенов за сессию только в определениях инструментов.

Сложите это с порогом «40% — потолок умной зоны», и получится главный практический вывод: при жирной конфигурации разговор стартует уже из тупой зоны, до первого сообщения пользователя. Пользователю этот расход не виден.

Контекст — бюджет, а не свалка

Sally-Ann Delucia из Arize по итогам года разработки формулирует смещение стека: агенты падают не из-за промптов, а из-за контекста; context management — это не «что влезло в окно», а стратегический выбор того, что модель увидит. Aghammadzada говорит то же экономическим языком: контекст — ограниченный ресурс с бюджетом, и каждый нерелевантный файл, лишний веб-поиск или старое сообщение об ошибке отнимает у агента reasoning power.

Полезно, что у бюджета есть приоритет расходов. HumanLayer оптимизируют контекст по четырём осям — correctness, completeness, size, trajectory, — и если их инвертировать, получится иерархия вреда: хуже всего неверная информация, затем отсутствующая, и только на третьем месте лишний шум. Практически это значит: чистку начинают с неправды, а не с объёма. Про четвёртую ось, trajectory, авторы честно говорят, что она «пока чисто на вайбах» — измерять не научились.

И сразу противоположный голос, чтобы не выпрямлять картину. Ian Gotts из экосистемы Salesforce, признавая context rot, утверждает по своей практике обратное: «мы все даём агентам слишком мало контекста, и поэтому у нас проблемы». Противоречие он снимает приоритизацией слоёв — много правил и контекста процесса, мало сырых данных. Методики измерить «достаточно» он не даёт, и это честно отражает состояние дел: направление ясно, метрики нет.

Что с этим делать

Считай стартовый оверхед до релиза. Открой пустую сессию и посмотри разбивку окна (в Claude Code это /context): системный промпт, инструменты, memory-файлы, MCP, skills. Если до первого сообщения занято больше трети — сокращай конфигурацию, а не модель.

Держи утилизацию в первой трети окна. Ориентир HumanLayer — до 40%, у DataRobot планка ещё ниже. Когда подходишь к границе, не «дожимай» сессию, а фиксируй результат в артефакт и открывай новое окно.

Ревизуй набор инструментов по количеству, а не по объёму. Кейс GeoEngine показывает, что вред начинается при свободном окне. Отключи MCP-серверы, которыми не пользуешься; для конкретной задачи запускай агента с узким конфигом (--mcp-config, --strict-mcp-config).

Ставь важное на края окна. Стабильные инструкции — вверх, актуальное состояние — вниз. Всё, что упало в середину под слоем tool-выводов, считай недоступным, даже если формально оно в контексте.

Чисти сначала неправду, потом объём. Устаревшая ошибка, отменённое решение, неверный ответ, лежащий рядом с исправленным, — вреднее, чем сотня лишних токенов. Если в треде застряла галлюцинация или удалённый кусок кода, который агент воскрешает, тред не спасают — его пересобирают.

Заведи метрику «шагов до деградации». Считай, на каком ходу агент начинает вызывать бессмысленные инструменты. Это дешёвый ранний сигнал: он ловит проблему до того, как о ней сообщат пользователи.

Компакция: что выживает и что тихо исчезает

Компакция — ответ индустрии на всё, что описано в первом разделе: раз окно кончается и портится, старую историю периодически сворачивают в сводку. Механизм рабочий и почти везде включён по умолчанию. Проблема в том, что решение «что безопасно забыть» принимает софт, а не ты, и об ошибке ты узнаёшь не из стектрейса.

Как устроена авто-компакция

Lance Martin из LangChain описывает базовый случай: Claude Code вызывает авто-компакцию при заполнении окна на 95% (200 000 токенов для Claude) — это суммаризация всей траектории. Ragunath Jawahar на Developer Summit подтверждает тот же порядок и оговаривается: практики чистят контекст, не дожидаясь автосрабатывания, — но эвристика «когда чистить» исследованием не подкреплена, это ощущение практиков.

Пороги у других реализаций заметно ниже. Emre из OpenAI на Build Hour формулирует три правила запуска сжатия. Первое: собирать снапшоты контекста из прода и из дизлайков, чтобы знать типичный размер контекста в сессии. Второе: не резать в середине хода — turn определяется как сообщение пользователя и всё, что произошло до следующего сообщения пользователя; разрез внутри хода резко повышает вероятность «потери нити». Третье: не ждать удара в лимит, ставить пороги на 40% или 80% заполнения. Демо-параметры конкретные и мелкие: у trimming — max turns 3, keep recent 3; у компакции — trigger 4, keep recent 2.

Разбор архитектуры агента Hermes (Hugging Face и Alejandro AO) даёт третий набор цифр: при установке агент спрашивает, на каком проценте заполнения запускать компакцию, по умолчанию — 50%, а для моделей с маленьким окном рекомендуют 70–80%. Там же две детали, которые стоит скопировать. Проверка размера контекста делается дважды: перед каждым обращением к модели и повторно на ошибке, когда провайдер вернул превышение окна, — второй путь страхует от неточной оценки. А сама оценка до первого вызова делается грубо: общее число символов делится на 4 — настоящий токенайзер гонять дорого, а для срабатывания порога точность не нужна. После первого ответа переключаются на поле usage из ответа провайдера и просто суммируют; форматы usage у провайдеров при этом различаются.

Отдельно стоит различать инструменты: David Mahler в разборе Claude Code разводит /compact с подсказкой («focus on the current working state of the lab») — ручную компакцию на чекпойнте, не дожидаясь авто, — и /clear, то есть новую сессию с обнулённой историей, правильный ход при смене темы.

Что именно сохраняют

Root Cause в разборе по документации Anthropic описывает механику так: всю историю отдают модели, сжимают в сводку и переинициализируют окно этой сводкой плюс 5 последних использованных файлов — остальное стёрто. Выживать должны архитектурные решения, нерешённые баги и детали реализации; уходить — повторяющиеся tool-выводы и сырые результаты из глубины истории.

Разбор The Working Thesis добавляет коэффициент и принцип. Коэффициент: история на 50 000 токенов сжимается до 1–2 тысяч. Принцип: хороший харнесс не просит «сделай пересказ», а использует специальный системный промпт компакции, который сохраняет решения, а не сырые входы, приведшие к ним — «решили игнорировать type warnings в legacy-модуле» вместо текста самого предупреждения. И сверху — гибрид, который стал дефолтом: харнесс почти никогда не компактит всю историю, последние 5–10 ходов остаются дословными. Marina Wyss описывает тот же паттерн в других числах (последние ~10 сообщений дословно, старше — в running summary), а учебный агент Google Cloud — в третьих (5 последних находок сырыми, старше — в 3 строки, режим прямо назван «loss-aware»).

Второй, более узкий рычаг — context editing. Это автоматическая чистка старых результатов tool-вызовов при переходе порога токенов, старые первыми; по умолчанию нетронутыми остаются 3 последних tool call. Цифры Anthropic по нему выглядят убедительно: context editing сам по себе срезает потребление токенов на 84% и позволяет доводить до конца сценарии, которые иначе упёрлись бы в лимит; связка memory tool + context editing даёт +39% к производительности относительно baseline на 100-ходовом web-search прогоне, из которых 29 пунктов приходится на сам context editing. Оговорка обязательна: это вендорские цифры на одном бенчмарке.

Официальную позицию Anthropic Root Cause цитирует как recall-first, precision-second: сначала максимизировать полноту сводки и только убедившись, что ничего важного не теряется, ужимать в сторону точности. Там же прямое признание: слишком агрессивная компакция ведёт к потере тонкого, но критичного контекста, важность которого выясняется позже. Полнота при этом оплачивается токенами — команда ежедневно выбирает точку на кривой «цена сводки против полноты». Dan Biderman из Engram добавляет структурное возражение: компакция бинарна — токен либо сохраняется, либо выбрасывается, промежуточных степеней нет, и на длинном горизонте это даёт забывчивость глубоко в сессии. Оговорка: это позиция вендора, продающего альтернативу, проверяемых цифр в интервью нет.

Есть и скрытая статья расходов: компакция выбрасывает prompt cache — так же бесшумно, без ошибки, просто счёт после неё выше. В Claude Code, по наблюдению Arize, много усилий вложено именно в то, чтобы компакция не инвалидировала кэш.

Что исчезает молча

Всё вышеперечисленное — про то, что компакция теряет по замыслу. Хуже, когда она теряет то, что терять не должна.

Что произошло: правило, пережившее 50 ходов, умерло в сводке

• Кто: GitHub issue 24460 против Claude Code, разобранный в материале Root Cause.
• Что делали: обычная длинная сессия с файлом проектных инструкций CLAUDE.md — конвенции коммитов, процедуры пуша, правила безопасности, нейминг. Правило «никогда не пушить в main» держалось 40–50 ходов.
• Результат: сработала компакция — и следующим ходом агент запушил в main. Суммаризатор воспринял содержимое файла правил как обычную историю разговора и проредил наравне с болтовнёй. Ошибки нет, стектрейса нет, агент не колеблется.
• Вывод: правило не «ослабло» — оно исчезло, и единственный сигнал об этом был в виде последствий. Обходной путь репортера — после каждого compact вручную просить агента перечитать CLAUDE.md — работает, пока кто-нибудь не забудет. Предложенный фикс: считать файл правил постоянным инвариантом, а не историей.

Здесь важно показать, что источники по этому вопросу прямо противоречат друг другу. David Mahler в своём разборе Claude Code утверждает, что memory-файлы (CLAUDE.md и авто-память) после компакции сохраняются, — и именно поэтому их надо держать в порядке. Root Cause документирует баг, где содержимое CLAUDE.md после /compact фактически терялось. Скорее всего, речь о расхождении версий или конфигураций, и не исключено, что оба правы для своей сборки. Но вывод из этой пары не зависит от того, кто прав: гарантия по описанию и гарантия по проверке — разные вещи. Документация говорит, что правило переживает компакцию; лог говорит, что в конкретной сессии оно не пережило. Верить надо логу.

Отсюда следует дешёвый и обязательный тест, который формулирует Root Cause: прогони сессию хотя бы один раз за реальную точку компакции и проверь, держится ли правило на следующем ходу. Не считать, что держится, только потому что держалось раньше. Это тест-кейс, а не вопрос веры.

Второй канал тихой потери — сам summary. Emre из OpenAI называет источники poisoning, и все три лежат внутри механизма сжатия: лоссовая суммаризация, свободноформатная накапливающаяся заметка и старый summary, перетирающий новый. Лекарство — три инструкции-предохранителя в summary-промпте: остерегайся противоречий, соблюдай временной порядок, контролируй галлюцинации. Дальше — доменная схема сводки: продукт и окружение, заявленные проблемы, что сработало и что нет, идентификаторы, временные вехи, текущий статус и следующие шаги. Hermes решает ту же задачу списком секций в context_compressor.py: цель, ограничения, выполненные действия, активное состояние, на чём агент заблокирован, ключевые решения, релевантные файлы, критический контекст, следующие ходы. Разница подходов не в идее, а в цене: авторы Hermes сами отмечают, что их промпт менее минималистичен — богаче и дороже.

Что отвергли в Arize и к чему пришли

Самая полезная часть материала — не рецепт, а два задокументированных провала. Sally-Ann Delucia рассказывала про агента Alex, который анализирует трейсы их же observability-платформы: спаны растут → упираются в лимит контекста → агент падает → повтор с ещё большим объёмом → снова падение. Система, анализирующая данные, была ограничена этими же данными.

Первая попытка — наивная truncation: брать первые 100 символов блоба и выбрасывать остальное. Работало для простых случаев, пока не перестало: агент забывал всё, и follow-up выглядел как новый разговор — на «расскажи подробнее про input B» он просто не понимал, о чём речь. Подход убивал связность диалога и был отброшен.

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

Рабочая схема получилась гибридной и намеренно тупой: берут первые 100 символов и последние 100, середину вырезают и складывают в memory store, откуда агент в любой момент может достать её сам. Плюс: дубликаты сообщений схлопывают, из длинных tool call оставляют только последний результат, системный промпт не сбрасывают никогда. Схема не менялась несколько месяцев. Формула автора: контекст — это то, что модель видит, а память решает, что выживает. Сами они признают, что это эвристика: принципиального контекстного бюджета и метрик качества контекста у них нет. Отдельная деталь: разобрав код Claude Code, они ожидали найти магию, а обнаружили похожую комбинацию truncation + compression.

Крайняя позиция по компакции — у Dex Horthy из HumanLayer: «/compact — мусор, я им никогда не пользуюсь». Вместо автосжатия агента заставляют записать progress-файл на диск, и этим файлом онбордят следующего агента в новом окне. Работа разбита на фазы, каждая заканчивается компактным markdown-артефактом, каждая следующая стартует с чистого окна, где лежит только он: research (суб-агенты читают код, их мусор остаётся у них, на выходе — файл с путями, сигнатурами и подводными камнями) → сброс контекста → planning (здесь же человеческое ревью) → implementation (только план и progress.md). Числа: сырой research съедает 60–80% окна, артефакт сжимает это до 15–20%. Про заявленные «35 000 строк кода за одну 7-часовую сессию» — подано как «reportedly», то есть маркетинговое заявление, а не измерение.

И бытовое наблюдение: Jono Catliff отмечает, что если после компакта осталось 2–3% свободного окна, каждое следующее сообщение вызывает рекомпакцию — тогда дешевле /clear или новая вкладка. Компакт не спасает переполненную сессию, он её только продлевает. Порядок величины, не измерение.

Что с этим делать

Не отдавай выбор порога умолчанию. 95% Claude Code — страховочная сетка, а не стратегия. Ставь свой порог (40/80% у OpenAI, 50% у Hermes) и режь на границе хода, а не в его середине.

Пиши схему сводки, а не «суммаризируй это». Списки секций у OpenAI и Hermes копируются целиком; сохранять надо решения, а не сырые входы. И добавь в промпт защиты от противоречий, нарушения временного порядка и галлюцинаций: без них summary сам становится каналом отравления.

Проверь компакцию тестом, а не по документации. Прогони сессию за реальную точку компакции и посмотри, держится ли правило на следующем ходу. Источники расходятся в том, переживают ли memory-файлы сжатие, — значит, у тебя это открытый вопрос до первой проверки.

Начинай с самого дешёвого рычага — с tool-выводов. Context editing с сохранением последних 3 вызовов и очистка сырых результатов из глубины истории дают больше всего экономии при наименьшем риске.

Оставляй хвост дословным. 5–10 последних ходов без сжатия — рабочий дефолт. Наивная обрезка без такого хвоста ломает связность диалога — это ровно то, на чём споткнулись в Arize.

Планируй компакцию, а не переживай её. Фиксируй результат фазы в артефакт на диске и стартуй следующую с чистого окна. И следи за побочным эффектом: компакция бесшумно инвалидирует prompt cache, счёт после неё будет выше.

Retrieval: подгружать по требованию, а не грузить заранее

На всех схемах RAG-систем есть стрелка «context sources → context window». Leonie Monigatti из Elastic в докладе «Agentic Search for Context Engineering» замечает, что эту стрелку рисуют все, а обсуждает почти никто: за ней прячется набор поисковых инструментов, и именно он решает, что окажется в окне. Её оценка — «context engineering это на 80% agentic search» — это hot take, а не измерение, но рамка рабочая: если ты не спроектировал поиск, ты не спроектировал контекст.

Сдвиг последних месяцев в том, что решение «что искать» переехало от системы к агенту. Marina Wyss формулирует водораздел так: в классическом RAG пайплайн статичен — пришёл вопрос, достали документы, положили в промпт, модель в отборе не участвует. В agentic RAG агент сам решает, что искать, каким инструментом и когда информации достаточно. Разница не идеологическая: в многошаговой задаче релевантность меняется на каждом шаге, и заранее собранный пакет документов протухает уже ко второму ходу.

Три режима отказа

Monigatti перечисляет три способа сломать агентный поиск. Первый — агент вообще не вызывает инструмент: решает, что знает ответ из параметрической памяти. Второй — вызывает не тот инструмент; она приводит кейс коллеги, где самым сложным в проекте оказалось заставить агента ходить в базу знаний, а не в web search. Третий — вызывает нужный инструмент с неверными параметрами.

Третий режим она раскладывает по сложности: get_customer_by_id с одним валидным ID — легко; semantic search со строкой — легко; добавь фильтры и top-K — сложнее; заставь написать полный ESQL/SQL-запрос с нуля — «большинство справляется, некоторые нет». Отсюда прямое проектное следствие: чем слабее модель, тем более специализированные инструменты ей нужны. Более мощная модель, по её словам, «очень сильно» снижает error rate на параметрах, но не гарантирует их отсутствия.

Semantic search проваливается на глазах

Дальше в докладе идут два живых провала, и они полезнее любой теории.

Что произошло: поиск не нашёл то, что лежало в базе

• Кто: Leonie Monigatti, Elastic — живое демо на данных расписания конференции.
• Что делали: сначала semantic search с жёстким top_k=3 по запросу «GAIA», потом general-purpose инструмент, которому агент сам пишет ESQL-запрос.
• Результат: семантический поиск вернул доклад про модели Gemma (близко токенизационно), доклад про harness engineering и третий нерелевантный — 0 из 3 попаданий при том, что нужный доклад в базе был. Агент с ESQL написал валидно выглядящий запрос с %GAIA%, но в ESQL wildcard — это *, а не % (привычка из SQL). Синтаксической ошибки нет, результатов — ноль. Починил ситуацию крошечный custom skill по ESQL: frontmatter инжектится в системный промпт, тело подгружается при обращении, внутри — структура запроса и правила про кавычки и wildcard. После этого корректный запрос с первой попытки.
• Вывод: semantic search бесполезен для точных ключей и не фильтрует по метаданным, если те не эмбеддятся (день, зал, спикер — это фильтры, а не смысл). А главный проектный вопрос звучит так: «0 результатов» — это валидный ответ или failure mode? Агент сам этого не различает.

Это не изолированный случай. Lance Martin (LangChain), пересказывая пост CEO Windsurf, приводит ту же мысль про код-агентов: «pure embedding based search становится ненадёжным», поэтому у них комбинация grep/file search, knowledge graph и LLM-реранкинга поверх, а чанкование идёт по семантически осмысленным границам кода.

Отсюда принцип, который Monigatti называет low floor / high ceiling. Нужны и специализированные инструменты (low floor: агент пользуется из коробки, редко ошибается, одна итерация), и general-purpose (high ceiling: вытягивает неожиданные запросы, но требует больше итераций). «Искать одну серебряную пулю — неправильный путь». В Q&A она ссылается на эксперимент Vercel «testing if bash is all you need»: DB-инструмент эффективнее на аналитике, file search быстрее для «просто найти», а наивысшую точность дал гибрид — сначала запрос к БД, потом верификация через shell. Google Cloud говорит то же: на «грязных» логах гибридный поиск часто выигрывает у чистых эмбеддингов.

Отбор инструментов — это тоже retrieval

Легко забыть, что определения тулов лежат в том же окне, что и документы. Статья RAG-MCP (2025), на которую ссылаются и Marina Wyss, и Carly Richmond из Elastic, предлагает делать семантический поиск по описаниям инструментов и подгружать только релевантные текущему шагу. Цифры: точность выбора инструмента выросла с 14% до 43% при сокращении prompt-токенов примерно вдвое (в изложении Elastic — «более чем на 50%»). Тот же приём реализован в langgraph-bigtool у LangChain. Оговорка честная: нужно, когда инструментов десятки; при пяти-десяти избыточно.

Ручной вариант дешевле и работает сразу. Carly Richmond показывает пример из Elastic Agent Builder, где агенту выдано 5 инструментов из 24 доступных — и по безопасности, и чтобы не путать модель: чем шире пространство решения, тем чаще выбирается не тот tool.

Третья ручка — время жизни накопленного. В её же демо долгой памяти счётчик показывал 30 сообщений в индексе; temporal pruning (удалить всё старше двух недель) срезал 15, оставив 15 — ровно вдвое. Смысл не в экономии места: устаревшие записи возвращаются в выдачу и отравляют контекст.

И четвёртая, самая неприятная. В том же демо Richmond заглянула в индекс и обнаружила, что система раз за разом сохраняла и возвращала один и тот же итинерарий — по одному признаку нашлось 12 совпадений. Без дедупликации автоматическая память сама себя усиливает: агент видит одно и то же в двенадцати экземплярах и считает это подтверждением. Рядом лежит забываемая ручка размера выдачи: в демо стоял size=20, и автор тут же себя поправила — «возможно, стоит вернуть один-два».

Что грузить заранее, а что по требованию

Практика Anthropic в Claude Code, как её пересказывает Marina Wyss, — гибрид: claude.md грузится вперёд, в начале каждой сессии, а навигация по кодовой базе идёт по требованию через glob и grep. Кодовая база не индексируется заранее, агент исследует её по мере надобности. Общая философия — «делать самое простое, что работает».

Тот же принцип в терминах DataRobot: в контекст загружаются только метаданные skills, и работают они как индекс в базе данных — агент по ним находит нужное, а тело подгружает при обращении. Их оценка — «минимум в десять раз меньше» операционного объёма, чем при прямом подключении MCP.

Бытовой замер того же эффекта есть у Jono Catliff: транскрипт на 3001 строку, вставленный сообщением в чат, съел 71% окна; тот же материал, сохранённый файлом и прочитанный агентом по пути, — 38%. Замер без методологии, брать как порядок величины, но направление верное: ссылка на файл дешевле содержимого файла. Промышленный вариант той же идеи предлагает Ian Gotts — держать контекст во внешней базе (граф или онтология) и поднять над ней MCP-сервер; он же оговаривает, что устоявшихся best practices здесь пока нет ни у кого.

Честная граница: холистические запросы RAG не берёт

Это место, где принято обещать больше, чем система может.

Dan Biderman (Engram), опираясь на работу с юридическими файловыми системами Harvey, приводит запрос: «какие M&A-сделки мы в этом году не закрыли?» Ответа нет ни в одном чанке — нигде не написано «не завершено». Надо пройти клиентское дело за делом, снять суть и понять, что петля не закрыта. Поиск по сходству к таким вопросам неприменим по конструкции: он ищет то, что есть, а не то, чего нет. По его словам, на фронтир-моделях с компакцией такой запрос обходится в тысячи долларов за один прогон — при том что любой сотрудник ответил бы сам.

Zach Blumenfeld (Neo4j) называет тот же класс estate-level: «какой документации у нас нет», «что мы вообще не используем», «какие паттерны повторяются по всему корпусу». Такие вопросы требуют обхода всего датасета, а каждый дополнительный векторный хит — ещё один шанс промахнуться мимо нужного документа. Он же честно говорит, что граф здесь не замена семантическому поиску, а дополнение.

Есть и менее очевидный отказ. Nyah Macklin (Neo4j) разбирает случай, где retrieval сработал безупречно: комплаенс-агент вытащил три верных чанка — «Jessica работает в Apex Global», «Apex Global в санкционном списке», «Jessica просит увеличение кредитной линии на $25 000». Все три лежали в окне одновременно. Агент одобрил. Данные верные, поиск верный, а связь между фактами нигде не была представлена. Её формулировка: лучшие модели не чинят раздробленный контекст, они просто рассуждают над обломками. Отсюда тезис о второй, незастроенной оси: текущий retrieval работает по текстовому сходству, которое даёт, по её оценке, «70–80% пути»; вторая ось — структурное сходство. Ей посвящён следующий раздел.

Практика: индексы, префильтры, детерминированная загрузка

Инженерный минимум описывает Carly Richmond: чанкование, эмбеддинги, векторная БД, приближённый kNN — в её примере HNSW с параметром num_candidates на шард. На миллионах векторов запрос становится долгим, отсюда prefiltering: сузить пространство лексическим или атрибутным фильтром до векторного сравнения — например, взять только записи за последнюю неделю. Чаще всего это самый дешёвый прирост точности. Она же призывает не бояться lexical: в собственном инструменте get_flights она сознательно использует лексический поиск, потому что пункты отправления и назначения нужны точные. Поверх выдачи ставится re-ranking — отдельный класс моделей, переоценивающих документы по своим признакам; Qwen, Jina, mixedbread лежат публично на Hugging Face.

Векторного стека можно и не поднимать. Zach Blumenfeld построил рабочую систему вообще без него: Lucene-индекс ставится только на ноды с текстом (документы и секции, папки не индексируются), каждому узлу выдаётся иерархический URI вида technical-library/bulletins/<doc>/<section>, и поиск скоупится пост-фильтром WHERE uri STARTS WITH ... — «искать только внутри раздела recalls». Вместо эмбеддингов — semantic expansion: модель расширяет запрос своим знанием мира («engine shuttering» → искать также «misfire» и «rough idle») и скармливает это Lucene как OR-запрос. Мотив прагматичный: он работает с шестью вендорами векторных БД и не хочет привязки. Оговорки он тоже называет: пост-фильтр — не пре-фильтр, и выигрыш меньше на плохо озаглавленных данных.

Загрузка документов у него детерминированная, без LLM: containment-дерево library → folder → document → section, NEXT_SECTION для порядка, LINKS_TO для перекрёстных ссылок, парсинг обычным regex/NLP. Отдача — идемпотентность: «если граф завтра исчезнет, а документы не менялись, перезальёшь и получишь ровно тот же граф». Работает потому, что исходные PDF и markdown уже структурированы; на грязных источниках понадобится LLM-парсинг. Ловушка — переименование документа: чужие ссылки на его URI протухают, и связи надо чинить руками.

Что с этим делать

Начни с описаний инструментов, а не с векторной БД. Структура «core purpose → trigger conditions (когда использовать и когда НЕ использовать) → relationships» по Monigatti стоит ноль и снимает часть промахов выбора тула.

Сократи набор инструментов до необходимого. 5 из 24, как в примере Elastic Agent Builder, — не экономия токенов, а сужение пространства ошибки. Если инструментов десятки, ставь семантический поиск по их описаниям (RAG-MCP: 14% → 43% при вдвое меньших токенах).

Заведи префильтр раньше, чем реранкер. Отсечь по дате, типу, владельцу до векторного сравнения дешевле, чем переранжировать мусор. И не стесняйся лексического поиска там, где нужны точные значения.

Обслуживай индекс как код. Дедупликация (12 одинаковых записей — реальный дефект, а не гипотеза), temporal pruning старше N недель, явный лимит выдачи (size=20 почти всегда больше, чем нужно).

Грузи файлы по пути, а не содержимым. Тела skills и документов подтягивай при обращении, а в стартовый контекст клади только индекс.

Определи заранее, что твоя система не умеет. Возьми один холистический вопрос из своего домена («какие сделки мы не закрыли») и проверь на нём retrieval. Если он не отвечает — это должно быть зафиксировано как известная граница, а не обнаружено пользователем.

Структура вместо токенов: графы, онтологии и источники истины

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

Контекст приходит формами, а не запросами

Zach Blumenfeld из Neo4j в докладе «AI on Your Lakehouse» формулирует тезис, который стоит выписать отдельно: контекст приходит формами (shapes), а не запросами. Вместо «дадим агенту text-to-SQL и vector search» ему дают три готовые формы представления данных: connections — граф-семантический слой поверх warehouse, объясняющий, как джойнить таблицы; table of contents — дерево документов со ссылками для навигации; themes — кластеры документов, вскрывающие глобальные паттерны. Каждая форма — отдельный скрипт-инструмент внутри одного skill.

Ключевое инженерное решение там же: в граф уезжают только метаданные. Проект Neo Carta (Neo4j Labs) поднимает MCP-сервер, который тянет из BigQuery схему и строит граф database → schema → HAS_TABLE → table → column, опционально с репрезентативными значениями и явными join-путями (источник — information_schema, но можно кормить query logs или задавать джойны руками). В демо это 6 таблиц и 5 reference join paths, загрузка идемпотентна. Агент читает граф и пишет корректный text-to-SQL. ETL самих данных не происходит.

Причин отказа от ETL Blumenfeld называет три, и третья интереснее первых двух. Объём — терабайты, непрерывно обновляемые, придётся строить синхронизацию. Кастомность — часть свойств в граф не нужна, часть нужна иначе. И security posture: данные физически перенести можно, а по требованиям безопасности нельзя — обычная ситуация в регулируемом контуре, отсекающая целый класс архитектур ещё до обсуждения качества. ETL, по его словам, оправдан только когда нужны сами графовые вычисления: рекурсивные джоины с требованием по латентности, graph embeddings, кластеризация.

Полезно и его различение перегруженных терминов: онтология помогает системе интерпретировать данные и рассуждать о них, semantic layer фиксирует согласованные термины, чтобы система корректно их запрашивала.

A/B на одних данных: вектора против графа

Stephen Chin (Neo4j) в докладе «CrabRAG» показал сравнение, которое редко делают честно: из одних и тех же markdown-файлов построены два хранилища — векторное (PGVector / LanceDB) и графовое (Cognee поверх Neo4j). Графовый поиск гибридный: вектора дают seed-ноды, дальше обход на один хоп и ранжирование по связности, в контекст попадает только выигравшее подмножество.

Метрик он не привёл — сравнение качественное, на двух вопросах. «Что на WAN с EOL-софтом»: векторный ответ — «не удалось найти конкретики, уточните»; графовый — конкретное имя хоста и устаревшая версия ОС. «Какие management-порты слушают на 0.0.0.0»: векторный — «сходи проверь конфигурацию сам»; графовый нашёл HAProxy и OpenVPN, пройдя от ноды роутера pfSense по связям. Демо на трёх-четырёх машинах домашней лаборатории, а заявка — на дата-центры и финансовые данные; разрыв в масштабе оценивай сам.

Его же аргумент про стоимость файловой памяти: в типовой раскладке (AGENTS.md, файлы памяти, файлы инструментов, дневные файлы) всё это просто markdown — читаемо, легко компактится руками, но агенты грузят «всё подряд в надежде, что что-то пригодится», очень репетитивно. Его замер: «мои агенты грузят как минимум 100k токенов на каждый раунд». Это оценка практика, а не измерение с методологией, — бери как порядок величины. Важнее порог: на малом масштабе с сильной моделью markdown работает, а «когда объём не влезает в миллионное окно современных моделей, markdown-файлов уже недостаточно». Ниже этого порога структура не окупается — честная граница в обе стороны.

Отдельное свойство графа, которое обычно недооценивают: он объясним и аудируем. Видно возвращённый подграф и то, какая его часть дала ответ. Если ответ неверен, ты чинишь extraction или схлопываешь дубликаты нод, а не «крутишь промпт». Для регулируемых доменов это сильнее любого прироста качества.

Единственная проверяемая цифра

Самое ценное измерение приводит Nyah Macklin (Neo4j), ссылаясь на работу Jiang et al. по модели ComGPT для телекома (IEEE Communications Magazine, март 2026). Ablation на QA по стандартам 3GPP: базовая модель — 37%, дообучение на доменных данных — 54%, связка knowledge graph + RAG вместе — 91% точности.

Читать это надо аккуратно. Разрыв закрыл не граф сам по себе и не RAG сам по себе, а их сочетание — что согласуется с тезисом про две оси сходства. Домен узкий (телеком-стандарты), и сама спикер настаивает читать первоисточник, а не верить цифре на слайде. Но это единственная воспроизводимая цифра в пользу графового слоя, и она измерена на ablation, а не на демо.

Онтология как рабочий инструмент, а не как академия

Слово «онтология» отпугивает, и зря — вопрос в масштабе. Ian Gotts (San Francisco Architect Community Group) даёт ориентиры: чтобы описать организацию и культуру — слой, который он считает самым важным и наименее оцифрованным, — нужно примерно 10 узлов и 20 рёбер. Полная карта всех слоёв контекста — 80–100 узлов и около 200 рёбер. Стартовая онтология измеряется десятками узлов, а не тысячами, и подъёмна для маленькой команды за один заход.

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

Второй способ не строить лишнего — не изобретать с нуля. Frank Coyle (UC Berkeley) напоминает, что за последние 15–20 лет наработаны готовые словари: schema.org, FOAF для соцсвязей, Dublin Core для публикаций; Wikipedia стоит на DBpedia. Способов построить собственную два: top-down (эксперты описывают домен) и bottom-up (вытягивать сущности и связи из реальных взаимодействий). Он же называет историческую границу прямо: экспертные системы 80-х не масштабировались, и это привело к AI winter; нынешняя связка «вероятностная модель плюс символьный слой» — попытка обойти ту же стену с другой стороны.

У онтологии есть и вторая роль — валидатор на выходе агентного цикла. Coyle вставляет в цикл (LLM → stop_reason == tool_use → выполнить tool) шаг, где результат приводится к форме, понятной ризонеру поверх доменной онтологии: разумно — идём дальше, нет — возвращаем в LLM или зовём человека. Его формула: «Pydantic на входе, онтология на леджере», и агенты по возможности без side effects — сначала прогнать через онтологию, потом менять состояние в БД. Ловятся вещи, которые тяжело поймать текстовыми правилами: повторный refund по тому же заказу; выплата на support desk вместо покупателя (через OWL disjoint — customer и support rep непересекающиеся классы); выдуманный статус «probably shipped» при перечислении допустимых paid / shipped / refunded. Реализуемо и в маленькой системе, если домен формализуем.

Иерархия источников истины

Ishita Daga, ML-инженер Tesla, в докладе «Enterprise Agents Have a Structure Problem» настаивает: агент не должен взвешивать все базы знаний одинаково. Источники истины ранжируются от самого чистого и наименее гибкого к самому грязному и гибкому:

1. semantic layer — курируемые определения KPI, метрик и бизнес-терминов;
2. canonical / parametric queries — набор готовых запросов, агент выбирает и докручивает фильтры;
3. database graph — таблицы, связанные с колонками и метриками; максимальная гибкость.

Отвечать надо начиная с чистейшего. Её цифра: первые два слоя закрывают примерно 80% задач, граф — оставшиеся 20. При этом database graph она называет «самым хитрым»: дорого строить, тяжело поддерживать — и рекомендует энтерпрайзам начинать с первых двух слоёв. Это прямой контраргумент желанию сразу строить граф.

Проблема, которая структурой не решается

Та же Ishita Daga называет три структурные причины провала enterprise-агента: ambiguity (агент не знает, какая таблица или база знаний — источник истины), staleness (определения KPI и процессы меняются быстрее, чем обновляются .md-файлы и skills) и preference — у каждой команды своё определение одной и той же метрики. Первые две лечатся описанным выше. Третью она прямо называет нерешённой проблемой индустрии.

И это честная позиция. Semantic layer фиксирует одно согласованное определение — но согласование и есть та работа, которую он не выполняет: если финансы и продажи считают «активного клиента» по-разному, слой лишь выбирает, чьё определение победит. Memory-файл не помогает по той же причине: он запоминает решение, а не примиряет стороны. Ian Gotts подходит с другой стороны: правила уровня организационной культуры нельзя закодировать как «если X, то Y» — нужен вывод из ситуации, и готовых решений он не видел. А Omri Bruchim и Tomer Ast из monday.com формулируют симптом: данные есть все, retrieval работает — не хватает понимания связей; на вопрос «на чём мне сфокусироваться прямо сейчас» агент угадывает. Их вывод стоит держать в голове: «memory» и «retrieval» — это не то же самое, что «understanding».

Граф как control plane, а не как справочник

Последний сдвиг — перестать думать о графе как об источнике фактов.

Что произошло: граф стал планом обхода, а не справочником

• Кто: Subbiah Sethuraman и Abhilash Asokan, ZS Associates (фарма-аналитика), доклад «Why We Killed Our Multi-Agent Pipeline».
• Что делали: до графа агенты выводили связи между метриками прямо из таблиц — это «не масштабировалось и часто выдавало связи, которых в данных не существует». Построили вручную, с доменными экспертами, граф сущностей: география → плательщик/аккаунт → бренд → KPI → вторичный и третичный KPI, с явными рёбрами «какой KPI драйвит какой», и зафиксировали, что такое TRX (число выписанных рецептов). Дальше граф стал задавать не факты, а допустимые пути обхода: каждое ребро — гипотеза. Цикл: взять сущность → посмотреть окрестность → достать гипотезы из рёбер → уйти в исходные данные и проверить числами → подтвердилось, идём дальше; нет — следующая гипотеза, до корневой причины.
• Результат: прогон занимает 50+ ходов; результат, на который у аналитика уходило 3–4 недели, получается за 20–30 минут.
• Вывод: ценность графа не в том, что он хранит правду, а в том, что он ограничивает пространство поиска и делает шаги проверяемыми. Цена входа соответствующая: доменная экспертиза и ручная работа над онтологией — это решение для крупной системы, а не для стартапа с одним Postgres.

Обратная сторона той же медали описана Emil Eifrem (Neo4j) как четыре проблемы «толстых агентов» без общего слоя: каждая команда заново ищет, где лежат данные; данные дублированы, и надо решать, какая копия правильная; нарушается DRY — изменение разносится руками по всем агентам; нет обучения, потому что связка «намерение → источник» зашита в код и промпты. Это позиция вендора графовой БД, но список проверяется самостоятельно.

Что с этим делать

Начинай с semantic layer и канонических запросов, а не с графа. По оценке Tesla, эти два слоя закрывают около 80% задач; граф — ответ на оставшиеся 20%, и только когда они реально болят.

Держи метаданные отдельно от данных. Схема, join-пути и определения — самостоятельный артефакт для агента; тащить сами данные в новое хранилище часто невозможно по security posture, а не по инженерным причинам.

Стартовая онтология — это десятки узлов. Ориентир Ian Gotts: 10 узлов и 20 рёбер на организацию и культуру, 80–100 узлов на полную карту. Бери готовые словари (schema.org, Dublin Core, FOAF) и расширяй по фактическим ошибкам агента.

Сделай онтологию исполняемой. Даже маленький валидатор на выходе цикла — перечисление допустимых статусов, непересекающиеся классы получателей выплат, запрет повторной операции по заказу — ловит ошибки, которые текстовыми правилами не поймать.

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

Согласование определений метрик планируй как организационную работу, а не как задачу платформы. Ни semantic layer, ни memory-файл не примиряют две команды, считающие метрику по-разному. Зафиксируй владельца определения явно.

Память: что записывать, что обновлять, что забывать

Память агента — это не «хранилище, куда всё складывается». Это решение о том, какая информация переживёт конец сессии, в какой форме и по какому правилу она устареет. Инструменты вторичны: Richmond Alake из MongoDB прямо говорит, что «нет одного способа решить память», у каждой команды выходит своя схема. Дальше — про то, что здесь уже измерено, а что остаётся открытым.

Четыре типа памяти — и зачем их различать

Рабочая рамка, на которую сходятся почти все источники, — CoALA (Cognitive Architectures for Language Agents, Принстон), в изложении IBM Technology: working (само окно контекста), semantic (факты, знания, конвенции), procedural (как делать — skills, файлы правил), episodic (что случалось в прошлых сессиях и чему агент научился). Lance Martin из LangChain даёт ту же тройку с привязкой к реализации: семантическая — факты, эпизодическая ложится на few-shot примеры, процедурная — на rules-файлы вроде CLAUDE.md, и она обычно грузится целиком при старте, а факты подтягиваются выборочно.

Различать их нужно ради одного практического вывода, который IBM формулирует напрямую: не каждому агенту нужны все четыре. Рефлекторному агенту (термостат, роутинг-бот) хватает working. Узкому саппорт-агенту, который сбрасывает пароли, — working плюс procedural. Все четыре нужны кодинг-агенту. Это дешёвый критерий «не строить лишнего».

Второе наблюдение IBM снимает половину инфраструктурных фантазий: академическая литература описывает semantic memory как векторные БД и графы знаний, «но в большинстве продакшн-систем сегодня это просто .md-файлы» — CLAUDE.md в корне проекта с архитектурой, конвенциями и списком того, чего делать нельзя. Платится за это постоянным расходом окна, потому что файл грузится в каждую сессию (см. раздел 6).

Самый трудный тип — эпизодический. Наивная реализация (сохранять транскрипты и искать по ним) формально эпизодическая, практически бесполезна. Продакшн-системы дистиллируют: строка «в прошлый раз при отладке auth-модуля проблема была в middleware-слое» полезнее полного транскрипта 45-минутной сессии. IBM честно перечисляет, что здесь не решено: что удалять, когда информация устаревает, хранить ли проектные воспоминания после того, как пользователь сменил работу. «Забывание для агентов — инженерная задача».

Измеренный эффект: Datadog и флип-флоп решений

Самый полезный количественный результат в этой теме — у Diane Lin из Datadog (доклад «Why Your Agent Disagrees With Itself»). Постановка: агент-триажер алертов безопасности, 93 алерта, каждый прогоняется три раза. В 25% случаев решения между прогонами расходятся — тот же вход, тот же промпт, разный вердикт. Из этих 25 процентных пунктов 15 закрывает эпизодическая память, оставшиеся 10 уходят человеку.

Механика простая и воспроизводимая маленькой командой. Эпизодическая память — «я видел похожие случаи, их пометили benign», без дистилляции причины; она автоматически закрывает повторяющиеся случаи, а в безопасности повторы — основная масса шума. Остаток идёт человеку, человек дистиллирует правило в семантическую память: «password spray без успешного входа → benign; с успешным входом → malicious». В следующий раз правило работает само. Ключевой выбор Datadog: после нахождения спорных точек модель не переобучают — файнтюн дорог и медленно итерируется, — а дополняют двумя видами памяти.

Отдельно стоит отрицательный результат, который в этой теме важнее положительного.

Что произошло: уверенность модели оказалась бесполезным сигналом

• Кто: Diane Lin, Datadog («Why Your Agent Disagrees With Itself»).
• Что делали: искали способ автоматически находить решения, которым нельзя доверять. Пробовали самооценку модели («насколько ты уверен в вердикте»), затем — расхождение между тремя независимыми прогонами одного и того же алерта на выборке из 93 алертов.
• Результат: самооценка уверенности оказалась ненадёжной — модель уверенно ошибается и неуверенно попадает. Работает только межпрогонное расхождение: 25% флип-флопа, из которых 15 п.п. снимает эпизодическая память, 10 п.п. остаются человеку.
• Вывод: не спрашивай модель, уверена ли она. Гоняй один и тот же вход несколько раз и смотри на дисперсию ответа — это и есть детектор мест, где памяти не хватает.

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

Консолидация: что Anthropic называет «dreaming»

Второй измеренный кусок — консолидация памяти между сессиями. Anthropic (команда платформы, доклад «Memory and dreaming for self-learning agents») описывает отдельный фоновый процесс, который проходит по накопленным воспоминаниям и сворачивает их: пять почти одинаковых записей об одном и том же — в одну, а повторяющийся паттерн через несколько сессий выделяется примерно за 60 секунд работы процесса. Эффекты у клиентов, на которые ссылается Anthropic: Harvey — шестикратный рост завершения задач, Rakuten — минус 90% ошибок первого прохода.

К этим цифрам стоит относиться как к вендорским: методика замера публично не разложена, а базовая линия («до чего именно 6×») не описана. Но направление совпадает с тем, что говорят все остальные: память без регулярной переработки деградирует. Emre из OpenAI («Build Hour: Agent Memory Patterns») называет консолидацию — слияние, очистку и переписывание памяти — отдельной регулярной операцией, наравне с записью и чтением.

Архитектурно Anthropic описывает эволюцию: claude.md → memory tool в SDK → память как файловая система, которой модель управляет сама через bash и grep; логика перехода — «уходить с дороги модели». Вокруг этого три слоя проектирования: storage (где лежит, какие метаданные и атрибуция), structure/content (файлы, skills), process (что и как часто триггерит обновление). Из требований клиентов чаще всего всплывает version history с атрибуцией «какой агент, когда, в какой сессии внёс правку» — маленькой команде это даёт обычный git поверх каталога памяти.

Cognition: механизм записи важнее хранилища

Walden Yan из Cognition (система knowledge в Devin) даёт цифру, которая переворачивает приоритеты: около 95% всех воспоминаний Devin сгенерированы автоматически. Логика — «очень мало кто садится писать большие доки о том, как работать с технологией», поэтому память не выпрашивают у пользователя, а предлагают: как только человек поправил агента («нет, git у нас используют не так»), Devin сам предлагает это запомнить, а человек одним движением подтверждает или отклоняет. Автомерж таких записей, по их наблюдениям, живёт порядка двух недель — дальше правило либо подтверждается практикой, либо начинает мешать и требует ревизии; стоимость всей этой памяти считается на инженера, а не на проект, потому что большая часть записей персональна («Cole обычно предпочитает draft PR»).

Отсюда два названных провала памяти. Переобобщение при генерации: разовая просьба «открой draft PR» не должна превращаться в правило «все и всегда открывают draft PR» — правильный уровень фиксирует, кто и что обычно предпочитает. Промах при retrieval: при тысячах воспоминаний нужно достать нужные, не взорвав окно бесполезными. И честное предупреждение: «удивительно много eval-работы уходит только на то, чтобы память оставалась надёжной по мере смены моделей». Если строишь накопительную память — закладывай на неё бюджет тестов, а не только хранилище.

Главная ловушка: semantic similarity ≠ business relevance

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

Ishita Daga из Tesla («Enterprise Agents Have a Structure Problem») даёт чистый пример. Команда A считает «среднее время до вехи» от завершения предыдущей вехи до завершения текущей, команда B — от старта текущей до старта следующей. Обе метрики верны и дают разные числа. Semantic layer хранит оба определения, agent memory (mem0, memory.md) хранит предпочтение — но не понимает разницы между двумя метриками и того, когда какую брать. Автор называет это открытой проблемой индустрии: нужен роутинг по тому, кто и из какой команды спрашивает, а не по близости векторов.

Практический ответ, который уже работает, — типизировать память под домен. Daniel Chalef (Zep / Graphiti) предлагает вместо «извлекаем любые факты» описать бизнес-объекты своего домена — FinancialGoal, DebtAccount, IncomeSource — через Pydantic / Zod / Go structs, с полями и бизнес-правилами, и зарегистрировать их при старте приложения. Retrieval после этого фильтруется по типам нод, а инструмент «получить финансовый снапшот» реализуется не одним поиском, а несколькими параллельными, каждый со своим фильтром по типу — то есть форма ответа задаётся заранее, а не выводится из top-k. Его же вывод: универсальной памяти не бывает, модель памяти обязана повторять бизнес-домен. Для маленькой команды это буквально несколько pydantic-классов.

Более дешёвый вариант того же принципа — у Arize: вырезанная середина контекста лежит в базе с ID, а тул отдаёт список ID, позицию в разговоре и короткий preview, чтобы агент сам решил, что вытащить обратно. И трезвая оценка от Ian Gotts, который держит около тысячи «мыслей» в личном графе: «всегда ли правильно достаёт? нет, не обязательно».

Что забывать и как память устаревает

Richmond Alake (MongoDB) описывает memory management как шесть компонентов: generation, storage, retrieval, integration, updating, deletion — и тут же оговаривается, что deletion в этом списке «ложь»: правильно реализовывать механизмы забывания, а не удаления. У него для этого заведены memory signals: recall count, recency, ID связанной беседы. Дальше — набор рабочих приёмов из разных источников:

Временные метки на каждом факте (Emre, OpenAI). «Люблю собак» два месяца назад против «люблю кошек» сегодня — новая память должна перекрыть старую, и модель должна видеть, что старее.

Weight decay или оконная функция, понижающая вес старых воспоминаний, — там же.

Temporal pruning (Carly Richmond, Elastic): удалять из хранилища всё старше порога. В демо порог — две недели: было 30 сообщений в индексе, удалено 15, осталось 15. Элементарно реализуемо любой командой.

Отбраковка по структуре графа (Vasilije Marković, Cognee): слабосвязанный узел с высоким шумом — кандидат в ошибочные; веса на рёбрах и нодах с temporal weighting показывают, как релевантность падает во времени; отсутствие причинных связей — индикатор недостоверности. Общего решения авторы не обещают: «зависит от use case».

Повышение сессионной памяти до глобальной (Emre, OpenAI): предпочтение, повторяющееся от сессии к сессии, «выпускается» в постоянное.

Против этого есть честное возражение. Nyah Macklin (Neo4j) напоминает, что скользящее окно и рецентность — компромисс: агент теряет важные детали просто потому, что счёл их старыми, критерий возраста не совпадает с критерием важности. Поэтому инварианты («это должно выжить любой ценой») стоит держать отдельным слоем, а не отдавать на откуп decay: Anthropic ровно так и разделяет compaction («это, наверное, больше не нужно») и memory tool («это должно выжить»).

И бытовое, но обязательное. Практик Jono Catliff показывает аккаунт с 17 записями автоматической памяти, среди которых — демо-проект из ролика на YouTube, который в памяти не нужен. Его практика: периодически спрашивать «покажи все свои воспоминания обо мне» и удалять лишнее. Проблема тут структурная: файл памяти не лежит в репозитории и не ревьюится как код. В Claude Code автоматическая память живёт в ~/.claude/projects/<проект>/memory/memory.md и при старте грузится первыми 200 строками — то есть сама память нуждается в курировании и структуре «индекс + отдельные файлы».

Наконец, граница знания. Dan Biderman (Engram) ставит вопрос «что интернализовать в веса, а что вынести в заметки» как открытый и признаёт, что некоторое забывание полезно: как только начинаешь вручную решать, что внутрь, а что наружу, получаешь whack-a-mole — у каждой компании свои данные. Его итоговая позиция трезвая: текстовые представления никуда не денутся, потому что интерпретируемы и аудируемы, а параметр-эффективные методы — слой сверху, а не вместо.

Что с этим делать

Начни с двух типов памяти, а не с четырёх. Процедурная (файл правил) и семантическая (дистиллированные доменные правила) закрывают большую часть пользы. Эпизодическую добавляй, когда у тебя есть поток повторяющихся однотипных решений — как у Datadog с алертами.

Меряй расхождение, а не уверенность. Прогоняй один и тот же вход 2–3 раза и смотри на разброс вердиктов. Самооценка модели как фильтр не работает (Datadog). Места расхождения — это ровно список того, чего не хватает в памяти.

Записывай автоматически, подтверждай в одно движение. 95% памяти Devin — автогенерация с approve/reject (Cognition). Механизм записи важнее выбора хранилища; проактивную документацию никто писать не будет.

Типизируй память под домен и фильтруй retrieval по типам. Похожесть по эмбеддингу — не релевантность (Tesla, Zep). Несколько параллельных поисков с фильтром по типу лучше одного top-k.

Заведи регулярную консолидацию и явный порог забывания. Дедупликация близких записей (Anthropic), временные метки и decay (OpenAI), pruning старше N недель (Elastic). Инварианты выноси в отдельный слой, который decay не трогает.

Держи память под git и ревьюй её как код. Version history с атрибуцией — самое востребованное свойство у клиентов Anthropic; маленькой команде это даёт обычный репозиторий плюс периодическая ручная ревизия (Catliff) и структура «индекс + файлы» из-за лимита в 200 строк.

Контекст в кодовой базе: файлы правил, skills и прогрессивное раскрытие

Файлы правил, skills, спеки и индексы в репозитории — это контекст, за который ты платишь каждой сессией, пригодился он или нет. Поэтому главный вопрос раздела не «что написать агенту», а когда именно этот текст попадает в окно. Ответ индустрии — прогрессивное раскрытие.

Прогрессивное раскрытие: три уровня

Barry Zhang и Mahesh Murag из Anthropic («Don't Build Agents, Build Skills Instead») описывают механизм так: skill — это просто папка с файлами, и в рантайме модель видит только метаданные скилла. Когда скилл нужен, читается SKILL.md с основной инструкцией и оглавлением папки; всё остальное открывается по необходимости. Цель дизайна названа прямо: «защитить context window, чтобы в него влезли сотни скиллов и они были композируемы».

Раскладка по токенам (DataRobot, «Skills are the New SDKs», и IBM Technology):

Уровень 1 — фронтматтер, всегда в системном промпте: обычно меньше 100 токенов на skill. Это «оглавление» всех доступных скиллов.

Уровень 2 — тело markdown, читается только при активации: обычно меньше 5K токенов.

Уровень 3 — всё остальное: скрипты, references/, assets/. Скрипт либо исполняется, и в контекст возвращается только вывод, либо служит примером кода.

Без этого механизма, как формулирует DataRobot, сотня skills «сожгла бы бюджет токенов ещё до первого вопроса». Отсюда следствие для того, как писать skill: description во фронтматтере всегда в контексте, а тело — нет. IBM подчёркивает, что description работает как триггер («use this when the user asks to...»), и сопоставление задачи со скиллом делает сама модель своим рассуждением — качество description критично, качество тела влияет только после активации.

Сколько стоит MCP и сколько стоят skills

Самое важное сравнение стоимости — у DataRobot. Подключённые MCP-серверы платят полную цену определений тулов в каждой сессии до начала разговора: 15 MCP-серверов — больше 100 000 токенов только в описаниях инструментов. Skills за счёт прогрессивного раскрытия дают ту же операционную функциональность примерно в 10 раз дешевле. Докладчик оговаривается, что цифры оценочные и методика не приведена, — но порядок величины проверяется у себя за пять минут.

Похожий бытовой замер из практики (Jono Catliff, «12 Rules»): описания подключённых MCP-инструментов заняли 24,1k токенов — 12% окна ещё до первого сообщения. Тоже порядок величины, не лабораторное измерение, но он объясняет, почему «контекст кончается ниоткуда»: восьмая часть окна уходит на инструменты, которые могут не понадобиться.

Из этого не следует «выключить MCP». Граница проходит по природе ресурса, и лучше всего её формулирует ведущий Confluent Developer: skills — это статическое справочное знание плюс локальная файловая система; MCP-ресурсы — живые данные (клиенты, тикеты, сообщение из Kafka прямо сейчас) и действия во внешнем мире, требующие аутентификации. DataRobot добавляет то же с другой стороны: MCP нужен там, где требуются аутентификация, изоляция процесса и «лошадиные силы» — GPU, семантический поиск по сотням терабайт. И наблюдение оттуда же: у Codex и Claude Code всего около десятка встроенных тулов, а не сотни.

Файлы правил: раздувать почти не окупается

Здесь есть неудобный замер. Тот же практик (Jono Catliff) задал один и тот же вопрос — «объясни структуру проекта и предложи улучшения» — с CLAUDE.md на 910 строк и на 33 строки. Результат: 45% окна против 41%, разница в 4 процентных пункта.

Вывод отсюда не «раздувай, всё равно дёшево», а более тонкий: раздувание файла правил почти не окупается. Ты платишь эти проценты каждым сообщением, а взамен получаешь текст, в котором 90% нерелевантно текущей задаче. Настоящая экономия приходит не от сокращения файла правил, а от выноса знания в skill: замер того же автора — отлаженный skill для разбора банковского CSV занял 27% окна против 45% при работе «через общий CLAUDE.md и серию уточняющих вопросов».

Что произошло: файл правил на 910 строк переписали в skills

• Кто: практик Jono Catliff, доклад «12 Rules» (бытовые замеры, порядок величины — не лабораторное измерение).
• Что делали: всё, что раньше сваливалось в один rules-файл и грузилось каждым сообщением, разбили на skills по воркфлоу; общие куски (tone of voice, banned phrases) вынесли в reference-файлы, на которые skill только ссылается — «открой, если понадобится, иначе пропусти».
• Результат: сокращение самого файла правил дало мало (910 → 33 строки: 45% → 41% окна). Вынос воркфлоу в skill — заметно больше: 27% против 45%. Skill в 31 строку со ссылками против 457 строк с зашитыми референсами — 25% против 31% окна на сообщение.
• Вывод: экономит не короткий файл правил, а перенос знания на уровень, загружаемый по требованию. Сценарии замеров несопоставимы (отлаженный скилл против хаотичного диалога) — доверять стоит направлению, а не точным числам.

Что делать с самим файлом правил, если сокращать его бессмысленно, а раздувать вредно. Три рабочих ответа:

Context priming вместо always-on файла (IndyDevDan): набор слэш-команд /prime, /prime_bug, /prime_feature со структурой purpose → run → read → report — каждая читает ровно те файлы, что нужны под свой тип задачи. В CLAUDE.md остаётся то, что нужно 100% агентов в 100% случаев. Замер автора: ~350 токенов в memory-файле против 23 000 до рефакторинга. Ограничение — надо помнить о запуске нужного prime.

Скоупы и подкаталоги (David Mahler): корень проекта, .claude/ (уезжает с git-клоном), ~/.claude (личные предпочтения) и CLAUDE.md в подкаталоге, который грузится только когда агент полез в файлы этой папки. Последнее — готовый механизм прогрессивного раскрытия по областям монорепо, и он сильно недооценён.

CLAUDE.md как слой маршрутизации (Ben AI, идею индексных файлов приписывает Karpathy): при большой базе корневой файл становится инструкцией навигации — где какой тип знания лежит, куда писать обновления, синтаксис ссылок. Дальше в каждой подпапке свой индексный файл, читаемый при заходе туда.

И отдельное правило от Ben AI, самое практичное при росте: skills должны ссылаться на общую базу, а не носить копии контекста. Если класть документы внутрь скилла, в references/, один и тот же файл дублируется по нескольким скиллам. Правильно — оставить в SKILL.md процесс и ссылки: тогда правка одного документа «обновляет» все скиллы разом.

Файл с диска, а не вставка в чат

Ещё один замер того же порядка величины: одно и то же содержимое, прочитанное агентом с диска, заняло 38% окна против 71% при вставке прямо в чат. Разница почти двукратная, объяснение простое: вставленный текст навсегда становится частью истории сообщений, а прочитанный файл — результат вызова инструмента, который можно вытеснить, ужать или перечитать позже.

Отсюда две привычки. Первая: не вставляй, а клади в файл и давай путь. Вторая, из «How AI Coding Agents Work» (The Working Thesis): ничего важного не оставляй висеть в чате — если агент выдал прекрасный markdown в ответе, попроси сохранить его в architecture_plan.md, иначе при компакции план на 500 слов превратится в буллет «brainstormed architecture». Тот же класс приёмов: разделять scratchpad (трекер прогресса, удаляется по завершении) и record-keeping файл, остающийся в репозитории как запись решений (Ragunath Jawahar); класть в проектный файл явные compact instructions — что сохранять при сжатии (пример Anthropic: «focus on test output and code changes»).

Иерархия: плохая строка research дороже плохой строки кода

Dex Horthy из HumanLayer («Advanced Context Engineering for Agents») даёт правило, расставляющее приоритеты по всей цепочке: «плохая строка research порождает тысячи плохих строк кода». Отсюда раскладка бюджета: фаза research может занимать 60–80% окна, но её артефакт — то, что уходит дальше в реализацию, — ужимается до 15–20%. На исследование не жалко потратить почти всё окно, но передавать дальше нужно сжатый вычитанный результат, а не историю рассуждений.

Из той же практики — отношение к файлам правил как к продуктовому артефакту: CLAUDE.md и слэш-команды «мы буквально тестируем неделями, прежде чем кому-либо разрешено их менять». Прямая противоположность привычке дописывать строчку в CLAUDE.md после каждой неудачной сессии.

Skills, написанные моделью, измеримо вредят

Популярная идея self-evolving skills получает прямое опровержение от DataRobot со ссылкой на опубликованные исследования: skills, сгенерированные LLM, ухудшают производительность — тратят больше токенов и больше времени на рассуждение вместо того, чтобы ускорять работу и экономить контекст. Формулировка спикера: «skill ровно настолько хорош, насколько хорош человек, который его написал». Направление эффекта названо, точных чисел в докладе нет.

Практический вывод: модель может помогать писать skill, но приёмка и структура — на человеке, ровно как с кодом. Рядом вторая проблема — безопасность: skills исполняют скрипты локально с доступом к файловой системе, переменным окружения и API-ключам, изоляции процесса в отличие от MCP нет, а аудиты публичных скиллов находят prompt injection, tool poisoning и скрытую малварь (IBM Technology и DataRobot; упоминается репозиторий на 85 000 скиллов). Аналогия честная — NPM десять лет назад: ставь чужой skill как обычную зависимость, с ревью.

Anthropic отдельно перечисляет нерешённое: тестирование и eval скиллов; тулинг, проверяющий, что агент подтянул нужный скилл в нужный момент; версионирование; явные зависимости skill → skill / MCP / пакеты. Stephen Chin из Neo4j описывает ту же проблему с земли: иногда подгружается не тот скилл, а иногда отсутствует звено цепочки — есть навык «открыть раковину», нет навыка «съесть».

Как разложить репозиторий под агента

Сводя всё вместе:

В файлах правил — только то, что нужно 100% агентов в 100% случаев: как запускать тесты, жёсткие запреты, навигация по репозиторию. Плюс индексные файлы в подкаталогах, грузящиеся при заходе в область.

В skills — процедурное знание: воркфлоу, которые повторяются и имеют чёткий триггер. Anthropic называет их «осязаемой памятью»: стандартный формат гарантирует, что записанное использует будущая версия агента, а скиллы можно эволюционировать и выбрасывать устаревшие. Оговорка там же: skills покрывают только процедурное знание.

Скриптом внутри скилла, а не тулом, — всё, что модель раз за разом пишет заново. Три претензии Anthropic к тулам: описания двусмысленны, модель не может починить тул, когда он мешает, и тулы всегда живут в context window. Код лишён этих проблем и лежит на диске, пока не понадобится.

В спеках рядом с кодом — форматы и контракты. Zach Blumenfeld (Neo4j) описывает связку «CLI, умеющий отдавать схему, плюс доменный skill плюс markdown-спека формата в docs/»: агент читает схему, пишет запрос и следует спеке, а не угадывает по промпту.

Состояние — наружу, в репозиторий. Beads (инструмент Steve Yegge в изложении Ragunath Jawahar): issue tracker внутри version control, задачи в JSONL коммитятся, SQLite — производный индекс. Это одновременно вынос состояния и координация параллельных агентов.

Два ограничения, чтобы не переоценить подход. Первое — масштаб: Stephen Chin (Neo4j) говорит, что в типовой раскладке из AGENTS.md, файлов памяти и файлов инструментов его агенты грузят минимум 100k токенов на каждый раунд, потому что тянут «всё подряд в надежде, что что-то пригодится»; на малом масштабе с сильной моделью это работает, на большом — нет. Второе — позиция Emil Eifrem (Neo4j): «markdown-файлы — часть решения, но не решение»; на десятках агентов данные дублированы и непонятно, какая копия правильная, ломается DRY, нет кросс-агентного обмена, потому что связка «намерение → источник» зашита в код и промпты. Это позиция вендора графовой БД, но список проверяется самостоятельно.

Наконец, репозиторий надо чинить не только для агента, но и от агента. Cole Murray (OpenInspect) описывает деградацию кодовой базы до уровня худшего инженера: не проверяющий код разработчик цементирует свои паттерны, дальше AI читает их как норму и размножает — 12 разных хелперов форматирования даты. Лечится процессом: плановые чистки, контракты между модулями и lint-правила против «подписей» AI-кода (hasattr / getattr вместо прямого обращения, dict[str, Any]). Встречное требование от Cognition: репозиторий должен быть локально тестируемым — локальная БД, docker-compose с Postgres, — чтобы агент запускал код без продовых кредов.

Что с этим делать

Проведи аудит подключённых MCP. Посчитай, сколько токенов уходит на описания инструментов до первого сообщения (ориентир DataRobot — 15 серверов дают больше 100k). Оставь MCP там, где нужны живые данные, аутентификация или удалённое исполнение.

Переноси знание из файла правил в skills, а не просто сокращай файл. Сокращение даёт единицы процентов окна (910 → 33 строки: 45% → 41%), перенос в скилл — десятки (27% против 45%). В корневом файле оставь навигацию; остальное — в подкаталожные файлы и skills.

Читай файлы, а не вставляй их в чат (38% против 71% окна) и сразу сохраняй в файл всё ценное из ответов агента — иначе компакция превратит план на 500 слов в один буллет.

Выстрой иерархию артефактов по правилу HumanLayer. Research может съесть 60–80% окна, но дальше передаётся сжатый артефакт на 15–20%.

Skills пиши руками. Сгенерированные моделью скиллы измеримо ухудшают работу (DataRobot). Чужие ревьюй как npm-зависимость — изоляции процесса у них нет. Свои версионируй в git и меняй файлы правил как продукт, а не как заметки (HumanLayer тестирует их неделями).

Держи в скиллах ссылки, а не копии общих документов (Ben AI), и выноси повторяющийся код агента в скрипты внутри скилла — они не занимают окно.

Суб-агенты: изоляция контекста и цена передачи

Изоляция — четвёртая операция контекста в рамке LangChain рядом с write / select / compress (её пересказывает Marina Wyss в «Context Engineering in 29 Minutes»). И единственная из четырёх, которая обещает не «уместить больше», а «не смешивать». Дальше — что она даёт, чем за это платят на стыках и где она превращается в способ испортить один хороший контекст четырьмя посредственными.

Измеренный эффект: суб-агент не тратит окно родителя

Самая наглядная цифра — у David Mahler («Claude Code: Context, Memory & Compaction Explained»). Он запустил general-purpose сабагента на целую задачу: тот читал файлы, гонял команды, собирал учебное пособие. Заполнение основного контекста — 19% до и 19% после. Наверх вернулась только финальная сводка. У сабагента своё окно, своя модель, свои инструменты и инструкции — родитель не платит за его чтение ничем.

IndyDevDan («Elite Context Engineering with Claude Code») меряет то же с другой стороны. Определения кастомных суб-агентов попадают не в пользовательский промпт, а в системный, поэтому три кастомных агента стоят 122 токена в главном окне — при «сыром» размере одного описания около 900 токенов. Работа (веб-скрейп документации) идёт в окнах 8–10 суб-агентов примерно по 3k токенов, наружу выходит только файл-результат. Суммарно сэкономлено порядка 40 000 токенов, главное окно осталось на ~9k.

Anthropic в пересказе Lance Martin (LangChain) формулирует эффект в терминах пропускной способности: многоагентность увеличивает общее число токенов, которое система способна обработать, — отсюда более богатые отчёты, а не только более дешёвые.

Но экономия — не главный приз. Marina Wyss ставит акцент иначе: основная проблема одного агента на всё — не нехватка места, а контаминация. Подробные результаты поиска из фазы research продолжают лежать в контексте на фазе написания кода и отвлекают. Суб-агент работает в чистом окне и возвращает сжатое резюме; весь мусор поиска остаётся у него. Emre (OpenAI, «Build Hour: Agent Memory Patterns») называет тот же приём isolate and route и говорит прямо: цель — минимизировать context conflict и context poisoning, а не только счёт за токены.

Arize («How we solved Context Management in Agents») описывает переход буквально: было — разговор, история чата, тяжёлые данные и поиск в одном контексте; стало — главный агент держит только чат и лёгкий контекст, а сотни спанов внутри одного трейса живут в суб-агенте. Назвали game-changer и раскатали на все data-intensive операции — и тут же честно добавили, что «огромный контекст всё ещё ломает всё».

Восстановление после взрыва: context bundles

У изоляции есть побочный полезный эффект — она делает состояние переносимым. IndyDevDan через хуки Claude Code дописывает все вызовы (промпты, read, search) в лог-файл в каталоге agents/context-bundles/, уникальный по дню, часу и session ID. Когда окно взорвалось, новый инстанс поднимается через /load_bundle <path>: дедуплицирует повторные чтения и восстанавливает картину работы предыдущего агента, включая исходный пользовательский промпт — ответ на вопрос «зачем контекст такой, какой он есть».

Цифра важная и отрезвляющая: бандл восстанавливает 60–70% состояния. Не 100%. Причём остальное режется сознательно: логировать всё нельзя — переполнишь окно следующего агента, поэтому содержимое записей и детали чтений в бандл не пишут, а загружать его нужно выборочно.

Запомни эти 30–40%. Ровно они и есть цена передачи. Дальше — что происходит, когда передач в системе не одна, а четыре подряд.

Главный контр-кейс: почему ZS убили четырёхагентный пайплайн

Что произошло: мультиагентный пайплайн выдавал связный по форме, бессвязный по сути результат

• Кто: ZS Associates, фарма-аналитика для крупных клиентов (доклад «Why We Killed Our Multi-Agent Pipeline», AI Engineer).
• Что делали: скопировали работу живого аналитика в топологию агентов — агент детекции сигналов, агент локализации источника, агент атрибуции драйверов, агент синтеза плюс оркестратор поверх.
• Результат: на выходе пакет выглядел прилично. Сигнал определён верно (падение назначений на 18% за 4 недели), причина найдена верно (страховщик перевёл препарат в худший тариф) — а рекомендованное действие мимо (отправить больше торговых представителей), и прогноз следом неверный. Ни один агент не владел картиной целиком.
• Вывод: три причины провала по их же разбору — LLM выполняла детерминированную работу; контекст терялся на каждом хендоффе; не было общего доменного знания. Пайплайн убили и пересобрали.

Разберём механику потери, потому что она универсальна и не зависит от домена.

Первое. Хендофф — это компрессия без критерия. Агент передаёт вниз не состояние, а его текстовое резюме, и физически не может знать, что понадобится потребителю ниже по цепочке: тот ещё не начал думать. У ZS агент локализации источника знал, что дело в тарифной сетке страховщика, — но резюмировал это как «источник: страховщик», и следующий агент работал уже с ярлыком, а не с фактом. Действие «отправить представителей» логично для ярлыка и абсурдно для факта «препарат переведён в худший тариф».

Второе. Потеря не сигнализируется. Carly Richmond (Elastic, NDC Conferences) описывает это как отдельный класс отказов: если вывод агента 1 нужен агенту 3 и не передан, ломается результат всей цепочки. Ошибка при этом не выглядит как ошибка — никто не падает, ничего не переполняется. «Слишком хорошая» изоляция просто режет нужные связи.

Третье. Каждый следующий агент достраивает недостающее правдоподобным. Модель не оставляет дыру — она её заполняет. Поэтому четыре хендоффа дают не «результат с четырьмя пробелами», а гладкий текст, где пробелы заклеены домыслом. Это и есть «связный по форме, бессвязный по сути»: увидеть дефект можно, только зная предметную область, — по форме претензий нет.

Dex Horthy (HumanLayer, YC Root Access) называет это испорченным телефоном и делает операционный вывод: значение имеет не то, что суб-агент делал, а то, что он вернул, — поэтому промптить надо родителя, объясняя ему, как промптить ребёнка о формате ответа. И добавляет: детерминированные системы уже хаотичны, недетерминированные тем более.

Рабочее правило: рассуждение не делится

Как ZS пересобрали систему: консолидировали всё рассуждение в одного агента. Параллелизм оставили — убрали именно распределённое суждение. Суб-агенты порождаются динамически под узкую задачу расследования (например, активность представителей в конкретном регионе) и возвращают результаты, но не рассуждение и не решение. Архитектура стала легче исходной, а хендоффов, на которых терялся контекст, просто не стало.

Формулировка, которую стоит унести целиком: один агент владеет рассуждением, суб-агенты возвращают результат, а не суждение.

К той же топологии пришли эмпирически и другие. Cognition дали Devin'у MCP, чтобы он произвольно писал другим Devin'ам и создавал новых, — получился, по словам Walden Yan (LatentSpace), «хаотичный мир». В практике осталась схема «один агент сегментирует работу и раздаёт её изолированным агентам, у каждого своя машина, машины не разделяются». Эксперименты Cursor, по его же наблюдению, пришли ровно к тому же виду.

Он же даёт трезвую проверочную рамку: «это вообще мультиагентность или просто вызов инструмента?» Большинство «мультиагентных» кейсов — суб-агент, посланный найти файл или реализацию; вся ценность в том, что его tool calls и токены схлопываются в один ответ для главного агента (так у Cognition устроен вызов DeepWiki). Это управление контекстом, а не сотрудничество агентов.

Единственное принципиальное исключение из правила «не делить суждение» — независимая проверка. JetBrains («How AI Agents Work») отделяют evaluator от исполнителя намеренно: у того, кто только что написал код, есть все основания считать его хорошим, у независимой проверки — нет. Но обрати внимание на характер суждения: checker судит о факте завершения по бинарному критерию, а не о предметной области.

Метод ZS: посадить агента в пустую папку и смотреть

Отдельно стоит забрать не вывод ZS, а способ его получить. Они посадили кодового агента в пустую папку, дали bash и доступ к базе, поставили реальную задачу — и просто смотрели: какие запросы он пишет, куда лезет первым делом, где спотыкается. Фиксы вывели из наблюдения, а не из представления о том, как «должен» работать аналитик.

Это решает исходную ошибку в корне. Главный вывод ZS: не вносить человеческие и организационные ограничения в архитектуру — пусть архитектура выводится из задачи. Разбиение по шагам живого аналитика выглядело логично, и именно оно создало точки потери контекста.

Метод переносится дословно. Leonie Monigatti (Elastic, «Agentic Search for Context Engineering») три дня логировала exec-инструмент своего агента, а потом спросила самого агента, какие паттерны он видит, — и получила рекомендации, какие специализированные search-инструменты стоит реализовать. Её порог тревоги: 4–5 вызовов инструмента на один вопрос — признак, что инструмент слишком сложен для агента.

Дешёвая версия для маленькой команды: пустая папка, bash, реальные данные, один прогон, полный лог. Смотреть на траекторию, а не на результат.

Границы: где многоагентность оправдана, а где это распил одного контекста

Оправдана, когда суб-агент возвращает факт или артефакт, а не мнение:

• поиск и локализация — «найди, где именно происходит событие и как данные текут между компонентами» (Dex Horthy), вызов DeepWiki (Cognition);
• работа с тяжёлыми данными — сотни спанов в трейсе остаются внизу, наверх идёт результат (Arize);
• фазовое разбиение с коротким дайджестом наверх — reader извлекает факты, scorer применяет политику, writer собирает итог (Google Cloud, «Context engineering explained»);
• независимая проверка условия завершения (JetBrains);
• объём, который физически не влезает в одно окно (Anthropic / LangChain);
• разная экспертиза. Ragunath Jawahar (Developer Summit): сабагент для security review работает принципиально по-разному в зависимости от жаргона в системном промпте, поэтому писать этот промпт стоит вместе с профильным экспертом команды — так активируется нужный регион знаний модели.

Не оправдана — и обычно это просто способ распилить один контекст на несколько испорченных:

• роли скопированы с оргструктуры: «продакт-менеджер, дата-сайентист и фронтендер» (Dex Horthy). Суб-агенты про контроль контекста, а не про роли;
• суждение распределено по цепочке — случай ZS;
• детерминированную работу отдали LLM. ZS вынесли детекцию сигналов в детерминированный пайплайн со статистикой, гардрейлами, порогами и приоритизацией: он кладёт сигнал в очередь, агент просыпается на готовый. До этого модель то применяла статистику, то на глаз объявляла сигналом шум. Формула — работа агента расследовать, а не обнаруживать;
• ты не удерживаешь «core four» (контекст, модель, промпт, инструменты) каждого агента. IndyDevDan: если теряешь из виду контекст даже одного агента — ты ещё не готов к суб-агентам.

И рамка сверху, объясняющая, почему всё это раз за разом сходится к «менеджер + изолированные исполнители». Danielle Perszyk (Amazon AGI Lab, LatentSpace) наблюдает мультиагентные системы на открытых харнессах: со стороны похоже на человеческое взаимодействие, но при росте масштаба видно, что ничего долговременного не остаётся — нет накопительной культуры, агенты фактически не влияют друг на друга. Практических рецептов отсюда пока нет, но вывод для проектирования есть: пока между агентами ничего не накапливается, любая топология сложнее «один рассуждает — остальные приносят» — это просто больше стыков, на которых теряется контекст.

Что с этим делать

Делегируй чтение и поиск, не делегируй вывод. Суб-агент возвращает факт, файл, дайджест, число. Интерпретация и решение остаются у одного агента.

Пропиши формат возврата в промпте родителя — не ребёнка, а того, кто ребёнка запускает (Dex Horthy). Значение имеет только то, что вернулось.

Замеряй экономию, а не верь ей. /context до и после делегирования: 19% и 19% (David Mahler) — так выглядит работающая изоляция. Если окно родителя растёт вместе с работой ребёнка, изоляции нет.

Заведи бандлы контекста до того, как окно взорвётся. Хуки пишут лог вызовов, новый инстанс поднимается из него и восстанавливает 60–70%. Содержимое чтений не логируй — утопишь следующего агента.

Перед разбиением на агентов вынеси наружу всё детерминированное. Пороги, статистика, приоритизация, SQL — это пайплайн, а не агент. Агент просыпается на готовый сигнал.

Проектируй от задачи, а не от штатного расписания. Прежде чем рисовать топологию, посади одного агента в пустую папку с bash и данными и посмотри, что он делает. Архитектуру выводи из лога.

Эксплуатация: измерять деградацию, а не надеяться

Всё предыдущее — про то, как собрать контекст. Этот раздел — про то, как узнать, что он перестал работать, и узнать не от пользователя. Ishita Daga (Tesla, «Enterprise Agents Have a Structure Problem») формулирует диагноз в одну фразу: многие команды не занимаются eval вообще, поэтому и не знают, что агент деградирует. Lance Martin (LangChain) добавляет условия входа: трейсинг токенов и evaluation — «table stakes» до любой оптимизации контекста. Без первого ты не считаешь, без второго сжатие слепое: ты не знаешь, испортил поведение или нет.

Как вообще ловить деградацию

Главная особенность агентных отказов в том, что они поздние. Правило, которое держалось на пятом ходу, тихо перестаёт держаться на пятнадцатом, и на коротком тесте это не воспроизводится.

Arize («How we solved Context Management in Agents») сделали под это отдельный вид evals: подгружают 10 ходов истории и тестируют 11-й. Смысл — сделать поздние отказы воспроизводимыми: баги контекста становятся тестируемыми, не нужно ждать жалобы пользователя. Они прямо называют это полезным сигналом того, как работает твоя стратегия управления контекстом. Это единственный найденный способ систематически ловить именно поздние отказы — и при этом самый дешёвый в реализации.

Оговорка от них же: метрик «качества контекста» у Arize всё равно нет, evals используются как прокси, а выбор того, что остаётся в контексте, после года работы — по-прежнему эвристика «первые 100, последние 100». Готовой методики нет ни у кого.

Второй детектор — расхождение между прогонами. Diane Lin (Datadog, «Why Your Agent Disagrees With Itself») взяла реальные security-алерты и прогнала каждый трижды: 93 алерта × 3 прогона. Без принятого решения в контексте около 25% меняли вердикт между прогонами. С эпизодической памятью примерно 15% стали консистентными, а около 10% продолжали «мигать» — либо нет похожего прецедента, либо расхождение сохраняется даже при наличии ссылки. Эти 10% уходят человеку.

Инструмент не требует ни разметки, ни эксперта, ни эталона. Всё, что «мигает», — либо дефект контекста, либо честно неопределённый случай, и оба ответа полезны.

Третий слой — дрейф траектории. Carly Richmond (Elastic) смотрит трассы через OpenLIT: видно каждый вызов инструмента — какие, в каком порядке, сколько заняли. Изменилось число вызовов или их порядок — изменится и результат. Её конкретный провал: подмена модели на FunctionGemma превратила выдачу маршрута в «я не могу этого сделать». Вывод — регрессионный набор эталонных пользовательских входов обязателен и для мажорных, и для минорных апгрейдов модели.

Плюс два дешёвых обязательных теста: пройти сессию хотя бы раз за реальную точку компакции и проверить, держится ли правило на следующем ходу («Context Compaction: What Survives the Summary…»), и сверять самоотчёт агента с tool-call history — Zach Blumenfeld (Neo4j) объективной проверкой считает только историю вызовов.

Петля самоулучшения: цифры и потолок

Что произошло: автоматическая оптимизация промпта упёрлась в плато на 80%

• Кто: Annabell Schäfer, Langfuse (доклад «Stop Burning Tokens», AI Engineer).
• Что делали: датасеты 200 (fit) / 100 (validate) / 300 (test); агент — простой промпт на дешёвой модели; оптимизатор — Claude Code с prompting guide и task.md. Цикл: прогон, поштучный скоринг, анализ кластеров ошибок на fit, гипотеза правки под самую крупную категорию, перепрогон, принять правку только если улучшился и validate. Ссылку на test-датасет оптимизатору не давали до самого конца.
• Результат: baseline 68% → первая же итерация 78% (+10 п.п.) → пик 83% на 3–4-й итерации → плато около 80%. На неприкосновенном тесте из 300 примеров — 80,2%, то есть улучшение обобщилось. Стоп-правило задано заранее: 15 итераций или 92% accuracy.
• Вывод: почти вся выгода пришла на первую итерацию; 92% не достигнуто и достигнуто не будет. Дальнейшие итерации жгут токены впустую — отсюда название доклада.

Важна не столько методика, сколько форма кривой. Разрыв между стоп-правилом (92%) и реальным плато (~80%) — не недоработка оптимизатора, а потолок, заданный шумом самой разметки.

Откуда шум. Рынок любит оценщики вида correctness / helpfulness / hallucination по шкале 0–1 или 1–5, но чтобы это работало, надо определить каждое значение шкалы для каждого контекста — чего почти никто не делает. Отсюда низкий сигнал и нестабильность между прогонами: LLM-as-a-judge недетерминирован. Langfuse переходят на бинарные доменные проверки: «ответ основан на retrieved context: да/нет» (проверяемо), «имя бренда написано правильно и не переведено на испанский», «к какому из пяти известных failure mode относится случай». Такие критерии нельзя купить — их вытаскивают из доменных экспертов, прогоняя сэмплы и спрашивая «почему здесь так, а там иначе».

Но и при бинарных критериях остаётся слой примеров, где сама разметка спорна: два эксперта расходятся, а «правильный» ответ зависит от прочтения. Остаток неустраним — и оптимизатор, продолжая крутиться, начинает подгонять промпт под шум, а не под задачу. Так пик 83% и сползает к 80%. Тот же остаток виден у Datadog: 10% «мигающих» алертов не чинят, их маршрутизируют человеку. Вывод: оцени свой потолок по доле спорных примеров и ставь стоп-правило рядом с ним, а не рядом со 100%.

Экономика: где реально сгорают деньги

KV-кэш — самый быстрый рычаг. Разбор Manus/Manifold в пересказе Marina Wyss: провайдеры кешируют key-value представления токенов, и если префикс контекста между вызовами не менялся, обрабатываются только новые токены на конце. Для Claude Sonnet это 30 центов за миллион кешированных входных токенов против $3 за миллион некешированных — разница в 10 раз. Агент делает 30–40 API-вызовов на задачу, так что множитель применяется ко всему прогону. Отсюда раскладка: стабильное (system prompt, определения tools) — наверх, динамическое (история, шаг, состояние) — вниз. Любая правка ранней части инвалидирует кеш.

Прямое следствие — не добавляй и не удаляй инструменты по ходу разговора: это ломает кеш. Manus держат все определения в стабильном префиксе и помечают часть недоступной для текущей фазы (tool masking). И неочевидная строка в счёте: компакция молча убивает prompt cache — без ошибки, просто счёт выше.

На что уходят токены. /context показывает разбивку: system prompt, tools, memory-файлы, MCP tools, описания skills, сообщения (обычно крупнейшая статья), свободное место и буфер под авто-компакцию. Конкретика: 40+ определений tools ≈ 10 000 токенов ещё до первого хода; уже на трёх подключённых MCP-серверах расход «весьма существенный», а на 20–40 съедает огромную долю окна (Jono Catliff); системный оверхед модели — отдельная статья: одно и то же «Hey» съело больше трети окна на Haiku против 9% на Opus. Дело не только в деньгах: квантованная Llama 3.1 8B провалила бенчмарк GeoEngine с 46 инструментами и отработала нормально с 19, хотя контекст спокойно помещался в окно.

Стоимость холистических запросов. Запрос, который обязан охватить картину целиком, дёшево не бывает. У ZS Associates после перестройки один прогон — 50+ ходов и «изрядное количество токенов», зато результат за 20–30 минут против 3–4 недель работы аналитика. Суммы они не назвали, и это честно: метрика тут — цена результата, а не цена вызова. Sarah Sachs (Notion, «Token Town») о том же: их поставщик веб-поиска не выигрывал ни по латентности вызова, ни по цене — преимущество было видно только на целых поисковых траекториях.

Что ломает юнит-экономику. Оттуда же два сценария: reasoning-модель обновили, цена за токен та же, но она тратит втрое больше выходных токенов; новая модель на 40% дороже предшественника, которого депрекейтят через 4 месяца. Отсюда — маршрутизация трафика по типам задач (триаж почтового ящика на Opus — «обдираловка и клиента, и себя») и трезвость насчёт того, что для целых классов работы LLM не нужен вовсе: чтобы превратить CSV в PDF или выполнить детерминированный SQL. Ориентир по бюджету на фоновых агентов (LatentSpace): $1 000 – $5 000 на инженера в месяц. И правило JetBrains: токен-бюджет и максимум итераций задаются до запуска петли, а размытая цель («сделай лучше») означает бесконечную петлю.

Скорость устаревания: что фиксировать, а что делать сменным

Dan Farrelly (CTO Inngest, «Your agent architecture has a half-life of 6 months») режет систему на три слоя с разным периодом полураспада: execution (поток, состояние, durability, ретраи) живёт годы; context (модели, промпты, тулы, память) меняется чаще всего — промпты живут недели, иногда одну, модели — месяцы; compute — руки: сэндбоксы, рантаймы, браузеры. Тезис: если слои связаны, короткий период полураспада одного тянет вниз остальные — технический долг под другим именем. Симптомы: оркестрация закопана внутри фреймворка, состояние держится в сэндбоксе, ретраи перепутаны с логикой промптов.

Граница получается такая. Фиксировать стоит слой исполнения: как устроен поток, где живёт состояние, как считаются ретраи, как всё трассируется. Сменным закладывать всё, что относится к знанию: модель, промпт, набор инструментов, стратегию памяти. Sarah Sachs формулирует это со стороны продукта — строить под мультимодельность, воспринимая харнесс как слой интероперабельности, и не покупать скидку ценой опциональности; технически это трудно («тяжело убить кеш и переключить модель посреди транскрипта»).

Состояние держи вне рантайма. Sandbox как хранилище состояния — удобный приём внутри сессии и антипаттерн с точки зрения долговечности: срок жизни песочницы измеряется прогоном, срок жизни системы — годами. Cognition строит наоборот и называет это «отделить мозг от машины»: мозг в control plane, песочница — только руки, дёргаемые tool calls; на машину кладут секреты в объёме прав пользователя. Альтернатива — агент целиком «в коробке», где состояние локализовано, но туда же попадают все секреты.

Масштаб, ради которого всё это: фоновый агент работает минуты и часы, делает порядка 200 вызовов тулов, и хотя бы один отказ практически гарантирован. Без сквозного трейса всей сессии — не только LLM-вызовов, но и ошибок БД, проблем прав, триггеров — такого агента невозможно даже отладить. Петля у Inngest: cron-хелсчек раз в 30 минут тянет метрики и спрашивает модель, всё ли здорово; при проблеме поднимается triage-агент; раз в неделю ревьюер читает историю прогонов и оценивает сам триаж. Скоринг — outcome-based: метрика это факт (открыли ли PR по итогу триажа, сохранили ли отчёт агента), посчитанный после прогона по полному трейсу.

Организационное дополнение от Ben AI: у контекстного слоя должен быть один ответственный владелец, иначе слой деградирует, — плюс регулярный ручной проход по дубликатам и противоречиям. Ian Gotts даёт метафору: контекст — топливо агента, а в Формуле-1 больше всего регламентируют и измеряют именно топливо, а не двигатель.

Отрезвляющий контекст — это аргумент за измерение

Две цифры, которые сейчас цитируют все: по данным MIT NANDA («GenAI Divide», 2025) 95% корпоративных ИИ-пилотов не дают измеримого эффекта на P&L, а Gartner прогнозирует отмену 40% agentic-AI проектов к 2027 году. Методология в докладах не разбирается, так что это ориентир, а не закон.

Важно, какой диагноз идёт следом. MIT указывает не на модели: системы не удерживают обратную связь, не адаптируются к контексту, не улучшаются со временем. То есть 95% — это не «ИИ не работает», это «никто не замкнул петлю». Ровно то, о чём говорит Ishita Daga: eval нет — значит и деградацию никто не видит.

Обратный полюс держи рядом. Cognition опубликовала внутренние цифры: доля коммитов Devin в их репозиториях выросла с 16% в январе до 80% в марте, число смерженных PR — в 7 раз за 2–3 месяца при росте штата примерно на 10%. И тут же их измеренный предел: вайб-кодинг с автомержем и без code review держит кодовую базу около 2 недель, дальше её проще выбросить. Разница между 95% провалов и 80% коммитов — не в моделях, они у всех одни. Она в том, что во втором случае есть число, которое кто-то смотрит.

Что с этим делать

Заведи long-session eval раньше, чем расширишь функциональность. Подгрузи 10 ходов реальной истории и тестируй 11-й (Arize). Единственный способ сделать поздние отказы воспроизводимыми, и он не требует инфраструктуры.

Прогоняй один и тот же вход трижды и смотри на расхождение. У Datadog так нашлись 25% «мигающих» вердиктов без разметки и экспертов; остаток в 10% маршрутизируется человеку. Стабильно неопределённые случаи — не баг, а очередь на ручную проверку.

Ставь стоп-правило по потолку, а не по мечте. Langfuse: 68% → 78% на первой итерации, пик 83%, плато 80%, стоп 15 итераций или 92%. Почти вся выгода в первом прогоне; дальше оптимизатор подгоняется под шум разметки.

Проверь раскладку контекста под KV-кэш сегодня. Стабильный префикс наверх, динамика вниз, инструменты не добавлять и не удалять на лету (маскировать). 30¢ против $3 за миллион при 30–40 вызовах на задачу — самая быстрая экономия.

Разведи слои по сроку жизни. Execution фиксируй и владей им сам; модель, промпт и набор тулов делай сменными; состояние выноси из песочницы в control plane. Промпты живут недели, execution — годы (Inngest).

Замкни петлю обратной связи, иначе ты в тех самых 95%. Лог событий «это определение неверно» (Tesla), еженедельный ревьюер поверх прогонов (Inngest), outcome-based скоринг вместо лайков, один ответственный владелец контекстного слоя (Ben AI).

Чек-лист и порядок действий

Если свести восемь разделов к одному тезису: контекст — это не то, что помещается в окно, а то, что вы решили туда положить. Всё остальное — следствия. Деградация начинается на трети окна, а не на его границе. Лишний инструмент вредит сильнее лишней тысячи токенов. Компакция экономит место и молча забирает правила. Retrieval решает большинство задач и не решает целый класс по конструкции.

Ниже — порядок, в котором это внедряют, и чек-лист для проверки того, что уже работает.

Порядок внедрения

Не пытайтесь закрыть всё сразу: первые два шага дают больше, чем остальные вместе.

Шаг 1 — Измерь то, что есть (полдня)

• Открой пустую сессию и посмотри разбивку окна до первого сообщения. Системный промпт, инструменты, MCP, файлы правил, skills.
• Если занято больше трети — проблема в конфигурации, а не в модели.
• Посчитай «шагов до деградации»: на каком ходу агент начинает вызывать бессмысленные инструменты.

Шаг 2 — Убери лишнее (1–2 дня)

• Отключи MCP-серверы, которыми не пользуешься: вред от числа инструментов начинается при свободном окне.
• Вынеси знание из файла правил в skills: сокращение файла даёт единицы процентов, перенос — десятки.
• Читай файлы с диска, а не вставляй их в чат.

Шаг 3 — Возьми компакцию под контроль (1 день)

• Поставь свой порог вместо умолчания, режь на границе хода.
• Опиши схему сводки: что сохранять обязательно (решения, а не входы).
• ПРОВЕРЬ на реальной сессии, переживают ли твои правила компакцию. Источники об этом спорят — значит, у тебя это открытый вопрос.

Шаг 4 — Подключи retrieval (неделя)

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

Шаг 5 — Память и структура (по необходимости)

• Память заводи, когда измерил нестабильность решений, а не «на всякий».
• Граф/онтологию — когда markdown перестал справляться, начиная с десятка узлов, а не с полной карты предметной области.

Шаг 6 — Эксплуатация (постоянно)

• Long-session eval: 10 ходов истории, проверяем 11-й.
• Один вход трижды: расхождение между прогонами — детектор проблем.
• Разложи контекст под KV-кэш: стабильное вверх, динамика вниз.

Чек-лист: контекст в проекте

• Знаю, сколько токенов занято до первого сообщения
• Утилизация рабочего окна держится ниже 40%
• Набор инструментов ревизован по количеству, а не по объёму
• Знание вынесено в skills; в корневом файле правил — навигация
• Skills написаны руками (сгенерированные моделью — вредят)
• Файлы читаются с диска, а не вставляются в чат
• Стабильные инструкции вверху окна, актуальное состояние внизу
• Результаты фаз сохраняются в артефакты, а не живут в истории

Чек-лист: контекст в системе

• Порог компакции задан явно, а не оставлен по умолчанию
• Схема сводки описана: что сохраняем обязательно
• Проверено на практике, что правила переживают компакцию
• Последние 5–10 ходов остаются дословными
• Retrieval подгружает по требованию; индекс без дублей
• Понятно, какие запросы retrieval не закрывает в принципе
• Память заведена под измеренную проблему, а не «чтобы была»
• Суб-агенты возвращают результат, а не суждение
• Состояние хранится вне рантайма
• Есть long-session eval и мониторинг расхождения прогонов

Пять правил, которые стоит запомнить

1. Контекст — бюджет, а не склад. Больше положить ≠ лучше работает; деградация начинается задолго до предела окна.
2. Считай инструменты, а не только токены. Сорок шесть инструментов проваливают задачу, которую девятнадцать решают при том же окне.
3. Проверяй гарантии, а не читай про них. Обещание «правила сохраняются при компакции» стоит одного теста и не стоит ни одного предположения.
4. Один агент владеет рассуждением. Суб-агенты экономят контекст, но каждая передача теряет смысл: результат бывает связным по форме и бессвязным по сути.
5. Измеряй деградацию, иначе её измерят пользователи. Прогон одного входа несколько раз ловит нестабильность дешевле, чем разметка и эксперты.

Что дальше

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

Все цифры в статье — из публичных выступлений практиков. Часть замеров лабораторные, часть — практика отдельных команд без методологии; в тексте это помечено. Проверяйте на своих данных.