Хотя про AI-агентов сейчас пишут буквально из каждого утюга, в этой статье мне особенно зацепился один момент — визуализация зависимости качества ответов LLM от длины контекста. Интуитивно мы все чувствуем, что «чем больше — тем лучше», но на практике кривая выглядит иначе: после определённого порога контекст начинает не помогать, а мешать. Сигнал тонет в шуме, модель теряет фокус, а качество решений деградирует. Забрал эту картинку себе в копилку как хорошее напоминание. Из этого логично вытекает важный тезис: формулировка задачи вторична, первична политика контекста. Не «как красиво спросить», а что именно и в каком объёме сейчас действительно нужно модели. Принцип «минимум, достаточный для текущего шага» оказывается куда более надёжным, чем попытка загрузить в контекст всё возможное «на всякий случай». Отдельно понравилась мысль про инструменты. Да, туллинг расширяет возможности LLM, но каждый их вывод — это ещё один удар по контекстному бюджету. Если инструменты шумят, возвращают избыточные данные или нестабильный формат, агент быстро начинает деградировать. Поэтому критичны строгие контракты, малый, предсказуемый и структурированный вывод — иначе инструменты становятся источником энтропии, а не силы. История сообщений — ещё одна зона инженерной ответственности. Хранить всё подряд — плохая стратегия. Актуальное должно быть доступно, «закрытые» куски — сжаты и зафиксированы в виде состояния, всё остальное — безжалостно отброшено. Контекст — не лог событий, а рабочая память, и к ней применимы те же принципы, что и к архитектуре систем. Итог для меня простой: контекст-инжиниринг — это полноценная дисциплина проектирования. Каждая загрузка в окно контекста — осознанное решение с ограничениями. Надёжность агента обеспечивается не магией промпта, а управлением информационным бюджетом, продуманной retrieval-стратегией и регулярной компакцией состояния. Именно здесь сейчас проходит граница между «демо» и реально работающими агентными системами. https://newsletter.systemdesign.one/p/what-is-context-engineering