Что такое QM?
Установка
Скажите своему агенту для написания кода: Let’s deploy https://github.com/yc-software/qm. Дальше он должен следовать руководству по развёртыванию из этого репозитория.
Что такое QM?
Большинство агентов созданы по модели личного помощника. Одного такого агента можно приспособить для работы на целую компанию, но быстро всё становится сложным. QM ориентирован на стартапы. Каждый сотрудник получает собственное изолированное рабочее пространство и работает независимо, не мешая коллегам, — при этом все могут совместно взаимодействовать с агентом в каналах Slack, групповых чатах и проектах.
У каждого пользователя и у каждой комнаты есть своя изолированная память, файлы, представление хранилища ключей (keychain), разрешения, кроны, веб-приложения и долгоживущая песочница.
Система изначально строилась с расчётом на открытый исходный код. Вы сами выбираете оболочку (harness) и модель и можете переключаться между ними — Pi, OpenCode, Codex и Claude Code управляют одним и тем же ядром, так что развёртывание не привязано к конкретному поставщику.
Возможности
-
Личные и общие области видимости (scopes). Каждый настраивает агента под себя, но при этом может работать с ним совместно в каналах Slack и проектах.
-
Slack и веб. Единые идентификация и конфигурация работают как в Slack, так и в веб-приложении.
-
Административный контроль. Можно задать конфигурацию на уровне организации, политику безопасности, а также перечень доступных оболочек и моделей.
-
Веб-приложения. Поднимайте кастомные внутренние приложения и публикуйте их для нужных сотрудников.
-
Общие навыки (skills). Навыки принадлежат определённой области видимости и могут предоставляться по разрешению; администратор может продвигать их на уровень всей организации, а пакеты навыков импортируются из git-репозиториев.
-
Фоновая работа. Кроны, наблюдатели (watches) и входящие вебхуки выполняют задачи, пока никто не смотрит.
Что можно делать с QM
-
Искать по внутренним заметкам, электронной почте, документам, базам данных и вебу одновременно
-
Извлекать информацию из корпоративной базы знаний
-
Создавать внутренние приложения, публиковать их для нужных людей и поддерживать актуальность их данных
-
Обучать агента вашему стилю письма на основе прошлых отправлений, а затем по расписанию разбирать входящие — с метками и черновиками ответов
-
Работать в существующем репозитории: запускать тесты, открывать PR, следить за CI, проверять системные логи
-
Вести проект в общем канале, публиковать обновления и follow-up сообщения
Архитектура
flowchart LR
DB[("Postgres<br/>sessions · memory · queue")]
subgraph CORE["Headless core"]
API["API · identity · policy · scheduler"]
LOOP["Agent loop<br/>(Pi, OpenCode, Claude Code)"]
API <--> LOOP
end
SBX["Per-scope sandbox<br/>files · tools · logged-in services"]
DB <--> API
LOOP <--> SBX
Каждый шаг (turn) проходит через центральное ядро (core), которое может использовать разнообразные модели и оболочки для формирования ответа. Уровень хранения данных на Postgres содержит данные пользователей, историю сессий и другое долгоживущее состояние. Агент располагает небольшим фиксированным набором инструментов; один из них — execute, запускающий команды в изолированной песочнице области видимости — долговечном компьютере, где установленные инструменты остаются установленными. Веб-интерфейс, панель администратора и публичный портал — это опциональные плагины поверх HTTP API ядра; Slack — опциональный внутрипроцессный (in-process) плагин, который ядро запускает и контролирует через прямой сервисный клиент.
Ядро запускает TypeScript непосредственно на Node и использует Fastify для HTTP. Плагин Slack использует Bolt; веб-интерфейс собирается с помощью Vite и рендерится с помощью Lit.
Само ядро является универсальным. Всё специфичное для конкретной компании — конфигурация организации, кастомные инструменты и навыки, образ песочницы, инфраструктура — хранится в каталоге развёртывания (deployment directory), который qm CLI проверяет и деплоит. Каждый субстрат (оболочка, хранилище сессий, песочница, память) скрыт за интерфейсом, поэтому production-реализации подключаются через единый файл конфигурации зависимостей.
Безопасность и секреты
Подход QM к безопасности следует практике локальных агентов написания кода — OpenCode, Codex и Claude Code: агент действует от имени того пользователя, для которого работает, с его учётными данными и разрешениями, и все его действия аудируются. Организация выбирает одну политику безопасности, которую более узкие области видимости могут только ужесточить:
-
Strict (строгий) — каждый вызов инструмента оболочкой приостанавливается для подтверждения человеком, за исключением двух финальных действий без побочных эффектов.
-
Auto (автоматический) (по умолчанию) — классификатор проверяет внешние данные с метками происхождения (provenance-labelled) и результаты инструментов до передачи их модели; развёртывание может указать собственный прокси для проверки.
-
Dangerous (опасный) — без фильтрации содержимого, без пауз между вызовами инструментов.
Заранее объявленная политика команд — правила подтверждения и жёсткие запреты на такие операции, как рекурсивное удаление или деструктивный SQL — применяется при любой политике безопасности, включая Dangerous.
SECURITY.md содержит модель угроз, допущения оператора и известные ограничения.
Развёртывание для вашей организации
Создайте репозиторий развёртывания, принадлежащий организации, с зависимостью от @yc-software/qm:
npm exec --yes --package=@yc-software/qm@latest -- \
qm init . --org <slug> --target <fly-or-aws>
npm install
В процессе инициализации для агента материализуется навык развёртывания и выполняется пошаговая настройка инфраструктуры, входа через веб, учётных данных коннекторов, опционального доступа к Slack, деплоя и финальной проверки — без необходимости клонировать исходный код. Каждое развёртывание работает в собственном облачном аккаунте оператора; инициализация не создаёт и не активирует CI для деплоя, и в этом репозитории нет рабочего процесса деплоя в production. Подробности — в deployment.md.
Участие в разработке
Мы принимаем вклады в виде текста, написанного человеком, — не кода; подробности в CONTRIBUTING.md. Опишите желаемое изменение в свободной форме в файле .txt или .md в папке adrs/, и если мы согласны с направлением, реализацию возьмём на себя. Об уязвимостях сообщайте приватно — через SECURITY.md, не через публичный issue.
Кастомизация вашего экземпляра
Описанный выше репозиторий развёртывания содержит конфигурацию и слой песочницы и никогда не требует клонирования исходного кода. Некоторые организации предпочитают другой подход: хранить весь код в одном месте, чтобы инженеры и агенты читали ядро и кастомизации вместе, при этом сохраняя кастомизации в приватном доступе. Для этого следует использовать приватный форк (private fork) — самостоятельный приватный репозиторий, история которого начинается как клон qm, а ядро остаётся идентичным upstream-версии.
Наполните его один раз, а затем клонируйте для работы:
gh repo create <org>/qm-private --private
git clone --bare git@github.com:yc-software/qm qm-seed.git
git -C qm-seed.git push --mirror git@github.com:<org>/qm-private
rm -rf qm-seed.git
git clone git@github.com:<org>/qm-private
git -C qm-private remote add upstream git@github.com:yc-software/qm
Создавайте приватный форк обычным клоном, как показано выше, — и никогда не используйте для этого функцию Fork на GitHub. Слово «форк» здесь обозначает концепцию — нижестоящую копию, которая намеренно расходится и принимает слияния из upstream, — а не кнопку Fork на GitHub. GitHub-форк наследует видимость исходного репозитория, поэтому форк публичного репозитория нельзя сделать приватным. GitHub-форк также разделяет сеть объектов с исходным репозиторием, так что коммиты, отправленные в форк, остаются доступными по SHA с публичной стороны. Многие организации также запрещают форкать приватные репозитории. У обычного клона ни одной из этих проблем нет, и это стоит лишь одного: клон является обычным репозиторием, поэтому CI-воркфлоу upstream будут запускаться в вашем аккаунте. Будьте готовы передать им нужные секреты или отключить те, что вам не нужны.
Всё специфичное для вашей организации размещается в deploy/layers/<org>/ — конфигурация, инструменты и навыки для песочницы, образы плагинов, инфраструктура — в той же структуре, которую создаёт qm init. Подробности — в deploy/layers/README.md. Ядро остаётся побайтово идентичным upstream — именно это делает слияния небольшими.
Два навыка поддерживают эту границу в обоих направлениях. update-qm сливает upstream qm в приватный форк и открывает PR синхронизации; upstream-pr отправляет исправление, не зависящее от конкретной организации, обратно в qm: создаёт ветку от upstream/main и перед отправкой проверяет исходящий diff, сообщения коммитов и скриншоты на наличие идентификаторов организации. Ничто из deploy/layers/ никогда не попадает в upstream.
Дополнительные материалы
-
docs/getting-started.md— первый запуск от начала до конца -
cli/README.md— CLIqmи контракт каталога развёртывания -
docs/deploy-directory.md— подробное описание каталога развёртывания -
.env.example— все настройки с документацией прямо в файле -
plugins/— интерфейсы (Slack, веб-интерфейс, панель администратора, портал)
Лицензия
За исключением особо оговорённых случаев, QM распространяется по лицензии MIT.