Как я превращал свалку заметок в библиотеку для ИИ-агентов

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

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

Звучит красиво, но было три проблемы:

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

Слои: от свалки к полкам

Факты хранятся по-разному, в зависимости от роли. Большие документы разбил на атомарные карточки:

— fact-card — один проверяемый факт = одна карточка. С источником, уровнем доверия и сроком годности.
— case-card — один публичный кейс клиента, и что про него говорить нельзя.
— objections — карточка возражения («облако дороже») с готовым безопасным ответом.
— personas — карточки аудиторий: боли, KPI, запретные углы.

Зачем дробить? Большой текст легко выдаёт лишнее — непубличную деталь или старую цифру. Атомарная карточка хранит ровно один факт. Просрочилась — система сама её отложит.

Интеграции: появился библиотекарь

Полки — это полдела. Дальше нужен тот, кто приносит нужное:

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

Предохранитель на финале

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

Что в итоге

Конечно, это не очень обязательный элемент фабрики контента. В воркфлоу записано, что надо найти, передать, написать, проверить. Всё в чистом контексте и галлюцинаций в финале не остаётся. Но каждый запрос это токены и время. И деньги. А запросы повторяются, в конце концов мы крутимся вокруг одних и тех же цифр исследований, бенчмарков, фактов. Поэтому постепенно наполнять базу знаний и оперативно обращаться к ней кажется не такой уж плохой идеей. Стоит потратить на реализацию несколько вечеров.

Ставьте плюсы, подписывайтесь на канал.

Звёздная гонка ИИ-агентов в мае 2026

Наткнулся на свежий разбор от Rost Glukhov, он 21 мая выгрузил через API число звёзд у 20 самых популярных опенсорсных фреймворков для агентов.

Что по цифрам:

→ OpenClaw — 373 тыс. звёзд. В апреле обогнал React и стал самым «звёздным» репозиторием в истории GitHub. Тот самый агент Штайнбергера, который живёт на твоём железе и общается через мессенджеры. Ритм — 62 релиза за месяц, по одному каждые 12 часов.
→ Hermes Agent от Nous Research — 160 тыс. за 12 недель. Растёт быстрее в неделю, чем OpenClaw в том же возрасте. Держит память между сессиями и сам пишет файлы навыков из успешных задач.
→ Середина таблицы спрессована между 26 и 43 тыс. — там позиции тасуются за сутки от одного поста на HN: Nanobot (Python, ~4 тыс. строк кода, от лаборатории HKU), AstrBot (самый активный по релизам), PicoClaw (Go, под встраиваемые устройства от Sipeed), AionUi (TypeScript, агентный UI) и ZeroClaw на Rust.

Что мне было интересно из выводов автора:

Во-первых, релизы и звёзды почти не коррелируют. OpenClaw выкатывает 62 релиза в месяц, а пара проектов с десятками тысяч звёзд — ноль.

Во-вторых — и это главное — звёзды измеряют любопытство, а не использование. Что люди реально запускают, показывают токены на OpenRouter, загрузки npm/PyPI и история CVE, а не счётчик в углу репозитория. Звезда стоит один клик; она не значит, что софт хоть раз запустили в проде.
Полезное напоминание перед тем, как в следующий раз выбирать стек по «самому популярному на гитхабе».

Оригинал и полный датасет: glukhov.org

Больше и раньше у меня в канале. Подпишись!

ИИ не заменил менеджеров. Он сделал их узким местом

Картинка из моей работы. Облачная конференция, сессии наших спикеров на других ивентах, лендинги, статьи в СМИ и блог, Хабр. При производстве практически каждой единицы контента используется ИИ — целая фабрика агентов. Но между ИИ и готовым результатом есть человек, в данном случая я. Человек смотрит, проверяет, принимает решение. И этот ресурс ничем не масштабируется.

И это не то, чтобы только у меня подгорает. На прошлой неделе в HBR вышел материал Managers Are Struggling to Keep Up with the AI Productivity Boom. Открывается цитатой менеджера: "каждые тридцать минут кто-то создаёт что-то, что я должен посмотреть". CIO в свежей колонке формулирует ещё жёстче: исполнение перестаёт быть ограничением, дефицитным ресурсом становится суждение. Производство чего либо-ускорилось в разы. Но при этом никто не перестраивает поток работы под ИИ, практически всегда остаются те же цепочки согласований, что были до.

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

Короче, производство ускорили на порядок, а пропускную способность решений — процентов на двадцать. Разница оседает у тебя на столе. И, надо признать, в этом нет ничьего злого умысла. Просто индустрия выкатила инструмент, который сжимает один этап цепи, и почему-то решила, что от этого ускорилась вся цепь. Не ускорилась. Узкое место мигрировало. Сейчас оно сидит на менеджерском стуле и проверяет то, что выдала модель.

💡Что могу посоветовать. «Делегируйте больше», «фокусируйтесь на главном», «приоритизируйте» — это всё сработает только, если у вас есть большая команда.

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

Второе — поменять метрику собственной нагрузки. Для контент-менеджера, например, это значит перестать мерить себя «количеством опубликованного» и начать мерить «сколько решений приняли за день» и «сколько из них пришлось переоткрывать». Это звучит абстрактно, но это единственная метрика, которая показывает, упёрся ли ты в производство (масштабируется ИИ) или в суждение (не масштабируется).

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

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

Подписывайтесь на канал, там больше и раньше.

Продолжаю делиться граблями, на которые я наступил в Claude Code. Как я ловил API Error: Stream idle timeout - partial response received

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

Проблема такая: оркестратор собирает SEO-статью на 8 000 слов, отдаёт редактору, пробует сохранить. Через 30 секунд тишины: API Error: Stream idle timeout — partial response received

Файл создан, но обрезан на месте, где стрим ушёл в idle.

❌ Первая очевидная неверная гипотеза: большой Write

Значит надо резать на чанки. Снизил лимит 15 000 → 8 000 → 6 000 → 5 000. Таймаут повторялся. Значит, дело не в размере записи.

✨ Настоящая причина: пересборка текста

Оркестратор не копировал готовый текст субагента. Он его пересобирал: переоформлял, перенумеровывал 28 сносок, «причёсывал» заголовки. Пока модель думала над форматированием, токены в стрим не эмитились. API считал соединение мёртвым и закрывал.

Решение РАЗ: passthrough + чанки ≤ 3 000

Вводим правило rules/common/safe-file-save.md:

➡️ Субагент возвращает строку оркестратору. Оркестратор копирует её в Write байт-в-байт — без «улучшений».

➡️ Разбиение планируется один раз до первого Write, потом проходится механически.

➡️ Лимит 3 000 символов на Write/Edit — потолок, при котором стрим не уходит в idle при честном passthrough.

➡️ Перед каждым Edit — сообщение 💾 Чанк K/M…. Иначе пользователь видит тишину и прерывает.

Если таймаут повторяется на 3 000 — спуск на 1 500. Если и там падает — это сеть, не контент.

И Recovery для обрезанных файлов

Повторный Write поверх частичного файла затирает уже сохранённое. Поэтому:

➡️ ls — проверить, что файл есть

➡️ Read — измерить длину

➡️ Edit (append) с точки обрыва, чанки по 3 000

Никогда не стартовать Write заново по тому же пути.

⭐️ Вторая волна: редактор

После фикса записи таймаут вернулся на возврате субагента-редактора. Вход 18 000 символов, выход 18 000 переписанного текста + отчёт «до/после» + метрики. Prefill и генерация занимают десятки секунд без эмита токенов. Retry не помогал: корень — объём выхода.

Решение ДВА: diff-mode

Вводим правило rules/common/editor-diff-mode.md. Редактор возвращает не переписанный текст, а список правок:

=== EDIT id=1 op=replace === FIND: Данное решение является инновационным продуктом REPLACE: VK Cloud управляет инфраструктурой — от ВМ до managed-БД REASON: редполитика + инфостиль === END EDIT ===

Лимиты: ≤ 60 правок, FIND ≤ 300, REPLACE ≤ 500, суммарный выход ≤ 8 000. Оркестратор парсит блоки и применяет через Edit.

Матрица по длине для глубокой редактуры:

➡️ ≤ 4 000 → классический

➡️ 4 000 – 20 000 → diff-mode

➡️ > 20 000 → секционный (одна H2 за вызов)

Пороги ниже именно для тяжёлых режимов — они удваивают выход за счёт отчёта «до/после».

Что в итоге то:

Два источника одной ошибки: оркестратор переформатирует перед Write, редактор генерирует слишком много на выход. Лечатся по отдельности: passthrough + чанки для записи, diff-mode для правок. Recovery закрывает остаточные случаи, когда таймаут всё-таки прилетел.

Я вроде не курю, но захотелось.

Как всегда ссылка на канал. Подписывайтесь

Исследователи из Nous Research опубликовали Autoreason — работу о том, почему итеративное самоулучшение LLM ломается на практике, и как это починить. Тема актуальная: все мы пытались строить агентов по схеме «сгенерируй → покритикуй → перепиши», и у всех это работало хуже ожиданий.

Авторы выделили три структурные проблемы примитивного подхода.

➡️ Искажение от формулировки — модель галлюцинирует недостатки, когда её прямо просят критиковать (ну конечно, она же не может сказать «всё хорошо»).

➡️ Расползание задачи — тексты бесконтрольно разрастаются с каждым проходом, теряя фокус.

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

На Haiku 3.5 традиционная критика-и-ревизия сжимала выдачу на 59-70% за 15 итераций — чистая деградация.

Их решение: на каждой итерации генерировать три версии — неизменный инкумбент (A), состязательную переработку (B) и синтез (AB). Судит панель свежих агентов без общего контекста через слепое голосование по методу Борда, где вариант «ничего не менять» равноправный кандидат. Каждый судья ранжирует все три варианта, за первое место даётся больше баллов, за последнее — меньше. Если исходный вариант выигрывает дважды подряд — стоп, сходимость.

По Claude-линейке результаты сильные: Sonnet 4.6 на задачах программирования показал 77% против 73% у однократной генерации, Haiku 3.5 с новым методом обогнал выбор лучшего из 6 вариантов при равных вычислительных затратах (40% против 31%). Но самое интересное — точка перелома на Haiku 4.5: при 60% точности прирост от доработок исчезает. Разрыв между способностью генерировать и оценивать закрылся, итерации стали бесполезными.

Практические выводы для агентов в Claude Code: роли критика, автора и синтезатора должны быть отдельными агентами с независимым контекстом, иначе получишь искажения. Всегда включай опцию «оставить как есть» в список возможных действий. Используй несколько судей (минимум 3, лучше 7) для принятия решений о редактуре. И самое главное — с сильными моделями (Haiku 4.5+, Sonnet 4) можно не заморачиваться с итерациями вообще, однократной генерации часто достаточно.

Короче, если твой агент в Claude Code делает хуже после «улучшений» — это не баг, а особенность примитивного самоулучшения. Autoreason показывает, как это лечить правильно, но на современных моделях проблема может быть уже неактуальна.

Оригинал и больше такого у меня в канале

На Data Fusion несколько раз услышал: «В эпоху ИИ будет цениться контент от человека». Оке.

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

До генеративного ИИ мир был завален:

• текстами от рерайтеров на бирже за 30 рублей за 1000 знаков;

• стоковыми фотографиями с улыбающимися людьми в офисах;

• лендингами, сделанными племянником директора в конструкторе;

• пресс-релизами, написанными по шаблону 2003 года.

Всё это человеческий контент. Аутентичный. С душой.

На самом деле аудитория никогда не ценила «человеческое». Она ценила хорошее. Просто раньше плохое человеческое выигрывало в кейсах, когда надо сделать дёшево или бесплатно. Теперь конкурент появился. И внезапно оказалось, что планка «лучше среднего копирайтера или среднего дизайнера» — не такая высокая.

Кто конкретно имеется в виду, когда говорят «человеческий контент будет цениться»? Топ 5% — да, всегда ценился. Журналисты-расследователи, сильные авторы с точкой зрения, эксперты с реальным опытом, талантливые дизайнеры — им ИИ не конкурент, он инструмент. Остальные 95% производили промышленный мусор, который почти никто не читал, но который исправно оплачивался, потому что альтернативы не было. ИИ не убивает хороший контент, дизайн, код. Он убивает индустрию посредственного. И это, честно говоря, давно пора. Проблема в том, что большинство людей, которые сейчас переживают за «ценность человеческого контента», — как раз из этих 95%.

И спикерам на DF приходится их как-то успокаивать.

Раньше и больше у меня в канале

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

Починил таймауты и ограничил запросы WebSearch. Раньше агенты зависали на длинных запросах и сжигали токены. Теперь у каждого субагента жёсткий лимит, параллельно работает не больше трёх запросов. Адаптивная глубина: если после 3 запросов уже 8+ источников — остальные пропускаются. Если после 5 запросов меньше 5 качественных — включается глубокий режим. Три сбоя подряд — полная остановка. Если поиск лёг — пустой конспект с маркером, а не выдуманные данные.

Добавил автоматические предохранители от перерасхода токенов. Конспект ресёрчера обрезается на 4-5K символов, а лишнее отсекается по приоритету тиров. Если 80%+ фактов из Tier 1-2 — фактчекер предлагает пропуск (экономия 4-6K токенов). И там много ещё всего.

Добавил оценку токенового бюджета. Теперь, например, перед запуском пайплайна видно: статья съест 14-20K токенов (5-7% дневного лимита). Можно решить, стоит ли запускать фактчекинг, если все источники и так Tier 1.

И завершил разбиение всех агентов на субагенты (кажется). Раньше один агент искал, писал и проверял — контекст распухал, ошибки каскадировали. Теперь сборщик, автор и верификатор работают в песочницах. Каждый видит только свои данные.

Запустил сбор отчётов генерации и ревью. Раз в неделю анализирую отчёты, ищу паттерны ошибок и обновляю правила. Замкнутый цикл: ошибка → отчёт → новое правило → следующая генерация лучше. Автоматику тут не стал делать, чтобы не допустить попадание галлюцинаций в правила.

Главный вывод: не пытайтесь предотвратить все ошибки ИИ-агентов. Стройте систему, которая их обнаруживает, логирует и улучшает правила на основе данных.

P.S.: Что в работе и про что постараюсь рассказать: пишу backend runtime на Python, чтобы wizard-поведение работало не только в Claude Code, но и через API, в своём бэкенде или другом LLM. Короче, чтобы не замыкаться только на Claude, а использовать агенты и в других нейросетях. Но тут ещё тестировать и тестировать.

Больше и раньше в канале

Нашёл интересную реализацию прямолинейного контентного агента на Claude Code — ralph-wiggum-marketer.

Суть: автономный копирайтер который работает в цикле. Задаёшь список задач в формате PRD — с описанием, критериями приёмки и приоритетом. Агент берёт задачу, пишет, проверяет по критериям, коммитит результат, логирует выводы, берёт следующую.

Тут есть интересное решение проблемы памяти. Каждая итерация стартует с чистым контекстом, но агент всегда читает progress.txt с накопленными выводами из прошлых итераций. Паттерны которые сработали остаются. Это и есть самообучение в простейшей реализации.

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

Для моих задач это, конечно, не готовое решение, но взять отсюда можно две вещи: структуру PRD с явными критериями приёмки для каждой задачи, и паттерн progress.txt как простейшую форму накопленной памяти между сессиями без сложной инфраструктуры.

Больше у меня в канале

rules отдельно, skills отдельно: система правил для ИИ-агентов в Claude Code

Возвращаюсь к своему опыту работы с Claude Code. Там за неделю накопилось несколько интересных решений в работе контентными агентами. Например, добавил устойчивость к ошибкам WebSearch и начал сохранять результаты проверок для дообучения. Но сначала надо вам рассказать про правила.

Почему rules, если есть уже привычные skills? Разница между этими сущностями принципиальная:

➡️ rules — это «как оформлять» (ограничения, чеклисты, формат),
➡️ skills — «что знать» (предметная экспертиза, справочники, методологии).

Rules загружаются автоматически через симлинки. Skills вызываются по запросу, когда агенту нужна глубокая экспертиза.

Но всё равно же не очень понятно, зачем такое разделение, да?

Правила не засоряют контекстное окно. Файлы из .claude/rules/ загружаются в системный промт автоматически — агент соблюдает правила, не тратя токены на их обсуждение. Skills, наоборот, подгружаются только когда нужны. Справочник на 200 терминов не висит в контексте постоянно — он появляется в момент, когда автору пора писать, и не мешает исследователю или фактчекеру.

Когда агентов больше одного, правила написания текстов неизбежно дублируются. Обновил термин в одном месте — забыл в трёх других. Решение: вынести все правила в единую директорию rules/ и раздавать агентам через симлинки в .claude/rules/

При этом сами правила делятся на два уровня:

➡️ Общие (rules/common/) загружаются в каждого агента: терминология, стиль, грамматика, протокол работы субагентов.
➡️ Доменные (rules/{domain}/) добавляют специфику формата: у SEO-статьи свои требования к структуре, у пресс-релиза — свои, у лендинга — свои.

Доменные папки могут содержать файлы с теми же именами, что и в common/. Это не дубли, а дельты — дополнения и уточнения общих правил для конкретного формата. Агент загружает оба файла и применяет оба набора ограничений.

Результат: один файл правил — один источник правды. Изменил правило в rules/common/ — оно обновилось у всех агентов. Новый агент подключается за минуту: создал .claude/rules/, добавил симлинки — готово.

Как это работает в оркестрации

В модульной системе с субагентами разделение rules и skills становится особенно важным. Типичный пайплайн:

1️⃣ Оркестратор собирает параметры задачи через wizard.
2️⃣ Субагент-исследователь загружает свои rules (протокол работы, устойчивость к ошибкам поиска), ищет данные, возвращает структурированный конспект.
3️⃣ Субагент-автор загружает свои rules (доменные стандарты формата + общие правила качества) и skill (экспертная специализация), пишет текст по конспекту.
4️⃣ Субагент-проверщик загружает свои rules (требования к фактам и качеству), проверяет текст независимо.

Каждый субагент получает только нужные данные (чистый контекст) и только свои правила. Исследователь не знает правил оформления — они ему не нужны. Автор не знает, как проверять факты — это задача следующего субагента. Фактчекер не знает, как писать — он только проверяет. Такое разделение позволяет держать контекст каждого субагента компактным и сфокусированным.

Больше такого в моём канале.

Hugging Face опубликовал ежегодный отчёт о состоянии моделей ИИ с открытым исходным кодом. Что там интересного:

💡 За 2025 год китайские модели составили 41% всех загрузок на платформе — Китай вышел на первое место по ежемесячным скачиваниям. Это прямое следствие эффекта DeepSeek: Baidu перешёл с нуля релизов на HF в 2024-м к более чем 100 в 2025-м, ByteDance и Tencent увеличили количество релизов в восемь-девять раз.

💡 Доля индустрии в разработке open source AI упала с 70% до 37%. Доля независимых разработчиков выросли с 17% до 39% загрузок. Но большинство из них не создают модели, они их переупаковывают.

💡 У Alibaba больше производных моделей, чем у Google и ещё одной компании вместе взятых. Если считать все модели Qwen, то их более 200000. Но, кажется, за этим стоит конкретный стратегический выбор Пекина: открыть модели, чтобы занять инфраструктурный слой.

💡 Маленькие модели скачиваются и разворачиваются значительно чаще крупных из-за стоимости, задержек и железа. Средняя медиана скачиваемой модели — 406 млн параметров.

💡 Среднее время интереса к модели — 6 недель — пожалуй, самая честная цифра в отчёте. Open source AI живёт циклами хайпа, а не долгосрочным использованием. Большинство релизов забывают раньше, чем успевают протестировать в проде.

💡 Датасеты по робототехнике выросли с 1145 до 26 991 за год и стали крупнейшей категорией датасетов на платформе, обогнав генерацию текста. Это направление стоит отслеживать отдельно, но это не прорыв в физическом ИИ. Это академические лаборатории, которые наконец-то начали публиковать данные там, где их увидят.

Полный отчёт

Мой канал Инженер Контекста

Пару интересных наблюдений из статьи Prompt Engineering Best Practices in 2026: The Ultimate Guide to Better AI Prompts.

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

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

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

Фреймворк RCCF который там описан — Role, Context, Constraints, Format — это по сути то, как должен быть устроен любой агент или скилл. Роль задаёт экспертизу. Контекст даёт почву. Ограничения убирают пространство для галлюцинаций. Формат делает вывод предсказуемым.

P.S.: Больше про агенты для контента в канале.

Разобрал репозиторий gstack от Гэрри Тана, CEO Y Combinator. Про критику от комьюнити писать не буду. Это в точности тот же спор который идёт вокруг любого репозитория с конфигами агентов. «Это просто промпты» — технически верно. Но ценность не в промптах, а в ролевой модели и порядке вызовов. Точнее всего описать репу так: структура инженерной организации как принцип проектирования, а не один агент на всё.

Что это такое, собственно:

gstack превращает Claude Code в виртуальную инженерную команду которой ты реально управляешь: CEO который переосмысливает продукт, инженерный менеджер который фиксирует архитектуру, дизайнер который ловит ИИ-шлак, параноидальный ревьюер который находит баги в продакшне, QA-лид который открывает настоящий браузер и кликает по приложению, и релиз-инженер который шипит PR. Тринадцать специалистов, все как слэш-команды, всё в Markdown, MIT-лицензия.

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

Что применимо для контентных агентов

Гэрри Тан не сделал одного агента «напиши код». Он разделил процесс на роли с разными углами зрения: стратег, исполнитель, ревьюер, контролёр качества. Для контентных агентов это, чисто теоретически, можно интерпретировать так:

• /plan-content по образцу /plan-ceo-review — переосмысляет тему перед написанием. Не «напиши статью про Kubernetes», а «какой угол здесь самый сильный, что аудитория хочет узнать, какой тезис будет неожиданным». Стратегический режим перед исполнением.

• /review-editorial по образцу /review — находит нарушения редполитики которые проходят поверхностную проверку но выглядят плохо при публикации. Автофиксит запрещённые слова, показывает спорные утверждения без источников.

• /qa-content по образцу /qa — проверяет финальный текст по чеклисту: факты атрибутированы, голос соответствует, структура соблюдена, нет клише, длина правильная для формата. Фиксит и перепроверяет.

• /ship-content по образцу /ship — финальный прогон перед публикацией: проверка всех пунктов, генерация превью для разных платформ, архивирование в базу опубликованных материалов.

• /retro-content по образцу /retro — еженедельный отчёт: сколько материалов вышло, какие форматы, какие темы, что залипло, что нет.

У меня система выстроена по-другому — агенты под задачи, субагенты с чистым контекстом, правила и скиллы — но тем интереснее смотреть на другие варианты архитектур.

P.S.: Редко выхожу с таким на Хабре, больше про агенты для контента в канале.

Хабр совместно с ЭКОПСИ опубликовали масштабное исследование: 30 000+ IT-специалистов оценили почти 700 компаний, из которых в итоговый рейтинг IT-брендов работодателей вошли 127. Главный критерий — привлекательность и узнаваемость в глазах специалистов. Интереснее разобрать, почему такие результаты. Я попросил одну нейросеть собрать исследования за четыре последних года и вот что получил:

6️⃣ Удалёнка и гибкость работы

Удалёнка стала чуть ли не обязательным условием выбора: ~91,5% IT-специалистов считают возможность работы из дома важной, и ~91,7% предпочли бы гибрид/удалёнку при равной зарплате. Компании с гибкими условиями выигрывают в рейтингах — Aviasales, например.

2️⃣ Корпоративная культура и HR-коммуникации

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

3️⃣ Внешняя видимость и вклад в сообщество

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

4️⃣ Интересные технологические задачи и продукты

Айтишники выбирают что они будут делать на работе. Популярные IT-бренды связаны с продуктами, которыми пользуются: Авито, 2ГИС, Ozon — это проекты с очевидным влиянием на общество. Работа над уникальными продуктами, сложными задачами и значимыми сервисами — это первый приоритет при выборе нового места.

5️⃣ Стабильность и надёжность

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

6️⃣ Размер компании: баланс между масштабом и теплотой

Большой бренд — это круто, но не всегда — привлекательно. Многие молодые разработчики выбирают компании поменьше, где меньше бюрократии, ближе команда, и можно реально участвовать в процессе. Компании, которые нашли баланс между стабильностью и уютной культурой, получают больше симпатий.

И от себя: мне нравятся большие компании, даже несмотря на KPI, Performance Review и другие страшные слова. Но важнее всего интересные задачи и какой-то рост. Если всё однообразно и по три года не меняется, то даже стабильность не поможет. Захочется уйти туда, где также стабильно, но от тебя постоянно просят сделать новое или затащить старое.

Как говорит нейросеть, напишите, что для вас важно?

📥Левашов - пишу про контент для ИТ, про ИИ, агенты и промты.

Плохие новости — LanguageTool перестаёт работать бесплатно

Альтернативу ещё стоит подобрать, но пока такие варианты:

💡Spell Checker for Chrome — Простое и лёгкое расширение для проверки орфографии на многих языках (включая русский); хороший выбор, если нужно «минимализм + надёжность».

💡 Free Spell Checker for Google Chrome — Простая бесплатная проверка орфографии на десятках языков, включая русский — подойдёт, если не нужна сложная грамматика.

💡 Magictool AI — Более «многофункциональное» решение: грамматика, орфография, переписывание текста, помощь с формулировками, AI-функции.

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

ТГ📥Левашов

Callout Manager в Obsidian: что это, как работает и зачем нужен

Продолжаю про Obsidian. Сначала хотел рассказать про шаблоны, тем более я с ними сам до сих пор разбираюсь и периодически переделываю, но понял, что перед этим нужно раскрыть тему callout-блоков и плагина Callout Manager.

💡 Скачать

Что такое callout-блоки

Callout-блоки — это специальные визуально оформленные блоки в Markdown-заметках Obsidian. Они состоят из:

➡️ иконки
➡️ типа блока (info, note, warning и т.д.)
➡️ опционального заголовка
➡️ содержимого

Это выделенный элемент текста, похожий на карточку или подсказку. Посмотреть пример таких блоков вы можете в посте про Obsidian TODO Plugin. В шаблонах я активно использую callouts для оформления.

Как вызвать callout в Obsidian

Достаточно начать строку с > и указать тип в квадратных скобках. Стандартный синтаксис выглядит так:

>[!info] Информация
Это пример callout-блока.

Что делает плагин Callout Manager

Встроенные в Obsidian callouts-блоки использовать можно, но неудобно — нужно помнить синтаксис, типы, иконки. Callout Manager решает эту проблему: он показывает все доступные блоки, позволяет ими управлять (менять цвет и иконку), добавлять новые.

Простой пример на скрине к посту — кастомный блок для выделения промтов.

ТГ:📥Левашов

Моя подборка плагинов Obsidian

Не откладывая историю про Obsidian в долгий ящик, решил рассказать про весь набор плагинов. Тут имеет смысл добавить истории — первый подход к этой программе я сделал ещё года два назад, но вот только почему-то не догадался почитать про то, как комьюнити расширяет её возможности. То есть просто использовал как систему заметок. И поэтому быстро забросил. А вот если бы почитал про плагины, про callout-блоки и шаблоны... Короче, вот список, а в следующих заметках про конкретные примеры работы.

Про Obsidian TODO Plugin выше.

А вот список:

💡 Templater

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

💡 Advanced Canvas

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

💡 Advanced Tables

Плагин, который добавляет нормальные таблицы: улучшенные формулы, автоформатирование, выравнивание, горячие клавиши и удобное редактирование в Markdown.

💡 Excalidraw

Бессменный лидер среди визуальных плагинов. Позволяет создавать полнофункциональные рисунки, майнд-карты, схемы, инфографику прямо в Obsidian. Огромная библиотека форм, поддержка слоёв, стилей и интеграция с заметками.

💡 Callout Manager

Улучшает работу с callout-блоками: добавляет быстрые вставки, кастомные стили, удобное управление видами подсказок, заметок, предупреждений и т.п.

💡 Modal Forms

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

💡 Enhancing Export

Плагин, который сильно расширяет встроенный экспорт в Obsidian. Позволяет сохранять заметки в HTML, DOCX, PDF, ePub, Hugo Markdown и другие форматы. Идеален для тех, кто делает отчёты или оформляет контент вне Obsidian.

💡 Iconize

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

Скриншотом будет мой реальный список плагинов. Как раз всё влезло, кроме Obsidian TODO Plugin. Если вы чем-то пользуетесь, но этого плагина нет в списке, то пишите в комментах.

ТГ:📥Левашов

Daily Notes + Obsidian TODO Plugin = фундамент для собственной GTD-системы в Obsidian

У меня в черновиках лежит написанная на 50% статья про продуктивность контент-медеждера, Obsidian и мои принципы управления собственной базой знаний, но писать, кажется, я её буду ещё долго. Поэтому начну выкладывать некоторые заметки в ТГ (и сюда) в надежде когда-нибудь собрать из них большой материал. Поехали.

Obsidian — это markdown-редактор и приложение для ведения базы знаний. Когда я переезжал в эту софтину, то важнейшим условием (а их было много и о них в другой раз), которое я ставил перед собой, было ведение собственного списка дел в её рамках. Отмечу, что есть ещё рабочая система управления проектами, так что отдельный сервис ещё и для GTD я бы не потянул. Чем больше сущностей, тем больше шанс, что ты не будешь пользоваться такой системой и скатишься в хаос.

В Obsidian я перепробовал несколько вариантов плагинов, в том числе и канбан-доски, но оказалось, что полноценный центр управления проектами мне здесь не нужен. Однако, всего два плагина — встроенный «Ежедневные заметки» и внешний «Obsidian TODO Plugin» — сформировали персональную GTD-систему, где идеи, задачи и контексты объединяются в единую структуру.

Ежедневные заметки — поток входящей информации

Плагин Ежедневные заметки создаёт автоматическую страницу на каждый день по вашему шаблону. Это центральная точка входа в поток информации и действий. В любой момент можно открыть дневную страницу и быстро зафиксировать всё, что появилось в голове или о чём вы договорились на встрече.

Obsidian TODO Plugin — управление задачами

Задачи в Obsidian основаны на обычных чекбоксах, но специализированные плагины вроде Obsidian TODO Plugin превращают их в полноценную GTD. Самое важное, что дает Obsidian TODO Plugin — это автоматический сбор задач. Плагин находит все открытые чекбоксы по всему хранилищу и объединяет их в списки. То есть вы записываете задачи в вашей ежедневной заметки, а плагин их просто собирает и показывает.

Есть ещё поддержка тегов и быстрый переход к заметке, в которой была создана задача. Кажется скудный набор возможностей, но эта система работает. Ты просто перестаёшь терять задачи и заметки к ним. И всё это в программе, которая позволяет тебе строить большие и очень удобные блок-схемы и чертежи, собирать базу знаний по продукту и многое другое. Меньше окон — меньше сущностей. Но об этом в другой раз. Stay tuned.

P.S.: Скриншотом будет как раз шаблон моей ежедневной заметки.

Доска VK WorkSpace: демо возможностей для эффективной работы команды Ozon

Команда коммуникационной платформы VK WorkSpace от VK Tech провела исследование и выяснила, что сотрудники компаний активно пользуются онлайн-досками даже летом — в среднем на 15% активнее. 

7 октября в 15:00 по Москве они проведут бесплатный вебинар, на котором расскажут, как Доска VK WorkSpace помогает командам в совместной работе с идеями, интеллект-картами и бизнес-процессами. 

Представитель Ozon расскажет, почему в компании выбрали Доску VK WorkSpace, как перенесли данные и в какие процессы удалось эффективно интегрировать сервис.

Вебинар будет интересен руководителям удаленных и гибридных команд, менеджерам проектов, маркетологам, аналитикам и всем, кому нужно использовать в работе визуализацию данных.

Чтобы участвовать, нужно зарегистрироваться по ссылке

Регистрация

В программе:

• Совместная работа в Доске VK WorkSpace: редактирование, комментарии, реакции, голосования и режим презентации.

• Шаблоны досок: Mind Map, командное ретро, диаграмма Ганта, Kanban, CJM, SWOT, Canvas и другие.

• Управление ролями и уровнями прав доступа в командах и досках, возможность поделиться ссылкой на отдельные элементы на досках. 

• Массовая миграция из Miro с сохранением структуры документов и уровней доступа.

• Администрирование Доски: обзор панели управления для контроля состава команд и настройки прав доступа.

• Демо ключевых возможностей Доски для совместной работы бизнеса с заказчиками.

• Критерии выбора ПО для Ozon: отечественный вендор, функциональность сервиса, интуитивный интерфейс. 

• Стратегия миграции Ozon в Доску VK WorkSpace: перенос данных — это просто.

• Интеграция Доски в бизнес-процессы Ozon и работа с совместными доступами.

Спикеры:

• Анастасия Борисова, младший менеджер продукта VK WorkSpace;

• Антон Агальцов, руководитель направления внутренних сервисов Ozon.

Зарегистрироваться 

Аддоны Istio и Kiali в сервисе Cloud Containers от VK Cloud

В Cloud Containers от VK Cloud добавлены два новых аддона — Istio и Kiali. Для кластеров K8s в сервисе Cloud Containers доступны различные аддоны, с помощью которых можно быстро и удобно добавлять новые функции в кластеры. Их можно выбрать в любой комбинации и установить либо при создании кластера с помощью Terraform, либо позднее в уже существующий кластер. Процесс установки автоматизирован и требует минимального вмешательства пользователя

Istio

Istio — это фреймворк централизованного управления сетевым трафиком, реализующий подход Service Mesh. Аддон Istio позволит реализовать единообразный и эффективный подход к управлению трафиком, балансировке нагрузки, шифрования, мониторингу и других задач в сервисе для управления кластерами Kubernetes от VK Cloud. DevOps-инженеры знают Istio, как сложную для установки архитектуру. Мы постарались максимально упростить установку Istio, а также добавили подробные инструкции и документацию.

Kiali 

Аддон Kiali — это консоль для Istio, который визуализирует генерируемые метрики и помогает понять, что происходит в Service Mesh. Он  пригодится не только для визуализации вашего приложения, но и поможет с созданием, проверкой и управлением конфигурациями mesh-сетки.

Узнать об обновлениях и работе с ними больше можно на вебинаре «Безопасность K8s на практике: возможности и инструменты».

Другие новости K8s читайте в нашем канале.