Как дать экспертам (не технарям) доступ к агентам. И дать им возможность обновлять этих агентов через командные скиллы. Да еще и так, чтобы они могли коннектиться к инфре компании с правильными доступами
Я накатал там в комментах ответ исходя из горького опыта экспериментов во время внедрений.
Заметил, что пересылаю его уже третий раз кому-то, решил запостить – думаю, кому-то из вас сэкономит нервы:
—————————
Я бы вообще абстрагировал бота (у Леши в вопросе речь шла про тг бот) от агентной части. Сделать сначала бэк + простой веб фронтенд (будет быстрее для итераций, чем трахаться с телегой как только выйдете за базовую функциональность)
И отдельно решать вопрос именно настроек агента (скиллы, AGENTS.md и т.д.). Так же отдельно вопрос per-user доступов к корпоративным тулам. Код агента ничего про это не должен знать – это авторизация либо поверх MCP, либо поверх CLI (см. gh как пример)
———
По агентному бэку: к сожалению, я не знаю хорошего агента, который дефолтно умеет в мультиюзер, т.к. все они делались изначально под локальный запуск одним пользователем.
Поэтому:
1. либо писать свой на базе какого-нибудь pi sdk;
2. либо изолированно запускать готовые (тот же pi или opencode) под каждого пользователя в сэндбоксе (в порядке увеличения изоляции: unix user → docker → microVM), а из своей тонкой мультитенантной прокладки просто роутить запросы в эти сэндбоксы
Заведение нового пользователя = создание нового сэндбокса. А новый чат в рамках пользователя – просто новая сессия внутри его агента
———
По расширениям (MCP, CLI, SKILLS). Я бы забил на MCP (особенно, если нужно быстро). Оставил бы только CLI и SKILLS. Если не использовать git для хранения, то вы с нуля будете изобретать версионирование, диффы, RBAC, разрешение конфликтов и т.д
Если хотим быстро и без боли – нам такое не подходит. Проще создать репо со скиллами на гитхабе, включая скиллы для работы с ним. можно даже сразу копировать весь репо в папочку
/srv/company_skills_marketplace и подлинковывать ее содержимое в ~/.agents/skills1. Даем скиллы для загрузки на гитхаб, обновления с гитхаба и т.д.
2. В какой-то момент разделяем роли, кто какие скиллы можем менять.
3. Потом запрещаем пушить в main и назначаем ревьюеров.
4* В идеале – разносим каждый скилл в отдельный репо, чтобы можно было обновлять независимо. Тогда в самом скилле можно даже зашить проверку версии по хэшу коммита и делать автообновление (или запрос пользователю на апдейт)
———
По коннекторам:
Тут все по старинке – даем пользователям разные доступы на уровне самих инструментов, куда коннектимся, пусть агент просто логинится под аккаунтом пользователя через cli (см. gh, gcloud, etc)
——————
Короче, все сводится к тому, чтобы разбить одну задачу на 4 независимых задачи изоляции:
1. Изоляция истории сессий (не могу посмотреть чужие сообщения)
2. Изоляция execution environment (не могу залезть в чужие файлы через shell)
3. Изоляция прав на обновление shared логики (не могу менять скиллы чужой команды)
4. Изоляция доступов (не могу залезть в гугл таблички фин.дира и посмотреть зп команды)
1 решается своим кодом, 2 – docker/microVM, 3 – гитхабом со скиллами-обертками для нормальных людей, 4 – давно решено