В одной из проверок VECTA агент получил практически пустой проект. При этом в исходной папке файлы были. Пользователь видел их, мог открыть в редакторе и ожидал, что агент начнёт с ними работать.
Причина оказалась прозаичнее проблем с моделью: в репозитории был пустой начальный коммит, а файлы ещё не попали в Git. Мы создавали рабочую копию задачи из HEAD. С точки зрения Git всё происходило правильно. С точки зрения пользователя инструмент потерял проект.
Этот случай хорошо показывает, что приходится делать вокруг coding agent. Запустить CLI и вывести ответ в чат недостаточно. Нужно определить, какую версию проекта получает агент, кому разрешено им управлять, что увидит человек после переподключения и относительно чего будет смотреть diff.
Меня зовут Андрей, я развиваю VECTA в Aterna и использую AI‑агентов в самой разработке. VECTA находится в закрытом тестировании. Это рабочее пространство для проектов и задач: агент выполняет работу на подключённом компьютере, а человек управляет задачей через desktop или браузер, в том числе с телефона. Ниже разберу несколько решений и ограничений этой архитектуры. Сравнительных замеров производительности с другими продуктами у меня пока нет.
Почему недостаточно второго терминала
Во многих случаях достаточно. tmux, SSH и отдельные worktree позволяют вести несколько агентских сессий без дополнительного продукта. Если вы работаете на одной машине, помните назначение каждой сессии и самостоятельно разбираете изменения, такая конфигурация вполне разумна.
Мой интерес начинается в другом сценарии. Один проект лежит на домашнем компьютере, второй на рабочем ноутбуке, третий на машине в офисе. У них разные инструменты и мощности. Агент на одной из машин просит разрешение, когда я уже вышел. Позже к проекту подключается коллега: ему нужны требования, предыдущие решения и результат, но работать он будет над своей задачей.
Здесь полезно связать обсуждение, выполнение и проверку с устойчивой сущностью «задача». Тогда с телефона я открываю конкретное решение, которое от меня требуется. С ноутбука возвращаюсь к diff той же задачи. Коллеге передаю доступ к рабочему контексту, а не подборку пересланных сообщений.
Сам подход давно не уникален. На Хабре есть разбор связки Orca и Pi Agent и опыт построения процесса поверх Vibe Kanban. У Orca документированы мобильное управление и работа с несколькими хостами. Поэтому наличие телефона, браузера или нескольких агентов само по себе не аргумент в пользу VECTA. Для меня предмет работы здесь конкретнее: сделать понятным путь от задачи в существующем проекте до проверяемого результата на выбранной машине.
Где выполняется работа
У системы три основных слоя.
Слой | Что делает |
|---|---|
Общий интерфейс desktop и web | Показывает проекты, задачи, обсуждение, запросы разрешений и результат |
API | Проверяет доступ, хранит серверное состояние и события, связывает клиентов с подключёнными машинами |
Runner на выбранном компьютере | Готовит рабочую копию, запускает подключённого агента и передаёт события выполнения |
Desktop построен на Electron, интерфейс общий с web‑клиентом. Runner написан на TypeScript, API на FastAPI. Браузерный клиент не запускает локальный CLI на телефоне. Он обращается к слою управления, а выполнение остаётся на выбранной машине.
Так слабый ноутбук или телефон могут использоваться для управления работой, которая выполняется на другом компьютере. Но вычислительные ресурсы сами по себе никуда не перемещаются. Для локального выполнения машина должна быть включена, runner должен работать, а сеть быть доступной. Локальной модели по‑прежнему нужны подходящие память и ускоритель.
Удалённый рабочий стол решает часть этой задачи другим способом. У него нет универсального ограничения «только два устройства»: существуют многопользовательские решения. И VECTA тоже зависит от сети. Разница в том, что единицей управления становится задача с её историей и действиями, а не экран компьютера. Сравнимых замеров трафика и задержки у меня пока нет.
Worktree копирует коммит, а человек работает с папкой
Вернёмся к пустому проекту. Проблему можно воспроизвести без VECTA и без модели. В отдельной временной папке создадим репозиторий с пустым первым коммитом, добавим файл, но не закоммитим его:
demo_dir="$(mktemp -d)" git init -q "$demo_dir/source" git -C "$demo_dir/source" -c user.name=Demo \ -c user.email=demo@example.invalid commit -q --allow-empty -m initial printf 'export const answer = 42;\n' > "$demo_dir/source/app.js" git -C "$demo_dir/source" worktree add -q -b agent "$demo_dir/task" HEAD test -f "$demo_dir/source/app.js" && echo 'source: app.js exists' test ! -f "$demo_dir/task/app.js" && echo 'worktree: app.js missing'
Это ожидаемое поведение Git. Но инструмент, к которому подключили существующий проект, должен явно определить свой контракт: он работает с последним коммитом или с текущим содержимым папки?
Для новой изолированной задачи в VECTA сейчас подготавливается снимок текущих допустимых файлов. В него входят обычные tracked‑файлы с их рабочим содержимым и неигнорируемые untracked‑файлы. Исходные рабочие файлы, staging area и ветка пользователя при этом сохраняются.
Тут сразу появляется вторая проблема: что показывать в diff. Допустим, до запуска агента человек уже поменял форму авторизации. Если сравнивать результат задачи с прежним HEAD, эти изменения будут выглядеть как работа агента. Поэтому подготовленное состояние становится отдельной baseline задачи. Последующие изменения сравниваются с ней.
В реализации для этого используются обычные механизмы Git: отдельный worktree, его индекс, объекты дерева и служебная ссылка baseline. VECTA не реализует собственную систему контроля версий. При этом подготовка действительно добавляет Git‑объекты и служебные ссылки в репозиторий, поэтому формулировка «вообще ничего не меняет в Git» тоже была бы неверной.
При возобновлении существующей задачи снимок не создаётся заново. Иначе более свежая исходная папка могла бы затереть уже выполненную работу агента.
Почему нельзя просто скопировать всё
В исходной папке могут быть .env, ключи, зависимости, символьные ссылки и пользовательские Git‑фильтры. Подготовка рабочей копии сама становится операцией, которую нужно ограничивать.
Сейчас у неё есть исключения для известных чувствительных путей и файлов, проверки типов файлов и ссылок, лимиты размера. Пользовательские Git‑фильтры для такого снимка не поддерживаются: они способны выполнять команды. Если во время подготовки обнаруживается изменение исходных файлов, операция завершается ошибкой вместо выдачи смешанного состояния.
Это не универсальный поиск секретов. Если токен записан в обычном config.ts, одно имя файла не позволит понять, что его нельзя передавать. Такой механизм также не заменяет атомарный снимок файловой системы.
У подхода есть цена совместимости: часть проектов потребует другой подготовки окружения. Например, зависимости, исключённые из копирования, не возникают в новой рабочей папке автоматически. Репозиторию нужен начальный коммит; отсутствие коммитов и пустой начальный коммит здесь разные случаи.
Закрытая вкладка и остановленный агент: разные события
Для управления с телефона недостаточно сделать узкий интерфейс. Мобильная сеть обрывается, вкладка уходит в фон, человек возвращается через несколько минут. За это время агент мог завершиться или остановиться на запросе разрешения.
Если клиент после переподключения получает только новые события, возможен неприятный случай: последнее событие уже произошло, новых не будет, а на экране навсегда осталось «работает».
В VECTA события задачи имеют последовательность. При переподключении клиент передаёт курсоры, API выбирает сохранённые события после них и возвращает их в порядке sequence. При этом снова проверяется доступ к рабочему пространству и видимость задачи. Переданный клиентом идентификатор не считается подтверждением прав.
Упрощённая логика выглядит так; это пояснение алгоритма, а не готовый клиент публичного API:
клиент сообщает: для задачи T последнее событие имеет sequence = N сервер проверяет доступ к T сервер выбирает сохранённые события T с sequence > N клиент применяет события, пропуская уже обработанные
Догоняющая выдача ограничена числом задач, событий, объёмом данных и временем отправки. Это защита от бесконечного ответа медленному клиенту, а не обещание восстановить произвольно длинную историю одним запросом. Переподключение интерфейса также не означает автоматического восстановления процесса после выключения компьютера.
Отдельный контракт нужен для кнопки остановки. Отправить процессу сигнал и убедиться, что он завершён, разные действия. В runner остановка ожидает подтверждения завершения; если его нет, возвращается ошибка. Нельзя освобождать ресурсы и принимать изменения так, будто процесс уже исчез.
Worktree не является песочницей
Отдельные рабочие папки помогают двум задачам не редактировать одни и те же файлы непосредственно. Они не изолируют операционную систему. Процессы могут конкурировать за память, порты, внешнюю базу и другие общие ресурсы. Совместимые по файлам изменения могут оказаться несовместимыми по смыслу.
В VECTA доступ рассматривается на нескольких уровнях:
Уровень | Какую границу задаёт |
|---|---|
Участник рабочего пространства | Какие данные человек видит и какие действия может выполнить |
Подключённая машина | К каким назначенным задачам runner может отправлять события |
Процесс агента и его инструменты | С каким окружением и разрешениями выполняется работа |
На сервере есть роли владельца, оператора и наблюдателя. Проверки выполняются в API, а не только через скрытие кнопок. Права на управление компьютером проверяются отдельно. Поэтому приглашение коллеги в пространство не стоит описывать как безусловную передачу управления всеми подключёнными машинами.
Перед запуском агентского процесса из окружения исключаются внутренние переменные VECTA, кроме явно переданных разрешённых параметров инструментов задачи. Это защита собственных учётных данных VECTA в этом канале, а не обещание удалить любые чужие секреты из окружения, файлов или настроек провайдера.
Реальная изоляция файловой системы, процессов и сети зависит от адаптера, провайдера и ОС. Диалог подтверждения не превращается в sandbox только потому, что пользователь нажал «разрешить». Аналогично текст агента нельзя считать доверенной командой или разрешением на действие.
Общий контекст не означает бесконечную память модели
У проекта сохраняются задачи, обсуждения и документы. Коллега с соответствующим доступом может изучить предысторию и вести отдельную задачу. Это полезно, когда требуется передать не только код, но и причины решений: что уже пробовали, какие изменения отклонили, что осталось проверить.
При этом история в продукте и контекст конкретного модельного вызова различаются. У моделей есть ограничения окна, у адаптеров разные механизмы продолжения сессии. Смена агента не означает перенос его скрытого состояния или полного внутреннего контекста в другую модель.
Документация существующего проекта и инструкции помогают агенту сориентироваться. Marketplace skills позволяет повторно использовать рабочие инструкции и подключаемые возможности. Но skill не получает право обходить разрешения задачи. Подключение MCP‑сервера или другого исполняемого инструмента расширяет поверхность доверия; полезное описание не делает такой инструмент автоматически безопасным.
Выбор модели тоже не уравнивает подключения. Возможность получить текст от совместимого API, доступ к файловым инструментам, запуск терминала и браузерная автоматизация являются разными возможностями. Поддержку локального или российского провайдера нужно проверять по конкретному подключению и сценарию, а не по наличию логотипа в списке.
«Готово» проверяется вне ответа агента
Возьмём типовую задачу в уже существующем приложении: после изменения формы авторизации кнопка отправки перестала помещаться на телефоне. Постановка «поправь адаптив» слишком размыта. Полезнее зафиксировать ширину экрана, ожидаемый сценарий, затрагиваемые файлы и ограничения, например не менять API авторизации.
После работы агента нужны как минимум diff, результаты проверок и просмотр сценария в браузере. В VECTA эти инструменты собраны рядом с задачей. Но встроенный браузер сам по себе не доказывает правильность приложения, а сообщение модели «тесты прошли» не заменяет фактический результат запуска.
Есть и техническая сторона браузера: preview проекта не должен давать странице произвольный доступ ко всем локальным сервисам машины. Поэтому разрешение открыть нужный preview нельзя подменять общим разрешением на весь loopback. В проекте этот класс ошибок отдельно проверяется реальным Chromium и тестовыми HTTP‑сервисами.
Приёмка остаётся самостоятельным действием. Даже если параллельно работают несколько агентов, нужен человек или явно настроенный проверочный процесс, который решит, соответствуют ли изменения задаче. Количество сессий не является метрикой готовности продукта.
Бюджет задачи не равен гарантированному счёту провайдера
В интерфейсе хочется предложить простую настройку: ограничить время, токены или стоимость задачи. На уровне интеграций она получается неодинаковой.
В текущем runner денежный лимит для локальных CLI‑задач допускается для Claude Code, токенный для Claude Code и Codex. Это отражает доступные отчёты этих адаптеров. Для неподдерживаемого вида учёта runner возвращает ошибку, предлагая ограничение по времени или другой агент. У управляемых режимов отдельный механизм квот; смешивать его с этим списком нельзя.
Есть и задержка отчётности. Если провайдер сообщает расход после выполнения части работы, локальная пауза не может задним числом отменить уже потраченные токены. Поэтому такие лимиты не стоит подавать как универсальный финансовый предохранитель с гарантией до цента. Неизвестная стоимость должна оставаться неизвестной, а не превращаться в ноль.
Практический результат более скромный и полезный: расход привязан к задаче, доступны поддерживаемые ограничения, а длинная серия доработок не теряется за пределами рабочего процесса.
Модель и место выполнения выбираются отдельно
В VECTA есть локальное выполнение с подключёнными агентами, управляемая модель VECTA Auto и отдельный режим VECTA Cloud. Названия легко смешать, поэтому важнее описывать, где находятся файлы и где выполняются инструменты.
В Auto модель предоставляется через одобренный аккаунт VECTA, а работа с локальным проектом выполняется на выбранном компьютере. Для этого режима не требуется отдельно устанавливать coding CLI или добавлять собственный ключ провайдера.
Cloud позволяет работать через браузер без постоянно включённого личного компьютера, но в текущей версии его область уже: диалоги и создание текстовых файлов или кода. Это не автоматическая миграция локального репозитория в полноценную облачную среду разработки.
Локальное выполнение также не означает, что данные вообще не покидают машину. API обслуживает синхронизацию задач и событий, а внешний модельный провайдер получает данные, которые ему передаёт агент. Использование локальной модели меняет модельный канал, но само по себе не превращает всю систему в полностью автономную локальную установку.
Что уже можно проверить, а чего я не измерял
Для подготовки новой рабочей копии в репозитории есть отдельные регрессионные тесты на настоящих временных Git‑репозиториях: untracked‑файлы после пустого коммита, сохранение staging area, исключение защищённых файлов, повторное открытие задачи, Git hooks, фильтры и изменение исходника во время подготовки. Это конкретнее, чем проверка того, что функция вернула ожидаемый объект.
Но наличие этих тестов не доказывает, что все сочетания ОС, моделей и проектов работают одинаково. Я также не измерял ускорение относительно Orca, Cursor или связки SSH с tmux и не проводил нагрузочный тест совместной работы двадцати человек. Эти утверждения нельзя выводить из наличия соответствующих экранов в интерфейсе.
Сейчас моя задача в VECTA состоит в том, чтобы человек мог продолжать полноценную разработку существующих проектов с разных устройств и сохранять контроль: над исходным состоянием файлов, правами, расходом и принятием результата. Проверять этот подход нужно на завершённых задачах, включая неудачные запуски и восстановление после сбоев.
Мне интересен ваш опыт с одним конкретным вопросом: какую исходную версию должен получать агент по умолчанию в проекте с незакоммиченными изменениями? Последний коммит, снимок текущей папки или только явно выбранные файлы? И где для вас проходит граница между удобством такого снимка и неожиданным поведением инструмента?
