VECTA ограничивает AI-агентам доступ к коду: агент видит только снимок без паролей и ключей

Разработчик Андрей из компании Aterna опубликовал технический разбор того, как устроено взаимодействие ИИ-агентов с кодовой базой в продукте VECTA. Продукт находится в закрытом тестировании. Публикация появилась на фоне растущего интереса к агентным инструментам для разработки, где ключевой вопрос сместился с «насколько умна модель» на «что именно ей разрешено видеть и менять». Автор честно оговаривает: сравнительных замеров производительности с другими продуктами у него пока нет.

Какую проблему обнаружили на практике?

Отправной точкой стал конкретный баг. ИИ-агент (agent, программа, которая сама выполняет задачи по инструкции) получил практически пустой проект, хотя пользователь видел все файлы в папке и мог открыть их в редакторе.

Причина оказалась не в модели, а в Git (системе контроля версий, которая отслеживает изменения в коде). В репозитории был пустой начальный коммит (зафиксированное состояние), а реальные файлы ещё не попали в историю. Рабочая копия создавалась из HEAD (последней зафиксированной точки), и с точки зрения Git всё было правильно. С точки зрения человека инструмент «потерял» проект.

Этот случай обнажил целый набор вопросов, которые приходится решать вокруг любого агентного инструмента для кода:

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

Три слоя архитектуры VECTA

VECTA разделяет управление и выполнение на три слоя.

Desktop построен на Electron, интерфейс общий с веб-клиентом. Runner (исполнитель задач) написан на TypeScript, API работает через FastAPI. Браузерный клиент, в том числе на телефоне, не запускает локальный CLI (командную строку), а обращается к слою управления. Само выполнение остаётся на выбранной машине.

Это значит, что слабый ноутбук или телефон могут управлять работой, которая физически выполняется на мощном компьютере. Но вычислительные ресурсы никуда не перемещаются: машина должна быть включена, runner должен работать, сеть должна быть доступна.

Как решается вопрос AI агентов и доступа к коду?

Для каждой новой задачи VECTA подготавливает снимок текущих допустимых файлов. В него входят:

• Обычные отслеживаемые файлы с их рабочим содержимым
• Неигнорируемые файлы, которых ещё нет в Git
• Исключения для чувствительных путей (.env, ключи), проверки типов файлов, лимиты размера

Исходные рабочие файлы, область подготовки (staging area) и ветка пользователя при этом сохраняются. Подготовленное состояние становится отдельной базовой линией задачи: все последующие изменения агента сравниваются именно с ней, а не с прежним HEAD. Так изменения, которые человек внёс до запуска агента, не приписываются машине.

При возобновлении существующей задачи снимок заново не создаётся. Иначе более свежая исходная папка могла бы затереть уже выполненную работу агента. Под капотом используются стандартные механизмы Git: отдельный worktree (рабочее дерево), его индекс и служебная ссылка baseline. VECTA не строит собственную систему контроля версий, но добавляет служебные объекты в репозиторий.

Работа с несколькими машинами: зачем это нужно?

Типичный сценарий автора продукта: один проект лежит на домашнем компьютере, второй на рабочем ноутбуке, третий на машине в офисе. У них разные инструменты и мощности. Агент на одной из машин запрашивает разрешение, когда человек уже ушёл.

VECTA привязывает обсуждение, выполнение и проверку к устойчивой сущности «задача». С телефона можно открыть конкретное решение, которое ждёт одобрения. С ноутбука вернуться к diff той же задачи. Коллеге передать доступ к рабочему контексту целиком.

Автор честно отмечает, что подход не уникален: на Хабре есть разборы связки Orca и Pi Agent, опыт построения процесса поверх Vibe Kanban. У Orca документированы мобильное управление и работа с несколькими хостами. Наличие телефона или нескольких агентов само по себе не аргумент в пользу VECTA.

Что делать с этим прямо сейчас, по ролям

Автору Дзена и копирайтеру. Если вы используете ИИ-агентов для генерации или редактуры текстов в проектах с Git, проверьте: агент видит реальные файлы или пустой коммит? Проблема «потерянного проекта» воспроизводится в любом инструменте, не только в VECTA.

Разработчику и техническому предпринимателю. Архитектура «снимок с исключениями вместо полного доступа к папке» применима к любому агентному инструменту. Ключевой принцип: AI агенты получают доступ к коду через контролируемую копию, а не напрямую к рабочей директории.

Предпринимателю в РФ и СНГ. VECTA пока в закрытом тестировании, цена и условия доступа не раскрыты. Из доступных в России инструментов для агентной разработки можно рассматривать связки на базе открытых моделей с локальным запуском, но готового аналога с такой же архитектурой управления задачами по состоянию на дату публикации назвать сложно.

Частые вопросы

Можно ли попробовать VECTA прямо сейчас?

Нет. Продукт находится в закрытом тестировании. Дата публичного запуска и цена не названы. Автор не указал, как попасть в список ожидания.

Чем подход VECTA отличается от удалённого рабочего стола?

Удалённый рабочий стол транслирует экран компьютера. VECTA делает единицей управления задачу с её историей и действиями. При этом VECTA тоже зависит от сети, и сравнимых замеров трафика и задержки автор пока не приводит.

Работает ли это только с Git?

Описанная архитектура целиком построена на стандартных механизмах Git: worktree, индекс, служебные ссылки. Для проектов без Git подход в текущем виде неприменим.