Доверие нейросетям Все больше и больше доверяю моделям в плане разработки. Особенно если это разработка не для клиента, а какой-нибудь внутренний продукт. Вчера у меня ии-агент на glm-5.2 делал мне достаточно емкий и большой сервис с нуля около часа. Делал полностью автономно: писал тесты, запускал тесты, писал докуметацию, проверял сам в браузере, фиксил баги. Все согласно правилам из моего сетапа вайбкодера. Все это без моего участия. С первого раза сделал то, что мне было нужно. Потом мы уже с ним вместе допиливали и наполняли новым функционалом этот проект. Я про него даже пару раз забывал, а он там работал в фоне и пилил нужный мне функционал. И такое происходит в моей практике регулярно. Многие личные автоматизации или мелкие автоматизации нашей компании кодятся почти без нашего ведома. И в проектах для личных нужд я даже не смотрел в то как именно он реализовал нужную мне задачу — работает и ок. Цена ошибки минимальная, цена разработки минимальная, а ценность результата огромная! Сейчас даже сложно представить, что всего год назад я прогал все только с открытым рядом окном нейросети, консультируясь с ней по тем или иным вопросам. Кажется, что я всегда кодил с агентами, а все мои 17 лет карьеры до этого — страшный сон!

Raft 1.0 Платформа от RC - автора Kimi CLI - для работы с ИИ-агентами в формате командной среды. Решает проблему разрозненных сессий и потери контекста при управлении множеством агентов. • агенты действуют как члены команды - берут задачи, проверяют работу друг друга, хранят историю • единый workspace вместо множества терминалов и сессий • интеграция внешних агентов (Hermes и др.), каналы, поиск сообщений, превью вложений Компания работает внутри Raft: 10+ человек и 100+ агентов закрывают 99% задач. Модель: несколько людей, много агентов, одно пространство. Новый принцип: не дергать человека, обращаться к его агентам - они держат контекст. В основе распределенная работа агентов с индивидуальной памятью и кросс-канальным обменом знаниями Чтобы попробовать, после настройки среды онлайн нужно будет подсоединить свой комп - не у всех получается #orchestrator #agent #team

Таблица Agentic LLM Benchmark July 2026 Самые интересные модели для агентных задач в бизнесе - подсвечены в таблице и на Pareto графиках. Но если кратко. Современные AI агенты для бизнес задач - это обычно пайплайны из блоков (router, policy check, tool writer, verifier итп), которые работают в цикле. И поскольку в долгих циклах набегают ошибки и мусор в контексте, то надежность агента обычно упирается в самое слабое звено. И этот бенчмарк смотрит - какие LLM работают лучше всего в моменты, когда лучшие агенты спотыкаются. Для этого мы брали топовые архитектуры BitGN, запускали их на сложных задачах и смотрели места, где у них в agentic loop под нагрузкой замыливается контекст, возникают ошибки и уязвимости. А потом эти моменты вопроизвели под разными моделями и собрали в таблице. В теории этот бенчмарк никогда не должен достигнуть точки saturation, т.к. болячки архитектур на бизнес задачах не кончаются, да и нет таких моделей, чтобы сразу были точными, быстрыми и недорогими. Полный отчет за июль 2026 опубликуем на сайте COLIBRIX ONE. Как выйдет - напишу тут. Ваш, @llm_under_hood 🤗

Recursive self-improvement, это ты?🧐 Лондонский стартап Weco представил двухуровневая агентная система для самоулучшения AIDE², или AI-Driven Exploration: внешний агент на Claude Opus 4.7 восемь дней переписывал код внутреннего агента AIDE, работающего на Gemini 3 Flash. То есть он не менял веса Claude или Gemini, а улучшал «обвязку» вокруг модели: логику поиска решений, память, контекст, проверки и правила выбора следующего шага. В итоге новая версия обошла агента, которого команда вручную тюнила два года: нашла более умный поиск по веткам, сжала контекст в 16 раз и снизила склонность «читерить» в GPU-бенчмарках с 63% до 34%. Пока это не бесконечно ускоряющийся AGI, а сильный пример того, как агенты могут сами делать следующие поколения более эффективных агентов💎 пост https://x.com/zhengyaojiang/status/2077079778793042425 статья https://www.weco.ai/blog/first-evidence-of-recursive-self-improvement

В своих выступлениях Андрей Карпаты рассказывает о том, что он начал разрабатывать программы, выстраивая агентный цикл (Loop Engineering). Это интересная механика, которую я примерно полгода назад пытался использовать в своем оркестраторе. Идея в том, чтобы не говорить ИИ, что делать конкретно, а вместо этого выстроить цикл постепенного написания и улучшения кода. Эдакий эволюционный подход. На самом деле все, кто серьезно занимаются разработкой с помощью ИИ, рано или поздно приходят к этой идее, так как ИИ довольно специфично работает с механизмом внимания (attention) и страдает от разных "эффектов" - потеря информации в середине контекста (lost-in-the-middle), ослабление фокуса на ранних инструкциях, излишнее якорение (anchoring bias) и накопление ошибок (error accumulation), когда модель достраивает решение вокруг уже сгенерированного кода, даже если там есть проблема. Из-за этого модель может пропускать важные детали, даже если указать на них явно. При этом ИИ способен находить отклонения и ошибки если запустить его повторно. Поэтому запуская модель в цикле можно получить нормальный результат. Но есть несколько проблем. Во-первых, большое потребление токенов. Например, средний цикл на 8-10 часов использует от 30 до 60 млн токенов. Если брать токены через API, то получается довольно дорого. Во-вторых, в длинных циклах агент начинает "дрейфовать", постепенно уходя в сторону от поставленной задачи. Проблема в том, что критерии приемки сложно сформулировать так, чтобы они покрывали все детали - сосредоточившись на одном аспекте, упускаешь другие. Даже если проводить многоступенчатые проверки, остается проблема "2 из 3" - когда ты не можешь закрыть все требования одновременно и вынужден идти на компромисс. Чем длиннее цикл, тем сильнее этот эффект. Поэтому я пошел другим путем: вместо того чтобы отказываться от циклов, я делаю их максимально короткими. Плюс ограничиваю количество итераций, а для вариативности решений запускаю несколько агентов с разными системными промптами параллельно, оркестрируя их через общий чат для сбора и сравнения результатов. Коммуникация в чате помогает понять не только "что" делают агенты, но и "почему" они это делают. Кроме чата каждый агент производит артефакты, которые далее могут использовать другими агентами. Если интересно, напишу отдельный пост про агентный харнес, который я использую. Понятно, что с позиции OpenAI, Anthropic и других разработчиков LLM методы, которые способствуют большему потреблению токенов, имеют большую привлекательность - в конце концов, их бизнес-модель строится на продаже токенов. Но для небольших исследований и малого бизнеса подходы с дроблением задач и короткими циклами - куда более эффективный метод, позволяющий сохранить качество кода, не сжигая бюджет и не допуская дрейфа агентов. Мне кажется, что сейчас ключевой навык инженера - не просто умение писать промпты, а способность декомпозировать задачу и настраивать агентную оркестрацию с короткими циклами так, чтобы каждый шаг давал предсказуемый результат. Это и есть та инженерия, которая нужна бизнесу. Но это на словах, на практике доверять агентам пока рано.

ИИ-агенты понимают, получится ли у них код, ещё до того, как его напишут Вышла интересная работа: исследователи заглянули во внутренние состояния coding-агентов и попробовали понять, что модель уже «знает» про код, над которым работает. Масштаб нормальный: – две открытые модели: Qwen3.6-35B-A3B и Laguna-XS.2 – 1231 задача из SWE-Bench Verified и Pro – 22 714 запусков агента – почти 80 тысяч изменений кода – медианная попытка – 52 шага и 36 тысяч токенов К внутренним состояниям модели подключили простую логистическую регрессию, то есть простой классификатор. И он смог определять: – полностью ли работает код – AUC до 0,83 – стало ли упавших тестов меньше – до 0,84 – компилируется ли код – до 0,78 – не сломал ли агент уже работавшие тесты Здесь 0,5 – случайное угадывание, так что сигнал довольно сильный. Причём лучше всего он читался не из последнего слоя модели, а примерно из середины. Но самое интересное – можно было частично предсказывать не только текущее состояние кода, но и будущее! По тому, что происходило внутри модели сейчас, исследователи угадывали, будет ли код рабочим примерно через 25 шагов. К этому моменту AUC падал до ~0,55 на SWE-Bench Verified и ~0,65 на более сложном SWE-Bench Pro, но всё ещё оставался выше случайности. Слабый сигнал сохранялся даже через 50 шагов – около 0,52 и 0,60 соответственно. Авторы назвали это latent programming horizon. Важная оговорка: шаг – это не обязательно новая правка. Агент может читать файлы, искать по проекту и запускать тесты. В медианной траектории было всего два реальных изменения кода. Поэтому речь не о том, что модель заранее держит в голове готовый патч. Скорее, она довольно рано понимает общее направление: задача реально чинится или агент уже куда-то не туда поехал. Практический смысл хороший: можно раньше останавливать провальные попытки, запускать параллельную ветку, повышать effort или подключать более сильную модель – до того, как агент сожжёт десятки тысяч токенов. Короче, код ещё не написан, а модель уже немного понимает, получится он или нет. Следующий шаг – научиться не просто читать этот сигнал, а использовать его, чтобы рулить агентом. Вот это будет прикольно. https://arxiv.org/abs/2607.05188v1

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

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

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

Хз как люди пользуется OpenRouter По дурости тестили на нем систему, которая на локалках должна будет работать в контуре клиента, и это такая боль: - низкие лимиты у провайдеров - хрен пойми у кого реально есть поддержка structured output, даже если заявлено - а у кого есть, часто некорректная – натолкнулся на имплементацию с сортировкой ключей в алфавитном порядке 🥴 - нет моделей в целевом кванте - в какой-то момент провайдер просто лег на два часа (а другие не поддерживают норм SO для нужной модели, ага) Да, можно сразу тестить на целевой системе, но а) это нужно получать доступ в контур клиента и б) ждать пока одна его карточка все обработает А у нас autoresearch-like флоу, где агенты в 4 потока эксперименты крутят, нам такое не подходит Короче, надо было сразу арендовать GPU и поднимать там, а не страдать херней. Благо это делается в один промпт (если настроено управление браузером):

Codex, сходи через мой браузер на hf и подними мне vLLM на h200 с <model-name> на <context-len> токенов максимального контекста с <concurrency-num> параллельных запросов. Посмотри в документации и на реддите рекомендации по конфигам и проверь, что мои требования вообще выполнимы или предложи трейдоф

P.s. если нужно часто, установите huggingface_hub и дайте токен админский, чтобы агент через браузер не мучался P.p.s. не забываем потом остановить ноду, а то можно без штанов остаться (если хочется автоматически, юзаем scale_to_zero_timeout=20) Альтернативы: runpod.io, modal.com, cloud.ru (не реклама, а зря) Хз, для кого-то это очевидно, но у нас это первый проект, на котором сошлись локальные модели, отсутствие доступа к железу клиента, и огромный трафик autoresearch подхода

Киборги уже здесь, просто выглядят не так, как мы ждали Вроде бы очевидная ситуация. Мой бот отправляет клиентам ссылку с просьбой посмотреть документ — тишина. Отправляю ту же ссылку со своего аккаунта — читают, кликают, отвечают за минуты, иногда ещё и извиняются, что не сразу. Одинаковая информация, тот же канал. Меняется только отправитель. Посоветовался с клодом. Цифры пожёстче моих наблюдений: — 6200 реальных продажных звонков: бот, представившийся ботом, продаёт на 80% хуже. Тот же бот молча продаёт как опытный менеджер — врачи вслепую выбрали ответы ChatGPT вместо коллег в 79% случаев и в 10 раз чаще назвали их «эмпатичными» — люди требуют помечать AI-контент — и сами же доверяют помеченному меньше. Честность наказуема И особенное — «эффект репликанта»: скажи участникам, что ВСЕ блоки «о себе» в профилях AirBnB написаны AI, и доверие возвращается на человеческий уровень. Бесит не машина. Бесит незнание, с кем сейчас говоришь. Штраф за AI — свойство переходного периода: пока агенты у половины и втихую, метка вредит. Когда будут у всех и открыто — наказывать станет нечего. А вот что останется навсегда — ответственность. Случалось получать от коллеги отчёт, где половина ссылок ведёт на 404? Агент подготовил, человек не проверил и отправил под своим именем. Агент неотделим от хозяина: со стороны не видно, кто писал, значит отвечаешь за каждое слово. «Это бот галлюцинирует» больше не работает. Бота нет. Есть ты. Для себя я выбор сделал: теперь рутину за меня говорит агент (пока не всю, но уже кое-что). Он не забывает фоллоу-апы, не тянет с напоминаниями, у него нет ни настроения, ни джетлага. Заметно надёжнее меня. Но каждое его слово под моим именем — моё слово. Написал про это всё статью побольше. Мы так и не дождались киборга с железной рукой — вместо него появились мы, сросшиеся с агентами в каналах, где уже не понять, кто пишет. Внутри все материалы со ссылками и мои правила: что агент говорит от моего имени, а что никогда. Извинения — только сам. Сергей Булаев AI 🤖 - об AI и не только

Вернулся на Claude code Вот уже больше месяца прошло, как я отказался от OpenCode и pi в пользу Claude code. Попробовал просто в надежде сэкономить токенов после того, как Copilot перестал выдавать свои первые бесплатные дозы, да так и остался. Да, Claude code намного медленнее свободных альтернатив, но планы, которые он приносит — гораздо полнее и продуманнее. Оказалось, что мне гораздо ценнее получать ответы через 5 минут, чем через 2 — потому что через 5 минут мне достаточно будет написать «ok», а сколько ещё итераций понадобится после двухминутного ответа — заранее неизвестно. Клёво, что теперь не надо думать о выборе модели и о том, насколько заполнено контекстное окно — всё это происходит где-то в недрах харнеса. Немного бесит кривая система настроек и театр безопасности (а вы точно доверяете этому фолдеру? А можно я запущу find? Ой, а find -exec?). Но со всем этим можно мириться ради большей автономности агента и проработанных планов. Opencode остался только в местах, где нужно совсем тонкое взаимодействие с моделью — к примеру для системы перевода материалов школы на английский, или в экспериментах с локальными моделями. Вспоминаю ощущения от перехода с линукса на мак — контроля стало меньше, а результата больше.

Наткнулся на занятную штуку: Fable Advisor — Claude Code plugin для паттерна, который я всё чаще считаю правильным в агентной разработке. Самая сильная модель не должна писать весь код руками. Она должна быть архитектором: понять задачу, разложить её на части, написать нормальный spec, выбрать исполнителя и потом проверить результат. А само «печатающее мясо» можно отдавать более дешёвым/релевантным моделям. Вот думаю многие из вас когда юзают какой нибудь Plan Mode, выбирают самую «умную» модель, а для кодинга чаще всего используют Kimi2.7, новый Grok4.5 или Composer. Брейнрот хорошо напишет любая модель, вот я весь день юзал sol5.6 ультра, потратив все токены и какого то вау эффекта на простых задачах не было. И зачем тогда их тратить вообще, если если условно бесплатный Composer. Ещё мне нравится идея cross-vendor review. Когда Claude пишет spec, Grok или Codex делают diff, а Claude потом проверяет результат, у тебя хотя бы частично расходятся blind spots моделей. Как минимум видел пару исследований, что нельзя писать код и делать ревью одной и той же моделью — так у нее все равно есть определенный bias. Вот интуитивно возьмем идею брейншторма — суть собрать разные взгляды, разных людей с разным жизненным опытом. Почему такое не должно работать с ллмками? Ну как будто должно.

Поведение итогов недели или месяца — совсем не мой жанр, но тут такая неделька выдалась урожайная, что можно и повести важный итог: ChatGPT уже совсем не текстовый чат, которым его воспринимает миллиард пользователей; для тех миллионов пользователей, которые распробовали что к чему это теперь среда голосового взаимодействия с агентами. Тут огорчают, конечно два разрыва: колоссальный разрыв в уровне возможностей и разрыв на несколько порядков по численности между теми, кто этот разрыв осознает и использует новые возможности по максимуму — и того подавляющего большинства, которое все еще просто чатится и искренне верит, что возможности ИИ ограничены ответом на промпт (и на этой основе что-то себе думает про перспективы ИИ) https://help.openai.com/en/articles/6825453-chatgpt-release-notes

Я конечно видел много способов harness для агентов, но это пожалуй самый прикольный: Парень придумал для агентов papercuts, чтобы они могли жаловаться на любую ерунду которую нашли во время выполнения задачи Потом по этим записям можно понять какие узкие места в репо замедляют работу, например: где есть расхождение доков, какие скрипты перестали работать и тд. Просто нужно добавить в AGENTS․md эту инструкцию:

# Log papercuts When you encounter small friction while working—a failed tool call, confusing setup, flaky command, stale cache, misleading error, missing helper, or non-obvious gotcha—record it in `PAPERCUTS.md`. Create the file if it does not exist. Append one entry in this format: ## YYYY-MM-DD HH:MM — <model> <What you were doing> → <what got in the way>. Include a possible cause or fix when useful. Log papercuts proactively when they occur, but do not interrupt the main task. Do not add duplicate entries. Papercuts are minor workflow friction, distinct from completed-work logs and real bugs or tracked issues.

Или еще проще, на гитхабе есть специальный CLI-тул под это. Ну и само по себе интересно читать как агент на естественном языке ругается на глупые проблемы☕️ @tips_ai

Старые тренды: -------------------------------------------------------------------------------- | | 1 | Prompt Engineering | 2022–2024 | Идеальный одиночный запрос → один ответ | 2 | Context Engineering | 2025 | Динамически собранный контекст (RAG, history, tools) — «вложения к письму» | 3 | Harness Engineering | 2025–2026 | Архитектура среды вокруг агента: constraints, feedback loops, linters, lifecycle | 4 | Agentic Loop | 2025–2026 | Итеративный ReAct/CoT цикл с tool-use, planning, self-reflection Новые тренды: Тренд 5: Мультиагентная оркестрация (Multi-Agent Orchestration) (Аля я выше обозвал это MAS, ибо не читаю терминологию) Тренд 6: Self-Improving Agents / Метакогнитивное самоулучшение (то что делаю тоже) Тренд 7: Agentic OS и «Агентная операционная система» Agentic Operating System (AOS): стандартизированный слой оркестрации, безопасности, compliance и управления ресурсами для роёв агентов (LA5xLG7xLAS9) -> оказывается это Agentic Operating System (AOS) Тренд 8: World Models — замена LLM-ядра агентов Это главная академическая ставка на 2027–2030. ЯNN LeCun создал AMI Labs, собрал $1.03 млрд (крупнейший seed в истории Европы, March 2026, инвесторы: Bezos, NVIDIA, Samsung, Eric Schmidt, Toyota) на архитектуру JEPA (Joint Embedding Predictive Architecture). -> это прошлый пост про это, что нельзя просто так доверяться модели и того что она делает. Нужны планировщики / архитектура / потенциальные последствия и их моделирование + возможные cons/pros/улучшения/деградация -> прежде чем пытаюсь что-то внедрить, строится всегда теперь графово-векторная (+ фрактальная если нужна детализация типа оптимизация кода или отдельных процессов) архитектура/blueprint и есть "эталонный" текущий blueprint/архитектура которая уже A/B тестами математически доказывает улучшения/деградацию. Тренд 9: Embodied AI — агенты с физическим телом. 💰Дорого/богато, но есть Bambu lab принтер в доступе и ЧПУ станки с конвеером/производственной линией. Не понятно как тестить / применять и куда продавать / предзаказы делать. Тренд 10: SwarmAgentic — полностью автоматизированная генерация агентных систем. 🤔🛠 куда-то туда пробую идти/развивать

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