Agent Skills и OKF: скиллы, знания и доверие

Скилл задаёт агенту способ выполнения задачи. В файле SKILL.md небольшой заголовок YAML содержит имя и описание, далее идут инструкции и ссылки на дополнительные материалы. Сначала модель получает описание навыка, при активации — его текст, затем при необходимости — остальные ресурсы. Это экономит контекст, но делает описание частью механизма выбора. Слишком широкий навык может перетянуть вызовы на себя и помешать обнаружению других. Явный вызов и автоматический выбор решают разные задачи; универсального победителя участники не называют.

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

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

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

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

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

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

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

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

OKF обсуждается как спецификация, оформляющая этот подход через Markdown, типизированные метаданные и отношения между страницами. Это развитие знакомых идей, совместимых с привычными инструментами вроде Obsidian. Реализации могут предоставлять операции через MCP. Ценность формата участники связывают с общим описанием знаний для агентов; наличие файлов в правильной структуре ещё не обеспечивает качество извлечения, актуальность содержания или одинаковое поведение разных реализаций.

На вопрос, заменяет ли OKF подход RAG, участники отвечают через спектр задач. Лёгкая структурированная база удобна для знаний ограниченной предметной области, которыми пользуются навыки. Для больших связанных наборов данных обсуждаются графовые базы, для широких коллекций и множества запросов — инфраструктура поиска и извлечения. Это ориентир выбора, а не универсальная граница по числу документов. Корпоративному поиску нужны обновление индексов, управление доступом и оценка релевантности; один формат хранения эти задачи не закрывает.

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

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

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