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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что в итоге

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

#ai_agents

Ну или мемов вам накидать.

У меня было 119 коммитов, 30 слитых пулл-реквестов, 38 104 добавленных строки и целая россыпь файлов всех сортов и расцветок — 7 новых субагентов, модуль клиентских кейсов, 11 правил редполитики, 13 скриптов-валидаторов и 10 тестов.

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

Так я вижу Code и Codex порой.

Anthropic выпустила Claude Fable 5. И это, возможно, самый необычный релиз ИИ за последние годы.

Не потому что модель показала рекордные цифры в бенчмарках. И не потому что она якобы приблизилась к AGI. А потому что впервые главный маркетинговый тезис звучит так:

Наша лучшая модель слишком опасна для публичного доступа.

Вместе с Fable 5 компания представила Mythos 5 — внутреннюю модель, доступ к которой ограничен из-за её возможностей в чувствительных областях вроде кибербезопасности. При этом Fable 5 построен на той же архитектуре. То есть вся презентация сводится к довольно необычной идее:

Вот наша самая мощная модель.

Но пользоваться вы будете не ей.

Если раньше AI-компании соревновались в том, кто покажет более высокий результат на очередном бенчмарке, то теперь соревнование переходит в другую плоскость. Не «насколько умна модель», а «насколько опасной мы считаем собственную модель».

И это довольно интересный сдвиг. Последние два года индустрия продавала интеллект. Сначала были задачи уровня школьных олимпиад. Потом исследования. Потом агентность. Теперь в качестве конкурентного преимущества начинают продавать ограничения. Фактически Anthropic говорит рынку:

Мы сделали модель настолько сильной, что вынуждены ограничивать доступ к ней.

Для компании это почти идеальная маркетинговая позиция. Особенно забавно выглядит появление двух уровней доступа к интеллекту. Раньше различия были простыми: бесплатная версия и платная версия.

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

— версия для всех;
— версия, которой вам не доверяют пользоваться.

И мне кажется, что именно это главный итог релиза. Не очередной рост качества на несколько процентов, а начало эпохи, где ИИ-компании будут конкурировать не только мощностью моделей, но и правом доступа к ним. Потому что если такой подход взлетит, через пару лет вопрос будет звучать не «какую модель ты используешь?», а «какой у тебя уровень допуска к модели?».

#ai

Но нас спасёт жадность... Вы цены на токены в Fable видели?🙈

Долго объяснять. 17 июня в Москве и онлайн пройдёт облачная конференция VK Cloud Conf. Я там буду. Из очень интересного на мой субъективный взгляд (без учёта, что я помогаю конфу организовывать):

— Большое исследование российского рынка ИИ от Apple Hills Digital и VK Tech. Покажем в первый раз и там прям любопытные цифры. Вчера, кстати, вышло исследование Apple Hills Digital совместно с VK Tech, Cloud.ru и Selectel про облачные тренды в корпоративном секторе России 2026. Забирайте здесь.

— Про особенности развития ИИ-агентов с кейсами и решениями. Про платформы и прочее.

— Managed Kubernetes как вычислительный центр для ИИ. И как с ним жить без виртуализации.

— Организация процессов в компании перед AI-апокалипсисом. Доклад от Битрикс24.

И там ещё много. Регаться здесь.

#vktech

Когда при мне говорят про искусство и эстетику

Две важные темы с VK Cloud Conf. Там еще интересного много, конечно, но в рамках этого канала рекомендую именно эти новости.

Мультиагентность в VK AI Space хочу уже пощупать сам.

Кратко про процессы

Надо собраться с силами и рассказать, что я там понаписал по агентам

Про контроль качества контента с помощью скриптов на GitHub

Или как контентщику использовать инструменты разрабов.

Вводные: агенты у меня сейчас живут в GitHub и запускаются из Code или Codex (в работе их миграция в различные окружения, но пока так). Качество генерируемых текстов я контролировал через промпты и агенты проверки: правила в контексте, отдельный субагент-фактчекер, редакторская вычитка. Я им доверял и, в общем, не зря, они ловят многое.

Но у этого доверия есть слепое пятно. Всё это живёт внутри сессии. Проверка случается, если агент про неё "вспомнил", если правило доехало в контекст. А когда что-то из этого не сработало, то ты узнаёшь об осечке уже когда сам садишься вычитывать.

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

Так появился слой на GitHub Actions. Устроено просто: на каждый сгенерированный материал запускается единая команда make check, за ней — цепочка проверок: тесты, валидация структуры, десятки детекторов на отдельных скриптах.

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

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

Почти все проверки я сделал мягкими: они советуют, но не блокируют, финальное слово за мной. Жёстко останавливает только то, что реально ломает сборку. Логика простая: агентам я по-прежнему доверяю, GitHub не заменил их, а стал вторым контуром.

В итоге я перестал держать в голове тревогу «а точно ли всё проверилось». Теперь на это отвечает не моя вера в процесс, а сам процесс.

#ai_agents #github

Про новый Content Ops и почему через полгода хвастаться «фабрикой контента» станет стыдно

«Мы автоматизировали продакшн», «агенты сами пишут релизы», «редактор нажимает одну кнопку». Пол-ленты про это.

Прогноз от меня простой. Через полгода это будет гигиена, а не достижение. Генерить объём научатся все, а значит, объём окончательно перестанет что-либо стоить. Дальше все повернутся к content ops.

Термин content ops придумали не вчера. В оборот он вошёл в конце 2010-х и собран по прямой аналогии с DevOps. По сути это маркетинговая дисциплина. Люди, процессы, технологии, чтобы эффективно производить контент. Воркфлоу, CMS, согласования, календарь. Старый content ops оптимизировал производство. Но это больше не узкое место.

И тут стоит сказать, что content ops назван по аналогии с devops, сами механики devops — версии, CI, откаты, мониторинг — к контенту по-настоящему не прикладывались. Не к чему было. Текст — не код.

Теперь — код. Скилл агента это буквально код: он дрейфует, деградирует, ломается на регрессиях. Вчера писал в голосе, сегодня сползает в канцелярит. Факты галлюцинируют, модель уверенно ставит цифру, которой нет. Нужен слой проверки, как CI, только для фактуры. И появляется полноценный content ops с позицией инженера content ops — опыт редактора плюс владение пайплайном.

Почему будущее там, а не в промпт-инженерах

Промпт-инженер — это про «как попросить модель». Навык. Он встроится в редактора за квартал и перестанет быть профессией. Сейчас учить людей правильным промптам уже кажется устаревшим навыком.

Content ops в новом смысле — это про «как держать систему из моделей, людей и стандартов, чтобы она не разваливалась и ей можно было доверять».

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

Что изменится внутри самой редакции

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

То есть в моём понимание над редакцией должен появиться человек, который наблюдает за процессами и чинит ошибки. Более того, у контента появится техдолг. Зоопарк агентов и скиллов от различных команд и коллег копится, они начинают противоречить друг другу. Никто уже не помнит, зачем это правило и можно ли его снять. Редакции впервые получат то, что раньше было головной болью только разработчиков. И эту проблему нужно закрывать уже сейчас, должна быть единая функция и точка входа и выхода.

Вот такой прогноз. Что скажете, коллеги?

#ai #contentops