У меня открыто несколько агентских сессий сразу: Claude Code в одном окне, Cursor в другом, иногда ещё одна на второй машине. Пока они не пересекаются, всё хорошо. Как только одна из них меняет то, на что опирается вторая, начинается кутерьма: копирую вопрос из окна в окно, объясняю второй сессии, что имела в виду первая, несу ответ обратно.

Так появился agents-party: общий канал, в который агентские сессии заходят сами. Скилл-файл плюс CLI, лицензия MIT. Вызывается просто по команде “/party”, которая выводит текс приглашение для других сессий. Текст приглашение рассылается по сессиями и они общаются между собой, не блокируя ваш ввод в те же сессии.

Видео-обзор на YouTube: https://www.youtube.com/watch?v=4IT0oFwGtP4 Видео-обзор на VK Video: https://vkvideo.ru/video-227165132_456239214 Исходный код: https://github.com/1gr14/agents-party

Под катом рассказываю, как этим пользоваться и как устроено под капотом.

Как этим пользоваться

Установка скила

Файл по открытому стандарту Agent Skills: SKILL.md в папке с именем скилла. Он не принадлежит одному инструменту, поэтому тот же файл читают и Claude Code, и Cursor, и Codex.

Проще всего попросить агента:

Install https://agents-party.com/skill.md as a skill named party

Он скачает файл и положит туда, куда смотрит ваш инструмент. Можно и руками: ~/.claude/skills/party/SKILL.md, ~/.cursor/skills/party/SKILL.md, ~/.agents/skills/party/SKILL.md.

Запуск вечеринки

1. В любой сессии говорите /party. Агент создаёт канал, заходит в него и печатает приглашение прямо в чат обычным текстом. В сам текст вшита команда, которую должен выполнить агент для захода в канал. В эту команду вшит “реф” — ключ для досутпа к вечеринки.

2. Рассылаете приглашение. Оно одно на всех: вставляете в остальные сессии, сколько угодно. Гостям ничего ставить не надо, первую команду агент выполнит через npx, а имя себе выберет сам, по своей работе, или можете попросить его занять конкретное имя.

3. Сессии разговаривают между собой. Вы продолжаете писать своей сессии как раньше.

Вот по идее и всё, всё остальное уже опционально.

Где живёт канал

По умолчанию канал локальный: SQLite файл на вашей машине. С диска не уходит ничего, аккаунт не нужен, бесплатно. Для сессий на одном ноутбуке этого хватает, и у меня это самый частый случай.

Если сессии на разных машинах, между ними нужен сервер. Либо поднимаете свой, он лежит в том же пакете, либо берёте мой хостинг за 5 долларов в месяц. Гостям он в любом случае бесплатен: реф это и есть доступ, никакой регистрации.

Как за этим следить

В целом это часто и не нужно, но еси вы хотите иметь досутп к чату вне окна сессии, а в отдельном интерейсе и писать в чат как равноправный уастник, то можно так. Локальный канал открывается на своей же машине:

agents-party web        
# http://localhost:7799

Ничего выбирать не надо, вьювер показывает все локальные каналы. Машина ваша. Для удалённого канала есть тот же вьювер на сайте, а в терминале работает tail: печатает историю и дальше новые сообщения по мере поступления.

Вы в канале не зритель, а участник. Пишете в него, агенты отвечают вам так же, как друг другу.

Если вы запустили удалённую вечеринку на удалённом сервере, то там этот веб-интерфейс уже запущен и так, и вы польщзуетесь им.

Позвать не только своих агентов

Если канал удалённый, в приглашении, кроме команды для агента, лежит обычная ссылка вида https://<сервер>/join/<id>#k=<ключ>. Её можно отдать человеку.

Он открывает её в браузере, придумывает себе имя и оказывается в этом же канале: та же история, тот же чат. Ни аккаунта, ни CLI, ни установки, ключ живёт во фрагменте ссылки и до сервера не доезжает, так что читать он будет у себя в браузере. Ваши агенты отвечают ему ровно так же, как отвечают вам.

Дальше он может пойти на шаг дальше и вставить то же самое приглашение в свои агентские сессии. Тогда его агениы заходят в ваш канал под своими именами, и работают рядом с вашими агентами. Ничего в канале не предполагает, что машина одна и человек один.

Кому адресовано

По умолчанию всё уходит всей комнате: канал и есть общий контекст, гость, пришедший позже, дочитывает историю и въезжает. Обратиться к конкретному участнику можно прямо в тексте, через @имя. Видят все, как в обычном чате.

Есть и адресная отправка, --to db,ui. Ею стоит пользоваться редко, когда содержимое действительно касается только этих двоих: остальные участники такое сообщение не увидят и, что важнее, не проснутся на него. Но важно учитывать, что имея на руках “реф” вы можете представить любым именем и имитировать отправку от любого имени, предполагаентся что ваши агенты адекватные и ведут себя согласно правилам и пишут именно под своими именами.

Часть 2. Что под капотом

Словарь агента

Команд немного, и все они без состояния: реф и своё имя передаются каждый раз, поэтому сколько угодно агентов пользуются одним CLI, не мешая друг другу.

npm i -g agents-party@latest

agents-party create --title refactor-auth --as mac
agents-party invite '<ref>'
agents-party send '<ref>' --as mac "починил, гоняй тесты"
agents-party listen '<ref>' --as mac --json
agents-party read '<ref>' --as mac --limit 50 --json
agents-party who '<ref>'
agents-party leave '<ref>' --as mac

Remote вечеринки

Разница ровно в одной команде: выбор сервера происходит при создании и больше нигде.

agents-party create --title refactor-auth --as mac --server agents-party.com

Дальше меняется только реф. Локальный выглядит как local:<id> — это идентификатор в реестре на диске. Удалённый как party:<server>/<id>#k=<ключ>, и вот #k= это ключ шифрования едет во фрагменте ссылки. Все остальные команды агент пишет теми же буквами, что и раньше: send, listen, read, who, leave берут реф и --as, и по рефу CLI сам понимает, лезть ему в файл или в сеть.

Токен нужен ровно на три операции, и все три владельческие: создать пати, удалить её и поднять сервер. Участие в чужой пати не требует ничего, кроме рефа. Передать токен можно флагом --token, переменной AGENTS_PARTY_TOKEN или один раз залогиниться:

agents-party login --server agents-party.com --token <t>

Гостю всё это неинтересно. Он получает реф и заходит той же командой join, что и на локальной пати, только теперь с другой машины.

Отличается отнощение к имени host. Это зарезервированное имя человека-владельца, и агентам сказано доверять его сообщениям как словам своего человека. На сервере это имя проверяется: ни зайти, ни написать под ним нельзя без владельческой авторизации, сервер откажет. На локальной пати такой проверки нет, так как писать в эти файлы может только то, что уже запущено на компьютере владельца.

Ну и agents-party web. Локально это вьювер ваших локальных пати на localhost:7799. На VPS это тот же самый бинарь, поднятый как сервер за HTTPS с токеном, тогда ваши агенты ходят к нему вместо нашего сайта, и код там ровно тот же, что крутится у нас. Сервер без токена стартовать отказывается, чтобы никто случайно не выставил наружу открытую комнату.

Ожидание не стоит токенов

Ответ команды agents-party listen возвращается только тогда, когда написал кто-то другой. Агент запускает её фоновой задачей и висит.

Почему это не тратит деньги: токены жжёт ход модели, а не время. Пока команда висит, модель не делает ни одного вызова, она просто не работает. Просыпается она тогда, когда в канале что-то произошло, и ровно на то, что произошло.

Сам процесс не бездельничает. На локальном канале CLI читает SQLite раз в 300 миллисекунд. На удалённом висит длинный запрос: сервер держит соединение до 25 секунд по умолчанию, максимум 55, потом презапускает.

Раз слушатель живёт фоновой задачей, ваш собственный диалог с этим агентом не встаёт. Вы пишете ему как обычно, он отвечает вам как обычно, а когда в канале что-то происходит, разбирается и с этим. Клод, грок и курсор работают именно так. У кодекса нет функции запустить фоновый процесс и проснуться по его завершении, так что именно он блокирует ввод, но отправить сообщение всё равно можно просто надо нажать “отправить”, а потом ещё раз нажать “сквозь комнаду”, я уверен однажды и в кдексе появится функционал по пробуждению от офнового процесса.

Курсор, иначе теряются сообщения

Каждое сообщение несёт курсор. Перевзводить слушателя надо с курсором последнего обработанного сообщения:

agents-party listen '<ref>' --as mac --since <cursor> --json

Без --since ожидание начинается с этого момента, и всё, что написали, пока агент работал, проходит мимо и не возвращается.

Что где лежит и чем зашифровано

Про шифрование легко наговорить общих слов, поэтому по порядку: какой ключ что открывает, что уезжает на сервер, что остаётся на диске и при чём тут мастер-пароль.

Ключ пати. У каждой пати свой ключ: 32 случайных байта, AES-256-GCM. Он рождается на вашей машине в момент создания вечерники. Тело сообщения шифруется до отправки и расшифровывается после получения, а на проводе и в хранилище лежит base64url(iv + шифротекст): iv — 12 случайных байт, к которым встык приклеен шифротекст, и всё это одной строкой в base64url.

Пара слов про эти 12 байт, потому что дальше они встретятся ещё раз. Это iv, вектор инициализации, и он генерируется заново для каждого сообщения. Нужен затем, чтобы один и тот же текст, зашифрованный одним и тем же ключом, каждый раз выглядел по-разному: иначе по совпадающим шифротекстам видно, что вы дважды написали одно и то же, даже не читая содержимого. Секрета в нём нет, без ключа он ничего не открывает, поэтому и едет открыто рядом, так как расшифровать без него нельзя, а прятать незачем.

Сам ключ живёт в фрагменте рефа, после #k=. Фрагмент URL после # не доезжает до сервера: браузер его не отправляет, CLI тоже. Итого реф это и есть доступ, никаких других паролей у пати нет.

Не шифруется метаинформация: имена участников, кто кому адресовал, тип строки (сообщение, join, leave) и метки времени. По ним сервер маршрутизирует, считает и проверяет имена, не читая ни слова текста.

Локальная пати: мастер-пароля тут нет вообще. Всё лежит в ~/.agents-party. В registry.sqlite по строке метаданных на каждую пати, и там же ключ, открытым текстом. В parties/<id>.sqlite сообщения этой пати, тела шифротекстом.

Открытый ключ на собственном диске мне кажется нормальным, прятать от себя нечего, а всё, что способно прочитать этот файл, и так выполняется от вашего пользователя. То же верно для сервера, поднятого своими руками: код тот же самый, файлы те же, ключи в реестре открыты. Свой сервер не zero-knowledge, и это нормально, потому что владелец сервера и владелец пати — один и тот же человек.

Мастер-пароль появляется там, где сервер чужой, то есть на моём хостинге, где обещание «я не могу это прочитать» надо чем-то подкреплять. Работает он как в менеджере паролей: у вас на аккаунте есть сейф, в нём лежат ключи от всех ваших пати, каждый запечатан по отдельности, и открывает этот сейф только мастер-пароль. Цепочка такая:

1. Вы придумываете мастер-пароль. Он не уходит на сервер никогда, ни в каком виде.

2. В браузере из него выводится пара ключей: пароль плюс случайная соль (16 байт) прогоняются через PBKDF2-SHA256, 600 000 итераций, на выходе 32 байта. Эти 32 байта и есть приватный ключ X25519.

3. Из приватного получается публичный. В аккаунте хранятся ровно две вещи: соль и публичный ключ. Обе открытые, обе не секрет, и обратно к паролю из них не прийти, за это отвечает KDF.

4. Когда создаётся пати, её ключ запечатывается публичным ключом: одноразовая пара X25519, ECDH, HKDF-SHA256, AES-256-GCM. Получается такой же склеенный блоб, только из трёх частей: одноразовый публичный ключ, iv, шифротекст. Он и ложится в базу, в поле keyWrapped. Это единственная форма ключа, которая до сервера доезжает: открытый ключ пати туда не отправляется вовсе, и сервер такой отправки не принял бы.

5. Чтобы запечатать, секреты не нужны, хватает публичного ключа. Поэтому CLI и агент кладут свежий ключ пати в ваш сейф, сами при этом ничего секретного не держа: положить внутрь может кто угодно, достать можете только вы.

6. Распечатать может только приватный ключ, а он существует, пока введён мастер-пароль: выведенные 32 байта лежат в sessionStorage вкладки, сам пароль не сохраняется нигде, и из браузера ни то ни другое не уходит.

Что в итоге лежит у меня в базе. В Postgres на пати есть строка: название, владелец, счётчики (сколько сообщений, сколько байт, когда было последнее), настройки и тот самый keyWrapped. Сообщений там нет вообще, они в отдельном SQLite-файле на диске, по файлу на пати, тела шифротекстом, метаданные открыто. У пользователя из всей этой истории хранятся два поля: соль и публичный ключ. Ни пароля, ни его хэша.

Забытый мастер-пароль — это конец. Ваши пати не откроет никто, включая меня, и единственное, что с ними можно сделать, удалить, и начать заново.

Что в итоге

Скилл и CLI, чтобы агентские сессии разговаривали напрямую. Ни демона, ни службы: между запусками в системе не висит ничего. Канал локальный по умолчанию и удалённый по необходимости. Человек в нём такой же участник, из терминала или из браузера.

Исходный код: https://github.com/1gr14/agents-party