Почему AI агенты не делают продакта эффективнее Если вы всерьез пытаетесь делегировать *значимую* (значимую – это такую, без которой не обойтись, а не какую-то фигню, которую вы до этого не делали, и без этого никто не страдал) часть своей продуктовой работы агенту, то вас будут ограничивать две вещи: - интеграция агента с рабочими системами (то есть, наличие MCP и прав доступа) - информационный контекст. Про интеграции мы с вами уже немного поговорили – это ад, особенно для корпоративных систем, где безопасники несут вахту. Но это ад предсказуемый, который мы в горизонте пары лет скорее всего победим. Давайте сегодня поговорим про то, почему у агента не хватает контекста, чтобы решать ваши рабочие задачи. Для того, чтобы сделать почти любое осмысленное действие по проекту, агенту нужен будет полный и актуальный статус. Что уже случилось до текущего момента, и какие дальнейшие шаги ожидаются. Но актуального статуса проектов нигде не существует в готовом виде! - Где-то на диске лежит PRD, но он потерял актуальность в тот момент, когда над проектом пошла активная работа - В Jira есть задачи даже со ссылками на коммиты, но это лишь часть истории - Есть расшифровки встреч (но не всех), оттуда попробуй извлеки точно о чем стороны договорились - Есть чатики в корпоративном мессендежре: личные сообщения, канал команды, чатик проекта (тут я передаю пламенный привет любителям создавать новый чатик с рандомным набором участников на каждый чих. В аду для вас уготован отдельный котел, который будет называться "Алексей Иванов, Иван Пертров, Елена Головач... и др.") - И если до этого пункта у вас еще теплилась надежда, что все это можно как-то структурировать и организовать, то в этот момент мимо вашего стола проходит разработчик и говорит "Кстати, по задаче, про которую ты спрашивал – она заблокинована, мне нужно прокинуть название use case из upstream сервиса", и окончательно убивает надежду. Этот самый полный контекст проекта поразительным образом существует у вас в голове, потому что ваш мозг, получая каждый новый сигнал, обновляет текущий статус. Но как только я сажусь делегировать задачу AI ассистенту, я осознаю, как много информации либо вообще не отражено в цифровом мире, либо погребены в такой помойке human слопа, что и за сто тысяч токенов не извлечешь. И это, на мой взгляд, наибольший барьер внедрения AI в рабочие процессы продакта на данный момент. Это то, почему продакт, приручивший Claude, пока не может значительно выигрывать у своего коллеги-луддита с блокнотиком и карандашом. Расскажите в комментах ощущаете ли вы тоже эту проблему и как с ней боретесь? На мой взгляд решение может выглядеть как second brain система. В следующем посте я порассуждаю о том, как она могла бы выглядеть и что уже удалось построить.

Раньше по дефолту в Codex у GPT-5.6 Sol окно контекста было ограничено конфигом на 272к токенов Но теперь его можно расширить до 1 млн токенов. Вставьте это в конфиг:

model = "gpt-5.6-sol" model_context_window = 1000000 model_auto_compact_token_limit = 900000

Или если нужно только на одну сессию:

codex -m gpt-5.6-sol \ -c model_context_window=1000000 \ -c model_auto_compact_token_limit=900000

Эти строчки расширяют контекст у 5.6 Sol до 1 млн токенов, и ставят авто-компакт на 900к, чтобы был запас под системный контекст И в CLI и в десктопной версии Подглядел у Tibo (руководитель OpenAI), только имейте ввиду что токены за пределами дефолтного окна считаются как x2, и тратят больше лимита ☕️ @tips_ai

С начала года я активно пилю свой иишный «второй мозг». Сначала он вырос из моего личного дневника в накопленный контекст жизни, для более качественных ответов с ИИ в чатике. Потом поверх него начал достраиваться контекст по проектам, CRM контактов, доступ к звонкам, телеге, дашбордам и разные агенты, которые помогают принимать решения, трекать меня по целям и задачам. Сейчас я пытаюсь формировать такие контексты для проектов, в том числе, чтобы к ним могли подключаться сотрудники. Для его разработки и обучения сотрудников нанял штатного вайбкодера и сам очень много рисерчу. В основном у западных компаний. Недавно наткнулся Грега Айзенберга, основателя Late Checkout ($100M+ выручка). Он описал, как сегодня выглядит оргчат его бизнесе. В управлении тонкий слой людей, отвечающих за стратегию, креатив и суждения. Под ним широкий слой AI-агентов: саппорт, продажи, исследования, маркетинг, операции. Управление людьми всё больше превращается в управление агентами, а управление агентами в управление и создание контекста. По его мнениею, контекст — это и есть компания, общий мозг, к которому подключены люди и AI. Люди приходят и уходят, агенты меняются и устаревают, а контекст остаётся, накапливается и развивается. Управление его компанией, это способность сохранять и управлять контекстом, который ускоряет и людей, и агентов. Возможно, пока чуть сложно и абстракно звучит, но я все больше в этом убеждаюсь по мере развития собственного «второго мозга». Как-нибудь сделаем эфир и покажу как все это выглядит.

Context-1 — поисковый агент, который умеет избавляться от лишнего. Часть 1/2 Авторы сегодняшней статьи заявляют следующую проблему. Когда агент ищет что-то в поиске, то нерелевантные страницы, выданные браузером, всё равно остаются в контексте агента. Чтобы справиться с этим, контекст можно обрезать или суммировать. Ещё одно весьма перспективное направление в этой области — self-editing context, при котором модель сама определяет, что ей нужно для решения задачи и может отбрасывать бесполезные документы. Этот подход авторы статьи и берут за основу своего субагента Context-1, построенного на модели в 20B параметров. В его арсенале есть четыре инструмента. Первый, search_corpus(query), позволяет оценивать релевантность документа: отбирается 50 документов, ранжируются, самые подходящие отправляются модели в рамках доступного бюджета токенов. Инструмент grep_corpus(pattern) проводит поиск с помощью регулярных выражений, read_document(doc_id) нужен, чтобы прочитать документ. Самый интересный из инструментов — prune_chunks(chunk_ids), который даёт модели возможность убрать какие-то фрагменты из контекста с сохранением траектории. После каждого шага модели сообщается, сколько токенов у неё осталось. Когда контекст заполнен наполовину, модель советуют освободить его, — но только на обучении, не на инференсе. После преодоления какого-то порога по токенам, модель начинает получать отбивку о необходимости почистить контекст на каждый запрос вызова инструментов для получения новых документов. В этом случае модель либо должна выдать ответ, либо запустить prune_chunks(chunk_ids). Авторы придумали, как генерировать синтетические данные для RL с возрастанием по сложности. Генерация происходит в пять стадий: Gather supporting documents — сбор сопутствующих документов, которые содержат уникальные факты на основе заданного сида. В статье приводится пример с сидом «Синагоги в Брюсселе», по которому модель собрала факты вроде «Синагоги выполнены в романо-византийском стиле». Generate clues (obfuscated references to facts) — собранные на первом этапе факты встраиваются в одну задачу, загадку, где разные сущности заменены фактами. Так, вместо, собственно, «синагога» в этом тексте будет сказано «религиозные сооружения в романо-византийском стиле». Verify that the task is valid — этап проверки, что в сопутствующих документах есть подсказки, ведущие к ответу. То есть в каком-то из документов должно быть прямо сказано, что «синагога — это религиозное сооружение в романо-византийском стиле». Проверка осуществляется не с помощью LLM, а просто кодом на Python. Optionally, collect distractors — опциональное добавление в базу документов-дистракторов. Важно, чтобы они не только вели модель по ложному пути, но и случайно не содержали правильных ответов. Optionally, recursively chain — опциональная генерация задач, которые связаны с прошлыми задачами. Так получается синта, которую нужно решать в несколько шагов. Во второй части поговорим об обучении и результатах. Разбор подготовил ❣ Владислав Пыж Душный NLP

Хороший разбор вреда от попыток сэкономить токены или как-то еще модифицировать ответы агентов, типа "Говори со мной как пещерный человек" или "говори со мной на упрощенном техническом английском". Переформулируя и сжимая ответ, агент неизбежно что-то выбрасывает из вывода и это может быть важная информация. У меня, кстати, наоборот, включен Explanatory стиль в Claude Code и я регулярно по таким фразам отлавливаю дрейф агента от цели. Излишнего расхода контекста от этого не возникает. Если хочется экономить, включите себе в статусной строке Claude Code отображение записи в кэш и чтения оттуда — как только поймаете момент, когда модель пишет в кэш 400к токенов после простоя, сразу поймете, от чего реально тратится контекст, а что является только гиковской гомеопатией. https://kuber.studio/blog/Reflections/Humanising-LLM-Outputs-is-Actually-Dumb

AgentFold — метод управления контекстом для агентов на длинных задачах На длинных сценариях поиска и анализа веб-агенты либо хранят слишком много сырой информации, либо слишком часто её суммаризируют, что забивает контекст. Авторы сегодняшней статьи предлагают метод AgentFold (GitHub), призванный решить эту проблему, сделав память агента динамической и управляемой самим агентом. Сейчас в веб-поиске используются два подхода. Первый — это ReAct, при котором все действия и решения конкатенируются в конец контекста. Благодаря этому ничего не теряется, но и контекстное окно забивается очень быстро. Второй подход — суммаризация на каждом шаге, однако при этом какая-то часть информации неизменно теряется. Ключевая идея AgentFold — создание активного и динамически пересчитываемого контекста для каждого следующего шага. То есть агент самостоятельно выбирает, что нужно запомнить точно, а что можно суммаризовать. Авторы отмечают, что они вдохновлялись человеческой способностью к осмыслению собственного опыта. В статье предлагается модифицировать и контекст, и то, в каком формате выдается ответ. Контекст должен состоять из следующих элементов: • Question — исходный вопрос; • Tools — доступные инструменты; • Multi-Scale State Summaries — свёрнутые блоки прошлых шагов. Например, шаги с первого по третий представлены одним блоком. При этом свёрнутым может быть и один шаг; • Latest Interaction — последний полный шаг. Суть в том, что все предыдущие действия хранятся в сжатом виде, а последнее — в подробном. Это позволяет меньше загружать контекст. Что касается ответа, то тут модель должна сперва размышлять, а потом делать фолдинг шагов. Он может быть гранулярным (granular) или глубоким (deep). В первом случае схлопывается только последний шаг, а во втором — целая ветка (например, «шаги с четвёртого по девятый»). После фолдинга идёт этап, на котором модель объясняет, почему объединила шаги именно так, как объединила. Наконец, вызываются инструменты и совершаются какие-либо действия. Для обучения всему вышеописанному, авторы брали вопросы из WebSailor и отправляли их во внешние опенсорсные модели (GLM-4.5 и DeepSeek-V3.1), чтобы построить контекст конкретного шага. При этом о том, как генерируются данные, не сообщается. Далее авторы генерировали ответ, выполняли действие, получали ответ от среды и собирали следующий шаг траектории. Проблема в том, что LLM сами не умеют сжимать контекст, что ведёт к ошибкам, галлюцинациям и тому подобному. Неправильные решения авторы отбрасывали, но как — в статье не описывается. Итоговый датасет представляет собой не набор пар «вопрос-ответ», а выборочный набор пар взаимодействия (intersection pairs), удовлетворяющих определённым условиям. На эти пары делается SFT. Согласно результатам замеров, AgentFold помогает снизить нагрузку на контекст к сотому шагу на 91% по сравнению с ReAct. При этом с увеличением числа шагов точность, как сообщают авторы, только растёт. Разбор подготовил ❣ Антон Гырдымов Душный NLP

Одну важную вещь я поймал на днях с AI консилиумами: когда вы просите консилиум дать свое мнение по определенному вопросу, то важно правильно ограничить видимость агентов; в противном случае - они прочитают факт/вывод в папке проекта и выдадут один и тот же, уже известный ответ. И тогда вся идея разнообразия мнений разбивается о стенку Что у меня произошло: Я в течение 4 дней исследовал одну проблему на пару с дружбаном - why-tree, просмотр сессий и тп. И на какой-то из итераций с консилиумом я заметил, что они стали оперировать фактами, которые им не должны были быть известны. Тут можно было подумать, что они или гении, или нагаллюцинировали... Начал копать и заметил, что у некоторых участников подозрительно много вызовов тулов —> выяснилось, что поскольку у них были тулы, чтобы читать файлы - то они решили, прежде чем дать свое мнение, почитать все что есть в проекте, ну и наткнулись на этот контекст, а далее уже было достаточно сложно их мнение "разнообразить". К слову, цитата из моего поста 3 года назад:

В Empatika Open, посвященной моему обучению в Stanford, я рассказывал про неприятный феномен групповых обсуждений, когда участники фокусируются на общем знании, теряя уникальное знание каждого. Как снизить вероятность такого поведения?

Собственно, именно таким неосторожным загрязнением (contamination) контекста мы и можем предопределить однообразие мнений участников консилиума - как человеческих, так и AI. Как лечится? 1) можно ограничить тулы, что даете субагентам (не давать им читать файлы) 2) явно попросить закарантинить файлы, которые им не должны быть доступны 3) давать разные задачи участникам - "опровергни", "найди чего не хватает", "перепроверь цифры", "скажи, что тебя переубедит" Attention is all you need 😉 P.S. Скилл я, разумеется, по мотивам проапдейтил, но пару седых волос точно прибавилось

ICML 2026: как агенты справляются с контекстом Об агентах и агентских системах в этом году говорили примерно все — тема стала одним из фокусов конференции. Главные тренды и новости собрала наша коллега Кристина Гуртова.

Было много работ о бенчмарках и диагностике агентов — пожалуй, самый крупный кластер. Пользовались популярностью мультиагентные системы и их обучение, agentic RL и tool use. Отдельное активное направление — safety. Общий тренд: рассматривать агента как инженерную систему, где каждый компонент (среда, обучение, оценка или память) становится отдельным объектом оптимизации. А я углублюсь в актуальную проблему агентов: как не захлебнуться в собственном контексте. Сжимать его, сворачивать или выносить во вне? Путь 1. Агент сам решает, что исключить из истории Раньше агент линейно накапливал всю историю в один растущий контекст. Теперь — он ей управляет. В Context-Folding (CMU, Stanford, ByteDance) агент разветвляет подзадачи с помощью двух тулколов: branch() создаёт подзадачу, return() возвращает итог этой подзадачи. Промежуточные шаги не попадают в основной контекст. В Agent-Omit (HKUST) авторы посчитали, что размышления съедают около 45% токенов, наблюдения — 52%, а действия — всего 3%, поэтому их статья сфокусирована на сокращении ризонинга. Агент выборочно опускает свои мысли и наблюдения. Conversational Inertia (ZJU, Ant) описывает отдельный побочный эффект длинной истории — «инерцию». Агент начинает имитировать собственные прошлые ответы как few-shot и перестаёт исследовать. Проблема лечится периодической очисткой истории. Путь 2. Сжатие контекста — оптимизируемый навык, а не фиксированное правило ACON (KAIST, Microsoft) оптимизирует не веса, а промпт для сжатия. Авторы собирают трейсы с полной и сжатой историей, сравнивают их с помощью LLM-критика и дополняют этим промпт. Затем дистиллирует такой навык компрессии в маленькую модель и используют его. Путь 3. Внешняя память и переиспользование опыта Ещё один вариант — не выбрасывать, а сохранять надолго. EAM держит память как граф знаний, где узлы — это состояния системы, а рёбра — действия для перехода между ними. Darwinian Memory — training-free память, где записи конкурируют за «выживание». Полезные переиспользуются, устаревшие и ненадёжные удаляются. SE-GA хранит три вида памяти: эпизодическую, семантическую и экспериенциальную. Агент достаёт малую часть из каждой из них, добавляя к себе в контекст. UMEM (Xiamen, Alibaba) обучают внешнюю модель работать с банком памяти. Для этого они замораживают модель-агента и обучают отдельный оптимизатор, что записать, обновить и удалить. Отдельно — как это честно мерить. AMA-Bench проверяет память в реальных агентных траекториях, а не на сырых диалогах, и дополнительно показывает, что многие memory-системы пока проигрывают простому long-context.

#YaICML2026 Душный NLP