Навык unlazy и метод Depth Tree для агентов

Для чего нужен навык unlazy

Навык unlazy — это агентский навык, созданный для предотвращения одной ошибки: когда агент по написанию кода сообщает о выполнении задачи до того, как она фактически завершена. Его основа — Depth Tree, метод разделения задачи по её реальным границам, где каждый конечный узел имеет собственные критерии приёмки. В версии 2 принудительное выполнение перенесено из текстовых описаний в файлы, поэтому агент должен доказывать завершение работы с помощью списка исполняемых команд, а не просто утверждать его.

Навык опубликован пользователем Leonxlnx на github.com/Leonxlnx/unlazy под лицензией MIT. В репозитории нет помеченных релизов, которые можно было бы зафиксировать: по состоянию на 2026-10-11 списки тегов и релизов пусты. Данное руководство было впервые написано для версии 2.0.0, датированной 2026-08-10. 2026-10-11 мы повторно проверили его на актуальном исходном коде из ветки main. В CHANGELOG этот код помечен как "Unreleased, target 2.1.0", при этом указано, что Git-тег или GitHub Release для 2.1.0 отсутствуют. Запуск команды установки сегодня загрузит именно этот новый код, а не 2.0.0. Навыки в этой области быстро меняются, поэтому ознакомьтесь с CHANGELOG репозитория, прежде чем внедрять что-либо из этого в рабочую среду.

Навык здесь означает стандартный объект: файл SKILL.md, который среда выполнения (harness) загружает в контекст модели, если задача соответствует его описанию. Если этот механизм вам в новинку, начните с что такое агентский навык и как среда выполнения его загружает. unlazy представляет собой обычный markdown и несколько скриптов Node, поэтому ему не требуется сервер или собственный API key.

Почему агенты останавливаются на 80 процентах и игнорируют третью инструкцию

Это поведение имеет узнаваемую форму. Вы запрашиваете четыре вещи. Ответ охватывает первую, вторую и четвертую. Итоговое резюме перечисляет все четыре как выполненные. Ошибок не возникло, поэтому система ничего не пометила, и вы обнаруживаете пропуск спустя неделю.

Документация unlazy README обосновывает это опубликованными исследованиями лени моделей. В ней приводится ссылка на arXiv 2512.20662, где установлено, что «детализированные многосоставные промпты по-прежнему приводят к частичному выполнению и преждевременному усечению в протестированных моделях». В справочных материалах по шлюзам (gates) проектная предпосылка изложена прямо: «Приведенные выше правила — это проза, а проза — это уровень, который данный проект уже считает самым слабым». Призыв к агенту «постараться сильнее» — это еще больше прозы, добавленной в тот же контекст, который привел к невыполнению задачи.

Именно поэтому версия 2 хранит свое состояние в файлах. Флажок в GATES.md находится вне зоны усмотрения модели. Либо под шлюзом есть подтверждающие данные, либо их нет, и скрипт может сообщить вам об этом без обращения к агенту.

Дерево глубины, слой за слоем

Дерево глубины — это декомпозиция с правилом, определяющим места допустимых разделений. Из справочника по методу:

Разделяйте только на границах реальных доменов, компонентов или верификации. Бинарные разделения опциональны.

Сделайте слой 1 запрошенной задачей.

Листья содержат результаты работы. Каждый слой над ними интегрирует и проверяет то, что возвращают его дочерние элементы.

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

Сделайте каждый лист одним связным результатом.

Объединяйте крошечные соседние листья; разделяйте лист, который скрывает несколько независимых результатов.

Это правило не дает глубокому дереву превратиться в имитацию бурной деятельности. Если лист гласит «переименовать переменную», он не проходит проверку, а разделение над ним зашло на один слой слишком далеко.

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

Вы выбираете глубину при вызове навыка:

/unlazy tree 5 refactor the payment module

Простой язык тоже работает, так как описание навыка сопоставляется с намерением, а не с командой через слэш:

tree 3 build the landing page and do not stop until every gate is checked

В ранних версиях этого руководства приводились диапазоны глубины с количеством листьев для каждого уровня. В текущем справочнике по методу количество листьев не указано вовсе, и там сказано: «Не рассматривайте глубину как арифметическое обещание относительно усилий или токенов». Осталось только качественное руководство: «Используйте неглубокое дерево или одиночный реестр для функции, локализованного поиска ошибки или документа». Оркестрованное дерево предназначено для случаев, когда несколько связных результатов выигрывают от свежих контекстов или независимого владения. Более глубокое дерево оправдано только тогда, когда его дополнительные ветви соответствуют реальным границам интеграции.

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

Как выглядит файл шлюзов (gates file)

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

# Gates: pricing section

- [ ] G1: three tiers render with real copy
  CHECK: node check.js pricing --tiers
  EXPECT: 3/3 tiers ok
  EVIDENCE: pending

- [ ] G2: annual toggle changes both price and label
  CHECK: node check.js pricing --toggle
  EXPECT: toggle ok
  EVIDENCE: pending

CHECK — это команда. EXPECT — это вывод, который считается успешным; для успеха также требуется, чтобы команда завершилась с кодом 0. EVIDENCE начинается с pending. После успешного выполнения проверяющий заполняет его отпечатком вывода (fingerprint) вместо исходного текста. Ручной шлюз не имеет команды, поэтому для него фиксируется минимальный факт, подтверждающий результат. Инструмент scripts/gate-check.mjs поставляется для выполнения этой задачи. С помощью --status он сообщает, какие шлюзы остаются открытыми, не запуская команды и не изменяя файлы, что позволяет провести аудит выполнения без чтения транскрипта. Он запускает команды реестра только при передаче --approve, поэтому изучите каждую команду и каждый скрипт, который она вызывает, прежде чем запускать его. Отдельный инструмент scripts/gate-lint.mjs проверяет качество реестра, ничего не запуская.

Правило отчетности в SKILL.md умещается в одну строку:

Не составляйте отчет о завершении, пока какой-либо обязательный шлюз не выполнен, заброшен, отложен или ожидает решения владельца.

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

Пишите шлюзы так, чтобы их мог запустить посторонний человек. «Выглядит хорошо» — это не проверка. test -s dist/index.html && echo ok, выводящий ok, является проверкой, так как он явно завершается ошибкой при пустом или отсутствующем файле.

Контракт PLAN.md перед началом параллельной работы

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

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

В режиме оркестрации драйверу дается указание: «Предоставьте каждой ветви только общий контракт, её точную зону ответственности и зависимости, её собственный реестр» и «не допускайте утечки историй других ветвей». Реестр каждой ветви объявляет пути, в которые она может записывать данные, и эти OWNS пути не должны пересекаться с путями любой другой ветви, запущенной в то же время. Когда субагент возвращает результат, драйвер должен «повторно запустить исполняемые проверки ветви, включая уже пройденные», потому что одного --status недостаточно для повторной верификации. Ветвь, чьи пункты были отмечены без реальных доказательств, не пройдет такую повторную проверку.

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

Как установить навык unlazy?

Поддерживаемый способ — использование CLI для навыков:

npx skills add Leonxlnx/unlazy

Добавьте -g для установки на уровне пользователя или --all для каждого агента, обнаруженного CLI. Эта команда устанавливает текущую версию из ветки main. Тегированных релизов нет, поэтому в README рекомендуется зафиксировать конкретный коммит, если вам нужна установка, которая не изменится в будущем.

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

git clone https://github.com/Leonxlnx/unlazy ~/.claude/skills/unlazy

git clone https://github.com/Leonxlnx/unlazy ~/.codex/skills/unlazy

Затем проверьте, что установка прошла успешно:

ls ~/.claude/skills/unlazy/SKILL.md

Вывод пути означает, что файл находится на диске. No such file or directory означает, что клонирование произошло в другое место, обычно из-за того, что директория навыков не существовала под тем именем, которое вы предполагали, и git создал новую. Не полагайтесь только на отчет агента. Агент, который сообщает об установке навыка, не показывает вам сам файл. Для работы программы проверки и опционального хука требуется Node 16 или новее; сторонние пакеты среды выполнения не используются.

По состоянию на 2026-10-11 в README описаны два инструмента: Claude Code, где вы вызываете навык командой /unlazy, и Codex CLI, где используется $unlazy. В документации не указаны способы работы с инструментами без загрузчика навыков, поэтому вставка содержимого SKILL.md в файл правил другого инструмента не тестировалась. Если вы хотите узнать, что именно обеспечивает надежную загрузку SKILL.md, в разделе написание собственного навыка агента рассматриваются frontmatter и соответствие описания, которые определяют, будет ли навык запущен.

Работает ли Stop hook вне Claude Code?

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

node <path-to-skill>/scripts/install-hooks.mjs            # this project only (settings.local.json)
node <path-to-skill>/scripts/install-hooks.mjs --global   # every project
node <path-to-skill>/scripts/install-hooks.mjs --uninstall

Stop hook срабатывает в тот момент, когда агент пытается завершить свой ход. Он сканирует журнал текущей сессии и состояние диспетчеризации, блокируя остановку, если условия (gates) не выполнены, поэтому ход не может завершиться при наличии неотмеченных пунктов. Он не выполняет сами проверки и не делает собственных вызовов модели. Однако это не бесплатно. В описании токеномики указано: «Блокировка вызывает продолжение работы агента, что потребляет ресурсы модели». Общие сведения о механизме и других событиях, к которым можно привязаться, см. в как срабатывают хуки Claude Code во время хода. README рекомендует устанавливать хук только с согласия пользователя. Также рекомендуется добавить .claude/settings.local.json, .unlazy/ и .unlazy-hook-state.json в правила игнорирования.

У него есть предохранительный клапан, что важнее, чем кажется на первый взгляд. Если агент не продвигается в прохождении условий в течение шести последовательных заблокированных остановок, хук освобождает его вместо того, чтобы удерживать, а правки, затрагивающие только метаданные, не сбрасывают этот счетчик. Строка ABANDON: <gate> <reason> также позволяет завершить сессию, но как явную передачу управления, а не как успешное завершение. Брошенное условие помечается как неуспешный результат, а не как выполненная работа. Без этих двух способов выхода условие, которое невозможно выполнить в вашей среде, приводило бы к сжиганию токенов до тех пор, пока вы сами не завершите сессию.

В Codex или любой другой среде для install-hooks.mjs некуда встраиваться, так как он записывает только файлы настроек Claude. Вы по-прежнему получаете файл условий и исполняемые проверки, но нет структурных механизмов, мешающих модели завершить ход раньше времени. В этом случае файл условий — это просто документ, который вам нужно прочитать самостоятельно.

unlazy или ponytail: что выбрать?

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

ponytail заставляет агента вести себя как старший разработчик, который первым делом спрашивает, нужно ли вообще писать этот код. Он сокращает область задач, отдает предпочтение стандартной библиотеке и уменьшает размер diff. unlazy исходит из того, что область задач уже согласована, и направляет усилия на то, чтобы каждая часть была завершена и проверена.

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

Можно использовать оба навыка, но важен порядок. Сначала определите область задач с помощью вопроса ponytail, а затем передайте согласованный объем работы в механизмы unlazy. Если сделать наоборот, вы построите дерево решений для работы, которую ponytail удалил бы, и потратите лишние ресурсы на всё это. Этот порядок — моя рекомендация, а не задокументированная интеграция между двумя проектами.

Что означает параметр глубины (depth) для агента на VPS?

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

В ранних версиях этого руководства приводились множители выходных токенов и затрат, основанные на сравнении шести запусков, проведенном авторами. С тех пор авторы отозвали эти цифры. В файле references/token-economy.md теперь указано, что исходные промпты, трассировки, выходные данные и записи оценок отсутствуют в репозитории, «поэтому эти цифры здесь невозможно воспроизвести», и добавлено: «Не используйте их в качестве гарантий продукта». В справочнике по методологии сказано еще более определенно: «Не рассматривайте глубину как арифметическое обещание относительно усилий или токенов». Мы удалили эти цифры, чтобы не повторять данные, от которых отказались сами авторы.

То, что в справочнике все еще говорится о затратах, носит рекомендательный характер. В начале документа советуют: «Переносите повторяющуюся, детерминированную проверку в команды и сохраняйте контекст оркестрации узким». Режим solo расходует дополнительные выходные токены в рамках одного контекста. Режим orchestrated добавляет новые контексты, и каждый новый контекст перед выполнением полезных действий считывает контракт и собственный журнал. Справочник предостерегает в обоих случаях: «Не оркеструйте задачу, которую можно реализовать и проверить в рамках одной сфокусированной сессии». Также не рекомендуется держать всю сборку в одном контексте только ради того, чтобы избежать накладных расходов на субагентов, если структура листьев и контрактов ясна.

Из этого следуют четыре настройки:

• Выбирайте минимальную глубину, при которой листья являются реальными единицами работы, а затем останавливайтесь. Глубина, которая вам не нужна, — это лишние расходы.
• Оставайтесь в режиме solo, если задачу можно построить и проверить в рамках одной сфокусированной сессии, так как настройка субагента стоит дороже, чем выгода от нового контекста.
• Установите хук Stop, если используете Claude Code. Сам хук не выполняет вызовов модели, но каждый блок возвращает агента к работе, а эта работа оплачивается.
• Установите жесткий лимит расходов на уровне аккаунта перед запуском любых длительных процессов.

Последний пункт — самый важный. Инструмент, разработанный так, чтобы отказываться от ранней остановки, по своей сути является инструментом, который продолжает работать. Бюджетирование и оповещения — это задача, отдельная от написания промптов, и в разделе контроль расходов агента на VPS описаны лимиты, которые стоит внедрить в первую очередь.

Что измеряли авторы и что это доказывает

Ранее в репозитории публиковался собственный тест, что встречается реже, чем следовало бы. Впоследствии от этого теста отказались, что встречается еще реже. В README теперь указано лишь то, что «предыдущие версии README также ссылались на внутреннее сравнение по результатам шести запусков» и что «исходные артефакты, необходимые для воспроизведения этих точных коэффициентов и показателей, в данном репозитории отсутствуют». Рекомендация авторов: «Рассматривайте эти результаты как исторические данные для проектирования, а не как гарантированные показатели производительности».

Методика тестирования сохранилась в research/validation-protocol.md: две задачи сборки, по три условия для каждой (без навыка, дерево 3, дерево 6), а также создание новой папки и сессии для каждого запуска. В протоколе это названо «исследовательским сравнением, проведенным сопровождающим». Там указано, что полученные коэффициенты токенов, количество самостоятельно найденных дефектов, а также ошибки в количестве отчетов и сбоев в реальном времени невозможно воспроизвести или проверить на основе содержимого репозитория. Также подчеркивается, что данное сравнение нельзя описывать как доказательство того, что unlazy вызывает конкретное улучшение или множитель затрат. В предыдущих версиях этого руководства приводились графики с результатами по каждому запуску. После того как авторы отозвали эти данные, мы их удалили.

Один урок проектирования оказался важнее цифр. Правило «перепроверять каждое число и утверждение о завершении непосредственно перед публикацией» по-прежнему содержится в SKILL.md, а шаблон gates предостерегает от копирования предоставленного числа в EXPECT в качестве собственного доказательства. Уверенное резюме, основанное на нерабочей сборке — это именно то, на предотвращение чего направлены gates.

Теперь об ограничениях. По состоянию на 2026-10-11 не осталось опубликованных результатов для оценки, есть только методика и протокол для надлежащего повторного тестирования. Проверьте это на своей работе: выполните одну и ту же задачу дважды — один раз в обычном режиме, а второй раз с файлом gates, затем подсчитайте количество закрытых gates, подкрепленных доказательствами, которые вы можете воспроизвести самостоятельно. Это число — единственный показатель в данной области, который имеет отношение лично к вам.

FAQ

Что такое Depth Tree в навыке unlazy?

Это метод декомпозиции. Задача разбивается только на реальных границах домена, компонента или проверки. Уровень 1 — это запрошенная задача, а каждый лист — это целостный результат с собственными контрольными точками (gates). Мелкие соседние листы объединяются, а лист, скрывающий несколько независимых результатов, разбивается снова. Каждый уровень над листьями выполняет интеграцию и проверку: он повторно проверяет дочерние элементы, а затем запускает интерфейсные, сквозные (end-to-end) и регрессионные тесты. Вы выбираете глубину при вызове, например tree 5. Если глубина не указана, навык выбирает минимальное дерево, которое раскрывает каждый независимый результат и точку интеграции.

Работает ли навык unlazy вне Claude Code?

Частично. Навык представляет собой обычный markdown, а README описывает использование Codex CLI наряду с Claude Code, поэтому Depth Tree, файл с контрольными точками, исполняемые проверки и четыре прохода на каждый лист там работают. Текущая документация не охватывает другие инструменты. Механизм принудительного исполнения отличается. Хук Stop, который блокирует завершение хода, пока контрольные точки не пройдены, является функцией Claude Code, устанавливаемой с помощью node <path-to-skill>/scripts/install-hooks.mjs. В других средах ничто структурно не мешает модели завершить ход раньше времени, поэтому вы сами читаете файл с контрольными точками и отправляете его обратно.

Насколько навык unlazy увеличивает расход токенов?

На сегодняшний день никто не может назвать точную цифру. Ранние соотношения токенов, полученные авторами, основаны на шести запусках, которые невозможно воспроизвести. Текущая документация гласит, что их нельзя использовать как гарантии продукта и не стоит рассматривать глубину как арифметическое обещание относительно усилий или токенов. Направление всё ещё ясно. Режим Solo добавляет вывод в рамках одного контекста. Режим Orchestrated добавляет новый контекст для каждого листа, который перед началом работы считывает контракт и журнал (ledger). Хук Stop не делает собственных вызовов модели, но каждый блок возвращает агента к работе. Оценивайте расход на своей собственной задаче и по своему счёту.

Что использовать: unlazy или ponytail?

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

Почему мой агент всё равно останавливается раньше времени после установки unlazy?

Проверьте четыре момента. Во-первых, убедитесь, что навык находится на диске, используя ls ~/.claude/skills/unlazy/SKILL.md, так как клонирование в несуществующую директорию — частая ошибка. Во-вторых, убедитесь, что файл с контрольными точками был создан до начала работы, так как хук сканирует журнал сессии, и при отсутствии GATES.md ему не на чем блокировать выполнение. В-третьих, проверьте, где был установлен хук: обычный запуск install-hooks.mjs записывает данные только в settings.local.json текущего проекта, поэтому для другого проекта потребуется --global. В-четвёртых, помните, что предохранительный клапан работает согласно проекту. Шесть последовательных заблокированных остановок без прогресса по контрольным точкам освобождают агента, а строка ABANDON: <gate> <reason> намеренно завершает попытку как видимую передачу управления, которая не является успешным завершением.