Тестирование скилов агента автономным циклом

Чтобы агент надёжно выполнял сложный скил, недостаточно написать инструкцию красивыми словами. Нужен цикл: гоняем агента, проверяем артефакты bash-чекером, ловим стабильные ошибки и правим структуру инструкции — не текст. За три итерации скил создания лендинга прошёл путь от 4 фейлов до 0. Сама идея цикла подсмотрена у Anthropic, материалы которого собрал агент Николая Сенина через knowlu.me и опубликовал на его trip2g-инстансе. Мой агент достал их через MCP-эндпоинт его сайта.

Где живёт агент

Агент — кастомная сборка Hermes, которую мы учим вести «второй мозг» во время работы. Этот второй мозг — обычный trip2g-инстанс с папкой markdown-заметок. Trip2g превращает их в сайт, формы, RAG, платные подписки. Агент пакуется набором скилов и инструкций — это его способ пользоваться вторым мозгом с ювелирной точностью. Скилы лежат рядом с заметками, обновляются из общей школы агентов.

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

Боль: скил — это markdown

Скил написан как пошаговая инструкция в .md. Агент читает её и интерпретирует свободно. Если шаг неудобный — он его пропустит. Если шагов много — он сократит. Если требование длинное — он не дочитает.

Конкретно: я просил агента после сборки лендинга обязательно создавать _report.md со списком проверок. В первой версии скила это был шаг 6 из 10. Агент стабильно пропускал его две итерации подряд, хотя в скиле было написано «НИКОГДА не пропускай».

Без формального чека я бы это не заметил. Глазами лендинг выглядел нормально — заголовки, кнопки, всё на месте.

Решение: harness вокруг агента

Сделал короткий bash-скрипт landing-iterate.sh. Он чистит vault, шлёт промпт через API Hermes, ждёт пока агент закончит, читает артефакты из контейнера, гоняет десяток проверок: есть ли файл, правильный ли frontmatter, создан ли репорт, отмечены ли в нём обе секции.

Результат — формальный счётчик N/10 PASS. Видно когда регрессия, видно когда улучшение, видно ровно какой пункт упал.

Между итерациями я делаю одно — анализирую issues-N.txt и правлю скил структурно, а не косметически. Не «добавь восклицательный знак», а «перенеси этот шаг в начало», «объедини с соседним», «сделай два файла в одном tool call».

Этот цикл прямо ложится на три паттерна, которые агент Николая выудил из выступлений Anthropic на Code with Claude 2026:

  • case-012, ежедневный цикл улучшения: офлайн-бенчмарк как стоп-кран, онлайн-оценки на трейсах из прод-использования. Мой landing-iterate.sh — этот стоп-кран. Без 0 FAIL я не дальше.
  • case-023, harness-first engineering от Datadog: вкладывайся в автоматические проверки, а не в чтение каждой строки кода. Один и тот же сдвиг — от человеческого ревью к машинной обвязке.
  • case-009, «Мечтание» от Anthropic: async-процесс смотрит транскрипты агентов, ищет повторяющиеся ошибки, обновляет общую память. У них дало шестикратный рост качества для юридического агента Harvey. У меня роль «мечтателя» пока играю я сам — между итерациями.

Ссылка на навигатор по кейсам: journal.nicksenin.com/code-with-claude.

Неожиданности

Первая. Я думал, что моя проблема — формулировки. Перепишу пожирнее, добавлю «обязательно», «никогда не пропускай» — и заработает. Не заработало. Сработал только структурный сдвиг: создание лендинга и репорта в одном tool call с явным условием брака. Текстом нельзя заставить агента не пропустить шаг. Можно только убрать саму возможность пропустить.

Вторая. Без обвязки я бы не понял, что ошибка стабильная. Думал бы, что иногда повезло, иногда нет. Формальный чек показал — пропуск всегда в том же месте. Стало ясно: это не случайность, это структурная дыра в инструкции.

Третья. Знания других агентов реально доступны. У Николая агент-собиратель прошёлся по выступлениям конференции, выдернул сжатые кейсы по схеме «барьер → рычаг → целевое состояние», уложил в его trip2g, открыл по MCP. Я не смотрел эти выступления и не читал расшифровки. Я задал поисковый запрос его MCP — и получил готовые формулировки, под которые сразу собрался план. Это не «нашёл статью в интернете», это обмен инфраструктурой: его второй мозг работает на моём агенте.

Выводы

  • Каждый скил, который мы хотим считать готовым, должен иметь свой harness — отдельный сценарий с проверками артефактов. Без harness любой скил остаётся гипотезой.
  • Цикл «промпт → артефакты → чек → правка скила» работает за 2–4 итерации, если правки структурные. Если только текстовые — не работает вообще.
  • «Мечтание» по case-009 хочется встроить прямо в Hermes: пусть агент сам ночью анализирует свои недавние сеансы, находит повторяющиеся ошибки и предлагает diff к скилам. Пока думаем о форме — но направление точно туда.
  • Trip2g-инстансы становятся фактическими хранилищами агентов, и MCP-эндпоинт каждого — это API доступа другого агента к этим знаниям. Чем больше людей публикуют свои базы — тем умнее становятся все остальные агенты в сети.

Что дальше

  • Сделать harness для остальных скилов (task-management, himalaya-email, use-steel-browser, drilling-семейство).
  • Развернуть три публичных Hermes-инстанса и гонять все harness-сценарии каждые 6 часов с публичным дашбордом. Чтобы при любом изменении скила сразу видеть, где регрессия. План e2e-public-hermes живёт в репозитории hermes-agent.
  • Спроектировать «мечтание» как нативный процесс Hermes — что запускает, что анализирует, какой формат diff к скилу.

Связанные материалы