Инженер Контекста

Выложил в опенсорс скилл 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

0.5
— на 3-м → 0.33
— на 5-м → 0.2
Потом усредняю по всем запросам. У меня вышло 0.847 — в среднем нужное стоит между первым и вторым местом. То есть поиск не просто «где-то находит», а выносит правильное почти в самый верх. Это уже хорошо.

Метрика 3: precision@5 — «а сколько мусора рядом?»
И вот честная, неприятная цифра. Precision спрашивает: из пяти выданных карточек сколько реально по делу? У меня ~0.21. Грубо: из пяти результатов по-настоящему нужный обычно один, а четыре это «рядом лежало, зацепилось по теме». Выдача грязновата. Казалось бы плохо, но тут важно, для кого этот поиск. Если бы результат читал человек и ему пришлось глазами продираться через мусор — да, беда. А у меня получатель агент (LLM). Он получает стопку из пяти карточек и сам отбрасывает нерелевантное: контекста ему хватает. Поэтому я сознательно терплю низкую precision ради высокого hit@5, лучше отдать лишнее, чем упустить нужное. Но и это принципиально — цифру я вижу. Не прячу, не округляю в уме до «нормально». Если однажды агент начнёт захлёбываться в мусоре, я замечу это по метрике заранее, а не по кривым статьям постфактум.

Главный вывод: RAG на русском ломается не на эмбеддингах, а на морфологии запроса. Пока агент пишет «базами данных», а ты ищешь по databases — никакая база не поможет. Сначала научи систему понимать, что это одно и то же. А потом обязательно померь, иначе будешь улучшать вслепую.

Вернёмся к практике разработки фабрики контента. Как агент находит нужный факт в базе на 200+ карточек

Я вроде рассказал, как собрал агентам базу знаний-граф? Если не рассказывал, то там я пришёл к той же идее, что Карпатый описывал как LLM Wiki, — связный самоподдерживающийся граф концептов, где всё ссылается друг на друга в обе стороны. Могу отдельно рассказать про карточки и базу отдельно, если интересно.

Но база бесполезна, если агент не может достать из неё нужное. И вот тут началось самое весёлое. Наивный план был такой: агент формулирует запрос → ищем по тегам → отдаём карточки. Запустил. Агент спрашивает про «работу с базами данных» — находит ноль. Хотя в базе лежит жирный синтез с тегом databases.

Проблема — русский язык. Морфология, будь она неладна

Агент пишет запрос живым языком: «базами данных», «облака в России», «искусственного интеллекта». А теги в базе канонические: databases, cloud, ai. Точного совпадения нет. Падежи, порядок слов, синонимы — всё это ломает простой поиск.

Пришлось строить query expansion — разворачивать запрос перед поиском:

➡️ Синонимы и алиасы. «ИИ» и «субд» — это ai и databases. Ведётся словарь синонимических групп поверх таксономии: каждый канонический тег знает все свои народные варианты.
➡️ Лёгкий RU-стеммер. Отрезаю частое окончание, чтобы «облако», «облака», «облаком» сводились к одному стему. Намеренно тупой стеммер на ~10 правил, но его достаточно и он не тянет зависимостей.
➡️ Фразовый индекс по стемам. Многословный алиас «базы-данных» распознаётся во фразе «работа с базами данных» — по множеству стемов частей, несмотря на падеж и порядок слов. Внутри это frozenset стемов: пересеклись — попадание.

Синоним матчится не только против тегов файла, но и против его домена — это ловит карточки, где тема зашита в домен, а теги пустые.

fact-cards — отдельным потоком

Обычные синтезы ранжируются в общий шортлист. А вот проверяемые факты поднимаются отдельно с уровнем доверия (confidence) и допуском к публикации (allowed_use). Просроченные по expires из выдачи вырезаются молча, чтобы автор физически не смог процитировать протухшую цифру. Ретривер тут работает как фильтр доверия, а не просто поиск.

Playbook на каждый сценарий

Не «агент, посмотри базу». А конкретная карта: для этого типа материала подавай сначала fact-cards и позиционирование, конкурентов по релевантности, а вот эти слои вообще запрещены без явной проверки. Один сценарий — один playbook.

И самое важное — я это померил

Тут очень легко себя обмануть. Погонял поиск руками, пару раз он выдал что нужно и ты такой: «работает». А на деле ты проверил три запроса из тысячи возможных, и на четвёртом всё разваливается. «Вроде находит» — это не факт, это ощущение.

Чтобы перестать врать себе, я сделал скучную, но честную вещь: завёл метрики для поиска. Это просто список запросов, где я заранее, руками, отметил правильный ответ. Типа:

Запрос: «тренды систем управления базами данных»
Правильный ответ: вот эта карточка и вот эта

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

Метрика 1: hit@5 — «нашёл ли вообще?»
Самый простой вопрос: в первых пяти результатах есть нужная карточка — да или нет? Считаю по всем запросам долю, где ответ «да». Сейчас это 1.0 — то есть по каждому из 15 запросов нужное лежит где-то в топ-5. Пока что промахов нет вообще. Почему именно топ-5, а не топ-1? Потому что агенту я и так отдаю несколько карточек — ему есть из чего выбрать. Мне важно, чтобы нужное попало в стопку, которую он получит.

Метрика 2: MRR — «а насколько высоко?»
Попасть в топ-5 мало. Одно дело — нужная карточка на 1-м месте, другое — на 5-м, за четырьмя лишними. MRR смотрит, на какой строчке стоит нужный ответ, и переводит это в оценку:
— ответ на 1-м месте → 1.0 (идеал)
— на 2-м →

Ваши скиллы возможно написаны под модель, которой уже нет

Anthropic удалила больше 80% системного промпта из Claude Code, и качество на их тестах не упало. Пересказывать статью не буду, интереснее, что из этого следует, если вы сами пишете агентов и скиллы.

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

2. Резать вслепую нельзя, а мерить нечем. У Anthropic были свои прогоны: удалили кусок промпта, прогнали набор задач, сравнили результат. Поэтому они и могли уверенно сказать «сняли 80%, качество то же». У нас так не выходит. Меняем скилл, смотрим на два поста и решаем, что стало лучше. А на третьем оказывается, что модель перестала расставлять ссылки, просто в первых двух ссылок и не было.

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

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

5. Архитектура скиллов важнее их содержания. Один SKILL.md на девятьсот строк грузится целиком: пишете пост в телеграм — модель попутно читает правила для лендингов. Лишнее разбавляет нужное, а трогать такой файл страшно, поэтому его проще дополнить, чем разобрать. Разложите по уровням: верхний решает, что за задача и куда идти дальше; профиль канала держит тон и рубрикатор только для себя; редкие рубрики подгружаются по надобности. Тогда правки перестают быть страшными: меняете один канал и точно знаете, что остальные не задели.

Что переносится на другие модели

Не переносится цифра. 80% — результат конкретной связки: их обвязка, их модели, их тесты на коде. Для GPT, Gemini или локальных моделей такого замера у вас нет.

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

Не переносятся архитектурные приёмы. Прогрессивное раскрытие, отложенная загрузка инструментов, автопамять — это свойства обвязки, а не модели. В чужом фреймворке эквивалента может не быть, и тогда «вынесите редкое в отдельный скилл» превращается в «вынесите в файл, который никто не подгрузит».

И главное

Спор о длине промптов маскирует настоящую проблему: у нас нет способа отличить улучшение от ухудшения. Пока его нет, любое решение — резать или не резать — принимается на ощущениях. Вопрос не в том, сколько правил у вас в скиллах, а в том, знаете ли вы, какие из них хоть на что-то влияют. А это уже content ops. 😎

Тг: https://t.me/proitru/2948

Смотрим на отчёт Similarweb «2026 Generative AI Landscape». Сначала общие выводы:

1️⃣ Первое, что стоит заметить, — это разрыв между двумя метриками роста. Визиты выросли на 70% до 9,5 млрд, а уникальные посетители — только на 57%, до 655 млн. Аудитория расширяется медленнее, чем растёт частота обращений: приходят не столько новые люди, сколько одни и те же, но чаще. ИИ перешёл из режима «попробовать» в режим привычки, и окно первого впечатления для брендов закрывается — вас теперь встречают внутри уже сложившегося сценария.

2️⃣ Второе — дробление идёт не туда, куда кажется по заголовкам. Доля ChatGPT в веб-визитах упала с примерно 76% в июне 2025 до около 53% к маю 2026, и главный бенефициар здесь Gemini: с менее 9% до 27–28%. По вебу перераспределение идёт в пользу Google. Это меняет практический вывод: «оптимизировать под ИИ» и «оптимизировать под Google» — уже не два проекта, а один.

3️⃣ Третье — замещения нет, есть наслоение. 461 млн из 494 млн пользователей ChatGPT в марте-мае 2026 продолжали пользоваться и Google, а поиск в целом держит 3,3 млрд уникальных посетителей в месяц против 655 млн у чатботов. Разрыв впятеро. Старый канал никуда не делся, новый добавился сверху — бюджет делится, а работы становится вдвое больше.

4️⃣ И, четвёртое, последнее, самое неудобное для отчётности. К рекомендованному ИИ бренду пользователи заходят в два-четыре раза чаще, чем к нерекомендованному конкуренту — при том что ссылку на источник содержат всего 6,8% ответов. Влияние на выбор идёт мимо реферального трафика, и в вашей аналитике его просто не будет видно.

➡️ Теперь #контентменеджерское :

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

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

3️⃣ Разделить роли страниц. ИИ цитирует материалы на два-три уровня вглубь, а приходят люди почти всегда на главную и верхнеуровневые. Значит, страницу «из глубин сайта» нельзя оценивать по трафику — её задача быть доказательной базой, и мерить её надо упоминаниями. А верхнеуровневая должна встречать человека, который уже что-то о вас знает из ответа ИИ, а не начинать разговор с нуля.

4️⃣ Писать под длинный запрос, а не под ключ. Средняя длина запросов растёт: привычка формулировать промпты переехала в поисковую строку. Это меняет требование к материалу — он должен отвечать на конкретный вопрос с условиями («для команды из пяти человек», «если данные в другом формате»), а не покрывать тему в целом. Ключ теперь не в заголовке, а в том, насколько узкий случай вы разобрали внутри.

5️⃣ Проставить авторство и подтверждаемость. Фамилия автора, его роль, ссылка на первоисточник у каждой цифры. Это то, что отличает материал-донор от материала-сырья.

6️⃣ Завести реестр упоминаний. Раз в месяц прогонять 20–30 профильных запросов по ChatGPT, Gemini, Perplexity и фиксировать: упомянули или нет, какая формулировка, кто рядом, какая страница процитирована. Без этих логов обсуждать «видимость в ИИ» не с чем.

#geo #ai

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

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

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

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

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

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

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

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

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

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

#ai

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

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

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

➡️ текстами от рерайтеров на бирже за 30 рублей за 1000 знаков;
➡️ стоковыми фотографиями с улыбающимися людьми в офисах;
➡️ лендингами, сделанными племянником директора в конструкторе;
➡️ пресс-релизами, написанными по шаблону 2003 года.

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

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

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

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

#ai

Хабр-дайджест: 09.03 — 13.03.2026
Пока разработчики спорят о качестве ИИ-кода, Рунет тихо переходит на белые списки.
ГЛАВНОЕ
Белые списки добрались до Москвы
— Самая рейтинговая статья недели (+185, 68 000 просмотров): технический разбор того, как DPI-фильтры ограничивают трафик до первых 16–20 КБ для нежелательных сайтов. Из миллиона доменов в белом списке остаётся ~0,1%.
Как ТСПУ ловит VLESS в 2026 и почему XHTTP — следующий шаг
— Четырёхслойная архитектура детекции VLESS-туннелей через DPI. Reality больше не защищает надёжно; автор разбирает XHTTP как следующий транспортный протокол и даёт рабочие конфигурации. 65 000 просмотров и 461 закладка.
После блокировки мессенджеров Matrix стал единственной альтернативой?
— Практическое руководство по развёртыванию Matrix Synapse на VPS за 5 минут.
ИИ: МЕЖДУ ХАЙПОМ И РЕАЛЬНОСТЬЮ
Код ИИ — это бред
— Один из самых острых текстов недели (+158). ИИ отвечает ассоциациями, а не логикой — и при бесконтрольном использовании архитектура проекта деградирует быстро и незаметно.
ИИ-дед возвращается
— Рабочий прототип голосового бота против мошенников: Whisper + Claude Haiku + ElevenLabs на WebRTC. Честный разбор проблем: задержки синтеза 6–8 секунд (+139).
LLM Inside: выжимаем максимум из Decoder Attention на GPU
— Яндекс: три операции Attention в одном CUDA-kernel через Online Softmax. 85–91% утилизации пропускной способности GPU.
ПРОГРАММИРОВАНИЕ И ИНСТРУМЕНТЫ
Мой плохой код — это ваша вина
— Критический разбор Bash, C/C++, Git, PostgreSQL и Django как инструментов с порочным API. Многие ошибки заложены в дизайне самих инструментов (+141).
Написал шахматный движок для 6×6 Crazyhouse — стал #1 на chess.com, а потом меня забанили
— Python → Rust через PyO3 с ускорением в 50 раз. Alpha-beta поиск без нейросетей — и закономерный бан.
Создание процедурной карты шестиугольников при помощи коллапса волновой функции
— Генератор карт на Three.js + WebGPU: Wave Function Collapse для ~4 100 ячеек с рендерингом воды и каустикой (+110).
ЖЕЛЕЗО И АРХИТЕКТУРА
Почему у нас нет кешей L5?
— Физический принцип «большой кэш не может быть быстрым», протоколы когерентности MESI и MOESI, редкие примеры L4 — Intel Haswell eDRAM и AMD 3D V-Cache.
ИНФРАСТРУКТУРА И БАЗЫ ДАННЫХ
Как построить отказоустойчивый PostgreSQL-кластер и не промахнуться
— etcd vs Consul, Patroni vs Stolon, маршрутизация между ДЦ. От Postgres Professional — с разбором типичных ошибок.
Немезида для хаоса: событийная архитектура для 500+ интеграций
— Яндекс Go: библиотека → платформа за 6 месяцев. Время развёртывания интеграции — 4 часа; трафик снизился с 11 000 до 2 000 RPS.
ИНФОРМАЦИОННАЯ БЕЗОПАСНОСТЬ
Мартовский «В тренде VM»: уязвимости в продуктах Microsoft
— Positive Technologies выделили 4 трендовые уязвимости: Windows Shell (CVE-2026-21510), Microsoft Word (CVE-2026-21514), Desktop Window Manager (CVE-2026-21519) и RDP-службы (CVE-2026-21533). Все уже эксплуатируются или будут в ближайшее время.
Кибербезопасность финансовой отрасли России в 2026 году
— Злоумышленники перешли от точечных атак к каскадным сценариям через подрядчиков, дочерние компании и цепочки поставок. Финсектор — главная цель: атаки на экосистемы, а не на отдельные организации.
Околоенотная грамота, или Как я создавал генератор паролей
— как создать свой генератор паролей.

Ещё одна статья Anthropic, которую я перечитал на выходных, «Building effective agents» - https://www.anthropic.com/engineering/building-effective-agents - вышла ещё в декабре 2024. Но я возвращаюсь к ней снова, потому что она остаётся одним из лучших объяснений того, что вообще происходит под капотом агентных систем.

Главный тезис, который я долго не мог принять: самые успешные команды строят агентов не на сложных фреймворках, а на простых компонуемых паттернах. Я читал это и думал: ну да, классика «keep it simple», слышали. А потом попробовал сам и понял, что это не про философию, а про конкретную боль.

Anthropic разделяют два понятия, которые все мешают в одну кучу:

1️⃣ Воркфлоу — когда LLM работает по заранее заданным путям в коде.
2️⃣ Агент — когда LLM сам решает, что и как делать.
Большинство задач, которые называют «агентными», на самом деле воркфлоу. И это нормально.

В статье описаны пять паттернов по нарастающей сложности.

1️⃣ Prompt chaining — просто цепочка вызовов, выход одного становится входом следующего.
2️⃣ Routing — классификация запроса и отправка по нужному пути.
3️⃣ Parallelization — несколько LLM-вызовов одновременно, когда нужна скорость или уверенность через голосование.
4️⃣ Orchestrator-workers — центральный LLM динамически раздаёт задачи воркерам, когда нельзя заранее предсказать шаги.
5️⃣ И evaluator-optimizer — один генерирует, второй критикует, по кругу.

Для меня это переключило мышление с «какой агент мне нужен» на «какой минимальный паттерн решает задачу». Статья для Хабра — это evaluator-optimizer: один агент пишет черновик, второй проверяет по редполитике и возвращает замечания. Не потому что так круто звучит, а потому что это минимальная архитектура, которая решает конкретную проблему качества.

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

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

Статья старая, часть примеров уже обросла более свежими материалами. Но как фундамент для понимания архитектуры агентных систем — до сих пор лучшее из того, что я читал. Если вы ещё не строили ничего агентного, начните с неё.

Изучил на выходных статью инженеров Anthropic про инструменты для агентов. Попробовал переложить на свою работу — получилось неожиданно.

Статья технически про MCP и то, как правильно проектировать инструменты для LLM-агентов. Казалось бы, это про разработчиков, не про контент. Но там есть один принцип, который перевернул мне представление о том, где вообще хранить редполитику команды.
Вот проблема, которую я не мог нормально решить: например, агент пишет статью для Хабра и каждый раз нужно напоминать ему голос, запрещённые слова, структуру. Зашиваешь в системный промпт — он раздувается и агент начинает игнорировать детали. Делаешь отдельный документ со стайлгайдом — агент его «читает», но не соблюдает.

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

И я понял: описание инструмента — это и есть правильное место для редполитики.

Не системный промпт. Не отдельный файл. А description конкретного инструмента write_habr_post.

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

Второй принцип, который оказался важным для контента: инструменты должны консолидировать операции, а не дробить их. Не generate_text + check_style + add_seo как три отдельных вызова. А один write_habr_post, который под капотом делает всё и возвращает готовый артефакт: текст, теги, три варианта заголовка.

Меньше шагов, меньше дрейфа от цели. Агент не теряется в последовательности вызовов.

Это не революция в подходе, скорее смещение акцента. Мы привыкли думать о качестве контент-агента через промпты. Статья предлагает думать через архитектуру инструментов. Редполитика перестаёт быть документом, который все знают но никто не читает — она становится частью того, как система работает.

Буду переписывать отдельные агенты и проверять на практике. Мой путь в нейросетях вообще напоминает эволюцию: от промптов к Claude Code, теперь к архитектуре агентных систем.