---
title: "APM: менеджер залежностей для навичок, промптів і MCP-серверів AI-агентів"
url: https://laravelukraine.com/blog/apm-menedzer-zaleznostei-dlia-navicok-promptiv-i-mcp-serveriv-ai-agentiv
date: 2026-11-13
---

# APM: менеджер залежностей для навичок, промптів і MCP-серверів AI-агентів

Поведінка AI-агента в проєкті давно залежить не лише від моделі, а й від того, що ми йому підклали: `CLAUDE.md` чи `AGENTS.md`, навички (skills), промпти, плагіни, MCP-сервери. Усе це - залежності, і з ними ті самі проблеми, які Composer розв'язав для PHP-коду: як відтворити налаштування на іншій машині, як оновлювати і як не отримати підмінений вміст. На цю проблему звернув увагу [Аміт Мерчант](https://www.amitmerchant.com/ai-agent-dependencies-management/), а інструмент, що пропонує відповідь, - [Agent Package Manager (APM)](https://github.com/microsoft/apm).

### Що таке APM

APM - відкритий менеджер залежностей для конфігурації AI-агентів у репозиторії Microsoft. Автор і основний мейнтейнер - Даніель Мепієль (Daniel Meppiel), поруч працює спільнота: в останньому випуску [0.35.0 від 22 жовтня](https://github.com/microsoft/apm/releases/tag/v0.35.0) - понад п'ятдесят 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](https://github.com/laravel/agent-skills), `frontend-design` - у репозиторії навичок Anthropic, а MCP-сервер Laravel Boost описано як локальний stdio-процес за [документацією Boost](https://laravel.com/docs/boost):

```yaml
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"]
```

Далі новий розробник у команді робить одне:

```bash
git clone <repo> && cd <repo>
apm install
```

У CI варто ставити `apm install --frozen`: команда бере коміти з lock-файлу без жодного розв'язання версій і падає, якщо записів бракує. Перед першим встановленням корисно подивитися план через `apm install --dry-run`.

Окремо про оновлення: з [3 листопада Dependabot підтримує APM](https://github.blog/changelog/2026-11-03-dependabot-version-updates-support-agent-package-manager). Досить додати в `.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, а нові залежності додавайте лише з репозиторіїв, автора яких ви знаєте.