Изграждане на споделени работни пространства за хора и агенти

Как проектите в Perplexity осигуряват постоянство, паралелност и проследимост на дълготрайната работа.

АвториPerplexity Engineering

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

  • Постоянство: Работата трябва да е трайна отвъд всяка отделна сесия на агент или sandbox среда, така че бъдещата работа да може да бъде продължена от същия потребител или агент и надградена от всеки сътрудник.
  • Паралелност: Няколко потребители в един и същ проект могат всеки да има по няколко агента, които редактират паралелно и придвижват напред общо състояние, вместо да се презаписват взаимно.
  • Проследимост: Както потребителите, така и агентите трябва да могат да виждат историята, за да проверяват кой какво е променил от последната им сесия, без да преглеждат отново целия проект, и да отменят редакции, когато е необходимо.

Тези предизвикателства са познати на софтуерните инженери. Git forge платформите се появиха преди десетилетия, за да отговорят точно на тези изисквания: хоствана услуга, която обвива контрола на версиите с функции за съвместна работа, така че много сътрудници да могат да се обединят около единен източник на истина. Файловата система, която захранва проектите, е именно такава Git forge платформа, създадена за сътрудничество между хора и агенти и между самите агенти.

Един проект: интерактивни агенти, планирани агенти и агенти на други потребители се събират в едно и също хранилище.

Архитектура

Git вече осигурява постоянство, паралелност и проследимост. Той идентифицира всеки файл по съдържанието му, така че непроменените файлове се съхраняват веднъж, а запазените копия никога не остаряват. Всеки къмит записва всички обновени файлове наведнъж, така че сътрудниците никога не виждат недовършено състояние. Когато двама записващи се сблъскат, загубилият може да приложи отново промените си върху новата версия и да опита пак. Веригата от къмити показва кой какво е променил и улеснява възстановяването на по-ранни версии. Това, от което агентите нямат нужда, е останалата част от една forge платформа, създадена за хора, като екрани за преглед, управление на клонове и известия.

Нашата архитектура изпълнява целия процес в облака и поддържа всички форми на интелектуален труд отвъд програмирането. Всеки проект в Computer се основава на Git хранилище, обслужвано от 5 компонента:

  • CLI поддържа локалните checkout копия, синхронизира обновяванията и изпраща промените на агента във всяка sandbox среда.
  • Контролната равнина намира хранилището на проекта и издава краткотрайни идентификационни данни за достъп до него.
  • Git услугата изпраща данни от хранилището към sandbox средите, получава изпратените от тях промени и решава кое изпращане да стане последният приет къмит.
  • Съхранението, базирано на AWS S3, запазва трайно данните на хранилищата.
  • Обработката надолу по веригата извлича текст и друга полезна информация от запазените документи и я прави достъпна, когато агентите зареждат или опресняват проекта.

Всеки агент разполага със собствена изолирана sandbox среда. В нея той работи с локално копие на хранилището, управлявано от малък CLI. CLI пита контролната равнина къде се намира хранилището, след което извлича и изпраща промени чрез Git услугата. Прокси за агенти проверява достъпа на заявките от sandbox средите, преди те да достигнат до Git услугата. Git услугата чете и записва хранилища в споделена файлова система и решава дали всяко изпращане да стане последният приет къмит. Тази файлова система се предоставя от услугата AWS S3Files, която прави базираното на S3 съхранение достъпно като обикновени файлове и директории. Съхранението е разделено на изолирани клетки, всяка със собствена файлова система и реплики на Git услугата. След като даден къмит бъде приет, фонови обработващи процеси извличат текст и друга полезна информация от променените документи, като съхраняват резултатите отделно от историята на хранилището и ги правят достъпни, когато агентите зареждат или опресняват проекта.

По-нататък ще разгледаме компонентите един по един.

CLI се свързва с контролната равнина, за да намери своето хранилище, след което извлича и изпраща промени през Git услугата чрез проксито за агенти. Git услугата проверява изпращанията и обновява приетия head и outbox в DynamoDB. Репликите в рамките на клетката използват съхранение в S3Files, а обработващите процеси надолу по веригата извличат текст за checkout и синхронизация.

CLI: работа с локални файлове в sandbox среди

Агентите работят в SPACE – нашата собствена sandbox платформа. Всяка sandbox среда разполага с малък CLI, който материализира хранилището и го поддържа синхронизирано. За всяка значима единица работа, извършена от агента, CLI изпраща промените като къмит.

Обикновено агентите засягат само малка част от файловете на проекта, затова не е необходимо цялото хранилище да се материализира предварително. Поради това CLI материализира отложено: големите и двоичните файлове, съхранявани чрез Git Large File Storage (LFS), пристигат като малки файлове указатели, съдържащи реалния размер на обекта, така че агентът може да използва името и размера, за да прецени дали си струва да ги изтегли. При документи като PDF файлове агентът първо чете парсирания текст и изтегля изходните файлове само когато е необходимо.

Друг естествен вариант би бил да се използва виртуална файлова система. Тествахме реализация, базирана на FUSE, но при натоварвания с интензивна работа с файловата система тя се оказа приблизително 400 пъти по-бавна от локалните файлове, тъй като всяка заявка изисква двупосочен обмен по мрежата. Освен това тя обикновено изисква привилегировани възможности от хоста, така че всеки агент би трябвало да работи в привилегирована sandbox среда.

Размерът от указателя и манифестът на парсването определят дали да се прочете парсираният текст, да се изтегли изходният файл или файлът да се пропусне.

Контролна равнина: намиране на хранилища и предоставяне на достъп

Контролната равнина определя къде се съхранява всяко хранилище и предоставя достъп до него. При създаване на хранилище контролната равнина го разпределя в клетка за съхранение – изолирана единица за съхранение със собствени реплики на Git услугата. Когато агент започне работа по проект, CLI пита контролната равнина къде се съхранява хранилището. Контролната равнина връща местоположението и временни идентификационни данни за Git услугата. Контролната равнина никога не чете и не записва данни от хранилището. Git услугата решава какво влиза в хранилището.

Git услуга: пренос на данни и координиране на обновяванията

Git услугата изпълнява Git операции и пренася съдържанието на хранилищата и историята на версиите между sandbox средите и съхранението. Тя е тънка обвивка около собствените команди на Git за обслужване. Поддържа откриване на референции (ref discovery), за да съобщи на клиента къде е head на хранилището, upload-pack за клониране и извличане и receive-pack за получаване на нови обекти и на заявка за придвижване на head на хранилището. Освен това обслужва Git LFS API: за големи и двоични файлове издава краткотрайни връзки, така че sandbox средите да могат да качват и изтеглят тези файлове директно от S3.

Започнахме с готов forge сървър, за да можем да създаваме прототипи на интерфейсите за агентите и потребителите паралелно с изграждането на собствен лек forge, фокусиран само върху нужните ни Git операции.

Услугата се състои от набор от реплики, всяка от които е работеща инстанция на един и същ сървър. Клетката обединява споделено съхранение с набор от реплики и поддържащите ги услуги. Така репликите в рамките на една клетка имат достъп до една и съща споделена файлова система, вместо да поддържат независими копия на всяко хранилище.

Това споделено съхранение позволява репликите да останат без състояние. Всяка реплика в клетката може да обслужва всяко от хранилищата ѝ, така че подмяната или добавянето на реплики не изисква преместване на данни от хранилищата между сървъри. Заявките за дадено хранилище обикновено отиват към една и съща реплика, за да остане кешът ѝ полезен, но хранилището не зависи от това конкретната инстанция да остане достъпна.

Стъпката за приемане проверява инвариантите на хранилището, за да гарантира, че всеки приет къмит представлява валидно състояние на хранилището. За всяко хранилище дефинираме изричен договор, така че механичните проверки да не позволяват на хранилището да нарасне прекалено. Големите и двоичните файлове, като PDF документи и изображения, се съхраняват чрез Git LFS, а не като сурови Git blob обекти. Компактирането запазва достъпа до скорошната история, като същевременно ограничава размера на хранилището. След успешно изпращане CLI пита Git услугата дали хранилището се нуждае от компактиране. Ако броят на запазените къмити надхвърли определен праг, Git услугата запазва само по-малък набор от най-скорошните къмити. По-старата история се заменя с една начална моментна снимка, а скорошните къмити се възпроизвеждат наново, за да се обновят идентификаторите на къмитите.

Компактирането запазва най-скорошните къмити, обединява по-старата история в една коренна моментна снимка и възпроизвежда скорошните къмити с нови идентификатори; новият head съдържа същите файлове.

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

Два агента изпращат промени едновременно; едното изпращане е прието, а другият агент получава отговор за остаряла база, възпроизвежда промяната си върху новия head и я изпраща отново.

Git услугата също така записва всяка приета промяна. За всеки приет запис тя добавя елемент в outbox – журнал, в който са посочени хранилището, новият къмит, потребителят, направил промяната, и променените пътища. Услугите надолу по веригата, например парсерът, четат този журнал, за да открият нова работа.

Заедно тези елементи образуват слой за управление на хранилища – без частите, от които агентите нямат нужда. Заявките тип pull request са излишни, защото никой човек не преглежда всяка промяна. Вместо това Git услугата проверява договора в момента на изпращане, агентът, загубил надпреварата, прилага повторно собствената си промяна, а историята на къмитите показва кой какво е променил. Детерминистичните проверки поддържат всяко хранилище в рамките на договора му, вместо растежът да зависи от човек-оператор.

Съхранение: гарантиране на трайността на работата

Слоят за съхранение запазва трайно данните на хранилищата независимо от sandbox средите и репликите на Git услугата. Хранилищата се намират в услугата AWS S3Files, която предоставя базирано на S3 съхранение чрез интерфейс на файлова система, който стандартният Git може да използва без модификации. Всяко от тях е bare Git хранилище в споделената файлова система, съдържащо обектите и референциите на хранилището, а не работно копие (checkout).

Разделянето на съхранението от изчислителните ресурси позволява sandbox средите да остават краткотрайни. Всеки агент получава собствена sandbox среда и много агенти могат да работят по един и същ проект, без да споделят машина. Ако дадена sandbox среда се срине, застрашена е само работата, която все още не е изпратена.

Вместо това бихме могли да дадем на всеки проект дълготрайна sandbox среда, споделена от всички негови агенти, така че файловете на проекта да се намират на диска на тази машина. Това обаче би обвързало изчислителните ресурси на агентите с мястото, където работи машината, и би изисквало тя да е оразмерена за най-натоварените периоди. Освен това машината би трябвало да остане в изправност в продължение на месеци, като резервните копия и възстановяването се управляват като част от системата за съхранение на проекта.

Една дълготрайна sandbox среда, споделена от агентите на проекта, в сравнение с краткотрайни sandbox среди за всеки агент, които достигат до трайно споделено съхранение чрез реплики без състояние на Git услугата.

Обработка надолу по веригата: как документите стават четими за агентите

Основният компонент надолу по веригата е конвейер за парсване, който извлича текст и метаданни от новодобавени или обновени документи, за да направи файловете на проекта лесно четими за агентите. Обработващ процес за парсване получава обновявания от опашката на потока от промени, определя променените файлове от метаданните на къмита и извлича суровите байтове по хеша на съдържанието. След това парсва документа, за да получи извлечения текст и метаданните на документа.

Резултатите от парсването се намират извън хранилището – в отделно съхранение, индексирано по хеша на изходния документ. Тези артефакти никога не се къмитват обратно в хранилището, тъй като това би замърсило ненужно историята и би увеличило броя на паралелните записи. Вместо това резултатите от парсването достигат до sandbox средата чрез checkout и синхронизация. Всеки checkout съдържа резервирана директория, която CLI използва за материализиране на артефактите. Парсването се извършва асинхронно, така че фоновият обработващ процес за парсване не блокира checkout операциите.

Как агентите използват работното пространство

Агентите изследват версията на хранилището, заредена в sandbox средата, със стандартни инструменти за файловата система. Вместо да следват фиксиран процес „търсене, после четене“, те разглеждат съдържанието на папките, търсят в съдържанието на файловете с grep, четат релевантни откъси и използват откритото, за да решат къде да търсят след това.

Подобно на Computer, Search използва същия подход чрез стандартните си файлови инструменти. Отделен изследващ агент търси в проекта с по-ограничен бюджет и връща пътищата на релевантните файлове и подкрепящи откъси. След това моделът, който отговаря, чете избраните файлове и генерира отговора. Повторното използване на съществуваща sandbox среда на проекта съкращава времето за подготовка: свързването към вече подготвен (warm) checkout отнема около 2,9 секунди, в сравнение с приблизително 8 секунди при студено стартиране.

Sandbox средите на Computer, изследващият подагент на Ask, фоновите процеси, записващи знания, и обработващите процеси за парсване четат от едно и също хранилище и outbox и записват в тях.

Парсираният текст прави по-големите документи, като PDF файлове и файлове на Office, достъпни за търсене със същите инструменти. Агентът първо проверява манифест – списък, който показва за кои документи има наличен извлечен текст, – след което търси и чете този текст като обикновени файлове. Изтегля оригиналния документ само когато текстът не е достатъчен, например за да разгледа фигури, оформление или вградени данни.

Сравнихме този подход със семантично търсене в индекс по 150 финансови въпроса, всеки от които се отнася до един документ, върху същия корпус. Изследващият агент постигна резултат 0,867 при намирането на правилния документ и 0,627 при правилния отговор, срещу приблизително 0,39 и 0,37 за семантичното търсене – около 1,7 пъти по-добре при отговорите и 2 пъти по-добре при намирането, при около 25% по-ниска латентност. Изследващият агент работи предимно с извлечен текст и рядко изтегля оригиналните PDF файлове.

Изследване срещу семантично търсене на файлове при вътрешния бенчмарк.

Една споделена инфраструктура

Постоянната памет на Computer използва същата инфраструктура на файловата система. Perplexity Brain, уикито със знания на Computer, съхранява паметта в хранилища за знания със собствена история и правила. Разделянето на знанията от файловете на проекта означава, че фоновите обновявания на паметта не се конкурират с редакциите на тези файлове. Сесия, която се нуждае и от двете, зарежда и двете хранилища.

Фоновите агенти четат съществуващите знания, включват нова информация и запазват обновените страници като къмити. Други агенти четат тези страници с обикновени файлови инструменти, а хората също могат да ги редактират. Записващите споделят работата си чрез хранилището, вместо да се координират пряко с всеки читател. Историята на къмитите показва кой какво е променил, а outbox съобщава за приетите обновявания на услугите надолу по веригата. Хората и агентите могат да надграждат взаимно работата си, като разполагат със запис за това как са се развивали знанията.

Заключение

Когато хора и агенти споделят проект, работното пространство не просто съхранява файлове. То осигурява общо място за обединяване на приносите и проследяване на промените. Git вече предоставя голяма част от тази основа. Ние добавяме координация и автоматизирани проверки, така че агентите да могат да изпращат работа, без човек да одобрява всяко обновяване. Резултатът е forge платформа, сведена до най-същественото, защото в основата си сътрудничеството между агенти и разработката на софтуер с много участници са един и същ проблем.

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

Тъй като все повече агенти работят автономно в проектите, общото им работно пространство трябва да остане надеждно и разбираемо за хората. Целта е ясна: всяка промяна трябва да е по-трайна от агента, който я е създал, да става достъпна за следващия сътрудник и да оставя ясна следа за това какво е променено.

Цитиране

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