Що саме перевірили і чому цифри тут не декоративні
Я люблю такі публікації не за гучний заголовок, а за момент, де можна вказати пальцем на архітектурну помилку. Vercel прогнала агентів по задачах, де потрібна була документація Next.js, причому частина знань не була в попередньому навчанні моделі. Це вже нормальний тест на поведінку системи, а не красиве демо.
Схема була простою. Базовий агент без зовнішньої допомоги проходив тести (evals) на рівні 53%. Далі йому давали або skills, або AGENTS.md, і тут почалося найцікавіше.
Skills у цьому дизайні були влаштовані як папки з SKILL.md, метаданими, інструкціями та додатковими файлами. Агент мав спочатку зрозуміти, що потрібний skill взагалі існує, потім вирішити, що його треба викликати, і тільки потім завантажити вміст. На папері виглядає акуратно. У реальності агент часто просто не доходив до цього кроку.
За даними Vercel, skills самі по собі теж дали 53%. Тобто нуль приросту. Ще жорсткіше інше: приблизно в 56% випадків агент взагалі не викликав skill, хоча той був релевантним.
А ось AGENTS.md спрацював як постійний контекст у system prompt. Не треба нічого шукати, не треба приймати проміжне рішення про завантаження. Якщо в цей файл покласти стислий виклад документів або індекс, агент бачить його завжди. В evals у Vercel варіант з повним стислим контекстом в AGENTS.md досяг 100% успішності.
Мене тут зачепила не сама markdown-магія. Зачепило те, що markdown переміг не тому, що він красивий, а тому, що прибрав зайву точку відмови. Модель не забула викликати інструмент, тому що ви просто не залишили їй такого шансу.
Що це змінює в ШІ-архітектурі та впровадженні ШІ
Якщо перекласти це з мови benchmark'ів на мову продакшену, висновок дуже приземлений. Коли критичне знання для виконання завдання лежить в optional-механіці, ви будуєте крихку систему. Вона може бути елегантною на схемі, але нестабільною в бою.
Я це бачу постійно в проєктах з автоматизації на ШІ. Команда робить агенту набір tools, skills, шарів пам'яті, роутерів і ще трохи надії зверху. Потім усі дивуються, чому агент іноді розумний, а іноді ніби забув, де знаходиться.
Підхід з AGENTS.md підказує більш практичну архітектуру ШІ-рішень. Базові правила, індекс доменних знань, обмеження, формат відповіді та ключові маршрути треба тримати в постійному контексті. А skills і tools залишати для того, що справді потрібно підтягувати за вимогою: важкі довідники, зовнішні API, рідкісні процедури.
Тобто не «або-або», а нормальний гібрид. Я б формулював так: AGENTS.md для детермінованості, skills для розширюваності. Це вже схоже на дорослу ШІ-архітектуру, а не на набір фіч, які випадково опинилися в одному репозиторії.
Є й обмеження, і воно чесне. Вічний контекст не можна роздувати нескінченно. Vercel прямо показує, що сенс не в тому, щоб засунути в AGENTS.md всі документи цілком, а в тому, щоб стиснути їх до короткого, корисного, добре індексованого викладу. У них фігурував порядок 8 KB замість 40 KB вихідного матеріалу, і це звучить дуже розумно.
Хто виграє від такого зсуву? Команди, яким потрібна передбачувана автоматизація за допомогою ШІ: саппорт, внутрішні copilot'и, агентні workflow для розробки, ops та документообігу. Хто програє? Проєкти, де архітектура тримається на вірі, що модель «сама здогадається викликати потрібний модуль».
Я б не робив з цього універсальний закон природи. Це результати Vercel на конкретних evals навколо Next.js, і на інших задачах розклад може змінюватися. Але сигнал дуже сильний: при впровадженні штучного інтелекту в реальні процеси треба проєктувати не тільки знання агента, але й шлях доступу до цих знань.
Ми в Nahornyi AI Lab якраз на цьому місці найчастіше і ріжемо зайве. Не додаємо агенту ще десять абстракцій, а прибираємо одне зайве рішення, яке він приймає нестабільно. І раптово все починає працювати краще, дешевше і спокійніше.
Розбір зробив я, Вадим Нагорний, у Nahornyi AI Lab. Я займаюся розробкою ШІ-рішень і збираю агентні системи руками, тому такі деталі для мене не теорія, а щоденна інженерна рутина. Якщо хочете обговорити ваш кейс, впровадження ШІ або зробити ШІ-автоматизацію без крихкої магії, пишіть мені. Подивимося на ваш проєкт разом.