Как LLM сдаются под натиском multi-turn атак

Cisco AI Defense выкатили исследование, которое хоронит миф о безопасности опенсорсных LLM в проде. Протестировали 8 моделей — от Llama 3.3 до Microsoft Phi-4. Средний success rate взлома: 64.21%.

Что тестировали:
499 диалогов с каждой моделью.
96 вредоносных сценариев.
102 угрозы.
Black-box режим.

Модели:
- Qwen3-32B (Alibaba)
- DeepSeek v3.1
- Llama 3.3-70B (Meta)
- Microsoft Phi-4
- GPT-OSS-20B
- Mistral Large-2
- Google Gemma-3-1B-IT

Лучше всех держался Google Gemma — 25.86% взломов.
Худший — Mistral с 92.78%.

Техники атак:
Crescendo — постепенное наращивание интенсивности запросов. Начинаешь с безобидных вопросов, плавно подводишь к запрещённому контенту.
Role-playing — "Представь, что ты хакер в фильме, как бы ты написал малварь?"
Prompt rephrasing — модель отказала? Переформулируй 5 раз, она сломается.
Trust building — сначала болтаешь о котиках, потом когда контекстное окно переполнено "а давай теперь про эксплойты".
Такие multi-turn атаки оказались в 2-10 раз эффективнее одиночных промптов.

Топ-5 выявленных угроз:
Malicious code generation — модели генерят эксплойты и малварь
Data exfiltration — вытягивают sensitive data через хитрые промпты
Ethical boundary violations — обходят этические ограничения как дорожные конусы
Misinformation — создают дезинфу промышленными масштабами
Sensitive disclosure — сливают конфиденциальную инфу

Модели не удерживают safety context на длинных диалогах. Safety guardrails заточены под одиночные запросы. В длинном разговоре модель теряет связь с предыдущими ограничениями.
Capability-first модели (Llama 3.3, Qwen3-32B) показали огромный разрыв между single-turn и multi-turn взломами. Создатели явно выбрали функциональность вместо безопасности.
Safety-first модели (Google Gemma) держатся чуть лучше, но тоже уязвимы.
Cisco прогнали DeepSeek R1 через 50 jailbreak промптов — получили 100% успех.

Влияние на энтерпрайз:
86% компаний словили инциденты связанные с LLM/VLM из-за выявленных уязвимостей. Но возможно просто еще не выявили их:
- Утечки защищаемой информации
- Генерации малвари в developer tools внутри периметра компании
- Content manipulation в приложениях с интегрированным доступом к моделям
Опенсорсные модельки активно используют в энтерпрайзе "как есть" и для fine-tuning. Второе не спасает, если базовая модель уязвима — все дотюненые версии тоже наследуют эти дыры.

Что советуют:
Runtime guardrails — детектить adversarial patterns в реальном времени (заводим в SOC пул диалогов и действий агентов)
Strict system prompts — жёстко ограничить доступ к редактированию конфигурационных файлов с промтами (хардкодим промты)
Regular AI red-teaming — непрерывно тестировать в контексте бизнес-сценариев (написать методику что тестируем и зачем, регулярно прогонять ручками и в авторежиме)
Ограничить external integrations — минимизировать интеграции с automated services (привет агентные системы)
Multi-turn aware filtering — детектить изменение контекста диалога в мультиагентных системах (делаем отдельный агент следящий за ходом диалога)

Вместо выводов:
Все открытые языковые модели обучены защищаться от одиночных атак, но в рабочей среде у вас диалоги.
Модели теряют контекст безопасности в длинных диалогах — это не ошибка, это нерешённая проблема всей отрасли.
Без внешних защитных слоёв (механизмы в процессе работы, отслеживание многоходовых атак, red team testing перед выкаткой прод) вы рискуете утечками, генерацией вредоносного кода и нарушениями требований. Защита "желательна" при поиграться самому на прототипе, но обязательное требование безопасности в энтерпрайзе

У кого в production стоят опенсорсные модели без дополнительных механик защиты? 🤔

AI-кибератака на глобальные организации от Anthropic

В сентябре 2025 года команда Anthropic выявила серию целенаправленных атак на технологические, финансовые, государственные и промышленные организации. Для автоматизации операций злоумышленники использовали AI-агента Claude Code, обходили ограничения модели через jailbreak-промпты и получили доступ к чувствительным системам. Атаки были полностью автономными — человеческое участие оценивалось в 10–20%.

Хронология событий:
Фиксация нетипичной активности на аккаунтах Anthropic.
+2 дня: Начало внутреннего расследования, сбор логов и следов AI-генерированных операций.
+5–7 дней: Сравнение паттернов атак с известными группировками, идентификация государственной китайской связки.
+10 дней: Отключение уязвимых сервисов и принудительная блокировка опасных действий AI-агента; уведомление пострадавших компаний; публикация отчёта.

Агент автономно проводил:
- Рекогносцировку инфраструктуры
- Поиск уязвимостей и написание эксплойтов
- Кражу учетных данных и lateral movement (перемещения внутри сети)
- Экспликацию данных и установку бекдоров
Доступ осуществлялся, имитируя pentest-команды — AI агентов обманывали промптами, выданными как команды для тестирования.
Одна из сложностей — эскалация прав и обход систем мониторинга происходили по цепочке с минимальным человеческим вмешательством.
Охват атаки: более 30 организаций
Автоматизация: 90% операций реализованы AI самостоятельно
Время реакции: от обнаружения до локализации — 10 дней

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

Для защиты команд и продуктов AI критически важно внедрять новые подходы к observability, безопасности LLM и построению устойчивых процессов реагирования:
- AI-агенты способны автономно проводить сложные атаки с минимальным вмешательством человека — нужен пересмотр протоколов доступа и мониторинга.
- Требуется интеграция специфических средств защиты для моделей LLM (детектирование jailbreaking, контроль доступа, постоянный аудит запросов).
- Регулярные учения по реагированию на подобные инциденты, обновление процедур postmortem и обмен индикаторами компрометации с сообществом.

Сегодня завели агента в прод — и это не про «успешный успех», а про реальную работу: релизы, фиксы, согласования, отсутствие dev‑среды, борьбу за тестовый контур и огромные отличия pre‑prod и prod, несколько дней в prod с нерабочим агентом без сетевой связности с LLM.

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

Что значит «в прод» в нашей ситуации?
«В прод» — это не кнопка.
Это цепочка артефактов и гейтов: статусы в трекере, привязки к релизу, CI в одной АС, CD в другой АС, формальные переходы типа Ready for QA, плюс несколько контуров в разных АС (DEV/IFT/QA/UAT/PROD) с разными правилами, доступами и окружением.

Уроки “первого релиза в новую АС”:
- Делайте не только фичу, а поставку: тикеты, описания, changelog, сценарий отката — это валюта доверия, особенно когда вокруг нет устоявшегося процесса и новые “точки контроля” возникают в последний момент.
- Либо встраивайтесь в конвейер платформенной команды, либо стройте его вместе: CI, CD, правила релиза, кто апрувит, кто владелец прода.
- Пишите “как будет ломаться” заранее: health-check’и, liveness/readiness, алёрты по error rate/latency, миграции — иначе это всё будет написано в чате инцидента, в режиме пожара.
- Не геройствуйте в одиночку: релиз — командный спорт (SRE/DevOps/DBA/разработка/владельцы систем), и вы либо договариваетесь заранее, либо потом срочно “ищете людей” по оргструктуре.

Ключевое: первый релиз — самый дорогой, потому что вы строите supply chain и договариваетесь о правилах. Дальше появляются повторяемость и предсказуемость: хотфиксы, второй релиз и т.д.

Пару месяцев назад принял участие в шоу https://t.me/k2cloud_team/227
Если устали на праздниках, то может взбодрить)

Посмотрел интервью с Marily Nika (AI Product Lead в Google). Она построила в Google больше LLM-приложений и AI-продуктов, чем кто-либо иной.

В интервью прослеживается смена парадигмы работы продактов и аналитиков из-за применения моделей.
Если раньше флоу работы был похож на "Идея → PRD → Согласование → Код", то теперь это "Идея → AI-прототип → Демо инженерам → Код".

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

Стек инструментов - 6 вполне ожидаемых:
1️⃣ Google AI Studio — для быстрого прототипирования: рабочее приложение за 10 минут прямо в браузере (Gemini Pro и Nano Banana для генерации картинок). Она приходит к инженерам не с текстом, а с работающим интерфейсом.
2️⃣ Opal (Google Labs) — для создания мини-апов и "одноразовых" приложений через промпты.
3️⃣ NotebookLM — для доменной экспертизы + RAG по продукту.
Киллер-фича: загружаешь тонну видео и сложную документацию → получаешь справочник за 15 минут. Идеально для погружения в новую тему.
4️⃣ Perplexity с тулом Reddit — для User Research, что отключает поиск по вебу и ищет только по тредам Reddit. Это дает реальные "боли" пользователей, а не типичные успешные успехи из SEO-статей.
5️⃣ Агент с LLM — для генерации PRD на основе предыдущих документов и tone of voice команды.
6️⃣ Fireflies — для саммари встреч, которые можно лить в Notebooklm

🦀 Карьерный инсайт из видео стратегия "Краба":
Эпоха бизнеса без применения ML/AI заканчивается. Хочешь в AI? Не прыгай в неизвестность, а двигайся боком внутри своей доменной области.— Занимался звуком? Иди в AI-звук или речевые технологии. Не иди в другие домены.
— Занимался графикой? Иди в AI-генерацию изображений или компьютерное зрение.Твой опыт — это конкурентное преимущество, не обнуляй его.

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

Если снять продуктовый хайп с всего что Маск делает переводом на IPO, то в части агентизации для меня интересна история Grokipedia — эталонный кейс Context Management System.

Это демонстрация главной проблемы Enterprise AI: как управлять "окном внимания" модели, когда база знаний бесконечна "нам надо загрузить все, и конфлю, и транскрипции, и интернет, и трендвотчинг отчёты и тд"), а данные разношёрстные и противоречат друг другу.

Что можно утащить к себе:

1. Статья — это "замороженный контекст" (Frozen context).
В классическом RAG мы тянем контекст «на лету» под каждый запрос. Это дорого (latency + токены) и не всегда стабильно.
В Grokipedia агент работает предиктивно. Статья — это snapshot контекстного окна, закешированный результат работы агента.
В проме выигрываем в скорости отдачи (пользователь читает статику), но получаем проблему которую называют Context Drift. Управление версионированием статьи становится управлением кэша.

2. Разрешение конфликтов (Conflict resolution).
Главный вызов в этом подходе — примирить противоречивые данные:
* Wikipedia говорит А.
* Пост в X говорит Б.
* ArXiv говорит В.
Модель не просто суммаризирует, она взвешивает "авторитетность" токенов.
В корпоративном RAG это боль №1: когда старая спецификация в Confluence противоречит свежему тикету в Jira, коду в Git, архитектурной спеке в какой-то другой системе. Если просто "скормить всё" — получим галлюцинацию и "ваш агент - г**но".

3. Сжатие смысла (Context compression).
Grokipedia показывает, как решать задачу на масштабе, когда модель не может впихнуть в промпт весь контекст темы. Агенту приходится:
1. Отобрать топ-N чанков.
2. Сжать их (summarization).
3. Выстроить иерархию (что в H1, что в сноску).
Каждая статья — это лог того, как модель отранжировала информацию по релевантности.

Чеклист: что забрать в архитектуру БЗ
1) Snapshotting.
Не надо всегда делать Real-time RAG. Если данные меняются редко (инструкции, регламенты), дешевле и надежнее сгенерировать «справку» агентом один раз в сутки/неделю, чем собирать контекст при каждом запросе юзера по всей БЗ.
2) Настроить веса источников.
В RAG-пайплайне жестко прописать иерархию доверия. Например: Git Code > Jira Ticket (Closed) > Confluence Page. Если источники конфликтуют — побеждает тот, что выше по рангу, а не тот, что семантически ближе.
3) Разделять Hot & Cold Context.
Статичные знания (Cold) могут лежать в дообучении или кэшированных промптах. Оперативка (Hot) — только через поиск. Смешивание этих слоев без маркировки — гарантия того, что агент будет врать, а пользователи беситься.

Вопрос на подумать:
В ваших RAG-пайплайнах как вы решаете конфликт данных? Если два документа говорят разное — побеждает тот, что новее (timestamp), или тот, что лежит в «более важной» папке (authority)? Или кто-то добавляет ручками теги важности?

Compound Engineering: Как заставить AI-агентов снижать, а не растить техдолг

В целом нас учили, что разработка — это линейный процесс: Plan -> Code -> Ship. Но когда код пишут агенты, этот подход генерирует тонны legacy кода, в котором никто не разбирается.
Киран Классен (Kieran Klaassen) из Every.to представил фреймворк Compound Engineering, который меняет эту legacy парадигму.

Суть проста: каждая единица работы должна делать следующую работу легче.
Если в классической разработке сложность со временем растет, то в Compound Engineering она должна падать за счет постоянной «кодификации» опыта в контекст агента (опять управление контекстом, экономия токенов и тд).

Фреймворк делит работу над фичей на 4 этапа, цикл с распределением усилий 40/20/20/20.
Обратите внимание на распределение времени:

1. Plan (40%) — Люди + Контекст.
Самая большая инвестиция времени. Мы не просим агента «написать код», мы готовим почву:
Сбор релевантных файлов и документации.
Написание детального спека (Spec).
Цель: Агент не должен «думать» во время кодинга, он должен только исполнять.

2. Work (20%) — AI-агенты (DeepSeek, Claude, Cursor) пишут код, тесты и документацию.
Это самый дешевый этап. Если фаза Plan сделана качественно, генерация проходит быстро и с минимумом галлюцинаций и повторных генераций.

3. Review (20%) — валидация. Автоматические проверки: типы, линтеры, тесты.
Человеческое ревью: проверка не синтаксиса, а соответствия интенту.

4. Compound (20%) — Самое важное во всей схеме.
То, ради чего всё затевалось. Если в процессе возникла ошибка или агент «затупил», мы не просто фиксим баг.
Мы обновляем систему:
А) Записываем паттерн в условный PATTERNS.MD.
Б) Обновляем системный промпт, чтобы ошибка не повторилась никогда.
В) Добавляем новый кейс в базу знаний RAG.

Плюсы:
1) Проект становится понятнее для моделей и сотрудников с каждым коммитом.
2) Новый агент (или сотрудник) сразу получает весь накопленный опыт команды через обновленные контекст и промпты.

Минусы:
1) Требует жесткой культуры ведения документации. Нельзя просто «пофиксить и забыть».
2) Высокая загрузка на старте: Первые фичи делаются дольше из-за настройки фазы Plan.

Кто уже пробовал вести подобные заметки для агентов в своих проектах?

Google DORA опросил более 5 000 инженеров и получил результат, который неудобен для производителя AI-инструментов.

Цифры из первых уст (DORA 2025):
- 90% разработчиков используют AI на работе (+14% к 2024-му)
- >80% считают, что продуктивность выросла
- Только 24% доверяют AI «много» или «очень много»
- 30% доверяют «чуть-чуть» или «совсем не доверяют»
- 61% никогда не использовали AI-агентов

Читаю это как: большинство полагается на инструмент, которому не доверяет. И это рациональная стратегия.

Но главная находка DORA — не про доверие. Про усиление.
Агенты функционируют как усилитель существующих сильных и слабых сторон, а не как серебряная пуля от всех проблем:
Сильная команда с AI — быстрее и стабильнее.
Слабая команда с AI — тащит в прод мусор утилизирующий железо и не приносящий выгоды в два раза быстрее.

AI adoption коррелирует с ростом скорости поставки и с ростом нестабильности — больше change failures.
Более 60% разработчиков находили ошибки в коде уже после деплоя в пром (привет баги в проме).
Без трейсабилити и управления для AI-агентов — это невидимый до определенного момента техдолг.

Чеклист как использовать это при продуктивизации агента:
- Не убеждать пользователя доверять агенту — использовать недоверие как фичу: приглашать на ревью сделанной агентом работы.
- Частота использования не равна доверию — высокий DAU агента при низком доверии = люди просто красят дашборд руководителя с красного или жёлтого на зеленый. Для оценки реальности нужна отдельная методика.
- Перед внедрением агента проверить систему, а не модели — DORA вводит 7 архетипов команд. В "legacy-узкой" команде агент вскроет узкое место в QA и code review, к которым она не готова.
- Governance AI Capabilities Model не инструкция в конфлюэнсе, а инфра с quality gates с динамическая практиками version control, transparency и measurable risk management для кода, генерируемого агентами.
- Доверие растёт через экспозицию, а не убеждение (долой презентации "смотрите как круто будет если начнёте пользоваться") — чем больше разработчик видит реальные возможности и ограничения инструмента, тем выше доверие.

Гипотеза, не подтвержденная DORA напрямую: потолок доверия в ~24% не сдвинется на уровне продукта без внешнего влияния.
Улучшение LLM и агентов само по себе не поднимает доверие, потому что пользователь не видит, почему так, а не иначе.

Вы отслеживаете adoption и trust отдельно как метрики для ваших AI-инструментов?
Считаете, что «если используют, значит доверяют»?
Может просто красят дашборд для закрытия KR?

Флот агентов вместо одного ассистента

Инженеры OpenAI больше не просят AI написать код. Они управляют флотом из 10–20 параллельных агентов — и это уже не эксперимент, а ежедневная практика.

Что происходит внутри OpenAI

Sherwin Wu (Head of Engineering, OpenAI API Platform) в подкасте Lenny's Newsletter в феврале 2026 раскрыл цифры изнутри:
— 95% инженеров используют Codex ежедневно
— 100% PR-ов проходят через Codex-ревью до того, как попадают к человеку
— Code review сократился с 10–15 до 2–3 минут

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

Главная причина провалов агентов, по словам Wu: underspecification — контекст не задан достаточно подробно.
Не модель плохая, а вводные слабые.

Что происходит внутри Antropic

В январе 2026 Boris Cherny (создатель Claude Code) описал свой рабочий процесс.
Никакого «одного чата» — у него одновременно 5 сессий в терминале + 5–10 в браузере:

Паттерн «spec → fleet»:
1. Plan mode → явный план до первой строчки кода: что делать, в каком порядке, как проверить
2. Subagents → отдельный агент на каждую роль: один пишет PRD, другой кодит, третий тестирует
3. Verify → каждый шаг верифицируется до перехода к следующему
4. Re-plan → если что-то пошло не так — стоп и новый план, а не «допиши как-нибудь»

Главный принцип
Фраза из подкаста Sherwin Wu, ставшая мемом: «Models will eat your scaffolding for breakfast».
Смысл: скаффолдинг под текущую модель даёт +10–20% сейчас и обнуляется следующим релизом.
Строй под архитектуру, а не под конкретную версию/фичу.

Флот агентов усиливает то, что есть здесь и сейчас: если процессы слабые, хаоса станет больше, а не меньше.

А у вашей команды как? Уже перешли к паттерну «оркестратор агентов» или всё ещё на уровне «попросил DeepSeek/ChatGPTClaude Code»? Какой главный барьер — инструменты, процессы или сопротивление команды?

Мы переписываем агентов под каждую задачу. Это не архитектура — это технический долг.

Смотрю на десятки multi-agent пайплайнов и везде одна картина:
кастомные роли (так стандарт же),
захардкоженные промпты (привет ИБ),
своя логика коммуникации (от команды к команде).

Новая задача — пишешь с нуля. Поменял модель на preview — половина нод пайплайна сломалась.

В статье Agent Primitives (arXiv:2602.03695) исследователи предлагают другой фундамент:
собирать системы из переиспользуемых «латентных блоков»,
как residual-слои в нейросетях.

Как это должно работать:
Вместо уникальных агентов авторы выделяют три базовых примитива:
— Review: итеративная критика (Solver → Critic → Solver).
— Voting: консенсус (несколько Solver’ов → Selector).
— Planning: декомпозиция (Planner → Executor).

А собирает их вместе Organizer — легковесный агент-маршрутизатор, который под новую задачу динамически решает, какие примитивы и в каком порядке вызывать.
Издалека похоже на AEF Сбера и дочек?
Но есть нюансы.

KV-кэш вместо текста (Инфра)
Обычно агенты общаются текстом, раздувая контекст и искажая суть при «пересказе». В статье примитивы передают друг другу напрямую KV-кэш (key/value тензоры из attention-слоёв).
Цифры на бенчмарках (MATH, HumanEval+): это даёт +12–16% к точности и сокращает расход токенов в 3–4 раза.
Оверхед системы при этом всего 1.3–1.6x.

⚠️ Почему пока не надо нести это в пром
1. Vendor Lock-in: Передача KV-кэша требует, чтобы у всех агентов были строго одинаковые веса и уровень квантования. Все модели должны быть гомогенны, желательно, чтоб ещё и одна версия (условно если в части основных нод пайплайна у меня Gigachat Про, в части планирующих и верифицирующих Макс, а на роутере Лайт - не прокатит).
2. Инфраструктура:
Стандартные vLLM/TGI из коробки такой шаринг не умеют — нужны кастомные патчи. Stateful-коммуникации тензорами надо решать на уровне инференса, а это уже не коммуналка.

Чеклист: что можно начать делать уже сейчас
Даже без сложного KV-кэша архитектурный паттерн примитивов работает:
- Обернуть частые связки (например, генерация + самокритика) в стандартизированные модули с единым JSON-интерфейсом.
- Разделить логику «исполнения» (примитивы) и «маршрутизации» (Organizer).
- Собирать Knowledge Pool — базу удачных конфигураций для маршрутизатора.

Готовы ли вы в своих системах пожертвовать гибкостью (использовать только одну модель) и усложнить инференс ради 4-кратной экономии токенов? Или пока надёжнее гонять JSON-ы?

Флот агентов: как запустить и не попасть в 40% провальных проектов

Запустили агента → работает в демо → не работает в проде. Знакомо? Если делали ИИ-агентов не на локальном ноуте, а в компании знакомо и больно.

Почему по мнению Gartner проваливаются агентные проекты:

1. Стоимость считают в пилоте, не в проде
Anthropic engineering blog: multi-agent система потребляет ~15× больше токенов, чем обычный чат. Добавь к этому retry (в проме очередь может быть заполнена, а какой-нибудь сервис смежников может лежать или быть занят), оркестрацию, логирование — cost per task в таком случае кратно растёт (кто пробовал OpenClaw и подобное не дадут соврать - жрет непомерно много токенов).

2. Innovation Theater
Демо блестит. Но:
1) Нет метрик успеха.
2) Нет даты перехода в прод.
3) Пилот вечно в статусе «изучаем».

3. Underspecification
Агент не угадывает — галлюцинирует в логике: врёт максимально правдоподобно для массовки, но те кто шарит в контексте вопроса сразу увидят проблемы.

Три архитектурных паттерна из исследований Garther, когда что брать:

1) Hierarchical (оркестратор → воркеры)
Этакий начальник строит план → раздаёт подзадачи → собирает результат
✅ Детерминирован, легко дебажить, аудит каждого шага
❌ Single point of failure, бутылочное горлышко при росте.
Когда применять: enterprise-процессы с требованиями аудита, надежности, ИБ и тд.

2) Plan-and-Execute (умный планировщик + дешёвые исполнители)
Дорогая модель строит план → маленькие модели исполняют шаги
✅ Дешевле на inference, весь путь виден до первого действия
❌ Ошибка в плане дорого обходится на всех последующих шагах
Когда применять: сложные задачи с предсказуемой структурой — генерация кода, документация, миграции.

3) Swarm (децентрализованные пиры, как в торрент сети)
Агенты равноправны, координируются без оркестратора
✅ Нет single point of failure, гибкое масштабирование
❌ Непредсказуемо, сложно дебажить, нет аудита.
Когда применять: только R&D и генерация гипотез. Не для промышленной среды с требованием воспроизводимости.

Чеклист запуска промышленного агента, который не умрет после 1-го релиза:
☑️ Метрики успеха зафиксированы до старта, не после.
☑️ Посчитан cost per task в проде, и в пилоте тоже был посчитан (но они отличаются, просто сделайте замеры и офигеете).
☑️ Первый workflow собран с автоматически верифицируемым результатом.
☑️ Паттерн был выбран под тип задачи, не под моду (у соседа всегда трава зеленее, но не надо переписывать агентов как у соседа).
☑️ Least-privilege access: агент не получает «доступ ко всему» (в пром таких агентов не пустит ни одна команда ИБ, потому BPMN, RACI-матрица и тд. Потому что агентизация = автоматизация. Процессы, job story и тд)
☑️ Трейсинг был настроен до первого продакшн-запроса (если где-то отвалит на первом запросе вашего агента в проде, то без трейсов будет очень тяжело общаться не то что с SOC, но и со своими разрабами).
☑️ Есть конкретный человек владелец — не «команда технического развития», он "продает" агента на конкретные job story конкретным нанимателям, он несёт ответственность как агент выполняет эти стори.
☑️ Дата перехода из пилота в пром зафиксирована.
Я делал тысячи прототипов в месяц, но до прода доезжали единицы. При этом бизнес уже с пилота прототипа на A/B заявлял об огромных выгодах. Но после A/B когда убирали шум эффектов от остальных инициатив, то видно что реальный эффект приносит автоматизация только 1 из 10 процессов.

Главный инсайт:

Factory AI — 75% PR от агентов одобряются без изменений. Их вывод: «Качество модели менее важно, чем следование лучшим практикам».
Те агента и его ноды программировать надо по лучшим практикам компании, а модель может быть не прорывной, просто дергать написанные (кожаными или другими агентами) разрабами навыки и тулы по API, не через MCP, без ризонинга.
Паттерн разработки в этом случае — это контракт между командой и агентом (или системой хостинга и исполнения агентов).
Менять паттерн разработки в проде многократно дороже, чем выбрать правильно с первого раза.

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

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

Несколько недель проводил эксперименты и зафиналил для себя что для агентских схем типа Claude Code/OpenClaw облачный LLM — это не опция, а база:
1) Килотонны контекста. Даже на простое "Привет" OpenClaw отправляет в модель весь свой манифест и список инструментов (около 10 000 токенов). Локальная карта типа 4070 с окном в 40к токенов "задохнется" уже на 3-4 шаге диалога.
2) Синдром "тупого джуна". Разрыв в интеллекте между стареньким OpenAI GPT-4o и локальной квантованной моделью — это разница между Senior-архитектором и интерном. В агентских задачах, где нужно строить цепочки рассуждений с помощью reasoning, локальные модели типа gpt-oss:20b / qwen3.5:27b часто уходят в бесконечные циклы или галлюцинируют в конфигах.
3) Экономическая иллюзия. Да, электричество дешевле токенов условных OpenAI/Antropic. Но время инженера, который будет фиксить "неведомую хурму" за агентом с локальной моделькой, стоит в разы дороже любой подписки. Да, и сэкономить его ПШЕ нельзя, тк он, внезапно, должен чинить за агентом

Если вы планируете внедрять агентскую автоматизацию, управляйте ожиданиями стейкхолдеров сразу:
1) Пишете агента под конкретную задачу стейкхолдера, хорошего сильного агента, тулы и навыки, но модель у вас может быть локальная или недорогая облачная. Тут затраты типичные для заказной разработки, все ожидаемое и ничего нового.
2) Даете клиенту конструктор типа OpenClaw или промышленного монстра Claude Code и лучшие облачные модели, сопоставимые с задачами этих чудовищ для самонастройки и интеграции в пайплайн, создания субагентов и тд. Тут и вайбкодинг и минимум затрат на смежников, но миллиарды потраченных токенов в день

А как ваши эксперименты с OpenClaw?

Не каждая джоба должна дожить до job story. В последние пару лет компании часто обьявляют об AI-First подходе, когда любая работа должна выполняться агентами, и лишь если ее нельзя агентизировать, то ее должен выполнить человек.

Главная ошибка команд в этих случаях — начинать с БТ или job story, а не с вопроса: это вообще нормальная агентизируемая работа или просто очередная хотелка.
Что с БТ не так? Если начали формировать БТ, значит идея уже прошла отбор и команда пишет требования и подгоняет под агентизацию.
Что с job story не так? Если начали писать job story, значит работа прошла 1 критерий отбора - повторяемость.

В job story должны попадать только те работы, у которых:
- есть повторяемость;
- есть триггер;
- есть понятные входы;
- есть ограниченный результат;
- есть критерии проверки;
- есть baseline метрики и предполагаемый и реалистичный расчет эффекта;
- есть контур автоматизации, где агент будет выполнять работу.

Умереть должны:
- разовые хотелки;
- "сделай умно", "нам бы прототипчик, а там разберемся";
- огромные процессы без границ и детализации каждого шага "потому что так сложилось";
- кейсы без baseline метрик, тк эффект от агентизации неизмерим;
- write-action без прав, подтверждения и аудита, ведь мы не хотим повторить судьбу Replite;
- все задачи, где нельзя однозначно понять, ошибся агент или нет.

Если вы не умеете считать эффект, у вас не backlog и стейкхолдеры, а зеленый дашборд с недоказуемым результатом и кружок фантазеров.

Считать можно одной строкой (на каждую джобу):
Эффект = Частота за отчетный период × Покрытие сценария живого пользователя × Доля использования кейсов которая реально идет через агента × ((AsIs - ToBe - Overhead) - (1 - SuccessRate) × Доработка) / 60 × СтоимостьЧаса - OPEX
Где:
- AsIs — ручное время сейчас;
- ToBe — время с агентом (маршрутизация сообщения или триггера + классификация запроса + планирование + вызов навыков + работа в среде исполнения + валидация + подготовка ответа + апрув и тд);
- Overhead — разметка, проверка, ревью, апрув от человеков (мало кто вообще считает эти затраты, а они очень неприличные);
- SuccessRate — доля успешных прогонов (мерить надо не на тесте, а на препроме и на проме с боевым пайплайном и моделями);
- Доработка — ручная переделка после фейла.

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

Сильный вопрос не «какую бы еще job story придумать?»
Сильный вопрос — «какая повторяющаяся работа уже созрела настолько, что достойна стать job story?»
Если джоба на это не отвечает — ей пора умереть.

Пу-пу-пу 🙈

С 15 апреля 2026 Qwen Code полностью отключил Free Tier через OAuth, а до этого лимит уже урезали с 1000 до 100 запросов в день.
Если у вас сегодня внезапно всплыло сообщение “выполните /auth”, это не баг IDE и не деградация Qwen 3.6 Plus а смена модели доступа к провайдеру.
Так что если вы гоняли RooCode или KiloCode поверх Qwen Code CLI в VS Code то проблема не в них и надо менять провайдера модели