● HABR WEEKLY DIGEST · AI / AGENTS / LLM

AI-статьи недели с Хабра

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

🗓 окно 3–10 августа 2026 ⚡ статей: 9 👀 на заметку: 4 📡 отсканировано: 110
📝 О чём пишут на этой неделе

Хабр на этой неделе писал не про модели, а про обвязку вокруг них: гейты ревью, границы полномочий, бюджет инструментов, трассировку вызовов. У голосового агента 1 200 мс из 1 275 съедал таймер тишины, а не модель. У агента с 331 инструментом одни только JSON-схемы заняли 302 КБ — около 75 тысяч токенов в префиксе каждого запроса. Почти в каждой статье есть цифра до и после, а у четырёх из девяти — репозиторий, который можно развернуть у себя: неделя замеров, а не мнений.

⚡

Главные статьи недели

01

Голосовой агент молчит секунду впустую: 1 200 мс из 1 275 — это таймер тишины

✍ OstapAndreevich Хабр ⏱ ≈6 мин голосовые агенты endpointing Realtime API
О чём

Все голосовые платформы решают, что человек договорил, по таймеру тишины. Автор замерил цену этого решения на живой русской речи через Yandex Realtime API (протокол совместим с OpenAI Realtime) и заменил фиксированный таймер детектором на правилах русского синтаксиса. Если вы строите голосового агента, то задержка, на которую жалуются пользователи, живёт не в модели — и статья показывает, где именно.

🔑 Главное
  • Из 1 275 мс до первого звука ответа 1 200 мс — ожидание таймера, и только 75 мс — распознавание, генерация ответа и синтез речи вместе.
  • На порогах silence_duration_ms 400 и 800 мс агент отвечал почти мгновенно, но слышал только «Здравствуйте»: VAD коммитил буфер в естественной паузе, остальная фраза уходила в следующий ход или в никуда.
  • Порог 1 200 мс тоже недетерминирован: из семи голосов, прогнанных одной фразой, три получили ответ «Здравствуйте, чем могу помочь?» вместо ответа по делу.
  • Детектор на правилах не отменяет таймер, а выбирает его по распознанному тексту: договорил — 250 мс, висящее служебное слово — 1 400 мс, непонятно — 700 мс. Итог — 316 мс и два обрыва вместо тридцати восьми.
  • Правила ловят пять случаев: висящие союзы и предлоги, инфинитив без дополнения, приветствия-анонсы, заминки и диктовку номера (семь числительных подряд с конца — номер назван целиком). Разговорные хвосты вопроса вроде «а по цене что» проверяются раньше правила о служебных словах.
⚡ Попробовать за вечер
  • Синтезировать одну типовую фразу с паузой после приветствия, срезать хвостовую тишину и подавать в свой Realtime API кусками по 20 мс, меняя только silence_duration_ms: 400, 800, 1 200.
  • Замерить время от последнего отправленного чанка речи до первого чанка аудио в ответе и отдельно записать, что агент вообще расслышал.
  • Добавить перед коммитом буфера проверку последнего слова по списку висящих служебных слов и переключать короткий или длинный порог.
  • Метрика: доля прогонов, где агент ответил на полную фразу, а не на приветствие, — при задержке ниже секунды.
Столбчатая диаграмма: таймеры 400, 800 и 1200 мс против детектора по смыслу — задержка и число обрывов фразы из статьи
На картинке: четыре режима на 72 репликах. Таймеры 400 и 800 мс — 38 обрывов фразы, 1 200 мс — ноль обрывов ценой секунды тишины, детектор по смыслу — 316 мс и два обрыва.
🔗 Читать на Хабре Обсуждение
02

33 агента на одном образе: всё решает граница между кодом и моделью

✍ hamidun Хабр ⏱ ≈28 мин ии-агенты промпт-инжиниринг python
О чём

За год автор собрал 33 агента — от шахматного тренера для ребёнка до ботов металлургического холдинга — и все они живут на одном Docker-образе без единой правки ядра. Различаются они тем, где у каждого проходит граница между тем, что считает код, и тем, что говорит модель. Здесь есть то, чего почти нет в статьях про агентов: замеры промпта и схем инструментов в цифрах, плюс разбор мест, где автор провёл границу неправильно.

🔑 Главное
  • Агент — это том, а не форк: образ один, а SOUL.md, config.yaml, plugins/, skills/, state.db и cron/jobs.json лежат в /opt/data. Новый агент — копия каталога в новый том.
  • Схемы инструментов обгоняют промпт после третьего десятка инструментов: у внутреннего CRM-админа с 331 инструментом 302 КБ JSON-схем — порядка 75 тысяч токенов в префиксе каждого запроса.
  • Три правки конфига тьютора (узкий профиль инструментов, отключённая проба окружения, выключенный reasoning) дали 15 266 → 1 424 токена промпта и медиану ответа 17 → 7,7 с. Токены режет тулсет, задержку — режим модели: рычаги разные, мерить надо оба.
  • Дата в промпте стоит с точностью до дня, а не до минуты: иначе на каждом запросе рвётся префиксный кэш провайдера.
  • MCP не использует ни один из 33: JSON-схемы у плагина и MCP-сервера одинаковые, а плагин дешевле по эксплуатации. Обратная сторона — секреты лежат в окружении процесса, поэтому плагины и терминал в одном агенте держать нельзя.
  • На демо-контуре клиента тулсет не урезали, и модель собрала себе OCR-пайплайн через терминал с доустановкой пакетов. Отдельная засада: при явно отключённом терминале остаётся execute_code — он в другом наборе.
  • Толщина персоны зависит не от предметной области, а от числа поверхностей и ролей: у шахматного тренера около 1,5 К токенов, у наставника интенсива — около 23 К.
⚡ Попробовать за вечер
  • Посчитать байты JSON-схем своего тулсета и перевести в токены — это цена префикса каждого запроса; в Hermes для этого есть офлайн-команда hermes prompt-size.
  • Собрать узкий профиль инструментов под одну задачу, выкинув всё, что она не вызывает, и замерить prompt_tokens до и после.
  • Отдельным шагом выключить reasoning и снова снять медиану ответа, чтобы не смешать два рычага в одну цифру.
  • Пройти по своим наборам инструментов и проверить, не остаётся ли исполнение кода в другом наборе при отключённом терминале.
  • Метрика: prompt_tokens на запрос и медиана ответа — замеренные по отдельности для тулсета и для режима модели.
🔗 Читать на Хабре Обсуждение
03

Восемь шагов и второй вендор: харнесс, где Claude пишет, а Codex не пускает в master

✍ gudrymudving Хабр ⏱ ≈15 мин claude code codex spec-driven development
О чём

Соло-разработчик показывает обвязку, через которую проходит каждая задача его Electron-заметочника: четыре класса задач, восемь шагов и вторая модель в роли ревьюера, которая не пишет код никогда. За 56 дней от первого коммита набралось 1 393 коммита и без малого три сотни файлов спецификаций. Каждый гейт здесь вырос из конкретного инцидента, и автор перечисляет эти инциденты по одному — читать полезнее, чем цифры.

🔑 Главное
  • Роли разведены жёстко: Claude Code пишет спеки, код и тесты, Codex работает строго read-only и возвращает только комментарии. Второй вендор находит около десяти процентов багов сверх того, что ловит ревью тем же Claude в чистом контексте.
  • Задача сначала получает класс — XS, Normal, Risk, Harness-Risk — и от класса зависит число проверок. Сомневаешься между Normal и Risk — берёшь Risk; на одну Risk-задачу уходит минимум пять вызовов Codex.
  • У Risk три отдельных прохода ревью: diff — баги, регрессии и пропущенные тесты, security — IPC, SQLite, секреты и сеть, impact — скрипт строит обратный граф импортов, а модель отделяет реальные зависимости от шума.
  • Находка модели — гипотеза, а не приговор. Адъюдикация даёт три исхода: починить до коммита, отклонить с короткой причиной или подтвердить и вынести в техдолг. В отчёте остаётся поле found_by — видно, какой проход дал сигнал.
  • Спека-контракт выросла из провала TDD: модель писала кривые тесты и подгоняла под них реализацию, всё было зелёное, а закреплено не то поведение. Замечание к тексту спеки стоит копейки, то же замечание к готовому коду — переделку.
  • Ревью в чистом контексте появилось из упрямства модели: в одном контексте она защищает своё же решение, спорить бесполезно.
  • Разбор репозитория вскрыл, что CI лежал в .github/workflows, а репозиторий живёт на GitLab: барьера не существовало вовсе, хотя документация называла CI действующим. Отсюда npm run verify как единственный вход перед коммитом.
  • Мост к ревьюеру сводил все сбои к одному статусу: кончившаяся квота выглядела как сломанная авторизация, а дифф длиннее 200 тысяч символов молча обрезался и приходил со статусом OK. Неполное ревью выглядело полным.
⚡ Попробовать за вечер
  • Развести автора и ревьюера: пусть первый агент пишет, а второй получает только дифф и контракт задачи, без рассуждений автора и в отдельном процессе.
  • Свести все проверки в одну команду по образцу npm run verify — typecheck, линтер, юниты, гигиена диффа — и запретить коммит, если она не прошла.
  • Проверить свой мост к ревьюеру на честность статусов: развести «что случилось с вызовом» и «что судья вообще видел» на два разных поля.
  • Метрика: доля находок ревьюера, которые вы приняли и починили до коммита, и сколько из них не увидела своя же модель.
🔗 Читать на Хабре Обсуждение
04

Когда одного агента достаточно: таблицы выбора вместо мультиагентного театра

✍ ratnik Хабр ⏱ ≈24 мин LLM агенты мультиагентные системы LangGraph
О чём

Карта агентного стека, которая заканчивается двумя рабочими таблицами: сначала выбираешь минимальную схему управления моделью под характер задачи, потом добавляешь только те инфраструктурные слои, которые требует длительность процесса, среда исполнения и права доступа. Полезна ровно тем, что помогает не тащить мультиагентность туда, где хватит одного вызова с типизированным результатом. Примеры инструментов из мира TypeScript, но принципы от языка не зависят.

🔑 Главное
  • Огромной части приложений мультиагентность не нужна: если всё помещается в один контекст, а права и критерий успеха едины, лишние агенты добавляют только задержку и стоимость.
  • Разнообразие агентов важнее их количества — в исследовании Understanding Agent Scaling два разных агента работали не хуже шестнадцати одинаковых. Автор честно оговаривает, что это результат конкретной постановки, а не универсальная пропорция.
  • Стратегию выбирают по тому, где живёт неопределённость: следующий шаг зависит от среды — ReAct; шаги известны заранее — обычный workflow; нужно сравнить пути — поиск вроде Tree of Thoughts, но только если варианты можно надёжно оценить.
  • Supervisor–worker вместо свободного группового чата, и координатор не обязан быть LLM: при известных правилах маршрутизации обычный код справится надёжнее.
  • Память — четыре разные задачи под одним словом. Память «обо всём» даёт шум, утечки, ложные воспоминания и дорогой retrieval.
  • Фреймворки заменяют самописный glue code — цикл «модель → инструмент», состояние, handoffs, tracing, approval flow, — но не заменяют Playwright под браузерным агентом, sandbox под исполнением кода, Temporal под долгоживущим процессом и OAuth под вызовом инструмента.
⚡ Попробовать за вечер
  • Взять один свой агент и пройти первую таблицу статьи: честно ответить, нужен ли ему цикл агента или хватит одного вызова с типизированным результатом и одним tool call.
  • На каждого лишнего агента задать вопрос автора: какую новую информацию, возможность или независимую проверку он даёт. Если никакую — убрать и перезамерить.
  • Добавить ровно те слои, которые требует задача: durable runtime, если процесс живёт дольше одного HTTP-запроса, sandbox — если агент запускает код.
  • Метрика: число вызовов модели и суммарная задержка на одну пользовательскую задачу до и после упрощения схемы.
Схема: слева свободный чат нескольких агентов, справа управляемая система со слоями планирования, памяти, политик, sandbox, human in the loop и evals из статьи
На картинке: два полюса из статьи. Слева болтливая команда агентов без границ, справа — LLM в кольце слоёв: граф выполнения, память, инструменты, политики и права, sandbox, человек в контуре, evals и наблюдаемость.
🔗 Читать на Хабре Обсуждение
05

MCP закрепил traceparent: агента пора наблюдать как распределённую систему

✍ bezkod (Proto) Хабр ⏱ ≈5 мин mcp opentelemetry distributed tracing
О чём

Разбор двух событий 28 июля: редакция MCP 2026-07-28 закрепила передачу контекста трассировки по W3C Trace Context, а OpenTelemetry поставил наблюдаемость ИИ-агентов в список направлений развития. Вместе они закрывают старую дыру: вызов инструмента теперь можно проследить от модели через MCP-клиент и сервер до внешнего API. Статья короткая и чётко разделяет, что уже в стандарте, а что пока дорожная карта.

🔑 Главное
  • В поле _meta внутри params разрешены три ключа: traceparent, tracestate, baggage. Для них сделано исключение из правила DNS-префиксов — иначе реализации выбрали бы разные имена и не смогли продолжать один трейс.
  • Сам протокол спаны не создаёт: клиенты и серверы по-прежнему обязаны извлечь контекст, продолжить трейс и экспортировать данные. Спецификация задаёт только формат передачи.
  • Встроенный механизм Logging выводят из MCP в пользу OpenTelemetry, вместе с ним депрецированы Roots и Sampling. Переходное окно — минимум двенадцать месяцев.
  • Базовый протокол стал stateless: из обязательного ядра убрали initialize, initialized и заголовок Mcp-Session-Id, а версию, идентификацию клиента и контекст трассировки перенесли в _meta каждого запроса. Прокси и балансировщикам больше не нужно скрытое состояние сессии.
  • Одного trace_id для агентов мало: семантические соглашения должны одинаково описывать вызов модели, вызов инструмента, шаг агента, ошибку политики и завершение задачи — и они ещё развиваются.
  • Поддержка Trace Context в спецификации не гарантирует корректную передачу в конкретном SDK или MCP-сервере. Это надо проверять для своей реализации.
⚡ Попробовать за вечер
  • Посмотреть сырой запрос tools/call своего MCP-клиента и проверить, кладёт ли он traceparent в _meta. Если нет — прокинуть вручную.
  • На стороне MCP-сервера извлечь контекст из _meta и открыть дочерний спан на вызов инструмента, чтобы он лёг в тот же трейс, что и остальные сервисы.
  • Если протокол уже обновлён — снять из своего ядра зависимость от Mcp-Session-Id и проверить, что прокси перед сервером после этого не разваливается.
  • Метрика: доля вызовов инструментов, у которых в бэкенде один trace_id с исходным запросом пользователя.
Схема сквозной трассировки: пользователь, приложение с агентом, MCP-клиент и сервер, инструменты и API, сбор телеметрии в Otel Collector и водопад спанов из статьи
На картинке: цепочка, которую нужно держать в одном трейсе — от пользователя через агента, MCP-клиент и сервер до инструментов и внешних API. Справа тот же путь как водопад спанов, где видно, какой шаг дал задержку и где ошибка.
🔗 Читать на Хабре Обсуждение
06

Guard-модель перед LLM: лучший RPS, лучшая медиана и лучшие хвосты — три разных инструмента

✍ AnnaResh Хабр ⏱ ≈23 мин guardrails tensorrt vllm
О чём

Guard-модель стоит на входе и выходе LLM-приложения и вызывается дважды за один ход диалога, поэтому её хвостовая задержка попадает в ожидание пользователя дважды. Автор прогнала пять инструментов — TensorRT, Triton, vLLM, Ray Serve и Flash DeBERTa — на одной небольшой энкодерной модели чуть больше 0,5 ГБ и выложила locustfile с конфигами. Отдельная ценность — честный список того, что она сломала сама и чего не измерила.

🔑 Главное
  • Лучший по пропускной способности, лучший по медиане и лучший по хвостам — три разных инструмента: litserve-onnx-trt 193,6 RPS, vLLM с медианой 440 мс, Triton с P95 790 мс.
  • Самая дешёвая победа — четыре строки в конфиге Triton (optimization { graph { level: 3 } }): P95 минус 28%, P99 минус 35%, пропускная способность почти не изменилась.
  • Разбор пайплайна по стадиям сработал как диагностика: удвоение инстансов энкодера дало +44,5%, а четырёхкратное масштабирование пре- и постпроцессинга — всего +7,6%. Узкое место было в энкодере, а не в питоновской обвязке, на которую автор грешила первые две недели.
  • INT8 не поехал ни в TensorRT, ни в ONNX Runtime: span-скоринг поверх энкодера состоит из операций, для которых восьмибитных ядер просто нет.
  • REST против gRPC по пропускной способности — разница 1–2%, зато gRPC срезает максимальную задержку с примерно 16,7 с до 3,85 с. Для guard-слоя выбор протокола влияет не на скорость, а на предсказуемость хвостов.
  • CUDA graphs в vLLM дают P99 минус 28,6%, но пиковую память ×5,1 — 35 514 МиБ против 6 946 у базовой конфигурации на LitServe.
  • Оговорка автора: качество ускоренной модели она не мерила, поэтому все выводы про квантизацию — про «поехало или нет», а не про то, можно ли это ставить в прод.
⚡ Попробовать за вечер
  • Взять свой guard или классификатор перед LLM и снять базовую линию по RPS, P50, P95 и P99 через locust — конфиги и инструкции лежат в репозитории gliner-guard-serve.
  • Если модель уже в Triton — добавить optimization { graph { level: 3 } } и перезамерить хвосты, не меняя больше ничего.
  • Найти своё узкое место: масштабировать отдельно пре- и постпроцессинг, отдельно энкодер, и посмотреть, что двигает цифры.
  • Зафиксировать единый профиль нагрузки с самого начала — автор называет разные профили главным методологическим долгом своей работы.
  • Метрика: P95 и P99 guard-слоя до и после; в задержку одного хода диалога они входят дважды.
🔗 Читать на Хабре Обсуждение Репозиторий
07

Бенчмарк 23 ASR-моделей: русскую IT-диктовку выиграл тайваньский fine-tune Whisper

✍ egorsokolov Хабр ⏱ ≈60 мин ASR распознавание речи code-switching
О чём

В марте автор советовал Whisper Large v3, выбрав его «на ощупь», и теперь пересобрал сравнение по науке: 23 модели в 60+ конфигурациях, больше 100 000 прогонов на русско-английском IT-корпусе, 120+ часов инференса на одной RTX 5070 Ti. Если вы диктуете промпты и заметки LLM, здесь и готовый лидерборд, и методика, по которой можно проверить свой выбор.

🔑 Главное
  • Среди открытых моделей выиграл breeze-asr — fine-tune Whisper Large v2 от исследователей MediaTek под тайваньский mandarin-english code-switching. Навык «не путаться, когда речь меняет язык» перенёсся на русско-английскую смесь.
  • Whisper Turbo встал на второе место и обошёл все варианты Large v3. Whisper Medium f16 и Large v2 2022 года тоже оказались выше любого Large v3 — причина в том, что v3 дообучали на псевдоразметке от v2 и она чаще срывается в повторы.
  • Кроме WER автор считает EPI — сохранение английских терминов латиницей — и пунктуацию; композитная метрика Q = 0,65·WER + 0,10·punct + 0,25·EPI под сценарий диктовки.
  • Решает само наличие пунктуационного промпта, а не его версия: у русских turbo-дообучений он даёт до +19 пунктов Q (с 70 до 89,5), у обычного turbo — +6,2, между версиями промпта разница 0,2–1,1 пункта.
  • На чистом CPU ни одна Whisper-модель не годится для интерактивной диктовки — скорость около реального времени или ниже. На средней видеокарте офлайн-расшифровка идёт в 20–50 раз быстрее реального времени.
  • Болячка Breeze — склейка предложений на стыке, наследство мандаринского дообучения без пробелов между словами. Regex-постпроцесс автора поднимает Q с 88,7 у голой модели до 90,7.
⚡ Попробовать за вечер
  • Поставить сборку автора klava-nevinovata, выбрать в Settings → Model модель Breeze-ASR и включить в Advanced промпт и анти-галлюцинационные настройки.
  • Надиктовать свой обычный рабочий текст с английскими терминами и сравнить с текущей моделью по двум осям отдельно: попадание в слова и латиница в терминах.
  • Если дискретной видеокарты нет — взять gpt-4o-mini-transcribe через свой ключ за $0,18 за час аудио, а для чистого русского без терминов посмотреть GigaAM.
  • Метрика: доля английских терминов, оставшихся латиницей, и число ручных правок на страницу расшифровки.
🔗 Читать на Хабре Обсуждение Репозиторий
08

Codex сам решает, когда сжать контекст: чекпоинт перед компактом

✍ z0rgoyok Хабр ⏱ ≈1 мин codex агенты модификация
О чём

Короткая заметка с механизмом: автор отдал модели решение о том, когда сжимать контекст, и обязал её объяснять причину и оставлять план. Перед большой фазой агент смотрит остаток окна, пишет чекпоинт, сжимается — и, очнувшись, читает чекпоинт, перепроверяет состояние репозитория и продолжает по плану. Полезно тем, кто ловил компакт посреди правки большого связного куска кода.

🔑 Главное
  • В ответ на вызов инструментов подмешивается текущая ситуация по контексту, а правила агента объясняют, как писать чекпоинты.
  • Решение о сжатии принимает модель, а не движок: она сравнивает объём планируемой работы с остатком окна и сжимается до начала фазы, а не посреди неё.
  • Чекпоинт хранит дифф, принятые решения, зелёные проверки, состояние сабагентов и поле next — с чего продолжать.
  • Автор прямо пишет, что выводов пока нет: это работающий прототип, а не измеренный результат.
  • Кит требует пропатчить Codex — код лежит в codex-luna-kit.
⚡ Попробовать за вечер
  • Поставить codex-luna-kit на отдельную копию Codex и дать агенту большую связную задачу, которая заведомо не влезет в окно.
  • Посмотреть, где он поставит чекпоинт и что запишет в next, и сравнить с тем, где сжатие случилось бы само.
  • Дописать в правила агента обязательный пункт «что перепроверить после пробуждения»: состояние репозитория и зелёные проверки.
  • Метрика: сколько задач после сжатия контекста агент продолжил без вашего вмешательства.
Скриншот сессии Codex: остаток контекстного окна, оценка следующей фазы, путь к обновлённому чекпоинту и план на сессию после сжатия из статьи
На картинке: механизм в действии. Агент считает остаток окна, объявляет, что следующая фаза в него не влезает, пишет путь к чекпоинту — и после автоматического сжатия возобновляет ту же фазу по плану из четырёх пунктов.
🔗 Читать на Хабре Обсуждение Репозиторий
09

История сессий Claude Code в браузере: headless-вьюер и те же команды по HTTP

✍ opium Хабр ⏱ ≈4 мин Claude Code AI-агенты self-hosted
О чём

Claude Code пишет каждую сессию в ~/.claude/projects/ машинным JSONL, где thinking и tool_use — разные типы блоков, связи идут через parentUuid, а результат инструмента формально приходит ролью user. Claude Code History Viewer (Rust + Tauri, MIT) собирает из этих файлов интерфейс с диалогами, поиском и статистикой по токенам, а кроме Claude Code понимает историю ещё 27 клиентов — Codex CLI, Gemini CLI, Cursor, Cline, Copilot, Goose, Zed. Автор разбирает headless-режим на сервере без иксов и перечисляет грабли.

🔑 Главное
  • Тот же интерфейс отдаётся в браузер серверным бинарём из релиза; готовый docker-compose.yml в репозитории собирает бинарь из исходников, и автор берёт готовый. Gtk и webkit нужны даже серверному бинарю — это compile-time зависимость Tauri.
  • Официальный compose ставит лимит памяти 512 МиБ: на большой истории контейнеру его не хватает, лимит лучше поднять сразу.
  • README отстал от кода: в версии 1.22.0 в лог уходят только первые восемь символов токена, а сам токен пишется файлом в ~/.claude-history-viewer. Если домашний каталог смонтирован read-only, войти нельзя вообще — нужен явный --token.
  • Бэкенд не спрятан: те же команды доступны как POST /api/<имя> с Bearer-токеном, без токена приходит честный 401.
  • Команда get_expiring_sessions показывает сессии, которые вот-вот попадут под автоочистку Claude Code: cleanupPeriodDays по умолчанию 30, чистка идёт при старте клиента. Против этого есть Archive Manager с Full Backup в ~/.claude-history-viewer/archives.
  • Первый скан большой истории занимает минуты, повторные запросы отдаются из кеша за 0,06 с.
  • Наружу без токена выставлять нельзя: транскрипты лежат в открытом виде.
⚡ Попробовать за вечер
  • Смонтировать ~/.claude в контейнер read-only, поднять cchv-server с явным --token и лимитом памяти выше 512 МиБ, проверить /health.
  • Дёрнуть POST /api/scan_all_projects с Bearer-токеном и собрать по проектам число сессий — так видно, где история копится быстрее всего.
  • Прогнать get_expiring_sessions по рабочему проекту и посмотреть, сколько сессий уходит в ближайшие сутки; при необходимости поднять cleanupPeriodDays или сделать Full Backup.
  • Метрика: сколько ваших сессий сгорело бы за ближайшую неделю при текущем retention — и сколько из них вы хотели бы сохранить.
🔗 Читать на Хабре Обсуждение Репозиторий
💬

На что обратить внимание

Статьи, которые стоит держать в голове, но в готовый рецепт «попробовать вечером» они не складываются.

🔗 Claude Code научился связывать сессии между собой

✍ opiumХабр⏱ ≈2 мин

Автор заметил, что два агента над одной проблемой сами обменялись сообщениями через сокет. В версии 2.1.224 появился cross-session SendMessage: сессии находят друг друга через ListAgents и пишут напрямую, в 2.1.225 это заработало и между машинами при включённом remote control. Поверх нескольких Claude Code теперь можно собрать отдельного координатора.

Читать ↗

🧪 Четыре байт-идентичных прогона — четыре разных результата

✍ ArtbossХабр⏱ ≈14 мин

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

Читать ↗

📦 LLM придумывают пакеты, которых не существует

✍ amaksimovv (CodeScoring)Хабр⏱ ≈10 мин

Обзор работы, отмеченной Distinguished Paper Award на USENIX Security 2025: 16 моделей, 576 000 образцов кода на Python и JavaScript и подсчёт того, как часто в ответах появляются несуществующие пакеты. Ошибка модели превращается в атаку на цепочку поставки, если злоумышленник опубликует пакет под придуманным именем.

Читать ↗

🧯 OWASP LLM10: модели сами уменьшают масштаб задачи

✍ payusova (OWASP)Хабр⏱ ≈11 мин

AI Red Team прогнала ресурсоёмкие промпты и увидела, что модели всё чаще заменяют полный результат описанием алгоритма или демонстрационным фрагментом. Но во многих сценариях генерация останавливалась только на лимите токенов, поэтому защита от Unbounded Consumption остаётся многоуровневой: лимиты длины, квоты, мониторинг аномалий.

Читать ↗
🎯

Мой план на эту неделю

Из всех статей выше — три, по которым реально что-то сделаю. Не «прочитать», а внедрить.

Посчитать: байты JSON-схем своего тулсета в токенах, собрать узкий профиль под одну задачу и замерить prompt_tokens до и после
до среды
Проверить: кладёт ли мой MCP-клиент traceparent в _meta запроса tools/call, и достроить трейс до вызова инструмента
до пятницы
Замерить: P95 и P99 своего guard-слоя под locust и попробовать graph optimization в Triton
до выходных
#

Метаданные

сгенерировано 2026-08-10T05:45:01Z
окно 2026-08-03 — 2026-08-10 (7 дней)
отсканировано / в дайджест 110 / 13
источник Habr RSS (хабы: Искусственный интеллект, Машинное обучение, Natural Language Processing, «Лучшее за неделю»)
пропущенные фиды нет
картинки оставлено 4 из 8 скачанных; выброшены декоративные обложки, стоковое фото и мем
×
Открыть статью