Кожна агентна система стикається з одним і тим самим незручним компромісом. Ви хочете мати глибоку, добре організовану базу знань, яка витримує перевірку коду (code reviews) та зберігається в історії git. Але вам також потрібно, щоб середовище виконання (runtime) працювало швидко та залишалося зосередженим. Ці дві потреби суперечать одна одній. Чим більше інструкцій ви зберігаєте, тим спокусливіше стає вивалити їх усі в промпт і сподіватися на краще. Це сподівання коштує дорого.

В екосистемі Agent Project Context це напруження чітко розділене між двома рівнями. APC відповідає за довговічність. APX — за швидкість. Розуміння того, як вони взаємодіють — і чому APX відмовляється попередньо завантажувати кожне визначення навички — розповідає про промпт-інжиніринг більше, ніж більшість посібників з оптимізації.

Архів та рушій

Завдання APC — забезпечення постійності. Він зберігає файли навичок, що підлягають повторному використанню, у папці .apc/skills/ як звичайні Markdown-документи. Оскільки ці файли знаходяться всередині вашого репозиторію, вони зберігаються разом із системою контролю версій. Ви можете відкрити pull request, який змінює процедуру розгортання. Ви можете зробити diff відкату політики безпеки, що відбувся шість тижнів тому. Ви можете провести аудит того, що саме мав знати агент і коли. Така можливість перевірки є критично важливою, коли розгортання проходить невдало або коли аудитор відповідності починає ставити запитання.

APX, з іншого боку, живе моментом. Він керує безпосередньою розмовою між вами та моделлю. Його мета — не архівувати знання, а використовувати їх точно. Коли APX сприймає навички як постійний вантаж, вся система сповільнюється. Контекстне вікно заповнюється. Витрати токенів зростають. Гірше того, увага моделі розсіюється між інструкціями, які не мають жодного стосунку до поточного запиту.

Ось чому тіла навичок завантажуються за запитом.

Справжня ціна перевантаженого промпту

Більшість команд розуміють, що токени коштують грошей. Менше команд усвідомлюють, що нерелевантні токени коштують точності.

Коли APX впорскує кожну доступну навичку в кожен крок розмови, промпт стає зашумленим. Модель одночасно отримує deployment runbook, посібник із безпеки, довідник стилю API, чек-лист тестування та FAQ з онбордингу. Навіть із великим контекстним вікном якість міркувань погіршується, коли моделі спочатку доводиться просіювати шум, щоб знайти сигнал. Вона може зачепитися за вимогу безпеки, призначену для розгортання в продакшн, відповідаючи на запитання про локальне налаштування тестування. Вона може «галюцинувати» кроки з чек-листа релізу під час простого виправлення помилки. Кожен зайвий абзац непов'язаного тексту — це відволікаючий фактор, який чекає на свій момент.

Математика проста. Більшості кроків не потрібні більшість навичок. Якщо ви просите швидко виправити помилку в логах, вам не потрібен повний текст deployment runbook або посібник із посилення безпеки. Вам потрібно, щоб модель побачила помилку, зрозуміла конвенції вашого проєкту та відредагувала потрібний файл. Завантаження нерелевантних тіл навичок не допомагає моделі зробити це. Це змушує модель відфільтровувати марні дані ще до того, як вона почне працювати над вашою реальною проблемою.

Як працює завантаження за запитом

Механізм простий, але продуманий. APC продовжує утримувати першоджерело (ground truth). Ваші визначення навичок залишаються там, де їм і належить бути: у .apc/skills/<name>.md.

APX не дублює ці файли в активну пам'ять. Замість цього він створює компактний реєстр назв навичок. Модель бачить цей список і розуміє, що існує каталог. Якщо їй потрібно переглянути або підтвердити, які можливості доступні, вона може викликати list_skills. Це забезпечує видимість без зайвого об'єму.

Коли завдання фактично потребує точного синтаксису, детальних кроків або специфічних обмежень, закодованих у файлі навички, модель викликає load_skill. У цей момент, і тільки в цей момент, APX отримує повне тіло Markdown з APC і впорскує його в контекст. Інструкція надходить «гарячою», використовується один раз за призначенням, і система уникає перенесення її як мертвого вантажу.

Уявіть різницю між імпортом бібліотеки та копіюванням визначення кожної функції у ваш основний файл. Один підхід робить ваш кодовий базис зручним для навігації. Інший створює безлад, який компілюється лише випадково.

Хто перемагає, коли навички конфліктують

APX також забезпечує чіткий порядок пріоритетів, коли завантажує навички. Не кожне середовище є однаковим, і загальні поради ніколи не повинні перекривати локальні знання.

Навички проєкту мають найвищий пріоритет. Ці файли розміщуються у вашому поточному репозиторії в папці .apc/skills/. Вони фіксують специфічні конвенції вашої команди, ваші кастомні обгортки, застарілі стандарти іменування та ваш конкретний інструментарій. Якщо ваш проєкт визначає власний спосіб обробки міграцій баз даних, саме це визначення матиме перевагу.

Далі йдуть глобальні навички. Вони охоплюють патерни в масштабах усієї організації, які застосовуються, коли сам проєкт не надає жодних інструкцій. Вони діють як стандартна бібліотека.

Вбудовані навички середовища виконання (runtime skills) знаходяться в самому низу як резервний варіант. Вони забезпечують загальні можливості, які має розуміти кожен агент, але які жоден конкретний проєкт не намагався перевизначити.

Такий багаторівневий підхід означає, що ваш репозиторій зберігає контроль над власною поведінкою. Глобальна або вбудована навичка не може випадково перехопити робочий процес, який ваша команда навмисно налаштувала під себе.

Як це виглядає на практиці

Уявіть типове завдання з технічного обслуговування. Колега вставляє лог помилки в чат. Traceback вказує на одне посилання на null у модулі утиліт. Виправлення, ймовірно, полягає у двох рядках захисного кодування.

У системі без завантаження за запитом APX заповнила б контекст усіма відомими їй навичками. Тепер моделі доводиться аналізувати сорок сторінок тексту, перш ніж торкнутися тих двох рядків. Вона бачить чек-лист релізу і думає, чи варто підвищити версію. Вона бачить посібник із безпеки і роздумує над валідацією вхідних даних у функції, якій просто потрібна перевірка на null. Вона бачить інструкцію з розгортання (deployment runbook) і починає думати про стейджинг-середовища. Модель втрачає фокус. Відповідь займає більше часу. Лічильник токенів крутиться.

Завдяки дизайну APX із завантаженням за запитом, модель бачить лише назви. Вона знає, що існують [release-checklist], [security-guide], [deployment-runbook] та [error-handling]. Вона ігнорує перші три. Вона може завантажити [error-handling], якщо конвенції вашого проєкту щодо безпеки null є специфічними. Вона виправляє баг. Непов'язані навички так і не потрапили у вікно контексту. Модель залишалася зосередженою, тому що промпт залишався чистим.

Та сама логіка діє і тоді, коли завдання дійсно складне. Якщо пізніше ви попросите агента підготувати розгортання в продакшн, він зможе завантажити інструкцію з розгортання, звернутися до посібника з безпеки та дотримуватися чек-листа релізу саме тоді, коли ці кроки стануть актуальними. Знання завжди були на місці. Вони просто чекали слушного моменту.

Дисципліна промптів як архітектура

Розділення між APC та APX — це не просто деталь реалізації. Це філософія дисципліни промптів. APC зберігає знання назавжди, роблячи їх доступними для перегляду, версіонованими та безпечними. APX вирішує, яка частина цих знань заслуговує на місце в активному контексті саме зараз.

Багатий каталог навичок — це актив. Роздутий промпт — це пасив. Мета полягає в тому, щоб зробити ваш контекст портативним, не роблячи його постійно активним. Ваш репозиторій має містити кожну інструкцію, яку коли-небудь писала ваша команда, але агент має читати лише ті, що допомагають із безпосереднім завданням.

Якщо ваша система змушує модель переносити зміст кожної навички у кожен крок діалогу, ви будуєте не інтелектуального помічника. Ви будуєте бібліотекаря, який тягне весь архів до кожного запитання біля довідкової стійки. Зберігайте все. Завантажуйте те, що важливо. Саме так ви забезпечите швидкість агентів, чистоту контексту та гостроту міркувань.