.agents и папка-как-агент: экосистема конфигураций

Что это и зачем

В 2026 году вокруг AI coding-агентов сформировался отдельный слой инженерной инфраструктуры: не только промпты, но и версионируемые конфиги, политики доступа, reusable skills, sub-агенты и долгоживущая память.

Если коротко:

AGENTS.md даёт человеко-читаемые инструкции по проекту.
.agents/ добавляет структурированную папку с конфигами и переиспользуемыми модулями.
.agent/ (proposal) предлагает хранить не только правила для кода, но и проектный контекст: требования, архитектуру, внешние ссылки.

Три линии экосистемы

Подход	Статус	Что решает
AGENTS.md	Production	Инструкции для агента: команды, границы, стиль, workflow
.agents Protocol	Draft	Унификация конфигов: MCP, skills, sub-agents, tasks, memories
.agent proposal	Proposal	Структурированный проектный контекст (spec/wiki/links)

Главная идея не в «победе одного стандарта», а в совместном использовании: AGENTS.md как базовый контракт, .agents как операционный слой, .agent как расширение контекста для сложных команд и продуктов.

Как устроен .agents Protocol

Обычно используется двухслойная схема:

~/.agents/ — глобальные настройки разработчика на машине.
./.agents/ — проектные настройки, которые хранятся в git.

Типичные директории и файлы:

agents.md — AGENTS.md-совместимые инструкции.
mcp.json — конфигурация MCP-серверов.
models.json — модельные пресеты.
skills/ — переиспользуемые скиллы.
agents/ — профили sub-агентов.
tasks/ — повторяемые задачи.
memories/ — персистентные заметки и решения.

Практический эффект для команды:

Можно версионировать «поведение агента» так же, как код.
Проще воспроизводить рабочую среду между разработчиками.
Легче формализовать границы доступа и безопасные команды.

Где здесь .agent/ (singular)

.agent/ чаще обсуждается как «директория проектной памяти»:

spec/ — требования и технический дизайн,
wiki/ — архитектурная и доменная база,
links/ — внешние системы (Jira, Figma, observability).

Этот подход особенно полезен, когда агенту нужно сопоставлять код с продуктовым контекстом, а не только с style guide.

Сравнение с альтернативами

Вариант	Плюсы	Ограничения
Только AGENTS.md	Просто стартовать, минимум поддержки	Сложно масштабировать на policies, tasks и skills
AGENTS.md + SKILL.md	Отлично для task-level экспертности	Нужен отдельный контур для shared config и governance
AGENTS.md + .agents	Хорошо масштабируется в команде	Требует дисциплины по структуре и ревью конфигов
Полный стек (AGENTS.md + .agents + .agent-подход)	Максимальный контроль и переносимость контекста	Риск переусложнения для маленьких проектов

Цены и модель использования

Для большинства команд базовая стоимость внедрения — это время на настройку структуры и регламентов:

Форматы и Markdown-спеки обычно открытые и бесплатные.
Затраты появляются на уровне инфраструктуры (MCP-серверы, приватные registry, CI-проверки).
Для небольших команд разумно начинать с AGENTS.md и добавлять .agents по мере роста.

Практические сценарии

1) Небольшой проект (1-3 разработчика)

Начать с AGENTS.md и минимального набора skills.
Добавить .agents/skills только для повторяемых задач (релиз, миграции, аудит).

2) Монорепозиторий

Root AGENTS.md + локальные AGENTS.md в подпроектах.
.agents/agents для специализированных sub-агентов (docs, test, security).
Единые policy-файлы для запретных путей и pre-approved команд.

3) Продуктовая команда с внешними системами

Подход .agent/spec/wiki/links для связи требований, архитектуры и операционных данных.
MCP-интеграции к трекерам задач, документации и мониторингу.

Риски и анти-паттерны

Переусложнение на раннем этапе: много файлов без реальной необходимости.
Дублирование инструкций между AGENTS.md и .agents/agents.md.
Отсутствие owner-а за конфиги: структура есть, но никто не поддерживает актуальность.

Рабочее правило: вводить новый слой только когда текущий уже стал узким местом.