Midjourney и другие нейросети - страница 1253

[Vitaliy Kuznetsov]

Как создать скилл для ИИ-агента: превратите опыт в рабочую инструкцию

//текст ChatGPT. Обложку Gemini

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

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

Что такое скилл и зачем он нужен

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

В распространённом формате Agent Skills скилл представляет собой папку с обязательным файлом SKILL.md. При необходимости в неё добавляют справочные материалы, скрипты и шаблоны.

Простейшая структура выглядит так:

my-skill/

├── SKILL.md

├── references/

├── scripts/

└── assets/

Главный файл содержит описание назначения скилла и основные инструкции. Остальные материалы нужны, если одного файла недостаточно.

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

Правило № 1. Сначала решите задачу, потом создавайте скилл

Самая распространённая ошибка — попросить нейросеть написать скилл по теме, с которой она должна работать.

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

Гораздо полезнее сначала выполнить реальную задачу вместе с агентом.

Во время работы фиксируйте:

• Успешные действия. Какая последовательность шагов привела к результату?

• Исправления. Где агент ошибся и что пришлось ему объяснять?

• Особенности входных и выходных данных. Какие форматы, поля и ограничения нужно учитывать?

• Неочевидные условия. Какие правила существуют именно в вашем рабочем процессе?

• Неудачные подходы. Что пробовали, почему это не сработало и как избежать повторения ошибки?

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

Главное — не подменять реальные наблюдения догадками. Если правило ещё не проверено, его лучше обозначить как предположение.

Правило № 2. Каждая строка должна что-то менять

При редактировании скилла задайте себе простой вопрос:

Совершит ли агент ошибку, если убрать эту инструкцию?

Если нет, строка, скорее всего, не нужна.

Сравните два варианта:

Плохо:

«Тщательно проверяйте документы и правильно обрабатывайте ошибки».

Хорошо:

«После извлечения таблиц из документа сравни результат с исходными страницами. Конвертация может потерять объединённые ячейки и изменить расположение значений».

Вторая инструкция объясняет, что именно может пойти не так и как это обнаружить.

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

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

Правило № 3. Описание скилла определяет, когда он включится

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

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

Хорошее описание отвечает на три вопроса:

1. Что конкретно делает скилл?

2. В каких случаях его следует применять?

3. Какие косвенные признаки указывают на необходимость его использования?

Например, недостаточно написать «Работа с таблицами». Лучше уточнить:

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

Описание должно быть достаточно широким, чтобы распознавать разные формулировки одной задачи, но не настолько широким, чтобы срабатывать на всё подряд.

В спецификации Agent Skills для поля description установлен предел в 1024 символа.

Правило № 4. Не превращайте главный файл в энциклопедию

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

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

Например, для скилла по редактированию текстов основным файлом может быть последовательность действий, а отдельными справочниками — правила для разных жанров, список нежелательных выражений и требования к оформлению.

Важно не просто вынести сведения, но и указать, когда их нужно читать:

«Перед редактированием технической документации открой справочник по терминологии».

Так агенту не приходится загружать всё содержимое без необходимости. В качестве ориентира официальное руководство рекомендует держать основной файл короче 500 строк и 5000 токенов. Это рекомендация, а не цель, к которой нужно стремиться.

Правило № 5. Будьте строги там, где ошибка дорого обходится

Инструкции не должны быть одинаково жёсткими во всех ситуациях.

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

Например:

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

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

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

Ещё один важный момент: скилл должен описывать не готовый ответ для одной задачи, а способ решения целого класса задач. Иначе он быстро устареет.

Правило № 6. Записывайте «грабли»

Во многих скиллах самый ценный раздел — список ошибок, на которых агент уже спотыкался.

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

Удобный формат:

• Симптом: что произошло.

• Причина: почему это случилось.

• Действие: как исправить ситуацию или избежать ошибки.

Например:

Симптом: после преобразования документа часть таблицы пропала.

Причина: выбранный способ конвертации не сохранил структуру объединённых ячеек.

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

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

Как проверить, что скилл работает

Готовый файл ещё не означает, что скилл полезен. Он может не активироваться, неверно интерпретировать инструкции или добавлять ненужные действия.

Минимальная проверка проста: выберите две-три типичные задачи и сравните результаты с использованием скилла и без него.

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

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

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

Ещё два правила, о которых легко забыть

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

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

Итог

Создание скилла — это не написание длинного промпта и не попытка объяснить нейросети всё о выбранной теме. Это извлечение практического опыта из выполненной работы.

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

Лучший скилл — не тот, в котором больше всего текста, а тот, который помогает агенту не повторять уже совершённые ошибки.

Источники

• Best practices for skill creators — руководство по созданию скиллов

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

[Vitaliy Kuznetsov]

GPT-6.1 Terra: OpenAI обновила модель для работы с компьютером

//текст и обложка ChatGPT

OpenAI представила GPT-6.1 Terra — обновление модели среднего класса, рассчитанное на повседневную работу, автоматизацию и обработку визуальных данных. По сравнению с GPT-5.6 Terra новинка стала заметно сильнее в программировании, анализе изображений и управлении приложениями, а её стоимость снизилась вдвое.

Главная особенность Terra — способность не только понимать содержимое экрана, но и выполнять последовательность действий в программах. Модель предназначена для обработки документов, заполнения форм, работы с каталогами, анализа технических чертежей и других задач, которые обычно требуют участия человека.

Что показывают тесты

В Terminal-Bench 4.0, проверяющем способности ИИ решать задачи программирования через командную строку, GPT-6.1 Terra набрала 50,3% против 21,5% у предыдущей версии при максимальном уровне рассуждений.

На тесте Agents’ Last Exam, оценивающем выполнение профессиональных задач с помощью программ, прирост относительно GPT-5.6 Terra составил 15 процентных пунктов при среднем уровне рассуждений. OpenAI также заявляет о более чем трёхкратном преимуществе в скорости выполнения задач перед GPT-6.1 Sol и GPT-6 Astra.

Улучшилась и точность ответов. В собственном тесте OpenAI на сложных вопросах, провоцирующих фактические ошибки, их доля при низком уровне рассуждений снизилась с 53,6% до 16,7%. Это результат внутреннего тестирования компании, поэтому переносить его напрямую на все реальные запросы нельзя.

Цена и первые впечатления

API-модель стоит $1 за миллион входных токенов и $5 за миллион выходных. Кэшированные входные токены обходятся в $0,05 за миллион. Контекстное окно — 1,05 млн токенов, максимальная длина ответа — 128 тысяч токенов.

Независимый анализ Artificial Analysis также отмечает существенный рост эффективности: при максимальном уровне рассуждений показатель Intelligence Index вырос на шесть пунктов относительно предыдущей Terra, а стоимость выполнения тестовых задач снизилась примерно с $1,40 до $0,40.

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

GPT-6.1 Terra уже доступна через API, а также в ChatGPT Work и Codex на поддерживаемых платных тарифах.

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

Источники:

• Официальный анонс OpenAI

• Artificial Analysis — независимый анализ и сравнение стоимости

• Документация модели и тарифы API