Ещё одна статья Anthropic, которую я перечитал на выходных, «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 потратила больше времени на оптимизацию инструментов, чем на общий промпт. Интерфейс агент-компьютер требует столько же внимания, сколько человеко-компьютерный. Это перекликается с тем, о чём я писал раньше про описания инструментов как место для редполитики.

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

#ai_agents

Продолжаю приземлять прошлогодние статьи инженеров Anthropic на контент. Сегодня выводы из материала про контекст-инжиниринг.

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

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

Интересно, что Claude Code решает часть этой проблемы нативно и статья объясняет почему именно так. CLAUDE.md грузится в начало каждой сессии как высокоприоритетный контекст. Компакция включается автоматически, когда окно заполняется: модель сама пишет конспект — архитектурные решения, незакрытые вопросы, текущее состояние — и продолжает с ним. Инструменты типа glob и grep дают агенту возможность тянуть файлы по необходимости, а не загружать всё сразу.

Но это работает из коробки для кода. Для контентных задач — нет.

Когда сейчас я строю агента в Claude Code, то упаковываю в CLAUDE.md всё: редполитику, голос, запрещённые слова, структуру, примеры. Это тот же антипаттерн — «загрузи всё». Статья предлагает другой принцип: в каждый момент в контексте должен быть наименьший набор высокосигнальных токенов, достаточный для следующего шага.

Для моих контентных агентов в Claude Code это означает три вещи:

1️⃣ CLAUDE.md должен содержать только принципы и примеры голоса — не полный список правил. Конкретные данные: факты о продукте, статистику, кейсы — агент должен тянуть через инструменты поиска в момент, когда они реально нужны в тексте, а не получать заранее.

2️⃣ Сложные задачи нужно разбивать на субагентов с чистым контекстом на каждом этапе. Ресёрчер собирает данные и возвращает конспект. Автор получает только конспект — не сырые результаты поиска. Ревьюер получает только финальный текст. Каждый работает в чистом окне.

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

Если подытожить, то означает одно изменение в архитектуре: разбить монолитного «агента-писателя» на три чистых этапа: ресёрч → черновик → ревью — где каждый этап получает только результат предыдущего, а не всю историю работы. Это и есть контекст-инжиниринг применительно к контенту. В моих агентах уже есть такие пайплайны, но надо теперь продумать более чистые переходы от агента к агенту.

#ai_agents

Вдогонку к утреннему посту, выводы из статьи AI Agents in Production: Frameworks, Protocols, and What Actually Works in 2026. Там они, собственно, прямо и описаны, но для вас решил перевести. Очень хорошо подходят и к работе над контентными агентами.

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

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

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

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

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

Доработка и есть настоящий проект. Собрать первую рабочую версию агента — это 20% работы. Остальные 80% — итеративная настройка: правка описаний инструментов, калибровка голоса, отлов нестандартных сценариев, которые не предусмотрел при проектировании. Для контентных агентов особенно: голос и редполитика требуют многократной итерации на реальных текстах.

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

#ai_agents
📥Левашов

OpenAI встраивает Sora в ChatGPT. Пока это только утечка через The Information, официального подтверждения нет — но выглядит логично.

Sora запустилась как отдельное приложение в сентябре 2025: взлетела на первое место в App Store, набрала почти 10 млн скачиваний. Потом всё быстро затихло — в январе установки упали на 45%, расходы пользователей сократились, приложение вылетело из топ-100. Сделка с Disney на контент с их персонажами тоже не помогла.
Решение предсказуемое: не можешь удержать пользователей отдельным продуктом — встрой его туда, где они уже есть. Именно так год назад ChatGPT поглотил DALL-E. Standalone-приложение Sora, судя по всему, останется, но основная аудитория придёт через чат.

ChatGPT используют около 900 млн человек в неделю. Для сравнения — у Sora было 9,6 млн скачиваний за всё время. Разница объясняет стратегию лучше любых слов.

Интересно другое: ChatGPT за последний год превращается в платформу. Текст, изображения (DALL-E), веб-поиск, интерактивные визуализации для обучения, а теперь видео. Граница между «чат-ботом» и «универсальным AI-инструментом» стирается быстрее, чем кажется.

Риски тоже реальные. При запуске Sora пользователи быстро начали делать дипфейки с историческими личностями и контент с нарушением авторских прав. Водяные знаки и фильтры есть, но обходные пути находятся всегда. Встраивание в ChatGPT масштабирует и возможности, и проблему одновременно.

#ai_news
📥Инженер Контекста

Мы вот такое в фильмах фантастических видели, а оно уже здесь. Google раскатила агентную автоматизацию на Galaxy S26 и Pixel 10. Пока бета, пока только США и Корея.

Работает так: зажимаешь кнопку питания, говоришь Gemini что сделать — «закажи пиццу на Uber Eats» или «вызови такси домой». Агент открывает приложение в защищённом виртуальном окне, проходит все шаги сам, перед оплатой останавливается и ждёт твоего подтверждения. Журналисты уже проверили на Galaxy S26 Ultra.

Поддерживаются Uber, Lyft, DoorDash, Grubhub, Uber Eats, Starbucks.

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

Кто в России сможет первый такое реализовать, как думаете?

#ai_news
📥Инженер Контекста

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

➡️ Воркфлоу: порядок шагов прописываем мы, LLM исполняет.
➡️ Агент: мы даём цель и инструменты, модель сама решает что вызвать, в каком порядке и когда остановиться.

Если в твоём описании агента написано «сначала сделай структуру, потом черновик, потом проверь редполитику» и нейросеть просто выполняет шаги в этом порядке — это воркфлоу. Ты прописал поток, модель исполняет.

Если нейросеть сама решает: «мне не хватает данных, пойду поищу в базе знаний» или «структура слабая, переделаю перед тем как писать» — и ты это не прописывал явно — это агент. Модель управляет потоком сама.

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

И немного теории. Есть четыре воркфлоу-архитектуры:

1️⃣ Prompt Chaining — цепочка вызовов LLM, результат каждого шага передаётся в следующий. Между шагами gate: не прошёл валидацию — шаг перезапускается. Большинство моих агентов написаны в этом воркфлоу.

2️⃣ Routing — LLM классифицирует запрос один раз, код направляет к нужному обработчику. Одно решение, один раз — это ещё воркфлоу. Это то, что я реализую сейчас, чтобы не терять контекст. Подробнее вот тут.

3️⃣ Parallelization — два варианта. Sectioning: задача бьётся на независимые части, каждую обрабатывает отдельный LLM параллельно, агрегатор собирает. Voting: несколько LLM решают одну задачу независимо, побеждает большинство.

4️⃣ Evaluator-Optimizer — генератор создаёт, оценщик критикует, генератор переделывает. Цикл контролируется кодом. Больше 2–3 итераций не имеет смысла: контекст раздувается, модель путается в своих версиях.

Последние два воркфлоу я использую, например, для агентов редактуры и проверки редполитики.

И две агентские архитектуры:

1️⃣ ReAct (Reasoning + Acting) — базовая агентская архитектура. Цикл: Think (какой инструмент вызвать) → Act (инструмент выполняется) → Observe (результат в контекст, хватит или ещё шаг). Повторяется пока модель сама не решит что данных достаточно. Это работает под капотом когда Claude Code читает и правит файл.

2️⃣ Orchestrator-Workers — оркестратор разбивает задачу на части и раздаёт субагентам. Количество субагентов определяется динамически под конкретную задачу, не прописано в коде — в этом отличие от Parallelization. Каждый субагент — отдельный ReAct со своим контекстом.

Далее разберу подробнее воркфлоу-архитектуры. Там под капотом тоже интересно.

#ai_agents
📥Инженер Контекста