Настрой всички AI агенти за код от един файл за 0 € с Microsoft APM

Накратко

APM е безплатен пакетен мениджър от Microsoft с MIT лиценз. Инсталира едни и същи умения, промптове, плъгини и MCP сървъри в девет различни инструмента за код от един файл.
Пишеш apm.yml, пускаш apm install, и всеки колега получава същата настройка след git clone.
Парите: без ръчно копиране на настройки в всеки проект. При моите примерни числа са около 670 € годишно за екип от четирма.

Настройваш агента за код веднъж. После започваш нов проект и го настройваш пак. После нов колега го настройва по трети начин. Това са платени часове, хвърлени на вятъра.

Старото решение е вики страница и папка с файлове за копиране. Новото е пакетен мениджър за контекста на агентите. Цена: нищо.

Какво е APM

APM е Agent Package Manager. Документацията го описва като npm за контекста на агентите. Във един файл посочваш какво ти трябва на агентите, а една команда го настройва на правилното място за всеки инструмент.

Проектът е в GitHub организацията на Microsoft и е отворен код с MIT лиценз. Страницата с документация, която ползвам, е обновена на 22 октомври 2026. Поддържаните инструменти в документацията са: GitHub Copilot, Claude Code, Grok Build, Cursor, OpenCode, Codex, Gemini, Windsurf и Kiro.

Колко струва

Елемент	Цена
Самият APM (MIT, отворен код)	0 €
Инсталиране на пакети от git сървъри	0 €, плащаш само хостинг, който вече имаш
Инструментите за агенти, които захранва	Колкото вече плащаш за тях

Как да го настроиш

Давам само стъпките, които показва официалната документация. За твоята платформа провери тях.

Инсталирай APM. На macOS с Homebrew: brew install apm. Документацията покрива и pip, Scoop, ръчна инсталация и самостоятелни инсталатори за Unix. На Unix може да трябва да настроиш PATH.
Пробвай примерния пакет. Пусни apm install microsoft/apm-sample-package. Това е примерът на Microsoft, така виждаш какво къде отива, преди да вярваш на нещо свое.
Създай apm.yml в корена на проекта. Има име, версия и секция dependencies.
Попълни двата списъка. Под apm слагаш пакети от GitHub, GitLab, Azure DevOps, Bitbucket или който и да е git сървър, с незадължителен път и референция към версия, например #v2.1. Под mcp слагаш MCP сървъри, например io.github.github/github-mcp-server.
Пусни apm install. Той разпределя посоченото към поддържаните инструменти на машината ти.
Комитни apm.yml. Колега пуска git clone <repo> && cd <repo> && apm install и получава същата настройка.

Закачи версиите с # референцията. Ако пакет се промени утре, агентите ти не бива да се променят заедно с него.

Сигурността, която има значение

Уменията и промптовете са указания към агент, който може да пуска команди. Лош пакет е реална атака. Документацията на APM казва, че инсталациите сканират за скрит Unicode, закачат хешове на съдържанието и блокират прозрачни MCP сървъри, ако не са посочени или доверени.

Има и файл apm-policy.yml, който се прилага при инсталация. Политиката може само да се стяга от фирмата към организацията и към репото. Репо не може да разхаби настройките на фирмата. За екип с данни на клиенти това е най-важната функция.

Сметката

Това са мои предположения, не числа на Microsoft. Екип от четирма започва 10 проекта годишно. Ръчната настройка на умения и сървъри отнема 45 минути на човек на проект. При 25 € на час са 4 × 0,75 ч × 25 € = 75 € на проект, или 750 € годишно.

С APM всеки отнема около 5 минути за clone и install. Това са 4 × 5 мин = 20 минути, около 8 € на проект, или около 83 € годишно. Спестяването е около 667 € на година. Не е животопроменящо. Но маха и проблема „тук ми работи“, който струва повече от минутите.

Къде се вписва

Три случая, където ясно се отплаща. Първо, малка агенция с много клиентски репота, които изискват едни и същи правила за агента. Второ, екип с разни инструменти, например един с Claude Code, друг с Cursor. Един apm.yml обслужва и двама. Трето, собственик, който иска същите MCP сървъри на нов лаптоп за пет минути.

Ако работиш сам в един инструмент и един репо, не го изискваш. Държи файловете си в папка и продължи.

Безопасен план за внедряване в екип

Не преключвай всички в понеделник. Избери едно малко репо и един човек. Пусни примерния пакет, после напиши минимален apm.yml с два-три пакета, които вече си прочел. Закачи всеки с референция към версия.

След седмица питай какво се е счупило. Ако нищо, добави файла във второ репо и позволи на още един колега да направи clone и install. Само тогава го запиши в страницата за нови колеги. Един месец така ти струва няколко часа и ти дава настройка, на която можеш да разчиташ.

Ограничения и слаби места

Бъди честен какво е това. Документацията казва, че примерът за манифеста следва работен черновата на договора и не включва реда $schema. Казва ито, че по-стари публикувани схеми отхвърлят формата git плюс път. На прост език: форматът още се мести.

APM инсталира неща. Не контролира поведението при работа, защото всеки инструмент решава как да ползва умението. Същият пакет може да се поведе малко по-различно в два инструмента. А пакетният мениджър е толкова безопасен, колкото са пакетите, които избереш. Чети какво инсталираш и предпочитай източници, които познаваш.

Алтернативи

Споделена папка в репото. Копираш умения и промптове ръчно. Безплатно, просто, но се чупи щом ползваш два инструмента.
Симлинкове между конфиг файлове. Един разработчик написа тази седмица, че синхронизирането на AGENTS.md и CLAUDE.md с копиране или симлинк е едно от ежедневните му безпокойства. За два файла работи, за двадесет не.
Вградената инсталация на плъгини в всеки инструмент. Ок ако ползваш един. За всеки допълнителен повтаряш работата.

Мнението на Иван

Струва си, ако имаш екип или повече от един инструмент. Безплатен е, MIT е, а файлът с политики е правилната идея. Бих го тествал първо върху един некритичен репо, бих закачил всека версия и бих прочел всеки пакет, преди да се допре до машината ми. Ако си сам в един инструмент, прескочи го за сега. Върни се, когато форматът стане стабилен.

Източници: Microsoft · Caleb Software

За автора

Ivan Ivanov

Основател на