Наговорить бессвязно — рабочий приём, а не лень
Андрей Карпатый, который в 2026 перешёл в Anthropic в команду претрейна, описал приём из собственной практики. Когда модели не хватает контекста, а печатать лень, он переключается на голосовой ввод и минут десять говорит потоком сознания — без структуры, как выйдет. Смысл не в экономии времени: модели неплохо собирают связное из бессвязного, и пересказ ваших путаных мыслей возвращается к вам чище оригинала.
Меня тут зацепило вот что. Мы годами учились ставить задачу коротко и чётко, и вместе с водой очень часто удаляем контекст. Почему прошлая версия не зашла, что сказал заказчик в коридоре, чем этот канал отличается от соседнего — формулировать всё это неудобно, поэтому в бриф оно не попадает. А потом всплывает на третьей итерации правок. В голос же попадает всё, ровно потому, что вы себя не редактируете на ходу.
Но переносить этот приём на редакцию я бы не спешил, и вот почему.
Карпатый исследует и прототипирует один — вся картина у него в голове, поэтому поток и правда содержит нужное. У редактора половина контекста снаружи: согласования, чужие правки, то, чего заказчик ещё не сказал. Наговорить вы можете только свою половину, а модель соберёт из неё стройную версию неполной картины. Это опаснее очевидно дырявого брифа: связность создаёт ощущение достаточности, и вопросы вы задавать перестаёте.
Проверить такую сборку тоже трудно. Модель не помечает, где ваша мысль, а где правдоподобная подстановка. Вы читаете гладкий текст, узнаёте себя и киваете.
Отдельно про цену. Десять минут речи — это довольно большой кусок текста и примерно две тысячи токенов, и он остаётся в переписке до конца сессии. Каждый следующий ваш вопрос модель читает вместе с ним заново: к двадцатой реплике вы оплатили эти десять минут двадцать раз. Но дороже не деньги, а место. Окно контекста не резиновое, и ваши оговорки лежат в нём рядом с правилами канала. Чем длиннее разговор, тем охотнее модель цепляется за случайную фразу из потока вместо инструкции в скилле. В агентском пайплайне это ещё умножается на каждый шаг цикла.
Отсюда рабочая рамка. Наговаривать — в отдельной сессии, забирать оттуда только сборку, ужимать её руками и приносить в работу абзацем, который вы прочли и одобрили. Проверять при этом не то, что модель оставила, а то, что она выбросила. Ценность приёма не в готовом брифе, а в том, что он вытаскивает из вас причины, которые вы не стали бы печатать. Собеседником модель тут работает отлично. Автором задачи — нет.
#ai #контентменеджерское
Андрей Карпатый, который в 2026 перешёл в Anthropic в команду претрейна, описал приём из собственной практики. Когда модели не хватает контекста, а печатать лень, он переключается на голосовой ввод и минут десять говорит потоком сознания — без структуры, как выйдет. Смысл не в экономии времени: модели неплохо собирают связное из бессвязного, и пересказ ваших путаных мыслей возвращается к вам чище оригинала.
Меня тут зацепило вот что. Мы годами учились ставить задачу коротко и чётко, и вместе с водой очень часто удаляем контекст. Почему прошлая версия не зашла, что сказал заказчик в коридоре, чем этот канал отличается от соседнего — формулировать всё это неудобно, поэтому в бриф оно не попадает. А потом всплывает на третьей итерации правок. В голос же попадает всё, ровно потому, что вы себя не редактируете на ходу.
Но переносить этот приём на редакцию я бы не спешил, и вот почему.
Карпатый исследует и прототипирует один — вся картина у него в голове, поэтому поток и правда содержит нужное. У редактора половина контекста снаружи: согласования, чужие правки, то, чего заказчик ещё не сказал. Наговорить вы можете только свою половину, а модель соберёт из неё стройную версию неполной картины. Это опаснее очевидно дырявого брифа: связность создаёт ощущение достаточности, и вопросы вы задавать перестаёте.
Проверить такую сборку тоже трудно. Модель не помечает, где ваша мысль, а где правдоподобная подстановка. Вы читаете гладкий текст, узнаёте себя и киваете.
Отдельно про цену. Десять минут речи — это довольно большой кусок текста и примерно две тысячи токенов, и он остаётся в переписке до конца сессии. Каждый следующий ваш вопрос модель читает вместе с ним заново: к двадцатой реплике вы оплатили эти десять минут двадцать раз. Но дороже не деньги, а место. Окно контекста не резиновое, и ваши оговорки лежат в нём рядом с правилами канала. Чем длиннее разговор, тем охотнее модель цепляется за случайную фразу из потока вместо инструкции в скилле. В агентском пайплайне это ещё умножается на каждый шаг цикла.
Отсюда рабочая рамка. Наговаривать — в отдельной сессии, забирать оттуда только сборку, ужимать её руками и приносить в работу абзацем, который вы прочли и одобрили. Проверять при этом не то, что модель оставила, а то, что она выбросила. Ценность приёма не в готовом брифе, а в том, что он вытаскивает из вас причины, которые вы не стали бы печатать. Собеседником модель тут работает отлично. Автором задачи — нет.
#ai #контентменеджерское
❤🔥1😁1
Cloudflare выложила в опенсорс свою внутреннюю ОС для агентов
5 августа Cloudflare открыла исходники Cloudflare OS — платформы, которая даёт каждому сотруднику агента и рабочее пространство, собранное вокруг конкретной компании: её терминологии, процедур и внутренних систем. Развернуть у себя может любая организация.
➡️ GitHub
Мне тут интереснее не платформа, а история за ней. Внутри Cloudflare её раздали всем ещё в мае, и пользуются тысячи человек, многие вне инженерных команд. Вместе с агентом они получили общую библиотеку контекста и скиллов: кто-то один находит способ делать работу лучше и этим способом сразу пользуются остальные. Скилл перестаёт быть личной настройкой и становится активом команды, и это, пожалуй, главное изменение из всех.
На первой версии всплыли две вещи. Первая знакома до боли: даже полностью предсказуемые задачи требовали заново поднимать агента и жечь токены там, где хватило бы обычного скрипта. Вторая серьёзнее и вылезла на совместной работе. Доступ к MCP-серверу говорит, какие инструменты агент может вызвать, но не говорит, какие данные он при этом увидел. Как только люди начали делиться пространствами и результатами, через них поехало то, что коллеге видеть не полагалось. Решение получилось изящным: система записывает каждый ресурс, который агент прочитал, история остаётся привязанной к его работе, и когда результат открывает другой человек, проверяется уже его доступ к исходным данным.
Вот это и стоит забрать. Контекст-инжиниринг мы обычно обсуждаем как вопрос качества: как написать скилл, чтобы модель работала лучше. Здесь виден второй слой, про который почти не говорят — вопрос доступа. Агент с ключами к базе знаний видит непубличные материалы и неанонсированные релизы, потом собирает из них пост, и человек на другом конце получает то, к чему сам допуска не имел. Пока агенты работали поодиночке, это была теоретическая проблема. С момента, когда результаты начинают ходить по команде, она становится вполне рабочей.
Оговорка при этом простая: это релиз Cloudflare про инфраструктуру Cloudflare. Разворачивается в их аккаунт, завязано на их Workers и Access, кастомизацию продают партнёры. Опенсорс тут скорее способ раздать платформу, чем отдать её. Поэтому смотреть я бы советовал не на код, а на постановку задачи — агент как общий актив компании, скиллы как коллективное знание, доступ как часть платформы, а не забота автора промпта. Эти три вещи переносятся куда угодно, независимо от того, на чьей инфраструктуре вы живёте.
#ai
5 августа Cloudflare открыла исходники Cloudflare OS — платформы, которая даёт каждому сотруднику агента и рабочее пространство, собранное вокруг конкретной компании: её терминологии, процедур и внутренних систем. Развернуть у себя может любая организация.
➡️ GitHub
Мне тут интереснее не платформа, а история за ней. Внутри Cloudflare её раздали всем ещё в мае, и пользуются тысячи человек, многие вне инженерных команд. Вместе с агентом они получили общую библиотеку контекста и скиллов: кто-то один находит способ делать работу лучше и этим способом сразу пользуются остальные. Скилл перестаёт быть личной настройкой и становится активом команды, и это, пожалуй, главное изменение из всех.
На первой версии всплыли две вещи. Первая знакома до боли: даже полностью предсказуемые задачи требовали заново поднимать агента и жечь токены там, где хватило бы обычного скрипта. Вторая серьёзнее и вылезла на совместной работе. Доступ к MCP-серверу говорит, какие инструменты агент может вызвать, но не говорит, какие данные он при этом увидел. Как только люди начали делиться пространствами и результатами, через них поехало то, что коллеге видеть не полагалось. Решение получилось изящным: система записывает каждый ресурс, который агент прочитал, история остаётся привязанной к его работе, и когда результат открывает другой человек, проверяется уже его доступ к исходным данным.
Вот это и стоит забрать. Контекст-инжиниринг мы обычно обсуждаем как вопрос качества: как написать скилл, чтобы модель работала лучше. Здесь виден второй слой, про который почти не говорят — вопрос доступа. Агент с ключами к базе знаний видит непубличные материалы и неанонсированные релизы, потом собирает из них пост, и человек на другом конце получает то, к чему сам допуска не имел. Пока агенты работали поодиночке, это была теоретическая проблема. С момента, когда результаты начинают ходить по команде, она становится вполне рабочей.
Оговорка при этом простая: это релиз Cloudflare про инфраструктуру Cloudflare. Разворачивается в их аккаунт, завязано на их Workers и Access, кастомизацию продают партнёры. Опенсорс тут скорее способ раздать платформу, чем отдать её. Поэтому смотреть я бы советовал не на код, а на постановку задачи — агент как общий актив компании, скиллы как коллективное знание, доступ как часть платформы, а не забота автора промпта. Эти три вещи переносятся куда угодно, независимо от того, на чьей инфраструктуре вы живёте.
#ai
👍2
Инженер Контекста
Хочу выкладывать отдельные скиллы в опенсорс
Как и обещал, а вы голосовали, скилл aeo-trust-blocks для аудита и переработки текста под AI-выдачу. Проверяет, насколько безопасно ИИ-поисковикам (ChatGPT, Perplexity, Google AI Overviews, Яндекс Нейро) цитировать ваш контент, и переписывает слабые места в самодостаточные блоки доверия — Extractable Trust Blocks.
Что внутри:
➡️ Аудит cite-safety — каждый блок текста оценивается по шкале 0–10 (извлекаемость, прямой ответ, фактологичность, структура, объём, имплицитные ссылки, нейтральность);
➡️ чек-лист самодостаточности и каталог «слепых зон контекста»;
➡️ формула Trust Block: [Утверждение] → [Объяснение] → [Граница применимости] → [Пример/Источник] и 6 типов блоков под разные интенты (answer capsule, fact block, comparison, how-to, definition, key takeaway);
➡️ замены «размыто → конкретно» («быстрое внедрение» → «внедрение за 2–4 часа»);
➡️ безопасная JSON-LD-разметка (Article, FAQPage, Organization) без нарушения structured data policies;
➡️ контракт с голосом канала: что переводить в ETB, а что оставить живым;
➡️ защита фактуры: цифры, цитаты и атрибуции при переработке не меняются.
Результат — таблица аудита (фрагмент → проблемы → переработанный блок → как повышен cite-safety) и итоговый Cite-Safety Score до/после.
📌 GitHub📌
Следующий скилл на тысяче подписчиков, что на моём скучном контенте выглядит не очень реальным. 😂
#ai_skills #ai
Что внутри:
Результат — таблица аудита (фрагмент → проблемы → переработанный блок → как повышен cite-safety) и итоговый Cite-Safety Score до/после.
📌 GitHub
Следующий скилл на тысяче подписчиков, что на моём скучном контенте выглядит не очень реальным. 😂
#ai_skills #ai
Please open Telegram to view this post
VIEW IN TELEGRAM
❤🔥2🔥2
Ассистенты расходятся не на проценты, а принципиально
Месяц назад по отчёту Similarweb я писал, что ИИ-поиск фрагментируется: доля ChatGPT в вебе просела с ~76% до ~53%, Gemini подобрал разницу. Открытым остался вопрос: расхождение между ассистентами — это разница в оттенках или разные ответы? Появились цифры — это разные ответы.
Вышел AI Software Index 2026: 126 категорий софта, 1825 брендов, 9978 ответов (5023 у ChatGPT, 4955 у Gemini). Около 80 покупательских формулировок на категорию — «какая CRM лучше для малого бизнеса», «я фрилансер, нужен биллинг». Собирали 6 августа в живых веб-приложениях, а не через API.
В каждой третьей категории два ассистента называют разный продукт №1.
Что ещё в цифрах:
→ ChatGPT, рекомендуя продукт, в 53% случаев ссылается на сайт самого продукта. Gemini — в 13%, остальное тянет со сторонних страниц, часто из блогов других софтверных компаний.
→ Один и тот же бренд забирает от 34% до 90% ответов в зависимости от того, сказал покупатель «я фрилансер» или «мы энтерпрайз».
→ Британская и американская формулировка одного вопроса меняют лидера примерно в половине измеримых категорий.
→ Присутствие ≠ победа: HubSpot в 19 лидербордах — три победы. Salesforce: 13 и ноль. QuickBooks: 7 и пять.
→ Где-то ответ забетонирован: GitHub первый в 91% ответов про CI/CD, Shopify — в 84% про e-commerce, Miro — в 83% про доски.
Дисклеймер: индекс выпустила GetIntel, которая продаёт мониторинг ИИ-видимости бренда. Исследование ровно про ту проблему, которую она монетизирует. Методология самопубликуемая, срез однодневный, «победа» = первый упомянутый в ответе бренд.
Что с этим делать
Разрыв 53% против 13% — это две разные задачи, а не одна. Для ChatGPT ваш сайт и есть источник: документация, сравнения, цены, сценарии. Вопрос только в том, есть ли там что вынуть. Для Gemini вашего сайта почти не существует, работает то, что о вас написали снаружи.
Каталоги отзывов на этом фоне выглядят бледно: 5% на троих против отраслевых медиа и живых обсуждений.
Ответ собирается под роль покупателя. Разброс от 34% до 90% значит, что нужны страницы и абзацы, где роль названа его словами, а не вашими сегментами из презентации.
И поправка к тому, что я советовал в прошлый раз. Я предлагал прогонять 20–30 запросов в месяц и вести реестр упоминаний. Этого мало. Когда одна смена роли двигает бренд на 56 пунктов, тридцать запросов дадут красивое, но случайное число. Мерить надо матрицей: базовая формулировка × роль × локаль. И смотреть не среднее, а размах. Большой размах означает, что позиции у вас нет — есть лотерея. И чинится это не подгонкой под ответ, а плотностью и извлекаемостью того, что модель о вас находит.
Под извлекаемость я недавно выкладывал скилл aeo-trust-blocks: аудит cite-safety и переработка текста в самодостаточные блоки. Индекс объясняет, зачем он нужен. В половине случаев ChatGPT подтверждает рекомендацию вашей же страницей. Если на ней нечего процитировать — подтверждать нечем.
#geo #ai
Месяц назад по отчёту Similarweb я писал, что ИИ-поиск фрагментируется: доля ChatGPT в вебе просела с ~76% до ~53%, Gemini подобрал разницу. Открытым остался вопрос: расхождение между ассистентами — это разница в оттенках или разные ответы? Появились цифры — это разные ответы.
Вышел AI Software Index 2026: 126 категорий софта, 1825 брендов, 9978 ответов (5023 у ChatGPT, 4955 у Gemini). Около 80 покупательских формулировок на категорию — «какая CRM лучше для малого бизнеса», «я фрилансер, нужен биллинг». Собирали 6 августа в живых веб-приложениях, а не через API.
В каждой третьей категории два ассистента называют разный продукт №1.
Что ещё в цифрах:
→ ChatGPT, рекомендуя продукт, в 53% случаев ссылается на сайт самого продукта. Gemini — в 13%, остальное тянет со сторонних страниц, часто из блогов других софтверных компаний.
→ Один и тот же бренд забирает от 34% до 90% ответов в зависимости от того, сказал покупатель «я фрилансер» или «мы энтерпрайз».
→ Британская и американская формулировка одного вопроса меняют лидера примерно в половине измеримых категорий.
→ Присутствие ≠ победа: HubSpot в 19 лидербордах — три победы. Salesforce: 13 и ноль. QuickBooks: 7 и пять.
→ Где-то ответ забетонирован: GitHub первый в 91% ответов про CI/CD, Shopify — в 84% про e-commerce, Miro — в 83% про доски.
Дисклеймер: индекс выпустила GetIntel, которая продаёт мониторинг ИИ-видимости бренда. Исследование ровно про ту проблему, которую она монетизирует. Методология самопубликуемая, срез однодневный, «победа» = первый упомянутый в ответе бренд.
Что с этим делать
Разрыв 53% против 13% — это две разные задачи, а не одна. Для ChatGPT ваш сайт и есть источник: документация, сравнения, цены, сценарии. Вопрос только в том, есть ли там что вынуть. Для Gemini вашего сайта почти не существует, работает то, что о вас написали снаружи.
Каталоги отзывов на этом фоне выглядят бледно: 5% на троих против отраслевых медиа и живых обсуждений.
Ответ собирается под роль покупателя. Разброс от 34% до 90% значит, что нужны страницы и абзацы, где роль названа его словами, а не вашими сегментами из презентации.
И поправка к тому, что я советовал в прошлый раз. Я предлагал прогонять 20–30 запросов в месяц и вести реестр упоминаний. Этого мало. Когда одна смена роли двигает бренд на 56 пунктов, тридцать запросов дадут красивое, но случайное число. Мерить надо матрицей: базовая формулировка × роль × локаль. И смотреть не среднее, а размах. Большой размах означает, что позиции у вас нет — есть лотерея. И чинится это не подгонкой под ответ, а плотностью и извлекаемостью того, что модель о вас находит.
Под извлекаемость я недавно выкладывал скилл aeo-trust-blocks: аудит cite-safety и переработка текста в самодостаточные блоки. Индекс объясняет, зачем он нужен. В половине случаев ChatGPT подтверждает рекомендацию вашей же страницей. Если на ней нечего процитировать — подтверждать нечем.
#geo #ai
❤🔥1🔥1
Контент Claude теперь помечен. И это не новость про списывающих студентов
11 августа Anthropic подтвердила, что маркирует контент, который создают с помощью их моделей. Не видимой плашкой, а маркерами внутри . На следующий день TechCrunch вышел с материалом о том, как на это реагируют в реддите: заголовок про пользователей, которые злятся, потому что их поймают на работе и на учёбе. Но интереснее реакций механика.
Что сделали:
— причина - кодекс прозрачности в рамках EU AI Act, вступил в силу 2 августа. Требует помечать сгенерированный или отредактированный ИИ контент так, чтобы метку читали другие системы. Подписанты не только Anthropic.
— все модели, вышедшие после 2 августа, метят и текст, и файлы. Для файлов — открытый стандарт C2PA.
— метка ставится на уровне модели. То есть она есть везде, откуда бы текст ни вышел: API, чат, Claude Code, Cowork, Tag.
— метка едет вместе с текстом при копировании и, по формулировке справки, может пережить часть правок. Сколько правок её снимают не уточняется.
— на старые модели поддержку обещают дораскатить.
Претензии делятся на две неравные части. Одна честная: модели учили на чужих текстах, никого не спрашивая, а теперь метят своё. Ирония тут есть. Вторая сводится к «меня поймают», но подаётся как защита невинных: студент, попросивший переставить абзац, журналист, попросивший конспект стенограммы. Только конспект с меткой становится проблемой ровно в одном случае: если его вставляют в статью как свой текст. Тогда проблема не в метке. Показательно, что в тех же тредах большинство комментаторов встало на сторону маркировки.
Что меняется у редакции
Предупреждать, что вы генерируете с помощью ИИ перестало быть вашим решением. Раньше «говорить ли заказчику, что черновик собрал агент» было вопросом договорённостей и совести. Теперь это свойство файла. Вопрос только в том, узнает заказчик об этом от вас или без вас.
Стилевые детекторы съезжают на второй план. Я рассказывал про свой слой проверок на GitHub Actions — там среди прочего скрипт считает плотность тире и ищет следы машинного текста. Это эвристика, она угадывает по стилю. Метка не угадывает, она в источнике. Значит, такие детекторы перестают быть ответом на вопрос «писал ли это ИИ» и остаются тем, чем и должны быть, — проверкой качества, а не происхождения.
Асимметрия, которую легко упустить. Наличие метки — сильное свидетельство. Отсутствие не значит ничего: метят не все и не везде, старые модели дораскатывают, локальные модели никто не обязывает. Любая проверка сотрудников или студентов «на ИИ» по этому принципу будет ловить одних и пропускать других. Строить такие процедуры начнут уже осенью, а границы у метки пока нет.
И к тому, о чём уже писал
В манифесте контент-опса у меня стояла строчка: ответственность за выпущенное важнее скорости выпуска. Тогда это была позиция. Теперь у неё появился технический носитель — происхождение едет вместе с текстом и доезжает до читателя.
А ещё я обещал развернуть content sec ops. Вот его первый слой, и он не про доступы агента к базе знаний, а про провенанс: знаем ли мы, что именно в материале сгенерировано, зафиксировано ли это где-то помимо головы редактора, и что мы отвечаем, когда спросят. Редакция с логом пайплайна ответит за минуту. Таких пока мало.
Что имеет смысл сделать на этой неделе: записать в редполитику, где вы используете генерацию и что сообщаете об этом клиенту. Одна страница, до того как вопрос прилетит снаружи.
#ai #contentops
11 августа Anthropic подтвердила, что маркирует контент, который создают с помощью их моделей. Не видимой плашкой, а маркерами внутри . На следующий день TechCrunch вышел с материалом о том, как на это реагируют в реддите: заголовок про пользователей, которые злятся, потому что их поймают на работе и на учёбе. Но интереснее реакций механика.
Что сделали:
— причина - кодекс прозрачности в рамках EU AI Act, вступил в силу 2 августа. Требует помечать сгенерированный или отредактированный ИИ контент так, чтобы метку читали другие системы. Подписанты не только Anthropic.
— все модели, вышедшие после 2 августа, метят и текст, и файлы. Для файлов — открытый стандарт C2PA.
— метка ставится на уровне модели. То есть она есть везде, откуда бы текст ни вышел: API, чат, Claude Code, Cowork, Tag.
— метка едет вместе с текстом при копировании и, по формулировке справки, может пережить часть правок. Сколько правок её снимают не уточняется.
— на старые модели поддержку обещают дораскатить.
Претензии делятся на две неравные части. Одна честная: модели учили на чужих текстах, никого не спрашивая, а теперь метят своё. Ирония тут есть. Вторая сводится к «меня поймают», но подаётся как защита невинных: студент, попросивший переставить абзац, журналист, попросивший конспект стенограммы. Только конспект с меткой становится проблемой ровно в одном случае: если его вставляют в статью как свой текст. Тогда проблема не в метке. Показательно, что в тех же тредах большинство комментаторов встало на сторону маркировки.
Что меняется у редакции
Предупреждать, что вы генерируете с помощью ИИ перестало быть вашим решением. Раньше «говорить ли заказчику, что черновик собрал агент» было вопросом договорённостей и совести. Теперь это свойство файла. Вопрос только в том, узнает заказчик об этом от вас или без вас.
Стилевые детекторы съезжают на второй план. Я рассказывал про свой слой проверок на GitHub Actions — там среди прочего скрипт считает плотность тире и ищет следы машинного текста. Это эвристика, она угадывает по стилю. Метка не угадывает, она в источнике. Значит, такие детекторы перестают быть ответом на вопрос «писал ли это ИИ» и остаются тем, чем и должны быть, — проверкой качества, а не происхождения.
Асимметрия, которую легко упустить. Наличие метки — сильное свидетельство. Отсутствие не значит ничего: метят не все и не везде, старые модели дораскатывают, локальные модели никто не обязывает. Любая проверка сотрудников или студентов «на ИИ» по этому принципу будет ловить одних и пропускать других. Строить такие процедуры начнут уже осенью, а границы у метки пока нет.
И к тому, о чём уже писал
В манифесте контент-опса у меня стояла строчка: ответственность за выпущенное важнее скорости выпуска. Тогда это была позиция. Теперь у неё появился технический носитель — происхождение едет вместе с текстом и доезжает до читателя.
А ещё я обещал развернуть content sec ops. Вот его первый слой, и он не про доступы агента к базе знаний, а про провенанс: знаем ли мы, что именно в материале сгенерировано, зафиксировано ли это где-то помимо головы редактора, и что мы отвечаем, когда спросят. Редакция с логом пайплайна ответит за минуту. Таких пока мало.
Что имеет смысл сделать на этой неделе: записать в редполитику, где вы используете генерацию и что сообщаете об этом клиенту. Одна страница, до того как вопрос прилетит снаружи.
#ai #contentops
🔥2🤔1
Проверка, которую агент не может пропустить
Готовил доклад про контроль качества в своей фабрике агентов и поймал себя на мысли: самый недооценённый слой в ней — хуки. Про промпты пишут все, про хуки почти никто.
Проблема, из которой они выросли. Долго все мои проверки жили в промптах: правила в контексте, субагент-фактчекер, редакторская вычитка. Они работают, но у этого доверия есть слепое пятно: проверка случается, если агент про неё «вспомнил», если правило доехало до контекста. А когда не сработало, узнаёшь уже на вычитке.
Хук устроен иначе. Это скрипт, который среда запускает сама на событие. Агент его не вызывает, а значит не может забыть, пропустить или уговорить себя, что в этот раз можно без проверки.
Что у меня стоит на хуках:
→ Записал файл — запустился линтер. Невидимые Unicode-символы, самоидентификация модели в тексте: запись возвращается агенту с текстом ошибки, и он сам переписывает файл. Человека в этом цикле нет вообще.
→ Завершение хода: анонсировал — приложи. Модель любит написать «запускаю фактчекера» и не запустить: слова есть, работы нет. Хук проверяет, что за словами стоит реальный вызов.
→ Перед веб-поиском хук сверяется с кэшем исследований. Если то же самое уже искали, агент в сеть не идёт. Это уже не про качество, а про деньги, но механика та же.
И одно правило, без которого всё это умирает: при собственном сбое хук обязан пропустить работу дальше и ничего не блокировать.
Главное отличие от проверок в промптах сформулирую так: промпт — это просьба, хук — это физика. Раньше на вопрос «а точно ли всё проверилось» отвечала моя вера в процесс. Теперь отвечает сам процесс.
#ai_agents #contentops
Готовил доклад про контроль качества в своей фабрике агентов и поймал себя на мысли: самый недооценённый слой в ней — хуки. Про промпты пишут все, про хуки почти никто.
Проблема, из которой они выросли. Долго все мои проверки жили в промптах: правила в контексте, субагент-фактчекер, редакторская вычитка. Они работают, но у этого доверия есть слепое пятно: проверка случается, если агент про неё «вспомнил», если правило доехало до контекста. А когда не сработало, узнаёшь уже на вычитке.
Хук устроен иначе. Это скрипт, который среда запускает сама на событие. Агент его не вызывает, а значит не может забыть, пропустить или уговорить себя, что в этот раз можно без проверки.
Что у меня стоит на хуках:
→ Записал файл — запустился линтер. Невидимые Unicode-символы, самоидентификация модели в тексте: запись возвращается агенту с текстом ошибки, и он сам переписывает файл. Человека в этом цикле нет вообще.
→ Завершение хода: анонсировал — приложи. Модель любит написать «запускаю фактчекера» и не запустить: слова есть, работы нет. Хук проверяет, что за словами стоит реальный вызов.
→ Перед веб-поиском хук сверяется с кэшем исследований. Если то же самое уже искали, агент в сеть не идёт. Это уже не про качество, а про деньги, но механика та же.
И одно правило, без которого всё это умирает: при собственном сбое хук обязан пропустить работу дальше и ничего не блокировать.
Главное отличие от проверок в промптах сформулирую так: промпт — это просьба, хук — это физика. Раньше на вопрос «а точно ли всё проверилось» отвечала моя вера в процесс. Теперь отвечает сам процесс.
#ai_agents #contentops
1❤2👍2🔥1🤔1
Давно хотел ввести новую более менее постоянную рубрику про полезные плагины — #ai_plugin
Начнём с максимально полезного — diagram-design — это новое дополнение к Claude Code, Codex и Pi. Уже 3,3 тысячи звёзд на GitHub, раздаётся бесплатно, лицензия MIT.
Что оно умеет
38 видов схем. Есть таймлайн, воронка, пирамида, квадрант «важность / трудозатраты», оргструктура, диаграмма Венна, столбики, линии, Гант. Всё, что обычно нужно в статье, лендинге или презентации.
Каждая схема — в трёх версиях: светлая, тёмная и «журнальная» с подписями-карточками. Файл открывается в браузере без установки чего-либо ещё и выгружается в PNG или SVG. Можно унести в статью, в слайды или отдать дизайнеру.
Главное — подстройка под ваш стиль
Пишете: «возьми фирменный стиль с такого-то сайта». Инструмент открывает главную страницу, находит цвета и шрифты, показывает, что предлагает применить, и ждёт вашего «да». Фон сайта становится фоном схемы, цвет кнопки — цветом акцента, ваш основной шрифт — шрифтом подписей.
Заодно проверяет читаемость: если фирменный цвет на мелком тексте плохо виден, предлагает подправить и объясняет, почему.
И приятная мелочь: при первом запуске в новом проекте он останавливается и спрашивает — настроить стиль или рисовать в дефолтном. Молча выдать безликую картинку не даст.
Автор зашила свой редстандарт: один акцентный цвет, один-два элемента, на которые читатель должен посмотреть первыми, тонкие линии, никаких теней. Целевая плотность — 4 из 10. Принцип: каждый блок должен заслужить своё место.
Начнём с максимально полезного — diagram-design — это новое дополнение к Claude Code, Codex и Pi. Уже 3,3 тысячи звёзд на GitHub, раздаётся бесплатно, лицензия MIT.
Что оно умеет
38 видов схем. Есть таймлайн, воронка, пирамида, квадрант «важность / трудозатраты», оргструктура, диаграмма Венна, столбики, линии, Гант. Всё, что обычно нужно в статье, лендинге или презентации.
Каждая схема — в трёх версиях: светлая, тёмная и «журнальная» с подписями-карточками. Файл открывается в браузере без установки чего-либо ещё и выгружается в PNG или SVG. Можно унести в статью, в слайды или отдать дизайнеру.
Главное — подстройка под ваш стиль
Пишете: «возьми фирменный стиль с такого-то сайта». Инструмент открывает главную страницу, находит цвета и шрифты, показывает, что предлагает применить, и ждёт вашего «да». Фон сайта становится фоном схемы, цвет кнопки — цветом акцента, ваш основной шрифт — шрифтом подписей.
Заодно проверяет читаемость: если фирменный цвет на мелком тексте плохо виден, предлагает подправить и объясняет, почему.
И приятная мелочь: при первом запуске в новом проекте он останавливается и спрашивает — настроить стиль или рисовать в дефолтном. Молча выдать безликую картинку не даст.
Автор зашила свой редстандарт: один акцентный цвет, один-два элемента, на которые читатель должен посмотреть первыми, тонкие линии, никаких теней. Целевая плотность — 4 из 10. Принцип: каждый блок должен заслужить своё место.
1🔥3👍1🤔1
DeepSeek открыл свой харнесс. За неделю вокруг него собрался каталог из 97 плагинов
Сначала база, потому что «харнесс» стало жаргоном, а объясняют его редко.
Модель — это функция «текст → текст». Она не умеет читать ваш репозиторий, запускать тесты, разбирать чужой стектрейс, откатываться после падения и продолжать работу на сороковом шаге. Всё это делает обвязка: агентный цикл, набор инструментов, системные промпты, права доступа, компакция контекста, песочница, логирование. Это и есть харнесс. Claude Code — харнесс. Модель — мозг, харнесс — руки, глаза и правила игры.
Отсюда следствие: цифра на агентном бенчмарке — это результат связки модель+харнесс, а не только свойство модели.
13 августа DeepSeek выложил Harness v0.1 в developer preview. MIT, пакет
Как устроено
Главный принцип — «всё есть плагин». В обычном агенте ядро зашито: разработчики решили, какая модель, какие инструменты, как выглядит интерфейс, — а вы дописываете что-то по краям. Здесь сменное всё: модель, инструменты, скиллы, сессии, песочница, работа с файлами, сам цикл агента и интерфейс. Меняется конфигом, лезть в исходники не надо. Ставите и снимаете плагины на ходу, без перезапуска и без мусора после них — за это отвечает Cordis, микроядро под капотом.
Работать можно в четырёх режимах. Standard — обычный полноценный агент. Minimal — всего два инструмента, режим для замеров на бенчмарках. Creator — чтобы собрать свою сборку. И Code — самый любопытный.
Про Code стоит объяснить отдельно. Обычно агент дёргает инструменты по одному, и результат каждого целиком уезжает в контекст. Поиск нашёл сорок файлов — все сорок путей в контексте. Прочитали эти сорок файлов — ещё сорок портянок текста, которые модель перечитывает на каждом шаге. В Code-режиме модель вместо этого пишет маленькую программу, харнесс запускает её целиком, и назад приходит только итог — три строки вместо восьмидесяти простыней. Экономия контекста огромная. Минус — программу надо написать без ошибок с первого раза: если ошибётся, упадёт вся, а не один шаг.
И третье — всё пишется. Правило простое: что увидела модель, то и записано. В лог попадают промпты, рассуждения, вызовы инструментов и их результаты, каждая подгрузка контекста. Из этой записи можно продолжить сессию, ответвиться от любой точки, найти нужный момент и проиграть заново. Кто хоть раз пытался понять, почему агент на тридцатом шаге снёс тесты, оценит.
Что произошло за неделю
Появился каталог того, что успели написать под dsh. 97 плагинов, CC0, семь категорий, свой сайт и бейдж. У самого каталога 54 звезды — это ещё заявка на роль справочника, не справочник. И читать «97 плагинов» как «97 независимых авторов» не стоит: больше трети позиций — репозитории одной организации, omdsh-dev.
Показательно, за что взялись в первую очередь. Три плагина решают одну проблему — контекст:
→ dsh-context-doctor — аудит инъекций, токен-стоимость цепочек инструкций, каталогов скиллов и схем инструментов, детект дублей и конфликтов
→ dsh-tool-search — выдача схем инструментов по требованию вместо загрузки всех сразу
→ dsh-agent-budget — бюджет токенов на дерево агентов
И самый интересный плагин в списке: dsh-chat-import — тянет истории из Claude Code, Codex, ChatGPT и Cursor и превращает их в возобновляемые сессии dsh. Экосистема прекрасно понимает, откуда приходят люди.
Прежде чем идти ставить
Отбора в каталоге нет: пул-реквест — это одна строка в двух README, английском и китайском. Ни ревью качества, ни аудита безопасности. При том что часть плагинов лезет в файловую систему, в базы и в управление компьютером. Кстати, искать плагины можно и мимо каталога — по тегу dsh-plugin.
Сам харнесс — v0.1, и в README капслоком обещаны ломающие изменения. Писать плагин под dsh сегодня — не «поставил и забыл», а подписка на чужой рефакторинг.
Подробный разбор архитектуры и таблица по всем лабам, у которых уже есть свой харнесс, — есть на Хабре.
#ai #ai_plugin
Сначала база, потому что «харнесс» стало жаргоном, а объясняют его редко.
Модель — это функция «текст → текст». Она не умеет читать ваш репозиторий, запускать тесты, разбирать чужой стектрейс, откатываться после падения и продолжать работу на сороковом шаге. Всё это делает обвязка: агентный цикл, набор инструментов, системные промпты, права доступа, компакция контекста, песочница, логирование. Это и есть харнесс. Claude Code — харнесс. Модель — мозг, харнесс — руки, глаза и правила игры.
Отсюда следствие: цифра на агентном бенчмарке — это результат связки модель+харнесс, а не только свойство модели.
13 августа DeepSeek выложил Harness v0.1 в developer preview. MIT, пакет
@deepseek-ai/dsh в npm, запуск одной строкой, веб-морда на 127.0.0.1:3080. За двое суток — больше 95 тысяч звёзд.Как устроено
Главный принцип — «всё есть плагин». В обычном агенте ядро зашито: разработчики решили, какая модель, какие инструменты, как выглядит интерфейс, — а вы дописываете что-то по краям. Здесь сменное всё: модель, инструменты, скиллы, сессии, песочница, работа с файлами, сам цикл агента и интерфейс. Меняется конфигом, лезть в исходники не надо. Ставите и снимаете плагины на ходу, без перезапуска и без мусора после них — за это отвечает Cordis, микроядро под капотом.
Работать можно в четырёх режимах. Standard — обычный полноценный агент. Minimal — всего два инструмента, режим для замеров на бенчмарках. Creator — чтобы собрать свою сборку. И Code — самый любопытный.
Про Code стоит объяснить отдельно. Обычно агент дёргает инструменты по одному, и результат каждого целиком уезжает в контекст. Поиск нашёл сорок файлов — все сорок путей в контексте. Прочитали эти сорок файлов — ещё сорок портянок текста, которые модель перечитывает на каждом шаге. В Code-режиме модель вместо этого пишет маленькую программу, харнесс запускает её целиком, и назад приходит только итог — три строки вместо восьмидесяти простыней. Экономия контекста огромная. Минус — программу надо написать без ошибок с первого раза: если ошибётся, упадёт вся, а не один шаг.
И третье — всё пишется. Правило простое: что увидела модель, то и записано. В лог попадают промпты, рассуждения, вызовы инструментов и их результаты, каждая подгрузка контекста. Из этой записи можно продолжить сессию, ответвиться от любой точки, найти нужный момент и проиграть заново. Кто хоть раз пытался понять, почему агент на тридцатом шаге снёс тесты, оценит.
Что произошло за неделю
Появился каталог того, что успели написать под dsh. 97 плагинов, CC0, семь категорий, свой сайт и бейдж. У самого каталога 54 звезды — это ещё заявка на роль справочника, не справочник. И читать «97 плагинов» как «97 независимых авторов» не стоит: больше трети позиций — репозитории одной организации, omdsh-dev.
Показательно, за что взялись в первую очередь. Три плагина решают одну проблему — контекст:
→ dsh-context-doctor — аудит инъекций, токен-стоимость цепочек инструкций, каталогов скиллов и схем инструментов, детект дублей и конфликтов
→ dsh-tool-search — выдача схем инструментов по требованию вместо загрузки всех сразу
→ dsh-agent-budget — бюджет токенов на дерево агентов
И самый интересный плагин в списке: dsh-chat-import — тянет истории из Claude Code, Codex, ChatGPT и Cursor и превращает их в возобновляемые сессии dsh. Экосистема прекрасно понимает, откуда приходят люди.
Прежде чем идти ставить
Отбора в каталоге нет: пул-реквест — это одна строка в двух README, английском и китайском. Ни ревью качества, ни аудита безопасности. При том что часть плагинов лезет в файловую систему, в базы и в управление компьютером. Кстати, искать плагины можно и мимо каталога — по тегу dsh-plugin.
Сам харнесс — v0.1, и в README капслоком обещаны ломающие изменения. Писать плагин под dsh сегодня — не «поставил и забыл», а подписка на чужой рефакторинг.
Подробный разбор архитектуры и таблица по всем лабам, у которых уже есть свой харнесс, — есть на Хабре.
#ai #ai_plugin
👍1🆒1
На Хабре вышла статья коллеги о том, как развернуть локальный ИИ-агент в своём контуре — Ollama плюс OpenClaw. Рабочая инструкция, пользуйтесь.
#ai_agents #habr
#ai_agents #habr
👍2
Зашли с вопросом про стратегию или концепцию AI-first в контент. Но спросили с пониманием, что это когда в любом процессе буквально сначала ИИ. Сгенерили, потом посмотрели, что вышло.
Можно со мной тут поспорить, конечно, но «first» в таких терминах никогда не значило «сначала». Mobile-first — не про то, что мобильную версию рисуют раньше десктопной, а про то, что мобильный экран учитывается в каждом решении. Так же и здесь: AI-first — не порядок шагов, а то, что ИИ встроен во весь процесс, а не стоит отдельным этапом в начале или посередине.
Когда ИИ отдельный этап, вы, например, ускоряете написание черновика втрое, но материал упирается в проверку. Текстов стало больше, проверять чужое дороже, чем писать своё, редактор тонет. Локальное ускорение, глобальное замедление — знакомая история же?
Когда ИИ встроен, вы смотрите на весь маршрут материала: от идеи до разбора после публикации, и на каждом отрезке спрашиваете, что здесь меняется теперь, когда есть модель.
На планировании раньше спорили, какую тему взять: производство стоило дорого, ошибиться было больно. Теперь дешевле накидать три черновика и посмотреть, какой живой, чем неделю обсуждать один.
На брифе выясняется, что модель не читает мысли. Приходится проговаривать вслух: что на входе, что на выходе, что считается браком. Побочный эффект: люди тоже начинают понимать задачу с первого раза.
По той же причине из головы главреда наконец переезжает в файл редстандарт. Больно, зато у команды появляется общий критерий вместо «мне не нравится».
На проверке — главное. Сверить факт с источником, поймать разнобой в терминах, прогнать текст по стандарту: всё это машина делает лучше и дешевле, чем пишет. Но ставят её обычно на написание, потому что генерация эффектнее.
И на разборе после публикации: что зашло, что нет, почему. Раньше на это просто не хватало рук.
Проверить себя просто: спросите, что у вас изменилось, кроме того, что тексты теперь пишет модель. Если ничего — это не AI-first, а новый инструмент на одном этапе. Нормально, все с этого начинают, просто не надо называть это стратегией.
И то, что не меняется при любой встроенности: последний шаг человеческий, кто-то ставит подпись. В этом вся разница между «сначала ИИ» и «ИИ везде». В первом случае вы ищете, что бы ему отдать. Во втором понимаете, что оставляете себе и почему.
Брюзжание off. Пойду дальше работать. Постараюсь следующими публикациями дать что-то прикладное, а не только теорию, как нужно строить новые редакции.
#контентменеджерское #ai
Можно со мной тут поспорить, конечно, но «first» в таких терминах никогда не значило «сначала». Mobile-first — не про то, что мобильную версию рисуют раньше десктопной, а про то, что мобильный экран учитывается в каждом решении. Так же и здесь: AI-first — не порядок шагов, а то, что ИИ встроен во весь процесс, а не стоит отдельным этапом в начале или посередине.
Когда ИИ отдельный этап, вы, например, ускоряете написание черновика втрое, но материал упирается в проверку. Текстов стало больше, проверять чужое дороже, чем писать своё, редактор тонет. Локальное ускорение, глобальное замедление — знакомая история же?
Когда ИИ встроен, вы смотрите на весь маршрут материала: от идеи до разбора после публикации, и на каждом отрезке спрашиваете, что здесь меняется теперь, когда есть модель.
На планировании раньше спорили, какую тему взять: производство стоило дорого, ошибиться было больно. Теперь дешевле накидать три черновика и посмотреть, какой живой, чем неделю обсуждать один.
На брифе выясняется, что модель не читает мысли. Приходится проговаривать вслух: что на входе, что на выходе, что считается браком. Побочный эффект: люди тоже начинают понимать задачу с первого раза.
По той же причине из головы главреда наконец переезжает в файл редстандарт. Больно, зато у команды появляется общий критерий вместо «мне не нравится».
На проверке — главное. Сверить факт с источником, поймать разнобой в терминах, прогнать текст по стандарту: всё это машина делает лучше и дешевле, чем пишет. Но ставят её обычно на написание, потому что генерация эффектнее.
И на разборе после публикации: что зашло, что нет, почему. Раньше на это просто не хватало рук.
Проверить себя просто: спросите, что у вас изменилось, кроме того, что тексты теперь пишет модель. Если ничего — это не AI-first, а новый инструмент на одном этапе. Нормально, все с этого начинают, просто не надо называть это стратегией.
И то, что не меняется при любой встроенности: последний шаг человеческий, кто-то ставит подпись. В этом вся разница между «сначала ИИ» и «ИИ везде». В первом случае вы ищете, что бы ему отдать. Во втором понимаете, что оставляете себе и почему.
Брюзжание off. Пойду дальше работать. Постараюсь следующими публикациями дать что-то прикладное, а не только теорию, как нужно строить новые редакции.
#контентменеджерское #ai
👍3🤔1
Вышел DeepSeek V4.1-Flash. Что там по применимости для контента?
Если лень всё читать, то вот сразу вывод: модели дешевеют быстрее, чем умнеют. Читать миллион токенов теперь почти ничего не стоит, а фактология осталась на прежнем уровне. Значит, на первый план выходит не выбор модели, а то, что мы кладём ей в контекст. Кто собирает хороший контекст, тот получает хороший текст. Кто надеется на модель, получит уверенную ошибку, просто дешевле. Контент-инженерия всё больше превращается в инженерию контекста.
Теперь подробности. В отчёте DeepSeek на 51 страницу нет ни одного теста на качество текста и ни слова о русском языке. Модель делали под агентов и код. Но часть выводов прямо переносится на контент-пайплайны.
1. Редстандарты в начало промпта
Главное в релизе — дешёвый контекст. Префилл стал почти вдвое дешевле, KV-кэш — вчетверо компактнее. Кэш префикса DeepSeek хранит не меньше 72 часов. В контент-пайплайне постоянная часть промпта большая: редстандарт, tone of voice, эталоны, описание продукта. Её выгодно ставить первой и не менять между запусками. Всё переменное: задание, исходник, дату — в конец. Если поставить дату в первую строку системного промпта, кэш будет сбрасываться каждый день.
2. Факты давать, а не спрашивать
Слабое место модели — фактология. На SimpleQA-Verified базовая модель набирает 42,3, а V4-Pro — 55,2. Длинные рассуждения не спасают: при переходе с уровня 25 на 100 результат меняется на пару пунктов. Если модель чего-то не знает, додумать это она не сможет.
Для контента вывод простой: имена, даты, цифры и названия продуктов берутся только из источников в контексте. Особенно это касается тех, кто работает на deepseek-v4-pro: с 14 сентября такие запросы молча уйдут на V4.1-Flash.
3. Миллион токенов не значит понимание миллиона токенов
На LongBench-V2 у модели 45,2, у V4-Pro — 51,5. Когда адаптируете длинный отчёт, отдавайте нужные разделы, а не весь PDF целиком.
4. Картинки на вход рабочий инструмент
Модель нативно мультимодальная, на DocVQA у неё 95,6. Слайды спикера, скриншоты интерфейса и таблицы из PDF можно отдавать как есть и просить черновик. При этом картинка сжимается примерно до 1344×1344, так что длинные скриншоты и плотную инфографику лучше резать на части. И цифры, снятые с графиков, стоит проверять: на Chartography у модели 78,9, у Opus 5 — 84.
5. Max не по умолчанию
В API три уровня: low, high и max, внутри это 50, 75 и 100. Переход с 25 на 100 даёт плюс 8–9 пунктов на тестах и примерно в 2,5 раза больше токенов. Большая часть прироста набирается уже к 60–80. Эти данные только по математике и коду, по текстам замеров нет. Моя гипотеза: для рерайта, адаптаций и анонсов хватит low, для аналитики стоит брать high.
Забрать DeepSeek V4.1-Flash, опубликовано под лицензией MIT
#ai
Если лень всё читать, то вот сразу вывод: модели дешевеют быстрее, чем умнеют. Читать миллион токенов теперь почти ничего не стоит, а фактология осталась на прежнем уровне. Значит, на первый план выходит не выбор модели, а то, что мы кладём ей в контекст. Кто собирает хороший контекст, тот получает хороший текст. Кто надеется на модель, получит уверенную ошибку, просто дешевле. Контент-инженерия всё больше превращается в инженерию контекста.
Теперь подробности. В отчёте DeepSeek на 51 страницу нет ни одного теста на качество текста и ни слова о русском языке. Модель делали под агентов и код. Но часть выводов прямо переносится на контент-пайплайны.
1. Редстандарты в начало промпта
Главное в релизе — дешёвый контекст. Префилл стал почти вдвое дешевле, KV-кэш — вчетверо компактнее. Кэш префикса DeepSeek хранит не меньше 72 часов. В контент-пайплайне постоянная часть промпта большая: редстандарт, tone of voice, эталоны, описание продукта. Её выгодно ставить первой и не менять между запусками. Всё переменное: задание, исходник, дату — в конец. Если поставить дату в первую строку системного промпта, кэш будет сбрасываться каждый день.
2. Факты давать, а не спрашивать
Слабое место модели — фактология. На SimpleQA-Verified базовая модель набирает 42,3, а V4-Pro — 55,2. Длинные рассуждения не спасают: при переходе с уровня 25 на 100 результат меняется на пару пунктов. Если модель чего-то не знает, додумать это она не сможет.
Для контента вывод простой: имена, даты, цифры и названия продуктов берутся только из источников в контексте. Особенно это касается тех, кто работает на deepseek-v4-pro: с 14 сентября такие запросы молча уйдут на V4.1-Flash.
3. Миллион токенов не значит понимание миллиона токенов
На LongBench-V2 у модели 45,2, у V4-Pro — 51,5. Когда адаптируете длинный отчёт, отдавайте нужные разделы, а не весь PDF целиком.
4. Картинки на вход рабочий инструмент
Модель нативно мультимодальная, на DocVQA у неё 95,6. Слайды спикера, скриншоты интерфейса и таблицы из PDF можно отдавать как есть и просить черновик. При этом картинка сжимается примерно до 1344×1344, так что длинные скриншоты и плотную инфографику лучше резать на части. И цифры, снятые с графиков, стоит проверять: на Chartography у модели 78,9, у Opus 5 — 84.
5. Max не по умолчанию
В API три уровня: low, high и max, внутри это 50, 75 и 100. Переход с 25 на 100 даёт плюс 8–9 пунктов на тестах и примерно в 2,5 раза больше токенов. Большая часть прироста набирается уже к 60–80. Эти данные только по математике и коду, по текстам замеров нет. Моя гипотеза: для рерайта, адаптаций и анонсов хватит low, для аналитики стоит брать high.
Забрать DeepSeek V4.1-Flash, опубликовано под лицензией MIT
#ai
🔥2
Обещанная история про косяки и разработку агентов, написанная во время перелёта в Москву
То, о чём я сейчас буду рассказывать, наверняка очень хорошо известно любому разработчику. И даже может вызвать у них улыбку. Итак, первую половину года я постоянно писал агенты для контента. Проектировал, вайбкодил, дописывал руками, что не нравилось, снова вайбкодил. Постоянно хотелось что-то улучшить, ускорить, оптимизировать, а затем опять усложнить. На каком то этапе там появился пайтон, экшены в гитхабе, синхронизация с другими репозиториями. И в какой-то момент для меня самого стало казаться, что этот процесс бесконечный.
Почему я вспомнил разработку в начале. Довольно часто знакомые программисты рассказывали, что долго не решались показать какой-то новый продукт, потому что опасались критики и провала. Процесс доработки становился бесконечным, а пока они стремились к идеалу, конкуренты выпускали сырую версию и уже начинали на ней зарабатывать.
Я свой mvp, конечно, раскатал на коллег практически в первые месяцы, но ситуация похожая. От той первой версии, которую забрали коллеги, до следующей анонсированной прошло три-четыре месяца. По своей внутренней нумерации я скакнул от v.1 до 4.55. Это приблизительно, в самолёте не посмотришь ченжлог, да и смысла в этом нет. То есть после первой раскатки я просто ушёл в лютые доработки и не смотрел по сторонам.
К чему это привело лично для меня:
Сложность и монструозность системы. Для всех кроме меня
Я то знаю, почему и зачем все эти проверки и экшены. И даже документацию написал, но кто её читает. Система, которую нельзя объяснить за десять минут, принадлежит одному человеку, даже если лежит в общем репозитории.
Я оптимизировал то, что видел сам
Да, видел много, но только по своим направлениям. Четыре месяца я честно доводил систему до идеала на выборке, которую сам же и составил. В ML для этого есть точное определение: переучился на тестовом наборе. Загуглите сами, что это.
Коллеги остались с v.1
Вот, кстати, это больнее всего. Пока я разгонялся, у них работала первая версия и они к ней приспособились. Придумали обходные пути, завели свои агенты и скиллы, привыкли к её странностям. Моя новая версия для них стала не улучшение, а ломкой того, что уже как-то жило. Чем дольше пауза, тем дороже обходится каждое обновление.
Точка остановки не наступила сама.
Я почему-то ждал, что в какой-то момент станет «готово» и я сам это почувствую. Не чувствуется. Список идей не заканчивается никогда, каждая следующая выглядит как последняя недостающая. Остановиться можно только решением, а не ощущением.
Следующие пару месяцев я не трогал ничего. Просто работал с системой как обычный пользователь, слушал коллег и смотрел по сторонам.
Первое, что выяснилось: половина того, что я написал, используется только мной. Не потому что плохо сделано, потому что не нужно. Я решал задачи, которые люди предпочитают решать другими способами. А то, что реально болит, казалось мне скучным, и я это четыре месяца обходил стороной. Теперь нагоняю.
Второе: пока не трогаешь, наконец видишь, что ломается. Когда каждую неделю выкатываешь новую версию, любой сбой списывается на свежие правки. Когда система стоит неподвижно, становится ясно, что она разваливается стабильно и в одном и том же месте.
Третье, и самое неприятное. За эти два месяца вышло столько всего нового, что какие-то мои проверки и промпты просто перестали иметь смысл. Я месяцами обходил ограничения, которое теперь снято на уровне инструмента. Смотреть по сторонам тоже работа, и я её не делал, потому что был занят.
Так что пауза оказалась не простоем. Она оказалась единственным способом узнать, что строить дальше. Разработка ослепляет: пока пишешь, видишь только следующий шаг.
Теперь стараюсь держать ритм: месяц строю, месяц живу с тем, что построил. Второй месяц даёт больше, чем первый, хотя это до сих пор кажется мне контринтуитивным.
#ai_agents
То, о чём я сейчас буду рассказывать, наверняка очень хорошо известно любому разработчику. И даже может вызвать у них улыбку. Итак, первую половину года я постоянно писал агенты для контента. Проектировал, вайбкодил, дописывал руками, что не нравилось, снова вайбкодил. Постоянно хотелось что-то улучшить, ускорить, оптимизировать, а затем опять усложнить. На каком то этапе там появился пайтон, экшены в гитхабе, синхронизация с другими репозиториями. И в какой-то момент для меня самого стало казаться, что этот процесс бесконечный.
Почему я вспомнил разработку в начале. Довольно часто знакомые программисты рассказывали, что долго не решались показать какой-то новый продукт, потому что опасались критики и провала. Процесс доработки становился бесконечным, а пока они стремились к идеалу, конкуренты выпускали сырую версию и уже начинали на ней зарабатывать.
Я свой mvp, конечно, раскатал на коллег практически в первые месяцы, но ситуация похожая. От той первой версии, которую забрали коллеги, до следующей анонсированной прошло три-четыре месяца. По своей внутренней нумерации я скакнул от v.1 до 4.55. Это приблизительно, в самолёте не посмотришь ченжлог, да и смысла в этом нет. То есть после первой раскатки я просто ушёл в лютые доработки и не смотрел по сторонам.
К чему это привело лично для меня:
Сложность и монструозность системы. Для всех кроме меня
Я то знаю, почему и зачем все эти проверки и экшены. И даже документацию написал, но кто её читает. Система, которую нельзя объяснить за десять минут, принадлежит одному человеку, даже если лежит в общем репозитории.
Я оптимизировал то, что видел сам
Да, видел много, но только по своим направлениям. Четыре месяца я честно доводил систему до идеала на выборке, которую сам же и составил. В ML для этого есть точное определение: переучился на тестовом наборе. Загуглите сами, что это.
Коллеги остались с v.1
Вот, кстати, это больнее всего. Пока я разгонялся, у них работала первая версия и они к ней приспособились. Придумали обходные пути, завели свои агенты и скиллы, привыкли к её странностям. Моя новая версия для них стала не улучшение, а ломкой того, что уже как-то жило. Чем дольше пауза, тем дороже обходится каждое обновление.
Точка остановки не наступила сама.
Я почему-то ждал, что в какой-то момент станет «готово» и я сам это почувствую. Не чувствуется. Список идей не заканчивается никогда, каждая следующая выглядит как последняя недостающая. Остановиться можно только решением, а не ощущением.
Следующие пару месяцев я не трогал ничего. Просто работал с системой как обычный пользователь, слушал коллег и смотрел по сторонам.
Первое, что выяснилось: половина того, что я написал, используется только мной. Не потому что плохо сделано, потому что не нужно. Я решал задачи, которые люди предпочитают решать другими способами. А то, что реально болит, казалось мне скучным, и я это четыре месяца обходил стороной. Теперь нагоняю.
Второе: пока не трогаешь, наконец видишь, что ломается. Когда каждую неделю выкатываешь новую версию, любой сбой списывается на свежие правки. Когда система стоит неподвижно, становится ясно, что она разваливается стабильно и в одном и том же месте.
Третье, и самое неприятное. За эти два месяца вышло столько всего нового, что какие-то мои проверки и промпты просто перестали иметь смысл. Я месяцами обходил ограничения, которое теперь снято на уровне инструмента. Смотреть по сторонам тоже работа, и я её не делал, потому что был занят.
Так что пауза оказалась не простоем. Она оказалась единственным способом узнать, что строить дальше. Разработка ослепляет: пока пишешь, видишь только следующий шаг.
Теперь стараюсь держать ритм: месяц строю, месяц живу с тем, что построил. Второй месяц даёт больше, чем первый, хотя это до сих пор кажется мне контринтуитивным.
#ai_agents
🔥2🤯2👍1
Не давай модели подбирать слова. Заметка для редакторов про метод Птачека
Томас Птачек, человек из мира безопасности, написал заметку о том, как он пишет тексты с ИИ. Метод сводится к двум запретам и одному разрешению.
Правило первое: ни одного слова, предложенного моделью
Обоснование у него любопытное. Модели сверхъестественно хороши в подборе приятных оборотов — это, собственно, их главный навык. Проблема тонкая: модель как будто застряла в режиме, где всё, что она пишет, — заголовок для журнала. Заголовки хороши, но человек, написавший статью из нескольких десятков заголовков, вызывает вопросы.
И дальше он предлагает относиться к правилу как к средству индивидуальной защиты: любой конкретный оборот, предложенный моделью, — вне игры, даже если он вам нравится и даже если вы уверены, что он лучше вашего. Логика в том, что вы не сможете надёжно отлавливать все способы, которыми модель превращает текст в нейрослоп. Поэтому запрет тотальный, без исключений на «ну вот тут же правда удачно».
Правило второе: никакой похвалы
Это он называет более тонкой проблемой — влиянием, а не подстановкой слов. Отдаёте черновик, модель отвечает, что это золото. А в первом черновике большинство абзацев плохи, логика скачет и есть лишних слов семьсот пятьдесят.
Модель одобряет структуру, потом абзацы и переходы, потом выбор слов, метафоры, отсылки. В результате вы укрепляетесь во всех импульсах первого черновика, хотя обычно поступили бы иначе: переписали бы, передумали, заменили абзацы. Именно эти передумывания — основа для вашего голоса. Читатель не поймёт, что не так, но почувствует искусственный привкус.
Обходной приём у него был такой: пару лет он открывал каждый промпт враньём. Помогает, но модель обычно начинает подгонять свои выводы под «цели». Так что нынешний совет проще: запретить похвалу прямым текстом и оставаться начеку.
Что модели разрешено
Тут всё про усталость. Ошибки можно ловить и вручную, но это утомительная работа, а модель не устаёт. Отсюда список: перебор со страдательным залогом, отглагольные существительные вместо действия, повторяющиеся обороты; «очень», «к сожалению», «на самом деле», рассыпанные по черновику, как опилки по верстаку. И отдельно — два-три абзаца, которые надо просто переставить в другое место, отчего ясность мгновенно улучшается.
Цикл: попросить модель найти проблемы, самому переписать проблемные куски, потом дать оба варианта на сравнение. И здесь важная деталь, которую легко упустить: сравнивать надо давать другой модели, без контекста вашей правки. Иначе она знает, что вы только что переписали, и знает, какой ответ вы хотите услышать.
Себе он сделал под это инструмент — редактор с подсветкой и комментариями на полях, где по тексту прогоняются заготовленные промпты-проходы. Но в заметке есть оговорка, которая мне нравится больше самого инструмента: что бы вы ни собрали сами, оно будет лучше моего, потому что собранное самостоятельно всегда лучше подходит своему автору.
Он скормил эту заметку GPT-5 со словами «я не автор», и модель сказала, что текст на 20% длиннее нужного. Птачек пишет: вероятно, она права. Но править он не будет.
Что я об этом думаю
Конечно, я не могу все тексты писать сам. Не для этого я целую фабрику контента написал. Но для редакторов экспертных материалов на Хабр эти приёмы очень пригодятся. Особенно проверки разными моделями.
Однако, я заложил эту логику в фабрику. Например, чистый контекст — это как раз проверка моделью без истории создания и правок текста.
Оригинал тут: sockpuppet.org/blog/2026/09/17/how-to-write-with-an-llm/
#ai #контентменеджерское
Томас Птачек, человек из мира безопасности, написал заметку о том, как он пишет тексты с ИИ. Метод сводится к двум запретам и одному разрешению.
Правило первое: ни одного слова, предложенного моделью
Обоснование у него любопытное. Модели сверхъестественно хороши в подборе приятных оборотов — это, собственно, их главный навык. Проблема тонкая: модель как будто застряла в режиме, где всё, что она пишет, — заголовок для журнала. Заголовки хороши, но человек, написавший статью из нескольких десятков заголовков, вызывает вопросы.
И дальше он предлагает относиться к правилу как к средству индивидуальной защиты: любой конкретный оборот, предложенный моделью, — вне игры, даже если он вам нравится и даже если вы уверены, что он лучше вашего. Логика в том, что вы не сможете надёжно отлавливать все способы, которыми модель превращает текст в нейрослоп. Поэтому запрет тотальный, без исключений на «ну вот тут же правда удачно».
Правило второе: никакой похвалы
Это он называет более тонкой проблемой — влиянием, а не подстановкой слов. Отдаёте черновик, модель отвечает, что это золото. А в первом черновике большинство абзацев плохи, логика скачет и есть лишних слов семьсот пятьдесят.
Модель одобряет структуру, потом абзацы и переходы, потом выбор слов, метафоры, отсылки. В результате вы укрепляетесь во всех импульсах первого черновика, хотя обычно поступили бы иначе: переписали бы, передумали, заменили абзацы. Именно эти передумывания — основа для вашего голоса. Читатель не поймёт, что не так, но почувствует искусственный привкус.
Обходной приём у него был такой: пару лет он открывал каждый промпт враньём. Помогает, но модель обычно начинает подгонять свои выводы под «цели». Так что нынешний совет проще: запретить похвалу прямым текстом и оставаться начеку.
Что модели разрешено
Тут всё про усталость. Ошибки можно ловить и вручную, но это утомительная работа, а модель не устаёт. Отсюда список: перебор со страдательным залогом, отглагольные существительные вместо действия, повторяющиеся обороты; «очень», «к сожалению», «на самом деле», рассыпанные по черновику, как опилки по верстаку. И отдельно — два-три абзаца, которые надо просто переставить в другое место, отчего ясность мгновенно улучшается.
Цикл: попросить модель найти проблемы, самому переписать проблемные куски, потом дать оба варианта на сравнение. И здесь важная деталь, которую легко упустить: сравнивать надо давать другой модели, без контекста вашей правки. Иначе она знает, что вы только что переписали, и знает, какой ответ вы хотите услышать.
Себе он сделал под это инструмент — редактор с подсветкой и комментариями на полях, где по тексту прогоняются заготовленные промпты-проходы. Но в заметке есть оговорка, которая мне нравится больше самого инструмента: что бы вы ни собрали сами, оно будет лучше моего, потому что собранное самостоятельно всегда лучше подходит своему автору.
Он скормил эту заметку GPT-5 со словами «я не автор», и модель сказала, что текст на 20% длиннее нужного. Птачек пишет: вероятно, она права. Но править он не будет.
Что я об этом думаю
Конечно, я не могу все тексты писать сам. Не для этого я целую фабрику контента написал. Но для редакторов экспертных материалов на Хабр эти приёмы очень пригодятся. Особенно проверки разными моделями.
Однако, я заложил эту логику в фабрику. Например, чистый контекст — это как раз проверка моделью без истории создания и правок текста.
Оригинал тут: sockpuppet.org/blog/2026/09/17/how-to-write-with-an-llm/
#ai #контентменеджерское
👍4❤1
Второй мозг контент-менеджера. Часть 1. Что стало с базой контента
Больше года назад я начал писать текст про базу контента в Obsidian. Он так и остался в черновиках, оборванный на фразе «прошло несколько месяцев, и я начинаю подводить итоги эксперимента». Итогов не было, потому что эксперимент не закончился. Он свернул туда, куда я не планировал.
С чего всё началось. Я разобрал свой рабочий день и увидел, что весь день пишу: минутки встреч, тексты задач, ответы в чатах, комментарии к чужим текстам. Написанное копится, но почти не переиспользуется. Через полгода найти старую заметку стоит столько же, сколько написать её заново. Я прошёл обычный путь: папки по проектам, потом по годам и месяцам, потом заметки в телефоне. Папки работают, пока ты редактор одного направления. Заметки хранят голый текст, который ни с чем не связан.
Тогда я написал, что в основе продуктивности контент-менеджера лежит база контента, и составил список, что она должна уметь: теги, Markdown с таблицами, шаблоны, папки, автоматизация, графы связей, визуализация. Семь пунктов. Я собирался выбрать под них инструмент — Obsidian — и рассказать, как всё устроил.
Инструмент я выбрал. Это оказался репозиторий на GitHub, и сейчас в нём лежит всё, что я делаю как контент-менеджер.
Пройдусь по старому списку, потому что он закрылся весь, только не так, как я ожидал.
Теги есть: у каждого файла в шапке домен, тип, продукт, география. Markdown с таблицами есть: кроме него, там вообще ничего нет. Шаблоны есть, но не заметок, а целых процессов: пресс-релиз, кейс, SEO-статья, дайджест, у каждого свои шаги и своя папка, куда он сохраняется. Папки есть, и они плоские: один уровень по типу материала, имя файла начинается с даты, никаких «черновиков» и «опубликованного». Автоматизация есть, и её больше, чем я мог себе представить год назад: конспект исследования сохраняется сам, ещё до того, как его кто-то прочитал. Графы есть: система показывает, какие статьи ни на кого не ссылаются и на кого стоило бы сослаться из новой. Визуализация тоже есть, хотя ей я пользуюсь реже всего.
Вот только главный читатель этой базы теперь не я.
Её читают ИИ-агенты. Перед тем как искать что-то в вебе, агент смотрит, есть ли по теме конспект в базе. Перед тем как написать цифру, сверяется с карточкой факта, у которой есть источник и срок годности. Перед тем как назвать продукт, открывает словарь канонических имён. Я год назад думал, что строю базу для себя, чтобы быстрее находить старое. А построил память для системы, которая без этой памяти врёт уверенно и красиво.
И тут список из семи пунктов оказался неполным. В нём не было трёх вещей, которые по-настоящему отличают базу контента от второго мозга. Память должна проверять то, что в неё кладут. Память должна стареть: цифра годовой давности должна сама проситься на перепроверку. И память должна учиться: ошибка, повторившаяся дважды, должна превращаться в правило, а не в ещё одну правку в тексте.
Про это и будет цикл. Не про то, как писать: на это есть Ильяхов и коллеги. Про то, как контент-менеджеру держать поток, когда часть потока теперь пишут не люди. Как и обещал год назад: только мой опыт, только мой идеальныйдушный мир, и каждый пост должен быть полезен сам по себе.
В следующем: четыре задачи моей недели и как выстраивается процесс работы.
P.S.: Сорри за второй мозг. Этим термином очень любят пользоваться инфоцыгане от ИИ, чем уже сильно бесят. Но на самом деле эта концепция очень даже рабочая, особенно если ты работает с огромным количеством информации.
#контентменеджерское #ai_agents #второймозгконтентменеджера
Больше года назад я начал писать текст про базу контента в Obsidian. Он так и остался в черновиках, оборванный на фразе «прошло несколько месяцев, и я начинаю подводить итоги эксперимента». Итогов не было, потому что эксперимент не закончился. Он свернул туда, куда я не планировал.
С чего всё началось. Я разобрал свой рабочий день и увидел, что весь день пишу: минутки встреч, тексты задач, ответы в чатах, комментарии к чужим текстам. Написанное копится, но почти не переиспользуется. Через полгода найти старую заметку стоит столько же, сколько написать её заново. Я прошёл обычный путь: папки по проектам, потом по годам и месяцам, потом заметки в телефоне. Папки работают, пока ты редактор одного направления. Заметки хранят голый текст, который ни с чем не связан.
Тогда я написал, что в основе продуктивности контент-менеджера лежит база контента, и составил список, что она должна уметь: теги, Markdown с таблицами, шаблоны, папки, автоматизация, графы связей, визуализация. Семь пунктов. Я собирался выбрать под них инструмент — Obsidian — и рассказать, как всё устроил.
Инструмент я выбрал. Это оказался репозиторий на GitHub, и сейчас в нём лежит всё, что я делаю как контент-менеджер.
Пройдусь по старому списку, потому что он закрылся весь, только не так, как я ожидал.
Теги есть: у каждого файла в шапке домен, тип, продукт, география. Markdown с таблицами есть: кроме него, там вообще ничего нет. Шаблоны есть, но не заметок, а целых процессов: пресс-релиз, кейс, SEO-статья, дайджест, у каждого свои шаги и своя папка, куда он сохраняется. Папки есть, и они плоские: один уровень по типу материала, имя файла начинается с даты, никаких «черновиков» и «опубликованного». Автоматизация есть, и её больше, чем я мог себе представить год назад: конспект исследования сохраняется сам, ещё до того, как его кто-то прочитал. Графы есть: система показывает, какие статьи ни на кого не ссылаются и на кого стоило бы сослаться из новой. Визуализация тоже есть, хотя ей я пользуюсь реже всего.
Вот только главный читатель этой базы теперь не я.
Её читают ИИ-агенты. Перед тем как искать что-то в вебе, агент смотрит, есть ли по теме конспект в базе. Перед тем как написать цифру, сверяется с карточкой факта, у которой есть источник и срок годности. Перед тем как назвать продукт, открывает словарь канонических имён. Я год назад думал, что строю базу для себя, чтобы быстрее находить старое. А построил память для системы, которая без этой памяти врёт уверенно и красиво.
И тут список из семи пунктов оказался неполным. В нём не было трёх вещей, которые по-настоящему отличают базу контента от второго мозга. Память должна проверять то, что в неё кладут. Память должна стареть: цифра годовой давности должна сама проситься на перепроверку. И память должна учиться: ошибка, повторившаяся дважды, должна превращаться в правило, а не в ещё одну правку в тексте.
Про это и будет цикл. Не про то, как писать: на это есть Ильяхов и коллеги. Про то, как контент-менеджеру держать поток, когда часть потока теперь пишут не люди. Как и обещал год назад: только мой опыт, только мой идеальный
В следующем: четыре задачи моей недели и как выстраивается процесс работы.
P.S.: Сорри за второй мозг. Этим термином очень любят пользоваться инфоцыгане от ИИ, чем уже сильно бесят. Но на самом деле эта концепция очень даже рабочая, особенно если ты работает с огромным количеством информации.
#контентменеджерское #ai_agents #второймозгконтентменеджера
🔥4
Второй мозг контент-менеджера. Часть 2. Четыре задачи из моей недели
Не откладываем в долгий ящик — продолжаем цикл. Год назад я описал свой день списком задач. По сути он не изменился, но у каждого дела появилась одна общая точка старта. Это сессия Claude Code, открытая внутри моего репозитория. Не потому, что я полюбил терминал. Это единственное место, где одновременно лежат память, правила и агенты: чат без репозитория забывает всё после закрытия вкладки, а репозиторий помнит, что я туда положил за полгода.
Покажу на четырёх реальных задачах, как я работаю с нейросетями. Можно сказать, что тут полностью реализован подход ai-first.
Пресс-релиз про технологический анонс. На входе: тема, бриф и имя спикера для цитаты. Я пишу в сессии «напиши пресс-релиз про ...». Начинается мастер: шаг за шагом, по одному вопросу. Тип релиза, продукт, потом выбор из трёх заголовков, трёх лидов, набора блоков. Я выбираю, как выбирал бы из вариантов коллеги. Дальше конвейер уходит в фон: ресёрчер собрал семь источников и сохранил конспект отдельным коммитом ещё до того, как его увидел автор. Фактчекер проверил четырнадцать утверждений: семь подтвердил, четыре уточнил, три не нашёл в публичных источниках, выдуманных не нашёл ни одного. Например, одна цифра вела на SEO-агрегатор, первоисточника не было — и в текст она не вошла. На выходе три версии релиза: общая, техническая и упрощённая техническая, и рядом отчёт, где написано, что проверено, а что осталось на согласование. Моя работа — согласовать то, что осталось.
Интервью для СМИ. На входе документ, в котором уже есть комментарии от разных сторон: заход от лица вендора, рыночный блок на подтверждение спикеру, никаких оценок про чужие платформы, у заказчика стилевой контракт без длинных тире и конструкций «не X, а Y». Раньше это был вечер правок руками и три переписки. Теперь я даю ссылку на документ, он импортируется в библиотеку как Markdown, а дальше говорю: «переработай по комментариям, образец канвы — вот это интервью из базы». Система берёт старое интервью как референс структуры, проходит комментарии, прогоняет финальную траст-редактуру. Идём согласовывать.
SEO-статья для блога. На входе документ с ТЗ: тема, ключи, структура. Я говорю: «напиши статью по этому ТЗ, работай автономно». Система сначала проверяет базу: у меня уже есть конспекты по теме, их она дополняет, а не собирает заново. Потом ресёрч, автор, фактчекер. И вот тут самое интересное: фактчекер снял из текста цифру, которая пришла из нашей же продуктовой фактуры, но публичного первоисточника у неё нет, а та публичная, что нашлась, относится к другому направлению. Заодно он заметил, что условия скидки в фактуре и на сайте расходятся. В статью ни то ни другое не вошло, но в отчёте появилась строка для продуктовой команды: сверить фактуру с сайтом. Траст-редактор внёс 26 правок и статья сохранена со статусом «на ревью». Идём согласовывать.
Обновление лендинга по SEO-ТЗ. На входе документ с тремя вкладками (анализ, структура, SEO) и текущая страница. Я говорю: «обнови лендинг баз данных по этому ТЗ». Режим обновления отличается от создания: структура страницы жёстко сохраняется, число блоков и предложений плюс-минус одно, на выходе таблица «было — стало» по каждому блоку. Редактор оценил черновик на 8 из 10, повторный круг не потребовался. Цифры в новых блоках траст-редактор пометил на перепроверку, фактчекер прошёл по ним точечно. В CMS я несу таблицу, а не текст: так тот, кто вносит правки на сайте, видит, что именно изменилось.
Что общего у этих четырёх задач. Я ни разу не писал текст с нуля и ни разу не искал факты сам. Моя работа сдвинулась в две точки: решения на входе (какой заголовок, какой угол, что считать источником) и приёмка на выходе (что взять на согласование и что из открытых вопросов нести людям на проверку). Всё между ними делает система, и всё между ними остаётся в репозитории: конспект, черновик, отчёт с трассой проверок. Поэтому следующая такая задача начнётся не с чистого листа, а с того, что уже найдено.
В следующем посте: про то, как у меня всё хранится и три вида памяти.
#контентменеджерское #ai_agents #второймозгконтентменеджера
Не откладываем в долгий ящик — продолжаем цикл. Год назад я описал свой день списком задач. По сути он не изменился, но у каждого дела появилась одна общая точка старта. Это сессия Claude Code, открытая внутри моего репозитория. Не потому, что я полюбил терминал. Это единственное место, где одновременно лежат память, правила и агенты: чат без репозитория забывает всё после закрытия вкладки, а репозиторий помнит, что я туда положил за полгода.
Покажу на четырёх реальных задачах, как я работаю с нейросетями. Можно сказать, что тут полностью реализован подход ai-first.
Пресс-релиз про технологический анонс. На входе: тема, бриф и имя спикера для цитаты. Я пишу в сессии «напиши пресс-релиз про ...». Начинается мастер: шаг за шагом, по одному вопросу. Тип релиза, продукт, потом выбор из трёх заголовков, трёх лидов, набора блоков. Я выбираю, как выбирал бы из вариантов коллеги. Дальше конвейер уходит в фон: ресёрчер собрал семь источников и сохранил конспект отдельным коммитом ещё до того, как его увидел автор. Фактчекер проверил четырнадцать утверждений: семь подтвердил, четыре уточнил, три не нашёл в публичных источниках, выдуманных не нашёл ни одного. Например, одна цифра вела на SEO-агрегатор, первоисточника не было — и в текст она не вошла. На выходе три версии релиза: общая, техническая и упрощённая техническая, и рядом отчёт, где написано, что проверено, а что осталось на согласование. Моя работа — согласовать то, что осталось.
Интервью для СМИ. На входе документ, в котором уже есть комментарии от разных сторон: заход от лица вендора, рыночный блок на подтверждение спикеру, никаких оценок про чужие платформы, у заказчика стилевой контракт без длинных тире и конструкций «не X, а Y». Раньше это был вечер правок руками и три переписки. Теперь я даю ссылку на документ, он импортируется в библиотеку как Markdown, а дальше говорю: «переработай по комментариям, образец канвы — вот это интервью из базы». Система берёт старое интервью как референс структуры, проходит комментарии, прогоняет финальную траст-редактуру. Идём согласовывать.
SEO-статья для блога. На входе документ с ТЗ: тема, ключи, структура. Я говорю: «напиши статью по этому ТЗ, работай автономно». Система сначала проверяет базу: у меня уже есть конспекты по теме, их она дополняет, а не собирает заново. Потом ресёрч, автор, фактчекер. И вот тут самое интересное: фактчекер снял из текста цифру, которая пришла из нашей же продуктовой фактуры, но публичного первоисточника у неё нет, а та публичная, что нашлась, относится к другому направлению. Заодно он заметил, что условия скидки в фактуре и на сайте расходятся. В статью ни то ни другое не вошло, но в отчёте появилась строка для продуктовой команды: сверить фактуру с сайтом. Траст-редактор внёс 26 правок и статья сохранена со статусом «на ревью». Идём согласовывать.
Обновление лендинга по SEO-ТЗ. На входе документ с тремя вкладками (анализ, структура, SEO) и текущая страница. Я говорю: «обнови лендинг баз данных по этому ТЗ». Режим обновления отличается от создания: структура страницы жёстко сохраняется, число блоков и предложений плюс-минус одно, на выходе таблица «было — стало» по каждому блоку. Редактор оценил черновик на 8 из 10, повторный круг не потребовался. Цифры в новых блоках траст-редактор пометил на перепроверку, фактчекер прошёл по ним точечно. В CMS я несу таблицу, а не текст: так тот, кто вносит правки на сайте, видит, что именно изменилось.
Что общего у этих четырёх задач. Я ни разу не писал текст с нуля и ни разу не искал факты сам. Моя работа сдвинулась в две точки: решения на входе (какой заголовок, какой угол, что считать источником) и приёмка на выходе (что взять на согласование и что из открытых вопросов нести людям на проверку). Всё между ними делает система, и всё между ними остаётся в репозитории: конспект, черновик, отчёт с трассой проверок. Поэтому следующая такая задача начнётся не с чистого листа, а с того, что уже найдено.
В следующем посте: про то, как у меня всё хранится и три вида памяти.
#контентменеджерское #ai_agents #второймозгконтентменеджера
🔥1
Второй мозг контент-менеджера. Часть 3. Три памяти и одно правило
Продолжаем сериал. Год назад я хотел от базы контента теги, папки и графы. Сейчас база устроена иначе, потому что её главный читатель сменился: агенты читают её чаще, чем я. Этот пост о том, как она разделена и почему.
Типовая ошибка, через которую я прошёл сам: одно хранилище на всё. Минутки, черновики, выписки из отчётов, скриншоты конкурентов лежат вместе, и поиск по ним работает ровно до тех пор, пока человек помнит, что ищет. У агента такой памяти нет. Ему нужно, чтобы у каждой записи были заданы три вещи: срок жизни, источник доверия и событие, после которого запись надо перепроверить. По этим трём признакам записи и расходятся в три разных хранилища. Я называю их памятями, потому что они различаются так же, как долговременная и рабочая память у человека.
Долговременная память. Проверенные синтезы по доменам и атомарные карточки: один факт, одна цифра, одно возражение клиента, один блок, пригодный для цитирования ИИ-поиском. Сейчас это двадцать разделов и 351 карточка фактов. У карточки фиксированная шапка: утверждение, домен, дата проверки, срок годности, уровень доверия, источник с издателем и ссылкой, список процессов, где карточку разрешено применять. Доверие трёх уровней: 218 карточек с высоким, 115 со средним, 18 с низким. Низкое доверие у карточки означает ограниченный допуск. Пример из базы: вендорский опрос про защиту 5G-сетей, процитированный через обзор на arXiv, доверие низкое, применять разрешено только в брифинге спикера. Автор пресс-релиза эту карточку не получит, даже если тема совпадёт. Теги, которых я хотел год назад, в итоге работают именно так: это фильтр допуска для агента, а поиск для человека у них вторичен.
Рабочая память. Конспект, который ресёрчер собирает под один материал: источники, цифры, цитаты по узкой теме. Таких конспектов сейчас около ста семидесяти, из них, например, сорок под статьи и одиннадцать под пресс-релизы. У конспекта есть срок годности, статус и ссылка на материал, в который он вошёл, поэтому по любой статье можно восстановить, откуда взялась каждая цифра. Ключевое правило рабочей памяти касается момента до поиска. Ресёрчер обязан сначала проверить, что по теме уже собрано, и зафиксировать один из трёх исходов: использовать как есть, дополнить, пересобрать. Это экономит деньги на поиске и защищает от расхождений между статьями одной серии.
Память о других. Профили чужих продуктов: что заявляют, какие цифры публикуют, как называют компоненты. Выделена отдельно по двум причинам. Доверие к чужим заявлениям другое, и триггер обновления другой: профиль конкурента устаревает не по календарю, а после релиза, ребрендинга или смены цен.
Правило распределения умещается в одну строку. Широкое и проверенное идёт в долговременную память. Узкое, собранное под задачу, в рабочую. Всё про чужой продукт в память о других. Запись, которая не проходит ни по одному критерию, в репозиторий не попадает. Минутки встреч там не живут.
Между рабочей и долговременной памятью нужен переход, который год назад я не спроектировал. Если ресёрчер под одну статью нашёл цифру, полезную ещё десяти материалам, она должна превратиться в карточку с источником, сроком годности и допуском. Иначе она останется в конспекте, который через три месяца истечёт. Сейчас этот переход полуручной: система предлагает кандидатов, я подтверждаю каждого. Это самое слабое место схемы, потому что я регулярно откладываю подтверждение.
Два ограничения, о которых нужно знать, прежде чем повторять схему. Просроченных карточек в долговременной памяти сегодня ноль, и это пока ничего не доказывает: базе меньше года, первые сроки годности истекут в 2027, и только тогда станет видно, работает ли механизм перепроверки. И память о других останется пустой, пока у неё нет отдельного процесса наполнения, одними ресёрчами под статьи она не заполняется.
В следующем посте: как агент получает из трёх памятей короткую подборку под задачу вместо дампа всей базы, и почему этот отбор важнее самого хранилища.
#контентменеджерское #ai_agents #второймозгконтентменеджера
Продолжаем сериал. Год назад я хотел от базы контента теги, папки и графы. Сейчас база устроена иначе, потому что её главный читатель сменился: агенты читают её чаще, чем я. Этот пост о том, как она разделена и почему.
Типовая ошибка, через которую я прошёл сам: одно хранилище на всё. Минутки, черновики, выписки из отчётов, скриншоты конкурентов лежат вместе, и поиск по ним работает ровно до тех пор, пока человек помнит, что ищет. У агента такой памяти нет. Ему нужно, чтобы у каждой записи были заданы три вещи: срок жизни, источник доверия и событие, после которого запись надо перепроверить. По этим трём признакам записи и расходятся в три разных хранилища. Я называю их памятями, потому что они различаются так же, как долговременная и рабочая память у человека.
Долговременная память. Проверенные синтезы по доменам и атомарные карточки: один факт, одна цифра, одно возражение клиента, один блок, пригодный для цитирования ИИ-поиском. Сейчас это двадцать разделов и 351 карточка фактов. У карточки фиксированная шапка: утверждение, домен, дата проверки, срок годности, уровень доверия, источник с издателем и ссылкой, список процессов, где карточку разрешено применять. Доверие трёх уровней: 218 карточек с высоким, 115 со средним, 18 с низким. Низкое доверие у карточки означает ограниченный допуск. Пример из базы: вендорский опрос про защиту 5G-сетей, процитированный через обзор на arXiv, доверие низкое, применять разрешено только в брифинге спикера. Автор пресс-релиза эту карточку не получит, даже если тема совпадёт. Теги, которых я хотел год назад, в итоге работают именно так: это фильтр допуска для агента, а поиск для человека у них вторичен.
Рабочая память. Конспект, который ресёрчер собирает под один материал: источники, цифры, цитаты по узкой теме. Таких конспектов сейчас около ста семидесяти, из них, например, сорок под статьи и одиннадцать под пресс-релизы. У конспекта есть срок годности, статус и ссылка на материал, в который он вошёл, поэтому по любой статье можно восстановить, откуда взялась каждая цифра. Ключевое правило рабочей памяти касается момента до поиска. Ресёрчер обязан сначала проверить, что по теме уже собрано, и зафиксировать один из трёх исходов: использовать как есть, дополнить, пересобрать. Это экономит деньги на поиске и защищает от расхождений между статьями одной серии.
Память о других. Профили чужих продуктов: что заявляют, какие цифры публикуют, как называют компоненты. Выделена отдельно по двум причинам. Доверие к чужим заявлениям другое, и триггер обновления другой: профиль конкурента устаревает не по календарю, а после релиза, ребрендинга или смены цен.
Правило распределения умещается в одну строку. Широкое и проверенное идёт в долговременную память. Узкое, собранное под задачу, в рабочую. Всё про чужой продукт в память о других. Запись, которая не проходит ни по одному критерию, в репозиторий не попадает. Минутки встреч там не живут.
Между рабочей и долговременной памятью нужен переход, который год назад я не спроектировал. Если ресёрчер под одну статью нашёл цифру, полезную ещё десяти материалам, она должна превратиться в карточку с источником, сроком годности и допуском. Иначе она останется в конспекте, который через три месяца истечёт. Сейчас этот переход полуручной: система предлагает кандидатов, я подтверждаю каждого. Это самое слабое место схемы, потому что я регулярно откладываю подтверждение.
Два ограничения, о которых нужно знать, прежде чем повторять схему. Просроченных карточек в долговременной памяти сегодня ноль, и это пока ничего не доказывает: базе меньше года, первые сроки годности истекут в 2027, и только тогда станет видно, работает ли механизм перепроверки. И память о других останется пустой, пока у неё нет отдельного процесса наполнения, одними ресёрчами под статьи она не заполняется.
В следующем посте: как агент получает из трёх памятей короткую подборку под задачу вместо дампа всей базы, и почему этот отбор важнее самого хранилища.
#контентменеджерское #ai_agents #второймозгконтентменеджера
👍1🤯1
Второй мозг контент-менеджера. Часть 5. Память стареет
Последняя душная часть про память. А далее перейдём к более интересным механикам и лайфхакам.
Приведу следующий пример: цифра трёхлетней давности существует, находится в карточке базы и выглядит обоснованной. Фактчечек считает его корректной и не проверяет. И цифра попадает в текст, проходя все проверки.
Поэтому у меня появилось старение памяти. Ниже четыре механизма, которые это делают, в порядке срабатывания.
1. Срок задаётся при записи и зависит от типа данных. У каждой записи в базе три поля: дата проверки, срок годности, уровень доверия. Срок не единый. Правило свежести фиксирует допустимую давность по типу цифры.
2. Истёкший срок меняет маршрут записи, а не удаляет её. Три реакции на трёх этапах.
➡️ До ресёрча. Библиотекарь при сборке коробки для агента выносит просроченные записи в отдельный список. Они видны, их нельзя подать как факт, а отсутствие свежих записей по теме превращается в пункт «пробелы: цифры проверять фактчекеру».
➡️ После автора. Фактчекер делает повторную проверку по типу данных: запрос по теме с текущим годом, поиск первоисточника, замена цифры с новой датой или снятие. Формулировка «по данным такого-то года» допустима только когда новее данных не существует, и это должно быть видно в конспекте.
➡️ После публикации. Детектор корпуса проходит по опубликованным материалам и считает три признака: возраст старше 365 дней, устаревшие годы в фактах, незакрытые метки «нужен фактчек». Первые два дают кандидата на обновление, третий поднимает приоритет.
3. Волны истечения ловятся заранее. Пакетный импорт получает одну дату на всю полку, и через год вся полка истекает одним днём. Окно предупреждения в 30 дней такую волну не показывает: вчера ноль просроченных, завтра полсотни. Поэтому индекс свежести считает волны отдельно: двадцать и больше файлов с одной датой в ближайшие 60 дней дают строку в плане ревизии, и ревизию полки планируют за месяц, а не по факту.
4. Свежесть считается по всем трём памятям. Срок у досье обязателен, слой входит в индекс, в гейт и в расчёт волн, а ревизия досье проходит по правилу «было → стало»: старая цифра остаётся в тексте рядом с новой, с датой и источником.
И про проблему, которую я сейчас исправляю. План ревизии собирается скриптом в один список: просроченное, истекающее за 30 дней, волны. Он должен был приходить задачей в репозиторий раз в неделю. Но расписание было отключено: задачи приходили, я их не отрабатывал, невыполненные копились. Ревизии идут кампаниями раз в несколько недель вместо еженедельной рутины.
Поэтому срок годности работает ровно настолько, насколько есть процесс реакции на его истечение. И этот процесс нужно настроить.
В следующем посте про чистый контекст. Я уже много рассказывал, почему фактчекер не должен видеть, как думал автор и тд.. В новых материала постараюсь углубиться в тему. Например, рассказать, что может случиться, когда система заглядывает через плечо субагентами и подсказывает им. И как с этим бороться.
#контентменеджерское #ai_agents #второймозгконтентменеджера
Последняя душная часть про память. А далее перейдём к более интересным механикам и лайфхакам.
Приведу следующий пример: цифра трёхлетней давности существует, находится в карточке базы и выглядит обоснованной. Фактчечек считает его корректной и не проверяет. И цифра попадает в текст, проходя все проверки.
Поэтому у меня появилось старение памяти. Ниже четыре механизма, которые это делают, в порядке срабатывания.
1. Срок задаётся при записи и зависит от типа данных. У каждой записи в базе три поля: дата проверки, срок годности, уровень доверия. Срок не единый. Правило свежести фиксирует допустимую давность по типу цифры.
2. Истёкший срок меняет маршрут записи, а не удаляет её. Три реакции на трёх этапах.
3. Волны истечения ловятся заранее. Пакетный импорт получает одну дату на всю полку, и через год вся полка истекает одним днём. Окно предупреждения в 30 дней такую волну не показывает: вчера ноль просроченных, завтра полсотни. Поэтому индекс свежести считает волны отдельно: двадцать и больше файлов с одной датой в ближайшие 60 дней дают строку в плане ревизии, и ревизию полки планируют за месяц, а не по факту.
4. Свежесть считается по всем трём памятям. Срок у досье обязателен, слой входит в индекс, в гейт и в расчёт волн, а ревизия досье проходит по правилу «было → стало»: старая цифра остаётся в тексте рядом с новой, с датой и источником.
И про проблему, которую я сейчас исправляю. План ревизии собирается скриптом в один список: просроченное, истекающее за 30 дней, волны. Он должен был приходить задачей в репозиторий раз в неделю. Но расписание было отключено: задачи приходили, я их не отрабатывал, невыполненные копились. Ревизии идут кампаниями раз в несколько недель вместо еженедельной рутины.
Поэтому срок годности работает ровно настолько, насколько есть процесс реакции на его истечение. И этот процесс нужно настроить.
В следующем посте про чистый контекст. Я уже много рассказывал, почему фактчекер не должен видеть, как думал автор и тд.. В новых материала постараюсь углубиться в тему. Например, рассказать, что может случиться, когда система заглядывает через плечо субагентами и подсказывает им. И как с этим бороться.
#контентменеджерское #ai_agents #второймозгконтентменеджера
Please open Telegram to view this post
VIEW IN TELEGRAM
🤯2
Пять способов не захламлять контекст. Разбор гайда LangChain
Подготавливая свои материалы, нашёл концептуальный гайд от LangChain про то, как агенты помнят, не держа всё в голове. Статья полезная, хотя и написана наполовину как витрина их собственного харнесса. Перескажу суть и скажу, что из этого реально работает у меня.
Проблема простая. Чем дольше работает агент, тем больше он в себе тащит: инструкции, выдачу инструментов, куски файлов, свои прошлые ответы. В какой-то момент он начинает тупеть — не ломаться, а именно тупеть, терять нить и путать детали. Метафора в статье хорошая: как подготовка к экзамену в ночь перед ним, чем больше учишь, тем сильнее вылетают первые главы.
Что предлагается: не пускать лишнее внутрь и разбираться с тем, что уже внутри.
Не пускать
Выгружать большое в файлы. Агент дёрнул инструмент, тот вернул простыню на тысячи строк. В контекст кладётся не простыня, а её начало, конец и путь к файлу. Понадобится деталь — дочитает. Ключевое отличие от обрезки: обрезка теряет данные навсегда, выгрузка оставляет их доступными. Разница кажется мелкой, пока агент не упирается в то, что нужная строка была в середине отрезанного.
Грузить инструкции по требованию. Вместо того чтобы держать все инструкции в системном промпте, агент видит только список названий с однострочным описанием, а полную инструкцию подтягивает, когда решил, что она нужна. У них точная формулировка: десять скиллов стоят примерно столько же контекста, сколько десять однострочников.
Это, кстати, второй раз за месяц, когда я вижу ровно эту архитектуру. В скилле для диаграмм, про который я писал, — то же самое: тонкий индекс плюс референсы по запросу. Похоже, паттерн устоялся.
Выносить шумную работу в субагента. Если вы заранее знаете, что задача грязная — обойти двадцать страниц, перелопатить выгрузку, — её отдают отдельному агенту с собственным контекстом. Назад приходит только результат. В их примере субагент читает полный отчёт у себя и возвращает три пункта; главный агент сырых данных вообще не видит. Бонус: такие задачи мелкие, их можно гнать параллельно и на модели подешевле.
Разбираться с тем, что уже внутри
Сжимать историю. Когда окно заполнено процентов на восемьдесят пять, старые сообщения схлопываются в сводку, свежие остаются как есть. Два важных условия: оригиналы при этом пишутся в файл, чтобы можно было вернуться, и процесс цикличный — следующая сводка включает предыдущую.
Полезная диагностика оттуда же. Выгрузка файлов срезает резкие скачки, сжатие истории гасит медленный подъём. Это разные болезни. Если у вас контекст распухает рывками — лечится первым. Если ползёт вверх ровно — вторым. Я до этого валил в одну кучу и чинил не тем.
Память между запусками. Отдельный markdown-файл, который читается в начале прогона и обновляется, когда агент узнал что-то, что стоит сохранить. Пример у них ровно редакторский: сказали «в саммари буллеты, а не абзацы» — без памяти будете повторять это каждую неделю.
Что в статье главное
Для меня — не пять техник, а тезис про владение памятью. Память агента у них лежит обычным файлом в вашем хранилище, а не внутри сервиса провайдера. Поэтому модель можно сменить, а всё накопленное останется.
Для контентных команд это не техническая деталь, а вопрос собственности. Ваш редстандарт, ваши правила, ваши накопленные исключения — где они физически лежат? Если markdown-файлом в репозитории, вы переживёте смену любого инструмента. Если внутри чужого продукта — нет.
И что меня смущает
В статье ноль цифр. Деградация объявлена, механизм описан, но насколько именно падает качество и насколько помогают эти пять приёмов — ни слова. Для компании, которая продаёт платформу для наблюдаемости и оценки агентов, отсутствие замеров странное.
Пороги — восемьдесят пять процентов, двадцать тысяч токенов — поданы как данность, откуда взялись, не объясняется. Там же сказано, что их надо настраивать под задачу, а как понять, что текущие не годятся, — нет.
И главное умолчание. Все пять приёмов — это обмен информации на место. Сводка решает, что считать важным. Превью решает, какие строки показать. Субагент решает, какие три пункта вернуть. Каждое из этих решений принимает модель, и каждое может выбросить не то. Сказано, что всё восстановимо, но восстановить можно, только если агент догадается, что ему чего-то не хватает. А он не догадается: он не знает, что выбросил.
Это ровно тот класс ошибок, который не ловится на демо и вылезает на третьем месяце работы. Держите в голове, когда будете это всё внедрять.
Почитать можно тут: langchain.com/blog/context-engineering-deep-agents-remember
#ai_agents
Подготавливая свои материалы, нашёл концептуальный гайд от LangChain про то, как агенты помнят, не держа всё в голове. Статья полезная, хотя и написана наполовину как витрина их собственного харнесса. Перескажу суть и скажу, что из этого реально работает у меня.
Проблема простая. Чем дольше работает агент, тем больше он в себе тащит: инструкции, выдачу инструментов, куски файлов, свои прошлые ответы. В какой-то момент он начинает тупеть — не ломаться, а именно тупеть, терять нить и путать детали. Метафора в статье хорошая: как подготовка к экзамену в ночь перед ним, чем больше учишь, тем сильнее вылетают первые главы.
Что предлагается: не пускать лишнее внутрь и разбираться с тем, что уже внутри.
Не пускать
Выгружать большое в файлы. Агент дёрнул инструмент, тот вернул простыню на тысячи строк. В контекст кладётся не простыня, а её начало, конец и путь к файлу. Понадобится деталь — дочитает. Ключевое отличие от обрезки: обрезка теряет данные навсегда, выгрузка оставляет их доступными. Разница кажется мелкой, пока агент не упирается в то, что нужная строка была в середине отрезанного.
Грузить инструкции по требованию. Вместо того чтобы держать все инструкции в системном промпте, агент видит только список названий с однострочным описанием, а полную инструкцию подтягивает, когда решил, что она нужна. У них точная формулировка: десять скиллов стоят примерно столько же контекста, сколько десять однострочников.
Это, кстати, второй раз за месяц, когда я вижу ровно эту архитектуру. В скилле для диаграмм, про который я писал, — то же самое: тонкий индекс плюс референсы по запросу. Похоже, паттерн устоялся.
Выносить шумную работу в субагента. Если вы заранее знаете, что задача грязная — обойти двадцать страниц, перелопатить выгрузку, — её отдают отдельному агенту с собственным контекстом. Назад приходит только результат. В их примере субагент читает полный отчёт у себя и возвращает три пункта; главный агент сырых данных вообще не видит. Бонус: такие задачи мелкие, их можно гнать параллельно и на модели подешевле.
Разбираться с тем, что уже внутри
Сжимать историю. Когда окно заполнено процентов на восемьдесят пять, старые сообщения схлопываются в сводку, свежие остаются как есть. Два важных условия: оригиналы при этом пишутся в файл, чтобы можно было вернуться, и процесс цикличный — следующая сводка включает предыдущую.
Полезная диагностика оттуда же. Выгрузка файлов срезает резкие скачки, сжатие истории гасит медленный подъём. Это разные болезни. Если у вас контекст распухает рывками — лечится первым. Если ползёт вверх ровно — вторым. Я до этого валил в одну кучу и чинил не тем.
Память между запусками. Отдельный markdown-файл, который читается в начале прогона и обновляется, когда агент узнал что-то, что стоит сохранить. Пример у них ровно редакторский: сказали «в саммари буллеты, а не абзацы» — без памяти будете повторять это каждую неделю.
Что в статье главное
Для меня — не пять техник, а тезис про владение памятью. Память агента у них лежит обычным файлом в вашем хранилище, а не внутри сервиса провайдера. Поэтому модель можно сменить, а всё накопленное останется.
Для контентных команд это не техническая деталь, а вопрос собственности. Ваш редстандарт, ваши правила, ваши накопленные исключения — где они физически лежат? Если markdown-файлом в репозитории, вы переживёте смену любого инструмента. Если внутри чужого продукта — нет.
И что меня смущает
В статье ноль цифр. Деградация объявлена, механизм описан, но насколько именно падает качество и насколько помогают эти пять приёмов — ни слова. Для компании, которая продаёт платформу для наблюдаемости и оценки агентов, отсутствие замеров странное.
Пороги — восемьдесят пять процентов, двадцать тысяч токенов — поданы как данность, откуда взялись, не объясняется. Там же сказано, что их надо настраивать под задачу, а как понять, что текущие не годятся, — нет.
И главное умолчание. Все пять приёмов — это обмен информации на место. Сводка решает, что считать важным. Превью решает, какие строки показать. Субагент решает, какие три пункта вернуть. Каждое из этих решений принимает модель, и каждое может выбросить не то. Сказано, что всё восстановимо, но восстановить можно, только если агент догадается, что ему чего-то не хватает. А он не догадается: он не знает, что выбросил.
Это ровно тот класс ошибок, который не ловится на демо и вылезает на третьем месяце работы. Держите в голове, когда будете это всё внедрять.
Почитать можно тут: langchain.com/blog/context-engineering-deep-agents-remember
#ai_agents
🔥2
Anti-Malware собрали карту российского рынка ИИ-агентов: семь корпоративных платформ, фреймворки, нормативная база, риски. Полезно хотя бы для того, чтобы увидеть масштаб.
#ai_agents
#ai_agents
👍1