Поведінка AI-агента в проєкті давно залежить не лише від моделі, а й від того, що ми йому підклали: CLAUDE.md чи AGENTS.md, навички (skills), промпти, плагіни, MCP-сервери. Усе це - залежності, і з ними ті самі проблеми, які Composer розв'язав для PHP-коду: як відтворити налаштування на іншій машині, як оновлювати і як не отримати підмінений вміст. На цю проблему звернув увагу Аміт Мерчант, а інструмент, що пропонує відповідь, - Agent Package Manager (APM).
Що таке APM
APM - відкритий менеджер залежностей для конфігурації AI-агентів у репозиторії Microsoft. Автор і основний мейнтейнер - Даніель Мепієль (Daniel Meppiel), поруч працює спільнота: в останньому випуску 0.35.0 від 22 жовтня - понад п'ятдесят PR, зокрема від шести нових контриб'юторів.
Ідея знайома кожному, хто працював із composer.json:
apm.yml - маніфест: які навички, інструкції, промпти, агенти, хуки, плагіни й MCP-сервери потрібні проєкту;apm install - встановлює їх, з транзитивними залежностями, і розкладає по каталогах конкретних агентів (.claude/, .github/, .cursor/ тощо);apm.lock.yaml - lock-файл із точними комітами й SHA-256 хешами вмісту; його комітять, як composer.lock.
Пакети беруться прямо з git-репозиторіїв (GitHub, GitLab, Bitbucket, Azure DevOps та інших), без центрального реєстру. Серед підтримуваних агентів README називає GitHub Copilot, Claude Code, Cursor, Codex, Gemini, OpenCode, Windsurf, Kiro і Grok Build. Ставиться через brew install apm, pip install apm-cli або інсталятор для Linux, macOS і Windows.
Приклад apm.yml для Laravel-проєкту
Нижче - маніфест, зібраний лише з пакетів, які справді існують. Навички Laravel Cloud і Nightwatch лежать в офіційному репозиторії laravel/agent-skills, frontend-design - у репозиторії навичок Anthropic, а MCP-сервер Laravel Boost описано як локальний stdio-процес за документацією Boost:
name: my-laravel-app
version: 1.0.0
targets: [claude, copilot, cursor]
dependencies:
apm:
# Розгортання в Laravel Cloud
- laravel/agent-skills/laravel-cloud/skills/deploying-to-cloud
# Налаштування Laravel Nightwatch
- laravel/agent-skills/laravel-nightwatch/skills/configure-nightwatch
# Верстка інтерфейсів
- anthropics/skills/skills/frontend-design
mcp:
# MCP-сервер Laravel Boost, що працює всередині застосунку
- name: laravel-boost
registry: false
transport: stdio
command: php
args: ["artisan", "boost:mcp"]
Далі новий розробник у команді робить одне:
git clone <repo> && cd <repo>
apm install
У CI варто ставити apm install --frozen: команда бере коміти з lock-файлу без жодного розв'язання версій і падає, якщо записів бракує. Перед першим встановленням корисно подивитися план через apm install --dry-run.
Окремо про оновлення: з 3 листопада Dependabot підтримує APM. Досить додати в .github/dependabot.yml екосистему apm, і він відкриватиме PR з оновленнями git-залежностей та перегенерованим apm.lock.yaml. Поки що це лише оновлення версій, без сповіщень безпеки.
APM і Laravel Boost: конкуренти чи доповнення
На перший погляд Boost робить те саме: php artisan boost:install генерує гайдлайни в CLAUDE.md чи AGENTS.md, ставить навички й прописує MCP-сервер у .mcp.json. Але підходи різні.
Boost знає Laravel. Він дивиться у ваш composer.json і ставить навички під наявні пакети: є livewire/livewire - з'явиться livewire-development, є Pest - pest-testing. Пакети екосистеми можуть класти власні гайдлайни й навички в resources/boost/, а версіонуються вони разом із Composer-пакетом. Плюс MCP-сервер Boost дає агенту доступ до бази, логів, маршрутів і пошуку по документації. Гайдлайни й .mcp.json Boost навіть дозволяє додати в .gitignore: вони перегенеровуються командою boost:update.
APM знає git і агентів. Йому байдуже, Laravel у вас чи React: він тягне будь-які навички з будь-якого репозиторію, фіксує коміти й хеші та розкладає вміст по різних агентах. Це шар для всього, що лежить поза Composer: навички з GitHub, внутрішні інструкції компанії, сторонні MCP-сервери.
Тож це радше доповнення. Розумний розподіл такий: Boost відповідає за все, що виводиться з Composer-залежностей, APM - за решту. Одне застереження: не давайте двом інструментам керувати тим самим. Якщо boost:install уже прописав laravel-boost у .mcp.json, оголошувати його ще й в apm.yml не обов'язково - оберіть одного власника цього запису.
Lock-файл як захист від підміни навичок
Документація APM формулює головну відмінність точно: звичайний пакет лежить на диску інертно, доки його не запустять, а навичку чи інструкцію агент може прочитати, щойно файл з'явився в .claude/. Тобто поява файлу вже рівнозначна виконанню, і перевіряти треба до розгортання.
Що APM робить для цього:
- фіксує коміти. Повторне
apm install бере коміт із lock-файлу, навіть якщо автор пакета переписав тег чи гілку;
- перевіряє хеші. Для кожного пакета зберігається SHA-256 його вмісту. Якщо свіжозавантажений вміст не збігається із записом, встановлення переривається як можлива підміна;
- шукає прихований Unicode. Кожне встановлення перевіряє файли на невидимі символи, якими можна сховати інструкції від людини, але не від моделі. Те саме на вимогу робить
apm audit;
- питає згоди на транзитивні MCP-сервери, які підтягує чужий пакет.
Тут є прямий зв'язок зі slopsquatting - атакою, коли зловмисник реєструє пакет під назвою, яку моделі вигадують у своїх відповідях. Агент чи розробник пише apm install з правдоподібним, але чужим owner/repo, і в проєкт приходить чужий вміст. Lock-файл тут не допоможе: він гарантує, що ви щоразу отримуєте те саме, але не те, що першого разу ви встановили правильне. APM прямо пише, що не підписує пакети й не аналізує код залежностей на шкідливість. Тому назву репозиторію перевіряйте очима, а не з підказки агента.
І, як слушно зауважує Мерчант, PR від Dependabot з оновленням навички треба читати так само уважно, як зміни коду: змінена інструкція міняє поведінку агента без жодного рядка в app/.
Чи варто братися
APM - ранній проєкт: версія 0.35.0, частина можливостей позначена як експериментальна, а lock-файл описано як робочу чернетку специфікації. Формати ще можуть змінюватися, тож закладатися на нього як на обов'язковий стандарт команди поки зарано.
Що можна зробити вже зараз:
- якщо вам вистачає того, що дає Boost, нічого не змінюйте;
- якщо ви копіюєте навички з GitHub між проєктами руками, спробуйте APM на одному з них і закомітьте
apm.yml разом з apm.lock.yaml;
- у CI використовуйте
apm install --frozen і apm audit;
- оновлення навичок переглядайте як звичайний PR, а нові залежності додавайте лише з репозиторіїв, автора яких ви знаєте.
