Как заставить дешёвую LLM думать как топовая: протокол вместо мощности

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

Мы проверили это на практике: попросили топ-модель написать протокол собственного мышления так, чтобы модели попроще исполняли его шаг за шагом. Получился скилл Fable Mind — 6 фаз с обязательными контрольными точками. С ним Sonnet на диагностике инцидентов и правках боевого сервера работает близко к топ-уровню, расходуя примерно в 5 раз меньше.

Почему дисциплина бьёт сырую мощность

Сырая мощность угадывает, дисциплина проверяет. Модель не обязана быть умнее — она обязана быть строже.

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

Шесть фаз протокола

Фазы идут по порядку, контрольные точки не пропускаются.

• Фаза 1. Намерение и критерий готовности. Одним предложением сформулировать, чего человек хочет на самом деле. Затем проверяемый итог: «готово = такой-то артефакт лежит там-то и проверен так-то». Если разумных трактовок две и больше — один уточняющий вопрос до работы.
• Фаза 2. Факты до мнений. Документация, память и комментарии устаревают. Любое утверждение о системе проверяется чтением её реального состояния: файл, журнал, база, живой процесс. Каждый факт — с доказательством: команда и её вывод, строка кода, результат запроса. Без доказательства это мнение, и помечается оно как мнение.
• Фаза 3. Минимум две гипотезы. Если в голове одна версия причины, второй назначается «моя версия неверна, совпадение случайно». Следующая проверка должна различать гипотезы, а не подтверждать любимую. Неожиданный результат объясняем сразу, до следующего шага.
• Фаза 4. Действия с обратимостью. Резервная копия и путь отката — до правки. Перед необратимым (удаление, деньги, отправка людям) — стоп-проверка из трёх вопросов: доказательства подтверждают именно это действие? что сломается, если я неправ? как откатить и за сколько?
• Фаза 5. Самопроверка перед ответом. Что бы меня опровергло — я это проверил? Числа пересчитаны из источника, единицы сходятся? Каждое утверждение откалибровано: «проверил», «предполагаю, потому что…», «не знаю». Выдать предположение за факт — худший провал протокола.
• Фаза 6. Ответ. Вывод первым, доказательства после. Факты отдельно от толкований. Нерешённое и риски — явно, отдельным блоком: спрятанный хвост стреляет через неделю, когда о нём все забыли.

Списком фазы выглядят самоочевидными. Разница видна в работе, поэтому ниже — все 6 фаз с примерами: как модель ведёт себя без правила и с ним.

Фаза 1 — намерение и критерий готовности

Запрос: «скрипт выгрузки падает, почини». Модель без протокола сразу пишет код — и заодно перерабатывает половину скрипта под свои представления о прекрасном. Через 20 минут у вас другой скрипт, и падает он в новом месте.

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

Критерий готовности кажется бюрократией до первого случая, когда агент отчитался «сделал», а артефакта нет. «Готово» без проверяемого артефакта — просто слово в отчёте.

Фаза 2 — факты до мнений

Запрос: «бот перестал отвечать в чате». Без правила модель открывает README, находит там схему работы и отвечает: «судя по документации, дело в токене — обновите его». README написан полгода назад. Бот молчит, потому что диск переполнен и система убила процесс.

С правилом модель начинает с живого состояния: статус процесса, последние 50 строк журнала, время последнего успешного ответа. И вставляет доказательства прямо в ответ: команда, её вывод, «процесс мёртв с 14:02, в журнале — no space left on device». Для утверждений без доказательства у неё есть обязательная пометка: «предполагаю».

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

Фаза 3 — минимум две гипотезы

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

С правилом до первой проверки на столе лежат две версии. H1: парсер упал. H2: парсер жив, изменились входные данные. Различающий тест: журнал парсера за время платежа. Обрабатывал другие письма в этот час — H1 отпадает за одну проверку, полчаса сэкономлены. Рабочий вопрос из скилла: «какой результат заставит меня отбросить мою версию?»

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

Фаза 4 — действия с обратимостью

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

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

Четвёртый пункт фазы — взгляд по сторонам: что ещё трогает это изменение? Перезапуск службы, от которой зависит соседний процесс; кэш, который ещё час отдаёт старое; ночная задача по расписанию, которая перезапишет правку. Минутная проверка «сосед не упал?» снимает целый класс сюрпризов следующего утра.

Фаза 5 — самопроверка перед ответом

30 секунд перед отправкой. Вопросы к себе: что бы меня опровергло — проверено ли это? числа пересчитаны из источника, единицы сходятся? какую аномалию я объяснил удобной версией, но не проверил? в каком месте скептик спросит «с чего ты взял?» — и стоит ли там доказательство или оговорка.

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

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

Фаза 6 — ответ

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

Второе требование — нерешённое отдельным блоком, без слияния с фактами. Хвост, названный в отчёте, стоит одну строку. Скрытый хвост стоит новую диагностику через неделю-две, когда контекст потерян и разбирательство начинается заново.

Провалы, из которых протокол вырос

Антипаттерны в скилле собраны из реальных случаев нашей работы. Пять показательных.

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

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

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

Четвёртый: знакомый алерт со знакомым, но неверным диагнозом. Мониторинг присылал сообщение «система залипла, нужен перезапуск» — текст совпадал с прошлыми случаями, и рука сама тянулась к рестарту. Проверка живого состояния показала: система работала, алерт был ложным срабатыванием с тем же текстом. Отсюда правило фазы 3: знакомый симптом не равен знакомой причине; перед диагнозом по паттерну спроси, что ещё даёт такую же картину.

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

Экономика: где протокол закрывает разрыв, а где нет

Токен топ-модели стоит примерно в 5 раз дороже токена средней из той же линейки. Для агента, который работает потоком — десятки сессий в день, — выбор модели превращается в заметную строку расходов, и «гоняем топ на всё» перестаёт быть нейтральным решением.

Грубая арифметика для потока: 100 задач в неделю, из них сложных — 15-20. Если топ-модель берёт только их, а остальные 80 закрывает средняя с протоколом, счёт за токены падает примерно втрое против режима «всё на топе». Качество рутинной части при этом не проседает: процессные проверки от размера модели не зависят.

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

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

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

Как написать такой протокол под себя

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

Соберите 10 последних фейлов вашего агента или ваших сессий с LLM. Источники: история чатов, тикеты, откаты в git, сообщения вида «ты же писал, что готово». Формат — одна строка на фейл: что просили, что модель сделала, где разошлось.

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

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

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

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

Держите ядро коротким. 10-15 правил модель читает и исполняет; протокол на 5 страниц — уже литература. Новые фейлы дописывайте в раздел антипаттернов с датой и одной строкой сути: со временем этот раздел становится самой ценной частью файла, потому что в нём — карта граблей вашей конкретной системы.

Как внедрить у себя

Понадобятся два слоя.

Первый — скилл-файл. Протокол оформляется отдельным SKILL.md с коротким описанием-триггером («применять при диагностике багов, действиях на боевом сервере, финансовых расчётах») и телом из шести фаз. В Claude Code такой файл кладётся в папку скиллов, и модель подхватывает его по команде или сама, когда задача подходит под триггер.

Второй — «всегда включено». Скилл, который надо вызывать руками, легко забыть. Поэтому выжимка ядра — пять-семь строк про факты с доказательствами, две гипотезы, проверку результата и калибровку «знаю/предполагаю» — вшивается в постоянные инструкции: в CLAUDE.md проекта или в системный промпт вашего агента. Тогда протокол работает в каждой сессии, включая фоновые и автоматические. Протокол не привязан к вендору: это обычный текст, для GPT-инструментов и Codex он читается через AGENTS.md.

И оговорка, без которой протокол начнёт раздражать: в нём прописано, когда его НЕ применять. Справочный вопрос, тривиальная правка, команда с очевидным результатом — ответ сразу, без ритуала. Раздувать простое — такой же провал, как комкать сложное.

Проверка, что протокол работает

Слои поставлены — теперь три проверки, что модель их подхватила.

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

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

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

Типовые возражения

«Это же просто промпт». Да, и в этом сила: обычный текст без привязки к вендору переносится между инструментами — Claude Code, Codex, самописный агент поверх API. От мотивационного «думай шаг за шагом» его отличают два свойства: правила выведены из задокументированных фейлов, и в них зашиты проверяемые действия. «Будь внимательным» модель сглаживает до фонового шума, «прочитай результирующее состояние после правки» — выполняет.

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

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

«Проверки замедлят простые задачи». Для того и существует секция «когда НЕ применять»: справочный вопрос и тривиальная правка идут без ритуала. Замедление остаётся на сложных задачах — и там оно окупается: непроверенная правка на живой системе обходится дороже трёх лишних минут на чтение журналов.

Где взять готовый файл

Собранный SKILL.md — шесть фаз, шаблон рабочих заметок и антипаттерны — лежит в клубе Solar Inside: club.4bos.ru. Выжимку «всегда включено» для постоянных инструкций соберёте из него за пять минут — ядро протокола умещается в несколько строк. Там же разборы остальных наших скиллов и систем автоматизации — от контент-конвейера до ночного агента, который сам закрывает задачи из бэклога. Забирайте файл, кладите в свой проект и дописывайте антипаттерны из собственных провалов: именно они делают протокол живым.