LLM анализ статьи

• https://research.perplexity.ai/articles/designing-refining-and-maintaining-agent-skills-at-perplexity

TL;DR: Текст объясняет, что Agent Skills — это не обычная документация и не код, а тщательно упакованный контекст для LLM-агентов. Главная мысль: хороший Skill должен загружаться только тогда, когда нужен, быть коротким, содержать не очевидные команды, а высокосигнальные инструкции, граничные случаи и evals. Плохой Skill ухудшает не только себя, но и всю систему навыков из-за лишнего контекста и неправильного роутинга.

1. 5–8 ключевых мыслей

1. Skill — это не файл, а модульная папка. В Perplexity Skill может включать SKILL.md, scripts/, references/, вложенные subskills, вспомогательные документы и шаблоны. Такая структура нужна, чтобы не грузить всё сразу, а раскрывать контекст постепенно.

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

3. Описание Skill — это роутинг-триггер, а не документация. Хорошее описание отвечает не “что делает Skill”, а “когда его нужно загрузить”. Формулировки вроде “Load when…” важнее, чем красивые объяснения назначения.

4. Skill нужен только там, где модель без него ошибается. Если LLM уже знает, как выполнить задачу, например базовые git-команды, не надо дублировать это в Skill. Skill нужен для специфических workflow, domain knowledge, устойчивых предпочтений, enterprise-процессов, edge cases и устранения нестабильного поведения.

5. Хорошая Skill-инструкция не должна быть чрезмерно процедурной. Вместо списка команд лучше дать намерение и критерии: например, не расписывать git checkout, cherry-pick, resolve conflicts, а сказать “перенеси коммит на чистую ветку, сохрани intent, объясни, если конфликт нельзя разрешить корректно”.

6. Gotchas и negative examples — один из самых ценных типов контента. Ошибки, пограничные случаи и запреты часто дают больше пользы, чем позитивные примеры. Они помогают модели не загружать Skill не туда и не делать типичные неверные шаги.

7. Evals нужно писать до или вместе со Skill. Авторы подчёркивают, что нельзя просто написать Skill и надеяться, что он работает. Нужно проверять precision/recall загрузки, forbidden-load cases, чтение вспомогательных файлов и end-to-end выполнение задач.

8. Skills нужно поддерживать осторожно. Изменение описания после merge — рискованный шаг, потому что оно влияет на роутинг и может сломать соседние Skills. Поддержка чаще должна быть append-mostly: добавлять gotchas и evals, а не переписывать ядро.

2. Что здесь действительно важно и почему

Самая важная идея: Skills — это инженерия внимания модели, а не инженерия обычного software-модуля. В обычном коде подробность часто полезна, а в Skill лишняя подробность может ухудшить поведение агента, потому что забивает контекст, мешает другим Skills и снижает точность выбора правильного поведения.

Вторая важная идея: роутинг важнее содержания. Даже идеально написанный Skill бесполезен или вреден, если он загружается не тогда, когда надо. Поэтому описание, positive/negative examples и forbidden-load evals становятся критической частью качества.

Третья важная идея: Skill должен содержать то, чего модель сама не знает или стабильно делает плохо. Это особенно применимо к твоим проектам с агентскими инструкциями, Codex, multi-agent workflow и md-файлами: не надо превращать Skills в длинные README. Нужно выносить туда только устойчивые правила, ошибки, критерии качества, “не делай так”, специфические workflow и то, что агент регулярно путает.

Четвёртая важная идея: иерархия — мощный инструмент, но не бесплатный. Многоуровневая структура помогает модели выбирать из 20 областей вместо 300 тем, но требует кураторства: индексов, коротких справочников, вспомогательных поисковых механизмов и evals. Без этого иерархия превращается в дополнительную сложность.

3. Слабые места, спорные тезисы и ограничения надёжности

Есть несколько спорных или требующих осторожности мест.

Первое: текст написан из перспективы Perplexity и их архитектуры Computer/Agent Skills. Многие принципы универсальны, но конкретные лимиты вроде “около 100 токенов на Skill description” или “желательно до 5,000 токенов в теле Skill” зависят от их реализации и не обязательно напрямую переносятся на Codex, Claude Code, OpenAI Custom GPTs или локальные агентские системы.

Второе: тезис “если это легко объяснить, модель уже знает это — удалите” полезен как эвристика, но не абсолютен. В enterprise-среде иногда нужно фиксировать даже очевидные вещи, если важна воспроизводимость, compliance или единый стиль исполнения.

Третье: утверждение про “self-generated Skills provide no benefit on average” выглядит важным, но в данном фрагменте не раскрыта методология исследования. Поэтому его лучше воспринимать как предупреждение против one-shot генерации Skills, а не как запрет на использование LLM для черновиков.

Четвёртое: текст продвигает сильную культуру evals, но не даёт полной методики построения eval suites. Он объясняет, что проверять, но не раскрывает подробно, как именно проектировать метрики, датасеты, judge rubrics и regression gates.