Шесть машин и одна среда: как инженер синхронизирует работу с Claude Code без командных подписок

# Одна среда на шесть компьютеров: эмуляция командной работы с Claude Code

Проблема потери контекста и неэффективной передачи задач между разработчиками и их инструментами актуальна в эпоху массового внедрения AI-агентов. В июне 2024 года разработчик Антон Дз (Antondz) предложил альтернативный подход к организации труда: вместо покупки командной подписки для единого аккаунта, он создал экосистему, в которой один профиль управляет шестью машинами, каждая из которых работает со своим уникальным аккаунтом, но разделяет общую базу знаний.

Архитектура распределенного интеллекта

Результатом года разработки стало решение, позволяющее использовать один рабочий день независимо от выбранного устройства. В составе «парка» находятся всегда включенный десктоп, два ноутбука на Windows, два MacBook и Linux-сервер в облаке. За этими машинами следят три человека, но ключевую роль играет программная синхронизация, а не физическое присутствие одного оператора.

*«Я сажусь за любой компьютер и пишу: «напомни, что коллега вчера делал с гейтом публикации, хочу продолжить». И продолжаю. Не спрашиваю в чате, не жду, пока передадут дела»*, — описывает принцип работы автор статьи.

Каждое устройство имеет отдельную подписку Claude Code. Однако, благодаря общей системе синхронизации, агент на любой машине может запрашивать логику работы и статус задач, выполненных «коллегами» (другими машинами) через чтение истории сессий и общих файлов. Это устраняет необходимость в сложных чат-потоках для передачи эстафеты работы.

Свобода от вендора

Одной из ключевых особенностей этой системы является её независимость от конкретного провайдера. Поскольку весь свод правил и знаний хранится в виде обычных текстовых файлов, а не в закрытой базе данных компании, смена AI-ассистента в будущем станет вопросом простого копирования конфигурационного файла. Это снижает риски vendor lock-in (зависимости от поставщика) и дает гибкость в выборе инструментов.

Механизмы синхронизации и безопасности

Для реализации такой масштабируемой среды автор отказался от использования облачных хранилищ и корпоративных серверов, preferring синхронизацию на уровне файловой системы и мессенджеров.

Транспорт данных: В качестве транспортного средства используется Syncthing для прямой передачи файлов между устройствами. Дополнительным каналом коммуникации служит телеграм-группа, куда агенты пишут о статусе задач. Автор подчеркивает важность этого этапа: сообщение о возникновении вопроса синхронизации должно быть явно зафиксировано в общем чате.

Управление файлами и права доступа:

* Лок-файлы: Чтобы предотвратить конфликт редактирования, агент перед изменением общего файла устанавливает «замок» на 15 минут, запрещая другие процессы вносить правки. * Разделение прав: У разных пользователей на разных машинах права доступа различаются. Каждый обмен сообщениями между агентами требует подтвержденного протокола: «забрал задачу» -> «принял» -> «отчитался результатом». * Безопасность: Пароли и API-ключи хранятся в изолированной папке, не синхронизируемой с общей базой знаний или правилами агента, что минимизирует риск утечки чувствительных данных при анализе контекста.

Умная экономия токенов и организация знаний

Эффективность системы обеспечивается не только синхронизацией, но и умным управлением контекстом. Автор использует Obsidian как централизованное хранилище знаний (режим «мозг»), где информация структурирована слоями.

Файл правил CLAUDE.md:

В центре системы лежит файл с общими инструкциями весом около 192 килобайт. Этот файл агент читает при каждом запуске. Однако, чтобы не тратиться на токены на чтение лишнего текста, автор оптимизировал структуру данных:

1. Высокий уровень: В главном файле содержатся лишь триггеры — короткие ссылки на конкретные правила. 2. Глубокий уровень: Подробное описание правил хранится в отдельных заметках Obsidian.

Агент читает полный контекст только тогда, когда правило действительно требуется. По данным замеров автора за две недели (122 сессии), стартовый контекст составляет в среднем 91 500 токенов. Это позволяет агенту понять ситуацию, не загружая память историей всех возможных сценариев.

*«Тут есть тонкость... большой свод правил агент читает целиком даже на 400 килобайтах, а вот короткий файл-указатель он читает только первые 200 строк»*, — отмечает Антон.

Финансовая целесообразность

В момент создания системы командный тариф от Anthropic требовал оплаты для пяти мест, тогда как в команде работало три человека. Использование личных подписок с локальной синхронизацией знаний оказалось дешевле. Даже после снижения минимального порога командного тарифа до двух мест, автор считает, что локальная модель дает преимущество в свободе действий и отсутствии общего счета, который сложно контролировать в распределенной среде.

Преимущества подхода

1. Постоянство контекста: Не нужно заново собирать информацию при переходе на другое устройство. Работа продолжается сразу. 2. Масштабируемость: Добавление новой машины — это просто копирование папок синхронизации и конфига, без сложной миграции. 3. Текстовая прозрачность: Знания хранятся как текст, что позволяет читать и редактировать их вручную, видеть историю изменений, а не только взаимодействовать через черный ящик базы данных.

Планы развития и ограничения

Система не идеальна и продолжает развиваться. Автор указывает на несколько проблем, требующих решения:

* Подтверждение выполнения: Сейчас система подтверждает только факт приема задачи. Отличить «я принял» от «я сделал» программно — еще нерешенная задача. * Гибкость агентов: Пока все машины работают на Claude Code. Автор планирует протестировать схему с другими агентами, чтобы убедиться в универсальности формата правил. * Рост объема данных: Файл правил постоянно растет. Автор откладывает ревизию и удаление устаревших правил, но признает, что скоро потребуется оптимизация структуры данных.

Несмотря на сложность настройки (требование высокого уровня владения скриптами и системами), данный кейс демонстрирует, как инженерные решения могут обходить финансовые и функциональные ограничения готовых корпоративных продуктов.

Техно-штрих

В процессе внедрения автор столкнулся с проблемой различия путей к файлам на Windows, macOS и Linux. Решение было найдено просто, но гениально: скрипты не содержат жестко заданных путей, а берут их из конфигурационного файла, который специфичен для каждой конкретной машины. Это позволяет использовать единый код на гетерогенной инфраструктуре, где буквы дисков и каталоги отличаются кардинально.

Таким образом, проект стал примером того, как децентрализация и использование простых текстовых форматов могут создать более гибкую и экономически эффективную среду для работы с искусственным интеллектом.