Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Поток AI и ML доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 31
Очень интересно и да, я бы доверила ии агенту такую задачу
Что-то надо менять. Негоже специалистам такие сальто перед работодателем крутить. Надо бы чтобы работодатели так вертелись-то по идее...
Нынешние сложности с поиском работы не связаны с "процессом" и поэтому вряд ли исправляются таким подходом. Частично они вообще вызваны излишним использованием ИИ с обоих сторон (и в этом смысл Ваш подход можно даже расценить как подливание масла в огонь). Но если сидишь без работы и от безысходности, то так развлекаться однозначно лучше, чем просто страдать от текущей ситуации!
Боты скоринг систем были еще и до ии-сумасшествия. Да и в целом не нужно страдать от ситуации, дали инструмент новый, значит используем его во благо себе. Работодатели внедряют ии в анализ резюме и чтение откликов по вакансиям, значит пусть мой агент с ними и разруливает.
Если агент получает от вас "не ОК", ему сообщается причина?
Забавная идея... Очень хотелось бы продолжения. Если не секрет, на каком железе это у Вас ходит ??? Сам сейчас подумываю о покупке чего-то, на чём такие штуки можно запускать локально.
Начинал я с клодом, но прокатилась волна блокировок и перешел я на kimi, помимо этого локально крутятся несколько моделек, например для генерации картинок. Всё это работает на макбуке m4 pro max 36/1tb. Я, на самом деле, делаю большую ошибку что не изолировал агента в отдельном инстансе, а позволяю ему видеть всё что у меня есть, но другого железа для эксперимента брать не хочу. Может и зря, будущее покажет.
Кстати kimi выпустили к3.1 и там открытые веса, но чтобы её запустить надо что-то около 2000гб ОЗУ, а так локально было бы круто иметь такого помощника.
А так ли нужно другое железо? Агент неплохо себя и в docker-контейнере чувствует…
Может и не нужно, конечно, но железо не резиновое. Если я запускаю llm для генерации 3д (есть у меня новое хобби по разработке игр), то можно просто уходить минут на 10, мак пыхтит как паровоз)
К сожалению у ИИ очень плохо получается сопоставлять важность задачи и степень прилагаемых усилий к ее решению. Но очень хорошо прокачано упорство. И это очень и очень опасная смесь. Он сам себе выдумывает проблемы, которые потом героически решает - даже если ценой станет система, на которой он запущен. Так что ограниченный доступ (или обособленное железо) - на мой взгляд, обязательное требование для запуска агента (+регулярный бекап).
Для себя настроил так, что у агента в конейтнере доступа даже к ключам подписки нет (не говоря уже про SSH/GIT) - “навабкодил” проксю, которая подменяет Auth-заголовки на правильные )
Изоляция в Докере без проброса лишних волюмов решает проблему безопасности процентов на 99
Это не совсем так. Если мягко. А если честно - то совсем не так. Докер изолирует инструмент, но рабочий каталог с текущим проектом остаётся общим с хостом, и "сбежать" из такой песочницы - элементарно. А само желание "сбежать" сформирует любая случайно залетевшая промпт-инъекция.
Я разработал два более адекватных подхода: один через ssh в отдельного юзера, второй через изоляцию на Linux namespaces. Первый в теории можно и для мака портировать. https://github.com/powerman/sandbox-ai-dev
Как понимаю, проблема не в docker, а в том, что локальная IDE на уязвимый проект "смотрит", что создает риски уже для хост-системы.
Если же к docker-контейнеру подключаться через SSH - то и особой разницы и нет.
Не всё так просто. Откуда-то же внутри докера взялся каталог с проектом? Обычно - из файловой системы хоста. И для уязвимости не обязательно открывать проект в IDE хоста, зачастую достаточно просто зайти в этот каталог в шелле (из-за direnv, mise, etc.) или выполнить в нём git-команду (что триггерит хуки). А работать с проектом на хосте нередко есть необходимость хотя бы ради того, чтобы некоторые токены держать вне доступа ИИ (т.е. вне докера в нашем случае).
Но если докер использовать как полноценную виртуалку, проекты в неё заносить через git clone и файлы с хостом не шарить - то да, будет безопасно. Просто очень неудобно. Потому что удобно настроено на хосте (где работали до появления ИИ-агентов), и дублировать все эти настройки в докере (и синхронизировать потом отличия с хостом) - идея так себе. Убирать с хоста и переносить всю работу внутрь виртуалки/контейнера - тоже неудобно, интеграция с десктопом хоста будет сильно хромать, и, фактически, придётся одновременно работать в двух разных ОС и поддерживать обе. Мой проект все эти проблемы решает.
Но если докер использовать как полноценную виртуалку, проекты в неё заносить через git clone и файлы с хостом не шарить - то да, будет безопасно. Просто очень неудобно.
Но чем это отличается от “другой пользователь” или “Linux namespaces” (через которые работает и docker)? Только тем, что вручную неудобно, а проект умеет?
Как минимум мне сценарий с docker нравится тем, что хост не загромождается средствами разработки - поверхность атаки ниже (хотя, конечно, от curl ... | bash это не спасет). И нет доступа к основной файловой системе - обычно на чтение там доступно много всего лишнего.
Конечно, можно все утилиты разработки держать в домашнем каталоге 2го пользователя и права настроить - но всегда останется сценарий “через уязвимость повысил права до root”. А в docker сбежать чуть сложнее будет.
P.S. а как с git работа идет? Ключи/пароли прописывать - даешь доступ к репо. Локально пушишь - натыкаешься на хуки. Через локальный git-сервер в 2 этапа пушить?
Но чем это отличается от “другой пользователь” или “Linux namespaces”
Подход принципиально другой: в докере отличается ОС а файлы проекта общие, а в моих двух подходах ОС та же а файлы проекта разделены. Та же ОС даёт привычные инструменты и их конфигурацию, бесшовную интеграцию с десктопом - т.е. работаешь как обычно работал.
хост не загромождается средствами разработки
Если на хосте средств разработки нет, то ценность моего подхода сильно падает - он проектировался для ситуации, когда разработка велась именно на хосте и под неё уже всё настроено, а теперь нужно делать ту же разработку с использованием ИИ, и хочется сохранить привычное удобство работы не потеряв безопасность.
но всегда останется сценарий “через уязвимость повысил права до root”. А в docker сбежать чуть сложнее будет.
На самом деле это не так. Рут обычно даёт эксплоит ядра, а ядро в докере то же самое. Плюс дополнительно добавляются уязвимости самого докера. Так что в этом плане принципиальных отличий в безопасности между всеми этими вариантами нет, тут защиту даёт только виртуалка с другим ядром.
а как с git работа идет?
Как с любым коллегой. Песочница с ИИ рассматривается в этом плане как другой сотрудник: у него собственные токены и права доступа, обмен изменениями в репо с ним идёт через ревью и git push/pull после ревью изменений.
В общем самый большой риск (помимо IDE или direnv) - это git-хуки. В целом решается достаточно просто (~/.bashrc):
export GIT_CONFIG_PARAMETERS="'core.hooksPath=/dev/null'"
IDE - открывать, подключаясь к контейнеру (VS Code так умеет, лично я через SSH в контейнере работаю). Поверхность атаки сводится к контейнеру, локально только интерфейс.
direnv и подобное - просто не использовать. Если все средства разработки в контейнере живут - то он и не нужен на хосте.
В том-то и дело, что этот подход не работает. Каналов утечек слишком много и постоянно придумывают новые. mise/direnv/хуки - их же придумали не для того, чтобы дыру в безопасности создать, а потому, что без них с проектом работать намного сложнее и неудобнее. Да и не всегда у вас есть возможность отказаться от использования хуков - они могут требоваться в рамках принятых процессов работы с проектом. С остальными утилитами та же фигня: иногда нужно работать с форками чужих проектов в которых они используются, т.е. полностью от них отказаться возможности нет.
Ну и кроме того, всё это создаёт проблему только если не контролировать изменения в проекте. Если ИИ работает на собственном клоне репо и изменения попадают на хост только после ревью и через git pull, то угроза безопасности падает до стандартного уровня "коллега запушил в репо фигню, которую пропустили на ревью и смержили". Потому что если пропустили и смержили, то не требуются mise/direnv/хуки, достаточно внедрить вредоносный код прямо в scripts/test.sh и его запустят на своих компах все другие разработчики.
Подход “ИИ работает как коллега” требует или доступа ИИ к репо (под своим пользователем), или отдельного сервера git для обмена данными с ИИ.
Прямой доступ даже отдельным пользователем - сомневаюсь, что приживется в рамках командной разработки. Мало того, что каждому нужен 2й акк, так еще и внутренние обсуждения с агентом выходят за рамки локальной разработки.
Отдельно для ИИ поднимать какой-нибудь Gitea - идея тоже явно не лучшая. По крайней мере если до этого не стояло ничего подобного.
Хотя подход “у ИИ полностью изолированная среда, работа идет через Issue и MR” мне нравится. Но организационных моментов порождает много.
Вы переусложняете. ИИ - ваш инструмент, поэтому доступ в репо (гитхаб/гитлаб/etc.) идёт под вашим аккаунтом, коммиты подписаны вашей подписью - в этом плане ничего дополнительного не требуется.
Что нужно дополнительно, так это возможность ограничить доступ для вашего аккаунта: отдельные токены для стейджа и прода, отдельные ключи ssh и т.п. Все эти токены/ключи для вашего аккаунта, но с разными правами - и в песочницу для ИИ прокидываются токены и ключи с минимальными правами доступа, не дающие ИИ случайно сделать то, о чём можно потом сильно пожалеть (напр. случайно грохнуть БД прода).
А что-то не прокидывается вообще. Напр. в моей реализации песочницы ключ для подписи коммитов остаётся на хосте (при вызове git commit в песочнице запрос пароля появляется на хосте).
В случае локальной разработки без центрального репо вроде гитхаба никто не мешает добавить git remote в репо на хосте на каталог с репо внутри ИИ-песочницы. Это позволит использовать те же git pull/push локально между двумя каталогами, что защитит от передачи на хост лишних "невидимых" файлов (хуки и настройки в .git, всякое в .gitignore) и позволит сделать git diff с веткой ИИ после git pull - т.е. ревью перед мержем в локальный каталог, по сути то же самое, что и при ревью PR на гитхабе.
В общем, единственный дополнительный организационный момент - это создание ограниченных ключей/токенов для работы ИИ под вашим же аккаунтом. Но это в любом случае нужно сделать, вне зависимости от используемого подхода к изоляции ИИ-агентов.
Интересная тема, однако в "массовости" скорее всего споткнется. Автор наклепал что-то под себя. В реальном мире, с другими критериями/задачами эта штука встретит кучу несоответствий и породит кучу багов.
Однако в тексте видно несколько железных утверждений. Больше всего мне понравилось: мы не умеем искать себе работу. Есть такое - 102%! Другое - про несоответствия. Это более интересная тема. Всегда мы встречаемся с несоответствиями вакансии. Но важно ли это? Мы решали проблемы характера А. Сможем ли мы решить проблемы характера Б и В? Наверняка, если это проблемы того же уровня. Решить проблемы - в данном контексте может быть равно "закрыть задачи" - это не столь важно. Другой вопрос если это 1А против 2А или 3А. Так я обозначил проблемы/задачи другого уровня. Например: мы быстро и качественно кодим бизнес-логику, она на раз проходит тесты безопасности и нагрузочные тесты. Это уровень 1А. Уровень 2А - это когда у нас есть команда, входящая задача и ограниченные сроки, а проверки те же - тесты безопасности и нагрузочные тесты. Уровень 5А - когда есть бизнес задача, жесткий дедлайн, и требования к стабильности (они разложатся на безопасность и нагрузку), а так же требования к долгосрочной поддержке. И плюсом ко всему - ограничения бюджета. Вот тут несоответствие может сыграть бОльшую роль.
Как агент справляется с разными уровнями несоответствия и личными пожеланиями расти вглубь/вширь/вверх?
Спасибо за комментарий. Пока в первую неделю ничего не было от агента на тему роста и решения несоответствий, пока агент просто отсекает вакансии, которые сильно не подходят. А вот если есть небольшие несоответствия, то в письмах-откликах он об этом честно пишет. Например, коммерческой go разработки, как требуется в вашей вакансии, не было, но ... и дальше пытается убедить что это не проблема, бравируя моими устремлениями, целями и возможностями.
Хотя смотрю план на неделю и вижу что на среду он мне запланировал какую-то сессию вопросов по определению моих софт и хард скиллов, а так же опыта в той или иной сфере. Посмотрим, пока это только начало.
А промтом поделитесь? :)
Я опытным путём пришел к тому что одного промта всегда недостаточно, я пишу цель, ввожу агент в режим рассуждения и дополняю его предложения. По итогу формируется что-то ввиде базы знаний и действий, которая постоянно корректируется мной и самим агентом. Другими словами самый первый промт был "я хочу чтобы ты нашел мне работу"
Удачи с поиском!
Идея превратить этот скрипт в полноценный SaaS-продукт точно найдет свою аудиторию на рынке) Люди реально ненавидят тратить часы на написание персональных сопроводительных писем
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Я нанял ИИ искать мне работу. Дневник эксперимента, неделя первая