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

Як проєкти Perplexity забезпечують збереженість, паралельність і відстежуваність тривалої роботи.

АвториPerplexity Engineering

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

  • Збереженість: результати роботи мають зберігатися довше за будь-який окремий сеанс агента чи пісочницю, щоб той самий користувач або агент міг продовжити роботу в майбутньому, а будь-які інші учасники — спиратися на неї.
  • Паралельність: кілька користувачів одного проєкту можуть мати по кілька агентів, які паралельно вносять зміни, що просувають спільний стан уперед, а не перезаписують одне одного.
  • Відстежуваність: і користувачі, і агенти мають бачити історію, щоб перевіряти, хто що змінив після їхнього останнього сеансу, не перечитуючи весь проєкт, і за потреби відкочувати зміни.

Ці виклики добре знайомі інженерам-програмістам. Git-платформи з’явилися десятиліття тому саме для того, щоб відповідати цим вимогам: це хостинговий сервіс, який доповнює систему контролю версій функціями для спільної роботи, щоб багато учасників могли сходитися до єдиного джерела істини. Файлова система, на якій працюють проєкти, — саме така Git-платформа, створена для співпраці людей з агентами та агентів між собою.

Один проєкт: інтерактивні агенти, агенти за розкладом та агенти інших користувачів працюють з одним і тим самим репозиторієм.

Архітектура

Git уже забезпечує збереженість, паралельність і відстежуваність. Він ідентифікує кожен файл за його вмістом, тож незмінні файли зберігаються один раз, а збережені копії ніколи не застарівають. Кожен коміт зберігає всі оновлені файли одночасно, тож учасники ніколи не бачать напівзавершеного стану. Коли два автори змін конфліктують, той, хто програв, може повторно застосувати свої зміни до нової версії та спробувати ще раз. Ланцюжок комітів показує, хто що змінив, і дає змогу легко відновлювати попередні версії. А от решта Git-платформи, створеної для людей, агентам не потрібна: екрани рецензування, керування гілками та сповіщення.

Наша архітектура виконує весь процес у хмарі й підтримує всі форми інтелектуальної роботи, не лише програмування. В основі кожного проєкту Computer — репозиторій Git, який обслуговують 5 компонентів:

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

Кожен агент має власну ізольовану пісочницю. У ній він працює з локальною копією репозиторію, якою керує невеликий CLI. CLI звертається до площини керування, щоб знайти репозиторій, а потім отримує й надсилає зміни через Git-сервіс. Проксі агента перевіряє доступ для запитів із пісочниці, перш ніж вони потраплять до Git-сервісу. Git-сервіс читає й записує репозиторії в спільній файловій системі та вирішує, чи стане кожне надсилання останнім прийнятим комітом. Цю файлову систему надає AWS S3Files, завдяки чому сховище на основі S3 доступне як звичайні файли й каталоги. Сховище поділено на ізольовані комірки, кожна з яких має власну файлову систему та репліки Git-сервісу. Після прийняття коміту фонові обробники видобувають текст та іншу корисну інформацію зі змінених документів, зберігаючи результати окремо від історії репозиторію й роблячи їх доступними, коли агенти завантажують або оновлюють проєкт.

Далі розглянемо компоненти по черзі.

CLI звертається до площини керування, щоб визначити розташування свого репозиторію, а потім отримує й надсилає зміни через Git-сервіс за посередництва проксі агента. Git-сервіс перевіряє надсилання й оновлює прийнятий head і outbox у DynamoDB. Репліки в межах комірки використовують сховище S3Files, а обробники на подальших етапах видобувають текст для отримання робочих копій і синхронізації.

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

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

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

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

Рішення залежить від розміру вказівника й маніфесту парсингу: прочитати розпарсений текст, завантажити вихідний файл або пропустити.

Площина керування: пошук репозиторіїв і надання доступу

Площина керування визначає, де зберігається кожен репозиторій, і надає до нього доступ. Під час створення репозиторію площина керування призначає його комірці сховища — ізольованій одиниці зберігання з власними репліками Git-сервісу. Коли агент починає роботу над проєктом, CLI запитує в площини керування, де зберігається репозиторій. Площина керування повертає розташування й тимчасові облікові дані для Git-сервісу. Площина керування ніколи не читає й не записує дані репозиторію. Те, що потрапляє до репозиторію, вирішує Git-сервіс.

Git-сервіс: передавання даних і координація оновлень

Git-сервіс виконує операції Git і передає вміст репозиторіїв та історію версій між пісочницями й сховищем. Це тонка обгортка над власними серверними командами Git. Він підтримує виявлення посилань (ref discovery), щоб повідомляти клієнту, де розташований head репозиторію, upload-pack для клонування та отримання змін і receive-pack для приймання нових об’єктів і запиту на просування head репозиторію. Також він обслуговує Git LFS API: для великих і бінарних файлів видає короткочасні посилання, щоб пісочниці могли завантажувати ці файли до S3 і з нього напряму.

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

Сервіс складається з парку реплік, кожна з яких — запущений екземпляр того самого сервера. Комірка об’єднує спільне сховище з набором реплік і допоміжних сервісів. Завдяки цьому репліки в межах комірки мають доступ до однієї спільної файлової системи замість того, щоб підтримувати незалежні копії кожного репозиторію.

Завдяки спільному сховищу репліки можуть залишатися без стану. Будь-яка репліка в комірці може обслуговувати будь-який із її репозиторіїв, тож заміна чи додавання реплік не потребує переміщення даних репозиторіїв між серверами. Запити до репозиторію зазвичай надходять до тієї самої репліки, щоб її кеші залишалися корисними, але репозиторій не залежить від доступності саме цього екземпляра.

На етапі прийняття перевіряються інваріанти репозиторію, щоб прийнятий коміт гарантовано відповідав коректному стану репозиторію. Для кожного репозиторію ми визначаємо явний контракт, тож механічні перевірки не дають йому надмірно розростатися. Великі та бінарні файли, як-от PDF і зображення, зберігаються через Git LFS, а не як звичайні Git-блоби. Ущільнення зберігає доступ до нещодавньої історії й водночас обмежує розмір репозиторію. Після успішного надсилання CLI запитує в Git-сервісу, чи потребує репозиторій ущільнення. Якщо кількість збережених комітів перевищує поріг, Git-сервіс залишає лише меншу кількість найновіших комітів. Старіша історія замінюється єдиним початковим знімком, а нещодавні коміти застосовуються повторно, щоб оновити їхні ідентифікатори.

Ущільнення зберігає найновіші коміти, згортає старішу історію в єдиний кореневий знімок і повторно застосовує нещодавні коміти з новими ідентифікаторами; новий head містить ті самі файли.

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

Два агенти надсилають зміни одночасно: одне надсилання приймається, а інший агент отримує відповідь про застарілу базу, повторно застосовує зміну поверх нового head і надсилає її знову.

Git-сервіс також реєструє кожну прийняту зміну. Для кожного прийнятого запису він додає елемент до outbox — журналу, у якому зазначено репозиторій, новий коміт, користувача, який вніс зміну, і змінені шляхи. Сервіси подальшої обробки, як-от парсер, читають цей журнал, щоб знаходити нову роботу.

Разом ці складники утворюють шар керування репозиторіями — без тих частин, які агентам не потрібні. Pull request тут не потрібні, оскільки жодна людина не переглядає кожну зміну. Натомість Git-сервіс перевіряє контракт під час надсилання, агент, що програв гонку, повторно застосовує власну зміну, а історія комітів фіксує, хто що змінив. Детерміновані перевірки утримують кожен репозиторій у межах його контракту, тож немає потреби покладатися на людину-оператора, щоб контролювати зростання.

Сховище: збереження результатів роботи

Рівень зберігання надійно зберігає дані репозиторіїв незалежно від пісочниць і реплік Git-сервісу. Репозиторії розміщено в AWS S3Files — сервісі, що надає доступ до сховища на основі S3 через інтерфейс файлової системи, який стандартний Git може використовувати без змін. Кожен репозиторій — це bare-репозиторій Git у спільній файловій системі, що містить об’єкти та посилання репозиторію, а не робочу копію.

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

Натомість ми могли б надати кожному проєкту довготривалу пісочницю, спільну для всіх його агентів, тож файли проєкту зберігалися б на диску цієї машини. Однак тоді обчислення агентів були б прив’язані до місця роботи машини, а її ресурси довелося б розраховувати на періоди найбільшого навантаження. Крім того, вона мала б місяцями залишатися справною, а резервним копіюванням і відновленням довелося б керувати в межах системи зберігання проєкту.

Одна довготривала пісочниця, спільна для агентів проєкту, порівняно з короткочасними пісочницями для кожного агента, які отримують доступ до довговічного спільного сховища через репліки Git-сервісу без стану.

Подальша обробка: як зробити документи зручними для читання агентами

Основний компонент подальшої обробки — конвеєр парсингу, який видобуває текст і метадані з нових або оновлених документів, щоб агенти могли легко читати файли проєкту. Обробник парсингу отримує оновлення з черги потоку змін, визначає змінені файли за метаданими коміту й отримує необроблені байти за хешем вмісту. Потім він розбирає документ, отримуючи видобутий текст і метадані документа.

Розпарсені результати зберігаються поза репозиторієм — у сховищі, де ключем є хеш вихідного документа. Ці артефакти ніколи не додаються комітами назад до репозиторію, оскільки це без потреби засмічувало б історію та збільшувало б кількість паралельних записів. Натомість розпарсені результати потрапляють до пісочниці під час отримання робочої копії та синхронізації. Кожна робоча копія містить зарезервований каталог, який CLI використовує для матеріалізації артефактів. Парсинг відбувається асинхронно, тож фоновий обробник парсингу не блокує отримання робочих копій.

Як агенти використовують робочий простір

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

Як і Computer, Search застосовує той самий підхід через свої стандартні файлові інструменти. Окремий дослідницький агент шукає в проєкті з обмеженішим бюджетом і повертає шляхи до релевантних файлів та підтверджувальні фрагменти. Потім модель, що формує відповідь, читає вибрані файли й генерує відповідь. Повторне використання наявної пісочниці проєкту скорочує час налаштування: підключення до прогрітої робочої копії займає близько 2,9 секунди, тоді як холодний старт — приблизно 8 секунд.

Пісочниці Computer, дослідницький субагент Ask, фонові автори знань і обробники парсингу читають з одного й того самого репозиторію та outbox і записують до них.

Розпарсений текст дає змогу шукати в більших документах, як-от PDF і файлах Office, тими самими інструментами. Агент спершу перевіряє маніфест — список документів, для яких доступний видобутий текст, — а потім шукає в цьому тексті й читає його як звичайні файли. Оригінальний документ він завантажує, лише коли тексту недостатньо, наприклад щоб розглянути рисунки, макет або вбудовані дані.

Ми порівняли цей підхід із семантичним пошуком за індексом на 150 фінансових запитаннях до того самого корпусу, кожне з яких стосується одного документа. Дослідницький агент отримав 0,867 за пошук правильного документа й 0,627 за правильність відповідей, тоді як семантичний пошук — приблизно 0,39 і 0,37. Тобто результат приблизно в 1,7 раза кращий для відповідей і вдвічі кращий для пошуку документів, а затримка — приблизно на 25% нижча. Дослідницький агент здебільшого працює з видобутим текстом і рідко завантажує оригінальні PDF.

Дослідницький пошук проти семантичного пошуку файлів на внутрішньому бенчмарку.

Одна спільна інфраструктура

Постійна пам’ять Computer використовує ту саму інфраструктуру файлової системи. Perplexity Brain, вікі знань Computer, зберігає пам’ять у репозиторіях знань із власною історією та політиками. Завдяки відокремленню знань від файлів проєкту фонові оновлення пам’яті не конкурують із редагуваннями цих файлів. Сеанс, якому потрібні і знання, і файли проєкту, завантажує обидва репозиторії.

Фонові агенти читають наявні знання, додають нову інформацію та зберігають оновлені сторінки як коміти. Інші агенти читають ці сторінки звичайними файловими інструментами, а люди також можуть їх редагувати. Автори змін діляться своєю роботою через репозиторій, а не координуються безпосередньо з кожним читачем. Історія комітів фіксує, хто що змінив, а outbox повідомляє сервісам подальшої обробки про прийняті оновлення. Люди й агенти можуть спиратися на роботу одне одного, маючи запис про те, як розвивалися знання.

Висновок

Коли люди й агенти працюють в одному проєкті, робочий простір не просто зберігає файли. Він стає спільним місцем, де об’єднуються внески й відстежуються зміни. Git уже забезпечує значну частину цієї основи. Ми додаємо координацію та автоматичні перевірки, щоб агенти могли надсилати результати роботи без схвалення кожного оновлення людиною. У результаті виходить Git-платформа, зведена до найнеобхіднішого, адже співпраця між агентами й розробка програмного забезпечення з багатьма учасниками — по суті одна й та сама задача.

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

Що більше агентів працює автономно в проєктах, то важливіше, щоб їхній спільний робочий простір залишався надійним і зрозумілим для людей. Мета проста: кожна зміна має жити довше, ніж агент, який її створив, ставати доступною наступному учаснику й залишати чіткий запис про те, що змінилося.

Цитування

BibTeX
@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}
}