Двадцать второго октября 2026 года в Сан-Хосе, на конференции AGNTCon + MCPCon North America, Anthropic объявила о передаче формата Agent Skills в Agentic AI Foundation, сокращённо AAIF. Фонд работает под эгидой Linux Foundation и уже держит протокол MCP, агента goose и файл AGENTS.md. В тот же день к ним добавились ещё три проекта, и общий счёт дошёл до десяти. На первый взгляд новость административная: сменился владелец, а текст спецификации остался прежним. Но административные решения обычно меняют практику тише и прочнее громких релизов. Если навык агента перестаёт быть собственностью одного вендора, его можно написать один раз и носить между платформами, как набор инструментов, который подходит к любому верстаку. Ниже разобрано, что именно переехало, как устроен навык изнутри и как упаковать в него опыт команды так, чтобы он работал не в одном продукте, а в нескольких сразу.
Передача затронула управление стандартом, а сам формат SKILL.md остался прежним
Anthropic передала фонду не только текст спецификации. В пакет вошли имя Agent Skills, логотип, организация с репозиториями и домен проекта. Иначе говоря, всё, что делает стандарт узнаваемым и управляемым, теперь принадлежит нейтральной площадке. Сам формат не изменился: папка с файлом SKILL.md, YAML-заголовок и markdown-текст под ним работают так же, как работали вчера. Изменилось управление. Мейнтейнеры из Anthropic, Google и OpenAI сопровождают стандарт как частные лица, а не как представители работодателей, и это существенная деталь: решения о развитии формата не привязаны к дорожной карте одной компании.
У шага есть прецедент. Протокол MCP Anthropic передала тому же фонду в декабре 2025 года, меньше года назад, и с тех пор он стал общим языком подключения инструментов у разных поставщиков. Сам фонд тогда стартовал с тремя проектами: MCP, goose и AGENTS.md, а среди учредителей называли Block и OpenAI. Навыки идут по той же дороге, и логика читается без труда: стандарт, которым пользуются конкуренты, удобнее держать там, где ни у кого нет права вето.
Для практика новость сводится к трём вещам. Существующие навыки переписывать не нужно. Выбор формата перестаёт быть ставкой на одного поставщика: если команда вложила месяц в библиотеку навыков, риск остаться с форматом, который однажды изменят в закрытом порядке, заметно меньше. А общий стандарт притягивает инструменты: навыки уже читают Claude Code, Cursor, Codex, Gemini CLI, VS Code, Copilot, goose, Windsurf и десятки других агентов. Любопытна и соседняя деталь: Claude Code теперь читает и AGENTS.md, тоже проект фонда, поэтому одна организация определяет сразу два файла, которые агент открывает раньше, чем притронется к коду.
Десять проектов фонда складываются в слои одной агентной конструкции
К стартовой тройке и навыкам присоединились A2A, Agent Router и agentgateway, а 22 октября ещё Open Responses от OpenAI, OpenEnv от Hugging Face и OpenSandbox от Alibaba. Если разложить десятку по задачам, получается вполне стройная схема.
Первый слой отвечает за знания и инструкции. AGENTS.md сообщает агенту, как устроен конкретный репозиторий: какие команды собирают проект, где лежат тесты, какие правила оформления приняты. Agent Skills хранит многоразовые процедуры, которые агент подгружает, когда задача совпадает с описанием. Первый файл отвечает на вопрос "что это за проект", второй на вопрос "как делается эта работа".
Второй слой отвечает за связь. MCP подключает агента к инструментам и источникам данных со структурированными вызовами и авторизацией, а A2A даёт агентам способ разговаривать друг с другом, даже если их собирали разные команды. Третий слой занят трафиком: agentgateway и Agent Router, судя по названиям и заявленному назначению, управляют маршрутизацией агентных запросов, чтобы организация видела, кто с кем обменивается и что при этом проходит.
Четвёртый слой связан с исполнением и проверкой. OpenSandbox даёт изолированную среду для кода, который порождает агент, OpenEnv описывает среды, где агентов обучают и оценивают, а Open Responses задаёт общий интерфейс обращения к моделям. Остаётся goose, открытый агент, на котором все эти договорённости удобно проверять живьём. Фонд не выпускает единый продукт. Он хранит правила, по которым разные продукты способны работать вместе, и в этом его главная ценность.
Навык устроен как папка с файлом SKILL.md, а модель читает его в три приёма
Минимальный навык - это папка, внутри которой лежит SKILL.md. По желанию рядом появляются каталоги scripts для исполняемого кода, references для справочных материалов и assets для шаблонов и ресурсов. Типичная раскладка выглядит так:
release-notes/
├── SKILL.md
├── scripts/
│ └── collect_commits.py
├── references/
│ └── style-guide.md
└── assets/
└── template.md
Файл SKILL.md начинается с YAML-заголовка, а у заголовка есть жёсткие правила. Поле name обязательно: от 1 до 64 символов, только строчные буквы, цифры и дефисы, без дефиса в начале и конце и без двух дефисов подряд. Имя совпадает с названием папки. Поле description тоже обязательно, до 1024 символов, и описывать оно должно сразу две вещи: что навык делает и когда его применять. Необязательные поля такие: license с названием лицензии, compatibility до 500 символов с требованиями к окружению, metadata как словарь строковых пар и allowed-tools, строка с заранее разрешёнными инструментами через пробел. Последнее поле в спецификации помечено как экспериментальное.
Самое умное в этом устройстве - порядок загрузки. Агент работает с навыком в три приёма. При старте он видит только имя и описание каждого навыка, около 100 токенов на штуку. Когда задача совпадает с описанием, он читает тело SKILL.md целиком. А дополнительные файлы из scripts и references подтягиваются лишь тогда, когда этого требует ситуация.
Арифметика показывает, зачем так сделано. Библиотека из 40 навыков стоит при старте примерно 4 000 токенов каталога. Если бы каждый навык загружался целиком и весил хотя бы 3 000 токенов, стартовая цена выросла бы до 120 000, и на саму работу осталось бы куда меньше места. Отсюда и рекомендация держать SKILL.md в пределах 500 строк, а детали выносить в соседние файлы.
Отсюда же растёт главное правило: описание - это триггер, а не вывеска. Формулировка вроде "Помогает с PDF" ничего не сообщает агенту о границах применения, и навык будет срабатывать невпопад или не сработает вовсе. Описание "Извлекает текст и таблицы из PDF, заполняет формы, склеивает документы; применять при любой работе с PDF-файлами" называет и действия, и ситуации.
Упаковка опыта команды в SKILL.md идёт от описания триггера до проверки результата
Лучшие кандидаты на навык - процедуры, которые команда повторяет снова и снова и каждый раз объясняет с нуля: оформление релизных заметок, разбор инцидента, подготовка отчёта, проверка миграции. Рабочий порядок упаковки выглядит так:
- Выбрать процедуру, которую команда повторяет не реже раза в месяц и для которой каждый раз требуются одни и те же пояснения;
- Записать description из двух частей, что навык делает и в каких ситуациях его нужно включать, словами, которыми задачу формулируют сами коллеги;
- Оставить в теле SKILL.md только порядок действий и критерии готовности, а справочные таблицы и длинные примеры вынести в references;
- Детерминированные операции, вроде сбора коммитов или проверки формата, поместить в scripts, чтобы агент запускал код, а не пересказывал его по памяти;
- Прогнать навык на трёх-пяти реальных задачах в каждом агенте, которым пользуется команда, и записать, где поведение разошлось;
- Закрепить владельца и версию в metadata, чтобы изменения проходили ревью, как любой другой код.
Ниже иллюстративный пример такого навыка. Он придуман для показа структуры, а не взят из чьей-то практики:
---
name: release-notes
description: Готовит заметки о релизе по списку коммитов. Применять, когда нужно оформить changelog или объявление о новой версии.
license: Apache-2.0
compatibility: Требуется Python 3.9 и доступ к git
metadata:
author: platform-team
version: "1.0"
allowed-tools: Bash(git:*) Read
---
# Заметки о релизе
Сначала запустить scripts/collect_commits.py с тегами предыдущей и новой версии.
Затем сгруппировать изменения по шаблону из assets/template.md и сверить тон
с references/style-guide.md. Готовая заметка не должна превышать одного экрана.
Если среди коммитов есть изменения, ломающие совместимость, вынести их в начало.
Тело здесь скромное: никаких длинных рассуждений, только порядок действий и условие готовности. Всё тяжёлое живёт в соседних файлах и подгружается по требованию. В поле metadata значение version записано в кавычках, потому что спецификация требует строковых значений, и число 1.0 без кавычек может прочитаться как дробное.
Один набор навыков в Claude Code, ChatGPT, Copilot и самописном агенте работает при условии проверки деталей
Переносимость навыков держится на простом ядре: имя, описание и markdown-текст читаются одинаково везде. Сложности начинаются на краях. Поле allowed-tools остаётся экспериментальным, и разные агенты по-разному трактуют, какие инструменты считать заранее разрешёнными и как их называть в записи вроде Bash(git:*). Скрипты из каталога scripts предполагают, что в окружении есть нужный интерпретатор и сеть, а у десктопного агента, облачного чата и сервера окружения различаются. Для этого и придумано поле compatibility: оно честно фиксирует требования, а не оставляет их на догадку. Поддержку в чат-продуктах вроде ChatGPT тоже стоит проверять отдельно, потому что набор возможностей у них другой, чем у агентов для терминала.
Рабочая тактика отсюда понятна. Ядро навыка пишется нейтрально, без ссылок на инструменты конкретного продукта. Всё, что зависит от среды, уходит в compatibility и в отдельные скрипты. Перед выкладкой в общую библиотеку навык проверяется в каждом агенте, которым реально пользуется команда.
Самописные агенты поддерживают формат за вечер. Для этого нужны три действия: собрать каталог из имён и описаний, положить его в системный промпт и дать модели инструмент для загрузки тела навыка. Минимальный загрузчик на Python выглядит так:
import pathlib
import re
import yaml
NAME_RE = re.compile(r"^[a-z0-9]+(-[a-z0-9]+)*$")
def read_skill(folder):
text = pathlib.Path(folder, "SKILL.md").read_text(encoding="utf-8")
_, header, body = text.split("---", 2)
return yaml.safe_load(header), body.strip()
def build_catalog(root):
lines = []
for folder in sorted(pathlib.Path(root).iterdir()):
if (folder / "SKILL.md").exists():
meta, _ = read_skill(folder)
lines.append(f"{meta['name']}: {meta['description']}")
return "\n".join(lines)
def load_skill(root, name):
if not NAME_RE.fullmatch(name):
raise ValueError("Недопустимое имя навыка")
_, body = read_skill(pathlib.Path(root, name))
return body
Каталог из build_catalog уходит в системный промпт и занимает около 100 токенов на навык. Функция load_skill регистрируется как инструмент: когда модель решает, что задача подходит под описание, она вызывает load_skill("release-notes") и получает тело. Проверка имени регулярным выражением здесь не украшение. Без неё модель или злоумышленник могли бы передать имя вроде "../../etc" и вытащить из файловой системы лишнее. Дополнительные файлы из references и scripts читаются обычным инструментом чтения файлов, и только когда тело навыка на них сослалось.
Карта стандартов фонда помогает выбрать связку MCP, AGENTS.md и навыков под конкретный сценарий
Выбор упирается в три вопроса: что агент должен знать о проекте, как делается типовая работа и к чему он должен получить доступ. Первому вопросу отвечает AGENTS.md, второму навык, третьему MCP. Из этого вырастают привычные сценарии.
Первый сценарий: один репозиторий, а разработчики сидят в разных агентах. Базу задаёт короткий AGENTS.md с командами сборки, тестов и правилами стиля, а поверх лежит каталог навыков для повторяющихся процедур. Общий файл остаётся компактным, узкие навыки подгружаются по требованию, и контекст не засоряется.
Второй сценарий: агент должен менять данные во внешней системе, заводить задачи, читать базу, проводить платежи. Тут нужен MCP, потому что структурированные вызовы и авторизация присущи ему, а у навыка встроенной модели доступа и исполнения нет, он опирается на инструменты, которые уже есть у агента. Навык при этом работает фильтром: даже если сервер выставляет двадцать инструментов, он подсказывает, какие нужны в этой процедуре и в каком порядке их вызывать. К тому же описания инструментов MCP обычно занимают контекст с самого начала, а навык стоит около 100 токенов, пока не понадобится.
Третий сценарий: работа делегируется между агентами разных команд или поставщиков. Здесь выходит на сцену A2A, а навыки описывают, как каждый участник ведёт свою часть. Четвёртый сценарий касается организаций с сотнями навыков, которым нужна раздача. Предложение SEP-2640, выдвинутое в июне 2026 года, расширяет MCP так, чтобы сервер отдавал навыки как ресурсы по схеме skill://, например skill://refund-processing/SKILL.md. Клиент сначала читает лёгкий индекс с именами и описаниями и только потом тянет нужное, а один сервер способен обслуживать целую библиотеку компании. Это именно предложение, поэтому его статус перед внедрением стоит проверять.
Пятый сценарий самый простой: задачу решает одна команда терминала. Тогда хватает навыка с коротким скриптом, а поднимать MCP-сервер ради такого случая расточительно. Полезное правило: сначала скрипт и навык, потом MCP, когда появится потребность в авторизации и общем доступе.
Навык исполняется агентом как инструкция, поэтому чужие навыки читают так же внимательно, как код
У переносимости есть теневая сторона. Навык - это текст, которому агент подчиняется, а значит, вредоносный навык по сути является внедрением инструкций, которое пользователь установил себе сам. Он может велеть агенту отправить файлы наружу, выполнить лишнюю команду или молча обойти проверку. Поэтому к установке навыка относятся как к установке программы: берут из источников, которым доверяют, и перед подключением читают и SKILL.md, и все скрипты рядом с ним.
Несколько привычек снижают риск заметно. Поле allowed-tools задаёт минимум: запись Bash(git:*) пускает агента только к командам git, тогда как голый Bash открывает всю оболочку. Секреты и токены в навыках не хранятся: если в references попал ключ, он утечёт вместе с папкой при первой же передаче коллеге. Версии фиксируются в metadata, а изменения идут через ревью, как код. И каждый навык имеет владельца, иначе библиотека за полгода превращается в склад устаревших процедур, которые агент продолжает старательно выполнять.
С ростом обмена навыками между командами всё это начинает напоминать менеджер пакетов со всеми его хлопотами: версии, зависимости, доверие к автору. Передача формата нейтральному фонду как раз и нужна, чтобы такие вопросы решались общими правилами, а не частными договорённостями отдельных вендоров.
Первый практичный шаг при этом скромен. Достаточно выписать пять процедур, которые в команде объясняют заново каждую неделю, превратить одну из них в навык и проверить в двух разных агентах. Формат остался прежним, а срок жизни у записанных в него знаний теперь другой: то, что описано в SKILL.md сегодня, переживёт смену инструмента, а значит, окупится дольше любого одноразового промпта.