Namespace набра $42 млн. — AI агентите получават собствени облачни машини

11 октомври 2026 г. в 08:00|Автор: Редакционният екип на QUASA|5 мин. четене

На 5 октомври 2026 г. Namespace обяви приключен Series B за $42 млн., воден от Scale Venture Partners, с участие на NEA, 20VC, Essence, Burst Capital, Susa Ventures и ангелски инвеститори, сред които изпълнителният директор на Datadog Оливие Помел; общото финансиране на компанията достигна $65 млн. Средствата са предназначени за разработка на продукта и разширяване на собствената изчислителна инфраструктура, включително машините за macOS. Namespace продава облачни среди, в които AI агенти могат да променят код, да изпълняват команди и да проверяват резултата.

На 6 октомври 2026 г. Scale Venture Partners потвърди, че води рунда. Инвеститорът описва промяната така: няколко агента могат да работят паралелно, като всеки се нуждае от изолирана среда с правилното хранилище, инструменти и контролиран достъп. Резултатите от компилациите и тестовете насочват следващото действие на агента, затова времето за изпълнение става част от скоростта на разработката.

Капитал за собствени машини и инструменти

Namespace развива бизнес на границата между софтуер за разработчици и облачна инфраструктура. Компанията предлага Devboxes за интерактивна работа с код, както и машини за GitHub Actions, компилации и тестове. Тя управлява собствен изчислителен слой, който включва хардуер, разпределяне на задачите и съхранение. Така може да поставя изпълнението близо до зависимости и вече създадени резултати от компилации, които следващите задачи използват.

Tech.eu посочва, че Namespace е основана в Цюрих през 2022 г. от бившия водещ инженер на Google Хуго Сантос, и цитира думите му: „I started Namespace because I believe developers deserve better.“ За европейските екипи произходът на компанията е контекст; услугата решава проблем, който възниква навсякъде, където агенти трябва да изпълняват код върху изолирани машини. Финансирането ще покаже дали Namespace може да разширява този капацитет, без цената на хардуера и поддръжката да изпревари търсенето.

Защо агентът се нуждае от отделна среда

Задачата на coding агента не приключва с предложена редакция. За да установи дали тя работи, агентът трябва да получи хранилището, да инсталира зависимости, да промени файлове, да стартира тестове и да прочете грешките. Често след това следва нова промяна в същото работно дърво. Ако няколко агента споделят една директория, временните файлове и редакциите им могат да си пречат; отделните среди дават на всяка задача собствено състояние.

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

Какво правят Devboxes отвъд CI runner

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

Хронологията на Namespace описва как Cursor Cloud Agents изпълняват команди, промени по файлове и Git операции в Linux или macOS Devboxes, докато Cursor управлява самия агент. За Claude Managed Agents са описани предварително задавани образ на машината, размер, хранилище, среда и време до спиране при неактивност. Това разделение е съществено: агентната услуга решава какво да направи, а Devbox предоставя мястото и инструментите, с които действието се изпълнява.

Поддръжката на macOS отговаря на по-тясна потребност от тази на Linux. Разработката за платформите на Apple изисква съответните инструменти за компилация и тестване, затова такива задачи се нуждаят от Mac капацитет. За други проекти Linux средата може да покрие изпълнението. Разширяването и на двата вида машини позволява повече паралелни задачи, но за клиента има смисъл само ако спестеното чакане оправдава цената на отделните среди.

Git Snapshots съкращават началото на проверката

При много едновременни задачи повторното извличане на едно и също хранилище може да забави старта още преди първия тест. Представянето на Git Snapshots от 30 септември 2026 г. описва функцията като ранен достъп и отчита до 6,5 пъти по-бързо извличане на код при участващи клиенти спрямо стандартното извличане. Това е фирмен резултат за конкретна операция, а не измерване на цялата работа на агента.

Механизмът подготвя хранилището и работното дърво веднъж и ги пакетира като snapshot. Следващите Linux или macOS runners изтеглят и разопаковат този пакет, вместо всеки сам да извлича историята на Git и да подрежда файловете. Функцията е описана за GitHub и Cursor Origin чрез съответните интеграции с GitHub Actions или Buildkite. Ползата би била най-осезаема при чести паралелни проверки и тежка начална подготовка; при кратки и редки задачи останалите стъпки може да определят по-голямата част от времето.

Разходът ще реши колко голям е пазарът

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

След рунда видимото изпитание за Namespace е разширяването на инфраструктурата, особено на Mac машините, докато достъпът до Git Snapshots се разширява отвъд ранните потребители. За екипите последствието ще се измерва в техните собствени проекти: дали изолираните среди намаляват чакането между редакция и резултат достатъчно, за да оправдаят разхода за всяка работеща машина.

Прочетете също:

Споделяне: