QM — платформа, на которой команда работает с ИИ-агентом через Slack и веб-приложение. Она снимает задачу, которую трудно решить личным чатом: дать сотрудникам отдельные рабочие пространства и при этом позволить им работать с агентом в общих каналах и проектах. QM разворачивают в собственном облачном аккаунте организации, со своими моделями и ключами.
Как QM разделяет личную и общую работу
В QM у каждого человека и каждой комнаты есть своя область: память, файлы, доступные ключи, разрешения и рабочая среда агента. Память здесь — сохранённый контекст, к которому агент может обращаться в дальнейшей работе. Рабочая среда, или песочница, — отдельное место, где агент хранит файлы, устанавливает инструменты и запускает команды. Состояние этой среды сохраняется между обращениями.
Такое разделение нужно, когда личная переписка и обсуждение проекта не должны смешиваться автоматически. Сотрудник может настроить агента под себя, а затем работать с ним вместе с коллегами в канале Slack или проекте. В README отдельно указано, что одна и та же личность пользователя и конфигурация используются в Slack и веб-приложении; сам Slack при развёртывании необязателен.
Агентом может управлять Pi или Claude Code. Это два варианта механизма, который получает задачу и ведёт работу с инструментами; Pi, согласно README, поддерживает модели разных поставщиков. Администратор выбирает, какие механизмы и модели доступны организации. Это не означает, что QM сам предоставляет модель или оплачивает её использование: развёртывание рассчитано на ваши модели и ключи.
QM поддерживает общие навыки — инструкции и приёмы работы агента, которыми можно делиться с разрешения владельца области. Администратор может разрешить навык для всей организации; наборы навыков также импортируются из git-репозиториев. Если вы пока разбираетесь, что агенту дают такие инструкции, начните с материала про навыки для Claude и других агентов.
Есть и работа без открытого чата: расписания, отслеживание событий и входящие вебхуки. Вебхук — запрос от другого сервиса, который запускает действие при событии. README также описывает создание внутренних веб-приложений и публикацию их для нужных сотрудников. Это часть командной платформы, а не отдельный плагин для личного чата.
Кому нужна командная среда QM
QM имеет смысл, если вы ведёте проект в общем канале Slack и хотите, чтобы агент отслеживал обсуждение, публиковал обновления и напоминал о следующих шагах. Личные обращения сотрудников при этом остаются в их собственных областях. Такой сценарий отличается от просьбы каждому участнику заново пересказать агенту историю проекта.
Другой случай — у команды есть внутренние заметки, документы, почта и базы данных, по которым нужно искать при выполнении задач. README перечисляет совместный поиск по этим источникам и вебу. Но для доступа к ним придётся настроить подключения и учётные данные: из одного факта установки QM доступ к рабочей почте или базе не появляется.
Третий случай — разработка. По описанию проекта агент может работать в существующем репозитории: запускать тесты, открывать запросы на включение изменений, следить за CI — автоматическими проверками кода — и смотреть системные журналы. Если вы уже используете ИИ-агентов для таких задач, QM добавляет командные области и общий доступ к результатам, а не заменяет сам репозиторий.
Если вам нужен один помощник для личных вопросов или расширение редактора для работы в своём проекте, QM, скорее всего, не нужен. Ради этих задач пришлось бы поднимать командную платформу, настраивать облачную инфраструктуру и разбираться с правами доступа.
Развёртывание QM в облаке организации
README предлагает два пути начала работы. Первый — передать своему агенту для программирования точную фразу из инструкции; после неё агент должен следовать руководству по развёртыванию в репозитории:
Let's deploy https://github.com/yc-software/qm
Второй путь — создать отдельный репозиторий развёртывания, принадлежащий организации, и установить зависимость от пакета QM. Команды из README выглядят так:
npm exec --yes --package=@yc-software/qm@latest -- \
qm init . --org <slug> --target <fly-or-aws>
npm install
Здесь нужно подставить идентификатор организации вместо <slug> и выбрать указанный в команде вариант облачной площадки вместо <fly-or-aws>. Для команд понадобится среда Node.js с npm. Инициализация создаёт в репозитории инструкции для агента по развёртыванию, а затем проводит через настройку инфраструктуры, входа в веб-приложение, учётных данных подключений, необязательного Slack, публикации и проверки работающего экземпляра. Исходный код QM для этого пути скачивать не требуется.
Это не установка по схеме «выполнил две команды — получил готового бота». Каждый экземпляр работает в собственном облачном аккаунте оператора; README отсылает за подробностями к руководству по развёртыванию в репозитории. Инициализация не создаёт и не включает автоматическое развёртывание через CI. Параметры собственного облака, входа и подключений всё равно придётся настроить.
Для сохранения сеансов после перезапуска README требует Postgres и указывает следующие ключи настройки:
DATABASE_URL
SESSION_STORE=postgres
Без этой настройки сеансы хранятся в памяти запущенного процесса и исчезают при перезапуске. Postgres также используется для истории сеансов и других сохраняемых данных. Если вы оцениваете QM для рабочих процессов, проверьте этот пункт до того, как начнёте полагаться на память агента.
Три задачи, которые авторы предлагают поручить QM
В README нет готового набора текстовых запросов для рабочих сценариев. Ниже — перечисленные авторами задачи: что вы поручаете агенту и какой результат описан в источнике. Это не обещание, что подключения к вашим сервисам заработают без настройки.
Первая задача — поиск сразу по внутренним заметкам, письмам, документам, базам данных и вебу. Вы задаёте рабочий вопрос в подключённой области, а агент ищет сведения в доступных ему источниках. Какие именно письма и документы он увидит, зависит от настроенных подключений, учётных данных и разрешений этой области.
Вторая задача — работа с почтой по расписанию. По описанию проекта агент может изучать стиль ваших прошлых отправленных писем, затем разбирать входящие, назначать метки и готовить черновики ответов. Для этого ему нужен доступ к почте; README не говорит, что агент получает его по умолчанию. Черновики и метки — конкретные результаты, которые перечисляют авторы.
Третья задача — сопровождение проекта в общем канале. Вы работаете с агентом вместе с коллегами, а он публикует обновления и последующие действия. Если проект связан с кодом, README также перечисляет запуск тестов, открытие запросов на включение изменений и наблюдение за автоматическими проверками. Для команды важно заранее решить, какие из этих действий агенту разрешено выполнять самостоятельно.
Доступ агента, режимы контроля и зрелость проекта
QM действует с полномочиями человека, для которого работает: использует доступные ему учётные данные и разрешения. Один из инструментов агента, execute, запускает команды в отдельной песочнице области. Поэтому подключение почты, файлов, репозиториев или сервисов означает реальный доступ к ним, а не только чтение ответов в чате. По README действия агента записываются для аудита; это не повод пропускать настройку прав.
В проекте описаны три режима контроля. Strict запрашивает одобрение почти для каждого вызова инструмента. Режим Auto, выбранный по умолчанию, блокирует доступ к частной сети. Dangerous убирает запросы одобрения инструментов; проверка внешнего содержимого в нём может только наблюдать и записывать результаты. Во всех режимах остаются заранее заданные правила для команд, включая запреты на некоторые разрушительные действия.
Отдельно настраивается обмен ресурсами. По умолчанию действует Isolated: файлы и другие ресурсы остаются в своей области, пока их явно не откроют для общего доступа. Режим Open допускает чтение отдельных личных ресурсов в общей комнате при условиях, описанных в README. Перед запуском с рабочими данными прочитайте модель угроз и ограничения в документации репозитория; мы не проверяли код и не называем платформу безопасной.
Проект написан преимущественно на TypeScript и распространяется под лицензией MIT, кроме отдельно оговорённых случаев. Репозиторий создан 29 июля 2026 года; на момент обзора у него 15 482 звезды, а последний коммит датирован 21 октября 2026 года. Число звёзд не заменяет проверку того, подходит ли вам модель развёртывания и контроля доступа.
Источник: репозиторий QM на GitHub.