Создание общих рабочих пространств для людей и агентов

Недавно мы запустили проекты — пространство, где люди и агенты вместе работают над долгосрочными задачами в Perplexity Computer. Каждый проект размещается в общем рабочем пространстве с файловой системой, которая накапливает контекст между сеансами, агентами и пользователями. Совместная работа множества участников, растянутая на месяцы, требует сохранности, параллельной работы и прослеживаемости:

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

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

Развернуть

Архитектура

Git уже обеспечивает сохранность, параллельную работу и прослеживаемость. Он идентифицирует каждый файл по содержимому, поэтому неизменённые файлы хранятся в единственном экземпляре, а сохранённые копии никогда не устаревают. Каждый коммит сохраняет все обновлённые файлы разом, поэтому участники никогда не видят наполовину завершённое состояние. Когда изменения двух авторов сталкиваются, проигравший может заново применить свои изменения к новой версии и повторить попытку. Цепочка коммитов показывает, кто и что изменил, и позволяет легко восстановить прежние версии. А вот всё остальное, что есть в форже, созданном для людей, — экраны ревью, управление ветками и уведомления — агентам не нужно.

Наша архитектура выполняет весь процесс в облаке и поддерживает все виды интеллектуальной работы, а не только программирование. Каждый проект Computer опирается на Git-репозиторий, который обслуживают 5 компонентов:

• CLI в каждой песочнице поддерживает локальные рабочие копии, синхронизирует обновления и отправляет изменения агента.
• Плоскость управления находит репозиторий проекта и выдаёт краткосрочные учётные данные для доступа к нему.
• Git-сервис передаёт данные репозитория в песочницы, принимает от них отправки и решает, какая из них станет последним принятым коммитом.
• Хранилище на базе AWS S3 надёжно сохраняет данные репозиториев.
• Последующая обработка извлекает текст и другую полезную информацию из сохранённых документов и делает её доступной, когда агенты загружают или обновляют проект.

У каждого агента своя изолированная песочница. Внутри неё он работает с локальной копией репозитория, которой управляет небольшой CLI. CLI запрашивает у плоскости управления расположение репозитория, а затем получает и отправляет изменения через Git-сервис. Прокси агента проверяет права доступа для запросов из песочницы, прежде чем они попадут в Git-сервис. Git-сервис читает и записывает репозитории в общей файловой системе и решает, станет ли каждая отправка последним принятым коммитом. Эту файловую систему предоставляет AWS S3Files, который делает хранилище на базе S3 доступным в виде обычных файлов и каталогов. Хранилище разделено на изолированные ячейки, у каждой из которых своя файловая система и свои реплики Git-сервиса. После принятия коммита фоновые воркеры извлекают текст и другую полезную информацию из изменённых документов, хранят результаты отдельно от истории репозитория и делают их доступными, когда агенты загружают или обновляют проект.

Далее мы рассмотрим компоненты по очереди.

Развернуть

CLI: работа с локальными файлами в песочницах

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

Обычно агенты затрагивают лишь малую часть файлов проекта, поэтому нет необходимости материализовать весь репозиторий заранее. В результате CLI материализует его лениво: крупные и бинарные файлы, хранящиеся через Git Large File Storage (LFS), поступают в виде небольших файлов-указателей с реальным размером объекта, и агент может по имени и размеру решить, стоит ли их скачивать. Для документов вроде PDF агент сначала читает разобранный текст и скачивает исходные файлы только при необходимости.

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

Развернуть

Плоскость управления: поиск репозиториев и выдача доступа

Плоскость управления (control plane) определяет, где хранится каждый репозиторий, и выдаёт доступ к нему. При создании репозитория плоскость управления назначает его в ячейку хранения — изолированный блок хранилища с собственными репликами Git-сервиса. Когда агент начинает работу над проектом, CLI запрашивает у плоскости управления, где хранится репозиторий. Плоскость управления возвращает его расположение и временные учётные данные для Git-сервиса. Сама плоскость управления никогда не читает и не записывает данные репозитория. Что попадает в репозиторий, решает Git-сервис.

Git-сервис: передача данных и координация обновлений

Git-сервис выполняет операции Git и передаёт содержимое репозиториев и историю версий между песочницами и хранилищем. Это тонкая обёртка над собственными серверными командами Git. Он поддерживает обнаружение ссылок (ref discovery), чтобы сообщать клиенту, где находится головной коммит репозитория, upload-pack — для клонирования и получения изменений, и receive-pack — для приёма новых объектов и запроса на продвижение головного коммита репозитория. Он также обслуживает API Git LFS: для крупных и бинарных файлов он выдаёт краткосрочные ссылки, чтобы песочницы могли загружать эти файлы в S3 и скачивать их оттуда напрямую.

Мы начали с готового сервера-форжа, чтобы прототипировать интерфейсы для агентов и пользователей параллельно с созданием собственного легковесного форжа, ориентированного только на нужные нам операции Git.

Сервис состоит из парка реплик, каждая из которых — запущенный экземпляр одного и того же сервера. Ячейка объединяет общее хранилище с набором реплик и их вспомогательными сервисами. Благодаря этому реплики внутри ячейки могут обращаться к одной и той же общей файловой системе, а не поддерживать независимые копии каждого репозитория.

Благодаря общему хранилищу реплики могут оставаться без состояния (stateless). Любая реплика в ячейке может обслуживать любой из её репозиториев, поэтому замена или добавление реплик не требует переноса данных репозиториев между серверами. Запросы к репозиторию обычно направляются на одну и ту же реплику, чтобы её кеши оставались полезными, но репозиторий не зависит от доступности этого конкретного экземпляра.

На этапе приёмки проверяются инварианты репозитория, чтобы каждый принятый коммит соответствовал допустимому состоянию репозитория. Для каждого репозитория мы определяем явный контракт, и автоматические проверки не дают ему чрезмерно разрастаться. Крупные и бинарные файлы, такие как PDF и изображения, хранятся через Git LFS, а не как обычные Git-блобы. Уплотнение (compaction) сохраняет доступ к недавней истории и при этом ограничивает размер репозитория. После успешной отправки CLI спрашивает у Git-сервиса, нужно ли уплотнить репозиторий. Если число сохранённых коммитов превышает пороговое значение, Git-сервис оставляет лишь небольшой набор самых последних коммитов. Более старая история заменяется одним начальным снимком, а недавние коммиты воспроизводятся заново с обновлёнными идентификаторами.

Развернуть

Одновременную запись несколькими авторами контролирует простой шаг синхронизации. Он отслеживает последний принятый коммит — головной коммит (head). Получив отправку, он принимает её, только если она построена на этом головном коммите. В противном случае он возвращает структурированный ответ об устаревшей базе (stale-base); проигравшему нужно воспроизвести своё изменение поверх нового головного коммита и отправить его повторно. Такая схема гарантирует, что параллельно работающие агенты не будут незаметно перезаписывать изменения друг друга, и при этом не вызывает заметных замедлений. В наших рабочих процессах в продакшене менее 2% отправок отклоняются как устаревшие. В целом медианная задержка отправки составляет менее 1,7 секунды, а задержка p99 — менее 8 секунд.

Развернуть

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

Вместе эти компоненты образуют слой управления репозиториями — без того, что агентам не нужно. Pull request не нужны, потому что никто из людей не проверяет каждое изменение. Вместо этого Git-сервис проверяет контракт в момент отправки, агент, проигравший гонку, заново применяет своё изменение, а история коммитов фиксирует, кто и что изменил. Детерминированные проверки удерживают каждый репозиторий в рамках его контракта, и не нужно полагаться на человека-оператора, который следил бы за его ростом.

Хранилище: надёжное сохранение работы

Уровень хранения надёжно сохраняет данные репозиториев независимо от песочниц и реплик Git-сервиса. Репозитории размещаются в AWS S3Files — сервисе, который предоставляет хранилище на базе S3 через интерфейс файловой системы, так что стандартный Git может работать с ним без изменений. Каждый репозиторий — это bare-репозиторий Git в общей файловой системе, содержащий объекты и ссылки репозитория, а не рабочую копию.

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

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

Развернуть

Последующая обработка: как сделать документы читаемыми для агентов

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

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

Как агенты используют рабочее пространство

Агенты исследуют загруженную в песочницу версию репозитория стандартными инструментами файловой системы. Вместо фиксированного конвейера «сначала поиск, потом чтение» они просматривают содержимое папок, ищут по содержимому файлов с помощью grep, читают релевантные фрагменты и по найденному решают, куда смотреть дальше.

Как и Computer, Search применяет тот же подход с помощью стандартных файловых инструментов. Отдельный агент-исследователь просматривает проект в рамках более ограниченного бюджета и возвращает пути к релевантным файлам и подтверждающие фрагменты. Затем модель, формирующая ответ, читает выбранные файлы и генерирует ответ. Повторное использование существующей песочницы проекта сокращает время подготовки: подключение к «тёплой» рабочей копии занимает около 2,9 секунды, тогда как холодный старт — примерно 8 секунд.

Развернуть

Разобранный текст позволяет искать по крупным документам, таким как PDF и файлы Office, теми же инструментами. Сначала агент проверяет манифест — список документов, для которых доступен извлечённый текст, — а затем ищет и читает этот текст как обычные файлы. Исходный документ он скачивает, только когда текста недостаточно, например чтобы изучить рисунки, макет или встроенные данные.

Мы сравнили этот подход с семантическим поиском по индексу того же корпуса на 150 финансовых вопросах, ответ на каждый из которых содержится в одном документе. Агент-исследователь набрал 0,867 по нахождению нужного документа и 0,627 по правильности ответов — против примерно 0,39 и 0,37 у семантического поиска. Это примерно в 1,7 раза лучше по ответам и в 2 раза лучше по поиску документов при задержке примерно на 25% ниже. Агент-исследователь в основном работает с извлечённым текстом и редко скачивает исходные PDF.

Развернуть

Единая общая инфраструктура

Постоянная память Computer использует ту же инфраструктуру файловой системы. Perplexity Brain — вики знаний Computer — хранит память в репозиториях знаний с собственной историей и политиками. Благодаря тому что знания хранятся отдельно от файлов проекта, фоновые обновления памяти не конкурируют с правками этих файлов. Сеанс, которому нужно и то и другое, загружает оба репозитория.

Фоновые агенты читают имеющиеся знания, добавляют новую информацию и сохраняют обновлённые страницы в виде коммитов. Другие агенты читают эти страницы обычными файловыми инструментами, а люди тоже могут их редактировать. Авторы делятся своей работой через репозиторий, а не координируются напрямую с каждым читателем. История коммитов фиксирует, кто и что изменил, а outbox сообщает о принятых обновлениях последующим сервисам. Люди и агенты могут опираться на работу друг друга, а запись о том, как развивались знания, сохраняется.

Заключение

Когда люди и агенты работают в общем проекте, рабочее пространство не просто хранит файлы. Оно становится общим местом, где объединяются вклады участников и отслеживается, что изменилось. Git уже даёт значительную часть этой основы. Мы добавляем координацию и автоматические проверки, чтобы агенты могли отправлять работу без одобрения каждого обновления человеком. В результате получается форж, сведённый к самому необходимому, ведь совместная работа агентов и разработка ПО силами многих участников по сути представляют собой одну и ту же задачу.

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

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

Цитирование

@online{perplexity2026BuildingSharedWorkspacesForPeopleAndAgents,
  author = {{Perplexity} and Se Won Jang and Peter Hart and Kartik Kapur and Kevin Lau and Sidhant Rajadnya and Ishbir Singh and Thomas Wang and Jarrod Bryan and Claire Beamer and Jeremy Yang},
  title = {{Building shared workspaces for people and agents}},
  date = {2026-10-12},
  url = {https://www.perplexity.ai/hub/blog/building-shared-workspaces-for-people-and-agents}
}