В работе. Это заметка, а не готовый текст. Несколько недель тестов, никакого вывода, и честный промежуточный результат — «не то, на что я надеялась». Публикую в таком виде намеренно. Дополнение к первой части, второй и третьей моего рассказа о настройке.
Чего мне хотелось
Помощника, который не является инструментом для написания кода.
Кого-то, кто держит картину сразу по всем моим проектам: что в приоритете, что заблокировано, что я три недели назад пообещала сделать в разговоре о проекте, который с тех пор не открывала. Кодинг-агенты прекрасны внутри одного репозитория и понятия не имеют, что существуют ещё четыре. Это не их недостаток — это граница, которую я сознательно построила в первой части, и работает она ровно так, как задумано. Но над проектами остаётся реальный провал, и именно в нём живёт большинство моих решений.
План был в разделении труда: оркестратор держит межпроектную картину и помогает планировать, а агенты в редакторе остаются отдельно и делают работу внутри каждого репозитория.
Почему именно этот
Я тестировала Hermes несколько недель, и причину выбора стоит назвать точно, потому что по той же причине его может выбрать кто-то ещё: в нём есть слоистая модель памяти, которой нет ни у одного из кодинг-агентов.
К тому моменту я уже была уверена, что узкое место — это устройство памяти (на этом стоит вся третья часть), и вот система, которая будто бы со мной согласна: структура встроена, а не собрана вручную из markdown-файлов и привычек. В этом и было всё притяжение. Не в модели за ним и не в интерфейсе. В памяти.
Как я его ограничила
Так же, как и всё остальное, и вот эту часть я повторила бы без изменений:
- собственный контейнер;
- оба порта привязаны только к локальному интерфейсу, так что из сети до него не дотянуться;
- дерево проектов подключено только на чтение, и ровно один проект доступен на запись;
- никакого доступа к сокету Docker, никакого домашнего каталога;
- зафиксированный образ, чтобы пересборка воспроизводила то, что я тестировала, а не то, что выложили на этой неделе.
Стоит сказать прямо: помощник, который видит все мои проекты, — это ровно то, чему граница нужна больше всего. Широкий доступ на чтение и узкий на запись — та форма, при которой мне вообще было спокойно его включить.
Что получилось на самом деле
Он правда хорош в узких разовых исследованиях. Задаёшь ограниченный вопрос — получаешь добротный ответ. Эта часть работает, и я ей пользуюсь до сих пор.
И это не то, на что я надеялась. Он управляет моделями через чат, а не через кодинг-агента, и вся разница оказывается именно здесь. Настоящего агентного цикла над репозиторием нет: ни цикла с инструментами, ни диффа, который можно посмотреть, ни шага проверки, ничего из того «попробовал, не вышло, поправился, попробовал снова», что делает агентов в редакторе полезными для настоящей работы. Для ответа в один заход — нормально. Для «сходи и разберись с этим в том проекте» — даже близко нет.
И это не зависит от того, чьи модели стоят за ним, что меня удивило. Я думала, переменная — модель. Оказалось, поверхность, через которую он говорит, важнее.
Так что делегирование до сих пор выключено, и намеренно. Прежде чем оркестратор начнёт от моего имени передавать работу кодинг-агенту, мне нужен явный выбор проекта, точки подтверждения, вменяемое поведение при таймаутах и сбоях и правило, куда и под именем какого проекта ложится получившаяся расшифровка. Ничего из этого пока не спроектировано. Включить без этого — значит выдать клавиатуру и список моих репозиториев агенту без присмотра, а вся остальная моя настройка существует ровно затем, чтобы такого не случилось.
Есть ещё вопрос лицензий, который я хочу закрыть до того, как что-то на этом строить: укладывается ли управление кодинг-агентом одного поставщика из оркестратора другого в условия использования. Не выяснено, и выяснять это задним числом не хочется.
Где остаётся сам вопрос
Открытым — и ответ на него мне нужен больше всего: что вы используете как личного администратора?
Мои требования на сегодня:
- держит контекст каждого проекта, и мне не приходится вставлять его руками;
- не привязан к подписке одного поставщика, чтобы слой планирования не переезжал каждый раз, когда переезжают инструменты для кода;
- либо настоящий агентный цикл, либо честное признание, что это поверхность для размышления, а не для действия, — плохой сценарий тут именно тот, где инструмент выглядит как второе, а ведёт себя как первое;
- ограничивается так же строго, как и всё остальное.
Кандидата, который проходит по всем четырём, у меня нет. Возможно, я в итоге напишу тонкую версию сама: что-то, что читает вики по каждому проекту из третьей части и ведёт небольшой файл общего состояния, вообще без самостоятельности. Менее внушительно — и отвечает на вопрос, который у меня действительно есть.
Пишу это незаконченным, потому что «я тестировала штуку несколько недель, и она не сделала того, на что я надеялась» полезнее для другого человека, чем ещё одна схема архитектуры. И потому что сама хотела бы прочитать такое до того, как начинала.
Вопросы, на которые у меня пока нет ответа:
- Ограничение чат-поверхности — это свойство всего класса инструментов или деталь нынешней реализации?
- Должен ли личный администратор вообще действовать, или держать точную картину — и есть вся работа? Я всё время предполагаю первое и уже не уверена.
- Если ответ — тонкий самописный слой, то какая самая маленькая версия имеет смысл?