Самосовершенствующиеся агенты за счет навыков: повторное использование, отбор, ремонт и проверка.

Агент, занимающийся программированием, который дважды сталкивается с одной и той же проблемой, обычно не имеет постоянного места для хранения полученных знаний. Идея плагина под названием Whetstone заключается в том, чтобы работа, выполненная агентом сегодня, способствовала улучшению его работы завтра. Инструмент, написанный и протестированный агентом, должен быть готов к использованию в следующий раз. Рабочий процесс, требующий корректировки, должен приводить к стабильным изменениям, которые можно будет проверить. Кроме того, до передачи результата должны уже быть выполнены все необходимые проверки.

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

Под «агентами, способными к самосовершенствованию», здесь подразумеваются агенты в деликатно скромном смысле. Агент помогает улучшать собственные инструкции и инструменты, человек проверяет изменения и решает, что станет постоянным, сама модель не переобучается, и ничего не работает в фоновом режиме без присмотра для самостоятельного обучения.

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

Та часть агента, которую можно действительно улучшить

Навык представляет собой папку, в которой находится файл SKILL.md с инструкциями, а также, по желанию, скрипты и справочные документы. Спецификация Agent Skills определяет стандартную структуру: в начале файла указываются краткое название и описание. Инженерная команда Anthropic описывает навыки как способ предоставления универсальным агентам повторно используемых знаний, причем преимущество заключается в возможности улучшения процедур без необходимости полной переработки движка.

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

Whetstone наделяет каждый из своих четырех навыков одной конкретной функцией:

• dry-promotion отвечает за сохранение кода, пригодного для повторного использования.
• skill-audit проверяет информацию, используемую для выбора навыка.

skill-repair предлагает изменения в процедурах.

verify-before-return проверяет результат выполнения.

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

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

1. DRY: сохранять уже успешно выполненную работу

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

Рендерер — это повторно используемый механизм, а контент — то, что меняется. В документации Anthropic приводится аналогичный пример с PDF-скиллом, который выполняет заранее написанный скрипт извлечения: код отвечает за стабильную механическую часть работы, в то время как модель принимает решения, специфичные для конкретной задачи.

Вот за что отвечает dry-promotion. Он копирует полезный вспомогательный файл в папку scripts/ скилла и переписывает инструкции так, чтобы скрипт выполнялся. Одного сохранения файла недостаточно: хотя скилл по-прежнему просит агента написать скрипт, нет ничего, что указывало бы ему на уже сохраненный вариант.

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

Перед возвратом субтитров запустите сохраненный счетчик символов. Если полученное значение превышает лимит, сократите текст и снова подсчитайте количество символов. Никогда не определяйте число приблизительно и никогда не создавайте счетчик заново.

Это позволяет получить стабильную реализацию, которую можно проверять и тестировать. Однако это не делает весь рабочий процесс детерминированным, поскольку сам субтитр может все еще меняться, а программа может верно повторять неверное определение. Счетчик должен определить, будет ли он считать кодовые точки Unicode или видимые символы, а также как он будет обрабатывать пробелы и переносы строк.

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

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

2. Помогите агенту выбрать подходящий навык

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

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

Описания — не единственный способ выбора. Claude Code также поддерживает явное вызов, а конфигурация во время выполнения влияет на то, что доступно. Тем не менее описание является сигналом выбора, который контролируется автором навыка.

Просмотр библиотеки навыков одного человека, при этом дубликаты с одинаковыми именами учитывались отдельно от конфликтов, привел к следующему резюме:

383 skills scanned
  missing description           0
  no trigger language         306
  colliding pairs               3
  duplicate names              23
  skills with >=1 defect      306  (79%)

79% — это укороченное значение, полученное при делении 306 на 383, что соответствует примерно 79,9%. Эти описания не прошли проверку формулировок, что не то же самое, что 306 замеченных случаев неправильного использования навыка. Сканер проверяет только буквальные формулировки-триггеры вроде «использовать, когда» или «когда пользователь». Модель может следовать описанию без таких слов, а описание с ними всё равно может оказаться слишком общим и бесполезным. Результат представляет собой список для дальнейшего изучения, а не показатель степени неисправности агента.

Предоставьте соседним навыкам разные задачи

Рассмотрим два реальных описания навыков из одного плагина:

Один из них представляет себя как эксперт в создании систем генерации с усилением с помощью поиска, использующих векторные базы данных, эмбеддинги и современные стратегии поиска. Другой представляет себя как эксперт в выборе, настройке и оптимизации векторных баз данных, таких как Pinecone, Weaviate, Chroma, Qdrant и Milvus, для семантического поиска и технологии RAG.

Оба варианта звучат убедительно, так кто из них лучше подойдет пользователю, который нуждается в помощи при выборе векторной базы данных для приложения RAG? Способная модель, вероятно, отдаст предпочтение второму варианту, который более узкоспециализирован, однако первый также претендует на то же поле деятельности. Ничто не указывает на то, в чем заключается сфера компетенции каждого, поэтому модели приходится самостоятельно определять границы.

Переработки в этом духе позволили бы четче разграничить их функции. Они еще не проходили тестирование на производительность:

name: vector-database-selection
description: >-
  Compare vector databases against workload, filtering,
  deployment, and operating-cost requirements. Use when
  choosing or replacing a vector store. For retrieval-pipeline
  design with an already chosen store, use rag-pipeline-design.

name: rag-pipeline-design
description: >-
  Design ingestion, chunking, retrieval, reranking, and
  evaluation for a RAG application. Use when building or
  diagnosing a retrieval pipeline. For a standalone vector
  database selection, use vector-database-selection.

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

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

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

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

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

3. Преобразование опыта в повторно используемые инструкции

Выявление проблемы ставит более полезный вопрос: где должна находиться коррекция?

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

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

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

Единое предупреждение, вставленное в каждый случай, полностью отменит необходимость диагностики.

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

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

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

Когда общее руководство требует ремонта

Библиотека одного человека — это его собственный накопленный хаос, проверяемый его собственным инструментом; поэтому аналогичная проверка была проведена и с публичным репозиторием плагинов, управляемым командой по исследовательскому программному обеспечению университета. В момент снимка он содержал 76 навыков в 12 плагинах.

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

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

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

4. Проверка перед передачей

verify-before-return предоставляет системе критерии приёмки и цикл проверки. Запись файла на диск — это лишь промежуточный этап, и рабочий процесс всё равно должен проверить результат с использованием доказательств, соответствующих задаче:

• Для презентации необходимо выполнить её отрисовку, затем проверить на наличие обрезанного текста, неразборчивых меток или элементов, выходящих за границы экрана.
• Для исследовательского отчёта нужно открыть исходные материалы и убедиться, что они подтверждают изложенные тезисы.
• Для кода следует запустить тесты, проверяющие требуемое поведение.

Любое утверждение о завершении работы должно указывать на то, что было фактически проверено.

Определите эти критерии до начала работы. Затем пусть специалист составит первый вариант, проверит его, устранит ошибки и повторит проверки, затронутые этими исправлениями. Ограничьте количество итераций и требуйте указания всего, что осталось нерешенным, поскольку стремление к постоянному совершенствованию может привести к бесконечной правке без видимого результата.

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

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

Какие тесты изменил аудитор

Результаты тестов показали, что аудитору пришлось рассматривать дублирующиеся установки и перекрывающиеся описания как отдельные находки. При первом запуске было выявлено 81 потенциальная пара; многие из них представляли собой идентичные навыки, находящиеся в разных версиях плагинов в кэше. Анализ этих пар привел к тому, что дубликаты с одинаковыми именами были исключены из анализа коллизий, в результате чего количество потенциальных пар сократилось до 3.

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

При удалении дублирующихся названий было обнаружено 23 названия, присутствующих более чем в одном сканированном пути. Кэшированные копии не подтверждают, что старые версии были активны, поэтому необходимо проверить включённые плагины и реализованные пути во время работы программы. Аналогично, 383 единицы относятся к сканированным файлам, а не к активным уникальным навыкам, и исключение сравнений с одинаковыми названиями не позволяет полностью устранить дубликаты в инвентаре.

Этот показатель представляет собой лишь грубую оценку: количество слов, общих для обеих описаний, делённое на количество уникальных слов в каждом из них, причём стандартным порогом является 0,35. Исключение может выглядеть как перекрытие, и два описания одной и той же должности с разным формулированием могут пройти незамеченными. Парсер frontmatter также поддерживает лишь часть форматов YAML. Любой флаг требует проверки человеком перед тем, как он будет использован для исправления проблем.

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

Упаковка не перемещается; перемещаются навыки

Целью было сделать утилиту whetstone пригодной не только в Claude Code. Использование формата SKILL.md помогает в этом отношении. Однако навык может по-прежнему зависеть от инструментов, разрешений или путей к файлам, которые не предоставляются другим клиентам, к тому же каждый клиент упаковывает плагины по-своему. Стандарт Agent Plugins, руководство Claude Code и документация OpenCode описывают такую структуру.

Whetstone отправляет оба списка в одном общем каталоге skills/. Процедура хранится в одном месте, а интеграция каждого клиента тестируется отдельно. Однако портативные инструкции всё равно не делают модели взаимозаменяемыми, поэтому выполните ту же типичную задачу в другой совместимой среде выполнения и проверьте её вызовы инструментов, зависимости и результаты, прежде чем считать, что поведение идентично.

Попробовать на одном рабочем процессе

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

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

Проект распространяется под лицензией MIT. Для Claude Code в файле README приведены команды установки:

claude plugin marketplace add cdcore09/whetstone
claude plugin install whetstone@whetstone

Обеспечены четыре точки входа: /audit, /promote, /repair и /verify. Используйте ту, которая соответствует вашей рабочей процедуре. При первой попытке разумно попросить утилиту изучить соответствующие файлы и предложить изменения перед тем, как что-либо применять.

Чтобы ознакомиться с инструментом аудита без установки каких-либо компонентов, склонируйте репозиторий и прочитайте файл skills/skill-audit/scripts/audit_skills.py. С верхней части репозитория его запускает приведённая ниже команда, причём используется только стандартная библиотека Python:

python3 skills/skill-audit/scripts/audit_skills.py ./skills

Замените ./skills на папку, которую вы хотите изучить, начав с небольшого набора, который вам знаком, прежде чем сканировать все кэши плагинов на вашем компьютере. Параметр --json генерирует структурированный отчет, а --threshold 0.25 показывает более широкий набор перекрывающихся описаний.

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

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