Два разных события: предложить и применить
Главная граница проходит не между ручным и автоматическим авторством, а между proposal и live-версией. Разбор прогона может свободно подготовить предложение, но до применения оно остаётся отдельным артефактом: целевой skill, основание, полный diff, базовая ревизия, результаты проверок и план отката.
Это закрывает два класса отказа одновременно. Слабый урок не попадает в следующие сессии до проверки, а хороший proposal не накладывается на файл, который успели изменить после анализа.
Evidence до proposal
Сам факт длинного или успешного прогона ничего не доказывает. Кандидат оправдан, когда:
- можно показать, что именно существующий skill реально использовался;
- находка повторяема или устраняет тяжёлый отсутствующий контракт;
- изменение уберёт хотя бы два будущих шага модели или инструмента;
- причина не сводится к routine success, одноразовому случаю, временной ошибке зависимости, общему совету или секрету.
Нормальный результат review — воздержаться. Иначе петля оптимизирует skill под шум последнего запуска (Harness Optimization).
Единица меньше умения: норма с уверенностью и областью
Вся механика выше работает над skill как над единицей выпуска. У этого есть неудобное следствие: между наблюдением в одном прогоне и целым умением лежит пропасть, и разбору приходится либо копить наблюдения до появления материала на полноценный skill, либо выпускать умение из одного случая.
Промежуточная единица закрывает разрыв — атомарная норма: один триггер, одно действие. «Когда пишешь новую функцию — предпочитай функциональный стиль». Она не претендует на процедуру, её нельзя вызвать и она не потребляет отдельный слот; это запись с полями, а не документ.
Три поля делают её пригодной для накопления:
- уверенность — величина, а не флаг, и с определённым поведением на каждом уровне: низкая норма предлагается, но не применяется; средняя применяется, когда уместна; высокая применяется без подтверждения. Она растёт от повторного наблюдения и от отсутствия поправки и падает от явной поправки пользователя и от того, что норма давно не встречалась;
- область — проект или все проекты, по умолчанию проект. Это не удобство раскладки, а защита от того же дефекта, что и в Agent First Repository: соглашение одного репозитория, попавшее в общий слой, начинает применяться там, где оно неверно, и обнаруживается это нескоро;
- доказательства — какие наблюдения породили норму, прямо в теле записи.
Повышение области формулируется перечислимым критерием, а не суждением: та же норма встретилась в двух и более проектах при высокой средней уверенности. Критерий здесь честнее любого «выглядит универсальным»: универсальность проверяется встречаемостью, а не тем, как норма звучит.
Вторая независимая реализация приходит к перечислимому критерию по другой оси: для командных уроков это не число проектов, а число людей и время — уверенность не ниже 0,90, не меньше пяти голосов «за», не меньше двух участников, возраст не меньше двух недель. Оси не конкурируют, а отвечают на разные вопросы: проекты проверяют, что норма не частное соглашение одного репозитория, люди — что она не частная привычка одного человека, возраст — что она пережила хотя бы одно столкновение с практикой. Там, где конфигурацию делят люди, а не проекты, вторая ось важнее первой.
Кластеризация набравшихся норм в умение остаётся отдельным событием с отдельным запуском — и дальше идёт через весь порядок выпуска, описанный выше. Норма не превращается в skill сама по себе от роста уверенности; уверенность решает, применять ли её, а не публиковать ли её как процедуру.
Что даёт эта единица сверх бинарного гейта evidence: правило перестаёт быть либо принятым, либо отвергнутым. Кандидат, который сегодня не проходит планку, не выбрасывается и не применяется — он лежит с низкой уверенностью и накапливает или теряет её сам. Планка остаётся на месте, но теперь она отделяет «применять» от «помнить», а не «записать» от «забыть».
Чем собирают наблюдения — и почему это не безразлично
Сбор наблюдений ведут либо детерминированным перехватом событий жизненного цикла, либо самим умением, которое должно сработать по совпадению задачи. Второе дешевле и напрашивается: разбор прогона логично поручить процедуре разбора прогона.
Детерминированная форма подтверждена второй независимой реализацией: хук завершения сессии читает стенограмму и с весами считает прерывания, поправки человека, отклонённые вызовы инструментов и ошибки инструментов; при высоком счёте агенту предлагается оформить урок. Показательна одна деталь: сессия, закончившаяся коммитом, получает понижающий вес — успешный исход служит признаком того, что трение было рабочим, а не дефектом. Сигнал тем самым собирается перехватом событий, а не суждением модели о том, было ли трудно.
Ошибка здесь не в полноте, а в смещении выборки, и это вывод сопоставлением, а не утверждение источника. Вероятностный сборщик теряет не случайные прогоны, а те, где он сам не сработал, — то есть ровно те, где что-то пошло не так с распознаванием задачи. Материал для обучения собирается по успешным прогонам механизма, который и надо чинить, и петля улучшения систематически не видит собственный основной дефект.
Ownership — это граница автономии
creator, owner и право изменить артефакт — разные вещи. Практичный fail-closed default: неизвестный, пользовательский и импортированный skill считаются user-owned. Агент может подготовить proposal, но не применять его автономно. Auto-apply допустим только для явно machine-owned пространства с отдельной политикой и квотой.
Такой default важнее эвристики по Git author: история помогает расследовать происхождение, но не является ACL.
Proposal привязан к точной версии
Минимальная связка: target + base_hash + proposal_revision + diff. Если target изменился, старый proposal становится stale; его нельзя молча домержить и считать прежним решением. Нужны новый diff, повторная проверка и новое подтверждение (Approval Path).
Подтверждение относится именно к этой ревизии proposal. Согласие на идею «улучшить skill» не является согласием на любой последующий текст.
Проверка до и после применения
Контроль состоит из разных ворот:
- fresh-context RED показывает наблюдаемый пробел без нового текста;
- структурный валидатор и security scanner блокируют повреждённый или опасный артефакт;
- fresh-context GREEN проверяет тот же сценарий с новой версией;
- regression/trigger corpus ловит побочные маршрутизационные изменения.
Scanner проверяет ограниченный класс угроз, а не правильность совета. Прошедший scanner skill всё ещё может быть неверным или чрезмерно общим.
Отложенная оценка как условие приёмки правки
У ворот выше есть пробел, который заметка сама же и называет двумя разделами ниже: внешний улучшатель «оптимизируется под последний случай». Ворота RED/GREEN проверяют тот самый сценарий, ради которого правку и предложили, — то есть меряют по задаче, на которой учились. Улучшение там гарантировано почти по построению, и оно ничего не говорит о всех остальных случаях.
Систематический ответ на это уже сформулирован в исследовании, и формулировка стоит того, чтобы её перенять целиком: умение — это внешнее состояние замороженного агента, и обучать его надо с той же дисциплиной, которая делает воспроизводимой оптимизацию весов. Отсюда устройство: отдельная модель-оптимизатор превращает оценённые прогоны в ограниченные правки одного документа — добавить, удалить, заменить, — и правка принимается только если строго улучшает отложенную проверочную оценку.
Три стабилизатора оттуда же, и все три — прямые заимствования из оптимизации весов:
- текстовый бюджет шага — сколько документа вообще разрешено изменить за одну итерацию, аналог скорости обучения;
- буфер отклонённых правок — чтобы одна и та же неудачная правка не предлагалась заново каждый круг;
- медленное обновление по эпохам поверх быстрых шагов.
Эксплуатационное свойство, из-за которого приём вообще применим: на исполнении это не стоит ничего — оптимизация происходит заранее, а в прод уезжает обычный документ, без единого дополнительного вызова модели. Цена целиком в обучении.
Вес свидетельства здесь заметно выше остального в этой области: шесть наборов задач, семь целевых моделей, три разные обвязки исполнения; метод лучший или равный во всех 52 проверенных сочетаниях и обходит и рукописные умения, и одноразовую генерацию, и четыре конкурирующих оптимизатора. Прирост к варианту без умения на одной из моделей — порядка двадцати пунктов в каждой из трёх обвязок. Отдельно проверен перенос: оптимизированное умение сохраняет ценность при переходе между масштабами моделей, между обвязками и на соседнюю задачу без повторной оптимизации.
Практический вывод для наших ворот: RED/GREEN оставляем как проверку на отсутствие регресса, но право принять правку отдаём отложенному набору, которого предлагающий не видел. Иначе контроль остаётся контролем формы, а не пользы.
Цикл без хорошего оракула идёт назад, и это измерено
Предыдущий раздел описывает, как надо. Цена вопроса видна из того, что происходит, когда проверочный набор плох, — и здесь есть редкий жанр: команда опубликовала отрицательный результат собственного эксперимента цифрами.
- базовая линия без умений — 53%;
- товарный оптимизатор, работающий против собственного синтетического проверочного набора, — 45%, то есть хуже, чем не делать ничего;
- их собственный алгоритм: 28,86% одним запуском и 64% другим.
Разброс между запусками тут важнее самих значений: один и тот же алгоритм, разница больше чем вдвое, и метрика на мешке слов этого разброса не показывала. Вывод авторов — судьба самоулучшения решается дизайном проверочного набора, а не выбором оптимизатора; исследование выше приходит к тому же с другой стороны, называя своей отправной точкой то, что существующие подходы «надёжно не улучшают собственную стартовую точку под обратной связью».
Отсюда порядок осмотра при выборе готового оптимизатора: сначала смотреть, против чего он принимает правки, и только потом — как он их порождает. Синтетический проверочный набор, порождённый той же моделью, — это фикстура, которая удобнее боевого вызова: она согласится почти со всем, потому что сделана из того же материала.
Две оговорки о цене, без которых приём выглядит дешевле, чем он есть:
- стоимость оптимизации кратно превышает стоимость самих прогонов — порядок величины от десяти до ста раз, потому что каждая итерация требует новых оценённых траекторий;
- сбивается это разделением ролей учитель — ученик: эволюционировать на сильной модели, исполнять на дешёвой. Приём законен именно потому, что результат — документ, и перенос между моделями проверен.
И отрезвляющее, которое стоит держать рядом с термином «самоулучшение»: агент не решает, куда эволюционировать. Событие, запускающее цикл, изменяемый компонент и ось улучшения выбирает человек. Автономна здесь итерация, а не постановка задачи — то же разделение, что между ownership и автономией выше.
Атомарность, откат и версия сессии
Apply должен либо выпустить целую ревизию, либо не выпустить ничего; метаданные proposal и live-текст не могут разъехаться при сбое. Откат возвращает предыдущую известную ревизию и сам остаётся аудируемым событием.
Запущенная сессия сохраняет уже загруженный снимок skill. Новая версия начинает влиять на новые загрузки, а не переписывает контекст задним числом. Поэтому GREEN выполняется свежей сессией, а в трассе фиксируется revision фактически использованного skill (Agent Audit Log).
Что брать из OpenClaw 2.0
Брать стоит механику Workshop: proposal-first, hash binding, fail-closed ownership, изолированный reviewer, scanner на apply, атомарную ревизию и rollback metadata. Не стоит переносить default auto: для репозитория пользовательских skills безопаснее propose, пока нет отдельного machine-owned namespace и набора регрессионных evals.
Внутренний и внешний циклы улучшения
Практика Warp подтверждает полезное разделение ролей. Внутренний цикл выполняет задачу и собирает явную обратную связь; внешний improver запускается отдельно, читает результаты нескольких прогонов и предлагает маленький сфокусированный diff. Изменение проходит обычный PR/review, а следующий запуск получает уже принятую версию.
Разделение не заменяет наши более строгие gates — ownership, base hash, RED/GREEN и rollback, — но объясняет, почему improver не должен жить внутри исполняемого skill. Агент, одновременно решающий задачу и переписывающий собственную методику, смешивает evidence с вмешательством и оптимизируется под последний случай.
Отдельно запущенный improver обязан сообщать, что он работает. Внешний цикл живёт вне сессии — фоновым процессом, задачей по расписанию, отдельным запуском, — и это ровно тот класс механизмов, который умеет молча не работать: процесс стартовал, отчитался об успехе, был убит средой и никакого разбора не сделал. Наружу это выглядит как «улучшений не нашлось», то есть как нормальный исход воздержания. Минимум, отличающий одно от другого: признак живости последнего прохода и число подряд идущих запусков, не доживших до конца (Agent Failure Modes).
Updater и польза умения — разные измерения
Даже корректно выпущенный skill может не улучшить итог: task-agent не распознал trigger, не загрузил документ или загрузил, но не соблюдал его. Поэтому end-to-end score раскладывается на четыре ступени: валидность candidate, activation rate, adherence после активации и gain на held-out задачах. Это не новые release-права, а диагностическая декомпозиция: она показывает, чинить ли текст умения, маршрутизацию или способность модели следовать длинной процедуре (Continual Agent Evolution, Instruction Compliance Measurement).
Если target менять нельзя
Встроенный, marketplace или внешний skill может быть полезен, но не принадлежать текущему репозиторию. Тогда безопасная форма адаптации — wrapper/chaining skill: он вызывает или окружает исходную процедуру дополнительной проверкой, не создавая видимость владения upstream-файлом.
Wrapper не является обходом ownership. Его собственное поведение проходит RED/GREEN, а контракт с upstream фиксирует версию и ожидаемый результат. Если исходный skill нельзя стабильно вызвать или его интерфейс не объявлен, остаётся proposal владельцу, а не копия содержимого под новым именем.
Связано с
- Harness Optimization — когда опыт вообще достоин durable-правки
- Agent First Repository — жизненный цикл и progressive disclosure skills
- Approval Path — подтверждение точного артефакта, а не намерения
- Agent Identity — ownership не равен полномочию
- Agent Audit Log — evidence, proposal revision и фактически загруженная версия
- Instruction Compliance Measurement — чем проверяют, что выпущенное умение действительно исполняется
- Memory Write Policy — соседний слой с той же границей: запись не становится правилом без человека
- Agent Failure Modes — почему фоновый улучшатель попадает в класс «отчитался и не сработал»
- Continual Agent Evolution — общий dual-loop и раздельная оценка candidate, activation, adherence и transfer