Agent Skills становится открытым стандартом: почему AI-агенту недостаточно просто видеть ваш код

Agent Skills больше не принадлежит только экосистеме Anthropic

22 октября Anthropic передала Agent Skills в Agentic AI Foundation — независимый проект под управлением Linux Foundation.

Вместе со стандартом передаются его название и логотип, GitHub-организация и домен agentskills.io. Развитием формата продолжат заниматься инженеры Anthropic, Google, OpenAI и других компаний, но уже в рамках vendor-neutral governance.

По данным Anthropic, с момента публикации стандарта в декабре 2025 года поддержку Agent Skills добавили более 70 agent-платформ, в том числе ChatGPT, Cursor, GitHub Copilot и VS Code. Компания также заявляет примерно о миллионе опубликованных skills и почти 280 миллионах установок.

Сам формат при этом предельно простой.

Skill — это обычная директория:

my-skill/
├── SKILL.md
├── scripts/
├── references/
└── assets/

Обязателен только SKILL.md. В нём находятся метаданные и инструкции для агента. При необходимости рядом можно положить исполняемые скрипты, документацию, шаблоны или другие материалы.

Например:

---
name: prisma-migrations
description: Работа с Prisma migrations в нашем backend
---

# Prisma migrations

Перед созданием миграции:

1. Проверь текущее состояние schema.prisma.
2. Проверь существующие migration directories.
3. Выполни prisma migrate status.

Никогда:
- не редактируй уже применённые migrations;
- не удаляй записи из _prisma_migrations;
- не используй db push на production.

После изменения:
1. создай новую migration;
2. запусти тесты;
3. проверь migration SQL;
4. покажи изменения пользователю перед применением.

На первый взгляд это выглядит как обычный markdown-файл.

Но сама идея важнее формата.

Агент видит код — но это ещё не значит, что он знает проект

С этим довольно легко столкнуться при реальной работе с coding agents.

Допустим, агенту дали весь backend и задачу:

Исправь ошибку запуска приложения.

Он видит:

if (!process.env.CLICKHOUSE_CA_PATH) {
  throw new Error('ClickHouse CA certificate not found');
}

И приложение действительно падает именно здесь.

Если дополнительного контекста нет, самый короткий путь очевиден:

// if (!process.env.CLICKHOUSE_CA_PATH) {
//   throw new Error('ClickHouse CA certificate not found');
// }

Запуск починен.

Задача формально выполнена.

Но разработчик проекта знает дополнительную информацию:

production ClickHouse всегда работает через TLS;

локально ClickHouse может работать без TLS;

проверку нельзя просто удалять;

поведение должно зависеть от CLICKHOUSE_SSL_ENABLED.

И правильное изменение выглядит уже иначе:

const sslEnabled =
  this.config.get('CLICKHOUSE_SSL_ENABLED') === 'true';

if (sslEnabled && !caPath) {
  throw new Error('ClickHouse CA certificate not found');
}

Проблема заключается не обязательно в том, что агент «плохой».

У него просто отсутствовало знание, которое для человека из команды кажется очевидным.

Anthropic прямо объясняет происхождение Agent Skills похожим образом: Claude Code хорошо справлялся с общими задачами, но часто не обладал procedural knowledge, необходимым для реальной работы внутри организации.

Именно это Skills пытаются формализовать.

Не просто контекст, а процедура

Большой context window сам по себе эту проблему не решает.

Можно дать агенту:

200 000 строк исходного кода

но это не расскажет ему:

как команда делает migrations;

какой сервис является source of truth;

почему определённый middleware нельзя удалить;

какие endpoints считаются legacy;

как принято деплоить приложение;

какие действия требуют ручного подтверждения.

Это знания другого типа.

Не:

Что находится в кодовой базе?

а:

Как в этой кодовой базе принято работать?

Например skill для production deployment может выглядеть так:

---
name: production-deploy
description: Правила деплоя backend в production
---

# Deployment

Приложение работает через Docker Compose.

Перед деплоем:

1. git status должен быть чистым;
2. выполнить npm test;
3. выполнить npm run build;
4. проверить docker compose config;
5. проверить новые Prisma migrations.

## Networking

Backend НЕ должен быть доступен напрямую из интернета.

Допустимая схема:

Internet
  ↓
nginx :443
  ↓
backend :3000

Запрещено:
- открывать 3000/tcp через UFW;
- отключать nginx;
- отключать TLS;
- публиковать внутренние Docker ports.

Если для решения задачи требуется одно из этих действий —
остановись и запроси подтверждение.

Теперь задача:

API после деплоя недоступно извне

уже имеет совсем другой набор допустимых решений.

Без skill агент может увидеть:

ufw status

3000/tcp DENY

и сделать:

ufw allow 3000/tcp

С ним агент знает:

открытие 3000 наружу вообще не является допустимым решением.

Это важное различие.

Почему нельзя просто положить всё в один AGENTS.md

Можно.

И для небольшого проекта этого часто будет достаточно.

Например:

AGENTS.md

может содержать:

- Не изменять applied migrations.
- Не отключать тесты.
- Не открывать внутренние порты.
- Authentication работает только через Keycloak.
- Audit middleware обязателен.

Проблема начинается с ростом проекта.

Допустим, агент умеет:

React
NestJS
Prisma
Docker
Nginx
Terraform
AWS
PostgreSQL
ClickHouse
Bitrix

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

Agent Skills использует другой подход — progressive disclosure.

При старте агенту достаточно увидеть:

prisma-migrations
Работа с migrations нашего backend

production-deploy
Процесс production deployment

frontend-ui
Правила создания компонентов

incident-debugging
Диагностика production incidents

То есть только name + description.

Когда задача касается Prisma, загружается полный:

skills/prisma-migrations/SKILL.md

Когда нужно разобраться с сервером:

skills/incident-debugging/SKILL.md

Остальные инструкции не занимают контекст. Именно такую трёхступенчатую модель — discovery, activation и execution — описывает спецификация Agent Skills.

Это позволяет держать десятки специализированных инструкций, не пытаясь постоянно запихнуть их все в prompt.

Skill может содержать не только текст

Вот здесь подход становится особенно полезным.

Допустим, мы постоянно просим агента диагностировать Docker.

Можно написать огромную инструкцию:

Проверь docker ps.
Потом docker compose ps.
Потом disk usage.
Потом logs...

А можно положить рядом скрипт:

server-diagnostics/
├── SKILL.md
└── scripts/
    └── diagnose.sh

#!/bin/bash

echo "=== Disk ==="
df -h

echo "=== Docker ==="
docker ps

echo "=== Compose ==="
docker compose ps

echo "=== Docker usage ==="
docker system df

А SKILL.md описывает уже не команды, а процедуру:

Запусти scripts/diagnose.sh.

Проанализируй:

1. свободное место;
2. состояние контейнеров;
3. restart count;
4. docker storage usage.

Не выполняй docker system prune автоматически.

Если свободно менее 10% диска —
сообщи об этом до любых изменений.

Получается интересная конструкция:

LLM
 +
инструкции
 +
проверенный код
 +
документация
 =
Skill

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

Skills, MCP и AGENTS.md решают разные задачи

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

Упрощённо:

AGENTS.md
= как нужно вести себя в этом проекте

Agent Skills
= как выполнять конкретный тип задачи

MCP
= к каким внешним инструментам и данным можно обратиться

Например:

AGENTS.md

"Не меняй production без подтверждения"

Skill:

deploy-to-production

"Вот процедура нашего деплоя"

MCP:

GitHub
Sentry
PostgreSQL
Kubernetes

То есть:

                 AGENTS.md
                    ↓
              правила проекта
                    ↓
Task → Agent → Agent Skill
                    ↓
             процедура работы
                    ↓
                   MCP
                    ↓
          инструменты и данные

И уже поверх этого должны существовать реальные permissions.

Потому что markdown-файл не является security boundary.

Skills не решат проблему опасного агента сами по себе

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

Можно написать:

NEVER DISABLE MONITORING

Но если агент имеет:

root shell
+
production credentials
+
доступ к monitoring configuration

то технически возможность всё равно существует.

Skill помогает агенту понять ожидаемый способ работы.

Permission system определяет, что он вообще способен сделать.

Поэтому нормальная agent architecture выглядит скорее так:

              MODEL
                ↓
            AGENTS.md
                ↓
             SKILLS
                ↓
         tool / policy layer
                ↓
     ┌──────────┼──────────┐
     ↓          ↓          ↓
   MCP       scripts     shell
     ↓
 permissions / sandbox
     ↓
real infrastructure

Skills уменьшают вероятность неправильного решения.

Sandbox и permissions ограничивают последствия, если оно всё-таки принято.

Это разные уровни защиты.

Почему превращение Skills в стандарт действительно важно

Пока skill является особенностью одного AI-клиента, компании приходится создавать собственную базу инструкций для каждого инструмента:

Claude Code instructions
Cursor rules
Copilot instructions
ChatGPT instructions
...

И знания начинают дублироваться.

Agent Skills предлагает другую модель:

skills/
├── prisma/
├── frontend/
├── deployment/
├── code-review/
└── incident-response/

а дальше:

Claude Code ─┐
ChatGPT ─────┤
Cursor ──────┼──→ skills/
Copilot ─────┤
VS Code ─────┘

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

Передача проекта Linux Foundation делает эту идею ещё интереснее: дальнейшее развитие стандарта больше не должно определяться исключительно потребностями Claude.

AAIF уже управляет MCP и AGENTS.md, а 22 октября одновременно получил Agent Skills, Open Responses, OpenEnv и OpenSandbox. Фактически вокруг AI-агентов постепенно формируется открытый технологический стек:

AGENTS.md
      ↓
правила

Agent Skills
      ↓
знания и процедуры

MCP / A2A
      ↓
инструменты и взаимодействие

OpenSandbox
      ↓
безопасное исполнение

Linux Foundation описывает все эти проекты как части одной vendor-neutral инфраструктуры для agentic AI.

Хороший AI-агент — это уже не просто хорошая модель

Первые coding assistants можно было оценивать почти исключительно по модели:

насколько хорошо она пишет код?

Для автономных агентов этого становится мало.

Теперь результат всё сильнее определяется системой вокруг LLM:

model
+
context
+
project rules
+
skills
+
tools
+
permissions
+
sandbox
+
review

Модель может отлично знать TypeScript, PostgreSQL и Docker.

Но она не знает, что именно в вашей компании:

production migration никогда не редактируется;

backend нельзя публиковать напрямую;

определённый middleware обязателен;

после изменения API нужно обновить конкретный SDK;

деплой выполняется только через конкретный pipeline.

Пока эти знания существуют только в голове разработчика, агент вынужден угадывать.

А если решение не получается несколько раз подряд, он начинает расширять область поиска и искать другой путь к поставленной цели.

И тогда появляется знакомая ситуация:

"Я попросил исправить проблему.
Почему он вообще полез менять это?"

Ответ зачастую довольно простой:

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

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

И возможно, именно этот слой окажется важнее очередных нескольких процентов прироста coding benchmark.

Потому что следующий этап развития coding agents — это уже не вопрос:

насколько хорошо AI умеет программировать?

А вопрос:

насколько хорошо AI понимает, как программировать именно у нас?